0920-20OS HL7 Reporting Guide

V251_IG_LB_LABRPTPH_R1_INFORM_2010FEB

HL7 Version 2.5.1 Implementation Guide:
Electronic Laboratory Reporting to Public Health,
Release 1 (US Realm)
HL7 Version 2.5.1: ORU^R01
HL7 Informative Document
February, 2010
Sponsored by:
Public Health / Emergency Response Work Group

PHER Work Group Co-chair:

Rita Altamore
Washington State Department of Health

PHER Work Group Co-chair:

Alean Kirnak
American Immunization Registry Association (AIRA)

PHER Work Group Co-chair:

Joginder Madra
Gordon Point Informatics Ltd.

PHER Work Group Co-chair:

Michelle Williamson
National Center for Health Statistics/CDC

Principal Author:

Austin Kreisler
SAIC - Science Applications International Corp
Questions or comments regarding this document should be directed to Rita Altamore at
mailto:[email protected].

Copyright © 2011 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material
in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level
Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

IMPORTANT NOTES:
HL7 licenses its standards and select IP free of charge. If you did not acquire a free
license from HL7 for this document, you are not authorized to access or make any use of it.
To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.
If you are the individual that obtained the license for this HL7 Standard, specification or
other freely licensed work (in each and every instance "Specified Material"), the following
describes the permitted uses of the Material.
A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and
agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use
Specified Material to develop and sell products and services that implement, but do not directly
incorporate, the Specified Material in whole or in part without paying license fees to HL7.
INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate
additional items of Special Material in whole or part, into products and services, or to enjoy
additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must
become ORGANIZATIONAL MEMBERS of HL7.
B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are
authorized, without additional charge, on a perpetual (except as provided for in the full license
terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy
(for internal purposes only) and share this Material with your employees and consultants for study
purposes, and (b) utilize the Material for the purpose of developing, making, having made, using,
marketing, importing, offering to sell or license, and selling or licensing, and to otherwise
distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement
and any relevant patent and other intellectual property rights of third parties (which may include
members of HL7). No other license, sublicense, or other rights of any kind are granted under
this Agreement.
C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified
Material, are authorized, without additional charge, to read and use the Specified Material for
evaluating whether to implement, or in implementing, the Specified Material, and to use Specified
Material to develop and sell products and services that implement, but do not directly incorporate,
the Specified Material in whole or in part.
NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part,
into products and services, or to enjoy the additional authorizations granted to HL7
ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS
of HL7.
Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
Page 2
February 2010
© 2010 Health Level Seven International. All rights reserved.

This page intentionally left blank.

Page 3
HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.
February 2010

Table of Contents

TABLE OF CONTENTS
1. INTRODUCTION....................................................................................................................................... 1
1.1 Purpose ................................................................................................................................................................1
1.2 Audience ..............................................................................................................................................................1
1.3 Scope ...................................................................................................................................................................1
1.3.1 Other Related Profiles...................................................................................................................................2
1.3.2 Condition Reporting .....................................................................................................................................2
1.4 Conventions .........................................................................................................................................................2
1.4.1 Message Element Attributes .........................................................................................................................3
2. MESSAGING INFRASTRUCTURE .......................................................................................................... 9
2.1 Messaging Framework.........................................................................................................................................9
2.1.1 Delimiters .....................................................................................................................................................9
2.1.2 Null Values In Fields Vs. Components ....................................................................................................... 10
2.1.3 Lengths ....................................................................................................................................................... 10
2.1.4 Snapshot processing.................................................................................................................................... 11
2.2 Use Of Escape Sequences In Text Fields ........................................................................................................... 12
2.3 Data Types ......................................................................................................................................................... 13
2.3.1 CE – Coded Element .................................................................................................................................. 15
2.3.2 CNN – Composite ID Number and Name Simplified ................................................................................ 16
2.3.3 CQ – Composite Quantity with Units ......................................................................................................... 17
2.3.4 CWE – Coded with Exceptions – All Fields Except OBX-5 ...................................................................... 18
2.3.5 CWE – Coded with Exceptions – For OBX-5 Only ................................................................................... 23
2.3.6 CX – Extended Composite ID with Check Digit ........................................................................................ 27
2.3.7 DR – Date/Time Range............................................................................................................................... 29
2.3.8 DT – Date ................................................................................................................................................... 29
2.3.9 DTM – Date/Time ...................................................................................................................................... 30
2.3.10 ED – Encapsulated Data ........................................................................................................................... 30
2.3.11 EI – Entity Identifier ................................................................................................................................. 34
2.3.12 EIP – Entity Identifier Pair ....................................................................................................................... 35
2.3.13 ERL – Error Location ............................................................................................................................... 35
2.3.14 FC – Financial Class ................................................................................................................................. 37
2.3.15 FN – Family Name ................................................................................................................................... 37
2.3.16 FT – Formatted Text Data ......................................................................................................................... 38
2.3.17 HD – Hierarchic Designator ..................................................................................................................... 39
2.3.18 ID – Coded Value for HL7-Defined Tables .............................................................................................. 40
HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page i
February 2010

Table of Contents
2.3.19 IS – Coded Value for User-Defined Tables ............................................................................................... 40
2.3.20 MSG – Message Type ............................................................................................................................... 41
2.3.21 NDL - Name With Date And Location ..................................................................................................... 41
2.3.22 NM – Numeric .......................................................................................................................................... 43
2.3.23 PL – Person Location ................................................................................................................................ 43
2.3.24 PRL – Parent Result Link ......................................................................................................................... 45
2.3.25 PT – Processing Type................................................................................................................................ 46
2.3.26 RP – Reference Pointer ............................................................................................................................. 47
2.3.27 SAD – Street Address ............................................................................................................................... 49
2.3.28 SI – Sequence ID ...................................................................................................................................... 50
2.3.29 SN – Structured Numeric .......................................................................................................................... 50
2.3.30 ST – String Data ....................................................................................................................................... 52
2.3.31 TM – Time ................................................................................................................................................ 52
2.3.32 TS – Time Stamp ...................................................................................................................................... 53
2.3.33 TX – Text Data ......................................................................................................................................... 53
2.3.34 VID – Version Identifier ........................................................................................................................... 54
2.3.35 XAD – Extended Address ......................................................................................................................... 55
2.3.36 XCN – Extended Composite ID Number and Name for Persons ............................................................. 57
2.3.37 XON – Extended Composite Name and Identification Number for Organizations .................................. 60
2.3.38 XPN – Extended Person Name ................................................................................................................. 61
2.3.39 XTN – Extended Telecommunication Number......................................................................................... 63
3. MESSAGE PROFILE – PUBLIC HEALTH LABORATORY MESSAGING ........................................... 65
3.1 Use Case Model ................................................................................................................................................. 65
3.2 Dynamic Interaction Model ............................................................................................................................... 68
3.3 Dynamic DefinitionS ......................................................................................................................................... 70
3.4 Interactions ........................................................................................................................................................ 72
3.5 References ......................................................................................................................................................... 76
4. MESSAGES ............................................................................................................................................ 78
4.1 ORU^R01^ORU_R01 ....................................................................................................................................... 79
4.1.1 Diagram of ORU^R01^ORU_R01 ............................................................................................................. 85
4.1.2 Comparison with the 2.3.1 ORU^R01 ........................................................................................................ 86
4.2 ACK^R01^ACK ................................................................................................................................................ 87
4.3 HL7 Batch Protocol ........................................................................................................................................... 87
5. SEGMENT AND FIELD DESCRIPTIONS .............................................................................................. 90
5.1 MSH – Message Header Segment ..................................................................................................................... 90
5.2 SFT – Software segment .................................................................................................................................... 96
Page ii
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Table of Contents
5.3 MSA – Acknowledgement Segment .................................................................................................................. 97
5.4 ERR – Error Segment ........................................................................................................................................ 99
5.5 PID – Patient Identification Segment .............................................................................................................. 100
5.6 NK1 – Next of Kin Segment............................................................................................................................ 106
5.7 PV1 – Patient Visit Information ....................................................................................................................... 111
5.8 PV2 – Patient Visit – Additional Information Segment ................................................................................... 115
5.9 ORC – Common Order Segment ..................................................................................................................... 119
5.10 OBR – Observation Request Segment ........................................................................................................... 123
5.11 TQ1 – Timing/Quantity Segment ................................................................................................................... 135
5.12 OBX – Observation/Result Segment ............................................................................................................. 137
5.12.1 Observation Identifiers, Observation Values, Interpretations and Comments ........................................ 145
5.13 SPM – Specimen Segment ............................................................................................................................. 147
5.14 NTE – Notes and Comments Segment .......................................................................................................... 152
5.15 FHS – FILE HEADER SEGMENT ............................................................................................................... 153
5.16 FTS – FILE TRAILER SEGMENT .............................................................................................................. 154
5.17 BHS – BATCH HEADER SEGMENT ......................................................................................................... 155
5.18 BTS – Batch TRAILER SEGMENT ............................................................................................................. 157
6. CODE SYSTEMS AND VALUE SETS ................................................................................................. 158
6.1 Vocabulary Constraints .................................................................................................................................... 159
6.1.1 HL7 Tables................................................................................................................................................ 173
6.2 Vocabulary Distribution ................................................................................................................................... 182
7. EXAMPLE LABORATORY RESULT MESSAGES .............................................................................. 183
7.1 LEAD Laboratory Result Message .................................................................................................................. 183
7.2 CAMPYLOBACTER JEJUNI ........................................................................................................................ 184
7.3 Animal rabies ................................................................................................................................................... 186
7.4 Hepatitis C Virus.............................................................................................................................................. 187
7.5 Minimal Message with Acknowledgement ...................................................................................................... 188
7.5.1 Example: Minimal Message .................................................................................................................... 188
7.5.2 Example: Successful Receipt Message .................................................................................................... 190
7.5.3 Example: Error on Receipt Message........................................................................................................ 190
7.5.4 Example: Error on Receipt - Warning...................................................................................................... 191
7.5.5 Example: Reject Receipt Message ........................................................................................................... 193
APPENDIX A. HL7 REPORTING OF CULTURE AND SUSCEPTIBILITIES .......................................... 194
A.1 Introduction..................................................................................................................................................... 194
A.2 Template for Culture Results .......................................................................................................................... 194
A.2.1 Examples of Culture Results .................................................................................................................... 195
HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page iii
February 2010

Table of Contents
A.3 Template for Culture and Susceptibility Results ............................................................................................. 197
A.3.1 Examples of Culture and Susceptibility Results ...................................................................................... 199
A.4 Linking Parent and Child Results ................................................................................................................... 203
APPENDIX B. CLINICAL LABORATORY IMPROVEMENTS AMENDMENT CONSIDERATIONS, US
REALM ONLY ........................................................................................................................................... 204
B.1 Mandatory Reporting Requirements ............................................................................................................... 204
B.2 Report Retention ............................................................................................................................................. 205
B.3 Authorized Parties ........................................................................................................................................... 206
APPENDIX C. STRATEGY FOR HARMONIZING MULTIPLE HL7 IMPLEMENTATION GUIDES......... 207
C.1 Background ..................................................................................................................................................... 207
C.2 Conformance to the HL7 Standard.................................................................................................................. 208
C.2.1 Usage ....................................................................................................................................................... 208
C.3 Strategy ........................................................................................................................................................... 210
C.3.1 Usage Rules ............................................................................................................................................. 210
C.3.2 Cardinality................................................................................................................................................ 211
C.3.3 Length ...................................................................................................................................................... 212
C.3.4 Vocabulary/Value Sets .............................................................................................................................. 212
C.3.5 Identifiers ................................................................................................................................................. 212
C.3.6 Pre-adoption of Features .......................................................................................................................... 213
C.3.7 Golden Rule ............................................................................................................................................. 213
APPENDIX D. RECOMMENDED CHANGES TO EXISTING IMPLEMENTATION GUIDES .................. 214

Page iv
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Index of Tables

INDEX OF TABLES
Table 1-1. Message Element Attributes ........................................................................................................ 3
Table 1-2. Usage Conformance Testing Recommendations ........................................................................ 6
Table 2-1. Delimiters ..................................................................................................................................... 9
Table 2-2. Data Types ................................................................................................................................. 13
Table 2-3. Coded Element (CE) .................................................................................................................. 15
Table 2-4. Composite ID Number And Name Simplified (CNN) ................................................................. 16
Table 2-5. Composite Quantity With Units (CQ) ......................................................................................... 17
Table 2-6. Coded With Exceptions – All Fields Except OBX-5 (CWE) ....................................................... 18
Table 2-7 Coded with Exceptions – For OBX-5 ONLY (CWE) ................................................................... 23
Table 2-8. Extended Composite Id With Check Digit (CX) ......................................................................... 27
Table 2-9. Date/Time Range (DR) ............................................................................................................. 29
Table 2-10. Date (DT) ................................................................................................................................. 29
Table 2-11. Date/Time (DTM) ..................................................................................................................... 30
Table 2-12. Encapsulated Data (ED) ......................................................................................................... 30
Table 2-13. Entity Identifier (EI) .................................................................................................................. 34
Table 2-14. Entity Identifier Pair (EIP) ........................................................................................................ 35
Table 2-15. Error Location (ERL) ................................................................................................................ 35
Table 2-16. Financial Class (FC) ................................................................................................................ 37
Table 2-17. Family Name (FN).................................................................................................................... 37
Table 2-18. Formatted Text Data (FT) ........................................................................................................ 38
Table 2-19. Hierarchic Designator (HD) ...................................................................................................... 39
Table 2-20. Coded Value For HL7-Defined Tables (ID) ............................................................................. 40
Table 2-21. Coded Value For User-Defined Tables (IS) ............................................................................. 40
Table 2-22. Message Type (MSG) .............................................................................................................. 41
Table 2-23. Name With Date And Location (NDL) ...................................................................................... 41
Table 2-24. Numeric (NM)........................................................................................................................... 43
Table 2-25. Person Location (PL) ............................................................................................................... 43
Table 2-26. Parent Result Link (PRL) ......................................................................................................... 45
Table 2-27. Processing Type (PT) .............................................................................................................. 46
Table 2-28. Reference Pointer (RP) ........................................................................................................... 47
Table 2-29. Street Address (SAD) .............................................................................................................. 49
Table 2-30. Sequence ID (SI) ..................................................................................................................... 50
Table 2-31. Structured Numeric (SN) ......................................................................................................... 50
Table 2-32. String Data (ST) ....................................................................................................................... 52
HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page v
February 2010

Index of Tables
Table 2-33. Time (TM) ................................................................................................................................ 52
Table 2-34. Time Stamp (TS)...................................................................................................................... 53
Table 2-35. Text Data (TX) ......................................................................................................................... 53
Table 2-36. Version Identifier (VID) ............................................................................................................ 54
Table 2-37. Extended Address (XAD) ......................................................................................................... 55
Table 2-38. Extended Composite Id Number And Name For Persons (XCN) ............................................ 57
Table 2-39. Extended Composite Name And Identification Number For Organizations (XON) ................. 60
Table 2-40. Extended Person Name (XPN) ................................................................................................ 61
Table 2-41. Extended Telecommunication Number (XTN) ......................................................................... 63
Table 3-1. Use Case: Laboratory To Public Health .................................................................................... 65
Table 3-2. Dynamic Definition – Individual Transactions With Acknowledgments ..................................... 70
Table 3-3. Dynamic Definition - Individual Transactions Without Acknowledgments ................................. 70
Table 3-4. Dynamic Definition - Batch Transactions ................................................................................... 71
Table 3-5. Interactions – Individual Transaction With Acknowledgments .................................................. 72
Table 3-6. Interactions – Individual Transaction Without Acknowledgments/Batch ................................... 74
Table 4-1. ORU^R01^ORU_R01 Abstract Message Syntax ...................................................................... 79
Table 4-2. ACK^R01^ACK Abstract Message Syntax ................................................................................ 87
Table 4-3. Batch Abstract Message Syntax ............................................................................................... 88
Table 5-1. Message Header Segment (MSH)............................................................................................ 90
Table 5-2. Software Segment (SFT) ........................................................................................................... 96
Table 5-3. Acknowledgement Segment (MSA) ........................................................................................... 97
Table 5-4. Error Segment (ERR) ................................................................................................................ 99
Table 5-5. Patient Identification Segment (PID) ....................................................................................... 100
Table 5-6. Next of Kin Segment (NK1) ..................................................................................................... 107
Table 5-7. Patient Visit Information (PV1) ................................................................................................. 111
Table 5-8. Patient Visit – Additional Information (PV2) ............................................................................. 115
Table 5-9. Common Order Segment (ORC) ............................................................................................. 120
Table 5-10. Observation Request Segment (OBR) .................................................................................. 124
Table 5-11. Time/Quantity Segment for Order Group .............................................................................. 135
Table 5-12. Observation/Result Segment (OBX) ...................................................................................... 137
Table 5-13. Observation Identifiers ........................................................................................................... 146
Table 5-14. Specimen Segment (SPM) .................................................................................................... 148
Table 5-15. Notes and Comments Segment (NTE) .................................................................................. 152
Table 5-16. File Header Segment (FHS) .................................................................................................. 153
Table 5-17. File Trailer Segment (FTS) .................................................................................................... 155
Table 5-18. Batch Header Segment (BHS) ............................................................................................... 155
Table 5-19. Batch Trailer Segment (BTS)................................................................................................. 157
Page vi
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Index of Tables
Table 6-1. Value Set/Code System Summary .......................................................................................... 159
Table 6-2. HL7 Table 0078 from 2.7 ......................................................................................................... 174
Table 6-3. HL7 Table 0125 – Value Type ................................................................................................. 176
Table 6-4. HL7 Table 0155 – Accept/Application Acknowledgment Conditions ....................................... 180
Table 6-5. HL7 Table 0291 - Subtype Of Referenced Data...................................................................... 180
Table 6-6. HL7 Table 0301 - Universal ID Type ....................................................................................... 181
Table 6-7. HL7 Table 0834 – MIME Type ................................................................................................. 182

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page vii
February 2010

Table of Figures

TABLE OF FIGURES
Figure 3-1. Send Laboratory Result Use Case Model ................................................................................ 67
Figure 3-2. Activity Diagram for Send Laboratory Result Use Case – Acknowledgment Required ........... 68
Figure 3-3. Activity Diagram for Send Laboratory Result Use Case - Without Acknowledgment .............. 69
Figure 3-4. Activity Diagram for Send Laboratory Result Use Case - Batch .............................................. 69
Figure 4-1. 2.5.1 ELR Message .................................................................................................................. 85
Figure 4-2. 2.3.1 ELR Message .................................................................................................................. 86

Page viii
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 1: Introduction

1.Introduction
The HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm),
Release 1 is the public health version of the HL7 U.S. Realm - Interoperability Specification: Lab Result Message to
EHR. The use case describes the transmission of laboratory-reportable findings to appropriate local, state, territorial
and federal health agencies using the HL7 2.5.1 ORU^R01 message. It includes a reference to batch processing. It
does not cover querying patient demographics or querying of laboratory results.

1.1 PURPOSE
This guide contains the necessary specifications for laboratory results reporting to local, state, territorial and federal
health agencies. In particular, this guide addresses messaging content and dynamics related to the transmission of
Laboratory Reportable Result Messages/ELR. Each state and territory has requirements for laboratories to report
certain findings to health officials. In the past, these reports were written by hand on forms provided by health
departments and mailed to appropriate offices. With computerization of laboratories, it has become possible for
laboratories to send reportable data to health departments electronically. The message described in this guide is not
specific to any pathogen or reportable condition and is applicable for most biological and chemistry laboratoryreportable findings. It should be noted that this guide does not cover reporting of results from laboratory to
laboratory.
This document is intended to meet the needs and requirements of implementation guidance in Public Health entities,
replacing the previous documentation regarding Electronic Laboratory Reporting (ELR). It does not replace the
need for documentation of the constraints of specific implementations.

1.2 AUDIENCE
This guide is designed for use by analysts and developers who require guidance on optional and ambiguous elements
of the HL7 Version 2.5.1 ORU Unsolicited Observation Message relative to the Public Health Lab Result/ELR Use
Case. Users of this guide must be familiar with the details of HL7 message construction and processing. This guide
is not intended to be a tutorial on that subject.

1.3 SCOPE
This specification covers the exchange of laboratory results from the testing source to appropriate local, state,
territorial and federal public health agencies. One of the primary features of this implementation guide is its focus
on key points of broad interoperability. These key points include the following:
•

1

Use of strong identifiers for key information objects – These information objects include patients, orders,
providers and organizations. A strong identifier is one that uniquely identifies the object in question in a global
fashion. This means the identifier includes enough information to remain unique when taken out of the context
within which the identifier was created. This is accomplished through the use of assigning authorities for the
identifier. In this guide, an assigning authority is normally handled either as an ISO Object Identifier (OID).
The combination of the identifier and the assigning authority should always be unique. This uniqueness ensures
that each identifier can be broadly shared among independent healthcare organizations and still point to its
originally associated object.
HL7 is developing an implementation guide for the use of OIDs, “HL7 Implementation Guidance for Unique
Object Identifiers (OIDs), Release 1 1”. Although this IG is still under development, it does provide guidance on
how organizations can manage OIDs.

The current version of the HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1 can be found at:
http://www.hl7.org/documentcenter/ballots/2009may/downloads/V3_OIDS_R1_I2_2009MAY.zip.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 1
February 2010

Chapter 1: Introduction
•

Use of Vocabulary Standards This guide calls for specific vocabulary standards for the exchange of
laboratory information. Use of standard vocabularies is important for a number of reasons. Use of standard
vocabularies allows broad distribution of healthcare information without the need for individual institutions to
exchange master files for data such as test codes, result codes, etc. Each institution maps its own local
vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a
single island of information. Standard vocabularies, particularly coded laboratory results, enable more
automated decision support for patient healthcare, as well as more automated public health surveillance of
populations.

1.3.1 Other Related Profiles
This specification documents a message profile for Electronic Laboratory Reporting to Public Health (ELR Receiver
profile). Several other profiles are referenced and documented including:
•

NHSN Receiver – This will be subject of a future HL7 Specification

•

Lab to EHR Receiver - HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable
Laboratory Result Reporting to EHR, Release 1

This document should not be considered the source of truth for these other profiles. They are provided here as
supplementary documentation.
This specification provides a strategy for harmonizing various lab result specifications, but that strategy has not been
universally agreed upon. The ELR Receiver profile has been constructed according to the strategy outline in
Appendix C. The Lab Result Sender profile has also been constructed according to the same strategy, but is not
considered ”Normative”. Only the ELR Receiver profile in this document should be considered “Normative”.
Normative is being used here in the sense that any system claiming conformance to the ELR Receiver profile would
have its conformance measured according to the profile in this document (which itself is an informative HL7
Standard).
Two profiles are found only in this document:
•

ELR Receiver – a message profile for Electronic Laboratory Reporting to Public Health. This is the
primary focus of this document.

•

Lab Result Sender – This profile is provided for informational purposes only. A sender of Laboratory result
messages conforming to the profile will satisfy the requirements of the ELR and NHSN profiles, and in the
future may meet the requirements of the Lab to EHR profile.

Other profiles may be added to the group of harmonized specifications, but it is not the intent of the strategy
provided in Appendix C to force any particular specification to harmonize with this group of specifications.

1.3.2 Condition Reporting
Authority to establish a list of reportable conditions and to specify the content of those reports resides with the
individual public health jurisdiction. A joint Centers for Disease Control and Prevention (CDC) – Council of State
and Territorial Epidemiologists (CSTE) project is underway, which has the goal of creating a national
knowledgebase containing this information. For information on current status, email [email protected].
Until the knowledgebase is completed, reporters can access further information about reportable conditions at the
website for their own Public Health jurisdiction, or at the CSTE web site:
http://www.cste.org/dnn/ProgramsandActivities/PublicHealthInformatics/tabid/346/Default.aspx

1.4 CONVENTIONS
This guide adheres to the following conventions:
•

The guide is constructed assuming the implementer has access to the 2.5.1 version of the HL7 Standard.
Although some information from the standard is included in this implementation guide, much information from
the standard has not been repeated here.

Page 2
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 1: Introduction
•

The rules outlined in HL7 2.5.1, Chapter 2, Section 2.12, Conformance Using Message Profiles, were used to
document the use case for, and constraints applied to, the messages described in this guide.

•

Data types have been described separately from the fields that use the data types. For details regarding data
type field lengths, please refer to Section 2.1.3, Lengths, in this document.

•

No conformance information is provided for optional message elements. This includes length, usage,
cardinality, value sets and descriptive information. Implementers who want to use optional message elements
should refer to the HL7 Standard to determine how these optional message elements will be used.

1.4.1 Message Element Attributes
The following table describes the various attributes used by this guide to document data type attribute tables,
message structure attribute tables and segment attribute tables. Not all attributes apply to all attribute tables.
Table 1-1. Message Element Attributes

TABLE 1-1. MESSAGE ELEMENT ATTRIBUTES
Attribute
Seq

Definition
Sequence of the elements as numbered in the HL7 message element. The Seq attribute
applies to the data type attribute table and the segment attribute table.
Three-character code for the segment and the abstract syntax (e.g., the square and curly
braces).

Segment

[ XXX ]

Optional

{ XXX }

Repeating

XXX Required
[{ XXX }] Optional and Repeating
Note that for segment groups there is no segment code present, but the square and curly
braces will still be present.
The Segment attribute only applies to the Message attribute table.
Maximum length of the element. Lengths are provided only for primitive data types.
The length attribute apples to data type attribute tables and segment attribute tables.
Lengths should be considered recommendations, not absolutes. The receiver can truncate
fields, components and sub-components that are longer than the recommended length. The
receiver should continue to process a message even when a field, component, or subcomponent length exceeds the maximum recommended length identified in this specification.

Length

See section C.3.3 for documentation on how lengths are handled in this guide.
The length attribute may contain a character indicating how the data may be truncated by a
receiver. The truncation characters are defined as follows:

DT
Usage

•

= Truncation not allowed

•

# Truncation allowed

•

No character indicates the truncation behavior is not defined.

Data type used by this profile for HL7 element.
The data type attribute applies to data type attribute tables and segment attribute tables.
Usage of the message element for this profile. Indicates whether the message element
(segment, segment group, field, component, or subcomponent) is required, optional, or
conditional in the corresponding message element. Usage applies to the message attribute

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 3
February 2010

Chapter 1: Introduction

TABLE 1-1. MESSAGE ELEMENT ATTRIBUTES
Attribute

Definition
table, data type attribute table and the segment attribute table. See section C.3.1 – Usage for
documentation on how usage has been implemented in this guide.
In this implementation guide, usage has been divided by actor. This guide documents four
separate actors:
•

Lab Result Sender

•

ELR Receiver

•

NHSN Receiver

•

Lab to EHR Receiver

Only the ELR Receiver actor is considered “Normative” in this guide. The other actors and the
related profiles are provided as informational only. These non-normative usage columns have
a grey background.
See section 3.1 for additional information about the various actors documented in this guide.
Legal usage values are:
R – Required.
HL7 Definition: A conforming sending application shall populate all “R” elements with a
non-empty value. Conforming receiving application shall process
(save/print/archive/etc.) or ignore the information conveyed by required elements. A
conforming receiving application must not raise an error due to the presence of a
required element, but may raise an error due to the absence of a required element.
Any element designated as required in a standard HL7 message definition shall also be
required in all HL7 message profiles of that standard message.
RE – Required, but can be empty.
HL7 Definition: The element may be missing from the message, but must be sent by
the sending application if there is relevant data. A conforming sending application must
be capable of providing all "RE" elements. If the conforming sending application knows
the required values for the element, then it must send that element. If the conforming
sending application does not know the required values, then that element will be
omitted.
Receiving applications will be expected to process (save/print/archive/etc.) or ignore
data contained in the element, but must be able to successfully process the message if
the element is omitted (no error message should be generated because the element is
missing).
O – Optional.
HL7 Definition: This code indicates that the Usage for this element has not yet been
defined. A usage of ‘Optional’ may not be used in ‘implementation’ profiles (nooptionality profiles). Conformance may not be tested on an Optional field. Narrower
profiles may be defined based on this profile, and may assign any usage code to the
element
C – Conditional.
HL7 Definition: This usage has an associated condition predicate (See section 2.B.7.6,
"Condition predicate").
If the predicate is satisfied: A conformant sending application must always send the
element. A conformant receiving application must process or ignore data in the
element. It may raise an error if the element is not present.
Page 4
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 1: Introduction

TABLE 1-1. MESSAGE ELEMENT ATTRIBUTES
Attribute

Definition
If the predicate is NOT satisfied: A conformant sending application must NOT send
the element. A conformant receiving application must NOT raise an error if the
condition predicate is false and the element is not present, though it may raise an error
if the element IS present.
CE – Conditional, but may be empty.
HL7 Definition: This usage has an associated condition predicate (See section 2.B.7.6,
"Condition predicate").
If the predicate is satisfied: If the conforming sending application knows the required
values for the element, then the application must send the element. If the conforming
sending application does not know the values required for this element, then the
element shall be omitted. The conforming sending application must be capable of
knowing the element (when the predicate is true) for all 'CE' elements. If the element is
present, the conformant receiving application shall process (display/print/archive/etc.) or
ignore the values of that element. If the element is not present, the conformant
receiving application shall not raise an error due to the presence or absence of the
element.
If the predicate is not satisfied: The conformant sending application shall not
populate the element.
The conformant receiving application may raise an application error if the element is
present.
X – Not used for this profile.
HL7 Definition: For conformant sending applications, the element will not be sent.
Conformant receiving applications may ignore the element if it is sent, or may raise an
application error.
- - The hyphen (-) Indicates the profile using the actor does not provide documentation of the
structure containing the particular element or does not provide documentation of the
particular element in the structure. For instance in a data type specification for CE, if a
profile does not provide documentation of the CE data type, then each component of
the data type would have a “-“ for the usage for the actor associated with that profile.
Minimum and maximum number of times the element may appear.
[0..0] Element never present.
[0..1] Element may be omitted and can have, at most, one occurrence.
[1..1] Element must have exactly one occurrence.
[0..n] Element may be omitted or may repeat up to n times.

Cardinality

[1..n] Element must appear at least once, and may repeat up to n times.
[0..*] Element may be omitted or repeat an unlimited number of times.
[1..*] Element must appear at least once, and may repeat unlimited number of times.
[m..n] Element must appear at least m, and at most, n times.
Cardinality applies only to message attribute tables and segment attribute tables.
See section C.3.2 for additional information on how cardinality is handled in this guide.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 5
February 2010

Chapter 1: Introduction

TABLE 1-1. MESSAGE ELEMENT ATTRIBUTES
Attribute

Definition
The set of coded values to be used with the field. The value set attribute applies only to the
data type attribute tables and the segment attribute tables. The value set may equate with an
entire code system part of a code system, or codes drawn from multiple code systems.

Value Set

Note: Where a table constraint is indicated, or where HL7 Version 2.6
standards are pre-adopted, the constrained or specified HL7 table is included
below the data type table.

Name

HL7 descriptor of the message element. Name applies to the message attribute table, data
type attribute table and the segment attribute table.

Description/Comments

Context and usage for the element. Description/Comments applies to the message attribute
table, data type attribute table and the segment attribute table.

Note: In the tables throughout this document, Yellow = This Interoperability Specification does not support the use of
this item. This corresponds with the Usage code “X”.

1.4.1.0 Usage Conformance Testing Recommendations
The following table provides some recommendations for testing the various usage codes described in the previous
table.
Table 1-2. Usage Conformance Testing Recommendations

TABLE 1-2. USAGE CONFORMANCE TESTING RECOMMENDATIONS
Usage
R – Required

Recommendation
Required elements must be present in a message instance with the following caveats:
A required segment, which is contained within a segment group, is required only when the
segment group is present in the message. For instance if the segment group is RE, then when
the segment group is present, the required segments in that group must be present.
A required field in a segment is required only when the segment itself is present in the
message. For instance if the segment is CE (conditional or empty) and the conditional
predicate is satisfied, then the segment is present in the message and the required fields must
be present in the segment.
A required component of a data type is required only when the field the data type is associated
with is present in the message.
Testing of a required element generally involves generating both a fully populated message
instance as well as a minimally populated message instance. It may be necessary to generate
specific test cases to handle separate segment groups, segments, etc. depending on the
usage associated with these higher level elements within a message.

RE – Required, but can Since conformant senders must be able to show they can send this data, the primary
be empty
mechanism for testing the RE usage would involve requiring the sender to transmit a “fully”
populated message instance from their application. In this case, the expectation is that the
message will be generated by the application, not handcrafted. The message would contain all
data the sending application can populate in the message. This generally means the sender
would be populating in their application all data elements being tested, including those that are
optional in the application.
O – Optional
Page 6
February 2010

Conformance testing for optional elements would not normally be performed. If a particular
HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 1: Introduction

TABLE 1-2. USAGE CONFORMANCE TESTING RECOMMENDATIONS
Usage

Recommendation
implementation decides to use an optional element, it should create an implementation specific
profile which further constrains this profile, making the optional element either required,
required but may be empty, condition or conditional but may be empty, and then test the
element in question based upon the assigned usage in that profile.

C – Conditional

Testing conditional elements generally means a special test case must be developed based
upon the specific conditional rule or conditional predicate documented for the element.

CE – Conditional, but Testing conditional but may be empty elements generally means a special test case must be
may be empty
developed based upon the specific conditional rule or conditional predicate documented for the
element.
X – Not used for this Testing this usage code usually involves looking at both fully populated and minimally
profile
populated messages. Note that the sending application may collect the data element in
question, but it should not communicate that data element in message instances.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 7
February 2010

Chapter 1: Introduction

This page intentionally left blank.

Page 8
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2. Messaging Infrastructure
2.1 MESSAGING FRAMEWORK
2.1.1 Delimiters
This profile supports the use of the normal HL7 delimiters. It is recommended, but not required, that implementers
be able to send messages using the standard HL7 delimiters. Receivers must be capable of receiving any legal
delimiters that are sent in a particular message instance.
This table is pre-adopted from the HL7 Version 2.6, which offers information regarding best practices. The intent
has not changed from Version 2.5.1. Note that this implementation guide includes additional constraints and
explanations for the entries.
Table 2-1. Delimiters

TABLE 2-1. DELIMITERS
Delimiter

Segment Terminator

Required

Encoding

Value

Character

Description

Position

-

Terminates a segment record. This value cannot be
changed by implementers.
Additional Constraints and Explanation:
The denotes the ASCII-013 carriage return character.
There is a common misunderstanding that a linefeed
character, or carriage return followed by a linefeed
character, is allowed also. Neither HL7 nor this profile
allows either of these two as part of the segment
terminator. Only the ASCII-013 carriage return is
allowed.

Field Separator

|

-

Separates two adjacent data fields within a segment. It
also separates the segment ID from the first data field in
each segment.
Additional Constraints and Explanation:
It is recommended that senders use ASCII-124, the vertical
bar (|) character, as the field separator.

Component Separator ^

1

Separates adjacent components of data fields where
allowed.
Additional Constraints and Explanation:
It is recommended that senders use ASCII-094, the caret
(^) character, as the component separator.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 9
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-1. DELIMITERS
Delimiter

Repetition Separator

Required
Value

~

Description

Encoding

Character
Position

2

Separates multiple occurrences of a field where allowed.
Additional Constraints and Explanation:
It is recommended that senders use ASCII-126, the tilde
character (~), as the repetition separator.

Escape Character

\

3

Use the escape character with any field represented by an
ST, TX or FT data type, or for use with the data (fifth)
component of the ED data type. If no escape characters
are used in a message, this character may be omitted.
However, it must be present if subcomponents are used
in the message. Best practice is always to include this
character.
Additional Constraints and Explanation:
It is recommended that senders use ASCII-091, the
backslash (\) character, as the escape character.

Subcomponent
Separator

&

4

Separates adjacent subcomponents of data fields where
allowed. If there are no subcomponents, this character
may be omitted. Best practice is always to include this
character.
Additional Constraints and Explanation:
It is recommended that senders use ASCII-038, the
ampersand (&) character, as the subcomponent
separator.

2.1.2 Null Values In Fields Vs. Components
In HL7, a null value for a field is indicated by paired double quotes (|""|). The null value applies to the field as a
whole, not to the components/subcomponents of the field. A null field value indicates that the receiver of the
message should delete the corresponding set of information from the data store. For this implementation guide, null
values within components and subcomponents are meaningless. For example, |lastname^firstname^""^^^^L| would
be interpreted exactly as |lastname^firstname^^^^^L|. The components and subcomponents of a data type constitute
a snapshot of the data. The set of data represented by the data type is handled as a complete set; therefore, using the
null value to indicate a missing component or subcomponent is unnecessary.

2.1.3 Lengths
In HL7 Version 2.5, HL7 assigned lengths to the components of data types, but did not standardize the lengths of the
fields that use those data types. This guide pre-adopts the length rules from HL7 Version 2.7: Starting with v2.7,
HL7 allows documentation of both a minimum and maximum length for an element.
In HL7 Version 2.7 length is specified for primitive data types (i.e., those without components). Length is not
specified for composite elements. For composite data types, the actual minimum and maximum lengths can be very
difficult to determine due to the interdependencies on the component content, and the specification of actual lengths
is not useful either. In general, this guide will adopt lengths from HL7 Version 2.7.
The concept of truncation is being pre-adopted from HL7 Version 2.7 as well, but only in regards to length
documentation. The transmission of the truncation character in message data is not being pre-adopted.
Page 10
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure
See section C.3.3 for additional documentation about how lengths are documented in this guide.
Note: In HL7 Version 2.5.1, the length of 65536 has a special meaning: For HL7, "If the maximum length
needs to convey the notion of a Very Large Number, the number 65536 should be displayed to alert the
user."
In this implementation guide, fields or components with length 65536 should be understood as having no
prescribed length. Receivers should be prepared to accept any size chunk of data carried in the field or
component.

2.1.4 Snapshot processing
HL7 distinguishes between two methods of update: the "snapshot" and the "action code/unique identifier" modes.
Both modes apply to repeating segments and repeating segment groups. For repeating fields, only snapshot
processing applies. For the purpose of this guide, only snapshot processing is supported for segments, segment
groups and fields.

