Laboratory Results Reporting HL7 2.

1
Message Standard Definition
Implementation Guide

www.healthlink.net
 Document Information
Version 1.3
Prepared August 5, 2002
Author Dave Brewerton
Reviewer Clifford Wilson
Editor Simon Chadwick
Laboratory Results Reporting HL7 2.1 Message Standard Definition and
Document
Implementation Guide

Date Author Version Comment

25/8/2021 Kyle Macdonald 1.3 p.16 Changed MSH-9 Message Control ID to MSH-10

All rights reserved. No reproduction, transmission, transcription, storage in a retrieval system,

or translation into any language or by any means, electronic, mechanical, optical, chemical,
manual, or otherwise, any part of this document without express written permission of
HealthLink Limited.

Liability Notice: Every effort has been made to ensure that the information in this document,
supplied by HealthLink Limited, is accurate and complete. However, as use and interpretation
of this document is beyond the control of HealthLink Limited, no liability, either direct or
consequential, can be entertained by HealthLink Limited, its agents, or its suppliers.

www.healthlink.net
Contents

Document Information ................................................................................................................................... 2

Contents ...................................................................................................................................................... 3
Introduction ................................................................................................................................................ 4
Document References ................................................................................................................................. 4
Document History ...................................................................................................................................... 4
Transaction Flow ............................................................................................................................................ 5
HL7 Separators ............................................................................................................................................... 6
Message Definition ......................................................................................................................................... 7
Conventions ................................................................................................................................................ 7
ORU Laboratory Results Message ............................................................................................................. 7
ACK– Response Message .......................................................................................................................... 8
Segment Definition......................................................................................................................................... 9
Conventions ................................................................................................................................................ 9
Data Types .................................................................................................................................................10
HL7 Composite Data Types ......................................................................................................................10
MSH - Message Header Segment ..............................................................................................................13
MSA - Message Acknowledgement Segment ...........................................................................................16
ERR - Error Segment.................................................................................................................................18
NTE - Note Segment .................................................................................................................................19
PID - Patient ID Segment ..........................................................................................................................21
PV1 - Patient Visit Segment ......................................................................................................................24
OBR - Observation Request Segment .......................................................................................................27
OBX - Observation Result Segment ..........................................................................................................31
Examples .......................................................................................................................................................35

Page 3 of 35
Introduction
This document contains the information required by a software developer or consultant to generate
correctly formatted messages to send Laboratory result information to another party. The messages
described by this document are already in use by the Healthlink Messaging service to transfer test
result information from Laboratories to General Practitioner Systems.
This Implementation Guide is based on the HL7 protocol for Data Exchange. While this document is
complete in its own right it may be necessary to refer to the HL7 standards to answer such questions as
why particular features have been selected. This document assumes that the reader is familiar with HL7
terminology such as 'segment', 'field' and 'message'.
This document does not address issues concerned with message delivery or encryption.

Document References

[1] Health Level Seven Inc., HL7 Standard Version 2.1 - An Application
Protocol For Electronic Data Exchange in Healthcare Environments.
[2] HealthLink, Laboratory Results – Laboratory Operating Procedures
and Technical Manual, 1996.

Document History
This document is to be read with the Specification document, LABRES/HLK/100 prepared by Orion
Systems Ltd in 1993.

Version Prepared By Date Comment

1.0 Dave Brewerton 8 July 2002 Document Preparation
1.1 Dave Brewerton 18 July 2002 Incorporation of Review Suggestions
1.2 Simon Chadwick September Errata :
2005 1. Page 7 - ORU Laboratory Results Message -
table and notes amended to emphasise MSA
segment is mandatory
2. Page 10 - Datatype table - NM and ST data
type descriptions filled in
3. Page 16 - MSA segment description amended
to emphasise MSA segment is mandatory
4. Page 21 - PID Table – amend PID-3, PID-5
and PID-11 to non-repeatable
5. Page 21 - PID Table - amend datatype for
PID-11 to AD
6. Page 27 - OBR Table - amend OBR-16 to
optional and non-repeatable.
7. Page 27 - OBR Table - amend OBR-20 to
non-repeatable.
8. Page 29 - delete spelling mistake in OBR-13
9. Page 30 - amend examples in OBR-19 and
OBR-20 to provide example Doctors' names.
10. Page 32 – amend field length of OBX 3.1
‘Identifier Code’

Page 4 of 35
 Transaction Flow
Messages are sent in response to real world events and demands. The following events lead up to the
transmission and receipt of this message.
1.A Patient Presents at a Medical encounter, usually with a GP.
2.The GP issues a script for the patient to have certain tests. For example a glucose test in
urine to test for possible diabetes.
3.The Patient presents at a Laboratory where the required samples are taken and the test
performed.
4.A data entry professional enters the results of the test into the laboratory system including
the patient information and the referring medical practitioner.
5.Triggered by the data entry, the Laboratory system sends the ORU message described by
this document to the GP. In New Zealand this is most likely done using the Healthlink
network.
6.The GP's Practice Management System (PMS) receives the message and records the details
of the test with those of the patient.
Developers of both the laboratory system and the Practice management system need to be familiar with
the message format described by this implementation guide. There are other transaction sequences that
could mitigate the use of this message but this is by far the most common situation.
Fully explained example transactions may be found at the end of this document.

Page 5 of 35
 HL7 Separators
HL7 allows for considerable flexibility in the selection of separator characters to be used for the
generation and parsing of the messages.
The carriage return character <CR>, (ASCII 0D16), is reserved by HL7 for the segment terminator and
must not be altered by any implementation. It is a common problem for segments to be separated by
both a carriage return character and a line feed character. This is incorrect HL7 usage and should be
avoided. This implementation will not accept such messages. It should be noted here that HMS 6.0 and
above will accept messages delimiting segments in this way without returning Negative
acknowledgements.
HL7 practices ‘trimming’ of separators. That is, after the last field containing data in a segment, the
carriage return character will occur to indicate the segment is complete. Thus the last character of a
segment should never be a field separator.
Example 1: Correct usage of a hypothetical HL7 segment.

