Development of an informatics system for accelerating biomedical research.

Abstract

Biomedical translational research can benefit from informatics system that support the confidentiality, integrity and accessibility of data.  Such systems require functional capabilities for researchers to securely submit data to designated biomedical repositories. Reusability of data is enhanced by the availability functional capabilities that ensure confidentiality, integrity and access of data. A biomedical research system was developed by combining common data element methodology with a service-oriented architecture to support multiple disease focused research programs. Seven service modules are integrated together to provide a collaborative and extensible web-based environment. The modules - Data Dictionary, Account Management, Query Tool, Protocol and Form Research Management System, Meta Study, Repository Manager and globally unique identifier (GUID) facilitate the management of research protocols, submitting and curating data (clinical, imaging, and derived genomics) within the associated data repositories. No personally identifiable information is stored within the repositories. Data is made findable by use of digital object identifiers that are associated with the research studies. Reuse of data is possible by searching through volumes of aggregated research data across multiple studies. The application of common data element(s) methodology for development of content-based repositories leads to increase in data interoperability that can further hypothesis-based biomedical research.

Introduction

Translational Medicine (TM) seeks to develop new treatments for diseases with insights towards the improvement of global health. To achieve this vision, understanding what and why interventions work, and how they can be scaled to benefit the entire population, depends on successful translational biomedical research and data lifecycle management. The process of TM is time consuming with translational barriers, from basic research to clinical application, bedside to community use, and from community to policy-making decisions. In overcoming the translational barriers, that biomedical informatics platforms reduce the time it takes for basic research to result in clinical applications ¹. To date, biomedical platforms for translational research have been developed for one or more purposes - (a) management of multi-dimensional heterogeneous data, (b) dissemination of knowledge generated during translational research, (c) testing of analytic approaches for data pipelines, and (d) application of knowledge-based systems and intelligent agents to enable high-throughput hypothesis generation ².

Several biomedical informatics applications have been discussed in the literature; for example, Research Electronic Data Capture (REDCap) is a software tool for collecting, storing, creating project specific databases for dissemination of clinical and translational research data ^{3, 4}. The informatics for integrating Biology and the Bedside (i2b2) system allows researchers to find cohorts of patients that fit specific profiles ⁵. Access to chemical, ‘omics’ and clinical data, with capabilities to investigate genetic and phenotypic relationships for cohorts of patients is supported by tranSMart platform ^{6, 7}. Analyses of large complex datasets with bioinformatics and image analysis tools, cloud services, application programming interfaces (APIs), and data storage capabilities is supported by the CyVerse infrastructure ^{8, 9}. Software tools to collect, manage, and share neuroimaging data of different modalities, including magnetic resonance imaging (MRI), magnetoencephalography (MEG), and electroencephalogram (EEG) is available through the Collaborative Informatics and Neuroimaging Suite (COINS) ^{10, 11}. Also, large scale analysis of biological data can be carried out by web-based platforms ¹². Within the National Institutes of Health (NIH), the Biomedical Translational Research Information System (BTRIS) has supported researchers to bring together data from the NIH Clinical Center and other institutes and centers ¹³.

However, many disease focused research programs have faced data discoverability and integration challenges. For example, traumatic brain injury (TBI) research data was initially collected in different ways and by disparate systems making sharing and reusing of data problematic. Because of the wide variability in systems and databases, many types of TBI injuries were classified as the same class of injury, impeding development of targeted therapies for the disease. To overcome these barriers, the TBI community recommended use of the common data elements (CDE) methodology for the development of the Federal Interagency Traumatic Brain Injury Research (FITBIR) ¹⁴.

