DSTU2 Ballot Source

This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). 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.

2.15.7.1.0 US Laboratory Order Implementation

The US Laboratory Order Implementation (USLabOrder) 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 Ordering in the US Realm ambulatory care setting (USLabOrder)- This use case is based upon existing regulatory requirements for Laboratories and Electronic Health Record Systems (EHR-S) for ordering clinical laboratory tests. The content has been modeled after the joint HL7 and The Standards and Interoperability (S&I) Framework Laboratory Orders Interface (LOI) Initiative and the HL7 Lab Order Conceptual Specification . However, much of the content is likely to be useable outside the ambulatory space and in other jurisdictions.

2.15.7.1.0.0.1 USLabOrder 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 CLIA and Glossary of laboratory terms defined for this implementation

2.15.7.1.0.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. Should the specimen work flow be in scope and if so how does it fit into the lab ordering implementation ( e.g. Does the DiagnosticOrder.status code valueset need to be expanded to include 'specimen received'?)
  4. Are there any operations that USLabOrder should consider ( see below )?
  5. What are reasonable conformance expectations including the concept of must support for profiles ( see conformance section below)?
  6. Comments regarding organization and design of the implementation?

2.15.7.1.0.2 Specification

The USLabOrder 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 USLabOrder is using a FHIR Bundle Resource to exchange a DiagnosticOrder Profile and the Resource Profiles it references. This FHIR bundle completely defines the laboratory order. 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 DiagnosticOrder constrains and extends DiagnosticOrder which is used to define the laboratory order. This Resources references the following profiles:
    • USlabPatient constrains and extends Patient which is used the subject of the order. .
    • USlabPHPatient constrains and extends Patient which is used the subject of the order for use cases where additional patient information is needed, such as for tests that may be reportable to public health and when the orderer instructs the laboratory to send copy of the results to the patient.
    • USlabPractitioner constrains and extends Practitioner which is used to define the provider who ordered the lab test(s) or a non-ordering provider to whom the orderer instructs the laboratory to send the results.
    • USlabPHPractitioner constrains and extends Practitioner which is defined for use cases where additional provider information is needed, such as for tests that may be reportable to public health. This Resource references the following profile:
    • USLabObsCode | USLabObsQuantity | USLabObsOther | USLabObsRatio | USLabObsPanel constrains and extends Observation which are used to support the various result types for record supporting information or other clinically relevant observations such as previous lab results and ask at order questions (AOE). These Resources reference the following profile:
    • USlabReasonForStudy constrains and extends Condition which is used to record reasons for performing the requested test.
    • USlabCond constrains and extends Condition which is used to provide other clinically relevant information to the laboratorian or pathologist.
    • USlabSpec constrains and extends Specimen which is used to define what, when, and how the specimen was collected.
    • USLabCCTarget constrains and extends Organization which is used to define a third party organization to which the orderer instructs the laboratory to send the results.

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