NOTE: This page has been replaced by the official FHIR Implementation Guide page: http://build.fhir.org/ig/HL7/cdisc-lab/index.html
Laboratory data play a key role in enabling sponsors and sites to monitor the safety and efficacy of treatment drugs administered to patients within a clinical trial. Historically, lab specimens were collected and/or processed by a central laboratory. To streamline this process and provide convenience to patients, many sites are offering laboratory services on-premises (aka local labs) for collection and processing of biological specimens.
The use of local labs, where each lab may have distinct processes and data collection systems, introduces the need for a standardized structure for the exchange of laboratory data. Without standard guidance to utilize in data transfer, data are inconsistently exchanged, in a variety of formats, increasing the burden on both the site and the research sponsor. This may increase cost, complexity, and time lines for clinical trials. FHIR provides an effective standard for sites and sponsors to utilize in exchanging clinical research laboratory data. The end-to-end process includes site data storage, site data preparation/transformation, production of FHIR format files, transformation from FHIR to CDISC laboratory data standards, and consumption of data by sponsor systems. The diagram below illustrates this process at a high level.
This implementation guide focuses on mapping laboratory data from FHIR to CDISC (#4 below).
This domain implementation guide is based upon the FHIR R4 standard (http://www.hl7.org/fhir/directory.cfml) and includes the following:
- Narrative, Domain Model, and Mappings
- Current and Target State
- Assumptions and Constraints
- Vocabulary Bindings
- Use Cases
The following items are out-of-scope for this implementation guide:
- Mapping individual laboratory test codes between coding systems (e.g., internal codes to LOINC)
- Site data preparation and transformation, which is relevant to clinical research as a whole (broader than laboratory data). Examples include:
- Setting up the site FHIR server
- Defining credentials and security for accessing data from a site FHIR server
- Providing instructions for FHIR server permissions
- Implementation of patient data protection by the site
Narrative, Domain Model, and Mappings
A narrative, FHIR resource domain model, and FHIR to CDISC data mappings are provided to assist in transforming laboratory data in FHIR format to a CDISC-compliant structures and standards.
Clinical Research Laboratory Data Narrative
Narratives, also known as scenarios, provide insight and context around the domain being discussed. By walking the reader through a fictitious example, the narrative highlights concepts important for the mapping and modeling work, and provides details for the creation of the test data set.
Clinical Research Laboratory Domain Model
The domain model provides a graphic representation of the relevant FHIR resources, attributes, and associations.
FHIR to CDISC Laboratory Data Mapping
The FHIR to CDISC mapping is useful for understanding how to relate FHIR resources and attributes to CDISC-compliant data structures and standards. To ensure a more comprehensive solution, FHIR resources are compared (mapped) to three existing CDISC standards that are used in clinical research laboratory data exchange: the CDISC LAB model, CDASH LB Domain variables, and SDTM LB variables.
Some attributes or variables within the CDISC standards do not have corresponding attributes within a FHIR resource. In some circumstances, data are provided through an alternative method, such as a supplemental file or transmission agreement. Below are the identified gaps. Please see the data mapping document for mitigation suggestions.
- Good Transmission Practice (GTP) fields for Model Version, Creation Date/Time, Transaction Type, Transmission Source ID, and Transmission Source Name (obtain from alternative method)
- Result Class (see below)
- Study Test Type (see below)
- Visit Name (see below)
CDASH LB Variable Gaps:
- VISIT (see Encounter Name, below)
- LBCOND (could obtain from Case Report Form or specimen entries)
SDTM LB Variable Gaps:
- VISIT (see Encounter Name, below)
The following items were out-of-scope for FHIR R4, but are being discussed for a future release:
- Observation: Result Class (for FHIR to LAB translation; tells what type of result the site is providing). This is awaiting Orders and Observations prioritization
- Observation: Study Test Type (values are: Study, non-Study). This is awaiting Orders and Observations prioritization.
- Encounter: Encounter Name (visit name). Patient Administration will consider an extension to the resource in a future release.
Current vs. Target State
Two core FHIR resources were modified and extended to support CDISC lab clinical research standards.
R4 resource additions include:
- Specimen: Specimen.collection CollectedPeriod, for specimens collected over a period of time (e.g., 24 hours)
- Specimen: Specimen.collection.fastingStatus, captures whether the subject has fasted prior to specimen collection
- Specimen: Specimen.condition, captures environmental or quality information about the specimen
- Specimen: Specimen.note extended to Organizations, supports laboratory comments that are not attributed to a specific person (e.g., produced by the instruments)
- Observation: Observation.interpretation cardinality modified to allow multiple interpretations
R4 Extensions and Profiles:
- Observation: Observation to ResearchStudy linkage (event-researchStudy), associated lab results with a particular study
- Specimen: Cqf-relativeDateTime, captures the collection relative to an event, such as administration of medication
If clinical research and/or R4 resources have not been implemented in site systems, sites may by inclined to rely on prior versions of FHIR resources used in Patient Care (Observation and Patient) as a short-term solution for sharing laboratory data with sponsors. Although this allows sites to share data through their current FHIR resources, limitations and risks should be considered.
The short-term solution excludes several resources and extensions which are useful for lab data:
- ResearchStudy: includes status and investigator information
- ResearchSubject: preferred over Patient because it masks the PII that the Patient resource may expose and enables a Sponsor to recreate the history of patient statuses/milestones
- DiagnosticReport: helpful for understanding groups of tests performed (battery of tests)
- Encounter: provides the visit date, which is preferred over inferring visit and specimen collection dates from observation date
- Specimen: provides the context around the collection and quality of the specimen
- Linkage between Observation and Study: useful in identifying results that have been collected for the research study, but support the study
Risks of using the short-term solution:
- The short-term solution does not facilitate easy retrieval and use of the data. Required fields, such as the study identifier or subject identifier would require additional effort to provide and maintain with the data set.
- Use of the Patient resource, rather than Research Subject, may result in unintentional disclosure of PII or complexity in managing patient and/or subject identifiers.
- Use of the observation date (date on which the lab result was generated), rather than the specimen collection or encounter dates, could result in date being associated with the incorrect patient visit if results are not generated on the collection date.
- Without study information associated with the observations, the sponsor would need to ensure that a study identifier is associated with the FHIR data files.
Implementation of short-term:
Without the associations between a Research Subject, Patient, and Observation, implementers may seek alternative ways of representing these linkages. One method is to use observation.subject to provide Research Subject and Research Study identifiers, rather than pointing to the Patient resource. If observation.subject contains an identifier that is not an identifier for one of the reference resource types (Patient, Group, Device, or Location), use an identifier type to indicate the context of the identifier. For example, if observation.subject contains the Research Subject identifier, set the identifier type to 'Research Subject ID.' Please note that this is not a desired long-term solution as it requires additional interpretation by the data consumer and is not compliant with the Observation FHIR resource definition.
Assumptions and Constraints
- Site should be able to provide study laboratory results via FHIR for the following queries:
- All lab data for Study
- All lab data for a Research Subject participating in a Study
- Lab data produced within a time frame, for Study
- The starting point for the lab implementation guide instructions is the file of laboratory data in FHIR format
- Observation.category.code should be set to 'laboratory' to assist in separating laboratory results from other observations
- NOTE: Personally identifiable information, such as race, patient initials, and birth date are included in the LAB XML standard and mapping, but should not be provided to sponsor companies without sufficient justification (e.g., required to perform patient reconciliation).
CDISC LB Domain Variable bindings are provided for situations where the site has agreed to provide CDASH or SDTM compliant content via FHIR, but the FHIR value set does not match CDISC controlled vocabulary.
If the FHIR value set binding strength is:
- Required, a FHIR to CDISC translation is provided
- Extensible, and CDISC controlled vocabulary has terms that are not in the FHIR value set, use the CDISC controlled vocabulary
- Preferred, use the CDISC controlled vocabulary
- Example, use the CDISC controlled vocabulary
The following LB Domain variables require translations or CDISC bindings:
- Specimen Condition (CDASH variable LBSPCCND) is an extensible value set and does not contain all values for the CDISC controlled vocabulary set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C78733 for specimen condition terminology.
- Specimen Type (CDASH and SDTM variable LBSPEC) is an example value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C78734 for specimen type terminology.
- Body Position during Specimen Collection (SDTM variable LBPOS) does not have a binding to a value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C71148 for body position terminology.
- Observation Code (SDTM variable LBTESTCD) is an example value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C65047 for lab test code terminology.
- Observation Code (SDTM variable LBTEST) is an example value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C67154 for lab test code terminology.
- Observation Interpretation (SDTM variable LBNRIND) is an extensible value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C78736 for reference range indicator terminology.
- Observation Units (SDTM variable LBORRESU) does not have binding to a value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C71620 for unit of measure terminology.
- Observation Method (SDTM variable LBMETHOD) is an example value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C85492 for method terminology.
- Specimen Anatomical Location (SDTM variable LBLOC) is an example value set. Bind to https://ncit.nci.nih.gov/ncitbrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&ns=ncit&code=C74456 for location terminology.
The specification describes two use cases:
- Sponsor converts FHIR JSON/XML file to CDISC LAB XML standard for consumption by Sponsor systems
- Sponsor converts FHIR JSON/XML file to CDISC CDASH or SDTM standard for consumption by Sponsor systems
Use Case 1: FHIR to CDISC LAB XML
For the September 2018 Connectathon, transformation code was written to query a sandbox FHIR server and convert the resulting FHIR file into the CDISC LAB XML standard format. The code is written in Java and is available in github. The FHIR to CDISC data mapping contains the path information that was used in the Java code.
Use Case 2: FHIR to CDISC CDASH or SDTM
Since implementations of CDASH and SDTM data stores may vary by sponsor, please see the FHIR to CDISC data mapping document for field level equivalencies to use in processing FHIR lab data files.
Sample Test Data
A sample data set has been developed to provide example data for testing. The sample data set is based upon the laboratory data narrative.