Frequently Asked Questions

Please note: The BRIDG model is no longer actively maintained. All information is provided for reference purposes only.

1. What does BRIDG stand for?

BRIDG stood for Biomedical Research Integrated Domain Group. The primary value of the acronym was the word "BRIDG", representing a bridge between organizations, technical and domain experts, and different clinical information models.

2. What was the BRIDG Project?

The BRIDG Project was a collaborative effort engaging stakeholders from the Clinical Data Interchange Standards Consortium (CDISC), the United States Food and Drug Administration (FDA), the HL7 Biomedical Research and Regulation Work Group (BR&R), the International Standards Organization (ISO), and the US National Cancer Institute (NCI). The goal of the BRIDG Project was to develop a shared view of the domain of "protocol-driven research and its associated regulatory artifacts."

The formal definition of the domain-of-interest for BRIDG Project stakeholders was:

Protocol-driven research and its associated regulatory artifacts, i.e. the data, organization, resources, rules, and processes involved in the formal assessment of the utility, impact, or other pharmacological, physiological, or psychological effects of a drug, procedure, process, subject characteristic, biologic, cosmetic, food or device on a human, animal, or other subject or substance plus all associated r egulatory artifacts required for or derived from this effort, including data specifically associated with post-marketing adverse event reporting.

A shared view of the BRIDG Model's domain-of-interest was considered essential in achieving the larger goal of semantic interoperability (SI) both among people and systems (computable semantic interoperability (CSI)).

The BRIDG Project produced the requisite view of shared semantics as an object-oriented class model expressed in the Unified Modeling Language (UML), documenting classes, attributes, constraints, assumptions, examples, and relationships between classes. Numerous class diagrams were provided, including diagrams based on clinical research data exchange scenarios, project-based diagrams, topic-based diagrams, a comprehensive diagram, and moderate-sized sub-domain diagrams, each representing various areas within the model. The class model was supplemented by some state transition models, and earlier versions also included instance diagrams. Additional artifacts such as the BRIDG mapping document, change lists, and user’s guide were published with each BRIDG release. Although the BRIDG class model itself was the primary artifact, collectively, these artifacts formed the BRIDG Model release file.

3. Where can I find the BRIDG Model?

The BRIDG Model is available for download from the BRIDG GitHub site at  https://github.com/CBIIT/bridg-model. Please navigate to the "Releases" folder.

4. What was the purpose of BRIDG?

The goal of the BRIDG Project was to produce a shared view of the semantics of a common domain-of-interest, specifically the domain of basic, pre-clinical, clinical, and translational research and its associated regulatory artifacts.

The mission of BRIDG was to enable computable semantic interoperability (CSI), the ability for information systems to exchange, at a machine-to-machine level, the meaning (rather than simply the structure) of data and/or to effectively combine functionality across machine/system boundaries. A shared semantic view was considered essential for the clinical research community to achieve CSI in various data interchanges and application interactions between systems.

This shared view could be used to:

• Document information requirements before designing and building a solution.
• Build the information structures in the solution.
• Trace requirements throughout the solution development process.

In BRIDG, this shared view was expressed as a collection of visual diagrams using the iconography and grammar of the Unified Modeling Language (UML). This set of visual diagrams plus the underlying relationships, definitions, explanations, and examples were collectively referred to as the BRIDG Model. For a short introduction to UML, please see the BRIDG User Guide published with each release of the model.

5. Who was the intended audience (user) of BRIDG?

The target audience for the BRIDG model and its associated artifacts included anyone with an interest in learning more about the BRIDG Project. In particular, the BRIDG Modeling Team and the HL7 Biomedical Research & Regulation Work Group members expected that the content would be of use by:

• Domain experts working within the domain scoped by the BRIDG Model to review and validate the accuracy of the domain concepts and their representations.
• Analysts, architects, and developers working on defining specific data interchange semantics (e.g., message specifications, application APIs or services) and/or building other detailed design artifacts like logical and physical database models.
• Terminologists/ontologists interested in augmenting current work involving building ontologies in the BRIDG Model domain-of-interest.

6. Who were the BRIDG stakeholders?

The BRIDG Project was a collaborative effort engaging stakeholders from five organizations:

• Clinical Data Interchange Standards Consortium (CDISC)
  CDISC initiated BRIDG, was involved since its inception, and made BRIDG its reference information model for its many standards. Numerous versions of SDTM were harmonized with BRIDG, the latest being SDTM 3.2, along with previous harmonizations with the CDISC Lab Model, the PGx domains, Trial Design Model and CDASH. On the CDISC side, the CDISC SHARE logical data model was built on a BRIDG-based framework and many of the therapeutic areas were developed with an eye toward BRIDG concepts.
