Frequently Asked Questions
BRIDG stands for Biomedical Research Integrated Domain Group. However, the primary value of the acronym is the word "BRIDG", which represents a bridge between organizations, technical and domain experts, and different clinical information models.
The BRIDG Project is 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 is to develop a shared view of the domain of "protocol-driven research and its associated regulatory artifacts." Specifically, the formal definition of the domain-of-interest for the BRIDG Project stakeholders is:
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 regulatory 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 is essential in achieving the larger goal of semantic interoperability (SI) both among people and systems (computable semantic interoperability (CSI)).
The BRIDG Project produces 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 are provided, including diagrams based on clinical research data exchange scenarios, project-based diagrams, topic-based diagrams, a comprehensive diagram, moderate-sized sub-domain diagrams, each representing various areas within the model. The class model is supplemented by some state transition models and earlier versions also had instance diagrams. There are several additional artifacts of interest that are published with each BRIDG release, such as the BRIDG mapping document, change lists, user's guide, etc. Although the BRIDG class model itself is the primary artifact, collectively, these artifacts form the BRIDG Model release file.
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 regulatory 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 is essential in achieving the larger goal of semantic interoperability (SI) both among people and systems (computable semantic interoperability (CSI)).
The BRIDG Project produces 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 are provided, including diagrams based on clinical research data exchange scenarios, project-based diagrams, topic-based diagrams, a comprehensive diagram, moderate-sized sub-domain diagrams, each representing various areas within the model. The class model is supplemented by some state transition models and earlier versions also had instance diagrams. There are several additional artifacts of interest that are published with each BRIDG release, such as the BRIDG mapping document, change lists, user's guide, etc. Although the BRIDG class model itself is the primary artifact, collectively, these artifacts form the BRIDG Model release file.
The BRIDG Model can be downloaded from the BRIDG website at https://bridgmodel.nci.nih.gov. Please navigate to the "Download & Archive" menu. You can download the current and previous published versions of the BRIDG model, as well as the current working copy of the BRIDG model from the Download & Archive menu.
The goal of the BRIDG Project is 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 is 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 is essential if the clinical research community, both for itself and also as part of the larger healthcare and life sciences communities, is to achieve CSI in the various data interchanges and application interactions between systems.
This shared view can be used to:
The mission of BRIDG is 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 is essential if the clinical research community, both for itself and also as part of the larger healthcare and life sciences communities, is to achieve CSI in the various data interchanges and application interactions between systems.
This shared view can 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.
The target audience for the BRIDG model and its associated artifacts is, first and foremost, anyone with an interest in learning more about the BRIDG Project in general. In particular, the BRIDG Modeling Team and the HL7 BR&R Work Group members expect that the content will be of use by the following:
- 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.
Please go to the About section to learn more about the BRIDG stakeholders and governance.
Please go to Background section to learn more about the history and evolution of the BRIDG project.
A Domain Information Model (DIM) can be 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 who 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, in our case health care
- Follows good modeling practices
- Enables interoperability when systems share a common understanding
- Is built by analysts and subject matter experts who develop consensus
- Informs development of downstream artifacts
A new release of the BRIDG Model is published once a year at a minimum, occasionally twice, at the discretion of the BRIDG modeling team and steering committee, based on harmonization schedules, balloting plans and the degree to which new semantics have been added to the BRIDG model. Documentation for the BRIDG Model is also updated with each release and an overview of the changes from one release to the next are covered in the Release Notes, with detailed changes at class, attribute and relationship level documented in the Change List files.
The BRIDG model is updated through a process called harmonization. Harmonization is a multi-step process of...
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 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 contain an “OTHER NAME(S)” section where synonyms can be captured.
Note that in some cases, content from a given source is not added to the BRIDG model, such as when a concept is outside the scope of BRIDG, or is highly specialized for a specific purpose, or is implementation-specific, such as audit metadata. Additionally, since BRIDG supports 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 are 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 are still compatible with BRIDG. With model harmonization, change is inevitable, so planning for change is essential.
- 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 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 contain an “OTHER NAME(S)” section where synonyms can be captured.
Note that in some cases, content from a given source is not added to the BRIDG model, such as when a concept is outside the scope of BRIDG, or is highly specialized for a specific purpose, or is implementation-specific, such as audit metadata. Additionally, since BRIDG supports 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 are 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 are still compatible with BRIDG. With model harmonization, change is inevitable, so planning for change is essential.
As a Domain Information Model (DIM), BRIDG is intended to cover the domain of protocol-driven research and associated artifacts. This domain naturally overlaps with numerous other domains, some of which have domain analysis models already in process while others do not. For example, the HL7 O&O Specimen Domain Analysis Model (DAM) overlaps with BRIDG in some areas while having a substantially different scope. The Federal Health Information Models (FHIMS) is another model with a significant amount of overlap. As the BRIDG team becomes aware of other DAMs and those DAMs become mature models, the BRIDG Modeling Team intends to harmonize with those projects on the common semantics given the direction by the Steering Committee. After such a harmonization effort, it is possible that the sub-domains in BRIDG may shrink or give way to references to other DAMs which more reasonably are the "home" model of those semantics of which the BRIDG Model will make use. BRIDG may also end up expanding if the need arises to cover other areas brought by new projects whose semantics are not yet harmonized into another domain model.
From another perspective, the BRIDG Model may be the basis for deriving various levels of project implementation models with obvious additions or changes to accommodate implementation-specific requirements.
The key advantage of the BRIDG Model is that it is a shared view of the semantics of protocol-driven research as understood by the stakeholders and as such represents countless hours of consensus development.
From another perspective, the BRIDG Model may be the basis for deriving various levels of project implementation models with obvious additions or changes to accommodate implementation-specific requirements.
The key advantage of the BRIDG Model is that it is a shared view of the semantics of protocol-driven research as understood by the stakeholders and as such represents countless hours of consensus development.
The BRIDG Model is a mature, stable model of the domain of translational research. It is an ISO standard (ISO 14199) that has been 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. It is updated on a regular yearly basis (at least) and provides an avenue for extending the model - submitting new concepts and/or updating existing concepts. 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. There are a variety of ways to leverage BRIDG to enhance the quality of a model or system and it can enable semantically consistent data exchange structures while reducing the upfront modeling effort.
If this value proposition addresses at least some of your concerns, it’s fairly easy to get involved or engage the BRIDG community to obtain further information, to get questions answered, or to submit proposed enhancements to the BRIDG model and provide feedback via the balloting process. The BRIDG model is discussed periodically on the HL7 Biomedical Research and Regulation Work Group (BR&R WG) conference calls which occur weekly on Tuesdays and are always open to new attendees. For more information, please see the Contact Us page on the BRIDG website.
If this value proposition addresses at least some of your concerns, it’s fairly easy to get involved or engage the BRIDG community to obtain further information, to get questions answered, or to submit proposed enhancements to the BRIDG model and provide feedback via the balloting process. The BRIDG model is discussed periodically on the HL7 Biomedical Research and Regulation Work Group (BR&R WG) conference calls which occur weekly on Tuesdays and are always open to new attendees. For more information, please see the Contact Us page on the BRIDG website.
It is important to note that the overarching, primary use case for the BRIDG Model is the need to achieve computable semantic interoperability (CSI) both 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) that are built around successful construction of Pillars #1 - #3
The BRIDG concepts are represented by classes that are grouped into sub-domains packages in the Enterprise Architect (EA) file. The sub-domains logically group related classes and include the following:
All classes have associations to other classes within and/or across sub-domains.
- 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 have associations to other classes within and/or across sub-domains.
The Unified Modeling Language (UML) is a "standardized general-purpose modeling language in the field of software engineering" and is defined by an organization called the Object Management Group (more information available at http://www.omg.org/, quoted text is referenced from http://en.wikipedia.org/wiki/Unified_Modeling_Language).
While it is not within the purview of an FAQ to explain the details of UML, there is a handy but 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.
While UML might not be easy to understand for all domain experts, the BRIDG modeling team has found that most domain experts can become comfortable with it or at least work with an analyst who assists in interpreting the model to help ensure needed semantics are in the model. Additionally, the BRIDG modeling team has made representation decisions that occasionally diverge from the most strict interpretations of UML for the sake of accessibility to non-technical readers, such as using class-level constraints as visual clues or reminders of business rules binding how classes and/or attributes can be used.
While it is not within the purview of an FAQ to explain the details of UML, there is a handy but 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.
While UML might not be easy to understand for all domain experts, the BRIDG modeling team has found that most domain experts can become comfortable with it or at least work with an analyst who assists in interpreting the model to help ensure needed semantics are in the model. Additionally, the BRIDG modeling team has made representation decisions that occasionally diverge from the most strict interpretations of UML for the sake of accessibility to non-technical readers, such as using class-level constraints as visual clues or reminders of business rules binding how classes and/or attributes can be used.
The Unified Modeling Language (UML) representation of the BRIDG Model is 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 publishes 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.
Alternatively, the BRIDG modeling team publishes 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.
Yes, the BRIDG Model glossary is maintained on the BRIDG website. In addition, definitions for all classes, attributes, and associations can be found in the BRIDG Model.
Questions or comments about the BRIDG Model can be directed to the BRIDG Modeling Team members through (bridgTHC-L@list.nih.gov). Questions and or comments can also be posted to the HL7 BR&R listserv (biomedrr@lists.hl7.org).
Project teams wishing to harmonize their content with BRIDG or to discuss the logistics of BRIDG harmonization are urged to contact the members of the BRIDG Modeling Team through (bridgTHC-L@list.nih.gov).
The BRIDG model is balloted annually through HL7 and CDISC. Review of the ballot material and providing comments is one way to influence the design and the semantics of the model. Every few years, BRIDG is also balloted at ISO and that provides another opportunity to provide feedback and ask questions.
The BRIDG model is discussed actively at various HL7 meetings, conference calls and on the HL7 listserv. Consider joining the HL7 BR&R listserv to learn more (biomedrr@lists.hl7.org).
The BRIDG model is balloted annually through HL7 and CDISC. Review of the ballot material and providing comments is one way to influence the design and the semantics of the model. Every few years, BRIDG is also balloted at ISO and that provides another opportunity to provide feedback and ask questions.
The BRIDG model is discussed actively at various HL7 meetings, conference calls and on the HL7 listserv. Consider joining the HL7 BR&R listserv to learn more (biomedrr@lists.hl7.org).
There is no charge for accessing or using any of the BRIDG content.
The BRIDG Model is governed by CDISC Intellectual Property policy. You can read about this here
New releases of BRIDG are produced once or twice a year. The current release and all historical releases of BRIDG can be found on the BRIDG website at https://bridgmodel.nci.nih.gov/. Once released, prior versions of BRIDG are not maintained. New features and the results of mapping new projects or new versions of existing projects are reflected only in the newest release of BRIDG after the mapping is completed. With every release since BRIDG 3.0, the BRIDG Modeling Team has published a change list that documents a detailed list of every attribute, class, relationship and constraint that have been added, deleted or modified in the BRIDG model since its previous version/release along with a list of things that are currently deprecated and are thus candidates for deletion in a future release. Organizations adopting the BRIDG Model are expected to manage any software or infrastructure that is dependent on a particular version of BRIDG in the same fashion that they would manage dependencies to other software/hardware technologies.
The BRIDG Modeling Team strives to ensure that semantics harmonized into and represented in one version are still available in the next version or are deprecated with at least a year for users to have their say as to whether that concept is still needed. However, as more is learned about any given semantic, the representation may change from one version to the next. The core concept is preserved but may map to a different BRIDG class or attribute. Documentation provided with the model helps users understand where their semantics reside. Each class and attribute in the BRIDG UML model is tagged with the name of the source model element(s) to which it is mapped. If remodeling of a concept is required, all mapping tags are curated so that its clear where the semantic maps in the new version of BRIDG.
The BRIDG Modeling Team strives to ensure that semantics harmonized into and represented in one version are still available in the next version or are deprecated with at least a year for users to have their say as to whether that concept is still needed. However, as more is learned about any given semantic, the representation may change from one version to the next. The core concept is preserved but may map to a different BRIDG class or attribute. Documentation provided with the model helps users understand where their semantics reside. Each class and attribute in the BRIDG UML model is tagged with the name of the source model element(s) to which it is mapped. If remodeling of a concept is required, all mapping tags are curated so that its clear where the semantic maps in the new version of BRIDG.
As a result of the harmonization process, the BRIDG Modeling team works closely with the project teams to enable the project team to build a detailed mapping of each project team concept to a BRIDG concept. This is represented as a mapping spreadsheet (in Excel spreadsheet format). This mapping spreadsheet is part of every BRIDG release. Furthermore, mapping tags in the model itself indicate to which BRIDG concepts the project semantics map. Additionally, there is often a project-level diagram illustrating the BRIDG concepts to which the project’s concepts mapped.
When a project is harmonized with BRIDG, a mapping spreadsheet is created which shows 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 that support 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. This is one way to identify what elements in the BRIDG model the project was mapped to.
Another way to see which BRIDG model elements represent the concepts in the source project is to review the project-level diagram. Most recent harmonizations have concluded with a project-level diagram being added to the model, and as time permits the BRIDG modeling team is backfilling class diagrams for some of the relevant older harmonized projects. Note that these project-level diagrams now also carry a link to download a spreadsheet containing the definitions of all the classes and attributes displayed in that diagram.
Finally, when a harmonization is finished, the BRIDG modeling team adds mapping tags to each BRIDG model element that was a target of a mapping in the mapping spreadsheet. Each of these tags captures the name of the project model and it’s version as well as the name of the project model element that maps to that BRIDG model element. This allows the BRIDG model to self-document its own provenance and users can use this information to run queries, generate reports, assess for impact analysis, trace back to the mapping spreadsheet, etc.
Another way to see which BRIDG model elements represent the concepts in the source project is to review the project-level diagram. Most recent harmonizations have concluded with a project-level diagram being added to the model, and as time permits the BRIDG modeling team is backfilling class diagrams for some of the relevant older harmonized projects. Note that these project-level diagrams now also carry a link to download a spreadsheet containing the definitions of all the classes and attributes displayed in that diagram.
Finally, when a harmonization is finished, the BRIDG modeling team adds mapping tags to each BRIDG model element that was a target of a mapping in the mapping spreadsheet. Each of these tags captures the name of the project model and it’s version as well as the name of the project model element that maps to that BRIDG model element. This allows the BRIDG model to self-document its own provenance and users can use this information to run queries, generate reports, assess for impact analysis, trace back to the mapping spreadsheet, etc.
Mapping tags are a way to track what project model elements have been mapped a given BRIDG model element. The BRIDG model leverages a feature available in the Enterprise Architect software where a tag name and tag value can be defined on any model element. BRIDG uses a convention for the tag names:
Map:ProjNamevX.X For Example: Map:SDTM IGv3.2
…where “Map:” is the standard prefix or boilerplate, “ProjName” is a shorthand, acronym or abbreviation of the project or model name, and “vX.X” is an indication of the version or release number. The mapping tag values are the names of the project’s data elements. The mapping tags thus trace the provenance of each concept in the model and can greatly help in impact analysis when remodeling a concept, or help assess interface requirements between two or more BRIDG-harmonized models or system. The BRIDG User’s Guide published with each release of BRIDG includes a table of mapping tag names and the harmonized project’s full name.
Map:ProjNamevX.X For Example: Map:SDTM IGv3.2
…where “Map:” is the standard prefix or boilerplate, “ProjName” is a shorthand, acronym or abbreviation of the project or model name, and “vX.X” is an indication of the version or release number. The mapping tag values are the names of the project’s data elements. The mapping tags thus trace the provenance of each concept in the model and can greatly help in impact analysis when remodeling a concept, or help assess interface requirements between two or more BRIDG-harmonized models or system. The BRIDG User’s Guide published with each release of BRIDG includes a table of mapping tag names and the harmonized project’s full name.
The BRIDG model is intended to be a conceptual model for clinical research. You can leverage it to further build out detailed logical models and physical designs. It is a robust UML class diagram and can be used to design down-stream artifacts. See "How BRIDG can be used".
The BRIDG Model has 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 has historically also been a package containing state transition diagrams. These packages were available in the UML model, but not in the HTML version. However, over the last several years, no new instance diagrams have been added nor have existing ones been updated, so the BRIDG modeling team members decided to drop the instance diagram package from the BRIDG 5.3.1 model. The package will remain available in UML version of all previous BRIDG releases.