CompanionGuide Lab Result

Lab Result
Companion Guide
Lab Result Companion Guide
Refers to the Implementation Guide

Based on
HL7 version 2.5
Companion Guide Version Number: 6.2
September, 2016
This material is provided on the recipient’s agreement that it will only be used for the purpose of describing UnitedHealthcare
products and services to the recipient. Any other use, copying or distribution without the express written permission of
UnitedHealthGroup is prohibited.
Page 1 of 74
Lab Result
Companion Guide
Change Log
Version Release date Changes
1.0 December, 2009  Initial External Release
2.0 January, 2010  Updated to include:
- Edits identified by Jim Reitter
- Edits identified by Lori McDougall
- Edits identified by Lab Galaxy Team
- Population of correct values in both Data Type
and Optionality columns of Segment Tables
3.0 February, 2010  Updated to include initial Legal feedback
- Added “Draft/Confidential” watermark to
document
- Clarified notice of changes provision language
(pg 4)
 Updated to include additional edits identified by
Jim Reitter
4.0 April 2010  Updated name of the document to include most
current date.
5.0 June 2010  Updated page 47 to include data types.
6.0 May, 2011  Updated to include:
- Order of segments changed
- Value examples reformatted
- Clarified Table of Contents
6.1 November, 2013 Updated to include:
- updated testing information, p.5
- changes in PID 3 and PID 7
- updated OBX 3
- updated FT 1-4 and FT1-19
6.2 September, 2016 Updated to include:

- OBR 20 length correction
Page 2 of 74
Lab Result
Companion Guide
Table of Contents
Table of Contents ........................................................................................... 3
Introduction .................................................................................................. 5
Scope ........................................................................................................ 5
Overview.................................................................................................... 5
References ................................................................................................. 5
Getting Started .............................................................................................. 6
Connectivity with UnitedHealthcare ............................................................... 6
Contact Information .................................................................................... 7
Provider Specific Business Rules and Limitations ............................................. 7
Transaction Specific Information ...................................................................... 8
Basic Message Construction Rules ................................................................. 8
HL7 Message Structure ................................................................................ 8
File Delimiters ............................................................................................. 9
File Specifications ...................................................................................... 10
Batch File Structure ................................................................................... 10
Segment Ordering ..................................................................................... 11
Segment Table Key ................................................................................... 12
Data Types .................................................................................................. 13
Optionality Designation ................................................................................. 14
Lab Result HL7 Batch File Segments ............................................................... 16
FHS – File Header Segment ........................................................................ 17
BHS – Batch Header Segment ..................................................................... 19
MSH – Message Header Segment ................................................................ 21
PID – Patient Identification Segment ........................................................... 27
OBR – Observation Request Segment .......................................................... 35
OBX – Observation Result Segment ............................................................. 47
NTE – Notes and Comments Segment .......................................................... 55
Page 3 of 74
Lab Result
Companion Guide
FT1 – Financial Transaction Segment ........................................................... 56

BTS – Batch Trailer Segment ...................................................................... 63
FTS – File Trailer Segment ......................................................................... 63
Appendices.................................................................................................. 64
Transaction Layout Examples ...................................................................... 64
Acknowledgement Messages ....................................................................... 66
MSA – Message Acknowledgment Segment................................................... 67
ERR – Error Segment ................................................................................. 68
Frequently Asked Questions........................................................................ 72
Page 4 of 74
Lab Result
Companion Guide
Introduction
Scope
This guide is to be used for the development of data interfaces to transmit laboratory test
results to UnitedHealthcare. As the healthcare industry evolves toward
standards-based communications for clinical data, UnitedHealthcare has recognized the
need to move away from custom and proprietary methods and towards common
standards that eliminate or substantially reduce the custom interface programming
and program maintenance that may otherwise be required.
The UnitedHealthcare standard described in this companion guide is based on the Health
Level Seven (HL7) version 2.5 messaging standard for electronic data exchange in
healthcare environments which was designed to conform to the requirements of the
American National Standards Institute (ANSI). During the development of the
UnitedHealthcare lab result data exchange standard, a deliberate effort was made to
support prior version implementations of HL7 for applications and systems that can
generate HL7 release 2.2, 2.3, 2.3.1, and 2.4 extracts in addition
to the 2.5 version that our standard is based upon.
This document describes the elements of HL7 messages as they relate to the
UnitedHealthcare standard for data transmission of lab result data and is not intended
to be an introduction to HL7 messages and standards. Readers unfamiliar with HL7
should first review the section below on Basic Message Construction Rules and/or the
information describing the HL7 2.x standard, available at www.hl7.org.
Overview
This is the November, 2013 release of the UnitedHealthcare Lab Result Companion
Guide and has been written to assist you in designing and implementing HL7 transactions
to meet UnitedHealthcare's processing standards. This Companion Guide must be used
in conjunction with the instructions as set forth by the American National Standards
Institute (ANSI) HL7 Working Group. The UnitedHealthcare Companion Guide identifies
key data elements from the transaction set that we request you provide to us. The
recommendations made are to enable you to more effectively complete EDI transactions
with UnitedHealthcare.
Updates to this guide will occur periodically and new documents will be distributed to all
submitting labs in writing in advance with not less than 30 days notice.
References
See Version 2.5 of the Health Level 7 standard for a full description of all messages,
segments, and fields. Information regarding HL7 is available at www.hl7.org.
Page 5 of 74
Lab Result
Companion Guide
Getting Started
Connectivity with UnitedHealthcare
Submitting Lab Result data to UnitedHealthcare is available through an internet based
EDI portal that provides a comprehensive electronic communication channel that is
rapid and secure.
EDI Connections:
Transmission Administrative Procedures

The first step is to register to request an account. If you have an existing
account, you can simply request to add lab result EDI transactions to your
current profile and complete the testing and production implementation
process.
You can transmit electronic data using the following methods:

 HTTPS Batch
 FTP + PGP Batch
 FTP over SSL Batch
Submitting a Test File
The purpose of the testing phase is to provide you with a mechanism to produce
the same reports and acknowledgments that are generated once you are in
production. You can test your ability to submit correct data content and your
ability to receive and process the acknowledgments and files that are generated
as a result of your file submission.
Transactions are processed by the file transport and validation facility but are not
sent for processing as they would be in the production environment. Reports will
be generated specifically related to your file submission along with HL7
acknowledgment transactions for each message within the file.
Please note that during the test phase, field and segment format validation are
checked for data within required segments. After production promotion, data
content and quality are validated which may require additional changes.
The general process is as follows:

1. You initiate self-testing of transactions by submitting a lab results file
formatted according to the specifications in this guide.
2. You receive back a set of reports and acknowledgment transactions
that correspond to the data you submitted.
3. Reports will show any errors or problems that were found in the
transactions sent.
4. You should continue testing until you have successfully submitted data
without any reported errors and then request production status for the
lab result transaction.
Page 6 of 74
Lab Result
Companion Guide
5. Your test to production status change request will be reviewed and you will
be notified when your request has been approved.
Troubleshooting
Contact UnitedHealthcare EDI Support at SupportEDI@uhc.com
Contact Information
Most questions can be answered by referencing the materials posted at

UnitedHealthcareOnline.com
In the event that you have additional questions of a clinical nature please contact your
UnitedHealthcare Network Representative. If you have hospital contract related
questions, please contact your local UnitedHealthcare Network Account Manager.
For any connectivity issues or questions, please contact UnitedHealthcare EDI
Support at SupportEDI@uhc.com.
For login or password issues, reports, account setup, and for any issues with
transactions in testing status:
 Contact: Customer Support
 Phone: 800-445-8174 M-F 8 a.m. to 5 p.m. Eastern Time.
 Email: UnitedHelpDesk@ediconnect.com
Provider Specific Business Rules and Limitations
When registering for an account when you have multiple Tax Identification Numbers
(TIN), there are two registration options that you should consider.
Registering a single Tax Identification Number and submitting all lab result data through
a single account would allow you to view all submitted data and reports with a single
sign-on for all of your Tax Identification Numbers.
Registering individually on the site for each of your Tax Identification Numbers and
submitting data specific to that TIN under the individually registered account would
require you to separate your lab result data into separate files by TIN. Individual
accounts by TIN would prevent you from viewing all of your data submissions at once
as compared to a single account registration but has the potential advantage that you
would have a smaller number of data to review within each single file acknowledgment
and report.
Page 7 of 74
Lab Result
Companion Guide
Transaction Specific Information

Basic Message Construction Rules
Encoding Rules for Sending

- Encode each segment in the order specified in the abstract message format.
- Place the Segment ID first in the segment.
- Precede each data field with the field separator.
- Encode the data fields in the order and data type specified in the segment
definition table.
- End each segment with the segment terminator.
- Components, subcomponents, or repetitions that are not valued at the end of a field
need not be represented by component separators. The data fields below, for
example, are equivalent:
^XXX&YYY&&^ is equal to ^XXX&YYY^
|ABC^DEF^^| is equal to |ABC^DEF|
Encoding Rules for Receiving

- If a data segment that is expected is not included, treat it as if all data fields within
were not present.
- If a data segment is included that is not expected, ignore it; this is not an error.
- If data fields are found at the end of a data segment that are not expected, ignore
them; this is not an error.
HL7 Message Structure
HL7 messages include data fields of various lengths and are separated by delimiters.
Fields are grouped by segments that may be required by HL7 rules or optional to be
used at the discretion of the submitter.
 Message
o Segment (repeatable)
 Fields (repeatable)
 Components
o Subcomponents
Segment Layout
 The first 3 characters = segment ID code
 Data field sequence:
o Field separator (|)
o If the value is not present, no further characters are required
o Present but not null, include values/characters. Be aware of the
maximum field length
o If the field is separated into components:
 Include component separators (^) if necessary
 Include no characters for components that are not present but
Page 8 of 74
Lab Result
Companion Guide
retain their position with a component separator (^) if more

components follow
 Include no separators for components not present at the end of a
field
o If the field is separated into Subcomponents:
 Include Subcomponent separators (&) if necessary
 Include no characters for Subcomponents that are not present but
retain their position with a subcomponent separator (&) if
more subcomponents follow
 Include no separators for Subcomponents not present at the end
of a field
o If the field definition repeats (if allowed):

 Use Repetition separator (~) only if more than one occurrence
is sent (Place between occurrences.)
 Repeat the Data Field sequence if there are any fields present to be sent. If no
other data fields are present then no further characters are required
 ASCII carriage return character <CR> (hex 0D) is the Segment Terminator.
File Delimiters
Encoding
Delimiter Value Character Usage
Position
Segment <CR> - Terminates a segment record. This value
Terminator cannot be changed by implementers.
Field | - Separates two adjacent data fields within a
Separator segment. It also separates the segment
ID from the first data field in each
segment.
Component ^ 1 Separates adjacent components of data
Separator fields where allowed.
Subcomponent & 4 Separates adjacent subcomponents of data
Separator fields where allowed. If there are no
subcomponents, this character may be
omitted.
Repetition ~ 2 Separates multiple occurrences of a field
Separator where allowed.
Escape \ 3 Escape character for use with any field
Character represented by an ST, TX or FT data type,
or for use with the data (fourth)
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.
Page 9 of 74
Lab Result
Companion Guide
File Specifications
UnitedHealthcare has put together the following grid to assist you in designing and
programming the information we need in order to submit lab result data. The table
contains a row for each segment that UnitedHealthcare has something additional, over
and above, the information in the HL7 Standard.
In addition to the row for each segment, one or more additional rows are used to
describe UnitedHealthcare’s usage for composite and simple data elements and for any
other information. All segments, data elements, and codes supported in the HL7
guidelines are acceptable; however, all data may not be used in the processing of
this transaction by UnitedHealthcare.
Batch File Structure

When messages are sent in a batch file containing multiple messages, the following
UnitedHealthcare Batch Protocol should be used to “bundle” the messages and provide
appropriate header information. UnitedHealthcare’s Batch Protocol specifies the
segments required for submission.
A physical file requires a single FHS (File Header Segment) terminated by a single
FTS (File Trailer Segment)
Each FHS requires one to many groups of BHS (Batch Header Segment)
terminated by BTS (Batch Trailer Segment)
Each BHS requires one to many MSH (Message Header)
Each MSH requires a single PID (Patient Identification)*