SEG|Field1|Field2|This is the last field<cr>

Example 2: Incorrect usage of the same hypothetical HL7 segment.

SEG|Field1|Field2|This is the last field|<cr>

For further details concerning message construction and separator characters refer to sections 2.11
(Message Construction Rules) and 2.8 (Message Delimiters) of the HL7 2.4 standard.
This implementation allows for the standard HL7 practice of allowing message defined delimiters
Healthlink strongly recommends that the standard HL7 characters for delimiting are used as it cannot
be guaranteed that all sites will be able to process messages with different separators.

Description Character ASCII Hex

Field separator ‘|’ 7C
Component separator ‘^’ 5E
Sub-component separator ‘&’ 26
Repetition separator ‘~’ 7E
Escape character ‘\’ 5C

These separators are used in the example messages throughout this document.

Page 6 of 35
 Message Definition

Conventions
In the message definition, any segment surrounded by parentheses ‘{ }’ is allowed to repeat. A
segment surrounded by square brackets ‘[ ]’ is an optional segment. A segment without the
surrounding square brackets should be thought of as required. Segments that are both optional and
repeating will be surrounded by both square brackets and parentheses.
Groups of segments that operate as complete units in the message (known as segment groups) will also
be surrounded by square brackets to indicate that the entire group is optional and parentheses to
indicate that the entire group may repeat. If a segment is required (i.e. It has no square brackets) inside
a group that is optional, then that segment is only required if the group is present. Wherever possible,
segment groups are indicated by indentation of the segments that belong to that segment group.
Segments that are allowed in the standard but which are not used by this implementation are not listed
in the message definition. However, the complete message structure will be displayed in the appendices
with the HL7 chapters listed. Segments and segment groups that are not used will be shaded.

ORU Laboratory Results Message

Segment Name Description

MSH Message Header
MSA Message Acknowledgement Segment
{
PID Patient Identification
[PV1] Patient Visit
{
OBR Order Detail – Observation Request
{
OBX Observation/Result
[{NTE}] Notes and Comments on Result information
}
}
}

Notes
The MSA segment was originally included in HL7 2.1 to allow for solicited Lab result messages. Even
though the ORU message is unsolicited, this segment is included for backwards compatibility reasons.
While the PV1 segment is officially optional, in practice it is almost always sent because many Practice
management systems require this message to be sent. Please see the specific notes on PV1 for more
information regarding the usage of this segment.

Example ORU^R01 Message

This message is listed here to show the correspondence of the message definition above with an actual
message. For ease of viewing the segments have been separated onto different lines. In an actual

Page 7 of 35
 message, the segments would be separated only with a carriage return character. Where a segment will
not fit on a single line, subsequent lines have been indented.
MSH|^~\&|DELPHIC|ediaccnt|LABRESULT|sectst03|200001200920||ORU|0155002273|P|
2.1
MSA|AA|0155002273
PID|1||CBC2654||DWARF^SLEEPY^E||19811019|F|||215 GRANGE
RD^OTUMOETAI^TAURANGA
PV1||O|""|||||""|""
OBR|1||00/147871401000|4010^HAEMATOLOGY.....^L|R||200001191752|""|""|||||200
001191752||2004^SWART^C|||7509^TESTING^HL7|7509^TESTING^HL7||200001200920
||||||||||""
OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F
OBX|2|ST|4030^DIFFERENTIAL^L|NEUS^Neut Seg|12.35|b/L|2.0-7.5|H|||F
OBX|3|ST|4090^PLATELET COUNT^L||145|b/L|150-400|L|||F
OBX|4|TX|4300^Blood Film^L||COMMENT at19 Jan 00||||||F
NTE|1|L|Moderate neutrophilic leucocytosis.
NTE|2|L|Mild thrombocytopenia.

This message contains the required MSH and MSA segments at the top followed by one instance of the
patient segment group. There is only one OBR for this patient but there are multiple results for this
single OBR. Where the Laboratory felt that more information was warranted such as the
thrombocytopenia, it is sent in an NTE segment following the OBX it relates to.

ACK– Response Message

Segment Name Description

MSH Message Header
MSA Message Acknowledgement
[ERR] Error

Page 8 of 35
Segment Definition

Conventions
In the tables that define the fields of the segments, Rows that are shaded mark entries that are not used
in this implementation. Where there are differences to the HL7 standard this will be noted in the field
notes with the text "Variance to HL7" followed by a short description of the nature of the variance.

Value Meaning Explanation

R Required
O Optional
C Conditional
X Not used
This must always contain data.
This field does not have to have data.
This field must contain data in certain
situations that will be described in the field
notes.
This field is not used in this implementation;
data sent in this field will be ignored by the
receiving definition.

The following values will be found in the column labelled Rpt.

Value Meaning Explanation

N No repetition This field does not repeat.
Y Allow repetition This field may repeat an infinite number of
times.

If the value in the repeats column is a number then the field will be allowed to repeat as long as the
number of occurrences of that field in the segment is less than or equal to that number. For Example if
the following repeating field was allowed 3 repeats then the first of the two following examples is legal
but the second is not.

...|1~2~3|...
...|1~2~3~4|...
If the repeat column is blank, then a value of N should be assumed.

Please Note:

Values in the Length column always refer to the total length of the field. So if a field contains a
composite data type such as PN (Patient Name) then the length will refer to the entire field including
any separators. For example:

...|Fyodor^I^Dostoevsky|...
(19 characters including the separators) This would be fine if the length of the Patient Name field was
19 characters or more, but would fail if the length was any less than 19 even though there are only 17
characters of actual data.

Page 9 of 35
Data Types

The following data types are used in the definition of segments. All of these are standard HL7 types.
Consult HL7 chapter two for further information.

Datatype Meaning Comment