• US Food and Drug Administration (FDA)
  The FDA was an active participant in BRIDG, assisting in the harmonization of the adverse event model, the HL7 ICSR, Study Design and Study Participation messages and the Clinical Trials Repository in the earlier years, and then sponsoring the BRIDG to FHIR mappings.
• HL7 Biomedical Research & Regulation (BR&R) Work Group (HL7)
  This work group’s areas of interest encompassed clinical and translational research, both regulated and non-regulated, and the subsequent regulatory submissions and information exchanges to bring new products to market and to ensure safe use throughout the product lifecycle. BR&R creates and promotes standards to facilitate biomedical research and any subsequent regulatory evaluation of the safety, efficacy and quality of medical products that may arise from research.
• International Organization for Standardization (ISO)
  BRIDG was first balloted in ISO in 2010, then again in 2015 (BRIDG 3.2) and it passed the ISO balloting process. BRIDG is now an ISO standard, ISO 14199. ISO was added as the fifth stakeholder in BRIDG and was represented on the BRIDG Steering Committee.
• US National Cancer Institute (NCI)
  The NCI sponsored much of the development of the BRIDG model and served as custodians of the BRIDG model managing all modeling and maintenance activities. Semantics from numerous NCI projects were harmonized with the BRIDG model covering areas such as imaging, oncology, bench research, donor-related clinical trials, etc. NCI hosted the web site and provided modeling, harmonization and curation services for the BRIDG model. NCI also provided other infrastructure support such as GitHub project space, etc. The BRIDG model semantics were also available through NCI’s metadata repository (caDSR).

7. What is a Domain Information Model (DIM)?

A Domain Information Model (DIM) is defined by the following characteristics:

• An implementation-independent view of a domain of interest
• Represents a shared understanding of concepts
• Uses domain terminology and is understandable to domain experts may have little or no UML skills but are a primary consumer
• Includes unambiguous definitions
• Uses complex data types designed specifically for the domain of focus
• Follows good modeling practices
• Enables interoperability when systems shared a common understanding
• Is built by analysts and subject matter experts who developed consensus
• Informs development of downstream artifacts

The BRIDG model was primarily a conceptual model from which detailed design level artifacts could be built.

8. How was BRIDG updated? What is harmonization?

The BRIDG model was updated through a process called harmonization. Harmonization is a multi-step process of:

• Extracting knowledge from two or more sources, stakeholders, or perspectives,
• Assessing the underlying commonalities and differences based on the meaning, not names or representation, and
• Determining a common, non-ambiguous representation of that knowledge across the various stakeholders.

Ideally harmonization is done by an informed, neutral group who must decide if the various perspectives represent the same or different semantic content. What is challenging is that sometimes the same basic concept has different names across the various sources. Alternatively, sometimes the same name is used to mean different things across various, sources requiring an examination of differences in terms of context, culture or deep-layer semantics. Thus, the process may be complex and time-consuming and can involve back and forth discussions or investigation to identify exactly what is meant and how best to represent it. It can also impact existing concepts in the model causing a refinement in definition or representation of a previously harmonized concept. At the end, the goal is to have a model of shared meaning, even if different stakeholders prefer their own names; as long as the underlying meaning is the same, data exchange can successfully be conducted based on that meaning. In support of that, all BRIDG model element descriptions contained an “OTHER NAME(S)” section where synonyms could be captured.

Note that in some cases, content from a given source was not added to the BRIDG model, such as when a concept was outside the scope of BRIDG, was highly specialized for a specific purpose, was implementation-specific, such as audit metadata. Additionally, since BRIDG supported a wide range of scenarios the cardinality and data type of a given concept may be less constrained than a given source project would have it because BRIDG must satisfy the needs of other users also. In such cases, users of the BRIDG model were able to constrain the representation in BRIDG to suit their requirements, such as making something mandatory that is optional in BRIDG, or changing the data type from a generic quantity or code data type to a specific kind. Such changes were still compatible with BRIDG. With model harmonization, change is inevitable, so planning for change is essential.

9. How did the BRIDG Model relate to similar efforts? What was the advantage of BRIDG?

As a Domain Information Model (DIM), BRIDG was intended to cover the domain of protocol-driven research and associated artifacts. This domain naturally overlapped with numerous other domains, some of which had domain analysis models already in process while others did not. The BRIDG Modeling Team intended to harmonize with those projects on the common semantics as directed by the Steering Committee.

The key advantage of the BRIDG Model was that it was a shared view of the semantics of protocol-driven research as understood by the stakeholders and represented countless hours of consensus development.

