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.4 US Laboratory Report to Public Health Implementation

The US Laboratory Report to Public Health Implementation (USLabPHReport) 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.

US Realm Laboratory Reporting to Public Health (USLabPHReport) - This use case is based upon existing regulatory requirements for laboratories to report "reportable" laboratory test results to local public health agencies. The content has been modeled after the same content as the USLabResult above and the HL7 Public Health and Emergency Care Workgroup (PHER) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting (ELR) to Public Health, Release 2 .

A.4.0.1 USLabPHResult 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 Additional Guidance and Glossary of laboratory terms defined for this implementation

A.4.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 USLabPHReport 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.4.2 Specification

The USLabPHReport 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 USLabPHReport 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:
  • USlabPHPatient constrains and extends Patient which is used the subject of the report for use cases where additional patient information is needed, such as for tests that may be reportable to public health.
  • USlabPHPractitioner constrains and extends Practitioner is used to define the laboratory contact for 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 USLabPHReport bundle this implementation consists of the following components:

• Operations - Question for balloters are there any operations that USLabPHReport should consider?
• Conformance statements - Definitions for the expected capabilities of each of the actors involved supporting USLabPHReport functionality:
  • USLabPHReport sender conformance
  • USLabPHReport receiver conformance
• Value Sets - todo: link to be provided - lists the additional Value Set bindings created for the USLabOrder, USLabReport, and USLabPHReport Implementations.
• Mappings - are translation of the concept codes for ELR to USLabPHReport - Note to balloters this is a stub entry for future work.
• Examples - Example instances of USLabPHReport 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 PHPatient Example
  • USLab PHPractitioner Example
  • USLab Ordering 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