2.1.4.0 Repeating Segments
HL7 defines snapshot processing for segments as follows:
In the "snapshot" mode, the information contained in the set of repeating segments or segment groups from
the incoming message replaces the corresponding information in the receiving application. This is
equivalent to a deletion of the prior information followed by the addition of the newly supplied
information. In this mode, everything (all repeating segments and segment groups) must be sent with every
subsequent message in the series of messages. There is no other way to indicate which ones changed and
which ones did not.
To specify "delete all of the segments in this repeating group" in the snapshot mode, send a single segment
with "delete data" (indicated by a value of "") in all fields. This actively signals the receiver that there is
information that needs to be deleted. If no segment were sent, this would equate to "no information.” No
information should not signal the receiver to take an action. There would be risk that the receiver might
misinterpret the sender's intent. 2

2.1.4.1 Repeating Fields
Snapshot processing for repeating fields requires sending a full list of repetitions for each transaction. If the intent is
to delete an element, the element is left off the list. This is analogous to the snapshot mode for repeating segments
and segment groups. To delete the whole list, transmit the field once with a |””| (null) in the first component.
Repetitions of fields shall not have empty repetitions followed by repetitions containing data, except where the HL7
standard clearly reserves certain repetitions for specific purposes. For instance, PID-5 Patient Name is a repeating
field, the first repetition of which is reserved by HL7 for the legal name. In the case where a name is known for the
patient, but is not the legal name, format the name field as follows: |~lastname^firstname^mi^^^^A|.

2.1.4.2 Message Snapshots
Snapshot processing for messages simply means that the content of the current message is used to replace the
contents from a prior message for the same information object. The primary problem associated with message
snapshots is making sure the appropriate information object is updated. In this case, the information object is a
laboratory result associated with a specific patient. To do the snapshot update properly, key identifiers must be
shared across the messages, and must together uniquely identify the specific laboratory result that is to be updated.
In HL7 version 2.7, the key identifiers to tie results together have been identified as the Placer Order Number (ORC2/OBR-2) and Filler Order number (ORC-3/OBR-3). Unfortunately, some laboratories don’t consider the placer or

2

Taken from HL:7 2.6, Chapter 2, section 2.10.4.1.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 11
February 2010

Chapter 2: Messaging Infrastructure
filler number as a unique identifier of the order (and hence the result). Instead, these laboratories use the placer and
filler order numbers to identify a group of orders. Typically, in this case, the implementer will need to also look at
OBR-4, the universal Service ID in conjunction with the placer or filler order number. Other identifiers in the
message that can be used to verify the correct results are being updated include the patient identifiers 3 found in PID3. If these identifiers don’t match across messages, even when the placer and filler order numbers match, then it’s
very likely the two messages are for different patients.
Another factor complicating the association of results across messages is the fact that many laboratories do not
generate unique filler order numbers. In many cases, these laboratories are actually using an “accession number” as
the filler order number. Often these accession numbers are reused by the laboratory system. That means that a
particular accession number may be use repeatedly for different orders over time. If this occurs, validating the
patient identifiers in PID-3 becomes critical. This guide will call for the use of placer and filler order numbers that
are not reused in this fashion.
Another issue with matching results from multiple messages is because not all laboratories properly identify the
assigning authority associated with an identifier (such as a placer of filler order number). In HL7 terminology, an
assigning authority is a component of an identifier that together with the actual ID makes the overall identifier
unique. For instance, if Laboratory A creates a filler order number 123, Laboratory B also creates filler order
number 123, and both these laboratories send results associated with these orders to a public health department, the
public health department needs to know which laboratory each filler order number is associated with. The assigning
authority is used to distinguish between these two laboratories. Not all laboratories provide that assigning
authorities, so the receiver of the message have to figure out a mechanism for associating the order number with the
appropriate laboratory. This guide will require use of some sort of assigning authority to prevent this problem, but
it’s worth noting that non-conformant Laboratories can cause tremendous problems by ignoring this requirement.
This actually becomes a patient safety issue because results can end up being associated with incorrect patients
because of this sort of problem.
Finally, for those public health departments that wish to create longitudinal records of laboratory results for patients,
the use of patient identifiers to associate results becomes important. Many of the same sorts of issues identified
above for placer and filler order numbers exist for patient identifiers. Often, no assigning authority information is
provided for these patient identifiers. In this case, personally identifiable information such as name, date of birth,
gender, address, etc. become important in trying to match results to the appropriate patient. Certainly, not all public
health departments will be trying to do this sort of matching, many are not even allowed to by state law, while others
may actually be required to by state law.

2.1.4.3 Creation of Message Snapshots
The snapshot of data used to construct the message is captured at the time the relevant event (see section 3.4 below)
occurs. The event triggering creation of the message is distinct from the time of transmission that may occur at some
later time, particularly when batch transmission is being used.

2.2 USE OF ESCAPE SEQUENCES IN TEXT FIELDS
Senders and receivers using this profile shall handle escape sequence processing as described in HL7 Version 2.5.1,
Chapter 2, Section 2.7.4 (Special Characters). This requirement applies to the ST, TX and FT data types.
Implementers shall not support escape sequences described in Sections 2.7.2 (Escape sequences supporting multiple
character sets), 2.7.3 (Highlighting), 2.7.5 (Hexadecimal), 2.7.6 (Formatted Text) and 2.7.7 (Local). This restriction
applies to the TX and FT data types.

3

To manage patient identifiers, HITSP has adopted the IHE Patient ID Cross-Referencing (PIX) transaction is described in IHE-ITI TF-2 §3.9.1
and IHE Patient Identity Feed transaction is described in IHE-ITI TF-2 §3.8.1. These two IHE transactions can be found in the IHE
Technical Framework (Vol. 2: Transaction) at http://static.ihe.net/Technical_Framework/index.cfm#IT.

Page 12
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3 DATA TYPES
Table 2-2. Data Types documents what data types are used within which profiles.
Table 2-2. Data Types

TABLE 2-2. DATA TYPES
Data type

Data Type Name

Lab Result

ELR

NHSN

Lab to EHR

CE

Coded element

U

X

X

U

CNN

Composite ID Number and Name Simplified

U

U

X

U

CQ

Composite Quantity with Units

U

U

U

U

CWE

Coded with Exceptions

U

U

U

U

CX

Extended Composite ID with Check Digit

U

U

U

U

DR

Date/Time Range

U

U

U

U

DT

Date

U

U

X

U

DTM

Date/Time

U

U

U

U

ED

Encapsulated Data

U

U

X

U

EI

Entity Identifier

U

U

U

U

EIP

Entity Identifier Pair

U

U

U

U

ERL

Error Location

U

U

X

X

FC

Financial Class

U

U

X

U

FN

Family Name

U

U

U

U

FT

Formatted Text Data

U

U

U

U

HD

Hierarchic Designator

U

U

U

U

ID

Coded Values for HL7 Tables

U

U

U

U

IS

Coded value for User-Defined Tables

U

U

U

U

Sender

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Receiver

Receiver

Receiver

Page 13
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-2. DATA TYPES
Data type

Data Type Name

Lab Result

ELR

NHSN

Lab to EHR

MSG

Message Type

U

U

U

U

NDL

Name with Date and Location

U

U

X

X

NM

Numeric

U

U

X

U

PL

Person Location

U

U

U

U

PRL

Parent Result Link

U

U

U

U

PT

Processing Type

U

U

U

U

RP

Reference Pointer

U

U

X

U

SAD

Street Address

U

U

U

U

SI

Sequence ID

U

U

U

U

SN

Structured Numeric

U

U

U

U

ST

String

U

U

U

U

TM

Time

U

U

X

U

TS

Time Stamp

U

U

U

U

TX

Text Data

U

U

U

U

VID

Version Identifier

U

U

U

U

XAD

Extended Address

U

U

U

U

XCN

Extended Composite ID Number and Name

U

U

U

U

XON

Extended Composite Name and ID Number for
Organizations

U

U

U

U

XPN

Extended Person Name

U

U

U

U

XTN

Extended telecommunications number

U

U

X

U

Sender

Receiver

Receiver

Receiver

Legend for Table 2-2. Data Types:
Page 14
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure
•

U - Used in profile

•

X - Not used in profile

2.3.1 CE – Coded Element
Table 2-3. Coded Element (CE)