CM Composite Data Type This field is a combination of other data
items. Where it occurs, the structure of
the composite will be defined in field
notes.
FT Formatted Text Same as ST but allows embedded HL7
formatting characters.
ID Coded Value The value in this field must be drawn
from a table of HL7 defined values. The
table of acceptable values will be found
in the field notes.
IS Coded Value The value in this field must be drawn
from a table of user defined values. The
table of acceptable values will be found
in the field notes. If the table occurs more
than once it will be repeated in an
appendix
NM Numeric Data A number value
ST String Data A string of alphanumeric characters
TS Time Stamp Always formatted as
YYYYMMDD[HHMM[SS]] HL7 allows
4 additional fields of milliseconds. These
are not used in this implementation.
TX Text Data ST that allows some additional special
characters.
DT Date Always formatted as YYYYMMDD.

HL7 Composite Data Types

These composites are used in the definitions of the segments. Where additional clarification is required
these tables may be repeated in the segment notes. These composites are only those that are used in this
document. For composites in fields that are not used please consult HL7 2.1.

AD – Address
This composite differs from the standard HL7 2.1 composite in a number of ways.
1. Other designation (Sub-component 2) is used exclusively as suburb.
2. The country code is entered into the State and Province code and not in HL7 defined country
code field.

Page 10 of 35
 Sub Component Type Notes
<Street Address>^ ST Limited to 35 Characters
<Suburb>^ ST Limited to 30 Characters
<City>^ ST Limited to 30 Characters
<Country Code>^ ST Limited to 7 Characters
<Zip Or Postal Code>^ ST Not Used
<Country> ST Not Used

The field length limits are to comply with the NZHIS specification.

CE – Coded Element
Allows transmission of codes and the associated text.
Sub Component Type Notes
<Identifier>^ ST
<Text>^ ST
<Name of coding system>^ ST
<alternate identifier>^ Not Used
<alternate text>^ Not Used
<name of alternate coding system> Not Used

CK – Composite ID with check digit

Specifies an ID value and associated check digit. For the purposes of this implementation the check
digit components will not be used.
Sub Component Type Notes
<Id Number>^ NM
<Check Digit>^ Not Used
<check digit scheme>^ Not Used
<assigning authority> Not Used

CN – Composite ID Number and Name

This composite is usually used for identifying medical practitioners throughout the message be they
laboratory or other medical personnel.
Sub Component Type Notes
<ID Number>^ ST Wherever possible this field will
contain the NZMC number of the
provider.
<Family Name>^ ST Limited to 25 characters.
<Given Name>^ ST Limited to 20 characters.
<Middle Initial Or Name>^ ST Always Middle initial. If the persons
name has two middle names then the
first middle initial should be used.
<Suffix>^ ST Not Used
<Prefix>^ ST Not Used
<Degree> ST Not Used

Page 11 of 35
The field length limits are to comply with the NZHIS specification.

CQ - Composite Quantity

Sub Component Type Notes

<Quantity>^ NM
<Units> CE

PN – Patient Name
This composite is used for the name of any patients identified in the message.
Sub Component Type Notes
<Family Name>^ ST Limited to 25 characters.
<Given Name>^ ST Limited to 20 characters.
<Middle Initial Or Name>^ ST Always Middle initial. If the persons
name has two middle names then the
first middle initial should be used.
<Suffix>^ ST Not Used
<Prefix>^ ST Not Used
<Degree> ST Not Used

The field length limits are to comply with the NZHIS specification.

Page 12 of 35
MSH - Message Header Segment
The MSH Segment contains the information about the message including, sender, recipient and some
syntactical information.
Seq Element Name Len Type R/O Rpt

1 Field Separator 1 ST R
2 Encoding Characters 4 ST R
3 Sending Application 15 ST R
4 Sending Facility 20 ST R
5 Receiving Application 15 ST R
6 Receiving Facility 30 ST R
7 Date/Time of message 14 TS O
8 Security 40 ST O
9 Message Type 7 CM R
10 Message Control ID 20 ST R
11 Processing ID 1 ID R
12 Version ID 8 NM O
13 Sequence Number 15 NM X
14 Continuation Pointer 180 ST X

MSH-1 – Field Separator

The field separator character will be ‘|’,
Example:

MSH|^~\&|DELPHIC...

MSH-2 – Encoding Characters

This field contains the separator characters for component, repeat and the escape character and sub-
components respectively. We strongly recommend that this field contain “^~\&”. Please see section
above on separators.
Example:

MSH|^~\&|DELPHIC|MEDLAB|LABRESULT|...

MSH-3 – Sending Application

This field should be filled in with the name of the sending application. Since this message is usually
sent from a laboratory this normally contains the name of the lab application. If the lab application is
not named, this field should contain the text 'LABRESULT'; most messages use this value.
Example: In this case the sending laboratory uses the Delphic Lab Results module.

MSH|^~\&|DELPHIC|ediaccnt|LABRESULT|...

Page 13 of 35
MSH-4 – Sending Facility
This field should be filled in with the Healthlink EDI Account name of the sending facility. This must
be filled in correctly so that message acknowledgements can be correctly processed. This field should
not be more 8 characters in length and should always be in lower case.
VARIANCE TO HL7: 8 character limit on the mailbox name.
Example:

MSH|^~\&|DELPHIC|ediaccnt|LABRESULT|...

MSH-5 – Receiving Application

This field identifies the receiving application. Since the receiving application will always be the
Healthlink Lab result processor this field should always contain the text 'LABRESULT'.
Example:

...|^~\&|DELPHIC|ediaccnt|LABRESULT|sectst03|...

MSH-6 – Receiving Facility

This field should be filled in with the Healthlink EDI account name of the intended recipient of this
message. This must be filled in correctly so that the message can be delivered to the correct practitioner
who ordered the test in the first place. Healthlink EDI accounts are always 8 or less characters and are
always lower case. EDI account names can be obtained from Healthlink or Healthlink Online.
Example:

