This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

?.? Purpose

The FHIR USLab Report Implementation focuses on identifying the requirements, specifications and standards, and on providing the implementation guidance for reporting of laboratory test results to ambulatory care providers in the US Realm using the FHIR in the RESTful framework. Its scope includes requirements to enable the incorporation of clinical laboratory test results into an Electronic Health Record System (EHR-S) as standardized structured data using the defined inter-organizational laboratory transaction. The Use Case requirements are directed at laboratory test results reporting between a Laboratory Information System (LIS) and an ambulatory EHR-S in different organizational entities, e.g., different corporate structure, ownership or governance. Future versions of this implementation may harmonize with existing guides to extend interoperability of laboratory results across care settings, e.g., acute care and public health.

?.? Audience

This guide is designed for use by analysts and developers who require guidance on FHIR resources, elements and specific extensions relative to the Laboratory Orders Interface (LOI) initiative and the HL7 V3 Lab Normative Standard. Users of this guide must be familiar with the details of the FHIR Specification and resource processing. This guide is not intended to be a tutorial on that subject.

?.? Conventions

This guide adheres to the following conventions:

?.? Key Technical Decisions

?.?.1 Profile And Component Architecture

This guide uses FHIR profiles on the following resource to define a minimum set of requirements to enable the successful exchange of laboratory orders:

The main objective is to ensure that EHR systems and Laboratory systems can exchange laboratory orders with minimum if any modifications from one combination to another combination of software, while maintaining flexibility to enable software developers to provide more capabilities using the same core Resource definitions.

?.?.2 Use Of Vocabulary Standards

This guide calls for specific vocabulary standards for the exchange of laboratory information such as LOINC and SNOMED. Standard vocabularies, particularly coded laboratory tests and their results, enable automated decision support for patient healthcare, as well as for public health surveillance of populations. Value Sets resource are provided as part of this implementation.

?.?.3 Snapshot Mode

FHIR only functions using snapshot mode - updates are communicated by sending a complete copy of the instance with the new data filled in. If a correction and/or status update to Obsveration Resource is necessary, the DiagnosticReport with all references to all Obsveration Resource, even if previously sent, shall be resent with the correction and/or current status and/or current values. For example, when a Complete Blood Count with manual differential is ordered, the blood count will be released and then at a later time the manual differential will be performed and released. When the blood count is released the DiagnosticReport will reference only the Observation Resources for the count as final results. When the differential is completed, the DiagnosticReport will reference all previous Observation Resources as well as the new Observation resources - in this case the blood count and the differential results. -->

?.?.4 Scope Of Implementation

Due to receiving system variations and need, this guide does not specifically indicate for each field whether to store it or not. This is left to the individual system's scope and purpose.

?.? Use Case - Ambulatory Care Setting

This use case was developed as a collaborative effort between the HHS/ONC Standards and Interoperability Framework Laboratory Results Initiative, the California Health Care Foundation, and the HL7 Orders and Observations Work Group.

?.?.1 Scope

The scope is the sending of lab results from a laboratory to an ambulatory provider.

?.?.1.1 In Scope

?.?.1.2 Out of Scope

?.? Actors

There are two actors that have responsibilities related to the conformance profiles defined in this document:

?.? Orders for Ambulatory Care Use Case and Context Diagrams

Figure 2-1. Use Case Diagram

Figure 2-1. Use Case Diagram

Figure 2-2. Context Diagram

Figure 2-2. Context Diagram

?.?.1 User Story

A Provider (orderer) may enter a laboratory order into an ambulatory EHR-S. A laboratory requisition is generated (paper or electronic) and is communicated to the laboratory. The information in the laboratory requisition is entered manually or captured electronically into the LIS. After the specimen(s) has been collected and, if necessary, shipped or delivered to the laboratory, the laboratory processes the specimen(s). If the specimen is satisfactory for testing the laboratory will perform the test. Prior to successful completion of a test, communication may also be necessary to indicate cancellation, failure to perform the test and the related reasons; for example if the specimen is either not appropriate for the ordered test, or otherwise unsatisfactory the rejection of the specimen will be communicated using USlabReport profile. Order cancellation notifications should be communicated using the USLabOrder profile. The laboratory performs or attempts to perform the test(s). If testing is successful, results are obtained and entered/released in the LIS. An authorized person at the laboratory reviews and approves the laboratory test results, or the certifying laboratory reviewer of record in the case of an auto-verification process, to be sent to the provider and any non-ordering providers requested in the laboratory order. The results are either pushed or pulled into the provider's EHR-S (results receiver). The EHR-S incorporates the results into the patient's electronic record. The provider logs into his/her EHR-S and views the laboratory results in order to inform patient care decisions.

?.?.1.1 Use Case Assumptions

?.?.1.2 Pre-Conditions

?.?.1.3 Post-Conditions

?.?.1.4 Functional Requirements

todo

?.?.1.4.1 Sequence Diagram

Figure N-N: Scenario 1 Sequence Diagram

Electronic Ordering Of New Or Scheduled
            Laboratory Test(S)

?.? Error Handling

Refer to the FHIR Specification on REST status codes and the use of the OperationOutcome Resource when further information about the transaction error is needed. Note to balloters: The error handling specifications are currently not fully defined for this implementation.

?.? Code Systems And Value Sets

Successful message implementation requires that transmitted messages (message instances) contain valid values for coded fields. For further discussion on Using codes in FHIR refer to the FHIR specification.

?.?.1 LOINC

The use of the Logical Observation Identifiers Names and Codes (LOINC) code system is required where a LOINC code is available for the Observation.name, i.e. the being resulted. Appropriate status is defined in the LOINC Manual Section 11.2 Classification of LOINC Term Status. If a local coding system is in use, a local code should also be sent in addition to the LOINC to help with identification of coding issues. When no valid LOINC exists the local code may be the only code sent.