10. Why should I use BRIDG? Why should I get involved? Why should I care?

The BRIDG Model is a mature, stable model of the domain of translational research. It is an ISO standard (ISO 14199) that was vetted by subject matter experts over its 10+ years. It provides a conceptual view of concepts which includes clear, unambiguous definitions, semantically robust data types, high-level cardinality that can be constrained, explicit relationships between concepts, as well as example values, other names, and notes when appropriate. Using such a model helps to consistently define, use, and re-use clinical information globally across the clinical information life cycle and facilitates information sharing within an organization as well as with external customers, partners, vendors, and regulators.

Please note:  The BRIDG model is no longer actively maintained. The information is provided for reference purposes only.

11. What is Computable Semantic Interoperability?

The primary use case for the BRIDG Model was the need to achieve computable semantic interoperability (CSI) within the domain of protocol-driven research as well as between this domain and others that may intersect with it at the interoperability level. For example, the domains of protocol-driven research and public health both share the concept of adverse events. It is beyond the scope of this BRIDG FAQ to discuss the full details of CSI, but a summary of the so-called Pillars of Computable Semantic Interoperability can be stated as follows:

• Pillar #1: Common model across the domains/sub-domains-of-interest
• Pillar #2: Computationally robust data type specification
• Pillar #3: Framework for binding context-specific terminologies to model elements
• Pillar #4: Methodology for constructing interoperability “building blocks” (e.g., data interchange structures or application service specifications) built around successful construction of Pillars #1 - #3

The BRIDG Model was a manifestation of Pillar #1. The BRIDG Model supported Pillar #2 through the specification of each BRIDG Model attribute using the HL7 v3 abstract data type standard. Pillar #3 can be supported by leveraging tooling support from NCI’s Cancer Data Standards Repository (caDSR) and Enterprise Vocabulary Services (EVS). Not all organizations will address Pillar #4 in the same way, however, the evolving HL7 FHIR standard is one avenue.

12. What domain concepts were included in the BRIDG Model?

BRIDG concepts were represented by classes grouped into sub-domain packages in the Enterprise Architect (EA) file. The sub-domains logically grouped related classes and included:

• Common: people, organizations, various roles, products, places
• Protocol Representation: protocol document and amendments, study design, study agents and arms, planned study personnel, sites and resources
• Study Conduct: scheduled and performed activities, results, actual study personnel, sites and resources, study status
• Biospecimen: specimens – biologic and others, specimen collection groups, specimen processing and moving
• Imaging: imaging study, imaging acquisition and reconstruction protocols, radiopharmaceuticals
• Molecular Biology: biomarkers, genes, genetic variations, genetic observations and results
• Adverse Event: adverse events, actions taken, causality, seriousness, outcome, product investigation
• Experiment: experiment, experimental activity items and factors, device parameters, in vivo-, in vitro-, and physico-chemical characterization
• Regulatory: regulatory applications, submissions, sponsors, assessments
• Statistical Analysis: statistical analysis plans and modification summaries, general and sample-size statistical considerations, data monitoring committee charter

All classes had associations to other classes within and/or across sub-domains.

13. How do I read a UML Class Model?

The Unified Modeling Language (UML) is a "standardized general-purpose modeling language in the field of software engineering" defined by the Object Management Group. There is a brief introduction to UML concepts and how to read a UML class diagram in the Appendix of the BRIDG User’s Guide. Download a copy of the latest BRIDG release package and navigate to the Documentation folder to find the User’s Guide.

14. What tools do I need to view the BRIDG Model?

The UML representation of the BRIDG Model was developed and maintained in a UML modeling tool from Sparx Systems called Enterprise Architect. A free viewer which enables full traversal and inspection of the complete BRIDG Model (which is an .EAP file) can be downloaded from the Sparx Systems website   http://www.sparxsystems.com/products/ea/downloads.html.

Alternatively, the BRIDG modeling team published either an RTF or PDF report of the content of the BRIDG EAP file, which can be viewed using a word processor. There is also an XMI export of the BRIDG EAP file which can be imported into most UML modeling tools. Both the report format and the XMI representation are part of every BRIDG release package.

15. Is there a glossary or dictionary for the BRIDG Model?

Yes, the BRIDG Model glossary is maintained on the BRIDG GitHub site. In addition, definitions for all classes, attributes, and associations can be found in the BRIDG Model.

16. Who used BRIDG? How?

The BRIDG Model was used in a variety of ways by different types of organizations. Described here are some of those implementations, provided for reference purposes only, as the BRIDG model is no longer being actively maintained and the continued use of BRIDG by the organizations has not been verified.