...|DELPHIC|ediaccnt|LABRESULT|sectst03|20000120092032|...

MSH-7 – Date/Time of Message

Date/Time that the sending system created the message. Healthlink always expects this information in
the following format.
Format: YYYYMMDD[HHMMSS]
This field is optional but HealthLink strongly recommends that it be filled at all times to maximum
precision.
Example: This message was generated on the 20th of January 2000 at 9:20:32am.

...|LABRESULT|sectst03|20000120092032|PKI|ORU|...

MSH-8 – Security
This field is used to implement security features. Under HMS 6.0 this is always using a Public Key
Infrastructure and this field always contains PKI. Older systems may use the Healthlink Encryption
system in which case the encryption key will go in this field. Please contact Healthlink for more
information.
Example: A PKI security scheme was employed when sending this message.

...|20000120092032|PKI|ORU|0155002273|P|2.1

Page 14 of 35
MSH-9 – Message type
This field identifies the message type. This field should always contain 'ORU' for lab result messages
and 'ACK' for acknowledgement messages.
Variance to HL7: this specification does not support trigger events.
Example: This message is an ORU message.

...|20000120092032|PKI|ORU|0155002273|P|2.1

MSH-10 – Message control ID

This field is a number or other identifier that uniquely identifies a message from a particular sender.
Each sender is responsible for ensuring that the Message Control Ids from their facility are unique.
Example:

...|20000120092032|PKI|ORU|0155002273|P|2.1

MSH-11 – Processing ID
This field tells how a receiving system should process this message.
Value Meaning
P Process this message as normal
D This message is being used for debugging purposes. It should
be properly acknowledged but the data should be ignored.

Example: This message should be processed as normal.

...|20000120092032|SECURITY|ORU|0155002273|P|2.1

MSH-12 – Version ID
This field contains the HL7 version number of this message. This is always '2.1'.

Example: This message subscribes to HL7 2.1.

...|20000120092032|SECURITY|ORU|0155002273|P|2.1

Page 15 of 35
MSA - Message Acknowledgement Segment
The MSA segment contains information to be sent when replying or acknowledging another message.
HL7 2.1 allows the ORU message to be used as a response for a request for lab results (solicited) as
well as being the standard unsolicited Observation Reporting message. Only the unsolicited mode is
used by Healthlink but this segment is required for ORU messages. The data in this segment can be
safely ignored by new implementations, but older systems still require this segment.

Seq Element Name Len Type R/O Rpt

1 Acknowledgement Code 2 ID R
2 Message Control ID 20 ST R
3 Text Message 80 ST O
4 Expected Sequence Number 15 NM X
5 Delayed Acknowledgement Type 1 ID X

MSA-1 – Acknowledgement Code

This field provides information about the processing of the message to which this message is a
response. This field will always be present and must contain one of the following values. In an
unsolicited ORU message this field should contain ‘AA’.

Value Meaning Comment

AA Application Accept The message was processed successfully. In an
ORU message this field will always have this
value.
AE Application Error The message had semantic difficulties.
AR Application Reject The message contained errors such as required
fields missing or fields too long.
This may also be generated if a serious error has
been caused by processing the original message.

Example: The message that this message is replying to was processed correctly.

MSA|AA|0155002273|This is a text message

MSA-2 – Message Control ID

This field contains the message control ID of the message sent by the sending system to which this
message is a response. Thus the systems can keep a record of those messages that have been responded
to and those that have not. In an original ORU message the value in this field is the same as that in
MSH-10 Message Control ID.
Example: The message, to which this message is a reply, was processed correctly.

MSA|AA|0155002273|This is a text message

Page 16 of 35
MSA-3 – Text Message
This field can contain any text relating to the processing of the message to which this is a reply. In an
unsolicited ORU message this field does not normally contain any data. In an ACK message however
this field is important, especially if the acknowledgement code is not AA. This field is used in
conjunction with the ERR segment to report errors.
Example:

MSA|AA|0155002273|This is a text message.

Page 17 of 35
ERR - Error Segment
The ERR segment is used to add error comments to acknowledgement messages.
Seq Element Name Len Type R/O Rpt
1 Error Code and Location 80 CM O

ERR-1 – Error code and location

This field identifies an erroneous segment in another message. This field should be filled in as
completely as possible. It is composed of the following components:
Sub Component Len Type Notes
<Segment ID>^ 3 ST Line number of the segment in the message, e.g. MSH is line
number ‘0’

<Set ID> 2 NM The Set ID of the offending segment.

<Field position>^ 5 NM This contains the index of the field causing the problem.
<PID>^ 16 NM The Set ID of the PID under which the error
occurred.
<Text> 51 ST Text describing the error.

Variance to HL7: HL7 allows this field to repeat.

Example: This shows that required field OBR-2 in the first occurrence of the OBR segment in the
message was missing.

ERR|OBR^1^2^^Required field missing

Page 18 of 35
NTE - Note Segment
The NTE segment is used for sending notes and comments.
Seq Element Name Len Type R/O Rpt
1 Set ID 4 NM O
2 Source of comment 8 ID O
3 Comment 120 TX R

NTE-1 – Set ID
This field is used where there are more than one NTE segments in a message. The number system used
is as follows:
If the comment is greater than 120 characters in length then it should be split across multiple NTE
segments and the same SetID should be used for all of them.
After each OBX segment the first NTE segment will have a SetID of ‘1’. If more comments are
required, then the subsequent SetID’s will increment the SetID by 1 for each unrelated NTE segment.
While this field is officially optional, it should always be filled in so that accurate debugging
information can be returned and processed.
Example 1: The following example shows the Set ID’s from two unrelated comments for a single
OBX segment.

OBX|…

NTE|1|L|Moderate neutrophilic leucocytosis.

NTE|2|L|Mild thrombocytopenia.

Example 2: The Following example shows the Set ID’s from two unrelated NTE segments for two
different OBX segments.

