This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Published by: HL7 Orders and Observations Workgroup

Primary Author/Editor: Eric M Haas, Health eData Inc.

A.3 US Laboratory Report Implementation

The US Laboratory Report Implementation (USLabReport) consists of the guidance documentation, profiles, operations, value sets and conformance statements it defines. This implementation has been prepared as a U.S. Realm Specification on behalf of the HL7 Orders and Observation Workgroup.

Laboratory Test Reporting in the US Realm ambulatory care setting (USLab Report) - This use case is based upon upon existing regulatory requirements for Laboratories and Electronic Health Record Systems (EHR-S) for reporting clinical laboratory results to ordering providers. The content has been modeled after the joint HL7 and The Standards and Interoperability (S&I) Framework Laboratory Results Interface (LRI) Initiative and the HL7 V3 Lab Normative Standard . However, much of the content is likely to be useable outside the ambulatory space and in other jurisdictions.

A.3.0.1 USLabReport Documentation

• Purpose- How this project came to be and what it is trying to achieve
• Use case- Describes the Scope, Assumptions, Pre and Post Conditions and Use Cases for this guide
• Key Technical Decisions- List of key technical decisions in creating this guide
• Additional Guidance-Information on Add-on and Reflex testing ( Including Culture and Sensitivities), CLIA, and Glossary of laboratory terms defined for this implementation

A.3.1 Draft for Comment Ballot

This guide will be balloted together with the FHIR specification itself as part of the second FHIR DSTU as part of the December-January ballot cycle. This will provide an opportunity to provide feedback on all aspects of the FHIR specification.

Questions for Balloters:

1. Should this implementation support all ways to exchange resources which include REST (current focus), Documents, Messaging, and Services?
2. Considering the scope and use case are there any important omissions from this implementation?
3. Are there any operations that USLabResult should consider ( see below )?
4. What are reasonable conformance expectations including the concept of must support for profiles ( see conformance section below)?
5. Comments regarding organization and design of the implementation?

A.3.2 Specification

The USLabReport is built on top of the HL7 FHIR standard. Basic aspects of the FHIR protocol, including RESTful operations, data types, search, etc. apply.

Profiles -The current focus of implementing USLabReport is using a FHIR Bundle Resource to exchange a DiagnosticReport Profile and the Resource Profiles it references. This FHIR bundle completely defines the laboratory results report. The Resource Profiles that may be used in the bundle are outlined below: (This list is not meant to be exhaustive as additional resources may also to be used)

• US Lab DiagnosticReport constrains and extends DiagnosticReport which is used to define the laboratory results report. This Resources references the following profiles:
  • USlabPatient constrains and extends Patient which is used as the subject of the report. .
  • US Lab DiagnosticOrder constrains and extends DiagnosticOrder which is used to define the laboratory order. This Resources references these USLabOrder Profiles
  • USlabSpec constrains and extends Specimen which is used to define what, when, and how the specimen was collected.
  • USLabObsCode | USLabObsQuantity | USLabObsRange | USLabObsRatio | USLabObsOther | USLabObsPanel constrains and extends Observation which are used to support the various result types for recording laboratory observations.
    • USLabPerformingLab constrains and extends Organization which is used to define a the organization that is responsible for the observation.

In addition to defining the the USLabReport bundle this implementation consists of the following components:

• Operations - Question for balloters are there any operations that USLabReport should consider?
• Conformance statements - Definitions for the expected capabilities of each of the actors involved supporting USLabReport functionality:
  • USLabReport sender conformance
  • USLabReport receiver conformance
• Value Sets - todo: link to be provided - lists the additional Value Set bindings created for the USLabOrder and USLabReport Implementations.
• Mappings - are translation of the concept codes for LRI to USLabReport - Note to balloters this is a stub entry for future work.
• Examples - Example instances of USLabReport Resources: Note to balloters these have not yet been validated by generated schema and are provided as informational only:
  • USLab DiagnosticOrder Example
  • USLab DiagnosticReport Example
  • USLab Patient Example
  • USLab PHPatient Example
  • USLab Practitioner Example
  • USLab PHPractitioner Example
  • USLab Practitioner Example
  • USLab Ordering Organization Example
  • USLab Copy to Organization Example
  • USLab Performing Lab Example
  • USLab Quantitative Observation Example
  • USLab Coded Observation Example
  • USLab Other (string) Observation Example
  • USLab Ratio Observation Example
  • USLab Quantitative Observation Example
  • USLab Condition Example
  • USLab Specimen Example