A CDE is defined as a fixed representation of a variable collected within a specified clinical domain, that needs to be interpretable unambiguously in human and machine-computable terms ¹⁵. It consists of a precisely defined question with a specified format, with a set of permissible values as responses. Typically, CDE development for biomedical disease programs involves multiple steps - identification of a need for a CDE or group of CDEs, stakeholders and expert groups for CDEs selection, iterations and updates to initial development with ongoing input from broader community, with final endorsement of the CDEs by the stakeholder community for its usage and widespread adoption ¹⁶.

Examples of CDEs use in various programs of clinical research include neuroscience ¹⁷, rare diseases research ¹⁸, and management of chronic conditions ¹⁹. For clinical data lifecycle management, the use of CDEs provides a structured data collection process, which enhances the likelihood for data to be pooled and combined for meta-analyses, modeling, and post-hoc construction of synthetic cohorts for exploratory analyses ²⁰. Investigators working to develop protocols for data collection can also consult the NIH Common Data Element Resource Portal for using established CDEs for disease programs ²¹. Also, the feasibility of using common data elements and a data dictionary for the development of the National Database for Autism Research was shown earlier ²².

Three key components comprise data dictionaries: data elements, form structures and eForms. A data element has a name, precise definition, and clear permissible values, if applicable. A data element directly relates to a question on a paper, electronic form (eForm) and/or field(s) in a database record. Form structures (FS) serve as the containers for data elements, and the eForms are developed by using FS. The data dictionary provides defined CDEs, as well as unique data elements (UDEs) for specific implementation of the BRICS instance. Reuse of CDEs is significantly encouraged, and in the case of FITBIR’s data dictionary, it incorporates and extends the CDE definitions developed by the National Institute of Neurological Disorders and Stroke (NINDS) CDE Project ¹⁵.

In this paper we demonstrate the application of CDE concept for developing a Biomedical Research Informatics Computing System (BRICS), providing functionalities that facilitate electronic submission of research data, validation, curation, and archival storage within program specific data repositories. Use of CDEs enhances data quality and consistency within the repositories that are important for advancing clinical and translational research.

Method

A high level overview of the informatics system architecture is provided in Figure 1. The architecture is defined by the three layers - (a) Presentation Layer, (b) Application Layer, and (c) Data Layer. The Presentation Layer serves as the secure entry point to the BRICS portal. Various open source technologies and libraries, including Java Server Pages (JSP), jQuery, JavaScript libraries (e.g. such as Backbone.js, Asynchronous JavaScript), and XML are used to make web-pages interactive. This layer also includes Web Start applications: Global Unique Identifier (GUID) client, Validation and Upload tools, and Download and Image Submission tools, all of which run on users’ machines.

Figure 1. A schematic representation of the informatics system architecture.

The Image Submission Package Creation Tool leverages the 35 plus medical image file readers in the Medical Image Processing Analysis and Visualization (MIPAV) software (v 8.0.2), to make data interoperable, mapping of image header data onto the data elements in imaging form structures for submission to the Data Repository. MIPAV is an open-source software that can be used for image analysis, it is accessible on any Java-compatible platform, including Windows, Mac OS X, and Linux. Over 30 file formats commonly used in medical imaging, including DICOM and NIfTI, and more than ten 3D surface mesh formats are supported by the software ²³. It also supports multi-scale and multi-dimensional image research from various modalities including microscopy, computerized tomography (CT), positron emission tomography (PET), and MRI. Inclusion of the MIPAV tool with the BRICS provides capabilities for uploading image packages and image analysis, that is not conveniently available on other informatics systems ²⁴.

The Application Layer is responsible for the logic that determines the capabilities of the BRICS modules and tools. Seven service modules within the Application Layer are integrated together to provide a collaborative and extensible web-based environment. These modules are the Data Dictionary (DD), Account Management, Query Tool, Protocol and Form Research Management System (ProFoRMS), Meta Study, Repository Manager and GUID. To communicate and exchange information between the modules, representational state transfer (RESTful) Web services are used.

Additional information on the various service modules is available from the BRICS site.