OBX|…

NTE|1|L|Moderate neutrophilic leucocytosis.

OBX|…

NTE|1|L|Poliomyelitis antibodies not detected

Example 3: The following example shows the Set ID’s from the same comment split across two NTE
segments.

OBX|…

NTE|1|L|Laboratory test performed as requested… <to 120 characters>

NTE|1|L|and completed but no antibodies detected.

NTE-2 – Source of Comment

Identifies the source of the comment. In this implementation, the laboratory is almost always the source
of the comment and the field usually contains L.

Page 19 of 35
 Value Meaning
L Filler was the source of the comment. This corresponds to the
Laboratory.
P Placer system was the source of the comment. This
corresponds to the GP in most cases.
O Other System.

Example: The Laboratory entered the comment.

NTE|1|L|Moderate neutrophilic leucocytosis.

NTE-3 – Comment
Contains the text of the comment.
Variance to HL7: HL7 allows infinite repeats of this field.
Example:

NTE|1|L|Moderate neutrophilic leucocytosis.

Page 20 of 35
PID - Patient ID Segment
The PID segment is used as the primary means of communicating patient identification information.
Seq Element Name Len Type R/O Rpt
1 SetID 4 NM O
2 External Patient ID 16 CK O
3 Internal Patient ID 16 CK R
4 Alternate Patient ID 12 ST O
5 Patient Name 48 PN R
6 Mothers Maiden Name 30 PN X
7 Date Time Of Birth 8 TS O
8 Sex 1 IS O
9 Patient Alias 48 ST X Y
10 Ethnicity 1 ST X
11 Patient Address 106 AD O
12 County Code 4 ST X
13 Home Phone Number 40 ST X 3
14 Business Phone Number 40 ST X 3
15 Primary Language 25 ST X
16 Marital Status 1 ST X
17 Religion 3 ST X
18 Patient Account Number 20 ST X
19 SSN Number 16 ST X
20 Drivers License Num 25 ST X

PID-1 – Set ID
This field uniquely identifies each repeat of the PID segment. The value is ‘1’ for the first PID segment
in the message and is incremented for each subsequent PID segment.
Example: This is the first PID segment in this message.

PID|1||CBC2654||DWARF^SLEEPY^E||19811019|F|||...

PID-2 – External Patient ID

Note: Usage may not be correct.
This field contains the patient NZHIS HCU number. If not known then this field is to be left empty.
Example: This patient does not have a HCU number.

PID|1||CBC2654||DWARF^SLEEPY^E||19811019|F|||...

PID-3 Internal Patient ID

Note: Usage may not be correct.
This field always contains the patient NHI number.

Page 21 of 35
Example:

PID|1||XXX9999||DWARF^SLEEPY^E||19811019|F|||...

PID-4 Alternate Patient ID

Note: Usage may not be correct.
This field contains any other patient ID that may be used to identify a patient. This field would not
normally be used because PID –3 Internal Patient ID, will identify most patients.
Example:

PID|1||XXX9999||DWARF^SLEEPY^E||19811019|F|||...

PID-5 – Patient Name

This field contains the patient’s name. See the PN composite above.
Example:

PID|1||XXX9999||DWARF^SLEEPY^E||19811019|F|||...

PID-7 – Date of Birth

This field contains the patient’s date of birth and optionally the time of birth. This information is not
required, but Healthlink strongly recommends that this field be filled as a way of checking the identity
of a patient.
Example:

...||DWARF^SLEEPY^E||19811019|F|||215 GRANGE RD^OTUMOETAI^TAURANGA

PID-8 – Sex
This field contains the patient’s gender. The following values may be used. We strongly recommend
that one of the first two values be employed as far as possible.
Value Meaning
M Male
F Female
U The patients gender is not known
I Indeterminate. This should almost never be used unless it is a
case of the patients gender being impossible to determine. In
all other cases use U for unknown.
O Other gender.

Example:

...||DWARF^SLEEPY^E||19811019|M|||215 GRANGE RD^OTUMOETAI^TAURANGA

PID-11 – Patient Address

This field contains the mailing address of the patient. Please see the definition of the AD data type
above.

Page 22 of 35
Example:

... ||19811019|M|||215 GRANGE RD^OTUMOETAI^TAURANGA

Page 23 of 35
PV1 - Patient Visit Segment
The Patient Visit Segment is used to communicate information about the patient visit that lead up to
this lab test. It is not required in the ORU message but some of the information is important to some
laboratories (especially hospitals where patient classes and locations are important). Many
implementations send HL7 nulls in the required fields. Others do not use this segment at all – This is
probably the best option if the information is not present.
Seq Element Name Len Type R/O Rpt

1 Set ID 4 NM O
2 Patient Class 1 ST R
3 Assigned Patient Location 12 ST R
4 Admission Type 2 ST X
5 Pre-admit Number 20 ST X
6 Prior Patient Location 12 ST X
7 Attending Doctor 60 ST X
8 Referring Doctor 60 CN O
9 Consulting Doctor 60 CN O Y
10 Hospital Service 3 ST X
11 Temporary Location 12 ST X
12 Pre-admit Test Indicator 2 ST X
13 Readmission Indicator 2 ST X
14 Admit Source 3 ST X
15 Ambulatory Status 2 ST X
16 VIP Indicator 2 ST X
17 Admitting Doctor 60 CN X
18 Patient Type 2 ST X
19 Visit Number 4 ST X
20 Financial Class 11 ST X 4
21 Charge Price Indicator 2 ST X
22 Courtesy Code 2 ST X
23 Credit Rating 2 ST X
24 Contract Code 2 ST X Y
25 Contract Effective Date 8 DT X Y
26 Contract Amount 12 NM O Y
27 Contract Period 3 ST X Y
28 Interest Code 2 ST X
29 Transfer to Bad Debt Code 1 ST X
30 Transfer to Bad Debt Date 8 DT X
31 Bad Debt Agency Code 10 ST X
32 Bad Debt Transfer Amount 12 NM X
33 Bad Debt Recovery Amount 12 NM X
34 Delete Account Indicator 1 ST X
35 Delete Account Date 8 DT X
36 Discharge Disposition 2 ST X

