Health data has become an abundant and rich source of information that can be leveraged for research, for pragmatic clinical trials, for post-market research, and for supporting information for clinical trials. The Clinical Data Interchange Standards Consortium (CDISC) Real-World Data (RWD) Connect Initiative conducted a qualitative Delphi survey “to understand the barriers of implementing CDISC standards for RWD and to identify tools needed to more easily implement them.” The Fast Healthcare Interoperability Resources (FHIR) to CDISC mapping guide was a tool developed in response to this survey.¹

Health Level Seven (HL7)² provides standards for health care data, while CDISC³ provides standards for research data. Bridging these worlds creates new opportunities to expand and accelerate research by blending research and real-life patient conditions to supplement otherwise untapped data sources.⁴

HL7 provides standards for health data exchange that encompass all aspects of RWD from digital health technologies, administrative claims, registries, and electronic health records. CDISC focuses on randomized clinical trials with standards targeted to pre-clinical, data collection, data tabulation, and analysis, that provide traceable metadata from beginning to end. Bringing rich and abundant health data into the research process through streamlined data capture, and data transfer could facilitate an increase in data reuse from the point of care onward and improve research efficiency.

The aim of this work is to provide a resource to solve the problem of data redundancy. The HL7 FHIR to CDISC joint mapping implementation guide was developed to eliminate data duplication and to improve interoperability. This document reviews what the FHIR to CDISC IG resource is and what it is not.

Interoperability between research and health care solves multiple problems. One such problem is data entry redundancy. Today, data are often entered into a clinical research site’s EHR, and then reentered into the sponsor’s clinical trial system (eg, Electronic Data Capture (EDC), Metadata Repository (MDR), etc.). This duplication results in delays in data transfer and impacts data quality. Having the right person enter the right information at the right time enables data reuse, thus reducing cost and variability. The FHIR to CDISC IG provides guidance for EHRs built on FHIR Release 4 (R4)⁵ to extract data for ingestion into a sponsor’s clinical trial system.

The vision of the data workflow is displayed in Figure 2 and Figure 3. Figure 2 illustrates a FHIR-enabled EHR with clinical concepts (or resources) that could be accessed using an API for clinical research.

Figure 3 shows that while data transfer appears to be seamless, implementers will need to consider caveats, such as variations in syntax and semantics, in each EHR system and in clinical research study requirements. The mapping guide is not an explicit methodology (ie, a one-to-one concept) to get from point A to point B.

The high-level map in Figure 3 shows how RWE can be used to support regulatory application in three ways. First, through data capture in electronic health systems. Second, RWE provides an avenue for using clinical data in retrospective studies. And third, RWE gives insight into CRF creation with data elements that support FHIR resources to allow for automatic population, reduced data entry, and transcription issues. The FHIR to CDISC IG will allow implementers to leverage each standard’s strengths and to gain the benefits of each standard for a specific use case.^{28, 29}

A gap analysis was performed to assess the possibility and feasibility of mapping from FHIR to CDISC, CDASH and SDTM. A CDISC workgroup began mapping domains in 2016, but work was halted when the team identified that numerous variables could not be populated. After noting that FHIR had matured enough that the documentation was feasible, the mapping of CDISC domains commenced.

The mappings were documented using FHIRPath, a path-based navigation and extraction language similar to Extensible Markup Language (XML) Path Language (X-Path).³⁰ X-Path uses expressions to show how to navigate the elements and attributes (the nodes) in an XML document.³¹ FHIRPath fulfills a similar need in a syntax-independent manner, and with additional terminology and other features that makes it a particularly appealing tool for use in mapping.

The CDISC domains selected for mapping were mature and common across health care data, including: Medical History (MH), Concomitant Medications (CM), Procedures (PR), Vital Signs (VS), Laboratory Test Results (LB), Adverse Events (AE), and Demographics (DM). Figure 4 provides a view of the relevant FHIR resources and the CDISC domains. It demonstrates that there are many FHIR resources used to represent the variables in each SDTM domain. The LAB entry noted at the bottom of the CDISC domains represents the CDISC Laboratory Data Model Version 1.0.1.³² LAB is the CDISC standard model for acquiring and exchanging laboratory data. LAB was originally published as part of the Clinical Research Sponsor Laboratory Semantics in FHIR IG and was included to ensure consistency with the LB domain updates.³³

The CDASHIG v2.1 mapping examples by domain was used as the basis for the mapping; this follows the CDASH model v1.1. The CDASHIG v2.1 references the SDTMIG v3.2 which references the SDTM v1.4.