The Data Layer consists of open source databases such as PostgreSQL, Virtuoso databases, file servers, and data persistence frameworks. The Virtuoso database is used to store the data accessed by the Query Tool and to store CDE metadata in the Data Dictionary data. The Repository module uses the PostgreSQL database to store and retrieve data. Also utilized are open-source libraries such as Hibernate and Apache Jena for storing and retrieve data from databases. The data layer is supported by the physical infrastructure located within the National Institutes of Health, and is certified at the Federal Information Security Modernization Act (FISMA) Moderate level ²⁵, conforming to additional USA federal information standards ^{26, 27}.

To de-identify data, researcher’s use the GUID tool (shown as a client in Figure 1) to assign a unique identifier for each study participant. The GUID is a random alphanumeric unique subject identifier (not generated from personally identifiable information (PII). The PII fields that can be used as part of the hashing process include complete legal given (first) name of subject at birth, middle name (if available), complete legal family (last) name of subject at birth, day of birth, month of birth, year of birth, name of city/municipality in which subject was born, and country of birth. The PII data is not sent to the GUID server but rather one-way encrypted hash codes are created and sent from the GUID client to the server (represented as a service module, Figure 1), allowing the PII to reside only on the researcher’s site. A random number for each of the research participant is generated by the server and is returned to the researcher. In addition, the GUID server can be configured to support multi-center clinical trials and investigations that enroll research participants across various programs.

Information package preparation

Researchers are responsible for most of the data submission activities, which includes study FS approval, eForms review, curation, mapping of data elements, and providing associated study documentation.

Two routes of data submission are available for researchers to make data findable. One approach is by using the ProFoRMS tool ( Figure 2, stage 1) for clinical research work, scheduling subject visits, collecting data, adding new data, modifying previously collected data entries, and correcting discrepancies that are tracked and maintained in audit logs. The other mode is by using a generic data collection system (e.g. RedCap), validating with the BRICS data dictionaries and uploading the extracted data into the repository module ( Figure 2, stage 2). Both routes of data submission validate the submitted data using specific range and values from the data dictionaries for a BRICS instance.

Figure 2. Schematic representation of 1. Submission Information Package (SIP), 2 - Archival Information Package (AIP) preparation, 3 - storage of AIPs, and 4 - Dissemination Information Packages (DIP) access.

The Validation Tool supports the data repository and ProFoRMs modules, by using CDEs with defined range and value metrics for data quality checks, to make data reusable. Once the data has been validated and uploaded via the submission upload tool, data is stored in its raw form within the repository module in a database that can be accessed by the Query Tool ( Figure 2, stage 3).

User support is provided for data stewardship activities that include training and assistance to authorized users, for CDE implementation, data validation and submission to the repositories. Access is controlled by a Data Access Committee (DAC) that reviews studies for relevance to a specified BRICS instance (defined by the biomedical program). In addition, access to the system is role based and specific permissions are associated with roles such as PI, data manager, and data submitter.

During packaging of data, GUIDs are assigned to research subjects (patients), using the GUID client with the users responsible for storing PII data locally within their institutional systems. Data curation is carried out by identifying the available standard forms and CDEs in the Data Dictionary. In the event no corresponding CDEs are available, then the user can define the data elements and obtain approval during the submission process.

Information package storage and management

The data Repository module serves as a central hub, providing functionality for defining and managing study information and storing the research data associated with each study ( Figure 2, stage 3). Authorized investigators can submit data to a BRICS instance, organize one or many datasets into a single entity called a Study. In general terms, a ‘Study’ is a container for the data to be submitted, allowing an investigator to describe, in detail, any data collected, and the methods used to collect the data, which makes data accessible. By using the repository user interface, researchers can generate digital object identifiers (DOIs) for a study, which can be referenced in research articles.

The repository module provides download statistics for specific studies, enabling the investigator to obtain information on their respective data that has been downloaded for other research activities, and overall increase data sharing and collaboration for additional research goals. Depending on the research studies, BRICS based repositories can host high throughput gene expression, RNA-Seq, SNPs, and sequence variation data sets ( Figure 2, stage 3).

Data sharing

By default, the system assigns the sharing preference as ‘private’ where only users to that specific study can access the data. When the data is in the private state, the PI has the option to share data with specific collaborators (preferential sharing). After a certain period (defined by the data sharing policy for each BRICS instance), the data enters a new ‘shared’ state, which is accessibleto the approved users.

Raw data is available for querying within 24 hours of data submission. For the data to be available via the Query Tool module, the raw data is processed through the ‘ NextGen Connect’ tool (integrated interface engine) and Resource Description Framework (RDF) data interchange tool ( Figure 2, stage 4). Shared data is available to all system users (approved by DAC) to search, filter, and download via the Query Tool functionality. The Query Tool offers three types of functionalities - (a) querying and filtering data, (b) data package downloads based on query, and (c) data package to the Meta Study module.

The Meta Study module is used for meta-analysis of the data as well as a collaboration tool between scientific groups. A Meta Study contains findings from studies that can be aggregated by researchers to conduct additional analysis. The Query tool can also support the statistical computing language R as well as structured visualization of data ( Figure 2, stage 4).

Result

The Query Tool (QT) enables users to browse studies, forms and CDEs, to select clinical data, use filters, and to sort and combine records. Using the GUID and a standard vocabulary via CDEs in forms, the QT provides an efficient means to reuse data by searching through volumes of aggregated research data across studies, find the right datasets to download and perform offline analysis using additional tools (e.g. SAS, SPSS, etc.). The statistical ‘ R-box’ tool, integrated with BRICS, has been incorporated in the QT, to support analysis without having to download data.

The QT has several ways to search for data. By default, the user is presented with all studies in the data repository that have data submitted against them. Users can use the QT to search for desired data by searching by study, or across studies by form or an individual data element ( Figure 3a).

Figure 3a. The Query Tool functionality is used to browse studies and forms, search data within forms and across studies.

Example from the Parkinson’s Disease Biomarker Program BRICS instance.

Each column of data in a QT result represents a well-defined element in the Data Dictionary. Users can refine results by selecting from the list of allowed element permissible values, like male or female, or move sliders to select a range of numeric values, like age or outcome scores (shown in Figure 3b).

Figure 3b. The Query Tool can be utilized by users to select from a list of data elements that exist or are part of a form structure.

In addition to providing tools to aid data discovery, the QT supports interactive features that facilitate analysis and practical use of the data through attribute-based filtering capabilities, based on the data element type.

Various datasets (e.g. clinical, cognitive, demographic) are available within the repositories that are integrated to the BRICS instances. Data can be shared in CSV file format for download, and/or stored in the Meta Study module for further analysis, research, and reference.

Biomedical data management use case

The Parkinson’s Disease Biomarker Program (PDBP) signifies the importance of Parkinson’s disease biomarker discovery process, which requires data replication and validation prior to clinical trial use ²⁸. Making both research data and workflow process findable, accessible, interoperable, and reusable was an important design consideration during the development of the PDBP system. The system consists of two major components - (a) Drupal-based portal, and (b) the PDBP Data Management Resource (DMR). The portal is publicly accessible to users for obtaining policy, stakeholders, individual PI, and specific study information, including summary data, and news (see PDBP site). The PDBP DMR is comprised of the previously discussed BRICS modules (shown in Figure 2) and incorporated the Parkinson’s disease CDEs into its Data Dictionary ²⁹. Use of CDEs results in making data FAIR by harmonization of clinical, imaging, genomics, laboratory, and biospecimen data. The CDEs are easily accessible from multiple open resources - the PDBP data dictionary ³⁰, the NINDS CDE project ¹⁵, and the NIH CDE repository ²¹. The DMR is securely managed with capabilities for account verification, GUID generation, data submission, validation, workflows, access, and biospecimen data management. A GUID is generated for each subject on their initial visit and is attached to the deidentified data. The GUID makes data reusable by enabling the aggregation of all research data (clinical, imaging, genomic, and biomarker) for a specific subject, both within a single study and across many PDBP studies.

The ProFoRMS module (shown in Figure 2) is used to schedule Parkinson’s Disease subject visits and capture data (including the GUID) via a web-based assessment form tool. It provides capabilities for real time data entry and automatic data harmonization and ensures data quality assurance prior to storage within the PDBP repository. Each of the questions in the PDBP DMR assessment form is associated to a CDE that supports reusability and interoperability of PDB data ^{28, 31}. The ProFoRMS also provides automatic assignment of specific forms to individualized cohorts based on protocol design, and quality assessment of data prior to uploading to the PDBP Data Repository.

The authorized PDBP users can use the QT for accessing data across studies and aggregate data based on assessment forms and CDEs, allowing for the linkage of biosample data to demographics data. More complex queries can be created by linking clinical data from ProFoRMS with imaging data from the MIPAV module and with corresponding biospecimens/biosamples.

Data can be downloaded directly from the PDBP data repository and/or from the Query Tool to be analyzed by researchers using their preferred tools. Because the DMR database contains only de-identified data, all data uploaded to the DMR can be shared with the scientific community. Use of standard operating procedures has resulted in harmonization of biospecimens/biosamples with the DMR Biosample Order Manager tool, which enables linking clinical and biorepository data ³². The PDBP data, queries and other metadata described for the research can be loaded into the Meta Study module and through the Meta Study user interface researchers can generate DOIs that can be referenced in research articles.

Biomedical Program Application

The initial deployment of BRICS was to support the U.S. Department of Defense's (DoD) and the National Institute of Neurological Disorders and Strokes (NINDS), FITBIR project. The core functionalities for FITBIR were reusable for developing PDBP, as well other biomedical programs.

A few highlights of the data repositories resulting from the implementation of BRICS instance for the biomedical programs are provided below -

Federal Interagency Traumatic Brain Injury Research (FITBIR). is a BRICS instance developed to advance comparative effectiveness research in support of improved diagnosis and treatment for those who have sustained a TBI ³³. The FITBIR repository stores data provided by TBI researchers and has accepted high quality research data from several studies, regardless of funding source and location. The DoD and NINDS provides funding for TBI human subject studies (both retrospective and prospective) and have required the research grantees to upload their clinical, imaging, and genomic data to FITBIR. As of 2018, there are 157 studies in FITBIR, spanning nearly hundred PIs, dozens of universities and research systems, the DoD, and the NIH. Data on 69,208 subjects, including more than 82,000 clinical image 3D data sets that are part of the repository. Currently, there are a total of 1,857,926 records in FITBIR. Data provided to FITBIR for broad research access are expected to be made available to all users within six months after the award period ends.

Parkinson’s Disease Biomarkers Program Data Management Resource (PDBP DMR). is a BRICS instance developed to support new and existing research and is a resource for promoting biomarker discovery for Parkinson's disease funded by NINDS, NIH. At the center of the PDBP effort is its DMR. The PDBP DMR uses a system of standardized data elements and definitions, which makes it easy for researchers to compare data to previous studies, access images and other information, and order biosamples for their own research. PDBP’s needs have accelerated BRICS system development, such as enhancements to the ProFoRMS data capture module, also with an investment into a BRICS plug-in for managing biosamples. The PDBP DMR now contains over 1,500 enrolled subjects, 1,415 of whom have biorepository samples. Also, PDBP has currently a total of 55,400 records.

eyeGENE. has a BRICS instance to support the National Ophthalmic Disease Genotyping and Phenotyping Network ³⁴. It is a research venture created by the National Eye Institute (NEI) to advance studies of eye diseases and their genetic causes, by giving researchers access to DNA samples and clinical information. Data stored in eyeGENE is cross-mapped to Logical Observation Identifiers Names and Codes terminology (LOINC) interoperability data standards ³⁵. Currently, eyeGene has 146,024 records with 6,400 enrolled subjects.

Informatics Core of Center for Neuroscience and Regenerative Medicine (CNRM) has a BRICS instance to support the CNRM medical research program with collaborative interactions between the U.S. DoD, NIH, and the Walter Reed National Military Medical Center. The Informatics Core provides services such as electronic data capture and reporting for clinical protocols, participation in national TBI research and data repository community, integration of CNRM technology requirements, and maintenance of a CNRM central data repository ³⁶. In addition, the Informatics Core has played an important role in the development of multiple BRICS modules used by FITBIR.

Common Data Repository for Nursing Science (cdRNS) has a BRICS instance to support the National Institute of Nursing Research (NINR) mission - to promote and improve the health of individuals, families, and communities ³⁷. To achieve this mission, NINR supports and conducts clinical and basic research and research training on health and illness. This research spans and integrates the behavioral and biological sciences, and that develops the scientific basis for clinical practice ³⁸. The NINR is a leading supporter of clinical studies in symptom science and self-management research. To harmonize data collected from clinical studies, NINR is spearheading an effort to develop CDEs in nursing science. Currently, there are 1,358 records in the cdRNS instance of BRICS.

The Rare Diseases Registry. has a BRICS instance for the Rare Diseases Registry (RaDaR) program of the National Center for Advancing Translational Sciences (NCATS). It is designed to advance research for rare diseases ³⁹. Because many rare diseases share biological pathways, analyses across diseases can speed the development of new therapeutics. The goal is to build a Web-based resource that integrates, secures, and stores de-identified patient information from many different registries for rare diseases, all in one place.

Discussion

The informatics system utilizes the Open Archival Information System (OAIS) model for preserving information for a designated community (group of potential consumers and multiple stakeholders). The implementation of the model highlights the importance of developing Submission, Archival, and Dissemination Information Packages ( Figure 2, SIPs, AIPs and DIPs) for longer term data preservation and reuse ⁴⁰. The primary producers of the data for the informatics system are the researchers and staff associated with each of the biomedical programs. Clinical data SIPs are produced for each of the instances by using eCRFs and imaging data SIPs are produced by the Image Submission tool. The CDEs and data dictionaries for the various BRICS instances support the development of archival information packages (AIPs), which are stored in distinct data repositories identified by the biomedical research programs ⁴¹. The portability of the informatics software is also possible by recent deployment to the National Trauma Research (NTR) data repository development work ⁴². In contrast to most of the centrally managed repositories within the NIH, the informatics software hosted for NTR is within a secure Amazon Web Services cloud platform. Deploying in the cloud environment enhances data access, sharing, and reuse of biomedical research data at larger scale ⁴³.

Supporting the FAIR principles

The FAIR (Findable (F), Accessible (A), Interoperable (I), and Reusable (R)) principles state that stewardship of digital data should promote discoverability and reuse of digital objects, which includes data, metadata, software and workflows ⁴⁴. In addition, the principles posit that data and metadata should be accompanied by persistent identifiers (PIDs), indexed in a searchable resource, retrievable by their identifiers, and use vocabularies that meet domain relevant community standards. The principles serve as guidelines for developing systems that can improve data discovery and reuse. In Table 1, we have correlated the various BRICS functional components, which contribute towards making data FAIR for biomedical research programs.

Table 1. Informatics functional components that support the FAIR (Findable (F), Accessible (A), Interoperable (I), and Reusable (R)) principles.

The FAIR principles listed in the table are from the cited reference 44.

	BRICS Functional Components
FAIR Principles	GUID	Data Dictionary	Data Repository	ProFoRMs	Query Tool	MetaStudy
Findable
Data are assigned a globally unique and eternally persistent identifier	x	x	x			x
Data are described with rich metadata		x	x	x	x	x
Metadata clearly and explicitly include the identifier of the data it describes			x			x
(Meta) data are registered or indexed in a searchable resource		x	x
Accessible
(Meta) data are retrievable by their identifier using a standardized communications protocol		x
The protocol is open, free, and universally implementable		x
The protocol allows for an authentication and authorization procedure, where necessary	x	x	x	x	x	x
Metadata are accessible, even when the data are no longer available		x
Interoper-able
(Meta) data use a formal, accessible, shared, and broadly applicable language for knowledge representation		x	x
(Meta) data use vocabularies that follow FAIR principles		x	x	x
(Meta) data include qualified references to other (meta) data		x			x
Reusable
(Meta) data have a plurality of accurate and relevant attributes		x	x		x	x
(Meta) data are released with a clear and accessible data usage license		x	x			x
(Meta) data are associated with their provenance		x	x			x
(Meta) data meet domain-relevant community standards		x	x

Unique identification that is machine-resolvable with a commitment to persistence is fundamental for providing access to data and metadata ⁴⁵. In the context of the informatics system discussed here, GUID does not imply findability on the web, however, it purports findability of research participant data within a BRICS instance. Authorized researchers can use GUID to link together all submitted information for a single participant, even if data was collected at different locations and/or for different purpose(s).

Several identifier schemes (e.g. DOI, Handle system, Identifiers.org, Uniform Resource Identifiers) vary in their characteristics ⁴⁶. A fundamental difference in an identifier scheme can be in the management (centrally or locally) of the resolver. For example, in the DOI scheme, a dereferencing service (e.g. Datacite or CrossRef) serves as a resolver that redirects the identifier to the actual content and the metadata.

The DOIs generated by BRICS is through the Interagency Data ID Service (IAD), which is operated by the U.S. Department of Energy Office of Scientific and Technical Information (OSTI). The IAD service acts as a bridge to DataCite, which is one of the major registries of DOIs. The DOIs are assigned to individual research studies and are findable within the established repositories, available also from open sites with core metadata supported via Data Tag Suite (DATS) 2.2 ⁴⁷.

The availability of an automated validation tool with the informatics system makes CDE findable in the Data Dictionary and ensures for data quality and consistency. The system provides for an automated means of mapping CDEs to other informatic systems data dictionaries, e.g. CDISC ⁴⁸. CDEs are made available through public websites (e.g. National Library of Medicine (NLM), NINDS CDE project, CDISC, etc.) to make data interoperable. Usability of data is enhanced by the adoption of standard imaging formats (e.g. DICOM, NIFTI, etc.). The informatics system also supports data discoverability across multiple repositories through the application of the biomedical and healthCAre Data Discovery Index Ecosystem (bioCADDIE) ⁴⁹.

Conclusion

Data confidentiality, integrity and accessibility are essential elements of responsible biomedical research data management. Community-wide data sharing requires development and application of informatics systems that promote collaboration and sustain data integrity of research studies within a secure environment. The informatics system presented above enables researchers to efficiently collect, validate, harmonize, and analyze research datasets for various biomedical programs. Integration of the CDE methodology with the informatics design results in sustainable digital biomedical repositories that ensure higher data quality. Aggregating data across projects, regardless of location and data collection time can define study populations of choice, for exploring new hypotheses based-research.

Data availability

Underlying data

All data underlying the results are available as part of the article and no additional source data are required

Software availability

Source code available from: https://github.com/brics-dev/brics

Archived source code at time of publication: http://doi.org/10.5281/zenodo.3355727 ⁵⁰

License: Other (open). Full license agreement is available from GitHub ( https://github.com/brics-dev/brics/blob/master/License.txt)

Funding Statement

The author(s) declared that no grants were involved in supporting this work.