Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

HL7 V2 messaging is widely used in Australia, including the transmission of Pathology results from laboratories to providers. This section provides a broad overview of the format and function of pathology messages before detailing specific elements in detail. Electronic ordering is less well developed currently but is used in some arenas and provides significant potential advantages for the requester and filler of laboratory tests.

HL7 V2 was developed before the introduction of xml or json and the format is text based and unique to HL7 v2. It was originally designed to pass 7 bit channels and optimizes file size and in Australia is restricted to the ASCII character set as described in the appendix on parsing HL7 v2. Implementers should read and understand Appendix 1 Parsing HL7v2. The file format contains no field names and requires pre-existing knowledge of its structure to process. It is highly storage and bandwidth efficient however.

Most results between laboratories and providers are currently sent in unsolicited mode, where no electronic order was sent, but a paper request was used. An HL7v2 ORU^R01 message is used for this and an example appears below.


Example Pathology Message
PID|||12345678^^^^MR~5432109876^^^AUSHIC^MC||ANTHONY^JENNIFER^KAY||19490709|F|||225 Wises Road^^BUDERIM^QLD^4551||^^^^^^54455055||||||4157269354
OBR|1||15-57243112-CBC-0^QML^2184^AUSNATA|CBC^MASTER FULL BLOOD COUNT^2184|||20151221|||||||201512211940||0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^UPIN||From QML"QMLG4399292.oru" 17.03.2016||DR=UMA2P,LN=15-57243112,RC=Y||201603171124||HM|F||^^^201512210000|0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^UPIN~0191324T^MCINTYRE^ANDREW^^^DR^^^AUSHICPR^L^^^UPIN||||123457Z&Davidson&David&&MBBS&Dr.
OBX|3|NM|789-8^Red Cell Count^LN||3.8|10*12/L|3.6-5.2||||F|||201512212329
OBX|5|NM|787-2^Mean Cell Volume^LN||100|fL|80-98|+|||F|||201512212329
OBX|6|NM|785-6^Mean Cell Haemoglobin^LN||32|pg|27-35||||F|||201512212329
OBX|7|NM|777-3^Platelet Count^LN||393|10*9/L|150-450||||F|||201512212329
OBX|8|NM|6690-2^White Cell Count^LN||8.8|10*9/L|4.0-11.0||||F|||201512212329
OBX|18|NM|704-7^Basophils^LN||0.00|10*9/L|< 0.21||||F
OBX|19|FT|5909-7^Interpretation^LN||Comment:\.br\Mild monocytosis and borderline high mean cell volume.  Other significant haematology parameters are within normal limits for age and sex.\.br\||||||F|||201512212329


When this message is received and Acknowledgement message is produced and returned to the laboratory.

ACK Message
MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2^L|Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2 (Build 6387) [win32-i386] {SVV=76;DBV=76}^L|QML^2184^AUSNATA|20160612150923+1000||ACK^R01|HOM06121509607-198|P|2.3.1^AUS&&ISO^AS4700.2&&L|||||AUS


These two messages are the backbone of result delivery and acknowledgement of delivery for pathology delivery. The first message is the results of the laboratory evaluation (a document), in this case a Full Blood Count, with a message wrapper to address the message and enable the delivery to be confirmed by the second message which is produced by the recipient and returned to the laboratory. The security and authentication around delivery is out of scope of this standard.

Messages are a stream of text which is divided into segments by the CR (ASCII13) character. Each segment starts with a three letter code identifying the content of the segment. eg "MSH", "PID", "OBX" etc. These segments are further defined by the standard to contain fields which are separated by the "|" character. Each field can optionally repeat and each repeat (if present) is separated by the "~" character. The fields themselves are divided into components by the "^" character and the components are divided into SubComponents by the "&" character. There are no levels of hierarchy possible below this. The text content of Fields/components or subcomponents must escape any delimitors used in HL7 ie |^~\& or Line breaks (ASCII 13/10). Escape sequences are provided for this. eg \.br\ replaces a line break in the original text. 

The segments in a message are specified by the standard and are ordered, can be optional and can optionally repeat. Each message type, which is specified in the MSH segment has its own segment structure, but all start with a MSH segment. This creates a hierarchy at the level of the specific message. The structure of a ORU^R01 message (The main message used to deliver results) is detailed below.


"{}"  Repeat

"[]" Optional


ORU^R01 Message Structure
ORU^R01           Unsolicited Observation Message
MSH               Message Header 
    PID           Patient Identification 
    [PD1]         Additional Demographics 
    [{NK1}]       Next of Kin/Associated Parties
    [{NTE}]       Notes and Comments
    PV1           Patient Visit
    [PV2]         Patient Visit - Additional Info
    [ORC]         Order common
    OBR           Observations Report ID
    {[NTE]}       Notes and comments
    [CTD]         Contact Data
    [OBX]         Observation/Result
    {[NTE]}       Notes and comments
  [{FT1}]         Financial Transaction
  {[CTI]}         Clinical Trial Identification
[DSC]             Continuation Pointer