• NCI's caDSR
  The National Cancer Institute (NCI) established the cancer Data Standards Registry and Repository (caDSR) and its associated applications to help the research community manage and use data standards by providing shared standards in a variety of human and machine-readable contexts. caDSR includes a database, application programming interfaces (APIs), and web-based applications for creating and using data standards for cancer metadata. The metadata in caDSR describes data elements, forms, and information models used in cancer research and clinical trials. The 3.0.2 version of BRIDG was first registered in caDSR in 2010 to help expose its classes and attributes as a set of non-enumerated CDEs specified using generic ISO datatypes. This occurred during NCI's caBIG initiative, when models were routinely recorded in caDSR. Over time, it became apparent that there were many ways to describe similar semantics when concepts were arbitrarily selected from the NCI Thesaurus, resulting in caDSR content that was not automatically connected through underlying metadata components, even when semantics were the same. In 2017, a more deliberate alignment of CDEs using BRIDG caDSR content as a higher-level semantic model was explored, helping to unify semantics through a well-designed information model. The first experiment was a joint project with the FDA and the National Center for Advancing Translational Sciences (NCATS), known as the Common Data Model Harmonization (CDMH) project. During this project, the BRIDG team mapped data elements in OMOP (OHDSI), PCORNet, I2B2ACT, and Sentinel (FDA) to BRIDG, and the caDSR curation team registered the CDEs, deliberately reusing BRIDG components. This enabled simple queries leveraging the caDSR underlying meta model to retrieve semantically related CDEs, allowing linkage of models with different levels of granularity and value sets. Multiple ways to record "mappings" to BRIDG were explored, such as adding explicit mapping tags as alternate designations for CDEs, but this method provided the most direct way to facilitate interoperability.
• National Marrow Donor Program (NMDP)
  The Center for International Blood and Marrow Transplant Research (CIBMTR) is a combined research program of the National Marrow Donor Program® and the Medical College of Wisconsin, which facilitates critical research on cellular therapy outcomes. Since 1972, just four years after the first successful hematopoietic cell transplantation (HCT), pioneers in the field of HCT recognized the significance of their work and the importance of collating and sharing data. This collaboration with the global scientific community led to research that increased survival and enriched quality of life for thousands of patients. CIBMTR, through its research partners, embraced data standards for electronic data capture and transfer. Common data elements (CDEs) within the Cancer Data Standards Repository (caDSR) for high-profile CIBMTR forms were extracted and associated with the BRIDG model. These CDEs represented outcomes data for hematopoietic cell transplantations and other cellular therapies.