Page 24 of 35
 Seq Element Name Len Type R/O Rpt

37 Discharged to Location 2 ST X
38 Diet Type 2 ST X
39 Servicing Facility 2 ST X
40 Bed Status 1 ST X
41 Account Status 2 ST X
42 Pending Location 12 ST X
43 Prior Temporary Location 12 PL X
44 Admit Date/Time 19 TS X
45 Discharge Date/Time 19 TS X
46 Current Patient Balance 12 NM X
47 Total Charges 12 NM X
48 Total Adjustments 12 NM X
49 Total Payments 12 NM X

PV1-1 – Set ID
This field is used to identify repeats of this segment within a message. Since this segment is always tied
to the PID it is neither necessary nor required and most messages do not use this field.
Where the Set ID is used it should be the same as the PID-01 Set ID to which this segment relates.
Example: This is the first PV1 sent in the message.

PV1|1|O|""|||||""|""

PV1-2 – Patient Class

This field is used by some laboratory systems to classify patients. This is especially the case for
hospital laboratories where the distinction between inpatients and outpatients is important. It has a
default value of “”, i.e. NULL. Where it is used and not null it will usually contain one of the following
values but site defined values are acceptable.

Value Meaning
I Inpatient
O Outpatient

Example: This lab result was ordered from an outpatient visit.

PV1|1|O|""|||||""|""

PV1-3 – Assigned Patient Location

This field contains the patient’s assigned location. Most implementations use HL7 null (“”) in this
field.
Example 1: Patient location is not known.

PV1|1|O|""|||||""|""

Page 25 of 35
PV1-8 – Referring Doctor
Most messages will not use this field, many systems send null. When this field is used, the physician
will be identified by the NZMC number.

Example:

PV1|1|O|""|||||""|""

PV1-9 –Consulting Doctor

Most messages will not use this field, many systems send null. When this field is used, the physician
will be identified by the NZMC number.

Example

PV1|1|O|""|||||""|""

Page 26 of 35
OBR - Observation Request Segment
The Observation Request segment sends information about the test (observation) to which the
subsequent OBX’s report the results. The GP who ordered the test can check the actual test performed
against that ordered and be aware of any minor variations to it.

Seq Element Name Len Type R/O Rpt

1 Set ID 4 NM O
2 Placer Order Number 75 CM O
3 Filler Order Number 75 CM O
4 Universal Service ID 200 CE R
5 Priority 2 ST O
6 Requested Date/Time 19 TS X
7 Observation Date/Time 19 TS R
8 Observation End Date/Time 19 TS R
9 Collection Volume 20 CQ R
10 Collector ID 60 CN O Y
11 Specimen Action Code 1 ST X
12 Danger Code 60 CM X
13 Relevant Clinical Info 300 ST O
14 Specimen Received Date/Time 19 TS R
15 Specimen Source 300 CM_SS X
16 Ordering Provider 60 CN O
17 Order Callback Phone Number 40 TN X 2
18 Placer Field 1 60 ST X
19 Attention Of 60 CN O
20 Receiving Doctor 60 CN O
21 Filler Field 2 60 ST X
22 Results Rpt/Status Chg - Date/Time 19 TS R
23 Charge to Practice 40 CM X
24 Diagnostic Service Sector ID 10 ST O
25 Result Status 1 ST O
26 Parent Result 200 CE X
27 Quantity/Timing 200 TQ X Y
28 Result Copies To 80 CN X 5
29 Parent 150 EI X
30 Transportation Mode 20 ST X
31 Reason for Study 300 CE X
32 Principal Result Interpreter 60 CN O
33 Assistant Result Interpreter 60 CN X
34 Technician 60 CN X
35 Transcriptionist 60 CN X
36 Scheduled Date/Time 19 TS X

Page 27 of 35
OBR-1 – Set ID
Identifies the repeats of this segment within a message. The first OBR for each patient will have a
SetID of ‘1’ and each subsequent OBR will increment by one.
Example: This is the first observation performed on this patient.

OBR|1||00/147871401000|4010^HAEMATOLOGY.....^L|

OBR-2 – Placer Order Number

This is the unique identifier given to this test by the placer of the order. In this case this would be the
identifier that the Practice Management system of the GP assigned to this test. This is made up of two
components.

Sub Component Len Type R/O Notes

<GP Practice ID>^ 20 ST O
<GP Order Number> 15 ST O

Electronic ordering has not to date been implemented so the Observation ID assigned by the practice
Management system is almost never known to the lab and consequently this field is not commonly
used. Some systems use null or a patient ID in this field. These are not recommended.
Example:

OBR|1|1322.4|00/147871401000|4010^HAEMATOLOGY.....^L|

OBR-3 – Filler Order Number

This is the unique identifier given to this test by the filler of the order. The filler of the order is always
responsible for generating the message in this implementation. Consequently, the filler order number
should always be known and filled in the message.
Sub Component Len Type R/O Notes
<Lab Order Number>^ 20 ST R
<Lab ID> 20 ST O

Example:

OBR|1|1322.4|00/147871401000|4010^HAEMATOLOGY.....^L|

OBR-4 – Universal Service ID

This field contains the code for the requested observation or test. This can be either a local or a
universal code. Where possible it is recommended that a universal procedure identifier be used.
Healthlink strongly recommends the use of LOINC. Local codes should only be used where no LOINC
code is available.
Sub Component Len Type R/O Notes
<Code>^ 20 ST R
<Description >^ 30 ST R
<Coding System> 10 ST O This field is not required but should always be
filled. If the coding system is local use ‘L’ in this
field otherwise use the full name of the coding

Page 28 of 35
 system.