Each PID segment requires one to many OBR (Observation Request)
Each OBR segment requires one to many OBX
(Observation/Result)
Each OBX may have one to many NTE (Notes and comments)
Each OBR must be followed by a single FT1 (Financial
Transaction)
Each BHS must be ended by a single BTS (Batch Trailer Segment) for that
BHS/BTS group
A physical file requires a single FTS (File Trailer Segment) at the end of the file
*The UnitedHealthcare standard requests that only one PID segment be sent within a
MSH to reduce the number of segments rejected if an error is found. Therefore, the PID
sequence should always be set to 1.
The structure of HL7 messages is defined in special notation that lists the segment IDs
in the order they would appear in the message. Braces, { . . . }, indicate one or more
repetitions of the enclosed group of segments. Brackets, [ . . . ], show that the enclosed
Page 10 of 74
Lab Result
Companion Guide
group of segments is optional. The following table describes the required segments and
cardinality of segments and groups of segments in the UnitedHealthcare lab result HL7
standard.
Segment Identifier Usage Cardinality Segment Name

FHS R [1..1] File Header Segment
{ R [1..*] File Batch Group
BHS R [1..1] Batch Header Segment
{ R [1..*] Message Group
MSH R [1..*] Message Header
PID R [1..1] Patient Identification
[{NTE}] O [0..*] Notes and Comments
{ R [1..*] Test Order Group
OBR R [1..1] Observations Request
{[NTE]} O [0..*] Notes and comments
{ R [1..*] Test Result Group
OBX R [1..1] Observation/Result (OBR
related)
{[NTE]} RE [1..*] Notes and comments
}
FT1 R [1..1] Financial Transaction
BTS R [1..1] Batch Trailer Segment
}
FTS R [1..1] File Trailer Segment
Segment Ordering
The structure of a typical lab result message will consist of a MSH segment followed by
one PID segment with related OBR/FT1 segments with one to many OBX result
segments.
The ordering of the segments in the file must enforce the hierarchical relationship of the
segments within a properly formatted HL7 ORU_R01 lab result message. The required
segments listed above identify the minimum set of segments required in a standard
batch file. If any of the required segments in a lab result data submissions is missing,
the lab result message will be rejected.
Within the UnitedHealthcare lab result HL7 standard, FT1 is defined as a required
segment since it contains billing information that will be used within our internal
processing to match the lab result billing procedure codes to the same billing procedure
code on the claim record. As part of the standard definition of an ORU_R01 message,
groups of related OBR and FT1 segments must be submitted within each PID patient
identification segment. The UnitedHealthcare standard further restricts the HL7
standard to require only a single FT1 segment for each OBR segment. A matching OBR
and FT1 segment with the same Set ID value must be included before the next OBR/FT1
or MSH segment and the OBR segment must be included before the matching FT1
segment.
Page 11 of 74
Lab Result
Companion Guide
Following is an example:
PID –Set ID 1
OBR –Set ID 1
OBX –Set ID 1
FT1 –Set ID 1
OBR –Set ID 2
OBX –Set ID 1
FT1 –Set ID 2
An additional requirement within the UnitedHealthcare lab result HL7 standard is that a
single message (MSH) contains information only for a single patient (PID
segment). This requirement will permit error processing for individual messages
without having to reject the entire batch or file due to a single error.
Segment Table Key

The following table defines the various column headers in the Message Control
Segment tables.
Table Item Definition

SEQ Sequence of elements as numbered in the segment
ELEMENT Element name as specified by HL7 (Reference only and will not
appear in message)
LEN Length of the element
DT Data Type
OPT R = Required
RE = Required but might be empty
O = Optional
RP/# Blank = No repetitions permitted
Y = repeatable indefinitely
Y/x (where x = repeatable times)
Page 12 of 74
Lab Result
Companion Guide
Data Types
HL7 Table 0440 – Data types
Data Type Data Type Name

CE Coded element
CNE Coded with no exceptions
CP Composite price
CQ Composite quantity with units
CWE Coded with exceptions
CX Extended composite ID with
check digit
DLN Driver’s license number
DR Date/time range
EI Entity identifier
EIP Entity identifier pair
HD Hierarchic designator
ID Coded values for HL7 tables
IS Coded value for user-defined
tables
MOC Money and charge code
MSG Message type
NDL Name with location and date
NM Numeric
PL Person location
PRL Parent result link
PT Processing type
SI Sequence ID
SPS Specimen source
ST String
TQ Timing/quantity
TS Time stamp
VID Version identifier
XAD Extended address
XCN Extended composite ID number and name
XPN Extended person name
XTN Extended telecommunications number
Page 13 of 74
Lab Result
Companion Guide
Optionality Designation
The following table outlines the optionality designations that have been defined by
HL7 and supported by UnitedHealthcare:
UnitedHealthcare
Value Definition Description Requirement
R Required A conforming sending application These elements must
shall populate all “R” elements with a have a value that
non-empty value. Conforming conforms to the
receiving application shall process element’s data type
(save/print/archive/etc.) or ignore specification. Lack of
the information conveyed by required a value or invalid
elements. A conforming receiving coding of this element
application must not raise an error will generate an error
due to the presence of a required and result in the
element, but may raise an error due message being
to the absence of a required element. rejected.
Any element designated as required
in a standard HL7 message definition
shall also be required in all HL7
message profiles of that standard
message.
Page 14 of 74
Lab Result
Companion Guide
UnitedHealthcare
Value Definition Description Requirement
RE Required The element may be missing from the These elements are
but may message, but must be sent by the expected to be
be empty sending application if there is populated when a valid
relevant data. A conforming sending value is available that
application must be capable of conforms to the
providing all "RE" elements. If the element’s data type
conforming sending application knows specification and
the required values for the element, intended usage.
then it must send that element. If the If a valid value is not
conforming sending application does available for this
not know the required values, then element, null values
that element will be omitted. are acceptable.
O Optional The component/sub-component may These elements may

be populated, but this is entirely at be populated at the
the discretion of the sending system. discretion of the
If the component/sub-component is sending application
populated (non-NULL), it must with a value that
conform to the specifications of that conforms to the
component/sub-component in HL7 element’s data type
version 2.5. Otherwise, the receiving specification. Lack of
application may indicate an error. a data value will NOT
Any specification of content or cause an error or
formatting for these components or automatic rejection of
sub-components beyond what is the message.
specified in HL7 version 2.5 must be
negotiated separately between
trading partners.
Page 15 of 74
Lab Result
Companion Guide
Lab Result HL7 Batch File Segments

The structure of the physical batch file consists of a single header and trailer segment
with the FHS File Header Segment as the first line in the physical file and the FTS File
Trailer Segment as the last line in the physical file. Within the FHS/FTS, there can be
one to many sets of BHS batch header segments and BTS batch trailer segments.
Within the batch header/trailer, MSH message segments group the individual lab result
values.
Example:
FHS
BHS
MSH (one to many)
BTS
FTS
Page 16 of 74
Lab Result
Companion Guide
FHS – File Header Segment

The FHS segment is used to head a file (group of batches) and must be the first line in
the physical batch file.
SEQ ELEMENT NAME LEN DT OPT RP/# TBL#

1 File Field Separator 1 ST R
2 File Encoding Characters 4 ST R
3 File Sending Application 227 HD O
4 File Sending Facility 227 HD R
5 File Receiving Application 227 HD O
6 File Receiving Facility 227 HD O
7 File Creation Date/Time 26 TS R
8 File Security 40 ST O
9 File Name/ID 20 ST R
10 File Header Comment 80 ST O
11 File Control ID 20 ST R
12 Reference File Control ID 20 ST O
FHS-1 File Field Separator [R] - This field has the same definition as the
corresponding field in the MSH segment.
Value is |, (ASCII 124).
FHS-2 File Encoding Characters [R] - This field has the same definition as the
corresponding field in the MSH segment.
Values are:
Component delimiter = "^"
Repeating delimiter = "~"
Escape character = "\"
Sub-component delimiter = "&"
(ASCII 94, 126, 92, and 38, respectively)
FHS-3 File Sending Application - Optional Value
FHS-4 File Sending Facility [R] - This field has the same definition as the
corresponding field in the MSH segment. This field further describes the FHS-3-
Sending Application and is UnitedHealthcare’s assigned identifier for the lab service
provider submitting the data. The value in this field should be set to the identifier that
uniquely identifies this submitter to UnitedHealthcare and that has been agreed upon
between the submitter and UnitedHealthcare and is usually the submitter’s Tax ID.
Page 17 of 74
Lab Result
Companion Guide
HL7 format for HD data type:

<Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
Field: FHS-4 File Sending Facility (HD)

Component/Sub-Component OPT
Namespace ID (IS) R
Universal ID (ST) O
Universal ID Type (ID) O
Value Example
123456789^LabName(as registered in Connectivity Director)^L
FHS-5 File Receiving Application - Optional Value
FHS-6 File Receiving Facility - Optional Value
FHS-7 File Creation Date/Time [R] - This field contains the date and time that the
sending system created the file. Note: This field should be reported to at least a
precision of minutes. Values with lesser precisions will be considered non- conformant.
The TS data type component degree of precision is a HL7 backward compatible value as
of HL7 v2.3 and will be ignored if sent.
HL7 format for TS data type:

YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^<degree of precision>
Field: FHS-7 File Creation Date/Time (TS)

YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ] R
degree of precision O
Value Example
minimum precision YYYYMMDDHHMM:
200911241217 [12:17 pm on November 24, 2009]
FHS-8 File Security- Optional Value
FHS-9 File Name/ID [R] – This field can be used by the application processing file. The
UnitedHealthcare standard requires that this value be set to either:
 The physical file name of the external file transmitted within the constraint that
this element is limited to a maximum of 20 characters as defined by
the HL7 standard.
Or
 A unique value to identify this file submission which could be the same
value as sent in the FHS-11 File Control ID.
FHS-10 File Header Comment - Optional Value
Page 18 of 74
Lab Result
Companion Guide
FHS-11 File Control ID [R] -This field is used to identify a particular file uniquely
with a maximum of 20 characters in numeric form. This uniqueness must persist over
time. It can be echoed back in FHS-12-reference file control ID.
FHS-12 Reference File Control ID- Optional Value
BHS – Batch Header Segment

The BHS segment defines the start of a batch. One to many groups of BHS/BTS
batches may be included in a single physical file, but generally most lab result files
will contain a single batch.

1 Batch Field Separator 1 ST R
2 Batch Encoding Characters 4 ST R
3 Batch Sending Application 227 HD O
4 Batch Sending Facility 227 HD R
5 Batch Receiving Application 227 HD O
6 Batch Receiving Facility 227 HD O
7 Batch Creation Date/Time 26 TS R
8 Batch Security 40 ST O
9 Batch Name/ID/Type 20 ST O
10 Batch Comment 80 ST O
11 Batch Control ID 20 ST R
12 Reference Batch Control ID 20 ST O
BHS-1 Batch Field Separator [R] - This field has the same definition as the
corresponding field in the FHS and MSH segments. This field contains the separator
between the segment ID and the first real field, BHS-2-batch encoding characters. As
such it serves as the separator and defines the character to be used as a separator for
the rest of the message.
BHS-2 Batch Encoding Characters [R]- This field has the same definition as the
corresponding field in the FHS and MSH segments. This field contains the four
characters in the following order: the component separator, repetition separator,
escape characters, and subcomponent separator.
Values are:
Page 19 of 74
Lab Result
Companion Guide

Value Example
Send Constant Value “^~\&”
BHS-3 Batch Sending Application - Optional Value
BHS-4 Batch Sending Facility [R] - This field has the same definition as the
corresponding field in the FHS and MSH segments. This field further describes the BHS-
3-Batch Sending Application and is UnitedHealthcare’s assigned identifier for the lab
service provider submitting the data. The value in this field should be set to the identifier
that uniquely identifies this submitter to UnitedHealthcare and that has
been agreed upon between the submitter and UnitedHealthcare and is usually the
submitter’s Tax ID.

Field: BHS-4 Batch Sending Facility (HD)

Namespace ID (IS) R
Universal ID (ST) O
Value Example
123456789^LabName^L
BHS-5 Batch Receiving Application - Optional Value
BHS-6 Batch Receiving Facility - Optional Value
BHS-7 Batch Creation Date/Time [R] - This field contains the date/time that the
sending system created the batch. If the time zone is specified, it will be used
throughout the message as the default time zone. Note: This field should be reported to
at least a precision of minutes. Values with lesser precisions will be considered non-
conformant. The TS data type component degree of precision is a HL7 backward
compatible value as of HL7 v2.3 and will be ignored if sent.

Field: BHS-7 Batch Creation Date/Time (TS)

Page 20 of 74
Lab Result
Companion Guide
Value Example
200911241217 [12:17 pm on November 24, 2009]
BHS-8 Batch Security - Optional Value
BHS-9 Batch Name/ID/Type - Optional Value
BHS-10 Batch Comment - Optional Value
BHS-11 Batch Control ID [R] - This field is used to uniquely identify a particular
batch. It can be echoed back in BHS-12-reference batch control ID if an answering
batch is needed. This field allows a maximum of 20 characters in numeric form.
BHS-12 Reference Batch Control ID - Optional Value
MSH – Message Header Segment

The MSH segment is used to define the intent, source, destination, and some
specifics of the syntax of a message.

1 Field Separator 1 ST R
2 Encoding Characters 4 ST R
3 Sending Application 227 HD RE
4 Sending Facility 227 HD R
5 Receiving Application 227 HD O
6 Receiving Facility 227 HD R
7 Date/Time Of Message 26 TS R
8 Security 40 ST O
9 Message Type 15 MSG R
10 Message Control ID 20 ST R
11 Processing ID 3 PT R
12 Version ID 60 VID R
13 Sequence Number 15 NM O
14 Continuation Pointer 180 ST O
15 Accept Acknowledgment Type 2 ID O
16 Application Acknowledgment Type 2 ID O
Page 21 of 74
Lab Result
Companion Guide

17 Country Code 3 ID O
18 Character Set 16 ID O Y
19 Principal Language Of Message 250 CE O
20 Alternate Character Set Handling 20 ID O
Scheme
21 Message Profile Identifier 427 EI O Y
MSH-1 Field Separator [R] - This field contains the separator between the segment
ID and the first real field, MSH-2-encoding characters. As such it serves as the
separator and defines the character to be used as a separator for the rest of the
message.
MSH-2 Encoding Characters [R] - This field contains the four characters in the
following order: the component separator, repetition separator, escape character, and
subcomponent separator.
Values are:
MSH-3 Sending Application [RE] - This field uniquely identifies the sending lab
service provider for purposes of differentiation between sources of data. The
Universal ID Type, if specified, should be set to “L” for “Locally defined coding
scheme” Refer to HL7 Table 0301 - Name Type for valid values.

Field: MSH-3 Sending Application (HD)

Namespace ID (IS) RE
Universal ID (ST) O
Value Examples
LabExtractApp or
LabExractApp^LEA.V2^L
Page 22 of 74
Lab Result
Companion Guide
MSH-4 Sending Facility [R] - This field further describes the MSH-3-sending
application and is UnitedHealthcare’s assigned identifier for the lab service provider
submitting the data. The value in this field should be set to the identifier that uniquely
identifies this submitter to UnitedHealthcare and that has been agreed upon between the
submitter and UnitedHealthcare. This is usually the submitter’s Tax Identification
Number (TIN). The Universal ID Type, if specified, should be set to “L” for “Locally
defined coding scheme” Refer to HL7 Table 0301 - Name Type for valid values.
Field: MSH-4 Sending Facility (HD)

Namespace ID (IS) R
Universal ID (ST) O
Value Example
123456789^LabName^L
MSH-5 Receiving Application – Optional Value
MSH-6 Receiving Facility [R] - This field identifies the receiving application among
multiple identical instances of the application running on behalf of different organizations.
The Universal ID Type, if specified, should be set to “L” for “Locally defined coding
scheme” Refer to HL7 Table 0301 - Name Type for valid values.

Field: MSH-6 Receiving Facility (HD)

Namespace ID (IS) R
Universal ID (ST) O
Required Value
Send Constant Value “LABGATEWAY”:
LABGATEWAYÛnitedHealth Group^L
MSH-7 Date/Time of Message [R] - This field contains the date/time that the sending
system created the message. If the time zone is specified, it will be used throughout the
message as the default time zone. This field should be reported to at least a precision of
minutes. Values with lesser precisions will be considered non- conformant. The TS data
type component degree of precision is a HL7 backward compatible value as of HL7 v2.3
and will be ignored if sent.
Page 23 of 74
Lab Result
Companion Guide

Field: MSH-7 Date/Time of Message (TS)
Value Example
200911241217 [12:17 pm on November 24, 2009]
MSH-8 Security – Optional Value
MSH-9 Message Type [R] - This field contains the message type, trigger event, and
the message structure ID for the message.
Refer to HL7 Table 0076 - Message type for valid values for the message code. The
UnitedHealthcare interface definition requires ORU to be sent for the <Message Code
(ID)>.
Refer to HL7 Table 0003 - Event type for valid values for the trigger event. The
UnitedHealthcare interface definition requires R01 to be sent for the <Trigger Event
(ID)>.
Refer to HL7 Table 0354 - Message structure for valid values for the message structure.
The UnitedHealthcare interface definition requires ORU_R01 to be sent for the <Message
Structure (ID)>.
HL7 format for MSG data type:

<Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
Field: MSH-9 Message Type (MSG)

Message Code (ID) R
Trigger Event (ID) R
Message Structure (ID) R
Required Value
ORU^R01ÔRU_R01
Page 24 of 74
Lab Result
Companion Guide
MSH-10 Message Control ID [R] - This field contains a number or other identifier
that uniquely identifies the message. The receiving system echoes this ID back to the
sending system in the Message acknowledgment segment (MSA). The sending system
must assign an identifier for the message that will remain globally unique for the lab
service provider (MSH-3). This will guarantee that the combination of the
Message control ID and the Sending Application constitute a globally unique message
identifier.
MSH-11 Processing ID [R] - This field is used to decide whether to process the
message as defined in HL7 Application (level 7) Processing rules.
Required Value is P (Production = "P") HL7 format for PT data type:

<Processing ID (ID)> ^ <Processing Mode (ID)>
Field: MSH-11 Processing ID (PT)

Processing ID (ID) R
Processing Mode (ID) O
MSH-12 Version ID [R] - This field is matched by the receiving system to its own
version to be sure the message will be interpreted correctly. The UnitedHealthcare
standard is based on HL7 version 2.5 but has attempted to accommodate backward
compatibility to HL7 version 2.2. Valid values include "2.2", "2.3", "2.3.1", "2.4", "2.5".
HL7 format for VID data type:

<Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version
ID (CE)>
Field: MSH-12 Version ID (VID)

Version ID (ID) R
Internationalization Code (CE) O
Internationalization Version ID (CE) O
Value Example
2.5
MSH-13 Sequence Number – Optional Value
MSH-14 Continuation Pointer – Optional Value
MSH-15 Accept Acknowledgment Type – Optional Value
MSH-16 Application Acknowledgment Type – Optional Value
Page 25 of 74
Lab Result
Companion Guide
MSH-17 Country Code – Optional Value
MSH-18 Character Set – Optional Value
MSH-19 Principal Language of Message – Optional Value
MSH-20 Alternate Character Set Handling Scheme – Optional Value
MSH-21 Message Profile Identifier – Optional Value
Page 26 of 74
Lab Result
Companion Guide
PID – Patient Identification Segment

The PID segment is used by all applications as the primary means of
communicating patient identification information. This segment contains
permanent patient identifying and demographic information that, for the most
part, is not likely to change frequently.

1 Set ID - PID 4 SI R
2 Patient ID (2.5) 20 CX RE
3 Patient Identifier List 250 CX R Y
4 Alternate Patient ID - PID 20 CX RE Y
5 Patient Name 250 XPN R Y
6 Mother’s Maiden Name 250 XPN O Y
7 Date/Time of Birth 26 TS R
8 Administrative Sex 1 IS RE 0001
9 Patient Alias 250 XPN O Y
10 Race 250 CE RE Y 0005
11 Patient Address 250 XAD RE Y
12 County Code 4 IS O
13 Phone Number - Home 250 XTN O Y
14 Phone Number - Business 250 XTN O Y
15 Primary Language 250 CE O
16 Marital Status 250 CE O 0002
17 Religion 250 CE O 0006
18 Patient Account Number 250 CX O
19 SSN Number - Patient 16 ST O
20 Driver's License Number - Patient 25 DLN O
21 Mother's Identifier 250 CX O Y
22 Ethnic Group 250 CE O Y 0189
23 Birth Place 250 ST O
24 Multiple Birth Indicator 1 ID O 0136
25 Birth Order 2 NM O
26 Citizenship 250 CE O Y
27 Veterans Military Status 250 CE O
28 Nationality 250 CE O
Page 27 of 74
Lab Result
Companion Guide

29 Patient Death Date and Time 26 TS O
30 Patient Death Indicator 1 ID O 0136
31 Identity Unknown Indicator 1 ID O 0136
32 Identity Reliability Code 2 IS O Y 0445
0
33 Last Update Date/Time 2 TS O
6
34 Last Update Facility 2 HD O
4
35 Species Code 2 CE O
1
5
36 Breed Code 2 CE O
0
5
37 Strain 8 ST O
0
0
38 Production Class Code 2 CE O 2 0429
39 Tribal Citizenship 5
2 CWE O Y
0
5
0
PID-1 Set ID - PID [R] - This field contains the number that identifies this
transaction. The HL7 standard identifies that for the first occurrence of the
segment within the parent MSH segment, the sequence number shall be one, for
the second occurrence, the sequence number shall be two, etc. For the
UnitedHealthcare standard, since only a single PID segment is requested for a
MSH segment, this value should always be set to 1.
PID-2 Patient ID [RE] - This is a deprecated field and is not used by

UnitedHealthcare. Submitters must use PID-3 for this information.
PID-3 Patient Identifier List [R] - This field contains the list of identifiers (one or
more) used by the healthcare facility to uniquely identify a patient (e.g., medical record
number, billing number, birth registry, national unique individual identifier, etc.). The
UnitedHealthcare assigned Patient Identifier (Member ID from insurance card) must be
included in this field and set with an identifier type code of “HC” for “Health Card
Number”. The UnitedHealthcare assigned Patient Identifier must be the first value sent
in this repeating value field before any other sets of identifiers.
If lab provider specific identifiers are sent, they should be coded using the identifier type
code of HC PI, MR, or SS depending on the ID number being submitted. The type of
identifier for each identifier sent should be indicated in the <identifier type code ID)>
component. Refer to HL7 Table 0203 – Identifier type for the complete list. The patient
identifier itself should be placed in the <ID (ST)> component. The
expected valid values for <identifier type code (ID)> for the UnitedHealthcare
interface are:
Page 28 of 74
Lab Result
Companion Guide
Value Description Comment