In the example message the MSH segment (Line 1) gives this message a Unique ID "BGC06121502965-8968" and Indicated it was sent by QML Pathology "QML^2184^AUSNATA". The response, The ACK^R01 message indicates that this message has been recieved using the Message Acknowledgment Segment (MSA, Line 2) with the original message ID "MSA|AA|BGC06121502965-8968" . The "AA" indicates "Application Accept".

The message contains a report. The report header is in the OBR Segment (Line 5) and the report has a Unique ID which will never change even if the report is updated "15-57243112-CBC-0^QML^2184^AUSNATA". It also gives the name of the report and who ordered it and who has been sent copies of the report along with the date the test was done.

The OBX segments, on lines 6-24, contain the atomic data that form the actual result. Each atomic result is identified with a code (eg Line 7 "718-7^Haemoglobin^LN") and a data type, in this case mostly Numeric(NM).

The details of the other fields and conventions, localized for Australia,  are specified in this standard, which should be read in concert with the International standard.



The following segments are necessary to support the functionality described in this chapter.

Note: The HL7 message construction rules define the standard HL7 encoding rules, creating variable length delimited messages from the segments defined below. Although only one set of encoding rules is defined as a standard in HL7 Version 2.3, other encoding rules are possible (but since they are non-standard, they may only used by a site-specific agreement). The segments in this section are listed in alphabetical order. The following chart shows a summary of the segments listed by category.

Figure 2-8. HL7 message segments

Segment Category

Segment Name

HL7 Section Reference


 DSC 2.16.4 
 FHS 2.16.6 
 FTS 2.16.7 
 MSA 2.16.8
 General PurposeNTE2.16.10 


All query segments have been moved to chapter 5

2.16.1 ADD - addendum segment

The ADD segment is used to define the continuation of the prior segment in a continuation message. See Section2.15.2, “Continuation messages and segments,” for details.

HL7 Attribute Table - ADD – Addendum




36O  00066Addendum Continuation Pointer ADD field definition ADD-1 Addendum continuation pointer (ST) 00066

Definition: This field is used to define the continuation of the prior segment in a continuation message.

See section 2.15.2, “Continuation messages and segments” for details. When the ADD is sent after the segment being continued, it contains no fields. It is only a marker that the previous segment is being continued in a subsequent message. Thus fields 1-N are not present. The sequence designation, 1-N, means the remainder of the fields in the segment being continued. These remainder of the segment being continued fields are present only when the ADD is sent with a continuation message.

2.16.2 BHS - batch header segment

The BHS segment defines the start of a batch.

HL7 Attribute Table - BHS – Batch Header

11ST R  00081Batch Field Separator
23STR  00082Batch Encoding Characters
315STO  00083Batch Sending Application
420STO  00084Batch Sending Facility
515STO  00085Batch Receiving Application
620STO  00086Batch Receiving Facility
726TSO  00087Batch Creation Date/Time
840STO  00088Batch Security
920STO  00089Batch Name/ID/Type
1080STO  00090Batch Comment
1120STO  00091Batch Control ID
12 20ST   00092 Reference Batch Control ID BHS field definitions BHS-1 Batch field separator (ST) 00081

Definition: 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. Recommended value is |,(ASCII 124). BHS-2 Batch encoding characters (ST) 00082

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and subcomponent separator. Recommended values are ^~\& (ASCII 94,126, 92, and 38, respectively). See Section 2.8, “MESSAGE DELIMITERS.” BHS-3 Batch sending application (ST) 00083

Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. BHS-4 Batch sending facility (ST) 00084

Definition: This field contains the address of one of several occurrences of the same application within the sending system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub-identifier in the second component. Entirely user-defined. BHS-5 Batch receiving application (ST) 00085

Definition: This field uniquely identifies the receiving applications among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. BHS-6 Batch receiving facility (ST) 00086

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments BHS-4-batch sending facility. Entirely site-defined. BHS-7 Batch creation date/time (TS) 00087

Definition: 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. BHS-8 Batch security (ST) 00088

Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified. BHS-9 Batch name/ID/type (ST) 00089

Definition: This field can be used by the application processing the batch. It can have extra components if needed. BHS-10 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol. BHS-11 Batch control ID (ST) 00091

Definition: 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. BHS-12 Reference batch control ID (ST) 00092

Definition: This field contains the value of BHS-11-batch control ID when this batch was originally transmitted.

Not present if this batch is being sent for the first time. See definition for BHS-11-batch control ID.

2.16.3 BTS - batch trailer segment

The BTS segment defines the end of a batch.

HL7 Attribute Table - BTS – Batch Trailer

110STO  00093Batch Message Count
280STO  00090Batch Comment
3100NM OY 00095Batch Totals BTS field definitions BTS-1 Batch message count (ST) 00093

Definition: This field contains the count of the individual messages contained within the batch. BTS-2 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol. BTS-3 Batch totals (NM) 00095

Definition: We encourage new users of this field to use the HL7 Version 2.3 data type of NM and to define it as “repeating.” This field contains the batch total. If more than a single batch total exists, this field may be repeated.