Figure 5 provides a view of how patient FHIR resource data could flow from an EHR to CDASH, and then to SDTM. If the study did not require viewing the data in CDASH then the data could go directly to SDTM. During the mapping discussions, the subject matter experts emphasized the need to go to CDASH as part of the data collection and data cleaning process. The patient data within the EHR database would be queried for relevant information (such as medication, observations, encounters, or procedures) and be sent to a FHIR server via FHIR messages. The FHIR messages have resource and identity metadata, a human-readable summary, extensions that allow supplementary data capture based on a definition identified by URL, and the standardized computable data. The FHIR resource message would be transformed first to the CDASHIG variable representation (using JavaScript Object Notation (JSON) or XML), and then to SDTMIG variable representation. The flow could go from FHIR to CDASH to SDTM, or FHIR to SDTM. Others may want to leverage FHIR to Operational Data Model (ODM)-XML, which is CDISC’s exchange standard, to CDASH to SDTM.³⁴ ODM is a way to represent CDASH or SDTM in a machine-readable data exchange format. The intermediate steps can be adjusted, depending on the requirements of the study.

The team used FHIR resource definitions and examples to determine which resources matched the concepts noted in the CDASH variable labels. The mapping was done with a resource-to-domain, and a context-based, approach. The team kept the mappings at a high level due to the variability in the data elements within EHR systems and to the differences in requirements for clinical research protocols. This initial mapping provides a starting point; as health care information standardization matures, the granularity of these mappings can increase. Where gaps still exist, guidance has been provided to help with mapping the variables in each domain. Explanations are given in the “gaps” column of the guide.

During the mapping and review process, the perspective was “what can be found in electronic health data?” in the current state. For example, if a Questionnaire or Form was used, FHIR resources such as Adverse Event would be appropriate; however, most clinical trial Adverse Events would be noted as Conditions in the medical records. Mapping caveats and comments were added when the match to a CDISC variable was not straightforward or was determined to be “fuzzy”. The race and ethnicity in the Demographics domain extensions were aligned with the U.S. Core FHIR Implementation Guide; however, other extensions and specific SNOMED CT® and LOINC® codes noted in U.S. Core were not referenced. The non-U.S. audience may have different local and regional requirements, so the guide’s focus was on the base FHIR resources. The end users can supplement the base mappings with country-specific details when leveraging FHIR to CDISC mappings.

The review process was split between CDISC and HL7 and consisted of a 14-day Internal Review and a 60-day Public Review on the CDISC side and a 30-day Ballot (HL7 Community Review) on the HL7 side. Figure 6 shows the timelines and the complexities of carrying out a review through two standards development organizations simultaneously. Both organizations shared and reviewed each review comment and its resolution.

There were 363 total comments, with the bulk occurring during the CDISC Internal Review (268). The simultaneous Public Review and Ballot Review yielded 95 total comments, 37 at CDISC and 58 at HL7. The predominant theme was clarifying the mapping and adding descriptive text to the comment sections. There were numerous comments about the Medical Dictionary for Regulatory Authorities (MedDRA) terminology and how to deal with it when mapping. Additionally, there were questions about aligning with other implementation guides. Table 1 provides a breakdown of the issues, the predominant themes, and the issues by domain.

In the parallel review process, the feedback from both organizations provided perspectives from diverse stakeholders. For example, the CDISC community includes industry (pharmaceutical, medical device, biotech), contract research organizations, governmental bodies, non-profit organizations, academic researchers, and others. In contrast, the HL7 community includes health care organizations, clinicians, payors, electronic health vendors, registry stakeholders, and governmental organizations, and others.

The final deliverable was published simultaneously on both the HL7 FHIR website and the CDISC website, in multiple formats, to support the needs of the user community.

The domains provided in the mapping are meant to be a starting point. They can be adjusted as needed based on requirements, input from subject matter experts, or as a result of modeling or governance activities. On the CDISC website, there is a Real-World Data section with several resources and examples of using CDISC standards with FHIR.¹³ A notable effort in RWD is the Laboratory Test Results (LB) domain mapping to LOINC file that shows LOINC code mappings to CDISC variables and terminology.

A number of team discussions involved mapping concepts from SNOMED CT to MedDRA or LOINC to CDISC variables and terms. Both publications of the IG include examples and varying formats. The CDISC side has an Excel sheet with tabs that contain the content, while the HL7 site has links to traverse the content of the IG. In addition, the sites include links to download XLS and XML formats.

The team also discussed including mappings for two clinical research FHIR resources: ResearchSubject and ResearchStudy. These FHIR resources are still in development at HL7; however, the Patient resource has connections to both ResearchSubject and ResearchStudy.

The FHIR to CDISC Joint Mapping IG was used in the HL7 January 2022 Connectathon for the Vulcan RWD and AE tracks.³⁵ The Connectathon work identified areas of improvement for the AE domain.

The HL7 FHIR to CDISC Joint Mapping IG provides a high-level guide from one standard to another to harmonize mapping approaches across the community. The IG provides a beneficial resource that can be used with the CDISC LB to LOINC mapping guide for leveraging real-world data for clinical trials. The guide assists stakeholders in utilizing health data through the HL7 FHIR resources to CDISC, CDASH, and SDTM variables. We encourage mappers to seek experts in terminology, FHIR resources, and CDISC standards to ensure the concepts mapped “from” and “to” are accurate for their use cases. As the document is used, we encourage the community to provide comments to improve the IG in future versions. Feedback from end users is important to effectively mature this guidance.