Example: This test was a complete Haematology scan, code 4010 of a local coding system.
...|00/147871401000|4010^HAEMATOLOGY^L|R||2000011917...

OBR-5 – Priority
All systems use ‘R’ in this field.
Example:
...|4010^HAEMATOLOGY^L|R||200001191752|""|""|||||...

OBR-7 – Observation Date/Time

This field contains the clinically relevant date and time of the observation. This is the date and time that
the samples or specimens were collected or the time the observation was made if the observation did
not involve specimen collection.
Example: The specimen was collected on the 19 th of January 2000 at 5:52pm.
...|4010^HAEMATOLOGY^L|R||200001191752|""|""|||||...

OBR-8 – Observation End Date/Time

Healthlink always uses HL7 null in this field.
Example:

...|R||200001191752|""|""|||||200001191752||...

OBR-9 – Collection Volume

Healthlink always uses HL7 null in this field.
Example:
...|R||200001191752|””|""|||||200001191752||...

OBR-13 – Relevant Clinical Info

This field contains additional clinical information about the patient or specimen. It can be used to
report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. If a
more structured form of information is required a series of OBX segments should be used instead.
Many messages do not use this field.
Example:.

...|R||200001191752|””|""||||Clinical Info|200001191752||...

OBR-14 – Specimen Received Date/Time

The time that the specimen was received (or taken) by the lab to perform the test. In many cases this is
the same as the Observation Date/Time. HL7 requires the use of this field and many messages send
null in this field.

Page 29 of 35
Example:.

...|””|""||||Clinical Info|200001191752||||2107^BARRETT^F|||...

OBR-16 – Ordering Provider

Contains the details of the GP or Practitioner that ordered the test. Please see the CN data type structure
above. Use the NZMC number where this is available.
Example:
...|200001181424||2107^BARRETT^F|||7200^FORD^SAM|...

OBR-19 – Attention Of
This field can be used to send the results to two GPs at one practice. The results will automatically be
sent to the Ordering Provider (OBR-16) and if another Provider needs to be included in the results then
those details should be entered in this field. Use the NZMC number where this is available.
Example:
...||2107^BARRETT^F|||7200^FORD^SAM|7509^MANING^HAL||20000...

OBR-20 – Receiving Doctor

This implementation requires this field to be the same as OBR-19.
Example:
...|7200^FORD^SAM|7509^MANING^HAL||200001200920||||||||||""

OBR-22 – Results Report Status Change

This field holds the date that the result status changed. For this implementation this will be the time that
the results were loaded into the Laboratory system. Many systems have this field the same as MSH-7
Date/Time of Message.
Example:
...|7509^MANING^HAL||200001200920||||||||||""

OBR-24 – Diagnostic Service Section ID

This field identifies which section of the lab was responsible for conducting the test. This field is not
often used. Please consult HL7 for the usage of this field.

OBR-32 – Principal Result Interpreter

This field contains the name and ID of the individual who interpreted the results. In most cases this
field is NULL. See the CN data type above.

Example:

...|7509^TESTING^HL7|7509^TESTING^HL7||200001200920||||||||||""

Page 30 of 35
OBX - Observation Result Segment
The OBX segment is used to transmit a single observation or observation fragment. It represents the
smallest indivisible unit of a test and its result.

Seq Element Name Len Type R/O Rpt

1 Set ID 4 SI O
2 Value Type 2 ID O
3 Observation Identifier 52 CE R
4 Observation Sub-ID 31 ST O
5 Observation Value 6144 ST R
6 Units 20 CE O
7 Reference Ranges 60 ST O
8 Abnormal Flags 10 ID O
9 Probability 5 NM O
10 Nature of Abnormal Test 5 ID O
11 Observation Result Status 2 ID R
12 Date Last Observation Normal Values 19 TS O

OBX-1 – Set ID
This field is used to identify repeats of this segment against each OBR segment. After every OBR the
first OBX will have a SetID of ‘1’ which will increment for each subsequent OBX Segment. If OBX is
more than the 6144 characters allowed, then the result can be split across two OBX Segments with the
same SetIDs.
Example 1: Standard Set IDs.

OBR|...

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

OBX|2|ST|4030^DIFFERENTIAL^L|NEUS^Neut Seg|12.35|b/L|2.0-7.5|H|||F
OBR|...

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

Example 2: Same result split across two OBX Segments

OBX|1|ST|4030^DIFFERENTIAL^L|NEUS^Neut Seg <and more text to 6144>...

OBX|1|ST|4030^DIFFERENTIAL^L|this completes the result above...

OBX-2 – Value Type

This field contains the format of the observation value in the OBX (field 5). This field should always
be filled. This implementation accepts the following values.

Page 31 of 35
 Value Meaning
ST OBX-5 Contains an HL7 string. This is the default.
OBX-5 contains HL7 text. Which is a string intended for user
TX
display.
OBX-5 contains HL7 text including formatting characters.
FT Please see HL7 section 2.4.6 for information on the use of
escape sequences and formatting characters.

Variance to HL7: HL7 this field is conditionally required.

Variance to HL7: This field will contain ST even if the result is numeric. (As in the example).
Example:

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

OBX-3 – Observation Identifier

This field contains a unique identifier for the specific observation that this result reports. This may be
the same as OBR-4 Universal ID if there is only one result to report for that test. This may be either a
local code or a universal identifier. Healthlink strongly recommends the use of LOINC codes in this
field.
Sub Component Len Type R/O Notes
<Code>^ 10 ST R
<Description >^ 30 ST R
<Coding System> 10 ST O This field is not required but should always be
filled. If the coding system is local use ‘L’ in this
field otherwise use the full name of the coding
system. i.e. ‘LOINC’.

Example: This is a local code for the Haemoglobin count.

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

OBX-4 – Observation Sub-ID

This field is used to distinguish between multiple OBX segments with the same observation ID
organised under one OBR. This situation is extremely rare.