This field may be defined as a CM data type for backward compatibility with HL7 Versions 2.2 and 2.1with each total being carried as a separate component. Each component in this case is an NM data type.

2.16.4 DSC - continuation pointer segment

The DSC segment is used in the continuation protocol.

HL7 Attribute Table - DSC – Continuation Pointer

180 ST   00014Continuation Pointer
1ID  039801354 Continuation Style DSC field definitions DSC-1 Continuation pointer (ST) 00014

Definition: This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of null or not present, then there is no more data to fulfill any future continuation requests. For use with continuations of unsolicited messages, see chapter 5 and section 2.15.2, "Continuation messages and segments.” Note that continuation protocols work with both display- and record-oriented messages. DSC-2 Continuation style (ID) 01354

Definition: Indicates whether this is a fragmented message (see Section 2.15.2, "Continuation messages and segments"), or if it is part of an interactive continuation message (see Section 5.6.3, "Interactive continuation of response messages").

Refer to HL7 Table 0398 – Continuation style code for valid values.

HL7 Table 0398 - Continuation style code

IInteractive Continuation

 2.16.5 ERR - error segment

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

HL7 Attribute Table - ERR –Error

180CMRY 00024Error Code and Location ERR field definition ERR-1 Error code and location (CM) 00024

Components: <segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)> ^ <code identifying error (CE)>



Definition: This field identifies an erroneous segment in another message. The second component is an index if there is more than one segment of type <segment ID>. For systems that do not use the HL7 Encoding Rules, the data item number may be used for the third component. The fourth component (which references HL7 Table 0357 - Message error condition codes, (as a CE data type)) is restricted from having any subcomponents as the subcomponent separator is now the CE’s component separator.



Note: See section, MSA-6-error condition, for a listing of this table.




2.16.6 FHS - file header segment



The FHS segment is used to head a file (group of batches) as defined in Section 2.15.3, “HL7 batch protocol.”


HL7 Attribute Table - FHS - File Header   

11STR  00067File Field Separator
24STR  00068File Encoding Characters
315STO  00069File Sending Application
420STO  00070File Sending Facility
515STO  00071File Receiving Application
620STO  00072File Receiving Facility
726TSO  00073File Creation Date/Time
840STO  00074File Security
920STO  00075File Name/ID
1080STO  00076File Header Comment
1120STO  00077File Control ID
1220STO  00078Reference File Control ID FHS field definitions FHS-1 File field separator (ST) 00067



Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-2 File encoding characters (ST) 00068



Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-3 File sending application (ST) 00069

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-4 File sending facility (ST) 00070

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-5 File receiving application (ST) 00071

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-6 File receiving facility (ST) 00072

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-7 File creation date/time (TS) 00073

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-8 File security (ST) 00074

Definition: This field has the same definition as the corresponding field in the MSH segment. FHS-9 File name/ID (ST) 00075

Definition: This field can be used by the application processing file. Its use is not further specified. FHS-10 File header comment (ST) 00076

Definition: This field contains the free text field, the use of which is not further specified. FHS-11 File control ID (ST) 00077

Definition: This field is used to identify a particular file uniquely. It can be echoed back in FHS-12-reference file control ID. FHS-12 Reference file control ID (ST) 00078

Definition: This field contains the value of FHS-11-file control ID when this file was originally transmitted.

Not present if this file is being transmitted for the first time.

2.16.7 FTS - file trailer segment

The FTS segment defines the end of a file.

HL7 Attribute Table - FTS - File Trailer

110NMO  00079File Batch Count
280STO  00080File Trailer Comment FTS field definitions FTS-1 File batch count (NM) 00079

Definition: This field contains the number of batches contained in this file. FTS-2 File trailer comment (ST) 00080


Definition: The use of this free text field is not further specified.



2.16.8 MSA - message acknowledgment segment

The MSA segment contains information sent while acknowledging another message.

HL7 Attribute Table - MSA - Message Acknowledgment

12IDR 000800018Acknowledgment Code
220STR  00010Message Control ID
380STO  00020Text Message
415NMO  00021Expected Sequence Number
51IDB 010200022Delayed Acknowledgment Type
6250 CEO 035700023Error Condition MSA field definitions MSA-1 Acknowledgment code (ID) 00018

Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 - Acknowledgment code for valid values.

HL7 Table 0008 - Acknowledgment code


Value Description

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 acknowledgment: Reject

CA Enhanced mode: Accept acknowledgment: Commit Accept

CE Enhanced mode: Accept acknowledgment: Commit Error

CR Enhanced mode: Accept acknowledgment: Commit Reject MSA-2 Message control ID (ST) 00010

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. MSA-3 Text message (ST) 00020

Definition: This optional field further describes an error condition. This text may be printed in error logs

or presented to an end user.

Use of MSA-3-text message and MSA-6-error condition are deprecated in favor of ERR-1-Error code and


location. The ERR segment allows for richer descriptions of the erroneous conditions. MSA-4 Expected sequence number (NM) 00021

Definition: This optional numeric field is used in the sequence number protocol.






  • No labels