TABLE 2-3. CODED ELEMENT (CE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

1..20= ST

RE

-

-

RE

Identifier

2

1..199 ST
#

RE

-

-

RE

Text

It is strongly recommended that text
be sent to accompany any identifier.
When a coded value is not known,
text can still be sent, in which case
no coding system should be
identified.

3

1..12

ID

CE

-

-

CE

Name of Coding
System

Lab to EHR Condition predicate:
Required if an identifier is provided in
component 1.

4

1..20= ST

RE

-

-

RE

Alternate Identifier

The alternate identifier (from the
alternate coding system) should be
the closest match for the identifier
found in component 1.

5

1..199 ST
#

RE

-

-

RE

Alternate Text

It is strongly recommended that
alternate text be sent to accompany
any alternate identifier.

6

1..12

CE

-

-

CE

Name of Alternate
Coding System

Lab to EHR Condition predicate:
Required if an alternate identifier is
provided in component 4.

ID

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

HL70396

HL70396

Page 15
February 2010

Chapter 2: Messaging Infrastructure

Example:

|625-4^Bacteria identified:Prid:Pt:Stool:Nom:Culture^LN^BAC^Bacteria Culture^99Lab|

2.3.2 CNN – Composite ID Number and Name Simplified
Table 2-4. Composite ID Number And Name Simplified (CNN)

TABLE 2-4. COMPOSITE ID NUMBER AND NAME SIMPLIFIED (CNN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

The ID Number component combined
with the Assigning Authority –
Universal ID component (component
10) must uniquely identify the
associated person. Note - despite
the component being named “ID
Number” this component is an ST
string data type, not numeric, so the
component is not limited to just
numbers.

Name

Usage

1

1..15= ST

RE

RE

RE

O

ID Number

2

1..50# ST

RE

RE

RE

O

Family Name

3

1..30# ST

RE

RE

RE

O

Given Name

4

1..30# ST

RE

RE

RE

O

Second and Further
Given Names or Initials
Thereof

5

1..20# ST

RE

RE

RE

O

Suffix (e.g., JR or III)

6

1..20# ST

RE

RE

RE

O

Prefix (e.g., DR)

7

1..5=

IS

RE

RE

RE

O

HL70360

Degree (e.g., MD)

8

1..4=

IS

X

X

X

X

HL70297

Source Table

Page 16
February 2010

I.e., first name.

Not supported.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-4. COMPOSITE ID NUMBER AND NAME SIMPLIFIED (CNN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

1..20= IS

RE

RE

RE

O

10

1..199 ST
=

CE

CE

RE

O

1..6

CE

ID

CE

RE

Component

Comments

Local

Assigning Authority –
Namespace ID

The coding system for this
component is locally managed.

Assigning Authority Universal ID

Must be an OID.

Assigning Authority Universal ID Type

ELR Condition predicate: This
component is required if a value is
present in component 10 (Assigning
Authority – Universal ID.)

Name

Usage

9

11

Value Set

O

HL70301

ELR Condition predicate: Required if
component 1 (ID Number) is
populated.

Constrained to the value ‘ISO’.

Example:

|1234^Admit^Alan^A^III^Dr^MD^^DOC^2.16.840.1.113883.19.4.6^ISO|

2.3.3 CQ – Composite Quantity with Units
Table 2-5. Composite Quantity With Units (CQ)

TABLE 2-5. COMPOSITE QUANTITY WITH UNITS (CQ)
SEQ

1

LEN

DT

NM

Lab Result

ELR

NHSN

Lab to EHR

Usage

Usage

Usage

Usage

Sender
R

Receiver
R

Receiver
RE

Receiver
R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Value Set

Component
Name

Comments

Quantity

Page 17
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-5. COMPOSITE QUANTITY WITH UNITS (CQ)
SEQ

LEN

2

DT

CWE

Example:

Lab Result

ELR

NHSN

Lab to EHR

Usage

Usage

Usage

Usage

Sender

Receiver

RE

RE

Receiver
RE

Receiver
RE

Value Set

Component

Comments

Unified Code
for Units of
Measure
(UCUM)

Units

Units of measure must be drawn from
the UCUM coding system.

Name

|150^m&meter&UCUM|

2.3.4 CWE – Coded with Exceptions – All Fields Except OBX-5
Table 2-6. Coded With Exceptions – All Fields Except OBX-5 (CWE)

TABLE 2-6. CODED WITH EXCEPTIONS – ALL FIELDS EXCEPT OBX-5 (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

1..20= ST

RE

RE

RE

RE

Identifier

2

1..199 ST
#

CE

CE

RE

RE

Text

It is strongly recommended that text
be sent to accompany any identifier.
When a coded value is not known,
the original text attribute is used to
carry the text, not the text
component.
ELR Condition predicate: If the
Identifier component is empty, then
this component must be empty.

Page 18
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-6. CODED WITH EXCEPTIONS – ALL FIELDS EXCEPT OBX-5 (CWE)
SEQ

3

LEN

1..12

DT

ID

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

CE

Receiver

CE

Receiver

C

EHR

Value Set

Component

Comments

HL70396

Name of Coding
System

Harmonized condition predicate:
Required if an identifier is provided in
component 1.

Name

Usage
CE

See section 6 for description of the
use of coding systems in this
implementation guide.
4

1..20= ST

RE

RE

RE

RE

Alternate Identifier

The alternate identifier (from the
alternate coding system) should be
the closest match for the identifier
found in component 1.

5

1..199 ST
#

CE

CE

RE

RE

Alternate Text

It is strongly recommended that
alternate text be sent to accompany
any alternate identifier.
ELR Condition predicate: If the
alternate Identifier component is
empty, then this component must be
empty.

6

1..12

ID

CE

CE

C

CE

HL70396

Name of Alternate
Coding System

Harmonized condition predicate:
Required if an alternate identifier is
provided in component 4.
See section 6 for description of the
use of coding systems in this
implementation guide.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 19
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-6. CODED WITH EXCEPTIONS – ALL FIELDS EXCEPT OBX-5 (CWE)
SEQ

7

LEN

DT

1..10= ST

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

CE

Receiver

RE

Receiver

C

EHR

Value Set

Component
Name

Comments

Usage
RE

Coding System Version NHSN Condition predicate: Required
ID
if a coding system is identified in
component 3.
The format for the version ID is
determined by the coding system
being used. The length has been
increased to handle longer versioning
strings.

8

1..10= ST

CE

RE

C

RE

Alternate Coding
System Version ID

NHSN Condition predicate: Required
if an alternate coding system is
identified in component 6.
However, the particular coding
system indicates versioning should
be handled will be appropriate here.
The length has been increased to
handle longer versioning strings.

9

1..199 ST
#

CE

CE

RE

RE

Original Text

Either original Text is used to convey
the text that was the basis for coding,
or when there is no code to be sent,
only free text.
ELR Condition predicate: If no
identifier and alternate identifier are
present, then this component is
required.

10

1..20= ST

Page 20
February 2010

RE

O

RE

-

Second Alternate
Identifier

Additional local code.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-6. CODED WITH EXCEPTIONS – ALL FIELDS EXCEPT OBX-5 (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component

Comments

Second Alternate Text

Additional local text.

Second Name of
Alternate Coding
System

NHSN Condition predicate: Required
if a second alternate identifier is
provided in component 10.

Name

Usage

11

1..199 ST
#

RE

O

RE

-

12

1..12

CE

O

C

-

ID

Value Set

HL70396

NHSN Note-Coding system identifier
for transmitter code instance. May
be the value ‘Transmitter’ or may be
a standard coding system identifier.
13

1..10= ST

RE

O

RE

-

Second Alternate
Version for the coding system
Coding System Version identified in components 12.
ID

14

1..199 ST
=

RE

O

RE

-

Coding System OID

OID for the coding system named in
CWE.3.

15

1..199 ST
=

X

X

X

-

Value Set OID

Not supported.

16

1..8=

X

X

X

-

Value Set Version ID

Not supported.

17

1..199 ST
=

X

X

X

-

Alternate Coding
System OID

Not supported.

18

1..199 ST
=

X

X

X

-

Alternate Value Set
OID

Not supported.

19

1..8=

X

X

X

-

Alternate Value Set
Version ID

Not supported.

DTM

DTM

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 21
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-6. CODED WITH EXCEPTIONS – ALL FIELDS EXCEPT OBX-5 (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Not supported.

Name

Usage

20

1..199 ST
=

X

X

X

-

Second Alternate
Coding System OID

21

1..199 ST
=

X

X

X

-

Second Alternate Value Not supported.
Set OID

22

1..8=

X

X

X

-

Second Alternate Value Not supported.
Set Version ID

DTM

Usage: The CWE data type is used where it is necessary to communicate a code, text, coding system and the version of coding system the code was drawn from. It also
allows the communication of an alternate code drawn from another coding system. Many coded fields in this specification identify coding systems or value sets
that must be used for the field. When populating the CWE data types with these values, this guide does not give preference to the triplet in which the
standard code should appear. The receiver is expected to examine the coding system names in components 3 and 6 to determine if it recognizes the coding
system.
The CWE data type allows communication of an early form of what has come to be called "null flavors." HL7 2.5.1 refers to these as CWE Statuses, where the
values are drawn from HL7 Table 0353. .The CWE Statuses are not supported in this guide.
Note: This guide pre-adopts the structure of the CWE data type from HL7 Version 2.7. In general, public health surveillance data transmissions are from healthcare
facilities, including laboratories, to local or State health departments, and then to CDC. NHSN is an exception in that healthcare facilities use a single application
to report data directly to CDC. This enables the States to have access to those data, more specifically a selected subset of data entered into NHSN, as soon as they
are stored in the NHSN database. In the future, data may be reported to NHSN by data transmissions that follow the more general model of healthcare to health
department to CDC. In addition, surveillance data submitted to NHSN and other public health systems may be transmitted from a hospital system, Health
Information Exchange (HIE), or some other information broker rather than a single facility. These hospital information system, HIE, or broker intermediaries
may be responsible for mapping local hospital codes to CDC codes and may also have their own local coding system in which at least some codes lack a unique
one-to-one relationship to CDC standard codes. As a result, three different codes may represent the same concept: the facility local code, the transmitter local
code, and the CDC standard code. All analysis at CDC will be performed on the CDC standard code. However, coding validation will require use of the two
local codes. The transmitter code is needed to identify mapping irregularities between facility local codes and CDC standard codes that are attributable to the
process of an intermediary standardizing facility local code for their own use. The triplet code can help CDC meet this need or requirement for data validation.
For this reason, a constrained version of the CWE data type from HL7 Version 2.7 has been pre-adopted for all CE and CWE data types in this guide.

Page 22
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

Example: |625-4^Bacteria identified:Prid:Pt:Stool:Nom:Culture^LN^BAC^Bacteria
Culture^99Lab^2.26^May 2006|
2.3.5 CWE – Coded with Exceptions – For OBX-5 Only
Table 2-7 Coded with Exceptions – For OBX-5 ONLY (CWE)

TABLE 2-7 CODED WITH EXCEPTIONS – FOR OBX-5 ONLY (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Name

Usage

1

1..20= ST

R

R

RE

RE

Identifier

ELR Note: The identifier component
is always required.

2

1..199 ST
#

RE

RE

RE

RE

Text

It is strongly recommended that text
be sent to accompany any identifier.
When a coded value is not known,
the original text attribute is used to
carry the text, not the text
component.

3

1..12

R

R

C

CE

Name of Coding
System

See section 6 for description of the
use of coding systems in this
implementation guide.

ID

HL70396

NHSN & Lab to EHR Condition
predicate: Required if an identifier is
provided in component 1.
4

1..20= ST

RE

RE

RE

RE

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Alternate Identifier

The alternate identifier (from the
alternate coding system) should be
the closest match for the identifier
found in component 1.

Page 23
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-7 CODED WITH EXCEPTIONS – FOR OBX-5 ONLY (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component

Comments

Alternate Text

It is strongly recommended that
alternate text be sent to accompany
any alternate identifier.

Name of Alternate
Coding System

Harmonized condition predicate:
Required if an alternate identifier is
provided in component 4.

Name

Usage

5

1..199 ST
#

RE

RE

RE

RE

6

1..12

CE

CE

C

CE

ID

Value Set

HL70396

See section 6 for description of the
use of coding systems in this
implementation guide.
7

1..10= ST

CE

RE

C

RE

Coding System Version NHSN Condition predicate: Required
ID
if a coding system is identified in
component 3.
However, the particular coding
system indicates versioning should
be handled will be appropriate here.
The length has been increased to
handle longer versioning strings.

8

1..10= ST

RE

RE

RE

RE

Alternate Coding
System Version ID

However, the particular coding
system indicates versioning should
be handled will be appropriate here.
The length has been increased to
handle longer versioning strings.

9

1..199 ST
#

RE

RE

RE

RE

Original Text

Original Text is used to convey the
text that was the basis for coding.

10

1..20= ST

RE

O

RE

-

Second Alternate
Identifier

Additional local code.

Page 24
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-7 CODED WITH EXCEPTIONS – FOR OBX-5 ONLY (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component

Comments

Second Alternate Text

Additional local text.

Second Name of
Alternate Coding
System

NHSN Condition predicate: Required
if a second alternate identifier is
provided in component 10.

Name

Usage

11

1..199 ST
#

RE

O

RE

-

12

1..12

CE

O

C

-

ID

Value Set

HL70396

NHSN Note-Coding system identifier
for transmitter code instance. May
be the value ‘Transmitter’ or may be
a standard coding system identifier.
13

1..10= ST

RE

O

RE

-

Second Alternate
Version for the coding system
Coding System Version identified in components 12.
ID

14

1..199 ST
=

RE

O

RE

-

Coding System OID

OID for the coding system named in
CWE.3.

15

1..199 ST
=

X

X

X

-

Value Set OID

Not supported.

16

1..8=

X

X

X

-

Value Set Version ID

Not supported.

17

1..199 ST
=

X

X

X

-

Alternate Coding
System OID

Not supported.

18

1..199 ST
=

X

X

X

-

Alternate Value Set
OID

Not supported.

19

1..8=

X

X

X

-

Alternate Value Set
Version ID

Not supported.

DTM

DTM

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 25
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-7 CODED WITH EXCEPTIONS – FOR OBX-5 ONLY (CWE)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Not supported.

Name

Usage

20

1..199 ST
=

X

X

X

-

Second Alternate
Coding System OID

21

1..199 ST
=

X

X

X

-

Second Alternate Value Not supported.
Set OID

22

1..8=

X

X

X

-

Second Alternate Value Not supported.
Set Version ID

DTM

Usage: This version of the CWE is used only with OBX-5. The CWE data type is used where it is necessary to communicate a code, text, coding system and the version
of coding system the code was drawn from. It also allows the communication of an alternate code drawn from another coding system. Many coded fields in this
specification identify coding systems or value sets that must be used for the field. When populating the CWE data types with these values, this guide does
not give preference to the triplet in which the standard code should appear. The receiver is expected to examine the coding system names in components 3
and 6 to determine if it recognizes the coding system.
The CWE data type allows communication of an early form of what has come to be called "null flavors." HL7 2.5.1 refers to these as CWE Statuses, where the values are
drawn from HL7 Table 0353. .The CWE Statuses are not supported in this guide.
Note: This guide pre-adopts the structure of the CWE data type from HL7 Version 2.7. In general, public health surveillance data transmissions are from healthcare
facilities, including laboratories, to local or State health departments, and then to CDC. NHSN is an exception in that healthcare facilities use a single application
to report data directly to CDC. This enables the States to have access to those data, more specifically a selected subset of data entered into NHSN, as soon as they
are stored in the NHSN database. In the future, data may be reported to NHSN by data transmissions that follow the more general model of healthcare to health
department to CDC. In addition, surveillance data submitted to NHSN and other public health systems may be transmitted from a hospital system, Health
Information Exchange (HIE), or some other information broker rather than a single facility. These hospital information system, HIE, or broker intermediaries
may be responsible for mapping local hospital codes to CDC codes and may also have their own local coding system in which at least some codes lack a unique
one-to-one relationship to CDC standard codes. As a result, three different codes may represent the same concept: the facility local code, the transmitter local
code, and the CDC standard code. All analysis at CDC will be performed on the CDC standard code. However, coding validation will require use of the two
local codes. The transmitter code is needed to identify mapping irregularities between facility local codes and CDC standard codes that are attributable to the
process of an intermediary standardizing facility local code for their own use. The triplet code can help CDC meet this need or requirement for data validation.
For this reason, a constrained version of the CWE data type from HL7 Version 2.7 has been pre-adopted for all CE and CWE data types in this guide.

Page 26
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

Example: |302620005^Salmonella group B phase 1 a-e^SCT^Sal^ Salmonella group
B^99LabMicro^20080731|
2.3.6 CX – Extended Composite ID with Check Digit
Table 2-8. Extended Composite Id With Check Digit (CX)

TABLE 2-8. EXTENDED COMPOSITE ID WITH CHECK DIGIT (CX)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

The ID Number component combined
with the Assigning Authority
component must uniquely identify the
associated object, i.e., any object
with which the field is associated.
Note - despite the component being
named “ID Number” this component
is an ST string data type, not
numeric, so the component is not
limited to just numbers.

Name

Usage

1

1..15= ST

R

R

R

R

ID Number

2

1..4=

ST

O

O

O

O

Check Digit

3

3..3

ID

O

O

O

O

HD

R

R

R

R

ID

R

R

R

R

4

5

2..5

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

HL7 0061

Check Digit Scheme
Assigning Authority

HL70203

The Assigning Authority component is
used to identify the system,
application, organization, etc. that
assigned the ID Number in
component 1.

Identifier Type Code

Page 27
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-8. EXTENDED COMPOSITE ID WITH CHECK DIGIT (CX)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

The Assigning Facility identifies the
place or location that the ID Number
was assigned for use.

Name

Usage

6

HD

RE

RE

O

O

Assigning Facility

7

DT

O

O

O

O

Effective Date

8

DT

O

O

O

O

Expiration Date

9

CWE

O

O

O

O

Local

Assigning Jurisdiction

CWE

O

O

O

O

Local

Assigning Agency or
Department

10

3..3

Usage: The CX data type is used to carry identifiers. This guide requires that all identifiers be accompanied by assigning authorities, and that all identifiers carry an
identifier type. This method allows the exchange of unique identifiers for the associated object across organizational and enterprise boundaries, enabling broad
interoperability.
Although the Identifier Type Code component is required, it is not a part of the actual identifier. Rather, it is metadata about the identifier. The ID Number and
Assigning Authority component, together, constitute the actual identifier. The reason for this requirement is to promote forward compatibility with HL7 Version 3
identifiers, where there is no concept of identifier type codes. Although this guide does not deal directly with Version 3 constructs, it is intended to work within
the context of the HITSP Interoperability constructs, which work with both Version 2.x messaging and Version 3 constructs.

Example:

Page 28
February 2010

|36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.840.1.113883.19.3.2.1&ISO|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.7 DR – Date/Time Range
Table 2-9. Date/Time Range (DR)

TABLE 2-9. DATE/TIME RANGE (DR)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Usage

1

TS

R

RE

R

RE

Range Start Date/Time

2

TS

RE

RE

O

RE

Range End Date/Time

Example:

Comments

|200806021328.0001-0005^200906021328.0001-0005|

2.3.8 DT – Date
Table 2-10. Date (DT)

TABLE 2-10. DATE (DT)
SEQ

1

LEN

4..8

Example:

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

Date

Format: YYYY[MM[DD]]

Name

Usage
R

|20080602|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 29
February 2010

Chapter 2: Messaging Infrastructure

2.3.9 DTM – Date/Time
Table 2-11. Date/Time (DTM)

TABLE 2-11. DATE/TIME (DTM)
SEQ

1

LEN

4..24

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

Date/Time

Format:
YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]
]]]]]][+/-ZZZZ]

Name

Usage
R

Usage: It is strongly recommended that the time zone offset always be included in the DTM particularly if the granularity includes hours, minutes, seconds, etc. Specific
fields in this implementation guide may require Date/Time to a specific level of granularity, which may require the time zone offset.

Example:

|200806021328.0001-0005|

2.3.10 ED – Encapsulated Data
Table 2-12. Encapsulated Data (ED)

TABLE 2-12. ENCAPSULATED DATA (ED)
SEQ

LEN

1

Page 30
February 2010

DT

HD

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

RE

Receiver

RE

Receiver

-

EHR

Value Set

Component
Name

Comments

Usage
RE

Source Application

Identifier of the application that is
the source of the encapsulated
data.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-12. ENCAPSULATED DATA (ED)
SEQ

2

LEN

4..11

DT

ID

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

-

EHR

Value Set

Component

ELR HL70834
(from HL7
2.7)

Type of Data

Name

Usage
R

4

1..32=

1..6

ID

ID

RE

R

RE

R

-

-

RE

R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Identifier of the type of data found
in component 5.
See section 6.1.1.5 for details of
HL70834.

Lab to EHR
– HL70191
3

Comments

HL70291
(from HL7
2.7)

Data Subtype

HL70299

Encoding

Identifier of the subtype of data
found in component 5.
See section 6.1.1.2 for details of
HL70291.
Identifier of the type of encoding to
be performed in the data
component

Page 31
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-12. ENCAPSULATED DATA (ED)
SEQ

LEN

5

DT

TX

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

-

EHR

Value Set

Component
Name

Comments

Usage
R

Data

The data in this component must
be properly escaped after
encoding. Receivers will need to
un-escape the text prior to
decoding.
Note that the length 65536 has a
special meaning in HL7, indicating
the length is a “Very Large Number”
Since in this case the Data
component of the ED data type
carries the actually encapsulated
data, this component may be much
larger than 65536. For instance, an
image carried in this data type
might be multi-megabyte in size.

Specific MIME type/MIME subtypes to be supported will be worked out for specific implementations.

Example:

|&2.16.840.1.113883.19.4.6&ISO^multipart^related^A^MIME-Version: 1.0

Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64
--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Page 32
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

Content-ID: <10.12.45567.43>
... Base 64 of base CDA document, which contains
...

...

--HL7-CDA-boundary
Content-ID: <10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG
... Base64 image ...
--HL7-CDA-boundary—
…|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 33
February 2010

Chapter 2: Messaging Infrastructure

2.3.11 EI – Entity Identifier
Table 2-13. Entity Identifier (EI)

TABLE 2-13. ENTITY IDENTIFIER (EI)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component
Name

Comments

Usage

1

1..199 ST
=

R

R

R

R

2

1..20= IS

RE

RE

RE

O

3

1..199 ST
=

R

R

R

R

4

1..6

R

R

R

R

ID

Value Set

Entity Identifier
Local

HL70301

Namespace ID

The coding system for this
component is locally managed.

Universal ID

Must be an OID.

Universal ID Type

Constrained to the value "ISO.".

Usage: The EI data type is used to carry identifiers. This guide requires that all entity identifiers be accompanied by assigning authorities. This allows the exchange of
unique identifiers for the associated object across organizational and enterprise boundaries, enabling broad interoperability.
In the EI data type, the Namespace ID, Universal ID and Universal ID type correspond to the HD data type identified elsewhere. These types, together, are
commonly considered the assigning authority for the identifier. The Entity Identifier and Assigning Authority components, together, constitute the actual
identifier.

Example:

Page 34
February 2010

|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.12 EIP – Entity Identifier Pair
Table 2-14. Entity Identifier Pair (EIP)

TABLE 2-14. ENTITY IDENTIFIER PAIR (EIP)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

EI

RE

O

O

RE

Placer Assigned
Identifier

2

EI

R

R

R

CE

Filler Assigned
Identifier

Lab to EHR Condition predicate:
Component 2 will be required if the
field is OBR-29; otherwise, the
component is RE. This is necessary
to accommodate the use of EIP in
SPM-2

Example:
|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.840.1.113883.19.3.1.6&ISO|
2.3.13 ERL – Error Location
Table 2-15. Error Location (ERL)

TABLE 2-15. ERROR LOCATION (ERL)
SEQ

1

LEN

3..3=

DT

ST

Lab Result

ELR

NHSN

Lab to EHR

Usage

Usage

Usage

Usage

Sender
R

Receiver
R

Receiver
-

Receiver
-

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Value Set

Component

Comments

Segment ID

The 3-character name for the
segment (i.e., PID).

Name

Page 35
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-15. ERROR LOCATION (ERL)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to EHR

Usage

Usage

Usage

Usage

Sender

Receiver

Receiver

Receiver

Value Set

Component
Name

2

1..2=

NM

R

R

-

-

Segment Sequence

3

1..2=

NM

CE

CE

-

-

Field Position

Comments

The field number with the error.
Should not be populated for errors
involving the entire segment.
ELR Condition predicate: This
component is required if components
4, 5 and/or 6 are populated.

4

1..2=

NM

CE

CE

-

-

Field Repetition

The first field repetition is counted a
1.
ELR Condition predicate: This
component is required if the field
identified in components 1, 2, and 3
is a repeating field.

5

1..2=

NM

CE

CE

-

-

Component Number

6

1..2=

NM

RE

RE

-

-

Sub-component
Number

Example:

Page 36
February 2010

ELR Condition predicate: This
component is required if component
6 is populated.

|MSH^1^21^1^2|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.14 FC – Financial Class
Table 2-16. Financial Class (FC)

TABLE 2-16. FINANCIAL CLASS (FC)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component

Comments

Local

Financial Class Code

The financial class code assigned to
the patient locally.

Name

Usage

1

IS

R

R

-

-

2

TS

O

O

-

-

Example:

Value Set

Effective Date

|X^20090602|

2.3.15 FN – Family Name
Table 2-17. Family Name (FN)

TABLE 2-17. FAMILY NAME (FN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

1..50# ST

R

R

R

R

Surname

2

1..20# ST

O

O

O

O

Own Surname Prefix

3

1..50# ST

O

O

O

O

Own Surname

4

1..20# ST

O

O

O

O

Surname Prefix From
Partner/Spouse

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 37
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-17. FAMILY NAME (FN)
SEQ

5

LEN

DT

1..50# ST

Example:

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

O

Receiver

O

Receiver

O

EHR

Value Set

Component
Name

Comments

Usage
O

Surname From
Partner/Spouse

|Admit|

2.3.16 FT – Formatted Text Data
Table 2-18. Formatted Text Data (FT)

TABLE 2-18. FORMATTED TEXT DATA (FT)
SEQ

LEN

DT

1..655 36

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component
Name

Comments

Usage
R

Formatted Text Data

Usage: The FT data type allows use of the formatting escape sequences documented in HL7 Version 2.5.1, Chapter 2, Section 2.7 - Use of Escape Sequences in Text
Fields. In this ELR Profile, the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters. These are
the escape sequences for the message delimiters (i.e., |^&~\).

Example:

Page 38
February 2010

|Culture \T\ Sensitivity Report …|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.17 HD – Hierarchic Designator
Table 2-19. Hierarchic Designator (HD)

TABLE 2-19. HIERARCHIC DESIGNATOR (HD)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Component

Comments

Local

Namespace ID

The coding system for this
component is locally managed.

Universal ID

Must be an OID except for ELR
Receiver for MSH-3 where a CLIA
identifier is allowed.

Universal ID Type

Constrained to the value ‘ISO’ except
for ELR Receiver for MSH-4 where
the value ‘CLIA’ is allowed..

Name

Usage

1

1..20= IS

RE

RE

RE

O

2

1..199 ST
=

R

R

R

R

3

1..6

R

R

R

R

ID

Value Set

HL70301

Usage: The HD data type is used directly to identify objects such as applications or facilities. It is used also as a component of other data types, where it is typically an
assigning authority for an identifier. Where this capability is used in this specification, that usage is described separately. Note that the HD data type has been
constrained to carry an OID identifying an application, a facility, or an assigning authority. The only exception to the use of OID’s for the HD is for the ELR
Receiver profile for MHS-4 (Sending Facility)

Example:

|Lab^2.16.840.1.113883.19.3.1.1^ISO|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 39
February 2010

Chapter 2: Messaging Infrastructure

2.3.18 ID – Coded Value for HL7-Defined Tables
Table 2-20. Coded Value For HL7-Defined Tables (ID)

TABLE 2-20. CODED VALUE FOR HL7-DEFINED TABLES (ID)
SEQ

1

LEN

DT

1..15= -

Example:

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component
Name

Comments

Usage
R

Coded Value for HL7Defined Tables

|ABC|

2.3.19 IS – Coded Value for User-Defined Tables
Table 2-21. Coded Value For User-Defined Tables (IS)

TABLE 2-21. CODED VALUE FOR USER-DEFINED TABLES (IS)
SEQ

1

LEN

DT

1..20= -

Example:

Page 40
February 2010

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component
Name

Comments

Usage
R

Coded Value for UserDefined Tables

|XYZ|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.20 MSG – Message Type
Table 2-22. Message Type (MSG)

TABLE 2-22. MESSAGE TYPE (MSG)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Usage

1

3..3

ID

R

R

R

R

HL70076

Message Code

2

3..3

ID

R

R

R

R

HL70003

Trigger Event

3

3,7

ID

R

R

R

R

HL70354

Message Structure

Example:

Comments

|ORU^R01^ORU_R01|

2.3.21 NDL - Name With Date And Location
Table 2-23. Name With Date And Location (NDL)

TABLE 2-23. NAME WITH DATE AND LOCATION (NDL)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

CNN

R

R

-

-

Name

2

TS

X

X

-

-

Start Date/time

Not supported.

3

TS

X

X

-

-

End Date/time

Not supported.

4

1..20= IS

X

X

-

-

HL70302

Point of Care

Not supported.

5

1..20= IS

X

X

-

-

HL70303

Room

Not supported.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 41
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-23. NAME WITH DATE AND LOCATION (NDL)
SEQ

6

LEN

DT

1..20= IS

7

HD

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

HL70304

Bed

Not supported.

Facility

Not supported.

Name

Usage

X

X

-

-

X

X

-

-

8

1..20= IS

X

X

-

-

HL7306

Location Status

Not supported.

9

1..20= IS

X

X

-

-

HL70305

Person Location Type

Not supported.

10

1..20= IS

X

X

-

-

HL7307

Building

Not supported.

11

1..20= IS

X

X

-

-

HL7308

Floor

Not supported.

Example:

Page 42
February 2010

|1234&Admit&Alan&A&III&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.22 NM – Numeric
Table 2-24. Numeric (NM)

TABLE 2-24. NUMERIC (NM)
SEQ

1

LEN

1..16

Example:

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

Numeric

HL7 allows only ASCII numeric
characters as well as an optional
leading plus or minus sign and an
option decimal point. Note that use
of scientific notation for numbers is
not supported by this data type.

Value Set

Component

Comments

Name

Usage
R

|123.4|

2.3.23 PL – Person Location
Table 2-25. Person Location (PL)

TABLE 2-25. PERSON LOCATION (PL)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Name

Usage

1

1..20= IS

RE

O

RE

O

HL70302

Point of Care

2

1..20= IS

RE

O

RE

O

HL70303

Room

3

1..20= IS

RE

O

RE

O

HL70304

Bed

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 43
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-25. PERSON LOCATION (PL)
SEQ

LEN

4
5

DT

HD
1..20= IS

6

CWE

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

O

O

O

O

Facility

O

O

O

O

HL70306

Location Status

RE

O

RE

RE

HL70305

Person Location Type

NHSN –
PH_Healthcar
eServiceLoc_
HL7_V3
7

1..20= IS

O

O

O

O

HL70307

Building

8

1..20= IS

O

O

O

O

HL70308

Floor

9

1..199 ST
#

O

O

O

O

Location Description

10

EI

O

O

O

O

Comprehensive
Location Identifier

11

HD

O

O

O

O

Assigning Authority for
Location

CWE data type is pre-adopted from
HL7 Version 2.7 to support NHSN
requirements. This will require a
change to Lab to EHR IG. NHSN
uses the HL7 V3 Healthcare Service
Location codes for this component.

Use of the PL data type in this implementation guide is optional. All fields using the data type are either optional or not supported. Specifics on what components of the
PL to use in an implementation would need to be determined by the implementers.

Example: |4E^234^A^Good Health Hospital&2.16.840.1.113883.19.3.2.3&ISO^N^N^Building
1^4^Nursing unit 4 East^1234&&2.16.840.1.113883.19.3.2.3&ISO^&2.16.840.1.113883.19.3.2.3&ISO|

Page 44
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.24 PRL – Parent Result Link
Table 2-26. Parent Result Link (PRL)

TABLE 2-26. PARENT RESULT LINK (PRL)
SEQ

1

LEN

DT

CWE

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Laboratory
Observation
Value Set

Parent Observation
Identifier

Identifier of the OBX-3 Observation
ID of the parent result. Typically, this
is used in microbiology results where
the sensitivities are linked to the
specific culture OBX where the
organism was identified.

Name

Usage

R

R

RE

R

2

1..20= ST

RE

RE

RE

RE

Parent Observation
Sub-Identifier

Identifier of the OBX-4 Observation
Sub-ID associated with the OBX-3
Observation ID of the parent result.
Typically, this is used in microbiology
results where the sensitivities are
linked to the specific culture OBX
where the organism was identified.
The combination of OBX-3 and OBX4 must be unique within a particular
OBR.

3

TX

RE

RE

RE

RE

Parent Observation
Value Descriptor

Taken from the OBX-5 of the parent
result. If OBX-5 contains coded data,
this will be the value of the text
component of the CE or CWE data
type or the original text component of
the CWE data type when there is no
coded component.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 45
February 2010

Chapter 2: Messaging Infrastructure
Usage: See Appendix A, of this document for details on how this data type and the EIP data type are used in parent/child result linking. Use of data type CWE for
sequence 1 reflects a pre-adoption of HL7 Version 2.6 standards.

Example:

|625-4&Bacteria identified:Prid:Pt:Stool:Nom:Culture&LN^1^Campylobacter jejuni|

2.3.25 PT – Processing Type
Table 2-27. Processing Type (PT)

TABLE 2-27. PROCESSING TYPE (PT)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Usage

1

1..1

ID

R

R

R

R

HL70103

Processing ID

2

1..1

ID

O

O

O

O

HL70207

Processing Mode

Example:

Page 46
February 2010

Comments

|P^T|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.26 RP – Reference Pointer
Table 2-28. Reference Pointer (RP)

TABLE 2-28. REFERENCE POINTER (RP)
SEQ

1

LEN

DT

1..999 ST
#

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

-

EHR

Value Set

Component

Comments

Pointer

Pointer to the object. For URIs, it
contains the path and query parts.

Name

Usage
R

Example:
/phin/library/documents/pdf/DRAFT_
PHIN_ORU_ELR_v2.5.1_20061221.
pdf
2

HD

R

R

-

R

Application ID

Unique identifier of the application
that holds the object being pointed to.
For URIs, it contains the scheme and
authority parts.
Note that the HD data type used for
this component is specialized for use
in the RP data type, and is different
that what is defined in section 2.3.17
(HD).

2.1

1..20= IS

O

O

-

O

2.2

1..199 ST
=

R

R

-

R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Local

Namespace ID
Universal ID

This component is restricted to a
universal resource identifier (URI).
For URIs, contains the scheme and
authority parts. Example:
http://www.cdc.gov

Page 47
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-28. REFERENCE POINTER (RP)
SEQ

2.3

3

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Name

Usage

1..6

ID

R

R

-

R

HL70301

Universal ID Type

This component is constrained to
support only universal Resource
Identifier. Literal value: ‘URI’

4..11

ID

RE

RE

-

RE

HL70834 (2.7)

Type of Data

Identifier of the type of data pointed
to. For the URI example referenced
above, this is '"application."
See section 6.1.1.5 For details of
HL70834.

4

1..32= ID

RE

RE

-

RE

HL70291 (2.7)

Subtype

Identifier of the subtype of data
pointed to. For the URI example
above, this is "pdf," indicating
portable document format.
See section 6.1.1.2 for details of
HL70291.

Usage: The field uses the RP data type to allow communication of pointers to images, sound clips, XML documents, HTML markup, etc. The RP data type is used when
the object being pointed to is too large to transmit directly.
This specification defines the mechanism for exchanging pointers to objects, but does not address the details of applications actually accessing and retrieving the
objects over a network.
This guide constrains this data type to support only Universal Resource Identifiers (URI). See http://ietf.org/rfc/rfc2396.txt for a detailed definition. The
general format of a URI is in the form ://?. The scheme and authority portions appear in the Application ID component,
Universal ID subcomponent. The path and query portion of the URI appear in the Pointer component of the RP data type.

Example:
|?requestType=WADO\T\study=1.2.840.113848.5.22.9220847989\T\series=1.2.840.113848.5.22.9220847
Page 48
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

98.4\T\object=1.2.840.113848.5.22.922084798.4.5^&https://www.pacs.poupon.edu/wado.jsp&URI^imag
e^jpeg |
2.3.27 SAD – Street Address
Table 2-29. Street Address (SAD)

TABLE 2-29. STREET ADDRESS (SAD)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

1..120 ST
#

R

R

R

R

Street or Mailing
Address

2

1..50# ST

O

O

O

O

Street Name

3

1..12# ST

O

O

O

O

Dwelling Number

Usage: The SAD is used only as a component of the XAD data type.

Example:

|2222 Home Street|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 49
February 2010

Chapter 2: Messaging Infrastructure

2.3.28 SI – Sequence ID
Table 2-30. Sequence ID (SI)

TABLE 2-30. SEQUENCE ID (SI)
SEQ

1

LEN

1..4=

Example:

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

Sequence ID

Non-negative integer up to 9999.
May be further constrained to limit
the number of times a segment may
repeat.

Name

Usage
R

|1|

2.3.29 SN – Structured Numeric
Table 2-31. Structured Numeric (SN)

TABLE 2-31. STRUCTURED NUMERIC (SN)
SEQ

1

LEN

1..2

2

Page 50
February 2010

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Component that must be one of ">"
or "<" or ">=" or "<=" or "=" or "<>".
This component defaults to "=" if
empty.

Name

Usage

ST

RE

RE

RE

RE

Comparator

NM

RE

RE

RE

RE

Num1

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-31. STRUCTURED NUMERIC (SN)
SEQ

3

LEN

1..1

4

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Component that must be one of "-" or
"+" or "/" or "." or ":".

Name

Usage

ST

RE

RE

RE

RE

Separator/Suffix

NM

RE

RE

RE

RE

Num2

Usage: The SN data type carries a structured numeric result value. Structured numeric values include intervals (^0^-^1), ratios (^1^/^2 or ^1^:^2), inequalities (<^10), or
categorical results (2^+).

Examples:

|^0^-^1|

|^1^/^2|
|^1^:^2|
|<^10|
|2^+|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 51
February 2010

Chapter 2: Messaging Infrastructure

2.3.30 ST – String Data
Table 2-32. String Data (ST)

TABLE 2-32. STRING DATA (ST)
SEQ

LEN

1

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

EHR

Value Set

Component
Name

Comments

Usage

R

R

String Data

Usage: The ST data type is normally used for short text strings. No leading blanks (space characters) are permitted. Trailing blanks are permitted. In this ELR Profile,
the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters. These are the escape sequences for the
message delimiters (i.e., |^&~\).

Example:

|almost any test data at all|

2.3.31 TM – Time
Table 2-33. Time (TM)

TABLE 2-33. TIME (TM)
SEQ

1

LEN

2..16

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

Time

Format: HH[MM[SS[.S[S[S[S]]]]]][+/ZZZZ]

Name

Usage
R

Usage: It is strongly recommended that the time zone offset always be included in the TM. Specific fields in this implementation guide may require time to a specific
level of granularity, which may require the time zone offset.

Page 52
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

Example:

|235959+1100|

2.3.32 TS – Time Stamp
Table 2-34. Time Stamp (TS)

TABLE 2-34. TIME STAMP (TS)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

1

DTM

R

R

R

R

Time

2

ID

X

X

X

X

Degree of Precision

Deprecated as of HL7 Version 2.3.
See component 1 (DTM) for the
current method of designating degree
of precision.

Component

Comments

Example:

|200806021328.0001-0005|

2.3.33 TX – Text Data
Table 2-35. Text Data (TX)

TABLE 2-35. TEXT DATA (TX)
SEQ

1

LEN

DT

-

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Name

Usage
R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Text Data

Page 53
February 2010

Chapter 2: Messaging Infrastructure
Usage: The TX data type is used to carry string data intended for display purposes. It can contain leading blanks (space characters). In this ELR Profile, the only allowed
escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters. These are the escape sequences for the message
delimiters (i.e., |^&~\).

Example:

| leading spaces are allowed.|

2.3.34 VID – Version Identifier
Table 2-36. Version Identifier (VID)

TABLE 2-36. VERSION IDENTIFIER (VID)
SEQ

1

LEN

3..5

DT

ID

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

R

Receiver

R

Receiver

R

EHR

Value Set

Component

Comments

HL70104

Version ID

Restricted to 2.5.1 in this guide.

Name

Usage
R

Literal value: ‘2.5.1’
2

CWE

O

O

O

O

Country Value
Set

Internationalization
Code

3

CWE

O

O

O

O

Local

International Version ID

Example:

Page 54
February 2010

|2.5.1|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.35 XAD – Extended Address
Table 2-37. Extended Address (XAD)

TABLE 2-37. EXTENDED ADDRESS (XAD)
SEQ

LEN

1

DT

SAD

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Usage

RE

RE

O

RE

Street Address

2

1..120 ST
#

RE

RE

O

RE

Other Designation

3

1..50# ST

RE

RE

O

RE

City

4

1..50# ST

RE

RE

RE

RE

State Value
Set

State or Province

5

1..12= ST

RE

RE

RE

RE

Postal Code
Value Set

Zip or Postal Code

6

3..3

ID

RE

RE

RE

RE

Country Value
Set

Country

7

1..3

ID

RE

RE

O

RE

HL70190

Address Type

8

1..50# ST

O

O

O

O

9

1..20= IS

RE

RE

RE

RE

PHVS_County
_FIPS_6-4

County/Parish Code

10

1..20= IS

O

O

O

O

HL70288

Census Tract

11

1..1

O

O

O

O

HL70465

Address
Representation Code

ID

Comments

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Example: Suite 555

In the US, the zip code takes the
form 99999[-9999], while the
Canadian postal code takes the form
A9A9A9.

Other Geographic
Designation
Lab to EHR: No standard value set is
used. FIPS codes may be used.

Page 55
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-37. EXTENDED ADDRESS (XAD)
SEQ

LEN

12

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Deprecated as of HL7 Version 2.5.
See XAD-13 Effective Date and XAD14 Expiration Date components.

Name

Usage

DR

X

X

X

X

Address Validity Range

13

1..8=

TS

O

O

O

O

Effective Date

14

1..8=

TS

O

O

O

O

Expiration Date

Example:

Page 56
February 2010

|4444 Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.36 XCN – Extended Composite ID Number and Name for Persons
Table 2-38. Extended Composite Id Number And Name For Persons (XCN)

TABLE 2-38. EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS (XCN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

The ID Number component combined
with the Assigning Authority
component (component 9) must
uniquely identify the associated
person. Note - despite the
component being named “ID
Number” this component is an ST
string data type, not numeric, so the
component is not limited to just
numbers.

Name

Usage

1

1..15= ST

RE

RE

RE

RE

ID Number

2

FN

RE

RE

RE

RE

Family Name

3

1..30# ST

RE

RE

RE

RE

Given Name

4

1..30# ST

RE

RE

O

RE

Second and Further
Given Names or Initials
Thereof

5

1..20# ST

RE

RE

RE

RE

Suffix (e.g., JR or III)

6

1..20# ST

RE

RE

RE

RE

Prefix (e.g., DR)

7

1..20= IS

O

O

O

O

HL70360

Degree (e.g., MD)

8

1..20= IS

O

O

O

O

HL70297

Source Table

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

I.e., first name.

Page 57
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-38. EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS (XCN)
SEQ

LEN

9

DT

HD

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

CE

Receiver

CE

Receiver

CE

EHR

Value Set

Component

Comments

Assigning Authority

The Assigning Authority component is
used to identify the system,
application, organization, etc. that
assigned the ID Number in
component 1.

Name

Usage
CE

Harmonized condition predicate:
Required if component 1 (ID Number)
is populated.
10

1..5

ID

RE

RE

RE

RE

11

1..4

ST

O

O

O

O

12

3..3

ID

CE

O

O

CE

HL70061

Check Digit Scheme

Lab to EHR Condition predicate:
Required if component 11 (Identifier
Check Digit) is populated.

13

2..5

ID

CE

CE

RE

RE

HL70203

Identifier Type Code

ELR Condition predicate. Required if
component 1 (ID Number) is
populated.

HD

RE

RE

O

O

ID

O

O

O

O

HL70465

Name Representation
Code

16

CE

O

O

O

O

HL70448

Name Context

17

DR

X

X

X

X

ID

O

O

O

O

14
15

18

1..1

1..1

Page 58
February 2010

HL70200

Name Type Code

Defaults to l (legal name) if empty.

Identifier Check Digit

Assigning Facility

Name Validity Range

HL70444

Deprecated as of HL7 Version 2.5.
See XCN-19 Effective Date and
XCN-20 Expiration Date components.

Name Assembly Order

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-38. EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS (XCN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Comments

Usage

19

1..8=

TS

O

O

O

O

Effective Date

20

1..8=

TS

O

O

O

O

Expiration Date

21

1..199 ST
#

RE

RE

RE

RE

Professional Suffix

22

CWE

O

O

O

O

Assigning Jurisdiction

23

CWE

O

O

O

O

Assigning Agency or
Department

Suggest using values from HL7 table
360.

Example:
|1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO
^^^^^^^^MD|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 59
February 2010

Chapter 2: Messaging Infrastructure

2.3.37 XON – Extended Composite Name and Identification Number for Organizations
Table 2-39. Extended Composite Name And Identification Number For Organizations (XON)

TABLE 2-39. EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS (XON)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Organization Name

ELR Condition predicate: Must be
present if there is no Organization
Identifier in component 10. Send it if
you have it.

Name

Usage

1

1..50# ST

CE

CE

-

RE

2

1..20= IS

RE

RE

-

RE

NM

X

X

-

X

ID Number
Check Digit

3
4

1..4=

NM

O

O

-

O

5

3..3

ID

O

O

-

O

HD

CE

CE

-

CE

6

HL70204

HL70061

Organization Name
Type Code
(Deprecated as of HL7 Version 2.5.)
Use XON-10 Organization Identifier.

Check Digit Scheme
Assigning Authority

The Assigning Authority component is
used to identify the system,
application, organization, etc. that
assigned the ID in component 10.
ELR & Lab to EHR Condition
predicate: Required if component 10
(Organization Identifier) is populated.

7

2..5

8

Page 60
February 2010

ID

CE

CE

-

RE

HD

O

O

-

O

HL70203

Identifier Type Code

ELR Condition predicate: Required if
component 10 (Organization
Identifier) is populated.

Assigning Facility

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

TABLE 2-39. EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS (XON)
SEQ

LEN

DT

9

1..1

10

1..20= ST

Example:

ID

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

HL70465

Name Representation
Code

Name

Comments

Usage

O

O

-

O

RE

RE

-

RE

Organization Identifier

|Level Seven Healthcare, Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|

2.3.38 XPN – Extended Person Name
Table 2-40. Extended Person Name (XPN)

TABLE 2-40. EXTENDED PERSON NAME (XPN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Name

Usage

1

FN

CE

RE

CE

RE

Family Name

NHSN Condition predicate: Required
if component 7, name type code, is
anything but “S” (Pseudo name) or
“U” (unknown name).

2

1..30# ST

CE

RE

CE

RE

Given Name

I.e., first name.
NHSN Condition predicate: Required
if component 7, name type code, is
anything but “S” (Pseudo name) or
“U” (unknown name).

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 61
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-40. EXTENDED PERSON NAME (XPN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component
Name

Usage

3

1..30# ST

RE

RE

RE

RE

Second and Further
Given Names or Initials
Thereof

4

1..20# ST

RE

RE

RE

RE

Suffix (e.g., JR or III)

5

1..20# ST

RE

RE

RE

RE

Prefix (e.g., DR)

6

1..20= IS

O

O

RE

O

HL70360

Degree (e.g., MD)

7

1..5

ID

RE

RE

RE

RE

HL70200

Name Type Code

8

1..1

ID

O

O

O

O

HL70465

Name Representation
Code

9

CWE

O

O

O

O

HL70448

Name Context

10

DR

X

X

X

X

ID

O

O

O

O

12

TS

O

O

O

O

Effective Date

13

TS

O

O

O

O

Expiration Date

14

1..199 ST
#

RE

RE

RE

RE

Professional Suffix

11

1..1

Example:

Page 62
February 2010

Comments

Name Validity Range

HL70444

Defaults to l (legal name) if empty.

Deprecated as of HL7 Version 2.5.
See XPN-12 Effective Date and XPN13 Expiration Date components.

Name Assembly Order

Suggest using values from HL7 table
360.

|Admit^Alan^A^III^Dr^^L^^^^^^^MD|

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 2: Messaging Infrastructure

2.3.39 XTN – Extended Telecommunication Number
Table 2-41. Extended Telecommunication Number (XTN)

TABLE 2-41. EXTENDED TELECOMMUNICATION NUMBER (XTN)
SEQ

LEN

1

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Telephone Number

Deprecated as of HL7 Version 2.3.

Name

Usage

ST

X

X

-

-

2

3..3

ID

RE

RE

-

-

HL70201

Telecommunication
Use Code

Should use ‘NET’ if component 4
(Email Address) is present.

3

2..8

ID

RE

RE

-

-

HL70202

Telecommunication
Equipment Type

Should use ‘Internet’ if component 4
(Email Address) is present.

4

1..199 ST
=

CE

CE

-

-

Email Address

ELR Condition predicate: Required if
component 7 (local number) is not
present. Component 4 (Email
Address) must be empty if
component 7 (Local Number) is
present.

5

1..3=

NM

CE

CE

-

-

Country Code

ELR Condition predicate: This
component is required or empty (RE)
if component 7 (Local Number) is
present otherwise it must be empty.

6

1..3=

NM

CE

CE

-

-

Area/City Code

ELR Condition predicate: This
component is required or empty (RE)
if component 7 (Local Number) is
present otherwise it must be empty.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 63
February 2010

Chapter 2: Messaging Infrastructure

TABLE 2-41. EXTENDED TELECOMMUNICATION NUMBER (XTN)
SEQ

LEN

DT

Lab Result

ELR

NHSN

Lab to

Usage

Usage

Usage

Receiver

Sender

Receiver

Receiver

EHR

Value Set

Component

Comments

Name

Usage

7

1..9=

NM

CE

CE

-

-

Local Number

ELR Condition predicate: Required if
component 4 (Email Address) is not
present. Component 7 (Local
Number) must be empty if
component 4 (Email Address) is
present.

8

1..5=

NM

CE

CE

-

-

Extension

ELR Condition predicate: This
component is required or empty (RE)
if component 7 (Local Number) is
present otherwise it must be empty.

9

1..199 ST
#

RE

RE

-

-

Any Text

For example: “Regular hours 8 am to
5 pm.”

10

1..4=

ST

X

X

-

-

Extension Prefix

Not supported.

11

1..6=

ST

X

X

-

-

Speed Dial Code

Not supported.

12

1..199 ST
#

X

X

-

-

Unformatted Telephone Not supported.
number

Usage: Note that component 4 (Email Address) and component 7 (Local Number) are mutually exclusive. You must populate one or the other, but not both in a single
repeat of this data type.

Example:

|^PRN^PH^^1^555^5552003|

|^NET^Internet^[email protected]|

Page 64
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

3. Message Profile – Public Health
Laboratory Messaging
3.1 USE CASE MODEL
Table 3-1. Use Case: Laboratory To Public Health

TABLE 3-1. USE CASE: LABORATORY TO PUBLIC HEALTH
Item
Description

Detail
The Public Health Laboratory Messaging Use Case focuses on the use case describing the transmission of laboratory-reportable findings to appropriate local, state,
territorial, and federal health agencies using the HL7 2.5.1 ORU message. It includes optional acknowledgments of receipt of transactions. The use case does allow
the optional use of batch processing to transmit results. It does not cover querying patient demographics or querying laboratory results. The use case does cover
reporting of healthcare associated infection (HAI) related microbiology results to the National Healthcare Safety Network (NHSN).
The goal of the use case is to provide safe, reliable delivery of reportable laboratory results to public health. If PHIN MS is used for transport, then use of the HL7
Acknowledgments may be un-necessary, although PHIN MS does not ensure that the payload conforms to HL7 formatting rules, it does provide safe and reliable
transport. The use case does not cover reporting of laboratory results from one public health jurisdictional entity to another.
This use case excludes the situation where public health is the originator of the order for testing. The use case for public health laboratory test orders and reporting of
related results is sufficiently different to warrant a distinct use case. The APHL/CDC PHLIP project is directly addressing this use case.
This use case is not intended to cover reporting of results to Cancer Registries. This use case is restricted individual living subjects (persons and animals).

Actors

Laboratory Result Sender – The laboratory result sender actor is an application capable of transmitting the results of laboratory testing on specimens. This may be the
laboratory itself or some aggregator of laboratory result data. The laboratory result sender application is capable of transmitting the results of laboratory testing to a
receiver, optionally capable of batching result messages and optionally capable of receiving HL7 acknowledgments. If the Laboratory Result Sender is an actual
laboratory system, it is often referred to as “Filler.”
The Laboratory Result Sender application is an HL7 Application as defined by HL7 Version 3 Standard: Abstract Transport Specification, Normative Edition 2009. One
point of confusion is what role data aggregators play in this use case. In typical circumstances, a data aggregator is considered an HL7 Application, and as such
directly takes on the role of Laboratory Result Sender for this use case. The HL7 Version 3 Standard: Abstract Transport Specification, Normative Edition 2009 also
describes several roles typically played by interface engines, include gateway, bridge and intermediary roles. The abstract transport specification considers the
gateway role to be an HL7 Application, so for this use case an interface engine playing the gateway role and originating the transaction in this IG would be a

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 65
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging

TABLE 3-1. USE CASE: LABORATORY TO PUBLIC HEALTH
Item

Detail
Laboratory Result Sender actor.
Laboratory Result Receiver – The laboratory result receiver is an application capable of receiving results of laboratory testing, optionally transmitting an
acknowledgment and optionally capable of receiving a batch of laboratory results and transmitting a batch acknowledgment. The laboratory result receiver may be
associated with the local, state, territorial and federal health agencies that require access to the results. In the use case, the laboratory result receiver is identified as
the "public health jurisdictional entity." Note that the Laboratory Result Receiver should not be confused with the “Placer” of the laboratory order that the laboratory
results are associated. The placer of the order is typically a provider who is responsible for treating the patient. In this case, the Laboratory Result Receiver is an
interested party who receives a copy of the results. There are three specializations for the Laboratory Result Receiver including:
° Electronic Laboratory Result (ELR) Receiver – A Laboratory Result Receiver conforming to the ELR receiver message profile
°

National Healthcare Safety Network (NHSN) Receiver 4 – A Laboratory Result Receiver conforming to the NHSN receiver message profile

°

Lab to EHR Receiver - A Laboratory Result Receiver conforming to the Lab to EHR 5 receiver message profile

It should be noted that the latter two actors, NHSN Receiver and the Lab to EHR Receiver are included in this guide for comparison purposes only. Other guides are
the source of truth for these profiles.
Assumptions

The following assumptions are preconditions for the use of this profile:
Each public health jurisdictional entity has previously defined the reportable conditions appropriate to its jurisdiction.
Laboratory result senders are responsible for the setup of their system with the reportable conditions appropriate to its jurisdiction.

Business
Rules

The following Business Rule applies to the use of this profile:
Batch processing may optionally be used as described in the Transmit Batch Message Use Case, 2008 (see References).

The Send Laboratory Use Case Model has two primary participating actors, the Laboratory Result Sender and the Laboratory Result Receiver. The use case has three “child”
use case, Preliminary Result, Final Result and Corrected Result.

4
5

The NHSN Receiver profile has been fully documented in a separate guide and was balloted in the January 2010 ballot cycle.
See HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR, Release 1. Available from the HL7 Members download at:
http://www.hl7.org/memonly/downloads/home_download.cfm

Page 66
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

Figure 3-1. Send Laboratory Result Use Case Model

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 67
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging

3.2 DYNAMIC INTERACTION MODEL

Figure 3-2. Activity Diagram for Send Laboratory Result Use Case – Acknowledgment Required

Page 68
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

Figure 3-3. Activity Diagram for Send Laboratory Result Use Case - Without Acknowledgment

Figure 3-4. Activity Diagram for Send Laboratory Result Use Case - Batch

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 69
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging

3.3 DYNAMIC DEFINITIONS
Three dynamic definitions are provided to support cases where acknowledgments are required, not used, and batch messaging.

Table 3-2. Dynamic Definition – Individual Transactions With Acknowledgments

TABLE 3-2. DYNAMIC DEFINITION – INDIVIDUAL TRANSACTIONS WITH ACKNOWLEDGMENTS
Item

Value

Profile ID

PHLabReport-Ack

HL7 Version

2.5.1

Accept Acknowledgement

AL – Always

Application Acknowledgement

Refer to HL7 Table 0155 – Accept/Application Acknowledgment conditions in section 6.1.1.2 for valid values.

Acknowledgement Mode

Immediate

Profile Type

Constrainable Profile

Message Types

ORU^R01^ORU_R01, ACK^R01^ACK

Encoding

ER7 (required)
2.5.1 XML (optional)
Table 3-3. Dynamic Definition - Individual Transactions Without Acknowledgments

TABLE 3-3. DYNAMIC DEFINITION - INDIVIDUAL TRANSACTIONS WITHOUT ACKNOWLEDGMENTS
Item

Value

Profile ID

PHLabReport-NoAck

HL7 Version

2.5.1

Accept Acknowledgement

NE – Always

Application Acknowledgement

NE – Always

Acknowledgement Mode

Immediate

Page 70
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

TABLE 3-3. DYNAMIC DEFINITION - INDIVIDUAL TRANSACTIONS WITHOUT ACKNOWLEDGMENTS
Item

Value

Profile Type

Constrainable Profile

Message Types

ORU^R01^ORU_R01

Encoding

ER7 (required)
2.5.1 XML (optional)
Table 3-4. Dynamic Definition - Batch Transactions

TABLE 3-4. DYNAMIC DEFINITION - BATCH TRANSACTIONS
Item

Value

Profile ID

PHLabReport-Batch

HL7 Version

2.5.1

Accept Acknowledgement

NE – Never

Application Acknowledgement

NE – Never

Acknowledgement Mode

NA

Profile Type

Constrainable Profile

Message Types

ORU^R01^ORU_R01, Batch Wrapper.

Encoding

ER7 (required)
2.5.1 XML (optional)

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 71
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging

3.4 INTERACTIONS
Table 3-5. Interactions – Individual Transaction With Acknowledgments

TABLE 3-5. INTERACTIONS – INDIVIDUAL TRANSACTION WITH ACKNOWLEDGMENTS
Lab

ELR

NHSN

Lab to

Usage

Usage

Usage

Usage

Message Type

Receiver Action

Sender

C6

O

R

ORU^R01^ORU_R01

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Sender

Event

Description

Preliminary
Result

Preliminary: A verified
early result is available;
final results not yet
obtained

R

Final Result

Final results; results
stored and verified. Can
be changed only with a
corrected result.

R

Correction to results

R

Correction

Receiver Receiver EHR

R

R

Order
Received

Order received; specimen O
not yet received

O

Specimen
Received

No results available;
specimen received,
procedure incomplete

O

O

Procedure
Scheduled

O
No results available;
procedure scheduled, but
not done

6

O

R

R

O

O

O

R

R

O

O

O

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

Data

Values
OBR-25=P

OBR-25=F

OBR-25=C

OBR-25=O

OBR-25=I

OBR-25=S

Conditional on certain reportable conditions and also dependent upon individual state laws/regulations.

Page 72
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

TABLE 3-5. INTERACTIONS – INDIVIDUAL TRANSACTION WITH ACKNOWLEDGMENTS

Event

Description

Lab

ELR

NHSN

Lab to

Usage

Usage

Usage

Usage

Message Type

Receiver Action

Sender

O

O

O

ORU^R01^ORU_R01

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

Commit Accept,
Commit Reject or
Commit Error

Laboratory
Result Sender

ORC-1=RE

NA

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Sender

Receiver Receiver EHR

Partial Results Some, but not all, results
Available
available

O

Unverified
Results
Stored

Results stored; not yet
verified

O

No Results
Available

No results available; Order RE
canceled, Testing Not
Done

RE

No Order

No order on record for this X
test. (Used only on
queries)

X

X

X

O

O

O

X

X

O

O

X

X

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

NA

Data

Values
OBR-25=A

OBR-25=R

OBR-25=X

OBR-25=Y

No Patient
Record

No record of this patient.
(Used only on queries)

Commit
Accept

Enhanced mode: Accept R
acknowledgment: Commit
Accept

O

-

R

ACK^R01^ACK

None

MSA-1=CA
Laboratory
Result Receiver

Commit Error Enhanced mode: Accept R
acknowledgment: Commit
Error

O

-

R

ACK^R01^ACK

None

MSA-1=CE
Laboratory
Result Receiver

Enhanced mode: Accept R
acknowledgment: Commit
Reject

O

-

R

ACK^R01^ACK

None

MSA-1=CR
Laboratory
Result Receiver

Commit
Reject

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

OBR-25=Z

Page 73
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging
Table 3-6. Interactions – Individual Transaction Without Acknowledgments/Batch

TABLE 3-6. INTERACTIONS – INDIVIDUAL TRANSACTION WITHOUT ACKNOWLEDGMENTS/BATCH
Lab

ELR

NHSN

Lab to

Usage

Usage

Usage

Usage

Message Type

Receiver Action

Sender

C7

O

R

ORU^R01^ORU_R01

None

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Sender

Event

Description

Preliminary
Result

Preliminary: A verified
early result is available;
final results not yet
obtained

R

Final Result

Final results; results
stored and verified. Can
be changed only with a
corrected result.

R

Correction to results

R

Correction

Receiver Receiver EHR

R

R

Order
Received

Order received; specimen O
not yet received

O

Specimen
Received

No results available;
specimen received,
procedure incomplete

O

O

Procedure
Scheduled

O
No results available;
procedure scheduled, but
not done

O

O

O

Partial Results Some, but not all, results
Available
available

7

R

R
O
O

O

O

R

R
O
O

O

O

ORU^R01^ORU_R01

ORU^R01^ORU_R01
ORU^R01^ORU_R01
ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

None

None
None
None

None

None

Data

Values
OBR-25=P

OBR-25=F

OBR-25=C
OBR-25=O
OBR-25=I

OBR-25=S

OBR-25=A

Conditional on certain reportable conditions and also dependent upon individual state laws/regulations.

Page 74
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

TABLE 3-6. INTERACTIONS – INDIVIDUAL TRANSACTION WITHOUT ACKNOWLEDGMENTS/BATCH
Lab

ELR

NHSN

Lab to

Usage

Usage

Usage

Usage

Message Type

Receiver Action

Sender

O

O

O

ORU^R01^ORU_R01

None

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Laboratory
Result Sender

ORC-1=RE

Sender

Receiver Receiver EHR

Event

Description

Unverified
Results
Stored

Results stored; not yet
verified

No Results
Available

No results available; Order RE
canceled, Testing Not
Done

RE

No Order

No order on record for this X
test. (Used only on
queries)

X

X

X

No Patient
Record

No record of this patient.
(Used only on queries)

O

O

X

X

O

X

X

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

ORU^R01^ORU_R01

ORU^R01^ORU_R01

ORU^R01^ORU_R01

None

NA

NA

Data

Values
OBR-25=R

OBR-25=X

OBR-25=Y

OBR-25=Z

Page 75
February 2010

Chapter 3: Message Profile – Public Health Laboratory Messaging

3.5 REFERENCES
1. HL7 U.S. Realm – Interoperability Specification: Lab Result Message to EHR,
Version 1.0, November 2007
2. Harmonized Use Case for Electronic Health Records (Laboratory Result
Reporting)
3. Implementation Guide for Transmission of Laboratory-Based Reporting of
Public Health Information using version 2.3.1 of Health Level Seven (HL7)
Standard Protocol, March 2005.
4. HL7 Version 3 Standard: Abstract Transport Specification, Normative Edition
2009

Page 76
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 3: Message Profile – Public Health Laboratory Messaging

This page intentionally left blank.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 77
February 2010

Chapter 4: Messages

4. Messages
The following sections detail the structure of each message, including segment name, usage, cardinality and
description. See section 1.4.1 (Message Element Attributes) for a description of the columns in the Abstract
Message Syntax Tables.

Page 78
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

4.1 ORU^R01^ORU_R01
The ORU^R01 message is constrained for transmitting laboratory results from the testing source to Public Health.
Table 4-1. ORU^R01^ORU_R01 Abstract Message Syntax

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard
MSH

[{SFT}]

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Description

Usage

Message Header

[1..1]

R

R

R

R

The message header (MSH) segment contains information
describing how to parse and process the message. This includes
identification of message delimiters, sender, receiver, message
type, timestamp, etc.

Software Segment

[1..*]

R

R

O

O

Each HL7 aware application that touches the message on the way
to the destination application must add a SFT segment for its
application. For instance, PHIN MS is not HL7 aware and would
not be expected to add an SFT. On the other hand, an integration
engine is HL7 aware and would be expected to add an SFT.
The first repeat (i.e., the Laboratory Result Sender actor) is
required. Any other application that transforms the message must
add an SFT segment for that application. Other applications that
route or act as a conduit may add an SFT but are not required to
do so.

PATIENT_RESULT [1..*]
Begin

{

R

R

R

R

The NHSN Receiver profile can receive only 1 Paient_Result
group.

[1..1]

R

R

R

RE

For public health reporting, the patient group is required.

PID

Patient Identification [1..1]

R

R

R

R

The patient identification (PID) segment is used to provide basic
demographics regarding the subject of the testing. The subject
may be a person or animal.

[PD1]

Additional
Demographics

[0..1]

O

O

O

O

[

PATIENT Begin

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 79
February 2010

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard
[{NTE}]

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Notes and
Comments for PID

[0..*]

RE

Receiver

RE

Receiver

O

EHR

Description

Usage
RE

This notes and comments (NTE) segment should contain notes or
comments pertaining to the patient identified in the PID segment.
It should not contain order or result related comments.
The Lab to EHR profile allows only a single NTE currently.

[{NK1}]

Next of
Kin/Associated
Parties

VISIT Begin

[

[0..*]

RE

RE

O

O

[0..1]

RE

RE

O

RE

PV1

Patient Visit

[1..1]

R

R

R

R

[PV2]

Patient Visit –
Additional
Information

[0..1]

RE

O

O

RE

]

VISIT End

]

PATIENT End

Page 80
February 2010

The next of kin (NK1) segment can be used to document the
patient’s next of kin, employer, guardian, etc. Particular
jurisdictions may require the NK1 segment to contain
parent/guardian information when reporting lead testing results for
children. When reporting results of animal testing (for example
testing animals for rabies) the NK1 segment can be used to
identify the owner of the animal.
HL7 requires that the patient visit (PV1) segment be present if the
VISIT group is present.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

ORDER_OBSERVA [1..*]
TION Begin

{

Lab

R

Receiver

R

Receiver

R

EHR

Description

Usage
R

The order group is required and can repeat. This means that
multiple ordered tests may be performed on a specimen.
Snapshot processing of the result message involves processing
as a snapshot all the repeats of the ORDER_OBSERVATION
group together as a group. This is especially important when
dealing with parent/child results (such as cultures and
sensitivities) which will span multiple ORDER_OBSERVATION
groups. All these must be processed from both a message
sender and message receiver perspective as a single snapshot.

[ORC]

Order Common

[0..1]

CE

CE

O

RE

The common order (ORC) segment identifies basic information
about the order for testing of the specimen. This segment
includes identifiers of the order, who placed the order, when it was
placed, what action to take regarding the order, etc.
ELR Condition predicate: The first ORDER_OBSERVATION
group must contain an ORC segment (containing ordering facility
information) if no ordering provider information is present in OBR16 or OBR-17.

OBR

[1..1]

R

R

R

R

[0..*]

RE

RE

O

RE

TIMING_QTY Begin [0..*]

RE

O

O

RE

Timing/Quantity

R

O

O

R

Observations
Request

[{NTE}] Notes and
Comments for OBR
[{
TQ1

[1..1]

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

The observation request (OBR) segment is used to capture
information about one test being performed on the specimen.
Most importantly, the OBR identifies the type of testing to be
performed on the specimen, and ties that information to the order
for the testing.

Although Timing/Quantity may be necessary for orders, it’s not
necessary for result reporting, particularly ELR.

Page 81
February 2010

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result

Receiver

Receiver

EHR

Description

Usage

[0..1]

O

O

O

O

[0..1]

O

O

O

O

[0..*]

CE

CE

CE

CE

TIMING_QTY End

}]
[CTD]
[{

ELR

Usage
Timing/Quantity
Order Sequence

[{TQ2}]

Lab

Contact Data
OBSERVATION
Begin

Multiple results may be associated with an order. There will
always be a single OBX in the results group.
Snapshot processing: Since the OBX segment in 2.5.1 does not
contain a unique instance identifier, it is assumed that the
repeating observation group will contain a complete set of
observations (OBXs) associated with the OBR. Where a single
OBX is being updated, all the OBXs related to the OBR must
accompany the updated OBX, i.e., a full snapshot is sent.
Harmonized condition predicate: May be empty for OBR-25
Result statuses of "O," "I," "S" and "X"; otherwise, it is required.

OBX Observation related
to OBR

[1..1]

R

R

R

R

The observation/result (OBX) segment contains information
regarding a single observation (analyte) result. This includes
identification of the specific type of observation, the result for the
observation, when the observation was made, etc.
For laboratory testing, the OBX is normally reporting the results of
a test performed on a specimen, Because the
ORU^R01^ORU_R01 message structure allows multiple
specimens to be associated with a single OBR, there is no direct
way to tell which specimen a particular OBX is associated with.
There are other HL7 messages for laboratory results where this
ambiguity does not exist, but were not chosen for this
implementation guide.

Page 82
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard

[{NTE}]
}]

-

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Notes and
Comments

[0..*]

Receiver

Receiver

EHR

Usage

RE

RE

RE

RE

The notes and comment (NTE) segment may carry comments
related to the result being reported in the OBX segment.

OBSERVATION
End

[{FTI}]

Financial Transaction [0..*]

O

O

O

O

{[CTI]}

Clinical Trial
Identification

[0..*]

O

O

O

O

CE

CE

C

RE

[{

Description

SPECIMEN Begin [0..*]

The specimen group is conditionally required in the ORU and is
used to carry specimen information that is no longer contained in
the OBR segment. It also provides a place for the specimen
number. Each specimen group documents a single sample. Note
that for ELR, the message has been constrained to support a
single SPECIMEN group per OBR, meaning only a single
specimen can be associated with the OBR.
ELR & NHSN Condition predicate: The specimen group is
required for the parent Order_Observation Group in the message.
ELR & NHSN Cardinality: These profiles currently support a single
SPM segment. Per the harmonization strategy the receiver must
pick from a message instance which repeat they will use for the
profile.

SPM

[1..1]
Specimen
Information related to
OBR

R

R

R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

R

The specimen information (SPM) segment describes the
characteristics of a single sample. The SPM segment carries
information regarding the type of specimen, where and how it was
collected, who collected it, and some basic characteristics of the
specimen.

Page 83
February 2010

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

[{OBX}] Observation related
to Specimen

[0..*]

RE

Receiver

RE

Receiver

O

EHR

Description

Usage
O

The Observation related to Specimen is generally used to report
additional characteristics related to the specimen. It is not used to
report the results of the requested testing identified in OBR-4
(Universal Service ID). The observations associated with the
specimen are typically information that the ordering providing
sends with the order. The laboratory forwards that information as
part of the result message.
One recommended value to report in the OBX related to
Specimen is the age of patient at time of specimen collection.
The appropriate LOINC code for this is 35659-2 (Age at specimen
collection:TimeDif:Pt:^Patient:Qn).
Other possible types of observations include:
Was specimen sent out?
Was it a specimen or isolate?
Id of the specimen/isolate sent for testing
Where was the specimen sent?
Reason for send out?
Implementers will need to provide a list of expected observations
associated with specimen.

}]
}

}

SPECIMEN End
ORDER_
OBSERVATION
End
PATIENT_RESULT
End

Page 84
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

TABLE 4-1. ORU^R01^ORU_R01 ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard
[DSC]

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Continuation Pointer [0..0]

X

Receiver

X

Receiver

X

EHR

Description

Usage
X

Not supported.

4.1.1 Diagram of ORU^R01^ORU_R01
The following diagram shows a simple view of the ORU^R01^ORU_R01 message structure. The green boxes represent the key segments in the HL7 result message and
include the MSH, PID, OBR and OBX segments. The data found in these segments are key to the laboratory report. Data found in the other segments may be important
but are not key to interpreting the message. Note that this diagram does not show repeating elements of the message (repeating groups or segments). It represents the way
in which information in the message is related. Neither does this diagram capture the conditions on when some of the segments must be present in the message. For
instance, there must be an ORC segment present in the message in the first repeat of the ORDER_OBSERVATION group.

Figure 4-1. 2.5.1 ELR Message

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 85
February 2010

Chapter 4: Messages

4.1.2 Comparison with the 2.3.1 ORU^R01
The following diagram shows the structure of the 2.3.1 ELR message.

Figure 4-2. 2.3.1 ELR Message
The message structure for the 2.3.1 ELR message is simpler than the 2.5.1 ELR message described above. There are several reasons for this including the following:
•

The 2.5.1 ELR message adheres strictly to the ORU^R01 message structure described by HL7 in 2.5.1. The 2.3.1 ELR message rearranged some of the groups in the
message to suite ELR purposes. Unfortunately, this approach breaks XML implementations of the HL7 standard.

•

The 2.5.1 ELR message includes new segments introduced by HL7. This includes the SFT and SPM segments. The SFT segment is used to document new
information that was not contained in the original 2.3.1 ELR message. The SPM segment was added by HL7 to replace some fields found in the OBR segment. The
SPM segment provides additional information about the specimen not found in the 2.3.1 message.

•

Support for the PV1 and PV2 segments have been added to the 2.5.1 ELR message. Both segments were part of the underlying HL7 standard for the ORU^R01 in
2.3.1 and 2.5.1. The difference here is that the 2.5.1 ELR has included support for some of this information in the 2.5.1 ELR message based upon states identifying a
need for this information.

•

Additional support for the NTE segment has been added to the 2.5.1 ELR message. NTE’s associated with the PID and OBR were part of the underlying HL7
standard for the ORU^R01 in 2.3.1 and 2.5.1. The difference here is that the 2.5.1 ELR has included support for additional comments in this message based upon
states identifying a need for this information.

Page 86
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

4.2 ACK^R01^ACK
Table 4-2. ACK^R01^ACK Abstract Message Syntax

TABLE 4-2. ACK^R01^ACK ABSTRACT MESSAGE SYNTAX
Segment
in

Name

Cardinality

Standard
MSH

[{SFT}]

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Description

Usage

Message Header

[1..1]

R

R

-

R

The message header (MSH) segment contains information
describing how to parse and process the message. This includes
identification of message delimiters, sender, receiver, message
type, timestamp, etc.

Software Segment

[1..*]

R

R

-

O

Each HL7 aware application that touches the message on the way
to the destination application must add a SFT segment for its
application. For instance, PHIN MS is not HL7 aware and would
not be expected to add an SFT. On the other hand, an integration
engine is HL7 aware and would be expected to add an SFT.
The first repeat (i.e., the originator) is required. Any other
application that transforms the message must add an SFT
segment for that application. Other applications that route or act
as a conduit may add an SFT but are not required to do so.

MSA

Message
Acknowledgment

[1..1]

R

R

-

R

[{ ERR }]

Error

[0..*]

CE

CE

-

C

ELR & Lab to EHR Condition predicate: Required when MSA-1 is
not "AA" or "CA."

4.3 HL7 BATCH PROTOCOL
Messages for this profile may be sent as part of a batch, using the HL7 Batch Protocol. The frequencies of batch transmissions are left to specific implementations.
Batches may be sent more often if the message size or resource requirements dictate. It should be noted that the Lab to EHR profile makes no mention of batch protocol,
so no usage has been defined here for the Lab to EHR Receiver.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 87
February 2010

Chapter 4: Messages
Table 4-3. Batch Abstract Message Syntax

TABLE 4-3. BATCH ABSTRACT MESSAGE SYNTAX
Segment Name
in

Cardinality

Standard

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Description

Usage

[FHS]

File Header Segment

[1..1]

R

R

R

-

File header required.

{

--- BATCH begin

[1..1]

R

R

R

-

One batch per file supported.

[BHS]

Batch Header Segment [1..1]

R

R

R

-

One batch per file supported.

{[

--- MESSAGE begin

[1..*]

R

R

R

-

One or more messages per batch supported.

(one or more HL7
messages)

[1..1]

R

R

R

-

MSH
....

-

....

-

....

-

]}

--- MESSAGE end

[BTS]

Batch Trailer Segment [1..1]

}

--- Batch end

[FTS]

File Trailer Segment

Page 88
February 2010

R

R

R

-

[1..1]

R

R

R

-

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 4: Messages

This page intentionally left blank.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 89
February 2010

Chapter 5: Segment and Field Descriptions

5.Segment and Field Descriptions
This messaging guide provides notes for supported fields. The following format is used in this document for listing and defining message segments and fields. First, the
message segment use is defined and then a segment attribute table listing all fields defined in the segment is shown. See section 1.4.1 (Message Element Attributes) for a
description of the columns in the Segment Attribute Tables.

5.1 MSH – MESSAGE HEADER SEGMENT
The Message Header Segment (MSH) contains information describing how to parse and process the message. This includes identification of message delimiters, sender,
receiver, message type, timestamp, etc.
Table 5-1. Message Header Segment (MSH)

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

1

1..1

ST

[1..1]

R

Receiver

R

Receiver

R

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
R

Field Separator

Character to be used as the field
separator for the rest of the message.
Literal value: ‘|’ [ASCII (124)].

2

4..5

ST

[1..1]

R

R

R

R

Encoding
Characters

Four characters, always appearing in the
same order: |^~\&#|.
Literal value: ‘^~\&#’.

3

HD

[1..1]

R

R

R

RE

Sending
Application

Field that may be used to identify the
sending application uniquely for
messaging purposes.
For this field only, if all three components
of the HD are valued, the first component
defines a member in the set defined by
the second and third components.

Page 90
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

4

HD

[1..1]

R

Receiver

R

Receiver

R

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
R

Sending Facility

Field that uniquely identifies the facility
associated with the application that plays
the Laboratory Result Sender Actor (see
section 3.1 Use Case Model) that sends
the message. If acknowledgments are in
use, this facility will receive any related
acknowledgment message.
Lab Result Sender Profile: For
harmonization across all receiver profiles,
use of an OID for this field is
recommended.
ELR Receiver Profile: For laboratories
originating messages, the CLIA identifier is
allowed for the Universal ID component of
the HD data type. Non-laboratory facilities
taking on the Laboratory Result Sender
actor role will use an OID for this field.

5

HD

[1..1]

R

R

O

RE

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Receiving
Application

Field that may be used to identify the
receiving application uniquely for
messaging purposes. For this field only, if
all three components of the HD are
valued, the first component defines a
member in the set defined by the second
and third components.

Page 91
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

6

HD

[1..1]

R

R

R

RE

Receiving Facility Field that uniquely identifies the facility for
the application that plays the Laboratory
Result Receiver Actor (see section 3.1
Use Case Model) and receives the
message. If acknowledgments are in use,
this facility originates any related
acknowledgment message.

7

TS

[1..1]

R

R

R

R

Date/Time Of
Message

Field containing the date/time the
message was created by the sending
system. Format:
YYYYMMDDHHMMSS[.S[S[S[S]]]]+/ZZZZ. Note that the time zone offset is
required, and the minimum granularity is
to the second, although more precise time
stamps are allowed.

8

1..40= ST

[0..1]

O

O

O

O

Security

Not supported.

[1..1]

R

R

R

R

Message Type

For the result message Literal Value:
‘ORU^R01^ORU_R01’.

9

MSG

For the acknowledgement message Literal
Value: ‘ACK^R01^ACK’.

Page 92
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

10

1..199= ST

[1..1]

R

Receiver

R

Receiver

R

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
R

Message Control String that uniquely identifies the
ID
message instance from the sending
application. Example formats for
message control IDs include GUID,
timestamp plus sequence number, OID
plus sequence number or sequence
number. The important point is that
care must be taken to insure that the
message control id is unique. The
sending application (MSH-3) plus
MSH-10 (message control id) needs to
be globally unique.

11

PT

[1..1]

R

R

R

R

Processing ID

Field that may be used to indicate the
intent for processing the message, such
as "T" (training,) "D" (debug,) or "P"
(production.)

12

VID

[1..1]

R

R

R

R

Version ID

HL7 version number used to interpret
format and content of the message. For
this message, the version ID will always
be Literal Value: 2.5.1.
Note that receivers must examine MHS-21
(Message Profile Identifier) to understand
which message profile the message
instance conforms with.

13

NM

[0..1]

O

O

O

O

Sequence
Number

14

1..180= ST

[0..1]

O

O

O

O

Continuation
Pointer

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 93
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

15

2..2

ID

[0..1]

CE

CE

CE

CE

HL70155

Accept
Harmonized condition predicate: Required
Acknowledgment when MSH-21 profile id is PHLabReportType
Ack or USLabReport, otherwise it may be
empty or “NE”.

16

2..2

ID

[0..1]

CE

CE

CE

CE

HL70155

Application
Harmonized condition predicate: Required
Acknowledgment when MSH-21 profile id is PHLabReportType
Ack or USLabReport, otherwise it may be
empty or “NE”. Refer to 6.1.1.2– HL7
Table 0155 – Accept/Application
Acknowledgment Conditions for valid
values.

17

3..3

ID

[0..1]

R

O

R

O

Country
Value Set

Country Code

18

5..15

ID

[0..*]

O

O

O

O

HL70211

Character Set

CWE

[0..1]

O

O

O

O

ID

[0..1]

O

O

O

O

19

20

3..13

Page 94
February 2010

ELR Receiver - If empty the default is
’USA’

Principal
Language Of
Message
HL70356

Alternate
Character Set
Handling Scheme

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-1. MESSAGE HEADER SEGMENT (MSH)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

21

EI

[1..*]

R

Receiver

R

Receiver

R

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
R

Message Profile
Identifier

Field used to reference or assert
adherence to a message profile.
Message profiles contain detailed
explanations of grammar, syntax, and
usage for a particular message or set of
messages. This field is allowed to repeat.
If multiple profiles are listed in this field, it
is assumed the profiles aren’t
contradictory. If they were contradictory,
this would be the basis for an error. The
rules described by HL7 Chapter 2.1 about
constraining profiles apply. The profile ID
for the profile defined in this guide should
appear as a Repeat. Other profile IDs
may appear in the field, as well, in cases
where more constrained profiles are
created from this profile. An OID for this
profile is available once it is assigned.
Value is based on profile id from dynamic
definition in section 3.3.
NHSN Cardinality: The NHSN Profile
currently supports a single repeat of this
field.

Note: When there is no performing lab specified in the OBX, use the combination of MSH-3 and MSH-4 to define a local coding system. It is assumed that:
•

Different applications within an organization with a single CLIA number may have different local coding systems (e.g., a clinical pathology application vs. an
anatomic pathology application).

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 95
February 2010

Chapter 5: Segment and Field Descriptions
•

A single application within an organization with a single CLIA number has a single local coding system. That coding system may contain multiple value sets, for
example, it may contain local value sets for observation identifier, observation value, abnormal flag, race, ethnicity, reason for study, and others.

Example:
MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.3.2^ISO|SPH^2.16.840.1.113883.19.3
.2^ISO|200707011325540400||ORU^R01^ORU_R01|20070701132554000008|P^T|2.5.1|||NE|NE|USA||||PHLabReportAck^^2.16.840.1.114222.4.10.3^ISO

5.2 SFT – SOFTWARE SEGMENT
The software segment provides information about the sending application or other applications that manipulate the message before the receiving application processes the
message. In this guide, the Laboratory Result Sender actor is required to populate the first SFT segment. Any other application that transforms the message must add an
SFT segment for that application. Other applications that route or act as a conduit may add an SFT but are not required to do so. See Table 3-1. Use Case: Laboratory To
Public Health, Actor, Laboratory Result Sender for further discussion the types of roles applications may play in these data exchanges. Based on that discussion, and HL7
Application (including gateways) is required to populate an SFT segment, while bridges and intermediaries may add an SFT but are not required to do so.
Table 5-2. Software Segment (SFT)

TABLE 5-2. SOFTWARE SEGMENT (SFT)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

XON

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Usage

[1..1]

R

R

-

-

Software Vendor
Organization

2

1..15# ST

[1..1]

R

R

-

-

Software Certified
Version or
Release Number

3

1..20# ST

[1..1]

R

R

-

-

Software Product
Name

4

1..20# ST

[1..1]

R

R

-

-

Software Binary
ID

Page 96
February 2010

Description/Comments

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-2. SOFTWARE SEGMENT (SFT)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

5

TX

[0..1]

O

O

-

-

Software Product
Information

6

TS

[0..1]

RE

RE

-

-

Software Install
Date

Example:
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An Lab System|56734||20080817

5.3 MSA – ACKNOWLEDGEMENT SEGMENT
The Message Response Segment (MSA) contains the information sent as acknowledgment to the order message received by a Laboratory Information System.
Table 5-3. Acknowledgement Segment (MSA)

TABLE 5-3. ACKNOWLEDGEMENT SEGMENT (MSA)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

2..2

ID

[1..1]

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

-

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
R

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

HL70008

Acknowledgment Acknowledgment code indicating receipt
Code
of message. (Refer to HL7 Table 0008 Acknowledgment Code for valid values.)

Page 97
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-3. ACKNOWLEDGEMENT SEGMENT (MSA)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

2

1..199= ST

[1..1]

R

-

R

Message Control Identifier that enables the sending system
ID
to associate this response with the
message for which it is intended. This
value will be the MSH.10 message control
ID from the message being
acknowledged.

3

ST

[0..0]

X

-

X

Text Message

4

NM

[0..1]

O

-

O

Expected
Sequence
Number

5

ID

[0..0]

X

-

X

Delayed
Deprecated as of HL7 Version 2.2 and the
Acknowledgment detail was withdrawn and removed from
Type
the standard as of HL7 Version 2.5.

6

CWE

[0..0]

X

-

X

Error Condition

Deprecated as of HL7 Version 2.4. See
ERR segment.

Deprecated as of HL7 Version 2.4. See
ERR segment.

Example:
MSA|CA|20070701132554000008

Page 98
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

5.4 ERR – ERROR SEGMENT
The ERR segment is used to add error comments to acknowledgment messages.
Table 5-4. Error Segment (ERR)

TABLE 5-4. ERROR SEGMENT (ERR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

1

ELD

[0..0]

X

X

-

-

Error Code and
Location

2

ERL

[0..*]

O

O

-

-

Error Location

3

CWE

[1..1]

R

R

-

-

HL70357

HL7 Error Code

Identifies the HL7 (communications) error
code.

ID

[1..*]

R

R

-

-

HL70516

Severity

Identifies the severity of an application
error. Knowing if something is Error,
Warning, or Information is intrinsic to how
an application handles the content.

CWE

[0..1]

O

O

-

-

HL70533

Application Error
Code

Note that Hl7 table 0533 has no
suggested values. It is always a user
defined table, and will generally contain
locally defined codes.

ST

[0..10]

O

O

-

-

Application Error
Parameter

4

1..1

5

6

1..80#

7

1..2048# TX

[0..1]

RE

RE

-

-

Diagnostic
Information

8

1..250# TX

[0..1]

RE

RE

-

-

User Message

9

1..20=

[0..0]

X

X

-

-

Inform Person
Indicator

IS

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Deprecated as of HL7 Version 2.5. See
ERR-2 Error Location and ERR-3 HL7
Error Code fields.

Information that may be used by help desk
or other support personnel to diagnose a
problem.
Not supported.
Page 99
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-4. ERROR SEGMENT (ERR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

10

CWE

[0..0]

X

X

-

-

Override Type

Not supported.

11

CWE

[0..0]

X

X

-

-

Override Reason Not supported.
Code

12

XTN

[0..*]

RE

RE

-

-

Help Desk
Contact Point

Example:
ERR||OBR^1|100^Segment sequence error^HL70357|E|||Missing required OBR segment|Email help desk
for further information on this error||||^NET^Internet^[email protected]

5.5 PID – PATIENT IDENTIFICATION SEGMENT
The Patient Identification Segment (PID) is used to provide basic demographics regarding the subject of the testing. The subject may be a person or animal.
Table 5-5. Patient Identification Segment (PID)

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

1..4

2

Page 100
February 2010

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element

Description/Comments

Name

Usage

SI

[1..1]

R

R

O

R

Set ID – PID

Literal Value: ‘1’.

CX

[0..0]

X

X

X

X

Patient ID

Deprecated as of HL7 Version 2.3.1. See
PID-3 Patient Identifier List.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
3

CX

[1..*]

R

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

R

EHR

Value Set

HL7 Element

Description/Comments

Patient Identifier
List

Field used to convey all types of
patient/person identifiers. This includes
social security numbers, driver’s license
numbers, medical record numbers, etc.

Name

Usage
R

NHSN Cardinality: NHSN currently
supports up to 4 patient identifiers.
4

CX

[0..0]

X

X

X

X

Alternate Patient
ID – PID

Deprecated as of HL7 Version 2.3.1. See
PID-3.

5

XPN

[1..*]

R

R

R

R

Patient Name

Patient name or aliases. When the name
of the patient is not known, a value must
still be placed in this field since the field is
required. In that case, HL7 recommends
the following: |~^^^^^^U|. The "U" for the
name type code in the second name
indicates that it is unspecified. Since
there may be no name components
populated, this means there is no legal
name, nor is there an alias. This guide
will interpret this sequence to mean there
is no patient name.
NHSN Cardinality: NHSN currently
supports up to 2 patient names.

6

XPN

[0..1]

RE

RE

O

RE

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Mother’s Maiden
Name

May be included for identification
purposes. Name type code is constrained
to the value "M."

Page 101
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
7

TS

[0..1]

RE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

RE

Receiver

RE

EHR

Value Set

HL7 Element
Name

Description/Comments

Usage
RE

Date/Time of Birth Patient’s date of birth. The time zone
component is optional. Note that the
granularity of the birth date may be
important. For a newborn, birth date may
be known down to the minute, while for
adults it may be known only to the date.
Birth date may be used by the lab to
calculate an age for the patient, which
may affect what normal ranges apply to
particular test results. Format:
YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][
+/-ZZZZ]
Note: If a birth date is not provided in the
PID, then the patient age at specimen
collection must be reported as an
observation associated with the specimen.

8

1..20= IS

[0..1]

RE

RE

RE

RE

9

XPN

[0..0]

X

X

X

X

10

CWE

[0..*]

RE

RE

RE

RE

11

XAD

[0..*]

RE

RE

O

[0..0]

X

X

X

12

1..20= IS

Page 102
February 2010

HL70001

Administrative Sex Patient’s gender.
Patient Alias

Deprecated as of HL7 Version 2.4. See
PID-5 Patient Name.

Race

One or more codes that broadly refer to
the patient’s race(s).

O

Patient Address

NHSN Cardinality: NHSN currently
supports a single patient address.

X

County Code

Deprecated as of HL7 Version 2.3. See
PID-11 - Patient Address, component 9
County/Parish Code.

HL70005

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element
Name

Description/Comments

Usage

13

XTN

[0..*]

RE

RE

O

O

Phone Number –
Home

14

XTN

[0..*]

RE

RE

O

O

Phone Number –
Business

15

CWE

[0..*]

O

O

O

O

PHVS_Langu Primary Language Need language for communication with
age_ISO_639
the patient (i.e., phone, email, letter, etc.)
-2_Alpha3

16

CWE

[0..1]

O

O

O

O

HL70002

Marital Status

17

CWE

[0..1]

O

O

O

O

HL70006

Religion

18

CX

[0..1]

C

O

C

O

Patient Account
Number

ELR: Use PID-3, with identifier type of
‘AN’.
NHSN Condition predicate: If PID-3 does
not have an identifier with the AN type
code, then this field is required and must
contain an anonymous (type code =
ANON) account number.

19

ST

[0..0]

X

X

X

X

SSN Number –
Patient

20

DLN

[0..0]

X

X

X

X

Driver’s License Deprecated as of HL7 Version 2.5. See
Number – Patient PID-3 Patient Identifier List.

21

CX

[0..*]

O

O

O

O

Mother’s Identifier

22

CWE

[0..*]

RE

RE

RE

RE

[0..1]

O

O

O

O

23

1..250# ST

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

HL70189

Ethnic Group

Deprecated as of HL7 Version 2.3.1. See
PID-3 Patient Identifier List.

NHSN Cardinality: NHSN currently
supports a single patient ethnic group.

Birth Place
Page 103
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element

HL70136

Multiple Birth
Indicator

Name

Description/Comments

Usage

24

1..1

ID

[0..1]

O

O

O

O

25

1..2=

NM

[0..1]

O

O

O

O

26

CWE

[0..*]

O

O

O

O

HL70171

Citizenship

27

CWE

[0..1]

O

O

O

O

HL70172

Veterans Military
Status

28

CWE

[0..0]

X

X

X

X

Nationality

Deprecated as of HL7 Version 2.4. See
PID-10 Race, PID-22 Ethnic Group, and
PID-26 Citizenship.

29

TS

[0..1]

RE

RE

RE

O

Patient Death
Date and Time

Format:
YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][
+/-ZZZZ]
If PID-29 is valued, then this field should
be populated with “Y” since the patient is
known to be dead.

Birth Order

30

1..1

ID

[0..1]

RE

RE

RE

O

HL70136

Patient Death
Indicator

31

1..1

ID

[0..1]

RE

O

O

RE

HL70136

Identity Unknown
Indicator

32

1..20= IS

[0..*]

O

O

O

O

HL70445

Identity Reliability
Code

33

TS

[0..1]

RE

RE

O

O

Page 104
February 2010

Last Update
Date/Time

Note: Used to indicate when
demographics were last updated. Format:
YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][
+/-ZZZZ]

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
34

HD

[0..1]

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

Receiver

O

EHR

Value Set

HL7 Element

Description/Comments

Last Update
Facility

This is the facility that originated the
demographic update.

Name

Usage
O

ELR: Condition predicate: If PID-33 is
present this is required.
35

CWE

[0..1]

RE

RE

O

X

PHVS_Anima Species Code
l_CDC

Population of this field supports animal
rabies testing as it relates to human rabies
testing. This is a variant to HITSP where
the field is not supported. If a constrained
version of this guide includes support for
Breed (PID-36) or Strain (PID-37), then
this field would be required if Breed and or
Strain is present.

36

CWE

[0..1]

O

O

O

X

Local

If a constrained version of this guide
includes support for Strain (PID-37), then
this field would be required if Strain is
present.

Breed Code

ELR Note: The value set for PID-35,
PHVS_Animal_CDC, is drawn from
SNOMED CT and includes breed codes
as well as codes for the species.
SNOMED CT is now structured such that
the selection of the specific breed also
implies a specific species.
37
38

1..80= ST
CWE

[0..1]

O

O

O

X

[0..2]

O

O

O

X

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Strain
HL70429

Production Class
Code

Page 105
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-5. PATIENT IDENTIFICATION SEGMENT (PID)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
39

CWE

[0..*]

O

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

O

Receiver

O

EHR

Value Set

HL7 Element

Tribal
Citizenship
Value Set

Tribal Citizenship HL7 recommends using Bureau of Indian
Affairs (BIA) Tribal Identity List. The
following is a link to the current live list:
http://www.usa.gov/Government/Tribal_Sit
es/index.shtml

Name

Description/Comments

Usage
X

This is a link to the most recent official
static list:
http://edocket.access.gpo.gov/2008/E86968.htm

Example:
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.840.1.113883.19.3.2.1&ISO~44433
3333^^^&2.16.840.1.113883.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^^^^M|20050602
|M||2106-3^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^955^5551009|eng^English^ISO6392^^^^3/2
9/2007|M^Married^HL70002^^^^2.5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|Reliable^2.16.840.1.113883.19.3.1^ISO

5.6 NK1 – NEXT OF KIN SEGMENT
If the subject of the testing is something other than a person, the NK1 will document the person or organization responsible for or owning the subject. For patients who
are persons, the NK1 documents the next of kin of the patient. This is particularly important for lead testing of minors, since the NK1 is used to document information
about the parent or guardian. For animal patients, the NK1 documents the person or organization that owns or is responsible for the animal. This is where the
employment information for the patient is documented.

Page 106
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions
Table 5-6. Next of Kin Segment (NK1)

TABLE 5-6. NEXT OF KIN SEGMENT (NK1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

2

1..4

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element

Description/Comments

Name

Usage

SI

[1..1]

R

R

-

-

Set ID – NK1

For the first repeat of the NK1 segment,
the sequence number shall be one (1), for
the second repeat, the sequence number
shall be two (2), etc.

XPN

[0..*]

CE

CE

-

-

Name

Name of the next of kin or associated
party. Multiple names for the same entity
are allowed, but the legal name must be
sent in the first sequence. If the legal
name is not sent, the repeat delimiter
must be sent in the first sequence.
ELR Condition predicate: If next of kin or
associated party is a person use this field,
otherwise, use field NK1-13

3

CWE

[0..1]

RE

RE

-

-

4

XAD

[0..*]

RE

RE

-

5

XTN

[0..*]

RE

RE

-

Relationship

Description of the relationship between
the next of kin/related party and the
patient. It is of particular importance
when documenting the parent or guardian
of a child patient or the owner of an
animal patient.

-

Address

Component that may contain the address
of the next of kin/associated party.

-

Phone Number

Field that may contain the telephone
number of the next of kin/associated
party. Multiple phone numbers are
allowed

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

HL70063

Page 107
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-6. NEXT OF KIN SEGMENT (NK1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element

Description/Comments

Name

Usage

6

XTN

[0..0]

X

X

-

-

Business Phone
Number

Not supported. Use NK1-5.

7

CWE

[0..0]

X

X

-

-

Contact Role

Not supported.

8

DT

[0..0]

X

X

-

-

Start Date

Not supported.

9

DT

[0..0]

X

X

-

-

End Date

Not supported.

1..60# ST

[0..0]

X

X

-

-

Not supported.
Next of Kin /
Associated Parties
Job Title

10

11

JCC

[0..0]

X

X

-

-

Not supported.
Next of Kin /
Associated Parties
Job Code/Class

12

CX

[0..0]

X

X

-

-

Not supported.
Next of Kin /
Associated Parties
Employee Number

13

XON

[0..1]

CE

CE

-

-

Organization
Name – NK1

ELR Condition predicate: If next of kin or
associated party is an organization use
this field, otherwise, use field NK1-2.

14

CWE

[0..0]

X

X

-

-

Marital Status

Not supported.

15

1..20= IS

[0..0]

X

X

-

-

Administrative Sex Not supported.

16

TS

[0..0]

X

X

-

-

Date/Time of Birth Not supported.

17

1..20= IS

[0..0]

X

X

-

-

Living Dependency Not supported.

18

1..20= IS

[0..0]

X

X

-

-

Ambulatory Status Not supported.

[0..0]

X

X

-

-

Citizenship

19
Page 108
February 2010

CWE

Not supported.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-6. NEXT OF KIN SEGMENT (NK1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
20

21

CWE

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element
Name

Description/Comments

Usage

[0..1]

O

O

-

-

[0..0]

X

X

-

-

Living
Arrangement

Not supported.

CWE

[0..0]

X

X

-

-

Publicity Code

Not supported.

1..20= IS

22

ELR

PHVS_Langu Primary Language Need language for communication with
age_ISO_639
the patient (i.e., phone, email, letter, etc.)
-2_Alpha3

23

1..1

ID

[0..0]

X

X

-

-

Protection
Indicator

Not supported.

24

1..20= IS

[0..0]

X

X

-

-

Student Indicator

Not supported.

25

CWE

[0..0]

X

X

-

-

Religion

Not supported.

26

XPN

[0..0]

X

X

-

-

Mother’s Maiden
Name

Not supported.

27

CWE

[0..0]

X

X

-

-

Nationality

Not supported.

28

CWE

[0..0]

X

X

-

-

Ethnic Group

Not supported.

29

CWE

[0..0]

X

X

-

-

Contact Reason

Not supported.

30

XPN

[0..*]

CE

CE

-

-

Contact Person’s
Name

ELR Condition predicate: Required if
NK1-13 is populated.

31

XTN

[0..*]

RE

RE

-

-

Contact Person’s
Telephone Number

32

XAD

[0..*]

RE

RE

-

-

Contact Person’s
Address

33

CX

[0..0]

X

X

-

-

Next of
Kin/Associated
Party’s Identifiers

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Not supported.

Page 109
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-6. NEXT OF KIN SEGMENT (NK1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
34

1..20= IS

35

CWE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set

HL7 Element

Description/Comments

Name

Usage

[0..0]

X

X

-

-

Job Status

Not supported.

[0..0]

X

X

-

-

Race

Not supported.

36

1..20= IS

[0..0]

X

X

-

-

Handicap

Not supported.

37

1..16# ST

[0..0]

X

X

-

-

Contact Person
Social Security
Number

Not supported.

38

1..250# ST

[0..0]

X

X

-

-

Next of Kin Birth
Place

Not supported.

39

1..20= IS

[0..0]

X

X

-

-

VIP Indicator

Not supported.

1

Example:
NK1|1|Mum^Martha^M^^^^L|MTH^Mother^HL70063^^^^2.5.1| 444 Home Street^Apt B^Ann
Arbor^MI^99999^USA^H|^PRN^PH^^1^555^5552006

Page 110
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

5.7 PV1 – PATIENT VISIT INFORMATION
This segment contains basic inpatient or outpatient encounter information.
Table 5-7. Patient Visit Information (PV1)

TABLE 5-7. PATIENT VISIT INFORMATION (PV1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

1

1..4

SI

[1..1]

R

R

O

R

2

1..20= IS

[1..1]

R

R

R

R

3

PL

[0..1]

C

O

RE

C

4

1..20= IS

[0..1]

CE

RE

O

CE

HL70004

Admission
Type Value
Set

Set ID - PV1

Literal Value: ‘1’.

Patient Class

A gross identification of the classification
of patient’s visit

Assigned Patient
Location

Lab to EHR Condition predicate:
Required if PV1-2 is "inpatient."

Admission Type

Lab to EHR Condition predicate:
Required if PV1-2 is "inpatient."

5

CX

[0..1]

O

O

O

O

Preadmit Number

6

PL

[0..1]

O

O

O

O

Prior Patient
Location

7

XCN

[0..*]

O

O

O

O

Attending Doctor

8

XCN

[0..*]

O

O

O

O

Referring Doctor

9

XCN

[0..*]

O

O

O

O

Consulting Doctor

10

1..20= IS

[0..1]

RE

O

RE

RE

11

PL

[0..1]

O

O

O

X

12

1..20= IS

[0.1]

O

O

O

O

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Local

Hospital Service
Temporary
Location

HL70087

Preadmit Test
Indicator

Page 111
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-7. PATIENT VISIT INFORMATION (PV1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

13

1..20= IS

[0..0]

X

X

X

X

14

1..20= IS

[0..1]

O

O

O

X

15

1..20= IS

[0..0]

X

X

X

X

Ambulatory Status Not supported.

16

1..20= IS

[0..0]

X

X

X

X

VIP Indicator

[0..*]

O

O

O

O

Admitting Doctor

[0..1]

O

O

O

O

17
18

XCN
1..20= IS

Re-admission
Indicator
HL70023

HL70018

Not supported.

Admit Source
Not supported.

Patient Type

19

CX

[0..1]

RE

O

RE

O

Visit Number

20

FC

[0..*]

O

O

O

O

Financial Class

21

1..20= IS

[0..0]

X

X

X

X

Charge Price
Indicator

Not supported.

22

1..20= IS

[0..0]

X

X

X

X

Courtesy Code

Not supported.

23

1..20= IS

[0..0]

X

X

X

X

Credit Rating

Not supported.

24

1..20= IS

[0..0]

X

X

X

X

Contract Code

Not supported.

25

DT

[0..0]

X

X

X

X

Contract Effective Not supported.
Date

26

1..12= NM

[0..0]

X

X

X

X

Contract Amount

Not supported.

27

1..3=

[0..0]

X

X

X

X

Contract Period

Not supported.

28

1..20= IS

[0..0]

X

X

X

X

Interest Code

Not supported.

29

1..20= IS

[0..0]

X

X

X

X

Transfer to Bad
Debt Code

Not supported.

Page 112
February 2010

NM

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-7. PATIENT VISIT INFORMATION (PV1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
30

DT

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Usage

[0..1]

O

O

O

O

Transfer to Bad
Debt Date

31

1..20= IS

[0..1]

O

O

O

O

32

1..12= NM

[0..1]

O

O

O

O

Bad Debt Transfer
Amount

33

1..12= NM

[0..1]

O

O

O

O

Bad Debt
Recovery Amount

34

1..20= IS

[0..1]

O

O

O

O

[0..1]

O

O

O

O

[0..1]

RE

O

O

RE

35
36

DT
1..20= IS

Description/Comments

HL70021

HL70111

Bad Debt Agency
Code

Delete Account
Indicator
Delete Account
Date

HL70112

Discharge
Disposition

37

DLD

[0..1]

O

O

RE

O

38

CWE

[0..1]

O

O

O

O

HL70114

Diet Type

HL70115

Servicing Facility

39

1..20= IS

[0..1]

O

O

O

O

40

1..20= IS

[0..0]

X

X

X

X

41

1..20= IS

[0..1]

O

O

O

O

42

PL

[0..1]

O

O

O

O

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Disposition of the patient at discharge or
once the visit is completed, for example,
"Discharged to Home/Self-Care",
"Expired", "Left Against Medical Advice".
Uses Uniform Billing codes.

Discharged to
Location

Bed Status
HL70117

Not supported

Account Status
Pending Location
Page 113
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-7. PATIENT VISIT INFORMATION (PV1)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

43

PL

[0..1]

O

O

O

O

Prior Temporary
Location

44

TS

[0..1]

RE

RE

RE

RE

Admit Date/Time

Date and time patient arrived for services

45

TS

[0..*]

RE

RE

RE

RE

Discharge
Date/Time

Date and time patient services ended

46

1..12= NM

[0..1]

O

O

O

O

Current Patient
Balance

47

1..12= NM

[0..1]

O

O

O

O

Total Charges

48

1..12= NM

[0..1]

O

O

O

O

Total Adjustments

49

1..12= NM

[0..1]

O

O

O

O

Total Payments

50

CX

[0..1]

O

O

O

O

Alternate Visit ID

[0..1]

O

O

O

O

[0..0]

O

O

O

X

51

1..20= IS

52

XCN

HL70326

ELR and NHSN Cardinality: ELR and
NHSN currently support a single discharge
date/time.

Visit Indicator
Other Healthcare
Provider

1

Example:
PV1|1|O|4E^234^A^Good Health Hospital&2.16.840.1.113883.19.3.2.3&ISO^N^N^Building 1^4^Nursing
unit 4
East^1234&&2.16.840.1.113883.19.3.2.3&ISO^&2.16.840.1.113883.19.3.2.3&ISO|R|||||||||||||||||||
|||||||||||||||||||||200808151000-0700|200808151200-0700

Page 114
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

5.8 PV2 – PATIENT VISIT – ADDITIONAL INFORMATION SEGMENT
The PV2 segment is a continuation of information contained on the PV1 segment.
Table 5-8. Patient Visit – Additional Information (PV2)

TABLE 5-8. PATIENT VISIT – ADDITIONAL INFORMATION (PV2)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

1

PL

[0..0]

X

X

-

X

Prior Pending
Location

Not supported

2

CWE

[0..0]

X

X

-

X

Accommodation
Code

Not supported.

3

CWE

[0..1]

RE

O

-

RE

Admit Reason

A generalized explanation of why the
patient needed services. Frequently used
for chief complaint. Has no universally
accepted value set.

4

CWE

[0..0]

X

X

-

X

Transfer Reason

Not supported.

Local

5

1..25= ST

[0..0]

X

X

-

X

Patient Valuables Not supported.

6

1..25= ST

[0..0]

X

X

-

X

Patient Valuables Not supported.
Location

7

1..20= IS

[0..0]

X

X

-

X

Visit User Code

Not supported.

8

TS

[0..0]

X

X

-

X

Expected Admit
Date/Time

Not supported.

9

TS

[0..0]

X

X

-

X

Expected
Discharge
Date/Time

Not supported.

NM

[0..0]

X

X

-

X

Estimated Length Not supported.
of Inpatient Stay

10

1..3=

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 115
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-8. PATIENT VISIT – ADDITIONAL INFORMATION (PV2)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

11

1..3=

NM

[0..0]

X

X

-

X

Actual Length of
Inpatient Stay

Not supported.

12

1..50# ST

[0..0]

X

X

-

X

Visit Description

Not supported.

13

XCN

[0..0]

X

X

-

X

Referral Source
Code

Not supported.

14

DT

[0..0]

X

X

-

X

Previous Service
Date

Not supported.

Employment
Illness Related
Indicator

Coded value indicating whether services
are provided as a consequence of
employment
Not supported.

15

1..1

ID

[0..1]

RE

O

-

RE

16

1..20= IS

[0..0]

X

X

-

X

Purge Status
Code

[0..0]

X

X

-

X

Purge Status Date Not supported.

17

DT

HL70136

18

1..20= IS

[0..0]

X

X

-

X

Special Program
Code

Not supported.

19

1..1

ID

[0..0]

X

X

-

X

Retention
Indicator

Not supported.

20

1..1=

NM

[0..0]

X

X

-

X

Expected Number Not supported.
of Insurance Plans

21

1..20= IS

[0..0]

X

X

-

X

Visit Publicity
Code

Not supported.

22

1..1

[0..0]

X

X

-

X

Visit Protection
Indicator

Not supported.

Page 116
February 2010

ID

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-8. PATIENT VISIT – ADDITIONAL INFORMATION (PV2)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
23

XON

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

[0..*]

RE

O

-

RE

Clinic
Organization
Name

Name of the organization within a facility
that provides patient care. Name shall be
unique within any given facility.
Not supported.

24

1..20= IS

[0..0]

X

X

-

X

Patient Status
Code

25

1..20= IS

[0..0]

X

X

-

X

Visit Priority Code Not supported.

[0..1]

O

O

-

X

Previous
Treatment Date

[0..0]

X

X

-

X

Expected
Discharge
Disposition

26
27

DT
1..20= IS

Not supported.

28

DT

[0..0]

X

X

-

X

Signature on File Not supported.
Date

29

DT

[0..1]

O

O

-

X

First Similar
Illness Date

30

CWE

[0..0]

X

X

-

X

Not supported.
Patient Charge
Adjustment Code

31

1..20= IS

[0..0]

X

X

-

X

Recurring Service Not supported.
Code

32

1..1

ID

[0..0]

X

X

-

X

Billing Media
Code

TS

[0..0]

X

X

-

X

Expected Surgery Not supported.
Date and Time

ID

[0..0]

X

X

-

X

Not supported.
Military
Partnership Code

33
34

1..1

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Not supported.

Page 117
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-8. PATIENT VISIT – ADDITIONAL INFORMATION (PV2)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

35

1..1

ID

[0..0]

X

X

-

X

Military NonAvailability Code

Not supported.

36

1..1

ID

[0..0]

X

X

-

X

Newborn Baby
Indicator

Not supported.

37

1..1

ID

[0..0]

X

X

-

X

Baby Detained
Indicator

Not supported.

38

CWE

[0..0]

X

X

-

X

Mode of Arrival
Code

Not supported.

39

CWE

[0..0]

X

X

-

X

Recreational Drug Not supported.
Use Code

40

CWE

[0..1]

RE

O

-

RE

41

CWE

[0..0]

X

X

-

42

CWE

[0..0]

X

X

HL70432

Admission Level
of Care Code

A generalized identification of patient’s
acuity for the services received during the
visit covered by this message

X

Precaution Code

Not supported.

-

X

Patient Condition Not supported.
Code

43

1..20= IS

[0..0]

X

X

-

X

Living Will Code

Not supported.

44

1..20= IS

[0..0]

X

X

-

X

Organ Donor
Code

Not supported.

45

CWE

[0..0]

X

X

-

X

Advance Directive Not supported.
Code

46

DT

[0..0]

X

X

-

X

Patient Status
Effective Date

Page 118
February 2010

Not supported.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-8. PATIENT VISIT – ADDITIONAL INFORMATION (PV2)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

47

TS

[0..0]

X

X

-

X

Not supported.
Expected LOA
Return Date/Time

48

TS

[0..0]

X

X

-

X

Not supported.
Expected Preadmission Testing
Date/Time

49

IS

[0..0]

X

X

-

X

Notify Clergy
Code

Not supported.

Example:
PV2|||1^Sick^99AdmitReason|||||||||||||N||||||||Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|||20010603|||19990603

5.9 ORC – COMMON ORDER SEGMENT
The Common Order Segment (ORC) identifies basic information about the order for testing of the specimen. This segment includes identifiers for the order, who placed
the order, when it was placed, what action to take regarding the order, etc.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 119
February 2010

Chapter 5: Segment and Field Descriptions
Table 5-9. Common Order Segment (ORC)

TABLE 5-9. COMMON ORDER SEGMENT (ORC)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

2..2

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element

Description/Comments

HL70119

Order Control

Determiner of the function of the order
segment. In the ORU^R01 this should be
the literal value: "RE."

Name

Usage

ID

[1..1]

R

R

-

R

2

EI

[0..1]

CE

CE

-

CE

Placer Order
Number

ELR & Lab to EHR Condition predicate: If
OBR-2 Placer Order Number is populated;
this field must contain the same value as
OBR-2.

3

EI

[1..1]

R

R

-

R

Filler Order
Number

This field must contain the same value as
OBR-3 Filler Order Number.
Note: In the circumstance where some of
the lab results are generated by the lab,
but others are performed by a reference
lab, the sending lab can choose what filler
order number to use, but what ever is
used, the sending lab is expected to be
able to trace all the observations in the lab
result back to the appropriate source lab
based on the filler order number provided
in ORC-3.

4

EI

[0..1]

RE

RE

-

RE

Placer Group
Number

5

2..2

ID

[0..1]

O

O

-

O

HL70038

Order Status

6

1..1

ID

[0..1]

O

O

-

O

HL70121

Response Flag

Page 120
February 2010

The placer group number is used to
identify a group of orders. In the
laboratory setting this is commonly
referred to as a "requisition number."

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-9. COMMON ORDER SEGMENT (ORC)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

7

TQ

[0..0]

X

X

-

X

Quantity/Timing

8

EIP

[0..1]

O

O

-

O

Parent

9

TS

[0..1]

O

O

-

O

Date/Time of
Transaction

10

XCN

[0..*]

O

O

-

O

Entered By

11

XCN

[0..*]

O

O

-

O

Verified By

12

XCN

[0..*]

CE

CE

-

O

Ordering Provider ELR Condition predicate: If OBR.16
Ordering Provider is populated, this field
will contain the same value.

13

PL

[0..1]]

O

O

-

O

Enterer's Location

14

XTN

[0..*]

CE

CE

-

O

Call Back Phone
Number

Deprecated as of HL7 Version 2.5. See
TQ1 and TQ2 segments.

ELR Condition predicate: If OBR-17
Callback Phone Number is populated, this
field will contain the same value. This
should be a phone number associated
with the original order placer.
ELR Cardinality: ELR currently supports
up to call back phone numbers.

15

TS

[0..1]

O

O

-

O

16

CWE

[0..1]

O

O

-

O

Local

Order Control
Code Reason

17

CWE

[0..1]

O

O

-

O

Local

Entering
Organization

18

CWE

[0..1]

O

O

-

O

Local

Entering Device

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Order Effective
Date/Time

Page 121
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-9. COMMON ORDER SEGMENT (ORC)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

19

XCN

[0..*]

O

O

-

O

Action By

20

CWE

[0..0]

X

X

-

X

Not supported.
Advanced
Beneficiary Notice
Code

21

XON

[1..*]

R

R

-

O

Ordering Facility
Name

ELR Cardinality: ELR supports a single
ordering facility name.

22

XAD

[1.*]

R

R

-

O

Ordering Facility
Address

The address of the facility where the order
was placed.
ELR Cardinality: ELR supports a single
ordering facility address

23

XTN

[1..*]

R

R

-

O

Ordering Facility
Phone Number

24

XAD

[0..*]

RE

RE

-

O

Ordering Provider The address of the ordering provider.
Address

25

CWE

[0..1]

O

O

-

O

26

CWE

[0..0]

X

X

-

X

Not supported.
Advanced
Beneficiary Notice
Override Reason

27

TS

[0..1]

O

O

-

O

Filler's Expected
Availability
Date/Time

28

CWE

[0..1]

O

O

-

O

HL70177

Confidentiality
Code

29

CWE

[0..1]

O

O

-

O

HL70482

Order Type

Page 122
February 2010

Local

Order Status
Modifier

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-9. COMMON ORDER SEGMENT (ORC)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

30

CNE

[0..1]

O

O

-

O

HL70483

Enterer
Authorization
Mode

31

CWE

[0..1]

O

O

-

O

Strongly
recommend
using
Laboratory
Order Value
Set from
HITSP

Parent Universal
Service Identifier

Example:
ORC|RE||CHEM9700122^MediLabCoSeattle^45D0470381^CLIA|||||||||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^E
I^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005|||||||Level Seven
Healthcare, Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005 Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444 Healthcare Drive^Suite 123^Ann
Arbor^MI^99999^USA^B

5.10 OBR – OBSERVATION REQUEST SEGMENT
The Observation Request Segment (OBR) is used to capture information about one test being performed on the specimen. Most importantly, the OBR identifies the type
of testing to be performed on the specimen and ties that information to the order for the testing.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 123
February 2010

Chapter 5: Segment and Field Descriptions
Table 5-10. Observation Request Segment (OBR)

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

1..4

2

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

SI

[1..1]

R

R

O

R

Set ID - OBR

For the first repeat of the OBR segment,
the sequence number shall be one (1), for
the second repeat, the sequence number
shall be two (2), etc.

EI

[1..1]

RE

RE

RE

RE

Placer Order
Number

This identifier is assigned by the placer of
the order being fulfilled by this result
message. This identifier distinguishes the
placer’s order from all other orders created
by the placer where an order is interpreted
to be the testing identified in a single OBR
segment. Normally, it is a type of system
identifier assigned by the placer software
application.
The Placer Order Number and the Filler
Order Number are essentially foreign keys
exchanged between applications for
uniquely identifying orders and the
associated results across applications.

Page 124
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
3

EI

[1..1]

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

R

EHR

Value Set HL7 Element Description/Comments
Name

Usage
R

Filler Order
Number

Order number associated with the Filling
Application. This number is assigned to
the test by the organization performing the
test. This field should not contain the
accession number or specimen identifier
for a specimen unless these identifiers
meet the criteria for a filler order number.
The specimen or accession identifier
should be placed in SPM-2. The Filler
Order Number identifies this order as
distinct from all other orders being
processed by this filler where an order is
interpreted to be the testing identified in a
single OBR segment. Normally, this is a
type of system identifier assigned by the
filler software application.
The Filler Order Number, along with the
Placer Order Number, is essentially foreign
keys exchanged between applications for
uniquely identifying orders and the
associated results across applications.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

In messages containing multiple OBRs,
each OBR must be identified by a unique
Filler Order Number. This is critical for
making parent/child results relationships
work properly. Microbiology cultures and
sensitivities are linked in this fashion in this
profile. See Appendix A, Section A.4.
Linking Parent and Child Results, of this
document for more information on linking
parent/child results.
Page 125
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

4

CWE

[1..1]

R

R

R

R

5

ID

[0..0]

X

X

X

X

Priority – OBR

Deprecated as of HL7 Version 2.3. See
TQ1-9 Priority Field.

6

TS

[0..0]

X

X

X

X

Requested
Date/Time

Deprecated as of HL7 Version 2.3. See
TQ1-8 Start Date/Time.

Page 126
February 2010

Strongly
recommend
using
Laboratory
Order Value
Set from
HITSP.

Universal Service Identifier code for the requested
Identifier
observation/test/ battery. Strongly
recommend Laboratory Order Value Set,
which is based on LOINC.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
7

TS

[1..1]

R

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

R

EHR

Value Set HL7 Element Description/Comments
Name

Usage
R

Observation
Date/Time

For specimen-based observations, the
date/time the specimen was collected. A
minimum of year, month and day must be
provided when the actual date/time is
known. For unknown collection date/time
use "0000". If the SPM is sent, this field
must contain the same value as the first
component of SPM-17 Specimen
Collection Date/Time. HL7 requires this
field in an OBR in a result message. For
OBXs related to this OBR and related to
the testing of a specimen, OBX-14
(Date/Time of the Observation) shall
contain the same value as this field.
Format:
YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]]]+/ZZZZ] except when reporting an unknown
date of ‘0000”

8

TS

[0..1]

CE

CE

O

RE

Observation End For specimen-based observations where
Date/Time
the specimen was collected over a period
of time, this represents the end point in
time when the specimen was collected.
ELR Condition predicate: This field must
contain the same value as the second
component of SPM-17 Specimen
Collection Date/Time.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 127
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

9

CQ

[0..0]

X

X

X

X

Collection
Volume

10

XCN

[0..*]

O

O

O

O

Collector
Identifier

ID

[0..1]

O

O

O

O

HL70065

Specimen Action
Code

12

CWE

[0..1]

O

O

O

O

Local

Danger Code

13

ST

[0..1]

RE

RE

O

O

Relevant Clinical
Information

14

TS

[0..0]

X

X

X

X

Specimen
Received
Date/Time

15

SPS

[0..0]

X

X

X

X

Specimen Source Deprecated as of HL7 Version 2.5. See
SPM-4 Specimen Type.

16

XCN

[0..*]

RE

RE

O

RE

Ordering Provider Identifier of the provider who ordered the
testing being performed. The National
Provider Identifier (NPI) may be used as
the identifier.

11

1..1

Deprecated as of HL7 Version 2.5. See
SPM-12 Specimen Collection Amount.

Deprecated as of HL7 Version 2.5. See
SPM-18 Specimen Received Date/Time.

Note that ORC.12 Ordering Provider is
constrained to contain the same value as
this field.

Page 128
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
17

XTN

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

[0..2]

RE

RE

O

O

Order Callback
Phone Number

This is the number the laboratory can call
with questions regarding the order. This
should be a phone number associated with
the original order placer. Note that ORC.17
Call Back Phone Number is constrained to
contain the same value as this field.

18

1..199= ST

[0..1]

O

O

O

O

Placer Field 1

19

1..199= ST

[0..1]

O

O

O

O

Placer Field 2

20

1..199= ST

[0..1]

O

O

O

O

Filler Field 1

21

1..199= ST

[0..1]

O

O

O

O

Filler Field 2

22

TS

[1..1]

R

R

R

R

Results
Required field in this message. Applies to
Rpt/Status Chng the entire report. Receipt of a subsequent
- Date/Time
message with the same Filler Number and
a different status in this field implies that
processing may need to occur at the
receiving application level to update a
previous report. Format:
YYYYMMDDHHMMSS.SS[…]+/-ZZZZ

23

MOC

[0..1]

O

O

O

O

Charge to
Practice

24

2..3

ID

[0..1]

RE

O

RE

RE

HL70074

25

1..1

ID

[1..1]

R

R

R

R

Result Status
V2 Result
Status Value
Set

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Diagnostic Serv
Sect ID

Page 129
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
26

PRL

[0..1]

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

Receiver

C

EHR

Value Set HL7 Element Description/Comments
Name

Usage
CE

Parent Result

Field that, together with OBR-29 Parent,
allows this result to be linked to a specific
OBX segment associated with another
OBR segment. See Appendix A, Section
A.4. Linking Parent and Child Results, of
this document for more information on
linking parent/child results.
Harmonized condition predicate: This field
is required when linking child sensitivities
to the parent culture.

27

TQ

[0..0]

X

X

X

X

Quantity/Timing

28

XCN

[0..*]

RE

O

O

RE

Result Copies To

Page 130
February 2010

Deprecated as of HL7 Version 2.5. See
TQ1 and TQ2 segments.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
29

EIP

[0..1]

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

Receiver

C

EHR

Value Set HL7 Element Description/Comments
Name

Usage
C

Parent

Used to link this OBR with a parent OBR.
Commonly used with microbiology
messages to link a susceptibility result with
the parent culture that identified the
organism. For this linkage to work
properly, the Placer Order Number and the
Filler Order Number must uniquely identify
the specific parent OBR. This means that
the same Filler Number cannot be used to
identify multiple OBRs. See Appendix A,
Section A.4. Linking Parent and Child
Results, of this document for more
information on linking parent/child results.
Harmonized condition predicate: This field
is required if OBR-24 carries the value
"MB" and OBR-4 indicates the ordered test
is a culture and sensitivity. Parent/child
linking should be used when the specimen
type changes between the parent and child
result (specimen and isolate/component
specimen) or for reflex tests.

30

4..4

ID

[0..0]

X

X

X

X

31

CWE

[0..*]

RE

RE

RE

O

32

NDL

[0..1]

RE

RE

O

O

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Transportation
Mode
Reason For
Study Value
Set

Not supported.

Reason for Study We know ICD9 is used today, but we will
allow ICD10 when the US starts using it.
Principal Result
Interpreter

Used for pathology results.
Page 131
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

33

NDL

[0..*]

O

O

O

O

Assistant Result
Interpreter

34

NDL

[0..*]

O

O

O

O

Technician

35

NDL

[0..*]

O

O

O

O

Transcriptionist

36

TS

[0..1]

O

O

O

O

Scheduled
Date/Time

37

1..16= NM

[0..0]

X

X

X

X

Number of
Sample
Containers

Not supported.
Transport
Logistics of
Collected Sample

Not supported. See SPM-26

38

CWE

[0..0]

X

X

X

X

39

CWE

[0..*]

O

O

O

O

40

CWE

[0..0]

X

X

X

X

Transport
Arrangement
Responsibility

Not supported.

Not supported.

Local

Collector's
Comment

41

1..1

ID

[0..0]

X

X

X

X

Transport
Arranged

42

1..1

ID

[0..0]

X

X

X

X

Escort Required Not supported.

43

CWE

[0..0]

X

X

X

X

Planned Patient
Transport
Comment

44

CWE

[0..1]

O

O

O

O

Page 132
February 2010

HL70088

Not supported.

Procedure Code

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

45

CWE

[0..*]

O

O

O

O

HL70340

Procedure Code
Modifier

46

CWE

[0..*]

O

O

O

O

HL70411

Placer
Supplemental
Service
Information

47

CWE

[0..*]

O

O

O

O

HL70411

Filler
Supplemental
Service
Information

48

CWE

[0..1]

O

O

O

O

HL70476

Medically
Necessary
Duplicate
Procedure
Reason

49

IS

[0..1]

O

O

O

O

HL70507

Result Handling

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 133
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-10. OBSERVATION REQUEST SEGMENT (OBR)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
50

CWE

[0..1]

O

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

O

Receiver

O

EHR

Value Set HL7 Element Description/Comments
Name

Usage
O

Strongly
recommend
using
Laboratory
Order Value
Set from
HITSP

Parent Universal This field has been retained as optional o
Service Identifier allow ELR implementations with Labs that
do not support unique placer or filler order
numbers. In some cases the labs filler
order number equates with a requisition
number that in conjunction with the
Universal Service ID will constitute a
unique identifier for the order. For
parent/child result linking to work in these
situations, the sending lab will need to
populate not only OBR-29, but this field
also. The receiving application will need to
use both OBR-29 and this field to properly
link these results. We note that such
implementations will not be conformant
with this guide, but optional support for this
field has been retained so that states may
still communicate with these labs in a nonconformant manner.

Note: In the circumstance where some of the lab results are generated by the lab, but others are performed by a reference lab, the sending lab can choose what filler order
number to use., Which ever filler order number is used, the sending lab is expected to be able to trace all the observations in the lab result back to the appropriate
source lab based on the filler order number provided in OBR-3.

Example:
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16.840.1.113883.19.3.1.6^ISO|5054
5-3^Bacterial susceptibility panel:-:Pt:Isolate:OrdQn:MIC^LN^^^^2.26|||2008081510300700||||||anemia|||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1
.113883.19.4.6^ISO^^^^^^^^MD|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F|625-4&Bacteria
Page 134
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

identified:Prid:Pt:Stool:Nom:Culture&LN^1^Campylobacter
jejuni|||23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.840.1.113883.19.3.1.6&ISO||
787.91^ DIARRHEA^I9CDX^^^^07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO

5.11 TQ1 – TIMING/QUANTITY SEGMENT
The TQ1 segment is used to specify the timing of events and actions such as those that occur in order management and scheduling systems.
Table 5-11. Time/Quantity Segment for Order Group

TABLE 5-11. TIME/QUANTITY SEGMENT FOR ORDER GROUP
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

1..4

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

SI

[1..1]

R

-

-

R

2

CQ

[0..1]

O

-

-

O

3

RPT

[0..*]

O

-

-

O

Repeat Pattern

4

TM

[0..*]

O

-

-

O

Explicit Time

5

CQ

[0..*]

O

-

-

O

Unified Code Relative Time and
for Units of Units
Measure
(UCUM)

6

CQ

[0..1]

O

-

-

O

Unified Code Service Duration
for Units of
Measure
(UCUM)

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Set ID - TQ1

Sequence number of the timing
specification, the first of which shall be 1;
the second of which shall be 2; and so on.

Unified Code Quantity
for Units of
Measure
(UCUM)

Page 135
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-11. TIME/QUANTITY SEGMENT FOR ORDER GROUP
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
7

TS

[0..1]

RE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

-

Receiver

-

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
RE

Start date/time

Field that may be specified by the
requester, in which case it indicates the
earliest date/time at which the services
should be started. In many cases,
however, the start date/time will be implied
or will be defined by other fields in the
service request record (e.g., urgency STAT).
The filling service may record a value in
this field after receipt of the service
request.

8

TS

[0..1]

O

-

-

O

9

CWE

[0..*]

RE

-

-

RE

End date/time
HL70485

Priority

10

1..250= TX

[0..1]

O

-

-

O

Condition text

11

1..250= TX

[0..1]

O

-

-

O

Text instruction

12

1..1

ID

[0..1]

O

-

-

O

HL70472

13

CQ

[0..1]

O

-

-

O

Unified Code Occurrence
for Units of duration
Measure
(UCUM)

14

1..10= NM

[0..1]

O

-

-

O

Page 136
February 2010

Urgency of the request. If this field is
blank, the default is R (routine). Multiple
priorities may be assigned to one order.

Conjunction

Total occurrence's

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

Example:
TQ1|1||||||200907291200+0400||R^Routine^HL70485

5.12 OBX – OBSERVATION/RESULT SEGMENT
The Observation/Result Segment (OBX) contains information regarding a single observation related to a single test (OBR) or specimen (SPM). This includes
identification of the specific type of observation, the result for the observation, when the observation was made, etc.
Table 5-12. Observation/Result Segment (OBX)

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

1

1..4

SI

[1..1]

R

R

R

R

2

2..3

ID

[0..1]

CE

CE

CE

CE

HL70125

Set ID – OBX

For the first repeat of the OBX segment,
the sequence number shall be one (1), for
the second repeat, the sequence number
shall be two (2), etc.

Value Type

This field identifies the data type used for
OBX-5.
Conditional statement: If OBX-5 is
populated, OBX-2 is required. See
Section 5.8.1, HL7 Table 0125 for the
data types that will be supported for this
field and OBX-5.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 137
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
3

CWE

[1..1]

R

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

R

EHR

Value Set HL7 Element

Description/Comments

Laboratory Observation
Observation Identifier
Identifier
Value Set

Unique identifier for the type of
observation. This field provides a code for
the type of observation. OBX-3 in
conjunction with OBX-4 Observation SubID should uniquely identify this OBX from
all other OBXs associated with this OBR.

Name

Usage
R

LOINC is used as the coding system for
this field except where the test being
reported has no equivalent LOINC code.
In this case, use of local codes is allowed.
This should only occur for new tests that
have yet been coded by LOINC.
When populating this field with values, this
guide does not give preference to the
triplet in which the standard (LOINC) code
should appear.
Lab to EHR - LOINC® is an HL7 approved
code system and shall be used for the
Observation Identifier as described in the
appropriate HITSP Interoperability
Specification. Use of LOINC codes for
additional tests is strongly encouraged.
4

1..20= ST

Page 138
February 2010

[0..1]

CE

CE

C

C

Observation Sub- Harmonized condition predicate: Required
ID
if there is more than one OBX with the
same OBX-3 Observation Identifier
associated with the same OBR. Normally,
this field is populated with a number, but
text values may be used also.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
5

6

Var

CWE

[0..1]

[0..1]

CE

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

CE

Receiver

RE

O

EHR

Value Set HL7 Element

Description/Comments

Observation Value
For coded
observation
values, use
Coded
Laboratory
Observation
Value Set.

Field that documents each specific,
allowed data type. See Section 6.1.1.1,
HL7 Table 0125 for the data types that will
be supported for this field.

Unified Code Units
for Units of
Measure
(UCUM)

UCUM® is an HL7-approved code system
and shall be used for units as described in
the appropriate HITSP Interoperability
Specification. The UCUM unit of measure
for values without a unit of measure is “1”.

Name

Usage
C

CE

Harmonized Condition predicate: Either
OBX-5 or OBX-8 (Abnormal flags) must be
present in the message except if OBX-11
is ‘X”, result can not be obtained.

Harmonized Conditional statement: If the
data type in OBX 2 is "NM" or "SN" and
the OBX-11 observation result status is
not ‘X’ then this field is required.
7

1..60= ST

[0..1]

RE

RE

RE

RE

References
Range

Interpretation range that applies to the
value reported in OBX-5. It should provide
enough information to understand the
abnormal flags reported in OBX-8.
ELR Note-It is not appropriate to send the
reference range for a result in an
associated NTE segment. It would be
appropriate to send information amplifying
the reference range provided in this field
in an NTE associated with this OBX.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 139
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
8

1..20= CWE

[0..*]

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

Receiver

RE

EHR

Value Set HL7 Element

Description/Comments

Lab to EHR, Abnormal Flags
NHSNHL70078
(2.5.1)

Indicator of the normalcy of the result
found in OBX-5. Cardinality indicates the
possible need for multiple abnormal flags,
as in the following example:
Example: Hemoglobin has a normal range
of 12-16
Initial result (reported in a separate ORU
message based on testing an earlier
specimen): HGB = 15.9 (results normal)
Current result (in this OBX based on
current specimen): HGB = 11.9
abnormality: (L) below low normal and a
(D) significant change down (delta > 3).

Name

Usage
RE

ELRHL70078
(2.7)

In this example, OBX-8 would be set to
|L~D|.
Microbiology example:
Ceftazidime susceptibility (LOINC 133-9)
value = |<=^1|, units = ug/ml, Abnormal
flag = S
ELR-Note that this IG is adopting
HL70078 form 2.7.
NHSN has pre-adopted the CWE data
type for this field from 2.7.
ELR Condition predicate: Required if
OBX-5 is empty the OBX-11 observation
result status is not ‘X’, result cannot be
obtained.
Page 140
February 2010

NHSN Cardinality: NHSN supports a
single
Abnormal
Flag. R1 (US Realm)
HL7 Version 2.5.1 IG: Electronic Lab Reporting
to Public
Health,
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Usage

9

1..5#

NM

[0..1]

O

O

O

O

10

1..2

ID

[0..1]

O

O

O

O

HL70080

Nature of
Abnormal Test

11

1..1

ID

[1..1]

R

R

R

R

HL70085

Observation
Result Status

TS

[0..1]

O

O

O

O

Effective Date of
Reference Range

ST

[0..1]

O

O

O

O

User-Defined
Access Checks

12
13

20=

Description/Comments

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Probability

Status of the observation result.

Page 141
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
14

TS

[0..1]

CE

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

CE

Receiver

RE

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
RE

Date/Time of the
Observation

The date/time of observation is intended
to carry the clinically relevant time of the
observation. For specimen-based
laboratory reporting, the specimen
collection date and time. For observations
carried out directly on a patient for
instance, such as a blood pressure, the
time the observation was performed also
happens to be the clinically relevant time
of the observation.
The date/time the testing was performed
should be reported in OBX-19
ELR Condition predicate: For observations
related to the testing of a specimen, OBX14 (Date/Time of the Observation) shall
contain specimen collection time and will
be the same value as OBR-7 and SPM17.1.
Format:
YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]]]+/ZZZZ] except when reporting an unknown
date of ‘0000”.

Page 142
February 2010

Note that in the past; OBX-14 was often
used to carry the time of testing a
specimen, even though HL7 clearly stated
it should be the specimen collection
date/time in that case. In this IG, the time
the testing was performed will be carried
in OBX-19, and OBX-14 will be used for its
HL7tointended
purpose. R1
Previous
version
HL7 Version 2.5.1 IG: Electronic Lab Reporting
Public Health,
(US Realm)
of
HL7
did
not
contain
OBX-19.
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element

Description/Comments

Local

If populated the field must identify the
same performing organization as that
identified in OBX-23 (Performing
Organization Name).

Name

Usage

15

CWE

[0..1]

O

O

O

O

16

XCN

[0..*]

O

O

O

O

Responsible
Observer

17

CWE

[0..*]

RE

RE

RE

O

HL7 V3
Observation
Observation Method
Method

Producer’s
Reference

Method of testing by the laboratory. If the
LOINC code in OBX-3 is methodless, this
field shall be populated. Sometimes the
method may be extrapolated from the
local test codes.
NHSN Cardinality: NHSN supports a
single Observation Method.

18

EI

[0..*]

O

O

O

O

Equipment
Instance Identifier

19

TS

[0..1]

RE

RE

RE

RE

Date/Time of the
Analysis

Time at which the testing was performed.

Reserved for
harmonization
with Version 2.6.

Not supported.

20

(TBD) [0..0]

X

X

X

X

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Note that in the past; OBX-14 was often
used to carry the time of testing a
specimen, even though HL7 clearly stated
it should be the specimen collection
date/time in that case. In this IG, the time
the testing was performed will be carried
in OBX-19, and OBX-14 will be used for its
HL7 intended purpose.

Page 143
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-12. OBSERVATION/RESULT SEGMENT (OBX)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
21

(TBD) [0..0]

22

(TBD) [0..0]

23

XON

[1..1]

X

R

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

X

X

X

Reserved for
harmonization
with Version 2.6.

Not supported.

X

X

X

Reserved for
harmonization
with Version 2.6.

Not supported.

R

O

R

Performing
Organization
Name

The information for producer ID is
recorded as an XON data type.
For laboratories, this field specifies the
laboratory that produced the test result
described in this OBX segment. This
information supports CLIA regulations in
the US. For producing laboratories that
are CLIA-certified, the CLIA identifier
should be used for the organization
identifier (component 10).

24

XAD

[1..1]

R

R

O

R

Performing
Organization
Address

Address of the laboratory that actually
performed the test when used as a
reference laboratory.

25

XCN

[0..1]

RE

RE

O

RE

Performing
Organization
Medical Director

Name of the Medical Director of the
reference laboratory. Required when
OBX-24 indicates the performing lab is in
a jurisdiction that requires this information.

Example:
OBX|1|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|1|66543000^Campylobacter jejuni^SCT^^^^January
Page 144
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

2007||||||P|||200906041458|||0086^Bacterial identification^OBSMETHOD^^^^50120080815||200906051700||||GHH Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1.113883.19.4.6&ISO^L^^^NPI
5.12.1 Observation Identifiers, Observation Values, Interpretations and Comments
Laboratory results fall into several broad categories or types of results. The first type of result is a quantitative measure of some property of a specimen and is typically
numerical in nature. Often these numeric results are also associated with some sort of interpretation, typically in terms of the normality or abnormality of the measured
quantity in relationship to a reference range or normal range. Another type of result is a qualitative result related to the testing of a specimen. This is typically coded or
textual in nature. Qualitative results may actually be interpretations of more detailed quantitative measurement. Finally, both quantitative and qualitative results may
have comments associated with them. These comments may provide additional clarification, information regarding how the result was obtained, etc.
How a particular result should be reported using the OBX segment above depends upon what is being used as an observation identifier for OBX-3. This guide assumes
that LOINC is normally being used for the identification of observations. LOINC identifiers can easily be classified as quantitative or qualitative. The LOINC scale
property QN (quantitative) indicates that the LOINC identifier is quantitative. All other LOINC identifiers can be treated as qualitative for the purpose of this discussion.
Those OBX’s associated with quantitative LOINC identifiers should be using OBX-5 with either the NM (numeric), SN (structured numeric), TS (timestamp), DT (date)
or TM (time) data types. These quantitative results can be accompanied by an interpretation. Coded interpretations should be reported using OBX-8 (abnormal flags)
when the values have been drawn from HL7 table 0078. When a coded interpretation is sent, or when a textual interpretation is sent, a second OBX using a nonquantitative LOINC identifier should be used.
So far, we have been talking about actual clinical findings, whether they are quantitative or qualitative. Often, additional clarifying documentation is sent along with the
clinical findings. These should be handled as comments, conveyed in an NTE segment(s) following the OBX in question. Comments typically fall into the following
categories:
•

Comments about how a clinical finding was reached

•

Clarification regarding the meaning of a clinical finding

•

Additional information not directly related to the clinical finding such as contact information for the lab, disclaimers, etc.

•

Most canned, or boiler plate text associated with a result falls into the comment category,

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 145
February 2010

Chapter 5: Segment and Field Descriptions
Table 5-13. Observation Identifiers

TABLE 5-13. OBSERVATION IDENTIFIERS
OBX.3
Testing

OBX.2

Discussion

Type

situation

Observation

Numeric result along
NM
with interpretation
Numerical intervals,
SN
ratios, inequalities
Time like quantitative
result with
TS, TM, DT,
interpretation

Conveys ordinal
value and
interpretation
Conveys ordinal
value and
interpretation

Page 146
February 2010

CWE

SN

Observation
Identifier:

OBX.5

scale

value

LOINC part =

OBX.7

Observation

OBX.6

number

May be populated
with codes from HL7
UCUM Units required table 0078
May be populated

May be populated
with comments, not
clinical findings.

QN

structured numeric

May be populated
with codes from HL7
UCUM Units required table 0078
May be populated

May be populated
with comments, not
clinical findings.

QN

timestamp, time or
date

[empty]

May be populated
with codes from HL7
May be populated
table 0078

May be populated
with comments, not
clinical findings.

ORD

Ordinal as a code.
SNOMED CT shall
be used when code
exists; otherwise it’s
a local code.
Sending ordinals as
codes is the
preferred ELR
approach.
[empty]

May be populated
with codes from HL7
table 0078
May be populated

May be populated
with comments, not
clinical findings.

ORD

Ordinal as structured
[empty]
numeric

May be populated
with codes from HL7
Required
table 0078

May be populated
with comments, not
clinical findings.

QN

Units

OBX.8

Reference

Abnormal Flags Range

NTE Segment

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-13. OBSERVATION IDENTIFIERS
OBX.3
Testing

OBX.2

Discussion

Type

situation

Observation

Conveys observation
and interpretation
CWE
Conveys observation
and interpretation
FT, TX or ST
Conveys observation
FT, TX or ST
and interpretation
Conveys imbedded
object (ED) or pointer
ED, RP
to object (RP)

Observation
Identifier:

OBX.5

scale

value

LOINC part =

NOM

NAR

Observation

OBX.6

OBX.8

OBX.7

Reference

Abnormal Flags Range

NTE Segment

Coded observation.
SNOMED CT shall
be used when code
exists; otherwise it’s
a local code.
[empty]

May be populated
with codes from HL7
table 0078
May be populated

May be populated
with comments, not
clinical findings.

text

[empty]

May be populated
with codes from HL7
table 0078
May be populated

May be populated
with comments, not
clinical findings.

[empty]

May be populated
with codes from HL7
May be populated
table 0078

May be populated
with comments, not
clinical findings.

[empty]

May be populated
with comments, not
clinical findings.

MULTI

text

Varies

Object pointer or
imbedded object

Units

[empty]

[empty]

5.13 SPM – SPECIMEN SEGMENT
The Specimen Information Segment (SPM) describes the characteristics of a single sample. The SPM segment carries information regarding the type of specimen, where
and how it was collected, who collected it and some basic characteristics of the specimen.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 147
February 2010

Chapter 5: Segment and Field Descriptions
Table 5-14. Specimen Segment (SPM)

TABLE 5-14. SPECIMEN SEGMENT (SPM)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

1

2

1..4

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

SI

[1..1]

R

R

O

R

Set ID – SPM

For the first repeat of the SPM segment, the
sequence number shall be one (1), for the
second repeat, the sequence number shall be
two (2), etc.

EIP

[1..1]

R

R

R

RE

Specimen ID

Unique identifier for the specimen as referenced
by the Placer application, the Filler application,
or both.
Note that the specimen id is not the same thing
as the placer/filler order number. Order numbers
identify the specific test to be performed on a
specimen. A particular specimen may be
associated with multiple orders (and multiple
placer/filler order numbers). The specimen id
may be the same as an accession number,
depending on how the particular lab assigns
accession numbers.

3

EIP

[0..*]

O

O

O

O

4

CWE [1..1]

R

R

R

R

Specimen
Type Value
Set

5

CWE [0..*]

RE

RE

O

O

PHVS_Modif Specimen Type
ierOrQualifie Modifier
r_CDC

6

CWE [0..*]

RE

RE

O

O

HL70371

Page 148
February 2010

Specimen Parent
IDs
Specimen Type

Description of the precise nature of the entity
that is the source material for the observation.
Allows sending qualifiers for a SNOMED CT
term from a single axis. Only used if SPM-4 is a
SNOMED code.

Specimen
Additives

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-14. SPECIMEN SEGMENT (SPM)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

7

CWE [0..1]

RE

RE

O

RE

Specimen
Collection
Method
Value Set

Method used to collect the specimen.
Specimen
Collection Method

8

CWE [0..1]

RE

RE

RE

RE

Body Site
Value Set

Specimen Source Source from which the specimen was obtained.
Site
For environmental samples, this may describe
the location of the source of the specimen. For
biological samples, it may represent the
anatomical site from which the specimen was
collected.

9

CWE [0..*]

RE

RE

O

RE

PHVS_Modif Specimen Source Modifier or qualifier for the specimen source site
ierOrQualifie Site Modifier
(SPM-8). Allows sending qualifiers for a
r_CDC
SNOMED CT term from a single axis. Only used
if SPM-8 is a SNOMED code. This allows use of
post-coordinated terminologies for specimen
source.

10

CWE [0..1]

O

O

O

O

HL70543

Specimen
Collection Site

11

CWE [0..*]

RE

RE

O

O

HL70369

Specimen Role

12

CQ

[0..1]

RE

RE

O

RE

Unified Code Specimen
for Units of Collection
Measure
Amount
(UCUM)

NM

[0..1]

O

O

O

O

Grouped
Specimen Count

ST

[0..*]

O

O

O

O

Specimen
Description

13
14

1..6=

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Amount of sample collected. This can be
reported as a volume or a weight/mass.

NHSN Cardinality: NHSN supports a single
specimen description.
Page 149
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-14. SPECIMEN SEGMENT (SPM)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

15

CWE [0..*]

O

O

O

O

HL70376

Specimen
Handling Code

16

CWE [0..*]

O

O

O

O

HL70489

Specimen Risk
Code

17

DR

R

R

RE

RE

[1..1]

Specimen
Collection
Date/Time

Time range over which the sample was
collected, as opposed to the time the sample
collection device was recovered. The first
component of the date range must match OBR-7
Observation Date/Time. The second component
must match OBR-8 Observation End Date/Time.
For OBXs reporting observations based on this
specimen, OBX-14 should contain the same
value as component 1 of this field.
A minimum of year, month and day must be
provided when the actual date/time is known.
For unknown collection date/time use "0000".
Format:
|YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]][+/ZZZZ]^YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]][+/
-ZZZZ]|