HC Health Card Number The Subscriber number from the UnitedHealth
Group issued medical card.
MR Medical record An identifier that is unique to a patient within a
number set of medical records, not necessarily unique
within an application.
SS Social Security
number
PI Patient Internal A number that is unique to a patient within an
Identifier Assigning Authority.
HL7 format for CX data type:

<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^
<Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility
(HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction
(CWE)> ^ <Assigning Agency or Department (CWE)>
Field: PID3 Patient Identifier List (CX)

ID Number (ST) R
Check Digit (ST) O
Check Digit Scheme (ID) O
Assigning Authority (HD) O
Identifier Type Code (ID) RE
Assigning Facility (HD) O
Effective Date (DT) O
Expiration Date (DT) O
Assigning Jurisdiction (CWE) O
Assigning Agency or Department (CWE) O
Value Example
987123456^^^^HC
PID-4 Alternate Patient ID [RE] - From V2.3.1, this field has been retained for
backward compatibility only. It is recommended to use PID-3 - Patient Identifier List for
all patient identifiers. When used for backward compatibility, this field contains
the alternate, temporary, or pending optional patient identifier to be used if needed - or
additional numbers that may be required to identify a patient. This field may be used to
convey multiple patient IDs when more than one exist for a patient. Possible contents
might include a visit number, a visit date, or a Social Security Number. UnitedHealthcare
Assigned Group Number as shown on the medical ID card.
HL7 format for CX data type:

<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^
<Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility
(HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning
Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Page 29 of 74
Lab Result
Companion Guide
Field: PID-4 Alternate Patient ID (CX)

ID Number (ST) RE
Check Digit (ST) O
Assigning Authority (HD) O
Identifier Type Code (ID) RE
Effective Date (DT) O
Expiration Date (DT) O
Value Example
987654^^^^HC
PID-5 Patient Name [R] - This field contains the names of the patient, the primary or
legal name of the patient is reported first. Therefore, the name type code in this field
should be “L - Legal”. Refer to HL7 Table 0200 - Name Type for valid values. Repetition
of this field is allowed for representing the same name in different character sets. Note
that “last name prefix” is synonymous to “own family name prefix” of previous versions of
HL7, as is “second and further given names or initials thereof” to “middle initial or name”.
Multiple given names and/or initials are
separated by spaces. The expected value for <name type code (ID> is “L” reflecting the
legal name of the patient.
HL7 format for XPN data type:

<Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or
Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^
<Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name
Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range
(DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration
Date (TS)> ^ <Professional Suffix (ST)>
Page 30 of 74
Lab Result
Companion Guide
Field: PID-5 Patient Name (XPN)

Family Name (FN) R
Given Name (ST) R
Second and Further Given Names O
or Initials Thereof (ST)
Suffix (e.g. JR or III) (ST) O
Prefix (e.g. DR) (ST) O
Degree (e.g. MD) (IS) O
Name Type Code (ID) RE
Name Representation Code (ID) O
Name Context (CE) O
Name Validity Range (DR) O
Name Assembly Order (ID) O
Effective Date (TS) O
Expiration Date (TS) O
Professional Suffix (ST) O
Value Example
Smith^John^Q^^^^L [Legal name of John Q. Smith]
PID-6 Mother’s Maiden Name – Optional Value
PID-7 Date/Time of Birth [R] - This field contains the patient’s date and time of birth.
The TS data type component degree of precision is a HL7 backward compatible value as
of HL7 v2.3 and will be ignored if sent.

Field: PID-7 Date/Time of Birth (TS)

Value Example
minimum precision YYYYMMDD:
20091124 [November 24, 2009]
PID-8 Administrative Sex [RE] - This field contains the patient’s sex. Refer to
User-defined Table 0001 - Administrative Sex for the HL7 defined values Expected
Page 31 of 74
Lab Result
Companion Guide
values for the UnitedHealthcare interface are:
Table 0001 - Sex

F Female
M Male
U Unknown
PID-9 Patient Alias – Optional Value
PID-10 Race [RE] - This field refers to the patient’s race. Refer to User-defined
Table 0005 - Race for suggested values. The second triplet of the CE data type for
race (alternate identifier, alternate text, and name of alternate coding system) is
reserved for governmentally assigned codes.
User-defined Table 0005 - Race

Value Description
1002-5 American Indian or Alaska Native
2028-9 Asian
2054-5 Black or African American
2076-8 Native Hawaiian or Other Pacific Islander
2106-3 White
2131-1 Other Race
HL7 format for CE data type:

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate
Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Field: PID-10 Race (CE)

Identifier (ST) RE
Text (ST) RE
Name of Coding System (ID) RE
Alternate Identifier (ST) O
Alternate Text (ST) O
Name of Alternate Coding System (ID) O
Value Example
2106-3^White^HL7
PID-11 Patient Address [RE] - This field contains the mailing address of the patient.
Address type codes are defined by HL7 Table 0190 - Address Type. Multiple addresses
for the same person may be sent in the following sequence: The primary mailing
address must be sent first in the sequence (for backward compatibility); if the mailing
address is not sent, then a repeat delimiter must be sent in the first sequence. The
minimum expected data submitted to UnitedHealthcare is to include the patient’s
mailing address (Address Type “M”).
Page 32 of 74
Lab Result
Companion Guide
HL7 format for XAD data type:

<Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or
Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type
(ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^
<Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <Address Validity
Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>
Field: PID-11 Patient Address (XAD)

street address (SAD) RE
> street address (ST) RE
> street name (ST) O
> dwelling number (ST) O
other designation (ST) O
city (ST) RE
state or province (ST) RE
zip or postal code (ST) RE
country (ID) O
address type (ID) RE
other geographic designation (ST) O
county/parish code (IS) O
census tract (IS) O
address representation code (ID) O
address validity range (DR) O
Address Validity Range (DR) O
Value Example
123 Main StreetÂpt. 3B^St. Louis^MO^63146-8524^^M
PID-12 County Code – Optional Value
PID-13 Phone Number - Home – Optional Value
PID-14 Phone Number - Business – Optional Value
PID-15 Primary Language – Optional Value
PID-16 Marital Status- Optional Value
PID-17 Religion – Optional Value
PID-18 Patient Account Number – Optional Value
Page 33 of 74
Lab Result
Companion Guide
PID-19 SSN - Patient – Optional Value
PID-20 Driver’s License Number – Optional Value
PID-21 Mother’s Identifier – Optional Value
PID-22 Ethnic Group – Optional Value
PID-23 Birth Place- Optional Value
PID-24 Multiple Birth indicator – Optional Value
PID-25 Birth Order – Optional Value
PID-26 Citizenship – Optional Value
PID-27 Veterans Military Status – Optional Value
PID-28 Nationality – Optional Value
PID-29 Patient Death Date and Time – Optional Value
PID-30 Patient Death Indicator – Optional Value
PID-31 Identity Unknown Indicator – Optional Value
PID-32 Identity Reliability Code – Optional Value
PID-33 Last Update Date/Time – Optional Value
PID-34 Last Update Facility – Optional Value
PID-35 Species Code – Optional Value
PID-36 Breed Code – Optional Value PID-
37 Strain – Optional Value
PID-38 Production Class Code- Optional Value
PID-39 Tribal Citizenship – Optional Value
Page 34 of 74
Lab Result
Companion Guide
OBR – Observation Request Segment

The Observation Request (OBR) segment is used to transmit information specific to
an order for a diagnostic study or observation, physical exam, or assessment. In
the reporting of clinical observations, the OBR segment serves as the report
header. It describes an entire set of observations.

1 Set ID – OBR 4 SI R
2 Placer Order Number 22 EI O
3 Filler Order Number 50 EI R
4 Universal Service Identifier 250 CE R
5 Priority – OBR 2 ID O
6 Requested Date/Time 26 TS O
7 Observation Date/Time # 26 TS RE
8 Observation End Date/Time # 26 TS RE
9 Collection Volume 20 CQ RE
10 Collector Identifier 250 XCN O Y
11 Specimen Action Code 1 ID O 0065
12 Danger Code 250 CE O
13 Relevant Clinical Info. 300 ST O
14 Specimen Received Date/Time 26 TS O
15 Specimen Source 300 SPS O
16 Ordering Provider 250 XCN RE Y
17 Order Callback Phone Number 250 XTN RE Y/2
18 Placer Field 1 60 ST O
19 Placer Field 2 60 ST O
20 Filler Field 1 60 ST O
21 Filler Field 2 120 ST O
22 Results Rpt/Status Chng – Date/Time 26 TS RE
23 Charge to Practice 40 MOC O
24 Diagnostic Serv Sect ID 10 ID O 0074
25 Result Status 1 ID RE 0123
26 Parent Result 400 PRL RE
27 Quantity/Timing 200 TQ RE Y
28 Result Copies To 250 XCN O Y
Page 35 of 74
Lab Result
Companion Guide

29 Parent 200 EIP RE
30 Transportation Mode 20 ID O 0124
31 Reason for Study 250 CE O Y
32 Principal Result Interpreter 200 NDL O
33 Assistant Result Interpreter 200 NDL O Y
34 Technician 200 NDL O Y
35 Transcriptionist 200 NDL O Y
36 Scheduled Date/Time 26 TS O
37 Number of Sample Containers * 4 NM O
38 Transport Logistics of Collected Sample 250 CE O Y
39 Collector's Comment * 250 CE O Y
40 Transport Arrangement Responsibility 250 CE O
41 Transport Arranged 30 ID O 0224
42 Escort Required 1 ID O 0225
43 Planned Patient Transport Comment 250 CE O Y
44 Procedure Code 250 CE O
45 Procedure Code Modifier 250 CE O Y
46 Placer Supplemental Service Information 250 CE O Y
47 Filler Supplemental Service Information 250 CE O Y
48 Medically Necessary Duplicate Procedure 250 CWE O
Reason.
49 Result Handling 2 IS O 0507
Page 36 of 74
Lab Result
Companion Guide
OBR-1 Set ID – OBR [R] – This field contains the number that identifies the order
sequence of this segment within the parent PID segment. This value should begin
at
1 and increment by 1 for each subsequent OBR segment within the PID segment.
The sequence number should begin at 1 again for OBR segments within the next
PID segment. The UnitedHealthcare standard requires that the Set ID numeric
value is directly associated with the same numerical FT1 segment Set ID value. A
valid HL7
ORU_R01 message order requires that the OBR is sent after the matching
FT1 segment within a parent PID.
Example:
PI
D
OBR|1|
OBX|1
|
FT1|1|  FT1-1 associated with OBR-1
OBR|2|
OBX|1
|
OBR-2 Placer Order Number – Optional Value
OBR-3 Filler Order Number [R]– This field is the order number associated with the
filling application. This is a permanent identifier for an order and its associated
observations. It is a special case of the Entity Identifier data type (Section 2.16.28, “EI -
Entity Identifier”). The first component is a string that identifies an order detail segment
(e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned
by the order filler (receiving) application. This string must uniquely identify the order (as
specified in the order detail segment) from other orders in a particular filling application
(e.g., clinical laboratory). This uniqueness must persist over time. The second through
fourth components contain the filler application ID, in the form of the HD data type (see
Section 2.16.36, “HD - hierarchic designator”).
The second component is a user-defined coded value that uniquely defines the
application from other applications on the network. A limit of six (6) characters is
suggested but not required. The second component of the filler order number always
identifies the actual filler of an order.
This value uniquely identifies an order and associated observations from a filling
application (clinical laboratory). This uniqueness must persist over time and remain
unique across all laboratories, subsidiary locations, and all tests. Common usage would
be a test order number. When the possibility exists that a laboratory may have different
subsidiaries or locations potentially using the same sequencing algorithms, the
<Namespace ID (IS> value must be included along with the value for <Universal ID
(ST>. The <Namespace ID (IS)> value identifies the lab organization using the same
value within field MSH-4 while the <Universal ID (ST)> value identifies the individual
subsidiary site or location.
Page 37 of 74
Lab Result
Companion Guide
HL7 format for EI data type:

<Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^
<Universal ID Type (ID)>
Field: OBR-3 Filler Order Number (EI)

Entity Identifier (ST) R
Namespace ID (IS) RE
Universal ID (ST) RE
Value Example
359826^123456789^SL921
[Subsidiary location SL921 for organization with Tax ID
123456789 with lab test order 359826]
RTC-359826
[Assumes that the Sending Facility is the assigning authority for
this Filler order number since not otherwise indicated]
OBR-4 Universal Service Identifier [R] – This field contains the identifier code for
the requested observation/test/battery. This can be based on local and/or “universal”
codes. We recommend the “universal” procedure identifier.
This value should be populated with the identifier for the procedure code (CPT-4)
associated with the lab result observation request in the OBR segment related to the FT1
segment. The coding system should be “C4” CPT-4 (see HL7 table 0396 Coding system).
Typically this value will be the same as FT1-7 and FT1-25 but in some cases the value
may be different based on individual lab provider coding methods. See the discussion for
FT1-7 for clarification. For lab proprietary coding system as an alternative identifier, use
“L” (Local general code)

Field: OBR-4 Universal Service Identifier (CE)

Identifier (ST) R
Text (ST) RE
Page 38 of 74
Lab Result
Companion Guide
Value Example
80061^Lipid Panel^C4
OR
80061^Lipid Panel^C4^423.1^Lipid Panel^L
OBR-5 Priority–OBR – Optional Value
OBR-6 Requested Date/Time – Optional Value
OBR-7 Observation Date/Time [RE]– This field is the clinically relevant date/time of
the observation and identifies the actual date and time the specimen was collected or
obtained.

Field: OBR-7 Observation Date/Time (TS)

Value Example
200911241217 [12:17 pm on November 24, 2009]
OBR-8 Observation End Date/Time [RE]– This field is the end date and time of a
study or timed specimen collection. If an observation takes place over a substantial
period of time, it will indicate when the observation period ended. For observations made
at a point in time, it will be null. This is a results field except when the placer
or a party other than the filler has already drawn the specimen.

Field: OBR-8 Observation End Date/Time (TS)

Value Example
200911241217 [12:17 pm on November 24, 2009]
Page 39 of 74
Lab Result
Companion Guide
OBR-9 Collection Volume [RE] – For laboratory tests, the collection volume is the
volume of a specimen. The default unit is ML. Specifically, units should be expressed in
the ISO Standard unit abbreviations (ISO-2955, 1977).
HL7 format for CQ data type:

<Quantity (NM)> ^ <Units (CE)>
Field: OBR-9 Collection Volume (CQ)

Quantity (NM) RE
Units (CE) RE
Value Example
125^ML
OBR-10 Collector Identifier – Optional Value OBR-
11 Specimen Action Code – Optional Value OBR-12
Danger Code – Optional Value
OBR-13 Relevant Clinical Information – Optional Value
OBR-14 Specimen Received Date/Time – Optional Value
OBR-15 Specimen Source – Optional Value
OBR-16 Ordering Provider [RE]– This value is defined as a repeating XCN data type
value in the HL7 specification. The UnitedHealthcare definition of this field is an XCN
data type that identifies the provider who ordered the test and a second set of XCN
provider values for the treating provider (if treating provider is known).
Ordering provider is always the first value in this group. The <ID Number (ST)>
must be clarified by the <Assigning Authority (HD)> using Table 0363 Assigning
Authority (listed below). The expected value for the provider identifier is NPI.
HL7 format for XCN data type:

<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and
Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III)
(ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^
<Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)>
^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier
Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code
(ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^
<Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date
(TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^
<Assigning Agency or Department (CWE)>
Page 40 of 74
Lab Result
Companion Guide
Field: OBR-16 Ordering Provider (XCN)

ID Number (ST) RE
Family Name (FN) RE
>Family Name (ST) RE
>Own Family Name Prefix (ST) O
>Own Family Name (ST) O
>Family Name Prefix from Partner/Spouse (ST) O
>Family Name from Partner/Spouse (ST) O
Given Name (ST) RE
Second and Further Given Names or Initials Thereof (ST) O
Suffix (e.g., JR or III) (ST) O
Prefix (e.g., DR) (ST) O
DEPRECATED-Degree (e.g., MD) (IS) O
Source Table (IS) O
Assigning Authority (HD) RE
>Namespace ID (IS) RE
>Universal ID (ST) O
>Universal ID Type (ID) O
Name Type Code (ID) O
Identifier Check Digit (ST) O
Identifier Type Code (IS) O
Name Representation Code (ID) O
Name Context (CE) O
DEPRECATED - Name Validity Range (DR) O
Name Assembly order (ID) O
Professional Suffix (ST) O
Page 41 of 74
Lab Result
Companion Guide
HL7 Table 0363 – Assigning Authority

NPI National Class: Insurance
Provider In the US, the Assigning Authority for this value is typically
Identifier CMS, but it may be used by all providers and insurance
companies in HIPAA related transactions.
MD Medical License An identifier that is unique to a medical doctor within the

Number jurisdiction of a licensing
board.
TAX Tax ID Number
UPIN UPIN Medicare/CMS (formerly HCFA)_s Universal
Physician Identification numbers
PRN Provider A number that is unique to an individual provider, a
number provider group or an
organization within an Assigning Authority.
Value Example
7583493848^Randolph^JamesÂ^Jr^^^^NPI
[Example of NPI ordering provider]
OR
7583493848^Randolph^JamesÂ^Jr^^^^NPI~125361259^Tolly^Tom^^^^^^NPI
[Example of NPI ordering and NPI treating provider]
OBR-17 Order Callback Phone Number [RE]– This value is the telephone
number for the provider who ordered the test.
HL7 format for XTN data type:

<DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)>
^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^
<Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^
<Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial
Code (ST)> ^ <Unformatted Telephone number (ST)>
Page 42 of 74
Lab Result
Companion Guide
Field: OBR-17 Order Callback Phone Number (XTN)

DEPRECATED-Telephone Number (ST) O
Telecommunication Use Code (ID) O
Telecommunication Equipment Type (ID) O
Email Address (ST) O
Country Code (NM) O
Area/City Code (NM) RE
Local Number (NM) RE
Extension (NM) O
Extension Prefix (ST) O
Any Text (ST) O
Speed Dial Code (ST) O
Unformatted Telephone number (ST) O
Value Example
^^^^^987^5551212
OR
^WPN^PH^^^987^5551212^^^call before 5:00 pm only~ÂSN^PH^^^789^5552121
[Example of two phone numbers sent]
OBR-18 Placer Field1 – Optional Value
OBR-19 Placer Field2 – Optional Value
OBR-20 Filler Field1 – Optional Value
OBR-21 Filler Field2 – Optional Value
OBR-22 Results Rpt/Status Chng - Date/Time [RE]– This field specifies the
date/time results reported or status changed.

Field: OBR-22 Results Rpt/Status Chng - Date/Time (TS)

Value Example
200911241217 [12:17 pm on November 24, 2009]
Page 43 of 74
Lab Result
Companion Guide
OBR-23 Charge to Practice – Optional Value
OBR-24 Diagnostic Serv Sect ID – Optional Value
OBR-25 Result Status [RE]– This field is the status of results for this order. Based on
the HL7 definition, this field is required whenever the OBR is contained in a report
message. If the status pertains to the order detail segment, use OBR-25-result
status and OBR-22-results report/status change - date/time. Refer to HL7 2.5
Chapter 4, Section 4.5.3.25, HL7 Table 0123 - Result status for valid entries.
Expected values for the UnitedHealthcare lab results interface standard are “F” –
Final or “X” – Cancelled.
HL7 Table 0123 - Result Status

Value Description
C Correction to results
F Final results; results stored and verified. Can only be changed with a
corrected result.
X No results available; Order canceled.
OBR-26 Parent Result [RE] – This field is defined to make it available for other types
of linkages (e.g., toxicology). This important information, together with the information
in OBR-29-parent, uniquely identifies the parent result’s OBX segment related to this
order. The value of this OBX segment in the parent result is the organism or chemical
species about which this battery reports. For example, if the current battery is an
antimicrobial susceptibility, the parent result’s identified OBX contains a result which
identifies the organism on which the susceptibility was run. This indirect linkage is
preferred because the name of the organism in the parent result may undergo several
preliminary values prior to finalization. The third component may be used to record the
name of the microorganism identified by the parent result directly. The organism in this
case should be identified exactly as it is in the parent culture. We emphasize that this
field does not take the entire result field from the parent. It is meant only for the text
name of the organism or chemical subspecies identified. This field is included only to
provide a method for linking back to the parent result for those systems which could not
generate unambiguous Observation IDs and sub-IDs. This field is present only when the
parent result is identified by OBR-29-parent and the parent spawn child orders for each
of many results. (See Chapter 7 for more details about this linkage.) A second mode of
conveying this information is to use a standard observation result segment (OBX). If
more than one organism is present, OBX-4-observation subID is used to distinguish
them. In this case, the first OBX with subID N will contain a value identifying the Nth
microorganism, and each additional OBX with subID N will contain susceptibility values
for a given antimicrobial test on this organism.
OBR-27 Quantity/Timing [RE]– This field is retained for backward compatibility only.
This field contains information about how many services to perform at one service time
and how often the service times are repeated, and to fix duration of the request.
Page 44 of 74
Lab Result
Companion Guide
HL7 format for TQ data type:

<Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time
(TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text
(TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence
Duration (CE)> ^ <Total Occurrences (NM)>
Field: OBR-27 Quantity/Timing (TQ)

Quantity (CQ) RE
Interval (RI) RE
Duration (ST) RE
Start Date/Time (TS) RE
End Date/Time (TS) RE
Priority (ST) O
Condition (ST) O
Text (TX) O
Conjunction (ID) O
Order Sequencing (OSD) O
Occurrence Duration (CE) O
Total Occurrences (NM) O
OBR-28 Result Copies To – Optional Value
OBR-29 Parent [RE] – This field relates a child to its parent when a parent/child
relationship exists. For example, observations that are spawned by previous
observations, e.g., antimicrobial susceptibilities spawned by blood cultures, need to
record the parent (blood culture) filler order number here. It is required when the order
is a child.
OBR-30 Transportation Mode – Optional Value
OBR-31 Reason for Study – Optional Value
OBR-32 Principal Result Interpreter – Optional Value
OBR-33 Assistant Result Interpreter – Optional Value
OBR-34 Technician – Optional Value
OBR-35 Transcriptionist – Optional Value
OBR-36 Scheduled Date/Time – Optional Value
OBR-37 Number of Sample Containers – Optional Value
OBR-38 Transport Logistics of Collected Sample – Optional Value
Page 45 of 74
Lab Result
Companion Guide
OBR-39 Collector’s Amount – Optional Value
OBR-40 Transport Arrangement Responsibility – Optional Value
OBR-41 Transport Arranged – Optional Value
OBR-42 Escort Required – Optional Value
OBR-43 Planned Patient Transport Comment – Optional Value
OBR-44 Procedure Code – Optional Value
OBR-45 Procedure Code Modifier – Optional Value
OBR-46 Placer Supplemental Service Information – Optional Value
OBR-47 Filler Supplemental Service Information – Optional Value
OBR-48 Medically Necessary Duplicate Procedure Reason – Optional Value
OBR-49 Result Handling – Optional Value
Page 46 of 74
Lab Result
Companion Guide
OBX – Observation Result Segment

The OBX segment is used to transmit a single lab-result value. It represents the
smallest indivisible unit of a laboratory report.

1 Set ID – OBX 4 SI R
2 Value Type 2 ID RE 0125
3 Observation Identifier 250 CE R 0396
4 Observation Sub-ID 20 ST RE
5 Observation Value 9999 varies RE Y
9
6 Units 250 CE RE
7 References Range 60 ST RE
8 Abnormal Flags 5 IS RE Y 0078
9 Probability 5 NM O
10 Nature of Abnormal Test 2 ID O Y 0080
11 Observation Result Status 1 ID R 0085
12 Effective Date of Reference Range 26 TS O
(2.5)
13 User Defined Access Checks 20 ST O
14 Date/Time of the Observation 26 TS RE
15 Producer's ID 250 CE RE
16 Responsible Observer 250 XCN O Y
17 Observation Method 250 CE O Y
18 Equipment Instance Identifier 22 EI O Y
19 Date/Time of the Analysis 26 TS O
OBX-1 Set ID - OBX [R] – This field contains the sequence number to identify the OBX
segment instance numerically within the parent OBR segment; this is a required value
when the OBX segment is sent. This value should begin at 1 and increment by 1 for each
subsequent OBX segment following the parent OBR segment. The sequence number should
begin at 1 again for OBX segments within the next OBR
segment.
OBX-2 Value Type [RE] - This field contains the format of the observation value in
OBX. It must be valued if OBX-11-Observation result status is not valued with an ‘X”. If
the value is CE then the result must be a coded entry. When the value type is TX
or FT then the results are bulk text. The valid values for the value type of an
observation are listed in HL7 Table 0125 - Value Type.
The observation value must be represented according to the format for the data type
Page 47 of 74
Lab Result
Companion Guide
defined in Chapter 2, Section 2.9, “Data Types.” For example, a PN consists of 6

components, separated by component delimiters.
Although NM is a valid type, observations which are usually reported as numbers will
sometimes have the string (ST) data type because non-numeric characters are often
reported as part of the result, e.g., >300 to indicate the result was off-scale for the
instrument. In the example, "">300"", "">"" is a symbol and the digits are considered a
numeric value. However, this usage of the ST type should be discouraged since the SN
(structured numeric) data type now accommodates such reporting and, in addition,
permits the receiving system to interpret the magnitude.
All HL7 data types are valid, and are included in Table 0125 except CM, CQ, SI, and
ID.
HL7 Table 0125 - Value type
Value Description
AD Address
CE Coded Entry
CF Coded Element With Formatted Values
CK Composite ID With Check Digit
CN Composite ID And Name
CP Composite Price
CX Extended Composite ID With Check Digit
DT Date
ED Encapsulated Data
FT Formatted Text (Display)
MO Money
NM Numeric
PN Person Name
RP Reference Pointer
SN Structured Numeric
ST String Data.
TM Time
TN Telephone Number
TS Time Stamp (Date & Time)
TX Text Data (Display)
XAD Extended Address
XCN Extended Composite Name And Number For Persons
XON Extended Composite Name And Number For Organizations
XPN Extended Person Name
XTN Extended Telecommunications Number
OBX-3 Observation Identifier [R] - This field contains a unique identifier for the
observation. The format is that of the Coded Element (CE). Example: 8625-6^P-R
interval^LN. The expected coding systems for the UnitedHealthcare lab result standard
are “LN” for LOINC. If LOINC is unavailable we can accept “L” for Local general or
proprietary codes.
Page 48 of 74
Lab Result
Companion Guide
When local codes are used as the first identifier in this field, HL7 encourages sending a
universal identifier as well to permit receivers to equivalence results from different
providers of the same service (e.g., a hospital lab and commercial lab that provides
serum potassium to a nursing home). LOINC® is an HL7 approved code system for the
Observation identifier. It covers observations and measurements, such as laboratory
tests, physical findings, radiology studies, and claims attachments and can be obtained
from www.regenstrief.org/loinc/loinc.htm. One possible universal identifier is LOINC®
codes for laboratory and clinical measurements.

Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System
(ID)>
Field: OBX-3 Observation Identifier (CE)
Identifier (ST) R
Text (ST) RE
Value Example
2571-8^Triglycerides^LN [Example of LOINC code for Triglycerides]
OR
2571-8^Triglycerides^LN^477X2^Triglycerides^L [Example of LOINC
code for Triglycerides followed by a lab provider specific coding]
OBX-4 Observation Sub-ID [RE] - This field is used to distinguish between multiple
OBX segments with the same observation ID organized under one OBR. For example, a
chest X-ray report might include three separate diagnostic impressions. The standard
requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of
the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely
identify each OBX segment for editing or replacement. The sub- identifier is also used to
group related components in reports such as surgical pathology. It is traditional for
surgical pathology reports to include all the tissues taken from one surgical procedure in
one report
OBX-5 Observation Value [RE] - This field contains the value observed by the
observation producer. OBX-2-value type contains the data type for this field according
to which observation value is formatted. HL7 defines this value as not a
required field because some systems will report only the normalcy/abnormalcy (OBX-
8), especially in product experience reporting but for lab result reporting, this value is
expected to be populated for each OBX segment. The length of the observation
field is variable, depending upon OBX-3-value type. This field may repeat for
multipart, single answer results with appropriate data types, e.g., CE, TX, and FT
data types.
Page 49 of 74
Lab Result
Companion Guide
The initial implementation of the UnitedHealthcare standard for lab results is not
configured to handle binary observation value data which would include the “ED -
encapsulated data” data type values such as images, Adobe Acrobat (PDF) files, or
other binary formats. When submitting large blocks of text based results such as
pathology results, the “TX - text data” data type should be used.
Note: the OBX-5 observation value is the location requested for lab result interpretive
text and not the NTE segment. The NTE segment should be used for ancillary notes
and comments related to the processing of the sample such as “Automated testing
could not be performed; results are based on manual analysis” or “Specific criteria for
analysis were not included therefore only partial testing
occurred” but NTE is not intended to be used for communicating the actual results or
interpretation of results.
OBX-6 Units [RE] - Background: When an observation’s value is measured on a

continuous scale, one must report the measurement units within the units field of the
OBX segment. Since HL7 Version 2.2 of the specification, all fields that contain units are
of data type CE. The default coding system for the Units codes consists of the
ISO abbreviation for a single case unit (ISO 2955-83) plus extensions that do not collide
with ISO abbreviations. We designate this coding system as ISO+ (see Figure
7-9). Both the ISO unit’s abbreviations and the extensions are defined in Section
7.4.2.6.2, “ISO and ANSI customary Units abbreviations.” The ISO+ abbreviations are
the codes for the default coding system. Consequently, when ISO+ units are
being used, only ISO+ abbreviations need be sent, and the contents of the Units field
will be backward compatible to HL7 Version 2.1.

Field: OBX-6 Units (CE)

Identifier (ST) RE
Text (ST) RE
Value Example
mg/dL^ Milligram/DeciliterÎSO+
OR
%^PercentÎSO+
Page 50 of 74
Lab Result
Companion Guide
OBX-7 References Range [RE]- When the observation quantifies the amount of a
toxic substance, then the upper limit of the range identifies the toxic limit. If the
observation quantifies a drug, the lower limits identify the lower therapeutic bounds
and the upper limits represent the upper therapeutic bounds above which toxic side
effects are common.
Components: for numeric values in the format:

a) lower limit-upper limit (when both lower and upper limits are defined, e.g., for
potassium 3.5 - 4.5)
b) > lower limit (if no upper limit, e.g., >10)
c) < upper limit (if no lower limit, e.g., <15)
alphabetical values: the normal value may be reported in this location
Value Example
>59
OR
1.5 - 4.5
OBX-8 Abnormal Flags [RE] - This field contains a table lookup indicating the
normalcy status of the result. We strongly recommend sending this value when
applicable. (See ASTM 1238 - review for more details).
Refer to User-defined Table 0078 - Abnormal flags for valid entries.
When the laboratory can discern the normal status of a textual report, such as chest X-
ray reports or microbiologic culture, these should be reported as N when normal and A
when abnormal. Multiple codes, e.g., abnormal and worse, would be separated by a
repeat delimiter, e.g., A~W."
User-defined Table 0078 - Abnormal flags

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
Page 51 of 74
Lab Result
Companion Guide
Value Description
S Susceptible. Indicates for microbiology susceptibilities only.
R Resistant. Indicates for microbiology susceptibilities only.
I Intermediate. Indicates for microbiology susceptibilities only.
MS Moderately susceptible. Indicates for microbiology susceptibilities only.
VS Very susceptible. Indicates for microbiology susceptibilities only
OBX-9 Probability - Optional Value
OBX-10 Nature of Abnormal Test - Optional Value
OBX-11 Observation Results Status [R] - This field contains the observation result
status. Refer to HL7 table 0085 - Observation result status codes interpretation for
valid values. This field reflects the current completion status of the results for one
Observation Identifier.
It is a required field. Previous versions of HL7 stated this implicitly by defining a

default value of “F.”
Code F indicates that the result has been verified to be correct and final and is the
requested status value in the UnitedHealthcare standard.
Code W indicates that the result has been verified to be wrong (incorrect); a
replacement (corrected) result may be transmitted later.
Code C indicates that data contained in the OBX-5-observation value field are to
replace previously transmitted (verified and) final result data with the same
observation ID (including suffix, if applicable) and observation sub-ID usually
because the previous results were wrong.
Code D indicates that data previously transmitted in a result segment with the same
observation ID (including suffix) and observation sub-ID should be deleted.
When changing or deleting a result, multiple OBX segments with the same observation
ID and observation sub-ID are replaced or deleted as a unit. Normal progression of
results through intermediate (e.g., ‘gram positive cocci’) to final (e.g.,
‘staphylococcus aureus’) should not be transmitted as C (correction); they should be
transmitted as P or S (depending upon the specific case) until they are final.
HL7 Table 0085 - Observation result status codes interpretation

Value Description
C Record coming over is a correction and thus replaces a final result
D Deletes the OBX record
F Final results; Can only be changed with a corrected result.
P Preliminary results
R Results entered -- not verified
S Partial results
Page 52 of 74
Lab Result
Companion Guide
Value Description
W Post original as wrong, e.g., transmitted for wrong patient
OBX-12 Effective Date of Reference Range - Optional Value
OBX-13 User Defined Access Checks - Optional Value
OBX-14 Date/Time of the Observation [RE] - This field is required in two

circumstances. The first is when the observations reported beneath one report header
(OBR) have different dates/times. This could occur in the case of queries, timed test
sequences, or clearance studies where one measurement within a battery may have a
different time than another measurement.
It is also needed in the case of OBX segments that are being sent by the placer to
the filler, in which case the date of the observation being transmitted is likely to have no
relation to the date of the requested observation. In France, requesting services routinely
send a set of the last observations along with the request for a new set of observations.
The date of these observations is important to the filler laboratories.
In all cases, the observation date-time is the physiologically relevant date-time or the
closest approximation to that date-time. In the case of tests performed on specimens,
the relevant date-time is the specimen’s collection date-time. In the case of observations
taken directly on the patient (e.g., X-ray images, history and physical), the observation
date-time is the date-time that the observation was performed."

Field: OBX-14 Date/Time of the Observation (TS)

Value Example
200911241217 [12:17 pm on November 24, 2009]
OBX-15 Producer’s ID [RE] - This field contains a unique identifier of the

responsible producing service. It should be reported explicitly when the test
results are produced at outside laboratories, for example. When this field is
null, the receiving system assumes that the observations were produced by
the sending organization.
The expected Coding System when this value is populated is “L” for Local general
code.
Page 53 of 74
Lab Result
Companion Guide

Field: OBX-15 Producer’s ID (CE)

Identifier (ST) RE
Text (ST) RE
OBX-16 Responsible Observer - Optional Value
OBX-17 Observation Method - Optional Value
OBX-18 Equipment Instance Identifier- Optional Value
OBX-19 Date/Time of the Analysis - Optional Value
Page 54 of 74
Lab Result
Companion Guide
NTE – Notes and Comments Segment

The NTE segment is commonly used for sending notes and comments that
accompany lab result data. Note that, depending on its position in the ORU
message in the HL7 standard, this segment may be associated with a PID, OBR,
and OBX segment. The intended use within the UnitedHealthcare standard is to use
the NTE segment when notes and comments are related to a specific lab result OBX
segment value.
1 Set ID - NTE 4 SI R
2 Source of Comment 8 ID RE
3 Comment 65536 FT RE Y
4 Comment Type 250 CE O
NTE-1 Set ID – NTE [R]- This field is used to identify the ordering of the NTE
segment. The value should begin at 1 and should be incremented sequentially for
each subsequent NTE segment when the text information to be sent exceeds the
maximum length in a single NTE segment. The sequence number should begin at
1 again for NTE segments within the next OBX segment.
Example:
OBX
NTE|1|L|Comment Text of 65536 characters
NTE|2|L|Comment Text segment 2
OBX
NTE|1|L|Comment Text
NTE-2 Source of Comment [RE]– This field is used to identify the source of the
comment. Refer to HL7 Table 0105 - Source of comment for valid values.
HL7 Table 0105 - Source of comment

Value Description
L Ancillary (filler) department is source of comment
P Orderer (placer) is source of comment
O Other system is source of comment
Expected Value
'L' – Ancillary department (Laboratory) is the source of the
comment
NTE-3 Comment [RE] – This field contains the comment contained in the segment.
For text values that exceed the HL7 standard 65,536 characters, separate the text
and send additional NTE segments.
NTE-4 Comment Type– Optional Value
Page 55 of 74
Lab Result
Companion Guide
FT1 – Financial Transaction Segment

The FT1 segment typically contains the detail data necessary to post charges,
payments, adjustments, etc. to patient accounting records.

1 Set ID - FT1 4 SI R
2 Transaction ID 12 ST O
3 Transaction Batch ID 10 ST O
4 Transaction Date 53 DR R
5 Transaction Posting Date 26 TS O
6 Transaction Type 8 IS R 0017
7 Transaction Code 250 CE R
8 Transaction Description 40 ST O
9 Transaction Description - Alt 40 ST O
10 Transaction Quantity 6 NM O
11 Transaction Amount - Extended 12 CP O
12 Transaction Amount - Unit 12 CP O
13 Department Code 250 CE O
14 Insurance Plan ID 250 CE R
15 Insurance Amount 12 CP E
O
16 Assigned Patient Location 80 PL O
17 Fee Schedule 1 IS O
18 Patient Type 2 IS O
19 Diagnosis Code - FT1 250 CE R Y
E
20 Performed By Code 250 XCN O Y
21 Ordered By Code 250 XCN O Y
22 Unit Cost 12 CP O
23 Filler Order Number 427 EI O
24 Entered By Code 250 XCN O Y
25 Procedure Code 250 CE R
E
26 Procedure Code Modifier 250 CE R Y
27 Advanced Beneficiary Notice Code 250 CE E
O 0339
28 Medically Necessary Duplicate Procedure 250 CWE O
Reason
29 NDC Code 250 CNE O
30 Payment Reference ID 250 CX O
Page 56 of 74
Lab Result
Companion Guide

31 Transaction Reference Key 4 SI O Y
FT1-1 Set ID – FT1 [R] - This field contains the number that identifies the order
sequence of this segment within the parent PID segment. This value should begin at
1 and increment by 1 for each subsequent FT1 segment within the PID segment..
The UnitedHealthcare standard requires that the Set ID numeric value is directly
associated with the same numerical OBR segment Set ID value. A valid HL7
ORU_R01 message order requires that the FT1 is sent after the matching OBR
segment within a parent PID.
Example:
PID
OBR|1|
OBX|1|
OBR|2|
OBX|1|
FT1-2 Transaction ID - Optional Value
FT1-3 Transaction Batch ID - Optional Value
FT1-4 Transaction Date [R] - This field contains the date/time or date/time range of the
transaction. For example, this field would be used to identify the date a procedure, item,
or test was conducted or used. To specify a single point in time, only the first component is
valued. When the second component is valued, the field specifies a time interval during
which the transaction took place. The UnitedHealthcare standard defines this value as the
First Service Date corresponding to the lab result submitted claim first service date value.
HL7 format for DR data type:
<Range Start Date/Time (TS)> ^ <Range End Date/Time (TS)>
Field: FT1-4 Transaction Date (DR)

Range Start Date/Time (TS) R
Range End Date/Time (TS) O
Value Example
minimum precision YYYYMMDD:
20091124 [November 24, 2009]
FT1-5 Transaction Posting Date – Optional value.
FT1-6 Transaction Type [R] - This field contains the code that identifies the type of
transaction. This is a required field in the FT1 segment per the HL7 standard. For the
UnitedHealthcare standard, the value should be set to “CG” - Charge.
Page 57 of 74
Lab Result
Companion Guide
Required Value
CG
FT1-7 Transaction Code [R] - This field contains the code assigned by the institution
for the purpose of uniquely identifying the transaction based on the Transaction Type
(FT1-6). For example, this field would be used to uniquely identify a procedure, supply
item, or test for charges; or to identify the payment medium for payments.
There are multiple locations to identify the transaction code within the HL7 ORU standard.
The UnitedHealthcare standard has defined this value to be the procedure code (CPT-4)
that matches the claim submission for this lab result. The coding system should be “C4”
CPT-4 (see HL7 table 0396 Coding system). In many cases, submitters will have the
same value within this field (FT1-7) and FT1-25 and OBR-4. The implementation allows
the flexibility for labs to use other identifiers and methods for submitting results. For lab
proprietary coding system as an alternative identifier, use “L” (Local general code)

Field: FT1-7 Transaction Code (CE)

Identifier (ST) R
Text (ST) RE
Name of Coding System (IS) RE
Name of Alternate Coding System (IS) O
Example 1: submission of lab results uses a consistent value for procedure code:
FT1|1|-7 value = 80061 (Lipid Panel)
OBR|1|-4 value = 80061 (Lipid Panel)
OBX|1| for LOINC 2093-3 (Total Serum Cholesterol)
OBX|2| for LOINC 2085-9 (HDL Cholesterol)
OBX|3| for LOINC 2571-8 (Triglycerides)
OBX|4| for LOINC 13457-7 (Cholesterol in LDL, Calc)
Page 58 of 74
Lab Result
Companion Guide
Example 2: submission of lab results breaks out procedure code into individual tests:
FT1|1|-25 value = 82465 (Total Serum Cholesterol)
OBR|1|-4 value = 82465 (Total Serum Cholesterol)
OBX|1| for LOINC 2093-3 (Total Serum Cholesterol)
OBX|2| for LOINC 13457-7 (Cholesterol in LDL, Calc)

FT1|2|-25 value = 83718 (HDL Cholesterol)
OBR|2|-4 value = 83718 (HDL Cholesterol)
OBX|1| for LOINC 2085-9 (HDL Cholesterol)

FT1|3|-25 value = 84478 (Triglycerides)
OBR|3|-4 value = 84478 (Triglycerides)
OBX|1| for LOINC 2571-8 (Triglycerides)
Value Example
OR
FT1-8 Transaction Description - Optional Value
FT1-9 Transaction Description – Alt - Optional Value
FT1-10 Transaction Quantity - Optional Value
FT1-11 Transaction Amount – Extended - Optional Value
FT1-12 Transaction Amount – Unit - Optional Value
FT1-13 Department Code - Optional Value
FT1-14 Insurance Plan ID [RE] - This field contains the identifier of the primary
insurance plan with which this transaction should be associated.
The UnitedHealthcare lab result standard defines this value to be the group number as
shown on the medical card. This is not the Member ID which is populated in PID-3.
The coding system for this value should be set to “HC” – Health Card Number (see HL7
table 0203 Identifier Type).

Page 59 of 74
Lab Result
Companion Guide
Field: FT1-14 Insurance Plan ID (CE)

Identifier (ST) RE
Text (ST) RE
Value Example
987654ÛnitedHealthcare^HC
FT1-15 Insurance Amount - Optional Value
FT1-16 Assigned Patient Location - Optional Value
FT1-17 Fee Schedule - Optional Value
FT1-18 Patient Type - Optional Value
FT1-19/I10 Diagnosis Code [RE] -This field should be reported if the diagnosis
information has been received by the laboratory. The coding system for this value
should be set to “I9C” – ICD9 CM or “I10” – ICD-10 (see HL7 table 0396 Coding
system). Multiple diagnosis values can be sent when properly delimited in this
repeating field.

Field: FT1-19 Diagnosis Code (CE)

Identifier (ST) RE
Text (ST) RE
Value Example
250^DIABETES MELLITUSÎ9C~272.2^MIXED HYPERLIPIDEMIAÎ9C
FT1-20 Performed By Code - Optional Value
FT1-21 Ordered By Code - Optional Value FT1-
Page 60 of 74
Lab Result
Companion Guide
22 Unit Cost - Optional Value
FT1-23 Filler Order Number - Optional Value
FT1-24 Entered By Code - Optional Value
FT1-25 Procedure Code [RE] - This field contains a unique identifier assigned to the
procedure, if any, associated with the charge. This field is a CE data type for
compatibility with clinical and ancillary systems.
This value should be populated with the identifier for the procedure code (CPT-4)
associated with the lab result observation request in the OBR segment related to this FT1
segment. The coding system should be “C4” CPT-4 (see HL7 table 0396 Coding system).
Typically this value will be the same as FT1-7. See the discussion above for FT1-7 for
clarification. For lab proprietary coding system as an alternative identifier, use “L” (Local
general code)

Field: FT1-25 Procedure Code (CE)

identifier (ST) RE
text (ST) RE
name of coding system (IS) RE
alternate identifier (ST) O
alternate text (ST) O
name of alternate coding system (IS) O
Value Example
OR
FT1-26 Procedure Code Modifier [RE] - This field contains the procedure code
modifier to the procedure code reported in FT1-25 - Procedure Code, when applicable.
Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA.
Multiple modifiers may be reported. The modifiers are sequenced in priority according to
user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers
are allowed and the order placed on the form affects reimbursement.
Usage Rule: This field can only be used if FT1-25 - Procedure Code contains certain
procedure codes that require a modifier in order to be billed or performed. For example
HCPCS codes that requires a modifier to be precise.
Page 61 of 74
Lab Result
Companion Guide

Field: FT1-26 Procedure Code Modifier (CE)

identifier (ST) RE
text (ST) RE
name of coding system (IS) RE
alternate identifier (ST) O
alternate text (ST) O
name of alternate coding system (IS) O
FT1-27 Advanced Beneficiary Notice Code - Optional Value
FT1-28 Medically Necessary Duplicate Procedure Reason - Optional Value
FT1-29 NDC Code - Optional Value
FT1-30 Payment Reference ID - Optional Value
FT1-31 Transaction Reference Key - Optional Value
Page 62 of 74
Lab Result
Companion Guide
BTS – Batch Trailer Segment

The BTS segment indicates the end of a batch.

1 Batch Message Count 10 ST R
2 Batch Comment 80 ST O
3 Batch Totals 100 NM O
BTS-1 Batch Message Count [R] - This field contains the count of the individual
messages contained within the batch. This value will be a numeric count of MSH
segments contained within the BHS/BTS batch.
BTS-2 Batch Comment - Optional Value
BTS-3 Batch Totals - Optional Value
FTS – File Trailer Segment

The FTS segment defines the end of a file and must be the last line of the physical
batch file.

1 File Batch Count 10 NM R
2 File Trailer Comment 80 ST O
FTS-1 File Batch Count [R] - This field contains the number of batches contained in
this file. This value will be a numeric count of BHS/BTS batches contained within the
file.
FTS-2 File Trailer Comment - Optional Value
Page 63 of 74
Lab Result
Companion Guide
Appendices
Transaction Layout Examples
Example Layouts of Submitted
HL7 transactions:
FHS File Header Segment
BHS Batch Header Segment
MSH Message Header Segment
PID Patient Identifier
Observation Set for Specimen
Universal Service Identifier 80061
OBR (Lipid Panel)
Test Result
OBX 2093-3 (Total Serum Cholesterol)
NTE Notes related to OBX result
Test Result
OBX 2085-9 (HDL Cholesterol)
Test Result
OBX 2571-8 (Triglycerides)
Test Result
OBX 13457-7 (Cholesterol in LDL, Calc)
Transaction Code 80061 (Lipid Panel),
FT1 Procedure Code 80061 (Lipid Panel)
BTS Batch Trailer Segment
FTS File Trailer Segment
Example 2: Lab submits detailed

test procedure codes
FHS File Header Segment
BHS Batch Header Segment
MSH Message Header Segment
PID Patient Identifier
OBR (Total Serum Cholesterol)
Test Result
OBX 2093-3 (Total Serum Cholesterol)
Page 64 of 74
Lab Result
Companion Guide
Example 2: Lab submits detailed

test procedure codes
Procedure Code 82465 (Total Serum
FT1 Cholesterol)
OBR (HDL Cholesterol)
Test Result
OBX 2085-9 (HDL Cholesterol)
FT1 Procedure Code 83718 (HDL
Cholesterol)
OBR (Triglycerides)
Test Result
OBX 2571-8 (Triglycerides)
Test Result
OBX 13457-7 (Cholesterol in LDL, Calc)
FT1 Procedure Code 84478 (Triglycerides)
BTS Batch Trailer Segment
FTS File Trailer Segment
Page 65 of 74
Lab Result
Companion Guide
Acknowledgement Messages
The layout of the message response is listed below. Braces, { . . . }, indicate one or
more repetitions of the enclosed group of segments. Brackets, [ . . . ], show that the
enclosed group of segments is optional. The following table describes the required
segments and cardinality of segments and groups of segments in the UnitedHealthcare
lab result HL7 response message.
Segment Identifier Usage Cardinality Segment Name

FHS R [1..1] File Header Segment
{ R [1..*] File Batch Group
BHS R [1..1] Batch Header Segment
{ R [1..*] Message Group
MSH R [1..*] Message Header
MSA R [1..1] Message Acknowledgment
[ERR] O [0..1] Error Segment
}
BTS R [1..1] Batch Trailer Segment
}
FTS R [1..1] File Trailer Segment
The response message will conform directly with the information submitted in the
original file transmission. A single FHS (File Header Segment) will be followed by one
to many BHS (Batch Header Segment) groups. Within each BHS group, one to many
MSH (Message Header Segments) will include a single MSA (Message
Acknowledgment Segment). If the acknowledgment indicates an error was found
within the MSH, a single ERR (Error Segment) will be included following the MSA. If
no errors were found in the MSH, no ERR segment will be included. The BHS will be
terminated by a corresponding single BTS (Batch Trailer Segment) and the file will be
terminated by a single FTS (File Trailer Segment).
A standard ACK acknowledgement message will consist of one of the following

scenarios:
1. A successful processing of a message without errors will result in a ACK
message with a value of AA in the MSA-1 Acknowledgement Code
2. An error found within the MSH-9 Message Type, MSH-12 Version ID, or MSH-
11 Processing ID will result in an ACK message with a value of AR in the MSA-
1 Acknowledgement Code and the message will be excluded from processing
3. An error found within the functional segment fields will result in an ACK
message with a value of AE in the MSA-1 Acknowledgement Code and the
message will be excluded from processing
Page 66 of 74
Lab Result
Companion Guide
MSA – Message Acknowledgment Segment

The MSA segment contains information sent while acknowledging another message.

1 Acknowledgment Code 2 ID R 0008
2 Message Control ID 20 ST R
3 Text Message 80 ST O
4 Expected Sequence Number 15 NM O
5 Delayed Acknowledgment Type
6 Error Condition 250 CE O 0357
MSA-1 Acknowledgment Code [R] - Definition: This field contains an

acknowledgment code, see message processing rules. Refer to HL7 Table
0008 - Acknowledgment code for valid values. Values included in the
UnitedHealthcare standard are “AA” and “AE”.
HL7 Table 0008 – Acknowledgment code

AA Original mode: Application Accept - Enhanced mode:
Application acknowledgment: Accept
AE Original mode: Application Error - Enhanced mode: Application
acknowledgment: Error
AR Original mode: Application Reject - Enhanced mode: Application Not Used
acknowledgment: Reject
CA Enhanced mode: Accept acknowledgment: Commit Accept Not Used
CE Enhanced mode: Accept acknowledgment: Commit Error Not Used
CR Enhanced mode: Accept acknowledgment: Commit Reject Not Used
MSA-2 Message Control ID [R] - Definition: This field contains the message
control ID of the message sent by the sending system. It allows the sending system
to associate this response with the message for which it is intended. This value will
contain the MSH-10 Message Control ID value related to this acknowledgement.
MSA-3 Text Message - Optional Value

The MSA-3 was deprecated as of v 2.4. The reader is referred to the ERR segment.
The ERR segment allows for richer descriptions of the erroneous conditions.
This field will NOT be included in the UnitedHealthcare MSA segment.
MSA-4 Expected Sequence Number - Optional Value.

MSA-5 Delayed Acknowledgment Type- Attention: The MSA-5 was deprecated as

of v2.2 and the detail was withdrawn and removed from the standard as of v 2.5.
Page 67 of 74
Lab Result
Companion Guide
MSA-6 Error Condition - Optional Value.

ERR – Error Segment

The ERR segment is used to add error comments to acknowledgment messages.

1 Error Code and Location 493 ELD O Y
2 Error Location 18 ERL R Y
3 HL7 Error Code 705 CWE R 0357
4 Severity 2 ID R 0516
5 Application Error Code 705 CWE O 0533
6 Application Error Parameter 80 ST O Y/10
7 Diagnostic Information 2048 TX O
8 User Message 250 TX O
9 Inform Person Indicator 20 IS O Y 0517
10 Override Type 705 CWE O 0518
11 Override Reason Code 705 CWE O Y 0519
12 Help Desk Contact Point 652 XTN O Y
ERR-1 Error Code and Location - Optional Value

This field will be located positionally but will NOT be populated with a value
in the UnitedHealthcare ERR segment.
Page 68 of 74
Lab Result
Companion Guide
ERR-2 Error Location [R] - Definition: Identifies the location in a message related to
the identified error, warning or message. If multiple repetitions are present, the error
results from the values in a combination of places. For errors relating to entire
segments (ERR-3 value of 100), only the Segment ID and Segment Sequence will be
populated.
HL7 format for ERL data type:

<Segment ID (ST)> ^ <Segment Sequence (NM)> ^ <Field Position (NM)>
^<Field Repetition (NM)> ^ <Component Number (NM)> ^ <Sub-Component
Number (NM)>
Field: ERR-2 Error Location (ERL)
Segment ID (ST) R
Segment Sequence (NM) R
Field Position (NM) O
Field Repetition (NM) O
Component Number (NM) O
Sub-Component Number (NM) O
ERR-3 HL7 Error Code [R] - Definition: Identifies the HL7 (communications) error
code. Refer to HL7 Table 0357 – Message Error Condition Codes for valid values.
HL7 format for CWE data type:

Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System
(ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID
(ST)> ^ <Original Text (ST)>
Field: ERR-2 Error Location (ERL)

Identifier (ST) R
Text (ST) R
Name of Coding System (ID) R
Coding System Version ID (ST) O
Alternate Coding System Version ID (ST) O
Original Text (ST) O
Page 69 of 74
Lab Result
Companion Guide
HL7 Table 0357 – Message Error Condition Codes

0 Message Success. Optional, as the AA conveys success. Used for
accepted systems that must always return a status code.
100 Segment Error: The message segments were not in the proper
sequence error order, or required segments are missing.
101 Required field Error: A required field is missing from a segment
missing
102 Data type error Error: The field contained data of the wrong data
type, e.g. an NM field contained "FOO".
103 Table value not Error: A field of data type ID or IS was compared
found against the corresponding table, and no match was
200 Unsupported found.
Rejection: The Message Type is not supported.
message type
201 Unsupported Rejection: The Event Code is not supported.
event code
202 Unsupported Rejection: The Processing ID is not supported.
processing id
203 Unsupported Rejection: The Version ID is not supported.
version id
204 Unknown key Rejection: The ID of the patient, order, etc., was not
identifier found. Used for transactions other than additions,
205 Duplicate key e.g.
Rejection: The ID of the patient, order, etc., already
identifier transfer of a in
exists. Used non-existent
response topatient.
addition transactions
206 Application (Admit,
Rejection: The transaction could not be performed at
record locked Newapplication
the Order, etc.).
storage level, e.g., database locked.
207 Application Rejection: A catchall for internal errors not explicitly
internal error covered by other codes.
ERR-4 Severity [R] - Definition: Identifies the severity of an application error.

Knowing if something is Error, Warning or Information is intrinsic to how an
application handles the content. Refer to HL7 Table 0516 - Error severity for valid
values. If ERR-3 has a value of "0", ERR-4 will have a value of "I". The
UnitedHealthcare standard will only send an ERR segment when an error is to be
reported, so this value will always be populated with “E”.
HL7 Table 0516 – Error Severity

W Warning Transaction successful, but there may be issues
I Information Transaction was successful but includes information e.g.,
inform patient
E Error Transaction was unsuccessful
ERR-5 Application Error Code - Optional Value.

This field will NOT be included in the UnitedHealthcare ERR segment.
Page 70 of 74
Lab Result
Companion Guide
ERR-6 Application Error Parameter - Optional Value.

ERR-7 Diagnostic Information - Optional Value.

ERR-8 User Message - Optional Value.

ERR-9 Inform Person Indicator - Optional Value.

ERR-10 Override Type - Optional Value.

ERR-11 Override Reason Code - Optional Value.

ERR-12 Help Desk Contact Point - Optional Value.

Page 71 of 74
Lab Result
Companion Guide
Frequently Asked Questions
1. Why has UnitedHealthcare opted to implement a HL7 based lab result

ORU R01 message format rather than a custom data feed with a smaller
focused subset of data elements?
UnitedHealthcare has adopted a HL7 based ORU R01 format for intake of lab results after
considering several options including custom proprietary formats. The health care
industry is migrating into more standards based communication of data and HL7 provides
a benchmark standard for communicating lab result information that is currently used by
many government and business organizations today.
2. How does a submitter obtain feedback about the success or failure of an

individual file submission?
Each file submission will result in a standard HL7 based response file. Each MSH
(Message Header) segment will be acknowledged individually by a corresponding MSA
(Message Acknowledgement) segment containing an acceptance indicator or a
rejection indicator with detailed error information.
3. How can submitters reconcile the MSA acknowledgment generated by this

transaction to the original message?
Submitters can use the MSA-2 Message Control ID to reconcile the response back to the
originally submitted value sent in MSH-10 Message Control ID.
4. Are the responses sent back in the same format that they were submitted to
UnitedHealthcare?
Yes, all responses will be sent back in a standard HL7 MSA segment acknowledgment
format. Refer to the companion guide for more information.
5. Are the data elements necessary for a successful transaction outlined in the
Companion Guide?
Yes. Required data values that must always be submitted are identified within the
implementation guide as “Required”. Other requested data elements are identified
as “Required but may be empty” with the expectation that when the conforming
sending application knows the required value for the element, then the value must
be sent.
6. What if my lab’s data exchange format version is different or older than the
HL7 2.5 version in the UntedHealthcare standard?
While the UnitedHealthcare standard is based on the HL7 2.5 version of the
ORU_R01 message, we have attempted to select segments and elements to try to align
to prior versions of HL7 back to version 2.2. Your file will be accepted and processed as
long as the data elements you send meet the requirements for element population as
described in the Companion Guide.
7. Our internal testing process is not supported by the process outlined in the
Companion Guide by UnitedHealthcare. What do we do?
Your Facility Connectivity Team Account Executive (FCT AE) will be in touch with you
regarding connectivity and set up. Other internal UnitedHealthcare teams will walk
Page 72 of 74
Lab Result
Companion Guide
you through the testing and validation process once you are connected to
UnitedHealthcare directly. If you have a specific testing question, please contact your
FCT AE.
8. Does our connection to UnitedHealthcare have to be set-up prior to us

being able to validate our format per the published lab result standard? Yes.
9. Does the Submitter ID have to be assigned by UnitedHealthcare? Yes.

This ID will be identified for your use from UnitedHealthcare during the
connectivity set up process.
10. Can submitters expect to receive one response for a single file or batch
and one MSA response for each message of that batch?
Yes. A typical response will be a corresponding single file containing one MSA
(message acknowledgment) response transaction for each MSH submitted in the
batch.
11. Do empty fields need spaces in them as placeholders or can they remain
empty? If they cannot remain empty, do we need to identify an empty field with
a specific character?
If the field is required within a segment being used, it cannot be empty. It should
contain an acceptable value based on the Companion Guide.
If the field is not required within a segment being used, that field should be preceded and
terminated with delimiters (i.e. ||). No special character or space is required
within the delimiters to denote an empty field.
If the empty field is located at the end of a segment with no other required or submitted
fields after it, the field can be omitted from the segment. In other words,
positional delimiters for optional fields are not needed at the end of a segment.
12. What is PGP encryption?

PGP stands for Pretty Good Privacy. It is a computer program that provides
cryptographic privacy and authentication. PGP is often used for signing, encrypting and
decrypting e-mails to increase the security of e-mail communications.
UnitedHealthcare accepts PGP encrypted lab result files via FTP.
13. If we are transmitting via FTP, how do we receive the acknowledgment? All
transaction responses are sent to the ECG mailbox associated with the FTP account.
14. Does a submitter have to purchase any additional software from

UnitedHealthcare or Ingenix if they are connecting directly to
UnitedHealthcare to submit the lab result data?
No.
15. Is PGP Encryption required when using Connectivity Director?

No. There are two options that do not require PGP encryption, which are FTP over
SSL batch (FTPS) and file submission via a browser interface (secured by using
HTTPS). Please refer to the Connectivity Director User Guide section 4.3 for
additional information.
Page 73 of 74
Lab Result
Companion Guide
16. Does Connectivity Director support SFTP?

Not at this time. There are currently 3 connection options, HTTPS (Batch and Real-
Time), FTP + PGP Batch and FTP over SSL Batch.
17. How does the submitter know and understand the reasons for rejection? The
ERR-2 Error Location and ERR-3 HL7 Error Location described in the appendix of the
Companion Guide provide details for the reasons for rejections.
18. How can our staff access responses from within Connectivity Director? The
submitter and owner of the Connectivity Director account can view responses in the
report section of the Connectivity Director web site.
19. How does our staff access responses when we are connecting via FTP
(outside of Connectivity Director)?
Responses will be delivered to an ECG outbox accessible via FTP or SFTP. The outbox will
use the same communication as the inbox where notifications are submitted to
UnitedHealthcare. Once a file is picked up from the outbox it no longer exists in the
outbox.
20. What is the process for correcting rejected transactions?

Rejected lab result MSH messages that could not be processed due to errors can be
resubmitted once a submitter has incorporated corrections or updates. A new file
containing the corrected MSH message can be submitted with the same file segment
and batch segment requirements as any other batch file submission.
21. Can test files be sent after a submitter has received approval for lab
result transaction production submissions?
Even after you have been granted production status for lab result file submissions, you
have the ability to designate a file as a test file by sending a “T” in the MSH-11
Processing ID element. When you do this, the file will be treated as a test
transaction file and will not be forwarded for processing. You can still send lab result test
transaction messages when you have been granted production status for lab result
transactions. Note: if you have not yet been approved for production status, all
messages will be processed as test messages regardless of the value in the MSH-
11 Processing ID element.
Page 74 of 74

CompanionGuide Lab Result

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CompanionGuide Lab Result

Uploaded by

Copyright:

Available Formats

Lab Result

Lab Result Companion Guide

Refers to the Implementation Guide

Companion Guide Version Number: 6.2

6.2 September, 2016 Updated to include:

FT1 – Financial Transaction Segment ........................................................... 56

Transmission Administrative Procedures

You can transmit electronic data using the following methods:

Submitting a Test File

The general process is as follows:

Contact UnitedHealthcare EDI Support at SupportEDI@uhc.com

Most questions can be answered by referencing the materials posted at

Provider Specific Business Rules and Limitations

Transaction Specific Information

Encoding Rules for Sending

Encoding Rules for Receiving

HL7 Message Structure

retain their position with a component separator (^) if more

o If the field definition repeats (if allowed):

Batch File Structure

Each MSH requires a single PID (Patient Identification)*

Segment Identifier Usage Cardinality Segment Name

Segment Table Key

Table Item Definition

Data Type Data Type Name

O Optional The component/sub-component may These elements may

Lab Result HL7 Batch File Segments

FHS – File Header Segment

SEQ ELEMENT NAME LEN DT OPT RP/# TBL#

Value is |, (ASCII 124).

FHS-3 File Sending Application - Optional Value

HL7 format for HD data type:

Field: FHS-4 File Sending Facility (HD)

FHS-5 File Receiving Application - Optional Value

FHS-6 File Receiving Facility - Optional Value

HL7 format for TS data type:

Field: FHS-7 File Creation Date/Time (TS)

FHS-8 File Security- Optional Value

FHS-10 File Header Comment - Optional Value

FHS-12 Reference File Control ID- Optional Value

BHS – Batch Header Segment

SEQ ELEMENT NAME LEN DT OPT RP/# TBL#

Value is |, (ASCII 124).

Escape character = "\"

BHS-3 Batch Sending Application - Optional Value

HL7 format for HD data type:

Field: BHS-4 Batch Sending Facility (HD)

BHS-5 Batch Receiving Application - Optional Value

BHS-6 Batch Receiving Facility - Optional Value

HL7 format for TS data type:

Field: BHS-7 Batch Creation Date/Time (TS)

BHS-8 Batch Security - Optional Value

BHS-9 Batch Name/ID/Type - Optional Value

BHS-10 Batch Comment - Optional Value

BHS-12 Reference Batch Control ID - Optional Value

MSH – Message Header Segment

SEQ ELEMENT NAME LEN DT OPT RP/# TBL#

SEQ ELEMENT NAME LEN DT OPT RP/# TBL#

Value is |, (ASCII 124).

HL7 format for HD data type:

Field: MSH-3 Sending Application (HD)

HL7 format for HD data type:

<Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

Field: MSH-4 Sending Facility (HD)