• Thomas Jefferson University
  A major barrier to the conduct of biomedical research has been the difficulty of sharing biomedical research data, both within and between institutions. Data located in different repositories were almost always organized, categorized, and represented in different ways—a problem referred to as "the Chasm of Semantic Despair." In an attempt to address this problem, the Cancer Informatics group at the NCI, in collaboration with colleagues at the FDA, ISO, HL7, and CDISC, developed an international standard data model for biomedical research called the Biomedical Research Integrated Domain Group (BRIDG) model. The purpose of the BRIDG model was to "bridge" the many chasms of semantic despair that existed within and between academic medical centers, pharmaceutical companies, and government regulators. The Sidney Kimmel Cancer Center at Thomas Jefferson University in Philadelphia successfully designed and implemented a cancer research information system based on the NCI-BRIDG model. In a 2019 presentation, Dr. Klumpp described how the BRIDG model was implemented in the cancer research information system at Thomas Jefferson and the benefits of such an integrated system. (Summary of Dr. Klumpp's presentation to NCI CBIIT Speakers Series, Feb. 2019)
• FDA's Common Data Model Harmonization (CDMH)
  The Common Data Model Harmonization (CDMH) Phase 1 project was designed to harmonize specific common data models (CDMs) so that important research information could be more easily shared and interpreted. The CDMs from Patient-Centered Outcomes Research Network (PCORNet), Informatics for Integrating Biology & the Bedside (i2b2/Accrual to Clinical Trials (ACT)), Observational Medical Outcomes Partnership (OMOP), and Sentinel were mapped to the Biomedical Research Integrated Domain Group (BRIDG) model as the intermediary model. The resulting 'reference model' from this harmonization (a BRIDG-informed database) was used to generate use case queries that were tested by several data partners, using electronic health records and administrative claims as data sources.
• FDA's Janus
  Janus is a data repository for subject-level clinical and nonclinical study data submitted to FDA as part of a regulatory submission. It was designed to support a transparent, consistent, and efficient scientific review process by performing automated extraction, transformation, loading, management, and integration of data to facilitate regulatory review. The Janus conceptual model was informed by the BRIDG model, was designed to receive data in CDISC SDTM format, and could support other emerging study data exchange standards, such as HL7 FHIR, v3, and RDF.
• PAREXEL
  Parexel Informatics utilized BRIDG as the basis for a central common data model (CDM) to increase semantic consistency and quality across a diverse portfolio of products and services. BRIDG provided standard domain models, well-defined terminologies, and consistent data types that supported the use of those terminologies and provided metadata for structured data management. Together, these benefits created a "shared language" across disparate applications. BRIDG was valuable in improving the quality of system integrations and new software development. This effort was launched to reduce the amount of time required to map customers' applications, increase the ability to reuse existing code, and achieve greater consistency across projects. All new development projects were intended to utilize the BRIDG-based CDM to provide a common understanding of business processes, a single source of interoperable schemas, and greater consistency across interoperable systems. This CDM was also expected to make it easier to reuse existing code for disparate software implementations. Implementation of any standard required an up-front investment for future value, and Parexel intended to make this investment available to the wider community by making their implementation of BRIDG widely available.

17. How much did BRIDG cost?

There was no charge for accessing or using any of the BRIDG content.

18. Was BRIDG copyrighted?

The BRIDG Model was governed by CDISC Intellectual Property policy.

19. What versions of BRIDG are supported?

The BRIDG model, while a valuable historical resource, is  no longer actively maintained. Access to this information is provided for reference purposes, acknowledging its past contributions to the field.

20. How did I know that my project semantics were harmonized with the BRIDG model?

As a result of the harmonization process, the BRIDG Modeling team worked closely with project teams to enable the project team to build a detailed mapping of each project team concept to a BRIDG concept. This was represented as a mapping spreadsheet (in Excel format), included in every BRIDG release. Mapping tags in the model itself indicated to which BRIDG concepts the project semantics mapped. Additionally, there was often a project-level diagram illustrating the BRIDG concepts to which the project’s concepts mapped.

21. How could one find which BRIDG model elements a project was mapped to?

When a project was harmonized with BRIDG, a mapping spreadsheet was created showing the project model’s elements and their metadata in columns on the left, the corresponding BRIDG model elements and their metadata in the columns on the right, and several columns in the middle supporting the process of mapping a source model to the BRIDG model, such as a mapping path to show the connections between classes in BRIDG that link to the target element, comments and rationale, status and such.

Another way was to review the project-level diagram. Most recent harmonizations concluded with a project-level diagram being added to the model.

Finally, when a harmonization was finished, the BRIDG modeling team added mapping tags to each BRIDG model element that was a target of a mapping in the mapping spreadsheet. Each of these tags captured the name of the project model and its version as well as the name of the project model element that maps to that BRIDG model element. This allowed the BRIDG model to self-document its own provenance and users could use this information to run queries, generate reports, assess for impact analysis, trace back to the mapping spreadsheet, etc.

22. What were “mapping tags”?

Mapping tags were a way to track what project model elements had been mapped to a given BRIDG model element. The BRIDG model leveraged a feature available in the Enterprise Architect software where a tag name and tag value could be defined on any model element. BRIDG used a convention for the tag names:

• Map:ProjNamevX.X (e.g., Map:SDTM IGv3.2)

…where “Map:” was the standard prefix or boilerplate, “ProjName” was a shorthand, acronym or abbreviation of the project or model name, and “vX.X” was an indication of the version or release number.  The mapping tag values are the names of the project’s data elements. 

Mapping tags thus traced the provenance of each concept in the model and could greatly help in impact analysis when remodeling a concept or help assess interface requirements between two or more BRIDG-harmonized models or systems. The BRIDG User’s Guide published with each release of BRIDG included a table of mapping tag names and the harmonized project’s full name.

23. Could the BRIDG Model be used to implement a physical design or generate code?

The BRIDG model was intended to be a conceptual model for clinical research. It could be leveraged to further build out detailed logical models and physical designs. It was a robust UML class diagram and could be used to design downstream artifacts.

24. Did BRIDG have instance diagrams or state transition diagrams?

The BRIDG Model historically contained a package with a variety of instance diagrams illustrating how to use the BRIDG classes to represent domain concepts using sample data. Likewise, there was a package containing state transition diagrams. These packages were available in the UML model, but not in the HTML version. Over the last several years of the project, no new instance diagrams were added nor were existing ones updated, so the BRIDG modeling team decided to drop the instance diagram package from the BRIDG 5.3.1 model. The package remains available in UML versions of all previous BRIDG releases.