18

TS

[1..1]

R

R

RE

RE

Specimen
Received
Date/Time

Time the specimen was received at the
diagnostic service. The actual time that is
recorded is based on how specimen receipt is
managed, and may correspond to the time the
sample is logged in.
Format:
YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]][+/-ZZZZ]

Page 150
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

TABLE 5-14. SPECIMEN SEGMENT (SPM)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

19

20

1..1

Receiver

Receiver

EHR

Value Set HL7 Element Description/Comments
Name

Usage

TS

[0..1]

O

O

O

O

ID

[0..1]

O

O

O

O

HL70136

Specimen
Availability

Specimen
Expiration
Date/Time

21

CWE [0..*]

RE

RE

O

O

HL70490

Specimen Reject
Reason

22

CWE [0..1]

O

O

O

O

HL70491

Specimen Quality

23

CWE [0..1]

O

O

O

O

HL70492

Specimen
Appropriateness

24

CWE [0..*]

O

O

O

O

HL70493

Specimen
Condition

25

CQ

[0..1]

O

O

O

O

Unified Code Specimen
for Units of Current Quantity
Measure
(UCUM)

NM

[0..1]

O

O

O

O

27

CWE [0..1]

O

O

O

O

Local

Container Type

28

CWE [0..1]

O

O

