1.0 Introduction

1.1 Overview

The purpose of this document is to describe the specification for a constrained Health Level Seven (HL7) Version 2.5.1 ORU Unsolicited Observation Message (Event R01). The goals supported by this Component specification are stated in the AHIC Electronic Health Record (EHR) and Biosurveillance Use Cases:

Transmission of complete, preliminary, final and updated laboratory results to the EHR system (local or remote) of the ordering clinician

Transmission of complete, preliminary, final and updated (or notification of) laboratory results to the EHR system (local or remote) or other clinical data system of designated providers of care (with respect to a specific patient)

Transmission of laboratory result data from electronically enabled healthcare delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time

The Use Cases note that there are obstacles to achieving the stated goals. In particular, the following obstacle is delineated:

Lack of harmonization among data interoperability standards including vocabulary, laboratory and other messaging standards

This Lab Result Message Component is the result of a considered assessment of the current practices in electronic laboratory results reporting and the requirements of the Use Case. Following the EHR Use Case as used by HITSP in consultation with the Department of Health and Human Services (HHS), the Office of the National Coordinator (ONC) and the American Health Information Community (AHIC), this scope includes laboratory results and interpretations from ambulatory, inpatient and other care settings. In order to encourage rapid and widespread adoption of this Component, HITSP placed emphasis on the message content in current implementations and the ease with which current implementations can become compliant. HL7 Version 2.x message-based laboratory result reporting is the most common electronic interface in existence today and HITSP did not want to invalidate those interfaces.

1.2 Copyright Permissions

2009 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSIs copyright is clearly noted.

1.3 Reference Documents

This section provides a list of key reference documents and background material.

A list of key reference documents and background material is provided in the table below. These documents can be retrieved from www.hitsp.org.

Table 1-1 Reference Documents

Reference Document	Document Description
HITSP Acronyms List	Lists and defines the acronyms used in this document
HITSP Glossary	Provides definitions for relevant terms used by HITSP documents
TN900 - Security and Privacy	TN900 is a reference document that provides the overall context for use of the HITSP Security and Privacy constructs

1.4 Conformance

This section describes the conformance criteria, which are objective statements of requirements that can be used to determine if a specific behavior, function, interface, or code set has been implemented correctly.

As this Component is based upon an HL7 message standard, the provided tools available for conformance checking (Message Workbench) rely on HL7 interpretations of these usage indicators. HL7 V2.5.1 does not support a unique instance identifier for an OBX. Therefore, until after the HL7 implementation guide is updated to v.2.6+, this means only snapshot mode will exist in the current edition of the specification.

1.4.1 Conformance Criteria

In order to claim conformance to this construct specification, an implementation must satisfy all the requirements and mandatory statements listed in this specification, the associated HITSP Interoperability Specification, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must also implement all of the required interfaces within the scope, subset or implementation option that is selected from the associated Interoperability Specification.

Claims of conformance may only be made for the overall HITSP Interoperability Specification or Capability with which this construct is associated.

1.4.2 Conformance Scoping, Subsetting and Options

A HITSP Interoperability Specification must be implemented in its entirety for an implementation to claim conformance to the specification. HITSP may define the permissibility for actor scoping, subsetting or implementation options by which the specification may be implemented in a limited manner. Such scoping, subsetting and options may extend to associated constructs, such as this construct. This construct must implement all requirements within the selected scope, subset or options as defined in the associated Interoperability Specification to claim conformance.

	Return to detail page at www.hitsp.org	HITSP/C36
	Prev TOC Next