BRIDG and FHIR discussion Smita Hastak Wendy Ver
BRIDG and FHIR discussion Smita Hastak Wendy Ver Hoef June 23 rd, 2020 HL 7 BR&R WG call
Agenda • Objective of the presentation • What is an Information Model? • BRIDG Model Implementation Approaches – Semantic Hub – Data Exchange Format • BRIDG to HL 7 FHIR mapping • BRIDG & FHIR in BR&R • Other BRIDG Topics for future discussion 2
Objective of the presentation • To highlight all the mappings of BRIDG model • To discuss the BRIDG to FHIR mappings – Use cases, findings, etc. • To discuss how to leverage BRIDG in context of FHIR 3
BRIDG Overview • BRIDG - Biomedical Research Integrated Domain Group – It is an information model or a domain analysis model – Referred to as “BRIDG Model” • A collaborative effort to represent the semantics of clinical and translational research • The stakeholders of BRIDG are CDISC, FDA, HL 7, ISO and NCI • Goal: To produce a shared view of the semantics of basic, preclinical, clinical and translational research and their associated regulatory artifacts (collectively called translational research). 4
What is an Information Model? • A visual representation that organizes data elements and standardizes how these data elements are related to each other. – Data elements are properties about entities – e. g. , Person name, DOB, Street address, Study Phase, Study Title, etc. – Depending on the tooling used to represent the model, these can also be converted to a machine readable representation. • Data models represent discrete facts about entities and their relationships to each other- people, places, things, activities and relationships • They are built to represent the data needs/requirements of a domain of interest – Clinical Trials, Imaging, Genomics, Specimen, etc. • Various types of data models – Conceptual, Logical, Physical Ian comment: It is also a machine readable representation. Hugh comment: ideally we do want the dynamic structures to support the static data elements, as needed 5
Why do you need an Information Model? • Since models represents the data needs of the domain of interest, they provide a common reference and standardization of the business data – Provides common framework for all business stakeholders • Standardization of these data elements provide the consistent semantics (meaning), structure and format (data type) to support the data needs – Definitions, text/numeric, multiplicity, business rules, etc. – Some terminology binding is needed at times to support the structure of the model - typically referred to as structural codes. Does not include domain specific terminology binding. • Process of analyzing the business data needs allows for identification of common data elements, their relationships and consistent representation – Reduces ambiguity, removes overlapping semantics, etc. 6
Types of Data Models • Conceptual – Abstract model that identifies and defines the key high level concepts of the business and their inter-relationships • Logical – Derived from the Conceptual model – fleshes out the details of each business concepts by developing the attributes/data elements, data format, multiplicity, etc. • Physical – Derived from the Logical model for developing a relational database design, APIs, data exchange specifications, etc. 7
BRIDG Model Implementation Approaches 8
BRIDG Implementation Approaches • Reference Model • Source for clinical research data semantics & foundation model • Data Integration/Mapping Solutions • One mapping to a standard rather than multiple point to point mappings • Exchange Format • Subsets of BRIDG classes represented in XSD/XML • Subset of BRIDG semantics represented in FHIR/Profiles • Physical Database • Create logical and physical database models in support of clinical research software solutions – NMDP, Thomas Jefferson University, Large CRO, FDA, etc. • Ontology • To develop clinical research ontology 9
Standards & Projects Mapped to BRIDG • Harmonization of new semantics from stakeholder projects – Bottom up modeling approach • Many project semantics mapped to BRIDG – Some represented as BRIDG Views • Some examples of project semantics that are mapped to BRIDG: – CDISC • CDISC SDTM IG v 3. 1. 2, v 3. 1. 3, and v 3. 2 • CDISC Lab v 1. 0. 1 • CDISC PGx IG r 1. 0 • CDISC CDASH v 1. 1 • CDISC TDM – Other standards • Clinical. Trials. gov (trial registration) • CDMH – FDA’s Common Data Model Harmonization • • • 10 – OMOP, PCORNet, etc. SEER – NCI Surveillance, Epidemiology & End Results NBIA – National Biomedical Imaging Archive APSR – IHE’s Anatomic Pathology Structured Report DICOM – SR TID 1500, Suppl 121 etc.
BRIDG as “Hub & Spoke” – Data Integration Approach -- “Connector to Healthcare Standards” CT. gov APSR SEER AIM DICOM BRIDG Model CDISC SDTM NBIA HL 7 OMOP PCOR net 11 GDCClinical FHIR BRIDG Mappings: Each of the outer “spokes” have been mapped to BRIDG Green – Standards Blue – healthcare projects/ models…. many others not listed here Note: Each source model to BRIDG mapping is bound to specific versions of both Models. See previous slide for version numbers and details
Why consider BRIDG as a “Semantic Hub”? • Supported by CDISC, FDA, HL 7, NCI, ISO – ISO, CDISC and HL 7 Standard • Mapped to many different research models and standards – Take advantage of the mappings, etc. – – – • Conceptual meaning of classes and attributes of BRIDG are annotated and registered in ca. DSR using NCIt standard terminology concepts – • NCIt: • • Source of truth for CDISC terminology Source of truth for FDA terminology Linked to UMLS CUIs Preferred terminology for NCI Not bound to any coding system – • CDISC SDTM, SEER, DICOM (partial), CIBMTR/NMDP, CT. gov, NBIA, AIM, CDMH (PCORNet, Sentinel, OMOP, ACT/I 2 B 2) Allows for cross walking between the mapped semantics Removes the need for point-to-point mappings Allows us to link together fields in different systems that are semantically the same but coded differently Provided the semantic foundation for the HHS cross-agency project – CDMH (NCI, FDA, NCATS, NLM, ONC) Credit: few bullets from Denise Warzel 12
BRIDG Model & HL 7 FHIR FDA/NIH U 01 Grant 13
BRIDG to FHIR Mapping Background • The BRIDG to FHIR mapping was one of the Aims of the FDA/NIH BRIDG Architectural Review Grant (U 01 FD 005846) awarded to Samvit Solutions. – Boris Brodsky was the FDA lead – BRIDG Model 5. 1 was mapped to HL 7 FHIR 3. 0. 1 – These mappings are not in the BRIDG Model as yet • Objective of the Mapping: Assess feasibility of representing BRIDG semantics as FHIR resources • Rationale for Mapping: – FHIR resources could provide a standards-based implementation of BRIDG semantics – FHIR resources could also enhance the usability of BRIDG since resources are smaller and more easily consumed 14
BRIDG to FHIR Mapping Scope In Scope: • BRIDG 5. 1 mapping to FHIR STU 3. 0. 1 • All BRIDG classes and attributes • Semantics are categorized according to use cases (see next slides) Out of Scope: • Semantics that are marked as deprecated • Relationships, cardinalities, data types, inherited attributes • Rationale: keep the focus on the foundational use cases and not get bogged down in the granular details. 15
Mapping Process • Since BRIDG semantics are based on a large set of very specific implementation use cases, it was challenging to figure out how to approach the mapping to FHIR without the context of use cases • Reviewed all BRIDG use cases (over the years) that have been harmonized into BRIDG • Identified a set of 13 major use cases that brought in the larger set of semantics • Used these 13 to provide a context to the mapping effort • Reviewed every class and attribute (from 13 use case perspective) and looked for an equivalent element in FHIR – At times, complex analysis was required to align the framework of BRIDG and FHIR, • e. g. , BRIDG Activity pillars as FHIR workflow patterns • Validated this with FHIR experts 16
BRIDG Harmonized Projects and Use Cases Use Case Project(s) Harmonized into BRIDG that support the use case 1. Submit Study Data to the US FDA CDISC -- PGx v 1. 0, PGxv 1. 0, RPS 1, SDTM IGv 3. 1. 2, SDTM IGv 3. 1. 3; CTRv 1. 0, FDA HL 7 SD SD DSTU 2012 2. Submit Trial Registration to international registries CT. GOV, CTRPv 1. 0, CTRPv 3. 8, CTRRr 3, CTRRv 3, WHO, CTR&Rr 2 3. Submit Oncology data to SEER Registry SEER 2015 4. Register a participant on a clinical trial C 3 PR, C 3 PRv 2. 9 (Participant Registration) 5. Report Drug and Device related Adverse Events to FDA AE, ca. AERSv 2. 2, ICSRr 2 6. Share structured Protocol and Case Report Form meta-data NCI CRF Standard 7. Submit Subject Lab Data to CRO and/or Sponsor Lab, Lab. Viewer 2. 2 8. Schedule a subject visit at a hospital as per the Study calendar PSC, PSCv 2. 6 (Study Calendar) 9. Study Setup and Management Vendor project 10. Study Site Network Management Coop. Grp, Vendor project 11. Share Protocol and Study data among Trial Stakeholders HL 7 SD, HL 7 SP, HSDBv 1. 0, CDISC - TDM, TDMv 2 12. Submission of study data for HCT trials from trial sites to a central repository HCTv 1. 0 13. Post-marketing Surveillance CDMHv 1. 0 17
Some Mapping Summary Reflections • Abstract vs Specific – Both BRIDG and FHIR have some abstract elements • • BRIDG abstraction is in the Activity classes (right hand side of the model) (e. g. , Performed. Activity class) FHIR abstraction is in the definition and request workflow pattern resources (e. g. , Plan. Definition resource) – Both BRIDG and FHIR have some specific elements • • BRIDG is more specific in the entity-related classes on the left side of the model (e. g. , Study. Subject) and in some Activity classes (e. g. , Performed. Substance. Administration) FHIR is more specific in entity-related resources (e. g. , Research. Subject), as is BRIDG, and also in the event workflow pattern resources (e. g. , Medication. Administration) • There is no 1: 1 between a BRIDG class and a FHIR resource definition, – In fact, many BRIDG class semantics mapped to elements of FHIR resources • FHIR resource definitions are not always well described. BRIDG model is very much about the nuances of a concept and its relationship to other concepts. Therefore not having good definitions for FHIR elements made it harder during mapping. – This level of documentation appears to be dependent on the WG or the resource owners. Had to make assumptions on what something was intended to mean. • Due to low maturity of many of the resources, the definitions appeared to be work in progress and not fully fleshed out. Made it challenging without the opportunity to ask questions to the all the resource owners. – Keep in mind this was 2018 – many of resources have evolved and have higher level of maturity now. 18
List of FHIR 3. 0. 1 Resources to Which BRIDG 5. 1 Mapped 1. Activity. Definition 2. Adverse. Event 3. Any Event pattern resource such as Communication, Encounter, Procedure 4. Any Request pattern resource such as Medication. Request, Procedure. Request, Device. Request 5. Body. Site 6. Care. Plan 7. Communication 8. Communication. Request 9. Condition 10. Coverage 11. Device 12. Device. Component 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Device. Request Device. Use. Statement Diagnostic. Report Document. Reference Encounter Group Imaging. Study Immunization Location Medication. Administration Medication. Dispense Medication. Request Naming. System Notification Observation (Vital. Signs profile) 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Organization Patient Person Plan. Definition Practitioner. Role Procedure. Request Related. Person Request. Group Research. Study Research. Subject Specimen Substance Supply. Delivery Task Note: This has likely changed since many new resources have been identified now 19
BRIDG and HL 7 FHIR • BRIDG Model and HL 7 FHIR Resources are two very different kind of artifacts – Each with a specific objective • BRIDG: Conceptual model representing the semantics and relationships in clinical research • FHIR: Implementation solution that defines what and how data is exchanged (the what can be informed by BRIDG) – Each with a different usage • BRIDG: To represent the entire domain of clinical research and connect all the data points and use cases across the domain • FHIR: Data exchange mechanism specific to one or more use cases of a given domain – Peter/Catherine – the Igs and Profiles 20
BRIDG and FHIR usage in BR&R • BRIDG can inform FHIR semantics for clinical research – Since much of the clinical research use cases have been modeled in BRIDG, BR&R can leverage it to inform extending FHIR resources to support clinical research use cases. Inform the design of research profiles. • BRIDG model has detail definitions for the concepts with relationship between the concepts – Can be leveraged to provide requirements to relevant FHIR resources – with definitions and referencing to other FHIR resources • BRIDG to FHIR mapping as a starter set – Can leverage the BRIDG to FHIR draft mapping as starter to build out BRIDG views (subset of BRIDG) that scope a required implementation use case (if that FHIR use case exist in BRIDG) • Once BRIDG to FHIR mapping is updated, validated and FHIR mappings are added as BRIDG tags… – Can run reports to show the cross model alignments – Maybe add the validated BRIDG mappings to FHIR specifications 21
Discussion • Could we use BRIDG semantics to inform – Existing FHIR resources and build out the clinical research context? • In BR&R and/or in other WGs – E. g. , in BRIDG, a Research. Subject can be any of the following: • Person, Animal, Drug, Specimen, Device • At present, Research. Subject FHIR resource only references Patient resource. – Inform the design of research-oriented Profiles on existing resources 22
Other BRIDG discussions for future • BRIDG Website – Views – BRIDG – FHIR draft mappings • BRIDG data types – Should we consider moving away from HL 7 ADT? • Simple data types or FHIR data types? • BRIDG model granularity – Should we consider removing the abstract nature of BRIDG and make it more of a logical layer? 23
Thank You! • Contacts – Smita Hastak • hastaks@mail. nih. gov – Wendy Ver Hoef • verhoefw@mail. nih. gov 24
- Slides: 24