Skip to end of metadata
Go to start of metadata

NOTE: This page has been replaced by the official FHIR Implementation Guide page:  http://build.fhir.org/ig/HL7/cdisc-lab/index.html


Scope

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.

Gaps

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.

LAB Gaps:

  • 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:

  1. ResearchStudy: includes status and investigator information
  2. 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
  3. DiagnosticReport: helpful for understanding groups of tests performed (battery of tests)
  4. Encounter: provides the visit date, which is preferred over inferring visit and specimen collection dates from observation date
  5. Specimen: provides the context around the collection and quality of the specimen
  6. 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:
    1. All lab data for Study
    2. All lab data for a Research Subject participating in a Study
    3. 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).

Vocabulary Bindings

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:

  1. Required, a FHIR to CDISC translation is provided
  2. Extensible, and CDISC controlled vocabulary has terms that are not in the FHIR value set, use the CDISC controlled vocabulary
  3. Preferred, use the CDISC controlled vocabulary 
  4. Example, use the CDISC controlled vocabulary

The following LB Domain variables require translations or CDISC bindings:

Use Cases

The specification describes two use cases:

  1. Sponsor converts FHIR JSON/XML file to CDISC LAB XML standard for consumption by Sponsor systems
  2. 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.

http://github.com/jennindg/MDIT_FHIR_LDM/tree/connectathon2018/

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.










  • No labels

7 Comments

  1. From Phil Pochon, CDISC Lab Team:

    1. In general it is a good mapping, and with some FHIR extension, can be made to work.
    2. As a transmission model, the lack of a Good Transmission Practice (GTP) layer probably is not a problem, since that information is now usually carried in the message wrapper. However, the IG should state this
    3. As a transmission model, its inability to specify if the data included is cumulative or incremental needs to be covered. If local labs are a main target, the sponsor has too many labs to leave it to the parties to decide.
    4. As a transmission model (not an issue with SDTM) It is weak on multiple patient identifiers, esp. how you transition from Screening toEnrollment/Randomization ID
    5. The lack of a mapping for Subject Age At Collection is a major problem for European data, where DOB cannot be collected.
    6. The inability to separate protocol from non-protocol add tests is a minor, but real issue
    7. As  a transmission model, it is not clear if it can send multiple test identifiers. The CDISC transmission model allows for this, so you can have a standard (CDISC, LOINC, etc), and the local lab’s identifier together. Very useful if there is a data issue to be discussed/researched, or instrument upgrades are involved during the study
    8. Not really clear how they are going to send multiple (SI and Conventional, or Original/Standardized) result values and keep them straight
    1. For item #2, we noted this in the gaps section

    2. For item #3, this is contained within the DTS and agreed upon by both Sponsor and transmitter.

    3. For item #4, FHIR is capable of transmitting multiple IDs for a participant/subject.  These can be distinguished by their 'type'.  This would be handled by using separate SDTM variables and using identifier 'types' within FHIR.  Which identifier(s) are supplied to uniquely identify a participant/subject needs to be agreed upon by the Sponsor and transmitter. 

    4. For #7, yes you can have multiple test identifiers.  This is part of the FHIR model.

    5. For #5, we need to discuss with HL7.  We may be able to have the year, rather than full birth date. NOTE: This is an issue for pediatric trials. 

    6. For #6, we need a clearer use case.  When pulling tests from FHIR, the normal use case would include the study tests.  Non-study test data would be handled via a special request (e.g., need additional results due to AE investigation).