O

O

HL70544

Container
Condition

29

CWE [0..1]

O

O

O

O

HL70494

Specimen Child
Role

26

1..4=

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Number of
Specimen
Containers

Page 151
February 2010

Chapter 5: Segment and Field Descriptions

Example:
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.840.1.113883.19.3.1.6&ISO||WB^
Whole Blood^HL70487^^^^^2.5.1||THYO^Thyoglycollate broth^HL70371^^^^2.5.1|BCAE^Blood Culture,
Aerobic Bottle^HL70488^^^^2.5.1|49852007^Structure of median cubital vein (body
structure)^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|2.0^mL&MilliLiter [SI Volume
Units]&UCUM&&&&1.6|||||200808151030-0700|200808151100-0700

5.14 NTE – NOTES AND COMMENTS SEGMENT
The Notes and Comments Segment (NTE) is used to convey additional comments regarding the associated segment. The NTE segment is not intended for automatic
processing. The contents of the NTE segment are primarily intended for human use. Automated process should not be based upon the contents of NTE-3 (Comment);
rather the content of that field should be displayed to humans.
Table 5-15. Notes and Comments Segment (NTE)

TABLE 5-15. NOTES AND COMMENTS SEGMENT (NTE)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

2

1..1

3

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

SI

[1..1]

