Represent Laboratory Results with FHIR

In the context of managing lab result data, FHIR (Fast Healthcare Interoperability Resources) offers two key resources: the Observation resource and the DiagnosticReport resource. Each plays a distinct role in representing and conveying lab results, and together they provide a comprehensive view of the lab data.

FHIR Observation

The Observation resource is used to represent the actual result of a laboratory test. It includes details such as:

• Test Results: The specific findings or measurements from the test (e.g., blood glucose levels, cholesterol levels).

• Units of Measurement: How the results are quantified (e.g., mg/dL).

• Reference Ranges: Normal value ranges for comparison.

• Observation Date and Time: When the result was recorded.

• Use: This resource focuses on the raw data from the test, providing a granular view of each result.

The DiagnosticReport resource adds additional context and information to the results presented by the Observation resource. It includes:

• Summary of Results: An aggregated view of all related observations and their interpretations.

• Clinical Interpretation: Comments or interpretations provided by the laboratory or a medical professional, which may help in understanding the results in a clinical context.

• Report Status: Indicates whether the report is final, preliminary, or in draft form.

This FHIR DiagnosticReport example below demonstrates how multiple Observation resources can be referenced within a single diagnostic report, specifically for a blood glucose test panel. It provides a structured approach to representing laboratory results using both LOINC and SNOMED CT codes.

In this example, the primary focus is on a blood glucose measurement (Observation/Obs001 exemplified above), but the report also includes other relevant tests commonly performed in diabetes assessment and metabolic health monitoring. These additional observations help provide a comprehensive clinical picture and are essential in diagnosing and managing conditions such as diabetes mellitus, insulin resistance, and cardiovascular risk factors.

Key Features of the Example

• References multiple Observation resources related to metabolic and cardiovascular health.

• Uses both LOINC and SNOMED CT codes in the code field to enhance compatibility.

• Includes SNOMED CT codes for interpretation and conclusion, making the report machine-readable and clinically relevant.

When ordering laboratory tests, FHIR provides specific resources to support this process. This page outlines the key FHIR resources involved in ordering laboratory tests, focusing on how SNOMED CT and/or LOINC can be bound to these resources to ensure standardized and accurate documentation within electronic health records (EHRs) and other clinical systems. These resources help ensure that lab test orders are transmitted, processed, and documented consistently across different healthcare systems.

The diagram below illustrates how the integration of SNOMED CT and LOINC can be utilized in laboratory test ordering and processing, using FHIR ServiceRequest to support interoperability between SNOMED CT-enabled Electronic Health Records (EHRs) and LOINC-enabled Laboratory Information Systems (LIS).

In this process, a laboratory test request is encoded using SNOMED CT within the EHR system. If needed, the corresponding LOINC code is derived using the LOINC Ontology. The request is then transmitted via FHIR ServiceRequest, containing either the SNOMED CT concept alone or both the SNOMED CT concept and its corresponding LOINC code.

On the receiving end, if only the SNOMED CT concept is provided, the LIS derives the appropriate LOINC code using the LOINC Ontology. The laboratory system then identifies and processes the request based on LOINC.

FHIR Service Request Resource

The FHIR ServiceRequest resource is used to represent a request for a service to be performed, such as laboratory tests, imaging studies, or procedures. It facilitates standardized communication between healthcare systems, ensuring that test orders and service requests are accurately transmitted and processed.

In the context of laboratory test ordering, the ServiceRequest.code element is used to specify the requested test. This field can contain either a SNOMED CT code, a LOINC code, or both, depending on how the ordering system captures and transmits test requests.

• When SNOMED CT is used, the code element holds the SNOMED CT concept representing the requested test.

• When LOINC is used, the code element contains the appropriate LOINC code that corresponds to the requested laboratory test.

• In cases where both SNOMED CT and LOINC are included, SNOMED CT provides a structured clinical representation, while LOINC ensures compatibility with laboratory systems that primarily use LOINC for test identification.