While data storage requirements in the EHR will not be addressed in this guide, it is recommended that LOINC codes be stored in or accessible by the EHR for the following reasons:

  1. If the result is related to a reportable condition and the laboratory provides a LOINC code,
  2. Meaningful Use Stage requires the EHR to send the LOINC code to public health. If the LOINC code is the only code sent to the lab in OBX-3, then the EHR must store and retain that code to satisfy CLIA reporting requirements.
  3. LOINC codes may be used for secondary data exchange purposes and other partner exchange agreements.

?.?.2 SNOMED CT

The use of the SNOMED-CT code system is required where a SNOMED-CT concept code is available for Observation.valueCodeableConcept, i.e. the actiual coded result. If a local coding system is in use, a local code should also be sent in addition to the SNOMED-CT concept code to help with identification of coding issues. When no valid SNOMED-CT exists the local code may be the only code sent. to satisfy CLIA reporting requirements, It also recommended that the Observation.valueCodeableConcept.text element is used if laboratory's original text which is used for printing and/or display is different from the code display value.

SNOMED CT is required for specimen source term elements, Specimen.type and Specimen.Collection.sourceSite where a SNOMED-CT concept code is available.

?.?.3 UCUM

The use of the UCUM (Unified Code for Units of Measure) code system is required for reporting units of measure in Observation.quantity.

?.?.4 Value Sets

The value sets for this implementation as well as USLabOrder and USLabPHReport can be found on the USlab Implementation page. In additionm, mappings to the HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface are also available.

?.? Additional Implementation Guidance

?.?.1 Confirmatory and Reflex Testing ( Including Culture/Susceptibility Testing)

Definition: Additional laboratory testing included in the original test request by reference to specific follow-up testing, e.g. "Urinalysis w/Culture Reflex" as opposed to "Urinalysis" ordered as a standalone test. The decision to perform the reflex or confirmatory test is based upon the results of the initial test and application of a predetermined local or national practice guideline, approved protocol or legal requirement.

An example is provided here for the scenario in which a urine cultire results in the identification of the pathogens: E.coli, x and y and a susceptibilty is performed on all three pathogens. todo..

?.?.2 Add-On Testing

Definition: Additional laboratory testing is requested by an authorized provider (as defined by CLIA and state law) on an existing specimen after the original test request has been submitted to the laboratory. The decision to request additional testing is individual provider driven and based on any number of factors not limited to a test result.

?.?.3 Clinical Laboratory Improvement Amendments Considerations

In the United States, clinical laboratory testing of human specimens is regulated by the Clinical Laboratory Improvements Amendments of 1988 (CLIA). Several sections of the regulations implementing CLIA impact how electronic laboratory data is formatted for the US Realm and these are outlined in this section. Impacted areas include mandatory test request requirements. CLIA Regulation Specifics.

?.?.4 Mandatory Ordering Requirements

Section 493.1241 of the CLIA Regulations requires the laboratory to have a written or electronic request for patient testing from an authorized person, and defines items that must appear as part of a clinical laboratory test request . The laboratory may accept oral requests for laboratory tests if it solicits a written or electronic authorization within 30 days of the oral request and maintains the authorization or documentation of its efforts to obtain the authorization.

Interpretative guidelines on the elements required in a test requisition . Specific fields impacted include the following:

FHIR element CLIA Requirement.
Patient.identifier A unique patient identification number is required
Patient.name The patient's name or unique patient identifier.
Observation.name Unique identification of the test performed is required.Use of LOINC codes for additional tests is strongly encouraged. For certain tests CLIA requires additional information: Laboratories using manufacturer's instruments, kits or test systems labeled for "investigational use only" or "research use only" must clearly state that the test results are not to be used for treatment or diagnostic purposes. If results of such tests are being reported without a disclaimer statement, or are being used by the provider for patient care, they are in the same category as in-house developed tests and the laboratory must establish performance specifications in accordance with �493.1253. The disclaimer for Analyte Specific Reagents (ASR) should state, "This test was developed and its performance characteristics determined by (Laboratory Name). It has not been cleared or approved by the U.S. Food and Drug Administration." The ASR disclaimer on the test report is required by the FDA under 21 CFR, Part 809.30, "Restrictions on the sale, distribution and use of analyte -specific reagents."
Observation.value The laboratory result is required. No regulatory requirements are specified, outside of readability, regarding result appearance.
Observation.valueQuantity Units, if required, or an interpretation must be given. For tests such as genetic screens the interpretation may actually be the test result. UCUM for vocabulary use is preferred.
Observation.interpretation Units, if required, or an interpretation must be given. For tests such as genetic screens the interpretation may actually be the test result.
Observation.referenceRange When available reference range shall be valued.
DiagnosticReport.status Used to reflect CLIA required conditions such as specimen acceptability, result corrections, cancellations as well as report status (§493.1291 (c)(7) and (k)(1,2).
Observation.issued This field is used to transfer the time stamp associated with generation of the analytical result by the instrument specified in Equipment Instance Identifier.
DiagnosticReport.performer(Organization) The identification of the performing laboratory is required. Populated with the CLIA ID Number. If the CLIA ID number is not used, all demographic fieldsmust be provided with appropriate information.
Specimen.type Reporting requirements call for the specimen source, which equates at minimum to the Specimen Type
Observation.UnsatisfactorySpecimenReason (extension) To specify the reason for specimen rejection..

?.?.5 CLSI Definitions - Quantitative, Semi-quantitative, Qualitative Results

The following defnitions were derived from the CLSI website:

?.?.6 Glossary