R

R

RE

-

ID

[0..1]

RE

RE

RE

-

FT

[1..*]

R

R

RE

-

Set ID – NTE

HL70105

For the first repeat of the NTE segment,
the sequence number shall be one (1), for
the second repeat, the sequence number
shall be two (2), etc.

Source of
Comment
Comment

Comment contained in the segment.
NHSN Cardinality: NHSN supports a
single comment.

4

Page 152
February 2010

CWE

[0..1]

RE

RE

O

-

HL70364

Comment Type

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

Example:
NTE|1|L|Comment goes here.

It can be a very long comment.|RE^Remark^HL70364^^^^2.5.1

5.15 FHS – FILE HEADER SEGMENT
This segment is used as the lead-in to a file (group of batches).
Table 5-16. File Header Segment (FHS)

TABLE 5-16. FILE HEADER SEGMENT (FHS)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Usage

Value
Set

HL7

Element

Description/Comments

Name

1

1..1

ST

[1..1]

R

R

R

-

File Field
Separator

Character to be used as the field
separator for the rest of the message.
The supported value is |, ASCII (124).

2

4..5

ST

[1..1]

R

R

R

-

File Encoding
Characters

Four characters that always appear in the
same order in this field: |^~\&|.

3

HD

[0..1]

O

O

O

-

File Sending
Application

4

HD

[1..1]

R

O

R

-

File Sending
Facility

5

HD

[0..1]

O

O

O

-

File Receiving
Application

6

HD

[1..1]

R

O

R

-

File Receiving
Facility

Unique identifier of the facility that is to
receive the message. This field has the
same definition as the corresponding field
in the MSH segment.

7

TS

[1..1]

R

O

R

-

File Creation
Date/Time

Date/time the file was created by the
sending system.

8

1..40= ST

[0..0]

X

X

X

-

File Security

Not Supported.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

NHSN - Party ID – same one as used in
PHIN MS wrapper.

Page 153
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-16. FILE HEADER SEGMENT (FHS)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Usage

Value
Set

HL7

Element

Description/Comments

Name

9

1..40= ST

[0..1]

O

O

O

-

File Name/ID

10

1..80= ST

[0..0]

X

X

X

-

File Header
Comment

Not Supported.

11

1..20= ST

[0..0]

X

X

X

-

File Control ID

Not Supported.

12

1..20= ST

[0..0]

X

X

X

-

Reference File
Control D

Not Supported.

Example:
FHS|^~\&||Lab1^2.16.840.1.113883.19.3.1^ISO||SPH^2.16.840.1.113883.19.3.2^ISO|200807231235580400

5.16 FTS – FILE TRAILER SEGMENT
The FTS segment defines the end of a file (group of batches).

Page 154
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions
Table 5-17. File Trailer Segment (FTS)

TABLE 5-17. FILE TRAILER SEGMENT (FTS)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

1

1..10= NM

[1..1]

R

O

R

-

File Batch Count

The number of batches contained in this
file. Since this interface is constrained to
one batch per file, this number should
always be ‘1’.

2

1..80# ST

[0..0]

X

X

X

-

File Trailer
Comment

Not supported.

Example:
FTS|1

5.17 BHS – BATCH HEADER SEGMENT
This segment is used as the lead-in to a file (group of batches).
Table 5-18. Batch Header Segment (BHS)

TABLE 5-18. BATCH HEADER SEGMENT (BHS)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
1

1..1

ST

[1..1]

R

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

R

Receiver

R

EHR

Value Set HL7 Element
Name

Description/Comments

Usage
-

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Batch Field
Separator

Character used as the field separator for
the rest of the message. The supported
value is |, ASCII (124).
Page 155
February 2010

Chapter 5: Segment and Field Descriptions

TABLE 5-18. BATCH HEADER SEGMENT (BHS)
Seq

Len

DT

Cardinality Lab

Result

Sender
Usage
2

4..5

ELR

NHSN

Lab to

Usage

Usage

Receiver

Receiver

Receiver

EHR

Value Set HL7 Element
Name

Description/Comments

Usage

ST

[1..1]

R

R

R

-

Batch Encoding
Characters

3

HD

[0..1]

O

O

O

-

Batch Sending
Application

4

HD

[1..1]

R

O

R

-

Batch Sending
Facility

5

HD

[0..1]

O

O

O

-

Batch Receiving
Application

6

HD

[1..1]

R

O

R

-

Batch Receiving
Facility

Unique identifier of the facility that is to
receive the message. This field has the
same definition as the corresponding field
in the MSH segment.

7

TS

[1..1]

R

O

R

-

Batch Creation
Date/Time

Date/time the batch was created by the
sending system.

8

1..40= ST

[0..0]

X

X

X

-

Batch Security

Not supported.

9

1..40= ST

[0..1]

O

O

O

-

Batch
Name/ID/Type

10

1..80= ST

[0..0]

X

X

X

-

Batch Comment

Not supported.

11

1..20= ST

[0..0]

X

X

X

-

Batch Control ID

Not supported.

12

1..20= ST

[0..0]

X

X

X

-

Reference Batch
Control D

Not supported.

Page 156
February 2010

Four characters that always appear in the
same order in this field: |^~\&|.

NHSN-Party ID – same one as used in
PHIN MS wrapper.

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 5: Segment and Field Descriptions

Example:
BHS|^~\&|| Lab1^2.16.840.1.113883.19.3.1^ISO||SPH^2.16.840.1.113883.19.3.2^ISO|200807231235580400

5.18 BTS – BATCH TRAILER SEGMENT
The BTS segment defines the end of a batch of messages.
Table 5-19. Batch Trailer Segment (BTS)

TABLE 5-19. BATCH TRAILER SEGMENT (BTS)
Seq

Len

DT

Cardinality

Lab

ELR

NHSN

Lab to

Sender

Usage

Usage

Receiver

Result
Usage

Receiver

Receiver

EHR

Usage

Value
Set

HL7

Element

Description/Comments

Name

1

10

NM

[1..1]

R

R

R

-

Batch Message
Count

This is the total number of messages
contained in the batch.

2

80

ST

[0..0]

X

X

X

-

Batch Comment

Not supported.

3

100

NM

[0..0]

X

X

X

-

Batch Totals

Not supported.

Example:
BTS|100

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Page 157
February 2010

Chapter 6: Code Systems and Value Sets

6. Code Systems and Value
Sets
Successful message implementation requires that transmitted messages (message instances) contain valid values for
coded fields. It is important to note that code sets are relatively dynamic and subject to change between publications
of these implementation guides.
Every code value passed in a message instance is drawn from a code system that has a globally unique identifier,
such as an OID. In general, the coded values allowed in a field (a) may be drawn from more than one code system,
and (b) may be a subset of the codes from a given coding system. Combining (a) and (b) makes it possible for the
allowed code value to be a combination of multiple subsets drawn from multiple coding systems. In most cases,
only a subset of the codes defined in a code system are legal for use in a particular message.
The subsets of the codes that are legal for a particular field is identified by an HL7 construct known as a "value set."
A value set is a collection of coded values drawn from code systems. Value sets serve to identify the specific set of
coded values for the message from the universe of coded values across all coding systems.
The segment tables in previous sections identify the value set or coding system used for each supported field
containing a coded value. Fields that use the data type CWE require that messages include the code, drawn from
HL7 0396, that uniquely defines the coding system, as well as the coded value itself. Some of these pre-coordinated
value sets must be updated, or new ones created, as new needs are identified.
Value sets are identified by a unique identifier also, but this identifier is not transmitted in the message. The
identifier or code for the coding system from which the value is derived is sent in the message. However, the value
set identifier is useful and important when vocabulary items are modified or replaced.

Page 158
February 2010

HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm)
© 2010 Health Level Seven International. All rights reserved.

Chapter 6: Code Systems and Value Sets

6.1 VOCABULARY CONSTRAINTS
Table 6-1. Value Set/Code System Summary shows the various value sets/code systems used in this IG. It also provides information about the source of the vocabulary and an
identifier for the vocabulary. The name found in the Value Set/Code System Name column corresponds with the value set identified in the Value Set column of the data type
and segment attribute tables found above.
Table 6-1. Value Set/Code System Summary

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code

Admission Type Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.33

Body Site Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.3221.8 Specimen Source Site. Identify the body site for injury, specimen, injection and
.9
finding. Shall contain a value descending from the SNOMED CT® Anatomical
Structure (91723000) hierarchy. This indicates the anatomical site

Country Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.63

Name

System Source

Value Set/Code System

Description

Value Set/Code System

Identifier

A code indicating the priority of the admission (e.g., Emergency, Urgent, Elective,
et cetera). See (UB-04/NUBC CURRENT UB DATA SPECIFICATIONS
MANUAL) UB-04 FL14

This identifies the codes for the representation of names of countries, territories
and areas of geographical interest. The complete set of 3166-1 codes.
http://www.iso.org/iso/iso-3166-1_decoding_table
Also available from PHIN VADS as: PHVS_Country_ISO_3166-1
Also known as HL7 Table 0399.

ELR Reportable Laboratory
Observation Identifier Value Set

TBD

TBD

This value set is determined by specific ELR implementations. The specific
reportable laboratory observation identifiers are often state or jurisdiction specific.

HL7 V3 Observation Method

HL7 Version 3.0

2.16.840.1.113883.5.84 (code
system)

Observation Method

2.16.840.1.113883.12.1 (code
system)

Administrative Sex.

HL70001

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_LabTestMethods_CDC
Also available from PHIN VADS as: PHVS_AdministrativeSex_HL7_2x

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 159-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70002

HL7 Version 2.5.1

2.16.840.1.113883.12.2 (code
system)

Marital Status.

Name

System Source

Identifier

Note, HITSP has identified a different value set in HITSP C80:
Name: Marital Status Value Set
Source: Health Level Seven (HL7) Version 3.0
The HL7 Lab to EHR IG adopted by HITSP uses the HL70002

HL70003

HL7 Version 2.5.1

2.16.840.1.113883.12.3 (code
system)

Event type

HL70004

HL7 Version 2.5.1

2.16.840.1.113883.12.4 (code
system)

Patient Class
Also available from PHIN VADS as: PHVS_PatientClass_HL7
Note, HITSP has identified a different value set in HITSP C80:
Name: Patient Class Value Set
Source: Health Level Seven (HL7) Version 3.0 Act Encounter Code
The HL7 Lab to EHR IG adopted by HITSP uses the HL70004

HL70005

HL7 Version 2.5.1

2.16.840.1.113883.6.238 (code
system)

Race Category
Also available from PHIN VADS as: PHVS_RaceCategory_CDC

HL70006

HL7 Version 2.5.1

2.16.840.1.113883.12.6 (code
system)

Religion

HL70008

HL7 Version 2.5.1

2.16.840.1.113883.12.8 (code
system)

Acknowledgment code
Also available from PHIN VADS as: PHVS_AcknowledgmentCode_HL7_2x

HL70018

HL7 Version 2.5.1

2.16.840.1.113883.12.18 (code
system)

Patient Type

HL70021

HL7 Version 2.5.1

2.16.840.1.113883.12.21 (code
system)

Bad Debt Agency Code

Page 160-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70023

HL7 Version 2.5.1

2.16.840.1.113883.12.23 (code
system)

Admit Source

Name

System Source

Identifier

Also available from PHIN VADS as: PHVS_AdmitSource_HL7_2x
Note, HITSP has identified a different value set in HITSP C80:
Name: Admission Source Value Set
Source: National Uniform Billing Committee (NUBC). See UB-04/NUBC
CURRENT UB DATA SPECIFICATIONS MANUAL) UB-04 FL15
The HL7 Lab to EHR IG adopted by HITSP does not support this element.

HL70038

HL7 Version 2.5.1

2.16.840.1.113883.12.38 (code
system)

Order status
Also available from PHIN VADS as: PHVS_OrderStatus_HL7_2x

HL70061

HL7 Version 2.5.1

2.16.840.1.113883.12.61 (code
system)

Check digit scheme

HL70063

HL7 Version 2.5.1

2.16.840.1.113883.12.63 (code
system)

Relationship
Also available from PHIN VADS as: PHVS_Relationship_HL7_2x

HL70065

HL7 Version 2.5.1

2.16.840.1.113883.12.65 (code
system)

Specimen Action Code

HL70074

HL7 Version 2.5.1

2.16.840.1.113883.12.74 (code
system)

Diagnostic Service Sector ID
Also available from PHIN VADS as: PHVS_DiagnosticServiceSectionID_HL7_2x

HL70076

HL7 Version 2.5.1

2.16.840.1.113883.12.76 (code
system)

Message type

HL70078 (2.5.1)

HL7 Version 2.5.1

2.16.840.1.113883.12.78 (code
system)

Abnormal Flags
Also available from PHIN VADS as: PHVS_AbnormalFlag_HL7_2x
Note, HITSP has identified a different value set in HITSP C80:
Name: Result Normalcy Status Value Set
Source: Health Level Seven (HL7) Version 3.0 Observation Interpretation.
The HL7 Lab to EHR IG adopted by HITSP uses the HL70078 from 2.5.1.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 161-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70078 (2.7)

HL7 Version 2.7

2.16.840.1.113883.12.78 (code
system)

Observation Interpretation.

HL70080

HL7 Version 2.5.1

2.16.840.1.113883.12.80 (code
system)

Nature of Abnormal Test

HL70085

HL7 Version 2.5.1

2.16.840.1.113883.12.85 (code
system)

Observation Result Status

Name

System Source

Identifier

Also available from PHIN VADS as: PHVS_ObservationResultStatus_HL7_2x

HL70087

HL7 Version 2.5.1

2.16.840.1.113883.12.87 (code
system)

Pre-Admit Test Indicator

HL70088

HL7 Version 2.5.1

2.16.840.1.113883.12.88 (code
system)

Procedure Code

HL70103

HL7 Version 2.5.1

2.16.840.1.113883.12.103 (code
system)

Processing ID.
Also available from PHIN VADS as: PHVS_ProcessingID_HL7_2x

HL70104

HL7 Version 2.5.1

2.16.840.1.113883.12.104 (code
system)

Version ID

HL70105

HL7 Version 2.5.1

2.16.840.1.113883.12.105 (code
system)

Source of Comment
Also available from PHIN VADS as: PHVS_SourceOfComment_HL7_2x

HL70111

HL7 Version 2.5.1

2.16.840.1.113883.12.111 (code
system)

Delete Account Code

HL70112

HL7 Version 2.5.1

2.16.840.1.113883.12.112 (code
system)

Discharge Disposition
Also available from PHIN VADS as: PHVS_DischargeDisposition_HL7_2x
Note, HITSP has identified a different value set in HITSP C80:
Name: Discharge Disposition Value Set
Source: National Uniform Billing Committee (NUBC). UB-04/NUBC CURRENT
UB DATA SPECIFICATIONS MANUAL- UB-04 FL17 – Patient Status.
The HL7 Lab to EHR IG adopted by HITSP uses the HL70112.

Page 162-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70114

HL7 Version 2.5.1

2.16.840.1.113883.12.114 (code
system)

Diet type

HL70115

HL7 Version 2.5.1

2.16.840.1.113883.12.115 (code
system)

Servicing Facility

HL70117

HL7 Version 2.5.1

2.16.840.1.113883.12.117 (code
system)

Account status

HL70119

HL7 Version 2.5.1

2.16.840.1.113883.12.119 (code
system)

Order Control.

2.16.840.1.113883.12.121 (code
system)

Response flag

Name

HL70121

System Source

HL7 Version 2.5.1

Identifier

Also available from PHIN VADS as: PHVS_OrderControlCodes_HL7_2x
Also available from PHIN VADS as: PHVS_ResponseFlag_HL7_2x

HL70125

HL7 Version 2.5.1

2.16.840.1.113883.12.125 (code
system)

Value Type

HL70136

HL7 Version 2.5.1

2.16.840.1.113883.12.136 (code
system)

Yes/No
Also available from PHIN VADS as: PHVS_YesNo_HL7_2x

HL70155

HL7 Version 2.5.1

2.16.840.1.113883.12.155 (code
system)

Accept/application acknowledgment condition

HL70171

HL7 Version 2.5.1

2.16.840.1.113883.12.171 (code
system)

Citizenship

HL70172

HL7 Version 2.5.1

2.16.840.1.113883.12.172 (code
system)

Veterans Military Status

HL70177

HL7 Version 2.5.1

2.16.840.1.113883.12.177 (code
system)

Confidentiality code

2.16.840.1.113883.6.238 (code
system)

Ethnic Group

HL70189

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_ConfidentialityCode_HL7_2x
A constrained version of the value set without the UNK value is available from
PHIN VADS as: PHVS_EthnicityGroup_CDC

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 163-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70190

HL7 Version 2.5.1

2.16.840.1.113883.12.190 (code
system)

Address type.

Name

System Source

Identifier

Also available from PHIN VADS as: PHVS_AddressType_HL7_2x

HL70191

HL7 Version 2.5.1

2.16.840.1.113883.12.191 (code
system)

Type of referenced data

HL70200

HL7 Version 2.5.1

2.16.840.1.113883.12.200 (code
system)

Name type

2.16.840.1.113883.12.201 (code
system)

Telecommunication use code

2.16.840.1.113883.12.202 (code
system)

Telecommunication equipment type

2.16.840.1.113883.12.203 (code
system)

Identifier type.

HL70201

HL70202

HL70203

HL7 Version 2.5.1

HL7 Version 2.5.1

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_NameType_HL7_2x
Also available from PHIN VADS as:
PHVS_TelecommunicationUseCode_HL7_2x
Also available from PHIN VADS as:
PHVS_TelecommunicationEquipmentType_HL7_2x
Also available from PHIN VADS as: PH_IdentifierType_HL7_2x

HL70204

HL7 Version 2.5.1

2.16.840.1.113883.12.204 (code
system)

Organization name type

HL70207

HL7 Version 2.5.1

2.16.840.1.113883.12.207 (code
system)

Processing mode.
Also available from PHIN VADS as: PHVS_ProcessingMode_HL7_2x

HL70211

HL7 Version 2.5.1

2.16.840.1.113883.12.211 (code
system)

Alternate character sets

HL70288

HL7 Version 2.5.1

2.16.840.1.113883.12.288 (code
system)

Census tract

Page 164-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70291 (2.7)

HL7 Version 2.7

2.16.840.1.113883.12.291 (code
system)

Subtype of referenced data.

Name

System Source

Identifier

Also available from PHIN VADS as: PHVS_MIME_MediaSubType_IANA
See Table 6-5. HL7 Table 0291 - Subtype Of Referenced Data below.

HL70297
HL70299
HL70301

HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.7

2.16.840.1.113883.12.297 (code
system)

CN ID

2.16.840.1.113883.12.299 (code
system)

Encoding,

2.16.840.1.113883.12.301 (code
system)

Universal ID type

This is an empty HL7 user defined table, so the codes will all be locally defined.
Also available from PHIN VADS as: PHVS_Encoding_HL7_2x
See Table 6-6. HL7 Table 0301 - Universal ID Type below for details.

HL70302

HL7 Version 2.5.1

2.16.840.1.113883.12.302 (code
system)

Point of care

HL70303

HL7 Version 2.5.1

2.16.840.1.113883.12.303 (code
system)

Room

HL70304

HL7 Version 2.5.1

2.16.840.1.113883.12.304 (code
system)

Bed

HL70305

HL7 Version 2.5.1

2.16.840.1.113883.12.305 (code
system)

Person location type
Note that NHSN has adopted the HL7 Version 3 Healthcare Service Location
coding system for this field.

HL70306

HL7 Version 2.5.1

2.16.840.1.113883.12.306 (code
system)

Location status

HL70307

HL7 Version 2.5.1

2.16.840.1.113883.12.307 (code
system)

Building

HL70308

HL7 Version 2.5.1

2.16.840.1.113883.12.308 (code
system)

Floor

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 165-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70326

HL7 Version 2.5.1

2.16.840.1.113883.12.326 (code
system)

Visit Indicator

HL70340

HL7 Version 2.5.1

2.16.840.1.113883.12.340 (code
system)

Procedure Code Modifier

HL70354

HL7 Version 2.5.1

2.16.840.1.113883.12.354 (code
system)

Message structure

HL70356

HL7 Version 2.5.1

2.16.840.1.113883.12.356 (code
system)

Alternate character set handling scheme

HL70357

HL7 Version 2.5.1

2.16.840.1.113883.12.357 (code
system)

Message Error Condition Codes

2.16.840.1.113883.12.360 (code
system)

Degree/license/certificate

2.16.840.1.113883.12.364 (code
system)

Comment Type

2.16.840.1.113883.12.369 (code
system)

Specimen Role

2.16.840.1.113883.12.371 (code
system)

Specimen Additives

2.16.840.1.113883.12.376 (code
system)

Special Handling Code

Name

HL70360
HL70364
HL70369
HL70371
HL70376

Page 166-230

System Source

HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.5.1

Identifier

Also available from PHIN VADS as:
PHVS_MessageErrorConditionCodes_HL7_2x
Also available from PHIN VADS as: PHVS_DegreeLicenseCertificate_HL7_2x
Also available from PHIN VADS as: PHVS_CommentType_CDC
Also available from PHIN VADS as: PHVS_SpecimenRole_CDC
Also available from PHIN VADS as: PHVS_AdditiveOrPreservative_HL7_2x

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70396

HL7