By supporting both SNOMED CT and LOINC within the ServiceRequest.code element, FHIR enables flexible and interoperable test ordering workflows, ensuring accurate and efficient exchange of laboratory test requests across healthcare systems.

More information on the FHIR Service Request Resource can be found here:

Below is an example of a FHIR ServiceRequest resource that uses both the SNOMED CT concept and the associated LOINC code 51459-6 for a request to measure the arbitrary concentration of antibodies to hepatitis E virus in serum:

• status: Set to “active,” indicating that the request is currently in progress.

• intent: “order” reflects that this is a formal request.

• code:

By leveraging the LOINC Ontology, it is possible to automatically derive the corresponding LOINC code for the SNOMED CT concept 72641010000107 |Arbitrary concentration of antibody to hepatitis E virus in serum at point in time (observable entity)|, see image below. The corresponding LOINC code is 51459-6, which represents the same clinical concept in the LOINC terminology system.

What is FHIR?

HL7 FHIR is a modern standard designed to facilitate the exchange of healthcare information electronically.

• Consistency: With standardized resources and robust semantics, FHIR ensures uniformity in healthcare data representation. This consistency supports accurate data exchange and enables healthcare providers to make informed decisions based on reliable information, ultimately enhancing patient care quality.

• Modularity: FHIR’s flexible architecture allows its resources to be used independently or in combination to meet specific healthcare needs. This modular approach supports adaptability across diverse healthcare contexts, enabling tailored solutions without overhauling entire systems.

• Interoperability: FHIR facilitates seamless data exchange between different healthcare systems and applications, enhancing communication and collaboration among healthcare providers. By standardizing data formats and protocols such as RESTful APIs and JSON/XML, FHIR promotes interoperability, improving patient care coordination and information sharing.

• Standardization: FHIR leverages contemporary web standards to ensure compatibility with existing IT infrastructures. By defining well-structured resources like Patient, Observation, and Medication with clear semantics, FHIR fosters consistency in how healthcare data is represented and interpreted across various systems.

• Scalability: Designed to accommodate evolving healthcare requirements and technological advancements, FHIR is scalable for both current and future healthcare needs. Its flexible architecture and support for extensibility allow healthcare systems to grow and adapt without compromising interoperability or data integrity.

HL7 FHIR plays a crucial role in linking healthcare data with standard terminologies, including SNOMED CT. By integrating FHIR with terminologies like SNOMED CT, more precise and standardized documentation and communication of clinical information can be achieved. This linkage enhances interoperability by enabling seamless exchange of structured clinical data, supporting accurate clinical decision-making, and promoting continuity of care for patients across various healthcare settings.

For the purpose of representing the laboratory data workflow, we can use the following FHIR resources:

• ServiceRequest: Represents laboratory orders or requests for specific diagnostic tests or procedures.

• DiagnosticReport: Captures the overall results or findings of the laboratory tests as a summarized report.

• Observation: Provides detailed data points or specific results associated with the laboratory tests.

Examples:

The image below illustrates how FHIR resources can be used to represent the generalized logical model for laboratory data. It outlines the relationships between key FHIR resources (highlighted in red) and logical model entities (depicted in gray), offering a structured approach to representing laboratory orders, individual results, and specimen information.

• Laboratory Order: Mapped to the FHIR ServiceRequest resource, representing the clinical request for laboratory testing. It includes details such as test code, priority, status, and the specimen to be tested.

• Result: Mapped to the FHIR DiagnosticReport resource, summarizing the findings of the laboratory tests based on the order. The DiagnosticReport serves as a container for individual results.

• Individual Results: Represented by the FHIR Observation resource, where each Observation provides specific result details such as:

Relationships

• The FHIR ServiceRequest initiates the laboratory process and forms the basis for the FHIR DiagnosticReport.

• The FHIR DiagnosticReport includes one or more FHIR Observations, each representing an individual result.

• The FHIR Specimen resource is central to the model, linking the order, results, and observations to the biological material tested.