OBX-5 – Observation Value

This field contains the value observed – the result of the test. This may be as simple as a numerical
value or it may contain detailed text describing the outcome. Information in this field should pertain
directly to the result. Notes on the result should be sent in separate Notes and Comments segments.
Variance to HL7: HL7 allows 64k to be sent in this field.
Example 1: Simple Observation Value

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

Example 2: Text Observation value. Note the value in OBX 2.

Page 32 of 35
 OBX|1|FT|…|THROAT SWAB^ ^CULTURE:Normal flora|...

OBX-6 – Units
This field specifies the measurement units of the fields in this segment. This includes results and
reference ranges and any other additional data. See HL7 section 7.1.4 for the regulations of legal units
and prefixes.
Example: The units for the Haemoglobin test result given last field is grams per litre.

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

OBX-7 – Reference Ranges

The reference range of the test conducted. The reference range is the range that a normal test will fall
into. This should be one of the following formats.
Format Notes
Lower Limit–Upper Limit This is the most common format
>Lower Limit Use this only if there is no upper limit
<Upper Limit Use this only if there is no lower limit

Example: Normal results for the Haemoglobin are from 115-165g/L

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

OBX-8 – Abnormal Flags

If the result of the test is not normal, then the abnormality should be communicated in this field. The
most common values for non-microbiology tests are as follows. Please consult HL7 section 7.3.2.8 for
a comprehensive list of acceptable values for all tests.
Variance to HL7: HL7 allows 5 repeats of this field.
Value Meaning
L Low
H High
LL Below Lower Panic Limit
HH Above Upper Panic Limit
N Normal, applies only to Non-Numeric Values.

‘L’, ‘H’ and ‘N’ are by far the most common values used.
Example 1: Because this result is in the normal reference range and the result is numeric, no value is
sent.

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

Example 2: Value for the test is abnormally high.

OBX|1|ST|0060^Glucose^L||9.0|mmol/L|3.0-6.1|H|||F

Page 33 of 35
OBX-9 – Probability
This field contains the probability of a result being true for results with categorical values. It mainly
applies to discrete coded results. It is a decimal number that must be between 0 and 1, inclusive. This
field is rarely, if ever, used.

OBX-10 – Nature of Abnormal Test

This field is rarely, if ever used. Please consult HL7 section 7.3.2.10 for usage guidelines.
Variance to HL7: HL7 allows this field to repeat.

OBX-11 – Observation Result Status

This field provides information about the status of the result for the test described in OBX-3. In almost
all messages in this implementation the results are final and verified; therefore ‘F’ should be used.
Other acceptable values are as follows:

Value Meaning
C Correction, replaces final result
D Delete, currently held result with same ID.
F Final result.
R Results entered but not verified.
P Preliminary result.
I Results Pending.
S Partial result.
X Results for this observation cannot be obtained.

Many practice management systems will not support the functionality of some of these values. Sender
and recipient will need to agree on the finer points of the functionality of these results. For example, is
a D always going to be followed up with another Final result. Will unverified results be accessible etc.

Example: This result is final.

OBX|1|ST|4120^HAEMOGLOBIN^L||134|g/L|115-165||||F

Page 34 of 35
 Examples
All data in these messages is completely fictitious.

Message
MSH|^~\&|DELPHIC|ediaccnt|LABRESULT|sectst03|200001201220|PKI|ORU|
0155002277|P|2.1
MSA|AA|0155002277
PID|1||SIM9999||SIMPSON^LISA^A||19400927|F|||84 RESOLUTION
ROAD^^WELCOME BAY
PV1||O|""|||||""|""
OBR|1||00/149543005500|0055^GENERAL
CHEM....^L|R||200001200910|""|""|||||200001200910||2004^SWART^C|||
7509^TESTING^HL7|7509^TESTING^HL7||200001201220||||||||||""
OBX|1|ST|0060^Glucose^L||9.0|mmol/L|3.0-6.1|H|||F
NTE|1|L|Note Hyperglycaemia.
OBX|2|ST|0610^Fructosamine^L||238|umol/L|200-300|N|||F
OBX|3|ST|0720^Albumin^L||41|g/L|35-50|N|||F

Meaning
This message was sent from ediaccnt (Healthlink Mailbox name) to Sectst03 at 12:20pm on the 20
January 2000. Female patient Lisa A Simpson, born on 27 September 1940 who lives at 84 Resolution
Rd, Welcome Bay, had a General Chemical Test ordered by C Swart. The General Chemical test has
three components, a glucose test, a Fructosamine and an Albumin test. Glucose showed 9.0 mmol/L
which is High and indicated that she was Hyperglycaemic. Fructosamine levels were 238 umol/L
which is inside the reference range of 200-300. Albumin levels were 41g/L which is inside the
reference range of 35-50.

Message
MSH|^~\&|DELPHIC|ediaccnt|LABRESULT|sectst03|200202181034|PKI|ORU|
0155032443|P|2.1
MSA|AA|0155032443
PID|1||FOR9999||KARAMAZOV^Dmitri^A||19570606|M|||19 Blockhouse Bay
Rd^Blockhouse Bay^Auckland
OBR|1||02-2993783-RF-0^SCL|RF^RENAL FUNCTION PANEL^L|R|200207100001
|200202171647|""|""|||||200202171647||99999^Svetlov^A||||||
200207101155|||F
OBX|1|ST|cr^CREATININE^L||0.13|mmol/L|0.05 - 0.10|HH|||F

Meaning
This message was sent from ediaccnt (Healthlink Mailbox name) to Sectst03 at 10:34am on the 18 th of
February 2002. Male patient Dmitri A Karamazov, born on 6th of June 1957 who lives at 19
Blockhouse Bay Rd, Auckland, had a Renal Function Test ordered by A Svetlov. Renal Function test
simply tests the level of Creatinine, which in this case was 0.13mmol/L. This value is above the upper
panic limit.

Page 35 of 35