2.16.840.1.113883.12.396 (code

HL7 Table 0396 defines the standard coding systems recognized by HL7. The
table defines a mechanism by which locally defined codes can be transmitted.
Any code/coding system not defined in HL7 Table 0396 is considered a “local”
coding system from the Hl7 perspective. Coding systems that are identified in
this implementation guide will be identified according to the recommended HL7
nomenclature from table 0396 as “99ELR-zzz” where “zzz” represents a string
identifying the specific non-standard coding system. To maintain backwards
compatibility with the 2.3.1 ELR implementation Guide, coding systems defined
locally (i.e., not identified in this guide) and not defined in HL7 Table 0396 can
continue to identify the coding system as “L”. It is strongly suggested that
implementers instead adopt the use of “99zzz” approach to identifying local
coding systems since HL7 has indicated that use of the “L” for local coding
systems is retained only for backwards compatibility, and its use may be
withdrawn in a subsequent 2.x version. Note that the local use of “99zzz” should
not collide with any of the “locally” defined coding systems identified in this
implementation guide.

Name

System Source

Identifier

http://www.hl7.org/special/ system)
committees/vocab/table_03
96/index.cfm

HL7 now maintains HL7 table 0396 “real time”. This means that values may be
added to the table at any time so that implementers can have an up-to-date
source of truth for the codes to be used to identify coding systems in any 2.x
message. Users of this IG should acquire the latest version of HL7 table 0396.
The latest version of HL7 table 0396 (independent of HL7 version) is available for
download from HL7 at:
http://www.hl7.org/special/committees/vocab/table_0396/index.cfm.
HL70411

HL7 Version 2.5.1

2.16.840.1.113883.12.411 (code
system)

Supplemental Service Information Values

HL70429

HL7 Version 2.5.1

2.16.840.1.113883.12.429 (code
system)

Production Class Code

2.16.840.1.113883.12.432 (code
system)

Admission Level of Care Code

HL70432

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_ProductionClass_HL7_2x
Also available from PHIN VADS as: PHVS_AdmissionLevelOfCareCode_HL7_2x

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 167-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70444

HL7 Version 2.5.1

2.16.840.1.113883.12.444 (code
system)

Name assembly order

HL70445

HL7 Version 2.5.1

2.16.840.1.113883.12.445 (code
system)

Identity Reliability Code

Name

System Source

Identifier

Also available from PHIN VADS as: PHVS_IdentityReliabilityCode_HL7_2x

HL70448

HL7 Version 2.5.1

2.16.840.1.113883.12.448 (code
system)

Name context

HL70465

HL7 Version 2.5.1

2.16.840.1.113883.12.465 (code
system)

Name/address representation

HL70472

HL7 Version 2.5.1

2.16.840.1.113883.12.472 (code
system)

TQ Conjunction ID

HL70476

HL7 Version 2.5.1

2.16.840.1.113883.12.476 (code
system)

Medically Necessary Duplicate Procedure Reason

HL70482

HL7 Version 2.5.1

2.16.840.1.113883.12.482 (code
system)

Order Type

HL70483

HL7 Version 2.5.1

2.16.840.1.113883.12.483 (code
system)

Authorization Mode

HL70485

HL7 Version 2.5.1

2.16.840.1.113883.12.485 (code
system)

Priority
Also available from PHIN VADS as: PHVS_ExtendedPriorityCodes_HL7_2x

HL70487

HL7 Version 2.5.1

2.16.840.1.113883.12.487 (code
system)

Specimen Type

HL70488

HL7 Version 2.5.1

2.16.840.1.113883.12.488 (code
system)

Specimen collection method.

2.16.840.1.113883.12.489 (code
system)

Risk Codes

HL70489

Page 168-230

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_SpecimenCollectionMethod_HL7_2x

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70490

HL7 Version 2.5.1

2.16.840.1.113883.12.490 (code
system)

Specimen Reject Reason

2.16.840.1.113883.12.491 (code
system)

Specimen Quality

2.16.840.1.113883.12.492 (code
system)

Specimen Appropriateness

2.16.840.1.113883.12.493 (code
system)

Specimen Condition

2.16.840.1.113883.12.494 (code
system)

Specimen Child Role

Name

HL70491
HL70492
HL70493
HL70494

System Source

HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.5.1
HL7 Version 2.5.1

Identifier

Also available from PHIN VADS as: PHVS_SpecimenRejectReason_HL7_2x
Also available from PHIN VADS as: PHVS_SpecimenQuality_HL7_2x
Also available from PHIN VADS as: PHVS_SpecimenAppropriateness_HL7_2x
Also available from PHIN VADS as: PHVS_SpecimenCondition_CDC
Also available from PHIN VADS as: PHVS_SpecimenChildRole_HL7_2x

HL70507

HL7 Version 2.5.1

2.16.840.1.113883.12.507 (code
system)

Observation Result Handling

HL70516

HL7 Version 2.5.1

2.16.840.1.113883.12.516 (code
system)

Error severity

2.16.840.1.113883.12.533 (code
system)

Application error code

HL70533

HL7 Version 2.5.1

Also available from PHIN VADS as: PHVS_ErrorSeverity_HL7_2x
Note that Hl7 table 0533 has no suggested values. It is always a user defined
table, and will generally contain locally defined codes.

HL70543

HL7 Version 2.5.1

2.16.840.1.113883.12.543 (code
system)

Specimen Collection Site

HL70544

HL7 Version 2.5.1

2.16.840.1.113883.12.544 (code
system)

This is an empty HL7 user defined table, so it is effectively locally defined.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 169-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

HL70834 (2.7)

HL7 Version 2.7

2.16.840.1.113883.12.834 (code
system)

Imported Table 0834 – MIME Types.

Name

System Source

Identifier

Note that the HITSP Lab to EHR IG uses HL70191, which can be directly
mapped to the 2.7 values imported from IANA.
Also available from PHIN VADS as: PHVS_MIME_MediaType_IANA
See Table 6-7. HL7 Table 0834 – MIME Type below.

ICD-10

TBD

TBD

TBD

Laboratory Observation Identifier
Value Set

TBD

TBD

Unique identifiers for the type of observations. Values must be drawn from
LOINC. This value set is the union of the following value sets:

Laboratory Coded Observation
Value Set

TBD

•

Laboratory Test Result Value Set

•

ELR Reportable Laboratory Observation Identifier Value Set

• NHSN Lab test id value set (TBD)
Drawn from SNOMED CT. At a minimum, it will contain the SNOMED CT®
Laboratory Test Finding (118246004) hierarchy and the SNOMED CT®
Microorganism (264395009) sub-tree. It may also need to contain various
modifiers and qualifiers as identified in PHVS_ModifierOrQualifier_CDC value
set.

TBD

The HITSP C80 Laboratory Observation Value Set covers only the Laboratory
Test Findings portion of this value set, and really needs to be expanded to cover
at least microorganisms and commonly use qualifiers and modifiers.
Laboratory Order Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.25

This identifies the laboratory order. From the LOINC® database, Laboratory
order concepts can be extracted by using the following filter:
CLASSTYPE=1 and
ORDER_OBS= order

Page 170-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Laboratory Test Result Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.40

Name

System Source

Value Set/Code System
Identifier

Description
The value set is defined as being the set of LOINC® values which: are used in
HEDIS measures:
category A/B/C bioterrorism agents/diseases (need help here)
Public Health jurisdiction and Federal reportable disease conditions8

NHSN Lab test id value set

TBD

This value set is still under development by NHSN. At this time, the name is just
a placeholder for the eventual value set.

PH_HealthcareServiceLoc_HL7_V CDC PHIN VADS (see
3
section 6.2 below)

2.16.840.1.113883.6.259 (code
system)

Healthcare Service Locations (HL7) - A comprehensive classification of locations
and settings where healthcare services are provided. This is based on the
National Healthcare Safety Network (NHSN) location code system that has been
developed over a number of years through CDC's interaction with a variety of
healthcare facilities and is intended to serve a variety of reporting needs where
coding of healthcare service locations is required. Keywords: HSLOC,
Healthcare Service Delivery Location

PHVS_AdministrativeDiagnosis_C CDC PHIN VADS (see
DC_ICD-9CM
section 6.2 below)

2.16.840.1.114222.4.11.856

ICD-9 CM Administrative Diagnosis Codes used for billing purposes, Reason for
Study, DG1 Diagnosis segments Keyword: ICD-9 Vol 1 & 2.

PHVS_Animal_CDC

CDC PHIN VADS (see
section 6.2 below)

2.16.840.1.114222.4.11.1074

Animal

PHVS_County_FIPS_6-4

CDC PHIN VADS (see
section 6.2 below)

2.16.840.1.114222.4.11.829

Codes representing county of origin, address county, reporting county

8

TBD

It is the authors understanding that the current HITSP value set for Laboratory Test Results does not include the LOINC codes necessary for ELR reportable conditions. It is expected that HITSP will add these ELR
test codes to the value set as they are identified (per the value set definition).

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 171-230

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

PHVS_Language_ISO_6392_Alpha3

CDC PHIN VADS (see
section 6.2 below)

2.16.840.1.114222.4.11.831

Primary spoken language

Name

System Source

Identifier

Note that HITSP identifies a language value set as follows:
“The value set is defined by Internet RFC 4646 (replacing RFC 3066). Please
see ISO 639 language code set maintained by Library of Congress for
enumeration of language codes and Frequently Asked Questions.”
RFC4646 seems to point to ISO 639 as the source of the actual language codes,
so this value set is consistent with the HITSP value set.

PHVS_Microorganism_CDC

CDC PHIN VADS (see
section 6.2 below)

2.16.840.1.114222.4.11.1009

Postal Code Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.2

Microorganisms/infectious agents
This identifies the postal (ZIP) Code of an address in the United States
http://zip4.usps.com/zip4/welcome.jsp

Reason For Study Value Set

TBD

TBD

Reason for Study. Union of concepts from
PHVS_AdministrativeDiagnosis_CDC_ICD-9CM and ICD-10.
Note: HITSP apparently has stopped using ICD-9 for diagnosis and focused on
using value sets from SNOMED CT.

SNOMED CT Specimen Collection SNOMED CT
(17636008) sub-tree.

2.16.840.1.113883.6.96 (code
system)

SNOMED CT Specimen Collection (17636008) sub-tree.

SNOMED CT Specimen sub-tree
(12303009)

SNOMED CT

2.16.840.1.113883.6.96 (code
system)

SNOMED CT Specimen sub-tree (12303009)

PHVS_ModifierOrQualifier_CDC

CDC PHIN VADS (see
section 6.2 below)

2.16.840.1.114222.4.11.1014

Used for Specimen Type Modifier and Specimen Source Site Modifier. Based on
a subset of SNOMED CT.

TBD

Specimen Collection Method.

Specimen Collection Method Value TBD
Set

Page 172-230

Also available from PHIN VADS as: PHVS_Specimen_CDC

Union of HL7 Table 0488 and SNOMED CT Specimen Collection (17636008)
sub-tree.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-1. VALUE SET/CODE SYSTEM SUMMARY
Value Set/Code System

Value Set/Code

Value Set/Code System

Description

Specimen Type Value Set

TBD

TBD

Specimen Type

Name

System Source

Identifier

Union of HL70487 and SNOMED CT Specimen sub-tree (12303009)
State Value Set

HITSP C-80,20090708 V1.1 2.16.840.1.113883.3.88.12.80.1

Identifies addresses within the United States are recorded using the FIPS 5-2
two-letter alphabetic codes for the State, District of Columbia, or an outlying area
of the United States or associated area. http://www.itl.nist.gov/fipspubs/fip52.htm
Also available from PHIN VADS as: PHVS_State_FIPS_5-2

Tribal Citizenship Value Set

TBD

TBD

Tribal Citizenship
HL7 recommends using Bureau of Indian Affairs (BIA) Tribal Identity List. The
following is a link to the current live list:
http://www.usa.gov/Government/Tribal_Sites/index.shtml
This is a link to the most recent official static list:
http://edocket.access.gpo.gov/2008/E8-6968.htm

2.16.840.1.113883.3.88.12.80.29
Unified Code for Units of Measure Regenstrief Institute, Inc.
(UCUM)
http://www.regenstrief.org/m
edinformatics/ucum

Units of measure concepts that includes atomic UCUM units as well as UCUM
expression. Commonly used UCUM units of measure concepts can be obtained
from UCUM Web Site
http://aurora.regenstrief.org/~ucum/ucum.html#datyp2apdxatblxmp
A tool for converting non-UCUM units of measure to the equivalent UCUM units
is available at:
http://www.regenstrief.org/medinformatics/ucum/unit-conversion-tool
A pre-coordinated value set of common units is also available from PHIN VADS
as: PHVS_UnitsOfMeasure_UCUM

6.1.1 HL7 Tables
This section provides values for HL7 tables that have had constraints applied to them in this IG.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 173-230

Chapter 6: Code Systems and Value Sets

6.1.1.0 HL7 Table 0078 from 2.7
Table 6-2. HL7 Table 0078 from 2.7

TABLE 6-2. HL7 TABLE 0078 FROM 2.7
Value

Description

L

Below low normal

H

Above high normal

LL

Below lower panic limits

HH

Above upper panic limits

<

Below absolute low-off instrument scale

>

Above absolute high-off instrument scale

N

Normal (applies to non-numeric results)

A

Abnormal (applies to non-numeric results)

AA

Very abnormal (applies to non-numeric units, analogous to
panic limits for numeric units)

null

No range defined, or normal ranges don't apply

U

Significant change up

D

Significant change down

B

Better—use when direction not relevant

W

Worse—use when direction not relevant

S

Susceptible. Indicates for microbiology susceptibilities only.

R

Resistant. Indicates for microbiology susceptibilities only.

I

Intermediate. Indicates for microbiology susceptibilities only.

Page 174-230

Comment

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-2. HL7 TABLE 0078 FROM 2.7
Value

Description

MS

Moderately susceptible. Indicates for microbiology
susceptibilities only.

VS

Very susceptible. Indicates for microbiology susceptibilities
only.

POS

Positive

Added in HL7 Version 2.7

NEG

Negative

Added in HL7 Version 2.7

IND

Indeterminate

Added in HL7 Version 2.7

DET

Detected

Added in HL7 Version 2.7

ND

Not Detected

Added in HL7 Version 2.7

AC

Anti-complementary substances present

Added in HL7 Version 2.7

TOX

Cytotoxic substance present

Added in HL7 Version 2.7

QCF

Quality Control Failure

Added in HL7 Version 2.7

RR

Reactive

Added in HL7 Version 2.7

WR

Weakly reactive

Added in HL7 Version 2.7

NR

Non-reactive

Added in HL7 Version 2.7

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Comment

Page 175-230

Chapter 6: Code Systems and Value Sets

6.1.1.1 HL7 Table 0125 – Value Type (Constrained from the Full HL7 Table)
Table 6-3. HL7 Table 0125 – Value Type

TABLE 6-3. HL7 TABLE 0125 – VALUE TYPE
Value

Description

Lab Sender

ELR Usage

NHSN Usage

Lab to EHR

Comment

AD

Address

X

X

X

X

Not supported.

CE

Coded Entry

R

O

-

R

CF

Coded Element With Formatted
Values

X

X

X

X

Not supported.

CK

Composite ID With Check Digit

X

X

X

X

Withdrawn as of Version 2.5.

CN

Composite ID And Name

X

X

X

X

Withdrawn as of Version 2.5.

CP

Composite Price

X

X

X

X

Not supported.

CWE

Coded with Exceptions

R

R

R

R

This Implementation Guide has a specially
constrained version of the CWE data type
in section 2.3.5 above which is used for
OBX-5. The version of the CWE
documented in section 2.3.4 above shall
not be used for OBX-5. The version of the
CWE constrained for use with OBX-5
requires sending coded data. If the lab is
trying to send only string data, the ST, TX
or FT data types should be used.

Usage

Usage

Data type to be used where it is important
to communicate the coding system and
coding system version with the coded
result being reported. Pre-adopted from
Version 2.6.
CX

Page 176-230

Extended Composite ID With
Check Digit

O

O

-

O

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-3. HL7 TABLE 0125 – VALUE TYPE
Value

Description

Lab Sender

ELR Usage

NHSN Usage

Lab to EHR

DT

Date

R

R

-

O

ED

Encapsulated Data

R

R

-

R

Field using the ED data type to allow
communication of images, sound clips,
XML documents, html markup, etc.

FT

Formatted Text (Display)

R

R

-

R

Field using the FT data type to carry a text
result value. This is intended for display.
The text may contain formatting escape
sequences as described in the data types
section. Numeric results and numeric
results with units of measure should not be
reported as text. These should be
reported as NM or SN numeric results,
with the units of measure in OBX-6.

MO

Money

X

X

X

X

Not supported.

NM

Numeric

R

R

-

R

Field using the NM data type to carry a
numeric result value. The only nonnumeric characters allowed in this field are
a leading plus (+) or minus (-) sign. The
structured numeric (SN) data type should
be used for conveying inequalities, ranges,
ratios, etc. The units for the numeric value
should be reported in OBX-6.

PN

Person Name

X

X

X

X

Withdrawn as of Version 2.5.

Usage

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Usage

Comment

Page 177-230

Chapter 6: Code Systems and Value Sets

TABLE 6-3. HL7 TABLE 0125 – VALUE TYPE
Value

Description

Lab Sender

ELR Usage

NHSN Usage

Lab to EHR

Comment

RP

Reference Pointer

R

R

-

R

Field using the RP data type to allow
communication of pointers to images,
sound clips, XML documents, html markup,
etc. The RP data type is used when the
object being pointed to is too large to
transmit directly.

Usage

Usage

This specification defines the mechanism
for exchanging pointers to objects, but it
does not address the details of
applications actually accessing and
retrieving the objects over a network.
The most common scheme for passing a
pointer is to use a Universal Resource
Identifier (URI). See
http://ietf.org/rfc/rfc2396.txt for
detailed definition. The general format of a
URI is in the form:
://?. The scheme and authority portions

appear in the Application ID component,
Universal ID subcomponent. The path and
query portion of the URI appear in the
Pointer component of the RP data type.

SN

Page 178-230

Structured Numeric

R

R

R

R

Field using the SN data type to carry a
structured numeric result value.
Structured numeric include intervals (^0^^1), ratios (^1^/^2 or ^1^:^2), inequalities
(<^10), or categorical results (2^+). The
units for the structured numeric value
should be reported in OBX-6.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

TABLE 6-3. HL7 TABLE 0125 – VALUE TYPE
Value

Description

Lab Sender

ELR Usage

NHSN Usage

Lab to EHR

Comment

ST

String Data

R

R

R

R

Field using the ST data type to carry a
short text result value. Numeric results
and numeric results with units of measure
should not be reported as text. These
shall be reported as NM or SN numeric
results, with the units of measure in OBX6.

TM

Time

R

R

-

O

TN

Telephone Number

X

X

X

X

TS

Time Stamp (Date & Time)

R

R

-

O

TX

Text Data (Display)

R

R

-

R

Field using the TX data type to carry a text
result value this is intended for display.
Numeric results and numeric results with
units of measure should not be reported as
text. These should be reported as NM or
SN numeric results, with the units of
measure in OBX-6.

XAD

Extended Address

X

X

X

X

Not supported.

XCN

Extended Composite Name And
Number For Persons

X

X

X

X

Not supported.

XON

Extended Composite Name And
Number For Organizations

X

X

X

X

Not supported.

XPN

Extended Person Name

X

X

X

X

Not supported.

XTN

Extended Telecommunications
Number

X

X

X

X

Not supported.

Usage

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Usage

Withdrawn as of Version 2.5.

Page 179-230

Chapter 6: Code Systems and Value Sets

6.1.1.2 5.2.1 HL7 Table 0155 – Accept/Application Acknowledgment Conditions (Constrained from the Full HL7 Table)
Table 6-4. HL7 Table 0155 – Accept/Application Acknowledgment Conditions

TABLE 6-4. HL7 TABLE 0155 – ACCEPT/APPLICATION ACKNOWLEDGMENT CONDITIONS
Value

Description

Lab Sender

ELR Usage

NHSN Usage

Lab to EHR

AL

Always

R

O

O

R

NE

Never

R

R

O

O

ER

Error/reject conditions only

O

O

O

O

SU

Successful completion only

O

O

O

O

Usage

Usage

Comment

6.1.1.3 HL7 Table 0291 – Subtype Of Referenced Data
Table 6-5. HL7 Table 0291 - Subtype Of Referenced Data

TABLE 6-5. HL7 TABLE 0291 - SUBTYPE OF REFERENCED DATA
Value

x-hl7-cda-level-one

Page 180-230

Description

Comment

Source RFC 2046

MIME media subtypes established in accordance with RFC
2046 (http://ietf.org/rfc/rfc2046.txt) and registered with the
Internet Assigned Numbers Authority
(http://www.iana.org/numbers.html). Note that the MIME
media subtype values are case-insensitive, in accordance
with RFC 2045.

HL7 Clinical Document Architecture Level One document

Not supported.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 6: Code Systems and Value Sets

6.1.1.4 HL7 Table 0301 - Universal ID Type
Table 6-6. HL7 Table 0301 - Universal ID Type

TABLE 6-6. HL7 TABLE 0301 - UNIVERSAL ID TYPE
Value

Description

Usage

Comments

DNS

An Internet dotted name. Either in ASCII or as integers

X

Not supported.

GUID

Same as UUID.

X

Not supported.

CEN

The CEN Healthcare Coding Scheme Designator.
(Identifiers used in DICOM follow this assignment scheme.)

X

Not supported.

HL7

Reserved for future HL7 registration schemes

X

Not supported.

ISO

An International Standards Organization Object Identifier

R

Used as the Universal ID Type in the CNN, EI and
HD data types.

L,M,N

These are reserved for locally defined coding schemes.

X

Not supported.

Random

Usually a base64 encoded string of random bits.

X

Not supported.

The uniqueness depends on the length of the bits. Mail
systems often generate ASCII string _unique names," from
a combination of random bits and system names.
Obviously, such identifiers will not be constrained to the
base64 character set.
URI

Uniform Resource Identifier

R

Used as the Universal ID Type in the RP data type

UUID

The DCE Universal Unique Identifier

X

Not supported.

x400

An X.400 MHS format identifier

X

Not supported.

x500

An X.500 directory name

X

Not supported.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 181-230

Chapter 6: Code Systems and Value Sets

6.1.1.5 HL7 Table 0834 – MIME Type
Table 6-7. HL7 Table 0834 – MIME Type

TABLE 6-7. HL7 TABLE 0834 – MIME TYPE
Value

Description

Lab Sender

ELR

NHSN

Lab to EHR

application

Application data

O

O

-

O

audio

Audio data

R

R

-

R

image

Image data

R

R

-

R

model

Model data

O

O

-

O

text

Text data

R

R

-

R

video

Video data

R

R

-

R

multipart

MIME multipart package

O

O

-

O

Usage

Receiver

Receiver

Receiver

Comments

6.2 VOCABULARY DISTRIBUTION
Vocabularies recommended in this guide are primarily standard vocabularies recommended by the HITSP for use in the particular domains. In many cases, these vocabularies
are further constrained into value sets for use within this guide or were previously constrained into value sets by the CDC and maintained in PHIN VADs for use in the Public
Health domain.
PHIN VADS is based upon Whitehouse E-Gov Consolidated Health Informatics (CHI) domain recommendations and its main purpose is to distribute the vocabulary subsets
that are needed for public health. PHIN VADS allow implementers to browse, search, and download the value sets associated with an implementation guide. PHIN VADS
has the capability to host multiple versions of value sets and implementation guide vocabulary. PHIN VADS provides vocabulary metadata that are needed for HL7
messaging or CDA implementation. The latest version of any value set referenced in this implementation guide can be obtained from the CDC PHIN VADS
[http://phinvads.cdc.gov].

Page 182-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

7. Example Laboratory Result
Messages
The examples provided in this section are handcrafted and as such are subject to human error. Examples should
not be used as the basis for implementing the messages in the implementation guide. Examples are provided to
illustrate the use of the messages.

7.1 LEAD LABORATORY RESULT MESSAGE
MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.3.2^
ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||||USEL
R1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An Lab
System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.8
40.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113883.4.1^IS
O^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^^^^M|20050602
|M||2106-3^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^955^55
51009|eng^English^ISO6392^^^^3/29/2007|M^Married^HL70002^^^^2.
5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||2008081510000700|Reliable^2.16.840.1.113883.19.3.1^ISO
NK1|1|Mum^Martha^M^^^^L|MTH^Mother^HL70063^^^^2.5.1| 444 Home
Street^Apt B^Ann Arbor^MI^99999^USA^H|^PRN^PH^^1^555^5552006
PV1|1|O|4E^234^A^Good Health
Hospital&2.16.840.1.113883.19.3.2.3&ISO^N^N^Building
1^4^Nursing unit 4
East^1234&&2.16.840.1.113883.19.3.2.3&ISO^&2.16.840.1.113883.1
9.3.2.3&ISO|R||||||||||||||||||||||||||||||||||||||||200808151
000-0700|200808151200-0700
PV2|||1^Sick^99AdmitReason|||||||||||||N||||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|||20010603||
|19990603ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|97001
23^Lab^2.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^
A^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.11
3883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005|||||||Level
Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 183-230

Chapter 7: Example Laboratory Result Messages

Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444 Healthcare
Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16.
840.1.113883.19.3.1.6^ISO|10368-9^Lead BldCmCnc^LN^3456543^Blood lead test^99USI^2.24|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11
3883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^MD
|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F||||||787.91^
DIARRHEA^I9CDX^^^^07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.1
6.840.1.113883.19.4.6&ISO
OBX|1|NM|10368-9^Lead BldC-mCnc^LN^^^^2.24|1|50|ug/dL^micro-gram
per deci-liter^UCUM^^^^1.6|<10 ug/dL|H|||F|||2008081510300700|||||2008081818000700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3
434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.
840.1.113883.19.3.1.6&ISO||122554006^Capillary blood
specimen^SCT^BLDC^Blood
capillary^HL70070^20080131^2.5.1||HEPA^Ammonium
heparin^HL70371^^^^2.5.1|CAP^Capillary
Specimen^HL70488^^^^2.5.1|181395001^Venous structure of
digit^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|50^uL&Micro
Liter&UCUM&&&&1.6|||||200808151030-0700|200808151100-0700
OBX|2|NM|35659-2^Age at specimen
collection^LN^^^^2.24||3|a^year^UCUM^^^^1.6|||||F|||2008081510
30-0700|||||2008081510300700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3
434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI

7.2 CAMPYLOBACTER JEJUNI
MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.3.2^
ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||||USEL
R1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An Lab
System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.8
40.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113883.4.1^IS
Page 184-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

O^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^^^^M|19800602
|M||2106-3^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^955^55
51009|eng^English^ISO6392^^^^3/29/2007|M^Married^HL70002^^^^2.
5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|
Reliable^2.16.840.1.113883.19.3.1^ISO
PV1|1|O|4E^234^A^Good Health
Hospital&2.16.840.1.113883.19.3.2.3&ISO^N^N^Building
1^4^Nursing unit 4
East^1234&&2.16.840.1.113883.19.3.2.3&ISO^&2.16.840.1.113883.1
9.3.2.3&ISO|R||||||||||||||||||||||||||||||||||||||||200808151
000-0700|200808151200-0700
PV2|||1^Sick^99AdmitReason|||||||||||||N||||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|||20010603||
|19990603
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16
.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A^III^Dr^^^
&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6
^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005|||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444 Healthcare
Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16.
840.1.113883.19.3.1.6^ISO|625-4^Bacteria
identified^LN^3456543^ CULTURE,
STOOL^99USI^2.26|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11
3883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^MD
|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F||||||787.91^
DIARRHEA^I9CDX^^^^07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.1
6.840.1.113883.19.4.6&ISO
OBX|1|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|1|66543000^Cam
pylobacter jejuni^SCT^^^^January
2007||||||P|||200906041458|||0086^Bacterial
identification^OBSMETHOD^^^^501-20080815||200906051700||||GHH
Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 185-230

Chapter 7: Example Laboratory Result Messages

SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.
840.1.113883.19.3.1.6&ISO||119339001^Stool
specimen^SCT^^^^20080131|||||||P^Patient^HL60369^^^^2.5.1|10^g
&gram&UCUM&&&&1.6|||||200808151030-0700|200808151100-0700

7.3 ANIMAL RABIES
MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.3.2^
ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||||USEL
R1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An Lab
System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.8
40.1.113883.19.3.2.1&ISO||^^^^^^L~Everyman^Fluffy^^^^^N||20070
602|M|||||||||||||||||||||20080817|Y|||2008081510000700|Reliable^2.16.840.1.113883.19.3.1^ISO|44696006^Beagle^SCT
^^^^20080731
NK1|1|Everyman^Adam^A^^^^L|OWN^Owner^HL70063^^^^2.5.1|444 Home
Street^Apt B^Ann Arbor^MI^99999^USA^H|^PRN^PH^^1^555^5552006
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16
.840.1.113883.19.3.1.6^ISO|||||||||1234^Seven^Henry^L^^Dr^^^&2
.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^I
SO^^^^^^^^DVM||^WPN^PH^^1^555^5551005|||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444 Healthcare
Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16.
840.1.113883.19.3.1.6^ISO|6528-4^Rabies virus
Ag^LN^^^^2.26|||2008081410300700|||||||||1234^Seven^Henry^L^^Dr^^^&2.16.840.1.113883.19.4.
6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^DVM|^WPN^PH^
^1^555^5551005|||||20080818300700|||F|||||||1235&Slide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883
.19.4.6&ISO
OBX|1|CWE|6528-4^Rabies virus
Ag^LN^^^^2.26|1|260373001^Detected^SCT^^^^20080731||||||F|||20
0808141030-0700|||||2008081510300700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3
434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI
Page 186-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.
840.1.113883.19.3.1.6&ISO||256865009^Brain
tissue^SCT^^^^20080131|||||||P^Patient^HL60369^^^^2.5.1|72^g&g
ram&UCUM&&&&1.6|||||200808141030-0700|200808151100-0700

7.4 HEPATITIS C VIRUS
MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.3.2^
ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||||USEL
R1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An Lab
System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.16.8
40.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113883.4.1^IS
O^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^^^^M|19800602
|M||2106-3^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^955^55
51009|eng^English^ISO6392^^^^3/29/2007|M^Married^HL70002^^^^2.
5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|
Reliable^2.16.840.1.113883.19.3.1^ISO
PV1|1|O|4E^234^A^Good Health
Hospital&2.16.840.1.113883.19.3.2.3&ISO^N^N^Building
1^4^Nursing unit 4
East^1234&&2.16.840.1.113883.19.3.2.3&ISO^&2.16.840.1.113883.1
9.3.2.3&ISO|R||||||||||||||||||||||||||||||||||||||||200808151
000-0700|200808151200-0700
PV2|||1^Sick^99AdmitReason|||||||||||||N||||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|||20010603||
|19990603
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16
.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A^III^Dr^^^
&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6
^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005|||||||Level Seven
Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444 Healthcare
Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.16.
840.1.113883.19.3.1.6^ISO|5198-7^HCV Ab Ser EIAaCnc^LN^140666^Hep C Virus Ab^99LabTest^2.26|||200808151030HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 187-230

Chapter 7: Example Laboratory Result Messages

0700||||||jaundice|||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11
3883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^MD
|^WPN^PH^^1^555^5551005|||||20080818300700|||F||||||782.4^Jaundice unspecified not of
newborn^I9CDX^^^^07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.16
.840.1.113883.19.4.6&ISO
OBX|1|SN|5198-7^HCV Ab Ser EIA-aCnc^LN^140666^Hep C Virus
Ab^99LabTest^2.24|1|||>^11.0|1^^UCUM^^^^1.6^^s/co ratio|0.00.9|H~POS|||F|||200808151030-0700|||||200808181800-0700||||GHH
Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.16.
840.1.113883.19.3.1.6&ISO||122555007^Venous blood
specimen^SCT^WB^Blood,
whole^HL70487^20080731^2.5.1||HEPA^Ammonium
heparin^HL70371^^^^2.5.1|VENIP^Venipuncture^HL70488^^^^2.5.1|
29092000^Venous
structure^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|2^ml&mi
lliliter&UCUM&&&&1.6|||||200808151030-0700|200808151100-0700
OBX|2|NM|35659-2^Age at specimen
collection^LN^^^^2.24|1|29|a^year^UCUM^^^^1.6|||||F|||20080815
1030-0700|||||200808151030-0700||||GHH
Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI
OBX|3|TX|11294-6^Current employment^LN^^^^2.24|1|food
handler||||||F|||200808151030-0700|||||2008081510300700||||GHH
Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.840.1
.113883.19.4.6&ISO^L^^^NPI

7.5 MINIMAL MESSAGE WITH ACKNOWLEDGEMENT
Acknowledgments are an optional part of this implementation guide. The National ELR group felt that this guide
should show some examples of the optional acknowledgments.
The first example is a minimal message, including only those fields that are required. The subsequent examples
include acknowledgements for a successful receipt, an error upon receipt and a rejection acknowledgement in
response to the minimal message.

7.5.1 Example: Minimal Message
Transaction sent:
Page 188-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.
3.2^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.
10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||
||USELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
Lab System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.
16.840.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113
883.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha
^M^^^^M|20050602|M||21063^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^
955^5551009|eng^English^ISO6392^^^^3/29/2007|M^Married^H
L70002^^^^2.5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|
Reliable^2.16.840.1.113883.19.3.1^ISO
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^
2.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A
^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840
.1.113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005||
|||||Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444
Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2
.16.840.1.113883.19.3.1.6^ISO|10368-9^Lead BldCmCnc^LN^3456543^Blood lead
test^99USI^2.24|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.84
0.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^I
SO^^^^^^^^MD|^WPN^PH^^1^555^5551005|||||20080818300700|||F||||||787.91^DIARRHEA^I9CDX^^^^07/09/2008|1235&S
lide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO
OBX|1|NM|10368-9^Lead BldC-mCnc^LN^^^^2.24||50|ug/dL^microgram per deci-liter^UCUM^^^^1.6|<10
ug/dL|H|||F|||200808151030-0700|||||2008081818000700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^
1236|3434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16
.840.1.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2
.16.840.1.113883.19.3.1.6&ISO||122554006^Capillary blood
specimen^SCT^BLDC^Blood
capillary^HL70070^20080131^2.5.1||HEPA^Ammonium
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 189-230

Chapter 7: Example Laboratory Result Messages

heparin^HL70371^^^^2.5.1|CAP^Capillary
Specimen^HL70488^^^^2.5.1|181395001^Venous structure of
digit^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|50^uL
&MicroLiter&UCUM&&&&1.6|||||2008081510300700|200808151100-0700
7.5.2 Example: Successful Receipt Message
Acknowledgment:

MSH|^~\&|ELR^2.16.840.1.113883.19.3.2^ISO|SPH^2.16.840.1.113
883.19.3.2^ISO|Lab^2.16.840.1.113883.19.4.6^ISO|GHH^2.16
.840.1.113883.19.3.1^ISO|20080818183002.90700||ACK^R01^ACK|1234567891|P^T|2.5.1|||NE|NE|USA||||US
ELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
ELR System|56739||20080817
MSA|CA|1234567890
7.5.3 Example: Error on Receipt Message
Transaction sent:

MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.
3.2^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.
10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||
||USELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
Lab System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.
16.840.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113
883.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha
^M^^^^M|20050602|M||21063^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^
955^5551009|eng^English^ISO6392^^^^3/29/2007|M^Married^H
L70002^^^^2.5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|
Reliable^2.16.840.1.113883.19.3.1^ISO
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^
2.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A
^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840
.1.113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005||
|||||Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann

Page 190-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444
Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBX|1|NM|10368-9^Lead BldC-mCnc^LN^^^^2.24||50|ug/dL^microgram per deci-liter^UCUM^^^^1.6|<10
ug/dL|H|||F|||200808151030-0700|||||2008081818000700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^
1236|3434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16
.840.1.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2
.16.840.1.113883.19.3.1.6&ISO||122554006^Capillary blood
specimen^SCT^BLDC^Blood
capillary^HL70070^20080131^2.5.1||HEPA^Ammonium
heparin^HL70371^^^^2.5.1|CAP^Capillary
Specimen^HL70488^^^^2.5.1|181395001^Venous structure of
digit^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|50^uL
&MicroLiter&UCUM&&&&1.6|||||2008081510300700|200808151100-0700
Acknowledgment:

MSH|^~\&|ELR^2.16.840.1.113883.19.3.2^ISO|SPH^2.16.840.1.113
883.19.3.2^ISO|Lab^2.16.840.1.113883.19.4.6^ISO|GHH^2.16
.840.1.113883.19.3.1^ISO|20080818183002.90700||ACK^R01^ACK|1234567891|P^T|2.5.1|||NE|NE|USA||||US
ELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
ELR System|56739||20080817
MSA|CE|1234567890
ERR||OBR^1|100^Segment sequence error^HL70357|E|||Missing
required OBR segment|Email help desk for further
information on this
error||||^NET^Internet^[email protected]
7.5.4 Example: Error on Receipt - Warning
Transaction sent:

MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.
3.2^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.
10700||ORU^R01^ORU_R01|1234567890|P^T|2.5.1|||NE|NE|USA||
||USELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
Lab System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.
16.840.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.113
883.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 191-230

Chapter 7: Example Laboratory Result Messages

^M^^^^M|20050602|M||21063^White^CDCREC^^^^04/24/2007|2222 Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^
955^5551009|eng^English^ISO6392^^^^3/29/2007|M^Married^H
L70002^^^^2.5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||200808151000-0700|
Reliable^2.16.840.1.113883.19.3.1^ISO
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^
2.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A
^III^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840
.1.113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005||
|||||Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444
Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2
.16.840.1.113883.19.3.1.6^ISO|10368-9999^Lead BldCmCnc^LN^3456543^Blood lead
test^99USI^2.24|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.84
0.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^I
SO^^^^^^^^MD|^WPN^PH^^1^555^5551005|||||20080818300700|||F||||||787.91^DIARRHEA^I9CDX^^^^07/09/2008|1235&S
lide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO
OBX|1|NM|10368-9^Lead BldC-mCnc^LN^^^^2.24||50|ug/dL^microgram per deci-liter^UCUM^^^^1.6|<10
ug/dL|H|||F|||200808151030-0700|||||2008081818000700||||Lab^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^
1236|3434 Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16
.840.1.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2
.16.840.1.113883.19.3.1.6&ISO||122554006^Capillary blood
specimen^SCT^BLDC^Blood
capillary^HL70070^20080131^2.5.1||HEPA^Ammonium
heparin^HL70371^^^^2.5.1|CAP^Capillary
Specimen^HL70488^^^^2.5.1|181395001^Venous structure of
digit^SCT^^^^20080731|||P^Patient^HL60369^^^^2.5.1|50^uL
&MicroLiter&UCUM&&&&1.6|||||2008081510300700|200808151100-0700
Acknowledgement:

MSH|^~\&|ELR^2.16.840.1.113883.19.3.2^ISO|SPH^2.16.840.1.113
883.19.3.2^ISO|Lab^2.16.840.1.113883.19.4.6^ISO|GHH^2.16
.840.1.113883.19.3.1^ISO|20080818183002.90700||ACK^R01^ACK|1234567891|P^T|2.5.1|||NE|NE|USA||||US
ELR1.0^^2.16.840.1.114222.4.10.3^ISO
Page 192-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Chapter 7: Example Laboratory Result Messages

SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
ELR System|56739||20080817
MSA|CE|1234567890
ERR||OBR^1^4|207^Application internal
error^HL70357|W|||Invalid LOINC Code|Email help desk for
further information on this
error||||^NET^Internet^[email protected]
7.5.5 Example: Reject Receipt Message
Transaction sent:

MSH|^~\&|Lab1^1234^CLIA|^1234^CLIA|ELR^2.16.840.1.113883.19.
3.2^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|20080818183002.
10700||ORU^R01^ORU_R01|1234567890|T^T|2.5.1|||NE|NE|USA||
||USELR1.0^^2.16.840.1.114222.4.10.3^ISO
(The remainder of the message is the same as that in Section 7.3.1 above.)
Acknowledgment:

MSH|^~\&|ELR^2.16.840.1.113883.19.3.2^ISO|SPH^2.16.840.1.113
883.19.3.2^ISO|Lab^2.16.840.1.113883.19.4.6^ISO|GHH^2.16
.840.1.113883.19.3.1^ISO|20080818183002.90700||ACK^R01^ACK|1234567891|P^T|2.5.1|||NE|NE|USA||||US
ELR1.0^^2.16.840.1.114222.4.10.3^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
ELR System|56739||20080817
MSA|CR|1234567890
ERR||MSH^1^10|202^Unsupported processing id^HL70357|E|||Test
message sent in production environment|Email help desk
for further information on this
error||||^NET^Internet^[email protected]

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 193-230

Appendix A: HL7 Reporting of Culture and Susceptibilities

Appendix A. HL7 Reporting
of Culture and Susceptibilities
A.1 INTRODUCTION
Parent-child relationships, such as culture and sensitivities, can be reported using the HL7 electronic messaging
standard. However, this is an area where many vendors and large laboratories have augmented the standard to
account for variations in the systems with which they work. This usually does not present a problem until these
messages must be shared between systems (for instance, between laboratories and sub-contracted laboratories, or
between laboratories and public health agencies).
Parent-child information such as culture and susceptibilities (e.g., reporting of multi-resistant tuberculosis or drugresistant gonococcus or pneumococcus) is a critical component of electronic, laboratory-based public health
reporting.
The approach described here is required for use in reporting microbiology results for this message profile.

A.2 TEMPLATE FOR CULTURE RESULTS
A template report for the initial identification of three organisms from a single stool culture is presented below. For
each field (i.e., the space between the pipes, "|"), a description of what should appear in that particular field is given,
along with the segment-field number in parentheses (e.g., OBR-3) for some of the fields. Note that these examples
use the ORU^R01 message type.

MSH|…
PID|…
OBR|1| Placer number | Filler number | Identifier code for
the requested test or panel of tests(OBR-4) |…
OBX|1|CE| Specific organism identifier (OBX-3) | Sub-id for
the first organism (OBX-4) | Description of organism
(OBX-5) |…
OBX|2|SN| Other identifier (OBX-3) | Sub-id for the first
organism (OBX-4) | Observation on the organism (OBX-5) |…
OBX|3|CE| Specific organism identifier (OBX-3) | Sub-id for
the second organism (OBX-4) | Description of organism
(OBX-5) |…
OBX|4|SN| Other identifier (OBX-3) | Sub-id for the second
organism (OBX-4) | Observation on the Organism (OBX-5) |…
OBX|5|CE| Specific organism identifier (OBX-3) | Sub-id for
the third organism (OBX-4) | Description of organism
(OBX-5) |…
OBX|6|SN| Other identifier (OBX-3) | Sub-id for the third
organism (OBX-4) | Observation on the organism (OBX-5) |…
SPM|1| Specimen identifier for the specimen being tested|_
This report has the MSH (Message Header), the PID (Patient Identification Segment), a single OBR (Observation
Request Segment), and six OBX (Observation/Results) segments, and a single SPM (Specimen Segment). Note that
the Set ID in the first field of each OBX is sequential, while the Sub-ID in the fourth field of each OBX is not
sequential, but acts as a link for all of the OBX segments that are reporting information for a related observation.
Page 194-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix A: HL7 Reporting of Culture and Susceptibilities
The Sub-ID field in the template above has the words "first," "second" and "third" in bold and highlighted in green.
This is done to show that the identification of the first organism is the relating observation for the first two OBX
segments (e.g., Set-ID numbers 1 and 2). The identification of the second organism is the relating observation for
the second two segments (e.g., Set-ID numbers 3 and 4), and so on. An example using the template above is
presented below.

A.2.1 Examples of Culture Results
In this example, Reliable Labs, Inc. is sending preliminary results of a stool culture to state public health authorities.
Three pathogens have been identified: Campylobacter jejuni, Salmonella and Shigella.
This example shows the use of the Sub-ID in OBX-4 to connect related observations. The Sub-ID is shown in
bolded letters and highlighted in green, as presented in the previous template. In this example, numbers are used for
the Sub-ID. However, a text identifier such as "isolate1" could be used. The HL7 standard has defined the Sub-ID
(e.g., OBX-4) as a "string" data type. Thus, it can be either a number or text.
In this example, the information about colony counts in OBX segments with Set IDs 2, 4, and 6 is provided to show
how the Sub-ID is used to relate the associated OBX segments to each other (e.g., 1 and 2, 3 and 4, 5 and 6). Some
laboratories may not have this additional information and would therefore transmit only the identification of the
organisms (e.g., OBX segments 1, 3 and 5).
Identified organisms must be reported as coded data instead of text data. Coded data enables machine processing of
results. String data can normally be interpreted only by humans.

MSH|^~\&|Lab1^1234^CLIA|Reliable^1234^CLIA|ELR^2.16.840.1.113
883.19.3.2.3^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|2007070
11325540400||ORU^R01^ORU_R01|20070701132554000008|P^T|2.5.1|||NE
|NE|USA||||USELR1.0^^2.16.840.1.113883.19.9.7^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
Lab System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.1
6.840.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.11388
3.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^
^^^M|19750602|M||2106-3^White^CDCREC^^^^04/24/2007|2222
Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^9
55^5551009|eng^English^ISO6392^^^^3/29/2007|M^Married^HL7
0002^^^^2.5.1||||||N^Not Hispanic or
Latino^HL70189^^^^2.5.1||||||||N|||2008081510000700|Reliable^2.16.840.1.113883.19.3.1^ISO
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2
.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A^I
II^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.
113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005||||||
|Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444
Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.
16.840.1.113883.19.3.1.6^ISO|625-4^Bacteria
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 195-230

Appendix A: HL7 Reporting of Culture and Susceptibilities

identified^LN^3456543^ CULTURE,
STOOL^99USI^2.26|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.840
.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO
^^^^^^^^MD|^WPN^PH^^1^555^5551005|||||20080818300700|||P||||||787.91^DIARRHEA^I9CDX^^^^07/09/2008|1235&Sl
ide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO
OBX|1|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|1|6654300
0^Campylobacter jejuni^SCT^^^^January
2007||||||P|||200808151030-0700|||0086^Bacterial
identification^OBSMETHOD^^^^501-20080815||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|2|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|1|^10000^^90000|1^^UCUM^^^^1.6|||||P|||2008081510300700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|3|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|2|3026200
05^Salmonella group B phase 1 a-e^SCT^^^^January
2007||||||P|||200808151030-0700|||0086^Bacterial
identification^OBSMETHOD^^^^501-20080815||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|4|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|2|>^100000|1^^UCUM^^^^1
.6|||||P|||200808151030-0700|||||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|5|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|3|7735200
2^Shigella^SCT^^^^January 2007||||||P|||2008081510300700|||0086^Bacterial identification^OBSMETHOD^^^^501Page 196-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix A: HL7 Reporting of Culture and Susceptibilities

20080815||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|6|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|3|<^1000|1^^UCUM^^^^1.6
|||||P|||200808151030-0700|||||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.
16.840.1.113883.19.3.1.6&ISO||119339001^Stool
specimen^SCT^^^^20080131|||||||P^Patient^HL60369^^^^2.5.1
|10^g&gram&UCUM&&&&1.6|||||2008081510300700|200808151100-0700

A.3 TEMPLATE FOR CULTURE AND SUSCEPTIBILITY RESULTS
The template and example in the Template for Culture Results section of this appendix describe a report for a
culture. The following template shows how antimicrobial susceptibility results are reported for the culture described
in that section. The connection of the culture to the susceptibilities is a "parent-child" relationship, where the culture
is the parent result and the susceptibilities are the child results. This means that there can be many child results for a
single parent result. In other words, there can be multiple OBR child segments for the single OBR parent segment
presented in the Template for Culture Results section of this appendix. The template for the report containing the
culture and susceptibilities appears below. The titles in Italics are given to highlight the individual parent and child
segments and are not found in an actual HL7 message transmission. It is important to note that in each of the OBR
child segments there is a pointer back to the parent result. This pointer is found in OBR-26 (Parent Result) and in
OBR-29 (Parent Number).
Message Header and Patient Identification Segment for the Parent-Child Message

MSH|…
PID|…
Parent OBR Segment

OBR|1| Placer number (OBR-2) | Filler order number (OBR-3) |
Identifier code for the requested test or panel of tests
(OBR-4) |…
Parent OBX Segments for First Organism Identified

OBX|1|CE| Specific organism identifier (OBX-3) | Sub-id for
the first organism (OBX-4) | Description of organism
(OBX-5) |…
OBX|2|SN| Other identifier (OBX-3) | Sub-id for the first
organism (OBX-4) | Observation on the organism (OBX-5) |…
Parent OBX Segments for Second Organism Identified

OBX|3|CE| Specific organism identifier (OBX-3) | Sub-id for
the second organism (OBX-4) | Description of organism
(OBX-5) |…
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 197-230

Appendix A: HL7 Reporting of Culture and Susceptibilities

OBX|4|SN| Other identifier (OBX-3) | Sub-id for the second
organism (OBX-4) | Observation on the Organism (OBX-5) |…
Parent OBX Segments for Third Organism Identified

OBX|5|CE| Specific organism identifier (OBX-3) | Sub-id for
the third organism (OBX-4) | Description of organism
(OBX-5) |…
OBX|6|SN| Other identifier (OBX-3) | Sub-id for the third
organism (OBX-4) | Observation on the organism (OBX-5) |…
Child OBR for First Organism identified

OBR|2| Placer number (OBR-2)| Filler order number (OBR-3) |
Identifier code for the requested test or panel of tests
(OBR-4) |||||||||||||||||||||| A pointer back to the parent
OBX segment that contained the identification of the first
organism, see below for description of "Pointers" (OBR-26)
||| Parent Filler order number (OBR-29) |...
Child OBX Segments for Susceptibilities of First Organism Identified

OBX|1|CE|Specific susceptibility identifier for first
antimicrobial (OBX-3) || Susceptibility finding (OBX-5)
||| Susceptibility interpretation (OBX-8) |…
OBX|2|CE|Specific susceptibility identifier for second
antimicrobial (OBX-3) || Susceptibility finding (OBX-5)
||| Susceptibility interpretation (OBX-8) |…
OBX|3|CE|Specific susceptibility identifier for third
antimicrobial (OBX-3) || Susceptibility finding (OBX-5)
||| Susceptibility interpretation (OBX-8) |…
Child OBR Segment for Susceptibilities of Second Organism Identified

OBR|3| Placer number (OBR-2)| Filler order number (OBR-3) |
Identifier code for the requested test or panel of tests
(OBR-4) |||||||||||||||||||||| A pointer back to the parent
OBX segment that contained the identification of the second
organism, see below for description of "Pointers" (OBR-26)
||| Parent Filler order number (OBR-29) |...
Child OBX Segments for Susceptibilities of Second Organism Identified

OBX|1|CE|Specific susceptibility identifier for first
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…
OBX|2|CE|Specific susceptibility identifier for second
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…

Page 198-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix A: HL7 Reporting of Culture and Susceptibilities

OBX|3|CE|Specific susceptibility identifier for third
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…
Child OBR Segment for Susceptibilities of Third Organism Identified

OBR|3| Placer number (OBR-2)| Filler order number (OBR-3) |
Identifier code for the requested test or panel of tests
(OBR-4) |||||||||||||||||||||| A pointer back to the parent
OBX segment that contained the identification of the third
organism, see below for description of "Pointers" (OBR-26)
||| Parent Filler order number (OBR-29) |...
Child OBX Segments for Susceptibilities of Third Organism Identified

OBX|1|CE|Specific susceptibility identifier for first
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…
OBX|2|CE|Specific susceptibility identifier for second
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…
OBX|3|CE|Specific susceptibility identifier for third
antimicrobial (OBX-3) || Susceptibility finding (OBX-5) |||
Susceptibility interpretation (OBX-8) |…
SPM Segment

SPM|1| Specimen identifier for the specimen being tested|…
A.3.1 Examples of Culture and Susceptibility Results
Using the template above, this example shows a report of three pathogens identified from a stool specimen with their
respective antimicrobial susceptibility tests.

MSH|^~\&|
Lab1^1234^CLIA|Reliable^1234^CLIA|ELR^2.16.840.1.113883.1
9.3.2.3^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|200707011325
540400||ORU^R01^ORU_R01|20070701132554000008|P^T|2.5.1|||NE
|NE|USA||||USELR1.0^^2.16.840.1.113883.19.9.7^ISO
SFT|1|Level Seven Healthcare Software,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1.2|An
Lab System|56734||20080817
PID|1||36363636^^^MPI&2.16.840.1.113883.19.3.2.1&ISO^MR^A&2.1
6.840.1.113883.19.3.2.1&ISO~444333333^^^&2.16.840.1.11388
3.4.1^ISO^SS||Everyman^Adam^A^^^^L^^^^^^^BS|Mum^Martha^M^
^^^M|19750602|M||2106-3^White^CDCREC^^^^04/24/2007|2222
Home Street^^Ann
Arbor^MI^99999^USA^H||^PRN^PH^^1^555^5552004|^WPN^PH^^1^9
55^5551009|eng^English^ISO6392^^^^3/29/2007|M^Married^HL7
0002^^^^2.5.1||||||N^Not Hispanic or
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 199-230

Appendix A: HL7 Reporting of Culture and Susceptibilities

Latino^HL70189^^^^2.5.1||||||||N|||2008081510000700|Reliable^2.16.840.1.113883.19.3.1^ISO
ORC|RE|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2
.16.840.1.113883.19.3.1.6^ISO|||||||||1234^Admit^Alan^A^I
II^Dr^^^&2.16.840.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.
113883.19.4.6^ISO^^^^^^^^MD||^WPN^PH^^1^555^5551005||||||
|Level Seven Healthcare,
Inc.^L^^^^&2.16.840.1.113883.19.4.6^ISO^XX^^^1234|1005
Healthcare Drive^^Ann
Arbor^MI^99999^USA^B|^WPN^PH^^1^555^5553001|4444
Healthcare Drive^Suite 123^Ann Arbor^MI^99999^USA^B
OBR|1|23456^EHR^2.16.840.1.113883.19.3.2.3^ISO|9700123^Lab^2.
16.840.1.113883.19.3.1.6^ISO|625-4^Bacteria
identified^LN^3456543^ CULTURE,
STOOL^99USI^2.26|||2008081510300700||||||diarrhea|||1234^Admit^Alan^A^III^Dr^^^&2.16.840
.1.113883.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO
^^^^^^^^MD|^WPN^PH^^1^555^5551005|||||20080818300700|||F||||||787.91^DIARRHEA^I9CDX^^^^07/09/2008|1235&Sl
ide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6&ISO
OBX|1|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|1|6654300
0^Campylobacter jejuni^SCT^^^^January
2007||||||F|||200808151030-0700|||0086^Bacterial
identification^OBSMETHOD^^^^501-20080815||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|2|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|1|^10000^^90000|1^^UCUM^^^^1.6|||||F|||2008081510300700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|3|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|2|3026200
05^Salmonella group B phase 1 a-e^SCT^^^^January
2007||||||F|||200808151030-0700|||0086^Bacterial
identification^OBSMETHOD^^^^501-20080815||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
Page 200-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix A: HL7 Reporting of Culture and Susceptibilities

OBX|4|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|2|>^100000|1^^UCUM^^^^1
.6|||||F|||200808151030-0700|||||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|5|CWE|625-4^Bacteria
identified:Prid:Pt:Stool:Nom:Culture^LN^^^^2.26|3|7735200
2^Shigella^SCT^^^^January 2007||||||F|||2008081510300700|||0086^Bacterial identification^OBSMETHOD^^^^50120080815||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|6|SN|564-5^COLONY
COUNT:NUM:PT:XXX:QN:VC^LN^^^^2.26|3|<^1000|1^^UCUM^^^^1.6
|||||F|||200808151030-0700|||||2008081610300700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
SPM|1|23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700122&Lab&2.
16.840.1.113883.19.3.1.6&ISO||119339001^Stool
specimen^SCT^^^^20080131|||||||P^Patient^HL60369^^^^2.5.1
|10^g&gram&UCUM&&&&1.6|||||2008081510300700|200808151100-0700
OBR|2||9700124^Lab^2.16.840.1.113883.19.3.1.6^ISO|505453^Bacterial susceptibility panel::Pt:Isolate:OrdQn:MIC^LN^^^^2.26|||2008081510300700|||||||||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11388
3.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^
MD|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F|6254&Bacteria
identified:Prid:Pt:Stool:Nom:Culture&LN^1^Campylobacter
jejuni|||23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700123
&Lab&2.16.840.1.113883.19.3.1.6&ISO||787.91^DIARRHEA^I9CD
X^^^^07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.16.840.1.
113883.19.4.6&ISO
OBX|1|SN|6979-9^AMPICILLIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|<^0.06|ug/mL^^UCUM^^^^1.6||S|||F|||200
808151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 201-230

Appendix A: HL7 Reporting of Culture and Susceptibilities

Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|2|SN|7016-9^GENTAMICIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|ug/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|3|SN|7002-9^CIPROFLOXACIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|ug/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBR|3||9700125^Lab^2.16.840.1.113883.19.3.1.6^ISO|505453^Bacterial susceptibility panel::Pt:Isolate:OrdQn:MIC^LN^^^^2.26|||2008081510300700|||||||||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11388
3.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^
MD|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F|6254&Bacteria
identified:Prid:Pt:Stool:Nom:Culture&LN^2^Salmonella
group B phase 1 ae|||23456&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700123&Lab&
2.16.840.1.113883.19.3.1.6&ISO||787.91^DIARRHEA^I9CDX^^^^
07/09/2008|1235&Slide&Stan&S&&Dr&MD&&DOC&2.16.840.1.11388
3.19.4.6&ISO
OBX|1|SN|6979-9^AMPICILLIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|<^0.06|ug/mL^^UCUM^^^^1.6||S|||F|||200
808151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|2|SN|7016-9^GENTAMICIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|ug/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|3|SN|7002-9^CIPROFLOXACIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|ug/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Page 202-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix A: HL7 Reporting of Culture and Susceptibilities

Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBR|4||9700126^Lab^2.16.840.1.113883.19.3.1.6^ISO|505453^Bacterial susceptibility panel::Pt:Isolate:OrdQn:MIC^LN^^^^2.26|||2008081510300700|||||||||1234^Admit^Alan^A^III^Dr^^^&2.16.840.1.11388
3.19.4.6^ISO^L^^^EI^&2.16.840.1.113883.19.4.6^ISO^^^^^^^^
MD|^WPN^PH^^1^555^5551005|||||2008081830-0700|||F|6254&Bacteria
identified:Prid:Pt:Stool:Nom:Culture&LN^2^Shigella|||2345
6&EHR&2.16.840.1.113883.19.3.2.3&ISO^9700123&Lab&2.16.840
.1.113883.19.3.1.6&ISO||787.91^DIARRHEA^I9CDX^^^^07/09/20
08|1235&Slide&Stan&S&&Dr&MD&&DOC&2.16.840.1.113883.19.4.6
&ISO
OBX|1|SN|6979-9^AMPICILLIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|<^0.06|µg/mL^^UCUM^^^^1.6||S|||F|||200
808151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|2|SN|7016-9^GENTAMICIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|µg/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI
OBX|3|SN|7002-9^CIPROFLOXACIN:SUSC:PT:ISLT:ORDQN:GRADIENT
STRIP^LN^^^^2.26|1|^0.05|µg/mL^^UCUM^^^^1.6||S|||F|||2008
08151030-0700|||||200808161030-0700||||Reliable Labs,
Inc^L^^^^CLIA&2.16.840.1.113883.19.4.6&ISO^XX^^^1236|3434
Industrial Loop^^Ann
Arbor^MI^99999^USA^B|9876543^Slide^Stan^S^^^^^NPPES&2.16.
840.1.113883.19.4.6&ISO^L^^^NPI

A.4 LINKING PARENT AND CHILD RESULTS
The previous example uses the information in OBR-26 as a pointer to the parent OBX where the culture result is
reported. OBR-26 has three components. The three components of OBR-26 are the OBX-3, OBX-4 and part of the
OBX-5 from the parent OBX segment. The pointer to the parent requires only the first two components. The third
component is intended to provide additional information that may be useful, but not necessary. This allows a
lengthy result in the parent OBX-5 (e.g., a paragraph describing pathology results) to be truncated or not sent at all.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 203-230

Appendix B: Clinical Laboratory Improvements Amendment Considerations, US Realm Only

Appendix B. Clinical
Laboratory Improvements
Amendment Considerations,
US Realm Only
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 is formatted for the US Realm and these changes are outlined in this appendix. Impacted areas
include mandatory reporting requirements, report retention and display, and those authorized to receive a report.
Specifics on the CLIA Regulation are found at http://wwwn.cdc.gov/clia/regs/toc.aspx.

B.1 MANDATORY REPORTING REQUIREMENTS
Section 493.1291 of the CLIA Regulations defines items that must appear on a clinical laboratory report in the US
(http://wwwn.cdc.gov/clia/regs/subpart_k.aspx#493.1291). Interpretative Guidelines on the elements
required in a report may be found at http://www.cms.hhs.gov/CLIA/downloads/apcsubk2.pdf. Specific report
fields impacted include the following:
Table B-1. Mandatory Reporting Requirements

TABLE B-1 – MANDATORY REPORTING REQUIREMENTS
Segment

Field

CLIA Impact

PID-3

Patient Identifier List

A unique patient identification number is required

PID-5

Patient Name

Positive patient identification required. If the patient’s name is known,
this must be that name. If it is not known, a unique patient identifier
must be assigned.

OBX-3

Observation Identifier 9

Unique identification of the test performed is required. LOINC® is an
HL7-approved code system and shall be used for the Observation
Identifier as described in the appropriate HITSP Interoperability
Specification. Use of LOINC codes for additional tests is strongly
encouraged. See Section 6 for more details. Addition of a local
laboratory code is allowed.
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

9

While CLIA requires a laboratory to maintain positive identification of a specimen reporting, that information as part of the result is not
required.

Page 204-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix B: Clinical Laboratory Improvements Amendment Considerations, US Realm Only

TABLE B-1 – MANDATORY REPORTING REQUIREMENTS
Segment

Field

CLIA Impact
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."

OBX-5

Observation Value

The laboratory result is required. No regulatory requirements are
specified, outside of readability, regarding result appearance.

OBX-6

Units

Units, if required, or an interpretation must be given. For tests such as
genetic screens the interpretation may actually be the test result.

OBX-7

Reference Range

Required.

OBX-8

Abnormal flag.

Use is not required, but a laboratory may use this field as part of its
interpretation guidance. If reported, it should be displayed by an
EHR.

OBX-11

Observation Result 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). See SPM-21 and -22 below.

OBX-19

Date/Time of Analysis

Use this field to meet the requirement for test report time.

OBX-23, 24, 25

Laboratory Identification Fields The identification of the performing laboratory is required. Populating
with the CLIA ID Number in OBX-23 meets the requirement if this
receiving EHR has access to a look-up table that will convert the
CLIA ID number to full demographics comprising OBX-23,Performing
Organization Name; OBX-24, Performing Organization Address; and
OBX-25, Performing Organization Medical Director. If the CLIA ID
number is not used, all demographic fields (OBX-23, OBX-24 and
OBX-25) must be populated with appropriate information.

SPM-4

Specimen Type

Reporting requirements call for the specimen source, which equates to
the Specimen Type in the SPM segment.

SPM-21

Specimen Reject Reason

Use this field in connection with OBX-11 if a test is cancelled for
specimen related reason. SNOMED-CT is the recommenced
terminology.

SPM-22

Specimen Quality

Use this field to provide a coded version for Specimen Description. For
Electronic Health Records, it is preferred that this field be used in
place of, or in connection with, SPM-14. SNOMED-CT is the
recommenced terminology.

B.2 REPORT RETENTION
While this section is not to be construed as legal advice, the electronic message from a performing laboratory is
presumed to be the legal report of the tests performed. Hence, the receiver must save the content of the message for
the same time period as required for any other legal document.
HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 205-230

Appendix B: Clinical Laboratory Improvements Amendment Considerations, US Realm Only

B.3 AUTHORIZED PARTIES
Local laws, generally at the State level, govern who is authorized to receive laboratory reports. CLIA restricts the
availability of those authorized to receive laboratory reports to just those approved at the local level and sets no
national standards. Testing laboratories may not report results to unauthorized parties under CLIA.
Testing laboratories either have a trusted relationship with the ordering party or presume that the ordering party is
authorized to receive results. However, testing laboratories need not have knowledge of the appropriateness of
others requested to receive results, such as "Copy to" recipients. To maintain CLIA compliance, a US testing
laboratory may choose to restrict its reports to only those recipients known to be authorized. Hence, copies of a
result need not be sent by a testing laboratory. Note that CLIA places no restrictions on the receiver of a laboratory
report regarding its retransmission of the report to others.

Page 206-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides

Appendix C. Strategy For
Harmonizing Multiple HL7
Implementation Guides
C.1 BACKGROUND
Multiple HL7 laboratory result implementation guides are being put forward to support various use cases. The
guides constrain the standard HL7 lab result message in various ways according to the needs of specific use cases.
These use cases include the HITSP Lab to EHR (Electronic Health Records), ELR (Electronic Laboratory Reporting)
to public health, NHSN (National Healthcare Safety Network) and others.
The sending laboratories for the above three Implementation Guides (IG) certainly overlap. All three are intended to
be used by US laboratories sending results to EHR’s, state/national public health agencies, or the National
Healthcare Safety Network. This creates tremendous burden for laboratories and other senders of lab data, who are
forced to generate three different sets of result message content for the same class of data.
The goal of this document is outline an approach for creating a harmonized set of specifications that allows senders
of lab data to use a single format to meet the needs of multiple receivers. It is not the goal of this document to force
all Laboratory Result IG’s into one specification. The goal of the strategy is to enable harmonization amongst guides
that are mutually compatible, and whose authors/stakeholders agree should be harmonized.
Each of the above IG's documents a message profile in which the conformance rules (e.g., for usage and cardinality)
are the same for the sender and receiver. These constrained profiles are tailored to suit the needs of the particular
receiver of data. The least constrained of the three is the Lab to EHR IG, followed by the ELR IG. The most tightly
constrained IG is the NHSN IG. In each case, the IG is focused on the data in which the receiver is interested. The
ELR and NHSN IG's mark a considerable number of elements as not supported, meaning the sender should never
send this data to the particular receiver. The Lab to EHR IG does have some elements that are not supported, but
considerably fewer than the other IG's.
This practice of marking data as not supported is a major reason why senders currently have to develop separate
interfaces to support each of these use cases. The goal here is to develop an approach to documenting these IG's
such that the sender needs only one interface to meet the requirements of all three receivers.
The first step is to separate the requirements of the sender from the receiver. As indicated above, the three source
IG's combine the requirements for both sender and receiver. By separating the two, we simplify the task of creating
a single sender specification that can be used to send lab data to all three receivers. The second step is to put in place
some rules governing how usage is related between the sender profile and the receiver profiles. These rules are
intended to prevent collisions between various requirements from receivers. These rules help identify places in the
IG’s where the three sets of receivers need to harmonize their specifications, allowing senders to support all 3
without requiring specialized interfaces for each receiver.
The harmonization strategy provided here was designed for an environment where the same type of message has
been used in multiple profiles. In this guide that message is HL7 ORU^R01. I is certainly possible to adapt this
harmonization strategy to work in the situation where different messages are used across multiple profiles, assuming
that those messages share common segments. In that circumstance, the strategy would only harmonize those
elements hat are in common across the various profiles such as data types, segments, vocabulary etc., but not
harmonizing on message structure. For example, it should be possible to adapt this strategy to harmonize across a
profile using the ORU^R01 and the OUL^R22 that are both capable of conveying laboratory results, and share many
common segments.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 207-230

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides

C.2 CONFORMANCE TO THE HL7 STANDARD
HL7 has defined a set of rules governing conformance with the 2.x series of standards. These rules are provided in
Chapter 2 of the HL7 standard. In version 2.7, these rules are provided in Chapter 2B, Conformance Using Message
Profiles. Understanding the rules for creating message profiles is essential to building a strategy for creating a
consistent set of implementation guides. Message profiles are composed of multiple elements, including:
•

use case definition

•

dynamic definitions

•

static definitions

•

vocabulary (table) definitions

The strategy being proposed in this document is intended to allow variations in the use case and dynamic definitions
while providing consistent static and vocabulary definitions. To accomplish this goal, this document will address
various aspects of a message profiles static and vocabulary definitions. This includes the following areas:
•

Usage

•

Cardinality

•

Length

•

Vocabulary

•

Identifiers

•

Pre-adoption of features

C.2.1 Usage
Usage is perhaps the most important, and probably the least understood aspect of developing a message profile. The
set of rules to be discussed focus on the HL7 concept of “usage”. In an HL7 v2.x message profile the term “usage”
is defined as follows:
Usage refers to the circumstances under which an element appears in a message.
Some elements must always be present, others may never be present, and others
may only be present in certain circumstances. A set of codes has been defined to
clearly identify the rules governing the presence of a particular element.
The rules govern the expected behavior of the sending application and limited
restrictions on the receiving application with respect to the element. These usage
codes expand/clarify the optionality codes defined in the HL7 standard.
The HL7 standard also defines the following set of Usage codes (related to the 2.x Optionality codes).
Table C-1. Usage Definitions by Sender and Receiver

TABLE C-1. USAGE DEFINITIONS BY SENDER AND RECEIVER
Usage

Description

Sender Meaning

R

Required

A conforming sending application shall Conforming receiving application shall process
populate all “R” elements with a non- (save/print/archive/etc.)
or
ignore
the
empty value.
information conveyed by required elements.

Page 208-230

Receiver Meaning

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides

TABLE C-1. USAGE DEFINITIONS BY SENDER AND RECEIVER
Usage

Description

Sender Meaning

RE

Required but may The element may be missing from the
be empty
message, but must be sent by the
sending application if there is relevant
data. A conforming sending application
must be capable of providing all "RE"
elements. If the conforming sending
application knows the required values for
the element, then it must send that
element. If the conforming sending
application does not know the required
values, then that element will be omitted.

O

Optional

This code indicates that the Usage for this This code indicates that the Usage for this
element has not yet been defined. A element has not yet been defined. A usage of
usage of Optional may not be used in Optional may not be used in implementation
implementation profiles (no-optionality profiles (no-optionality profiles). Conformance
profiles). Conformance may not be tested may not be tested on an Optional field.
on an Optional field. Narrower profiles Narrower profiles may be defined based on this
may be defined based on this profile, and profile, and may assign any usage code to the
may assign any usage code to the element
element

C

Conditional

This usage has an associated condition This usage has an associated condition
predicate (See section 2.12.6.6, predicate (See section 2.12.6.6, "Condition
"Condition predicate").
predicate").
If the predicate is satisfied:

Receiver Meaning
Receiving applications will be expected to
process (save/print/archive/etc.) or ignore data
contained in the element, but must be able to
successfully process the message if the
element is omitted (no error message should
be generated because the element is missing).

If the predicate is satisfied:

A conformant sending application must A conformant receiving application must
always send the element.
process or ignore data in the element. It may
raise an error if the element is not present.
If the predicate is NOT satisfied:

A conformant sending application must If the predicate is NOT satisfied:
NOT send the element.
A conformant receiving application must NOT
raise an error if the condition predicate is false
and the element is not present, though it may
raise an error if the element IS present.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 209-230

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides

TABLE C-1. USAGE DEFINITIONS BY SENDER AND RECEIVER
Usage

Description

Sender Meaning

Receiver Meaning

CE

Conditional but it This usage has an associated condition This usage has an associated condition
may be empty
predicate (See section 2.12.6.6, predicate (See section 2.12.6.6, "Condition
"Condition predicate").
predicate").
If the predicate is satisfied:

If the predicate is satisfied:

If the conforming sending application
knows the required values for the
element, then the application must send
the element. If the conforming sending
application does not know the values
required for this element, then the
element shall be omitted. The conforming
sending application must be capable of
knowing the element (when the predicate
is true) for all CE elements.

If the element is present, the conformant
receiving
application
shall
process
(display/print/archive/etc.) or ignore the values
of that element. If the element is not present,
the conformant receiving application shall not
raise an error due to the presence or absence
of the element.

If the predicate is not satisfied:

If the predicate is not satisfied:
The conformant receiving application may raise
an application error if the element is present.

The conformant sending application shall
not populate the element.
X

Not supported

For conformant sending applications, the Conformant receiving applications may ignore
element will not be sent.
the element if it is sent, or may raise an
application error.

In this table, the usage as it applies to the sender is shown in a separate column from the usage as it applies to the
receiver.

C.3 STRATEGY
This section provides details on various aspects of the proposed strategy for harmonizing multiple implementation
guides. Details will be provided for usage, cardinality, length, vocabulary and identifiers. Rules for pre-adoption of
features from subsequent HL7 versions are addressed. Finally, an overall “Golden Rule” is proposed to make the
strategy work.

C.3.1 Usage Rules
•

Sender Usage should be marked as X (Not Supported) only when no receivers support the element.

•

Receiver Usage should be marked X (Not Supported) only when all receivers do not support the element. If
one receiver supports the element, each receiver should at least mark the element as O (Optional).
Receivers should ignore optional elements in their receiver profile.

•

Sender usage should reflect the tightest constraint among the receivers. If any receiver has the element as R
(Required) then the element should be required for the sender.

•

Receiver conditional usage should not be contradictory. For instance if two receivers have an element
marked as conditional (C, CE), the conditions certainly need to be harmonized so the sender has only one
set of Condition predicates to deal with.

•

Receiver usage of R, RE, C, CE and O allow the receiver to ignore a data element. Receivers should
separately document what elements they actually support. When an element is being ignored by the
receiver, the elements presence or absence in a message should be ignored and no error should be raised,
unless the element is malformed according to the underlying HL7 standard.

Page 210-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides
Note that once sender usage has been established, there are restrictions on what cardinalities are allowed for the
element in question.
Table C-2. Usage Rules

TABLE C-2. USAGE RULES
Tightest

Allowed Receiver

Usage

receiver profiles

Receiver

Usage for other

Sender usage

Allowed Sender Cardinality

R

R, RE, CE, C, O

R

[1..1], [1..n], [1..*], [m..n], [m..*]

CE

CE, C, RE, O

CE

[0..1], [0..n], [0..*]

C

C, RE, O

C

[0..1], [0..n], [0..*]

RE

RE, O

RE

[0..1], [0..n], [0..*], [m..n], [m..*]

O

O

O

[0..1], [0..n], [0..*]

X

X

X

[0..0]

C.3.2 Cardinality
Like usage, cardinality will need to be harmonized. The HL7 Conformance documentation (HL7 2.5.1, Chapter 2,
section 2.12.6.4) links cardinality to usage. For instance, a required element must have a minimum cardinality of 1
or greater, cardinality of 0 is not allowed. Table 2 - Usage Rules above outlines the cardinalities allowed for various
usage constraints. The rules for cardinality are as follows:
•

The lower bound of cardinality for the element will be determined from the lower bound from all the profiles
sharing the tightest usage for the element. The lower bound cardinality will be the greatest lower bound value
from this set. If there is a single profile with the tightest usage, then the lower bound cardinality will equal that
profiles lower bound cardinality

•

The upper bound of cardinality for the element will be the loosest upper bound for all the profiles being
considered.

•

Where the receiver is expecting fewer repetitions of and element that the bound set by the above two rules, the
burden is on the receiver to determine which repetitions it is interested in receiving. This means the receiver
may need to scan repetitions beyond the number indicated in documented upper bound to identify repeats they
are interested in.
Example: A segment in a message is Optional and Repeating in the HL7 standard, for instance [{NTE}] (usage –
Optional, cardinality – 0..*). In one profile, the element has been constrained to Required with cardinality 1..1. In a
second profile, it has been constrained to Required with cardinality 2..3. In a third profile, it has been constrained to
RE with cardinality 0..5. The Sender profile would have the element as Required, with cardinality 2..5. The lower
cardinality limit of 2 came from the first profile that made the element required. The upper cardinality limit of 5
came from the second profile that had the loosest cardinality. A receiver conforming to the first profile (R, 1..1)
would be expected to look at all 5 repeats of the element to determine which one it is interested in receiving.

Table C- 3. Cardinality Example

TABLE C- 3. CARDINALITY EXAMPLE
Profile

Usage

Cardinality

HL7 Standard – [{NTE}]

Optional

0..*

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 211-230

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides

TABLE C- 3. CARDINALITY EXAMPLE
Profile

Usage

Cardinality

Profile 1

Required

1..1

Profile 2

Required

2..3

Profile 3

Required or empty

0..5

Sender profile

Required

2..5

C.3.3 Length
The recommendation here is to adopt the length documentation conventions from the latest HL7 version, in this case
2.7. Starting with v2.7, HL7 allows documentation of both a minimum and maximum length for an element.
In v2.7, length should not be specified for composite elements. In these cases, the actual minimum and maximum
lengths can be very difficult to determine due to the interdependencies on the component content, and the
specification of actual lengths is not useful either. This strategy also recommends adopting the standard length
ranges defined in v2.7 as opposed to trying to sort out differences between the various IG’s.

C3.3.1 Conformance Length
The concept of a conformance length was also introduced in v2.7. The conformance length indicates the minimum
length an application must support. For the purposes of this strategy, the upper limit of allowed length range will be
considered the conformance length.

C3.3.2 Truncation of data
One useful feature of length management in v2.7 is a set of new rules for handling truncation of data. This
document proposes supporting those rules. Truncation behavior will be documented for data type components and
segment definitions. We will use the same mechanism for documenting truncation behavior as the 2.7 standard:
•

= Truncation not allowed

•

# Truncation allowed

•

No character indicates the truncation behavior is not defined.

C.3.4 Vocabulary/Value Sets
Binding vocabulary to specific coded elements in messages will probably be one of the most troublesome aspects of
harmonizing the various specifications. Vocabulary is often selected to meet requirements specific to the use case
the specification designed to support. Identifying harmonized vocabulary spanning multiple use cases may be
difficult if not impossible. The following principles will be used a guide:
•

Use HL7 standard vocabularies where they are dictated by the standard

•

Use nationally harmonized standards where appropriate. This includes vocabularies selected by HITSP.

•

Where HL7 and HITSP have not identified specific vocabularies, attempt to harmonize the different value
sets for an element across the various specifications

•

Create new value sets that incorporate vocabularies that cannot be otherwise harmonized.

C.3.5 Identifiers
Uniformity is also needed in the treatment of identifiers, and the assigning authorities associated with those
identifiers. One example of issues in this area is one IG requiring use of an OID to identify a sending laboratory,

Page 212-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix C: Strategy For Harmonizing Multiple HL7 Implementation Guides
while a second IG requires the use of the laboratory’s CLIA number. The sending system cannot support both
requirements with a single message.
Since HITSP is the current US authority for implementations, it makes sense to use the HITSP strategy for handling
identifiers. This means the Lab to EHR IG should be used as the basis for handling particular identifiers. Other IG’s
following this strategy must support the HITSP identifier. They may allow other than those specified by HITSP, but
they cannot require the use of an identifier different from what HITSP has specified.
For example, in the Lab to EHR IG, MSH-4, Sending Application is required to be an OID. The ELR specification
must support an OID for MSH-4, but may allow a CLIA number instead. What the ELR IG cannot do is require the
use of the CLIA number.

C.3.6 Pre-adoption of Features
In many cases, implementation guides will pre-adopt features from newer versions of the HL7 standard. Where
features are being pre-adopted, all the harmonized specifications must agree on the version to be pre-adopted. The
following guidelines will be used when pre-adopting features:
•

Use the latest version of the HL7 2.x standard, which will soon be v2.7.

•

When new segments, data types, fields, components, sub-components, et al. are being pre-adopted, they
should be as loosely constrained as possible, unless all the harmonized specifications agree to tighter
constraints.

C.3.7 Golden Rule
The golden rule for this strategy is taken from HL7 2.7 Chapter 2, section 2.6.2, Rules for the Recipient:
•

ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but
were not expected

•

treat optional segments that were expected but are not present as consisting entirely of fields that are not
present

•

treat fields and components that are expected but were not included in a segment as not present.

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 213-230

Appendix D: Recommended Changes to Existing Implementation Guides

Appendix D. Recommended
Changes to Existing
Implementation Guides
Based on the harmonization strategy provided in Appendix C, this guide is recommending the following changes to
HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to
EHR, Release 1. Note that this IG is not making the actual changes; it is simply recommending certain changes be
made to harmonize the profiles.
Table D-1. Recommended Changes

TABLE D-1. RECOMMENDED CHANGES
Item

Recommendation

Harmonization Strategy

Adopt the harmonization strategy documented in Appendix C of this guide.

Data type Lengths

Pre-adopt the HL7 version 2.7 data type lengths as identified in this guide.

CWE Data type

Pre-adopt the HL7 2.7 structure for the CWE data type.

Batch processing

Add support for batch transaction processing for Lab results

Message Acknowledgements

Add a profile for result transmission without acknowledgement. Some transport
mechanisms exist that guarantee deliver of the payload, rendering the current
commit accept protocol unnecessary.

ORU^R01 Message Structure

Allow NTE following PID segment to repeat.

NK1 Segment

Add documentation for NK1 segment. There are two circumstances where NK1
should be used.
•

Identification of guardian for lab testing of minors. This is particularly important
for child lead testing.

SFT Segment

Identification of owner information for animal lab testing. This is relevant for
animal rabies testing as it relates to a human case of rabies exposure.
Add documentation for this segment.

ERR Segment

Add documentation of ERR segment

PID-35 (Species)

Add this as an optional field. This is needed for animal rabies testing.

PID36 (Breed)

Add this as an optional field. This is needed for animal rabies testing.

PID-37 (Strain)

Add this as an optional field. This is needed for animal rabies testing.

PID-38 (Production Class Code)

Add this as an optional field. This is needed for animal testing.

PID-39 (Tribal Citizenship)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

PV1-11 (Temporary Location)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

•

Page 214-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix D: Recommended Changes to Existing Implementation Guides

TABLE D-1. RECOMMENDED CHANGES
Item

Recommendation

PV1-14 (Admit Source)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

PV1-52 (Other Healthcare Provider)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

PV2-26 (Previous Treatment Date)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

PV2-29 (First Similar Illness Date)

Add this as an optional field. Some states collect this information as part of a
reportable lab result.

OBX-8 (Abnormal Flags)

Pre-adopt the CWE data type for this field from HL7 version 2.7. This was done to
allow communication of local abnormal flags along with the standard HL7 codes.

Align Observation Identifiers with data The ELR IG developed a strategy for relating the LOINC scale property with the
types for OBX-5
data type being used for OBX-5. This strategy also identifies when units of measure
are required, when abnormal flags are appropriate, reference ranges and
comments. This strategy is detailed in section 5.12.1 of this guide.
FHS Segment

Add documentation of this segment

FTS Segment

Add documentation of this segment

BHS Segment

Add documentation of this segment

BTS Segment

Add documentation of this segment

HL70002 (Marital Status)

This needs to be harmonized with HITSP:
Note, HITSP has identified a different value set in HITSP C80:
•

Name: Marital Status Value Set

• Source: Health Level Seven (HL7) Version 3.0
The HL7 Lab to EHR IG adopted by HITSP uses the HL70002
HL70004 (Patient Class)

This needs to be harmonized with HITSP:
Note, HITSP has identified a different value set in HITSP C80:

HL70023 (Admit Source)

•

Name: Patient Class Value Set

•

Source: Health Level Seven (HL7) Version 3.0 Act Encounter Code
The HL7 Lab to EHR IG adopted by HITSP uses the HL70004

This needs to be harmonized with HITSP:
Note, HITSP has identified a different value set in HITSP C80:
•

Name: Admission Source Value Set

Source: National Uniform Billing Committee (NUBC). See UB-04/NUBC
CURRENT UB DATA SPECIFICATIONS MANUAL) UB-04 FL15
The HL7 Lab to EHR IG adopted by HITSP does not support this element.

•

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 215-230

Appendix D: Recommended Changes to Existing Implementation Guides

TABLE D-1. RECOMMENDED CHANGES
Item

Recommendation

HL70078 (Abnormal Flags-2.5.1, This needs to be harmonized with HITSP and within HL7.
Observation Interpretation 2.8))
Note, HITSP has identified a different value set in HITSP C80:
•

Name: Result Normalcy Status Value Set

• Source: Health Level Seven (HL7) Version 3.0 Observation Interpretation.
The HL7 Lab to EHR IG adopted by HITSP uses the HL70078 from 2.5.1.
The ELR IG has pre-adopted the HL7 version 2.7 Observation Interpretation code
system, which adds new values not in 2.5.1 or in the HL7 V3 vocabulary (what a
mess).
HL70112 (Discharge Disposition)

This needs to be harmonized with HITSP.
Note, HITSP has identified a different value set in HITSP C80:
•

Name: Discharge Disposition Value Set

Source: National Uniform Billing Committee (NUBC). UB-04/NUBC
CURRENT UB DATA SPECIFICATIONS MANUAL- UB-04 FL17 – Patient
Status.
The HL7 Lab to EHR IG adopted by HITSP uses the HL70112.
•

HL70305 (Person location type)

This needs to be harmonized with HITSP.
Note that NHSN has adopted the HL7 Version 3 Healthcare Service Location coding
system for this field.

HL70834 (Imported Table 0834 –
MIME Types)

This needs to be harmonized with HITSP.

Laboratory Observation Identifier
Value Set

The Laboratory Test Result Value Set form HITSP C80 as it is defined today is
inadequate for both ELR to Public Health and NHSN reporting. This IG defined an
expanded value set called Laboratory Observation Identifier Value Set which is the
union of the following value sets:

Note that the HITSP Lab to EHR IG uses HL70191, which can be directly mapped
to the 2.7 values imported from IANA.

•

Laboratory Test Result Value Set

•

ELR Reportable Laboratory Observation Identifier Value Set

• NHSN Lab test id value set (TBD)
Laboratory Coded Observation Value This needs to be harmonized with HITSP C80. The Laboratory Coded Observation
Set
Value Set is drawn from SNOMED CT. At a minimum, it will contain the SNOMED
CT® Laboratory Test Finding (118246004) hierarchy and the SNOMED CT®
Microorganism (264395009) sub-tree. It may also need to contain various modifiers
and qualifiers as identified in PHVS_ModifierOrQualifier_CDC value set.
The HITSP C80 Laboratory Observation Value Set covers only the
Laboratory Test Findings portion of this value set, and really needs to be
expanded to cover at least microorganisms and commonly use qualifiers
and modifiers.

Page 216-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Appendix D: Recommended Changes to Existing Implementation Guides

TABLE D-1. RECOMMENDED CHANGES
Item

Recommendation

Primary Spoken Language

It’s not clear if the HITSP C80 value set for Primary Spoken Language is the same
as that identified in this IG (ISO-639). Note that HITSP identifies a language value
set as follows:
“The value set is defined by Internet RFC 4646 (replacing RFC 3066). Please see
ISO 639 language code set maintained by Library of Congress for enumeration of
language codes and Frequently Asked Questions.”
RFC4646 seems to point to ISO 639 as the source of the actual language codes, so
this value set is consistent with the HITSP value set.

Reason For Study Value Set

This needs to be harmonized with HITSP.
Reason
for
Study.
Union
of
PHVS_AdministrativeDiagnosis_CDC_ICD-9CM and ICD-10.

concepts

from

Note: HITSP apparently has stopped using ICD-9 for diagnosis and focused on
using value sets from SNOMED CT.
SPM-4 (Specimen Type)

Adopt the Specimen Type Value Set, which uses the HL7 table 0487 and the
SNOMED CT Specimen sub-tree (12303009).

SPM-5 (Specimen Type Modifier)

Adopt the PHVS_ModifierOrQualifier_CDC (a subset of SNOMED CT) as the value
set for this field.

SPM-7 (Specimen Collection Method) Adopt the Specimen Collection Method Value Set, which includes the HL7 table
0488, and SNOMED CT Specimen Collection (17636008) sub-tree.
SPM-9 (Specimen Source Site
Modifier)

Adopt the PHVS_ModifierOrQualifier_CDC (a subset of SNOMED CT) as the value
set for this field.

OBSERVATION Begin

Adopt harmonized condition predicate for OBSERVATION Begin group in ORU^R01
message structure.

MSH-15 Accept Acknowledgment
Type

Adopt harmonized condition predicate for MSH-15.

MSH-16 Application Acknowledgment Adopt harmonized condition predicate for MSH-16.
Type
OBR-26 Parent Result

Adopt harmonized condition predicate for OBR-26

OBR-29 Parent

Adopt harmonized condition predicate for OBR-29

OBX-4 Observation Sub-ID

Adopt harmonized condition predicate for OBX-4.

OBX-5 Observation Value

Adopt harmonized condition predicate for OBX-5

OBX-6 Units

Adopt harmonized condition predicate for OBX-6

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1

Page 217-230

Appendix D: Recommended Changes to Existing Implementation Guides

This page intentionally left blank.

Page 218-230

HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1