2 Patient Administration for Pathology

2.1 Message Control Segments 

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

If a value is the usual default for use in Australia it has been highlighted in blue.

Figure 2-1. HL7 message segments 

Segment Name

HL7 Section Reference

BHS2.1.2
BTS2.1.3
DSC 2.1.4 
ERR2.1.5
FHS 2.1.6 
FTS 2.1.7 
MSA 2.1.8
MSH2.1.9

2.1.2 BHS - batch header segment

The BHS segment defines the start of a batch.

 

HL7 Attribute Table - BHS – Batch Header

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
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 

2.1.2.0 BHS field definitions

2.1.2.1 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).

2.1.2.2 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. Australian values are ^~\& (ASCII 94,126, 92, and 38, respectively). 

2.1.2.3 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.

2.1.2.4 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.

2.1.2.5 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.

2.1.2.6 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.

2.1.2.7 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.

2.1.2.8 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.

2.1.2.9 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.

2.1.2.10 BHS-10 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol.

2.1.2.11 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.

2.1.2.12 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.1.3 BTS - batch trailer segment

The BTS segment defines the end of a batch.

 

2.1.3.0 BTS field definitions

HL7 Attribute Table - BTS – Batch Trailer

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
110STO  00093Batch Message Count
280STO  00090Batch Comment
3100NM OY 00095Batch Totals

2.1.3.1 BTS-1 Batch message count (ST) 00093

Definition: This field contains the count of the individual messages contained within the batch.

2.1.3.2 BTS-2 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol.

2.1.3.3 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. Only a single Batch is allowed in Australia.

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.1.4 DSC - continuation pointer segment

The DSC segment is used in the continuation protocol.

 

2.1.4.0 DSC field definitions

HL7 Attribute Table - DSC – Continuation Pointer

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
180 ST   00014Continuation Pointer
1ID  039801354 Continuation Style 

2.1.4.1 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 HL7 International Standard chapter 5 and section 2.15.2, "Continuation messages and segments.” Note that continuation protocols work with both display- and record-oriented messages.

2.1.4.2 DSC-2 Continuation style (ID) 01354

Definition: Indicates whether this is a fragmented message (see HL7 International Standard Section 2.15.2, "Continuation messages and segments"), or if it is part of an interactive continuation message (see HL7 International Standard 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

ValueDescription
FFragmentation
IInteractive Continuation

2.1.5 ERR - error segment

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

 

HL7 Attribute Table - ERR –Error

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
180CMRY 00024Error Code and Location

2.1.5.0 ERR field definition

2.1.5.1 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.

2.1.6 FHS - file header segment

The FHS segment is used to head a file as defined in Overview.

 

HL7 Attribute Table - FHS - File Header   

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
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

2.1.6.0 FHS field definitions

2.1.6.1 FHS-1 File field separator (ST) 00067

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.2 FHS-2 File encoding characters (ST) 00068

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.3 FHS-3 File sending application (ST) 00069

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.4 FHS-4 File sending facility (ST) 00070

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.5 FHS-5 File receiving application (ST) 00071

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.6 FHS-6 File receiving facility (ST) 00072

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.7 FHS-7 File creation date/time (TS) 00073

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.8 FHS-8 File security (ST) 00074

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.9 FHS-9 File name/ID (ST) 00075

Definition: This field can be used by the application processing file. Its use is not further specified.

2.1.6.10 FHS-10 File header comment (ST) 00076

Definition: This field contains the free text field, the use of which is not further specified.

2.1.6.11 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.

2.1.6.12 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.1.7 FTS - file trailer segment

The FTS segment defines the end of a file.

 

HL7 Attribute Table - FTS - File Trailer

SEQ LENDTOPTRP/#TBL#ITEM #ELEMENT NAME
110NMO  00079File Batch Count
280STO  00080File Trailer Comment

2.1.7.0 FTS field definitions

2.1.7.1 FTS-1 File batch count (NM) 00079

Definition: This field contains the number of batches contained in this file. In Australia there is a maximum of 1 batch in a file.

2.1.7.2 FTS-2 File trailer comment (ST) 00080

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

2.1.8 MSA - message acknowledgment segment

The MSA segment contains information sent while acknowledging another message.

HL7 Attribute Table - MSA - Message Acknowledgment

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
12IDR 000800018Acknowledgment Code
220STR  00010Message Control ID
380STO  00020Text Message
415NMO  00021Expected Sequence Number
51IDB 010200022Delayed Acknowledgment Type
6250 CEO 035700023Error Condition

The sending system must return the Message Control ID from the received message in the MSA segment. 

2.1.8.0 MSA field definitions

2.1.8.1 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

ValueDescription 
AAOriginal mode: Application Accept - Enhanced mode: Application acknowledgment: Accept 
AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error 
AROriginal mode: Application Reject - Enhanced mode: Application acknowledgment: Reject 
CA Enhanced mode: Accept acknowledgment: Commit Accept 
CEEnhanced mode: Accept acknowledgment: Commit Error 
CR Enhanced mode: Accept acknowledgment: Commit Reject 

2.1.8.2 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.

2.1.8.3 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.

2.1.8.4 MSA-4 Expected sequence number (NM) 00021

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

2.1.8.5 MSA-5 Delayed acknowledgment type (ID) 00022

Definition:  This field has been retained for backward compatibility.   This field is used only as described above, in the HL7 International Standard Section 2.13.2, “Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only).” Otherwise this field is not used.

HL7 Table 0102 - Delayed acknowledgment type

ValueDescription
DMessage received, stored for later processing
Facknowledgment after processing

2.1.8.6 MSA-6 Error condition (CE) 00023

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field allows the acknowledging system to use a user-defined error code to further specify AR or AE type acknowledgments. This field is a generalized replacement for MSA-3-text message .

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.

The Message Error Condition codes are defined by HL7 Table 0357 - Message error condition codes.

HL7 Table 0357 - Message error condition codes

Error Condition CodeError Condition Text Description/Comment
Success  
0Message accepted

Success. Optional, as the AA conveys success. Used for systems that must always return a status code.

Errors  
100Segment sequence errorThe message segments were not in the proper order, or required segments are missing.
101Required field missingA required field is missing from a segment
102Data type errorThe field contained data of the wrong data type, e.g. an NM field contained "FOO".
103Table value not foundA field of data type ID or IS was compared against the corresponding table, and no match was found.
Rejection  
200Unsupported message typeThe Message Type is not supported.
201Unsupported event codeThe Event Code is not supported.
202Unsupported processing idThe Processing ID is not supported.
203Unsupported version idThe Version ID is not supported.
204Unknown key identifierThe ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient.
205Duplicate key identifierThe ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).
206 Application record locked  The transaction could not be performed at the application storage level, e.g. database locked. 
207 Application internal error   A catchall for internal errors not explicitly covered by other codes.

2.1.9 MSH - message header segment

The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

 

HL7 Attribute Table - MSH - Message Header

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
11STR  00001Field Separator
2STR  00002Encoding Characters
3180 HDO 0361 00003Sending Application
4180HDO 036200004Sending Facility
5180HDO 036100005Receiving Application
6180HDO 036200006Receiving Facility
726TSR  00007Date/Time Of Message
840STO  00008Security
915†CM 0076 / 000300009Message Type
10199††STR  00010Message Control ID
113PTR  00011Processing ID
12250††††VIDR 010400012Version ID
1315NMO  00013Sequence Number
14180STO  00014Continuation Pointer
152IDR††† 015500015Accept Acknowledgment Type
162IDR††† 015500016Application Acknowledgment Type
173IDR†† 039900017Country Code
1816IDON††††††021100692Character Set
19250CER††  00693Principal Language Of Message
2020ID  035601317 Alternate Character Set Handling Scheme 
2110ID O0449 01598 Conformance Statement ID
22





Reserved
23





Reserved
24





Reserved
25





Reserved
26





Reserved
27

250†††††

CWEOY
02430

Security Handling Instructions

† Australian variation to HL7 V2.4 with the length changed from 13 to 15 characters.

† Australian variation to HL7 V2.4 with the length changed from 20 to 199 characters to accommodate a globally unique identifier. This has been pre-adopted from HL72.6-2.9.

†††Australian variation to HL7 V2.4, field optionality has been changed to required.

††††Australian variation to HL7 V2.4 with the length changed from 60 to 250 characters.

††††† Australian variation to HL7 V2.4, field is pre-adopted from HL7 International v2.9. Length of 250 has been set consistent with the CWE length specified in section 3.6 CWE – coded with exceptions.

†††††† Australian variation to HL7 V2.4, field repeat is disallowed.

2.1.9.0 MSH field definitions

2.1.9.1 MSH-1 Field separator (ST) 00001

Definition: 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. Recommended value is |, (ASCII 124).

2.1.9.2 MSH-2 Encoding characters (ST) 00002

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\& (ASCII 94,126, 92, and 38, respectively). In the Australian context the separators are fixed to these values.

2.1.9.3 MSH-3 Sending application (HD) 00003

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

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.

User-defined Table 0361-Sending/receiving application is used as the user-defined table of values for the first component.

User-defined Table 0361 – Sending/receiving application

ValueDescription
MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^LExample application identifier
Best Practice 1.8.5.743Application identifier with only namespace ID valued
PRSLT^HL7PIT^LExample Lab Sending application

Note: By site agreement, implementors may continue to use User-defined Table 0300 - Namespace ID for the first component.

2.1.9.4 MSH-4 Sending facility (HD) 00004

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field further describes the sending application, MSH-3-sending application . With the promotion of this field to an HD data type, the usage has been broadened to include not just the sending facility but other organizational entities such as a) the organizational entity responsible for sending application; b) the responsible unit; c) a product or vendor’s identifier, etc. Entirely site-defined.

User-defined Table 0362 - Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component.

User-defined Table 0362 – Sending/receiving facility

ValueDescription
Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUIDExample sending facility identified with GUID
QML^2184^AUSNATALab example using AUSNATA as coding scheme

Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID  for the first component.

2.1.9.5 MSH-5 Receiving application (HD) 00005

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field uniquely identifies the receiving 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. User-defined Table 0361- Sending/receiving application is used as the HL7 identifier for the user-defined table of values for the first component.

Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.

2.1.9.6 MSH-6 Receiving facility (HD) 00006

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. 

User-defined Table 0362 - Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component. Entirely site-defined.

Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.

2.1.9.7 MSH-7 Date/time of message (TS) 00007

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.

Note: This field was made required in version 2.4. Messages with versions prior to 2.4 are not required to value this field. This usage supports backward compatibility.

2.1.9.8 MSH-8 Security (ST) 00008

Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.

2.1.9.9 MSH-9 Message type (CM) 00009

Components: <message type (ID)> ^ <trigger event (ID)> ^ <message structure (ID)>

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

The first component is the message type code defined by HL7 Table 0076 - Message type. This table contains values such as ACK, ADT, ORM, ORU etc. See HL7 International Standard section 2.17.1 for complete listing.

The second component is the trigger event code defined by HL7 Table 0003 - Event type. This table contains values like A01, O01, R01 etc. See HL7 International Standard section 2.17.2 for a complete listing

The third component is the abstract message structure code defined by HL7 Table 0354 - Message structure.

This table has two columns. The first column contains the value of this code, which describes a particular HL7 “abstract message structure definition” in terms of segments, as defined in HL7 International Standard sections 2.12, “CHAPTER FORMATS FOR DEFINING HL7 MESSAGES” and 2.12.1, “HL7 abstract message syntax example”. The second column of table 0354 lists the various HL7 trigger events that use the particular abstract message definition. For example, the message structure code ADT_A01 describes the single abstract message structure used by the trigger events A01, A04, A05, A08, A13, A14, A28 and A31. See HL7 International Standard section 2.17.3 for a complete listing.

Note: Australian variation to HL7 V2.4 with the length changed from 13 to 15 characters.

2.1.9.10 MSH-10 Message control ID (ST) 00010

Definition: 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 Message Control ID is not an order number for the request nor is it a specimen identifier used by the pathology provider. It is a unique internal identifier for one specific message originating from a particular site. This internal field in the message will not conflict when messages from different placers/fillers with the same Message Control ID are received.  All systems should ensure that their data tables are not keyed uniquely using the value from Message Control ID.

If a patient has one MSH with multiple OBR segments and if there is an error in one result then all results in the message are rejected, not just the OBR with the error. However, when one MSH is sent for each OBR then only the result with the error is rejected.

The recommended format for Message Control ID is a combination of two or three components, including:
1) The first component is to identify the sending facility. 
2) The second (optional) component is a date in YYYYMMDD format.
3) The third component is an incremental counter starting at number 1. 
The generalised format is:

 <sending facility>_<date>.n{nnnnnnn..}

Example:

dhm_20160505.2178

qml_20160915.789


Note: It is not intended for the full AUSNATA form to be used, only the first component of the AUSNATA code. 

For placers, they could use their <site code> or <site code>_<date> e.g. px_45678912.25 

Note: Australian variation to HL7 V2.4 with the length changed from 20 to 36 characters to accommodate a globally unique identifier (GUID).   

2.1.9.11 MSH-11 Processing ID (PT) 00011

Components: <processing ID (ID)> ^ <processing mode (ID)>

Definition: This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules. The first component defines whether the message is part of a production, training, or debugging system (refer to HL7 Table 0103 - Processing ID for valid values). The second component defines whether the message is part of an archival process or an initial load (refer to HL7 Table 0207 - Processing mode for valid values). This allows different priorities to be given to different processing modes. The value used in normal usage is highlighted in blue.

HL7 Table 0103 - Processing ID

ValueDescription
DDebugging
PProduction
TTraining

HL7 Table 0207 - Processing mode

ValueDescription
AArchive
RRestore from archive
IInitial load
TCurrent processing, transmitted at intervals (scheduled or on demand)
Not presentNot present (the default, meaning current processing) 

2.1.9.12 MSH-12 Version ID (VID) 00012

Components: <version ID (ID)> ^ <internationalization code (CE)> ^ <internal version ID (CE)>

Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. Beginning with Version 2.3.1, it has two additional “internationalization” components, for use by HL7 international affiliates. The <internationalization code> is CE data type (using the ISO country codes where appropriate) which represents the HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has more than a single ‘local’ version associated with a single US version. The <internal version ID> has a CE data type, since the table values vary for each HL7 Affiliate.

HL7 Table 0104 —Version ID

ValueDescription 
2.0 Release 2.0 September 1988
2.0D Demo 2.0 October 1988
2.1 Release 2. 1 March 1990
2.2 Release 2.2 December 1994
2.3 Release 2.3 March 1997
2.3.1 Release 2.3.1 May 1999
2.4 Release 2.4 November 2000

To indicate compliance with this localisation the <internationalization code (CE)> must be "AUS&Australia&ISO3166_1".

The <internal version ID (CE)> component must be valued as follows to indicate the profile that is being adhered by the sender.

When the profile is referenced in AU FHIR Provider Directory Endpoint resource payloadType attribute, append the internal version ID identifier component to the following base URL http://ns.hl7.org.au/hl7v2/profiles/. The allowed values in the following table should be maintained into the Australian Endpoint Payload Types value set FHIR resource.

The year and serial number component YYYYXX (where YYYY is a 4 digit year, and XX is a 2 digit serial number) of the internal version ID may change on publication of this specification to align with the version numbering. e.g. "HL7AUSD-STD-OO-ADRM-2018.1" an ID becomes: HL7AU-OO-REF-SIMPLIFIED-201801 where there is a substantive change to the profile otherwise it will remain unchanged and reflect the time of the last substantial change. (A serial number XX is used instead of a date as often the date of publication is unknown, this allows for advance drafting prior to release) 

These are identifiers and they are not intended to be parsed.

HL7 Table 01043—Internal Version ID

Internal version ID valueDescription of useProfile URI for use in FHIR Provider Directory
HL7AU-OO-ORM-201701ORM Order messages based on this specificationhttp://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-ORM-201701
HL7AU-OO-ORU-201701ORU messages based on this specificationhttp://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-ORU-201701
HL7AU-OO-ACK-201701

ACK^R01, ACK^O01 acknowledgement messages

ACK messages where the message type is ACK and structure is a generic ACK. The trigger event may vary.

http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-ACK-201701
HL7AU-OO-ORR-201701Order Response messageshttp://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-ORR-201701
HL7AU-OO-ACK-READ-202001Application read acknowledgements (See 8.4 User Read Acknowledgements)http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-ACK-READ-202001
HL7AU-OO-REF-SIMPLIFIED-201706-L1Simplified Referral Level 1 REF messages (See A8.2.1.1 Referral Level 1)http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1
HL7AU-OO-REF-SIMPLIFIED-201706*Simplified Referral Level 2 REF messages (See A8.2.1.2 Referral Level 2)http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706
HL7AU-OO-REF-SIMPLIFIED-201706*For RRI message application acknowledgementshttp://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706/RRI
HL7AU-OO-OSQ-202001Query for order status. See Section 5.3.http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-OSQ-202001
HL7AU-OO-OSR-202001Query response for order status. See Section 5.3.http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-OSR-202001

*Note that the internal version ID value is shared between multiple message types e.g. REF / RRI.


To indicate compliance with Simplified Referral profile see Appendix 8 Simplified REF profile A8.3 Sender Conformance.

To indicate compliance with other profiles, refer to the profile specification.

2.1.9.13 MSH-13 Sequence number (NM) 00013

Definition: A non-null value in this field implies that the sequence number protocol is in use. This numeric field is incremented by one for each subsequent value.

2.1.9.14 MSH-14 Continuation pointer (ST) 00014

Definition: This field is used to define continuations in application-specific ways.

Only the sender of a fragmented message values this field.

2.1.9.15 MSH-15 Accept acknowledgment type (ID) 00015

Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 - Accept/application acknowledgment conditions for valid values.

Note: In the Australian context acknowledgements must always be used and the value must be "AL".

2.1.9.16 MSH-16 Application acknowledgment type (ID) 00016

Definition: This field contains the conditions under which application acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode.

The following table contains the possible values for MSH-15-accept acknowledgment type and MSH-16- application acknowledgment type:

HL7 Table 0155 - Accept/application acknowledgment conditions

ValueDescription
ALAlways
NENever
ERError/reject conditions only
SUSuccessful completion only

Note: In the Australian context application acknowledgements should be used and the value must be "AL".

2.1.9.17 MSH-17 Country code (ID) 00017

Definition: This field contains the country of origin for the message. It will be used primarily to specify default elements, such as currency denominations. The values to be used are those of ISO 3166, which are reprinted here upon written approval from ANSI.2. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code.

2 Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland

Refer to HL7 Table 0399 - Country code for the 3-character codes as defined by ISO 3166 table.

HL7 Table 0399 – Country code 

ValueDescription
ABWARUBA
AFGAFGHANISTAN
AFTFRENCH SOUTHERN TERRITORIES
AGOANGOLA
AIAANGUILLA
ALBALBANIA
ANDANDORRA
ANTNETHERLANDS ANTILLES
AREUNITED ARAB EMIRATES
ARGARGENTINA
ARMARMENIA
ASMAMERICAN SAMOA
ATAANTARCTICA
ATGANTIGUA AND BARBUDA
AUSAUSTRALIA
AUTAUSTRIA
AZEAZERBAIJAN
BDIBURUNDI
BELBELGIUM
BEN BENIN 
BFA  BURKINA FASO
BGD BANGLADESH 
BGRBULGARIA 
BHR BAHRAIN 
BHS BAHAMAS 
BIH BOSNIA AND HERZEGOVINA 
BLR BELARUS 
BLZ BELIZE
BMU BERMUDA 
BOL BOLIVIA 
BRA BRAZIL
BRB BARBADOS 
BRN BRUNEI DARUSSALAM 
BTN BHUTAN 
BVTBOUVET ISLAND
BWA BOTSWANA 
CAFCENTRAL AFRICAN REPUBLIC 
CAN CANADA 
CCK COCOS (KEELING) ISLANDS 
CHE SWITZERLAND 
CHL CHILE
CHN CHINA 
CIV COTE D'VOIRE 
CMR CAMEROON 
COD CONGO, THE DEMOCRATIC REPUBLIC OF THE 
COG CONGO 
COK COOK ISLAND 
COL COLOMBIA 
COM COMOROS 
CPV CAPE VERDE 
CRI COSTA RICA 
CUB CUBA
CXR CHRISTMAS ISLAND 
CYM CAYMAN ISLANDS 
CYP CYPRUS 
CZE CZECH REPUBLIC 
DEU GERMANY 
DJIDJIBOUTI 
DMA DOMINICA 
DNK DENMARK 
DOM DOMINICAN REPUBLIC 
DZA ALGERIA 
ECU ECUADOR 
EGY EGYPT 
ERI  ERITREA 
ESH WESTERN SAHARA 
ESP SPAIN
EST ESTONIA 
ETH ETHIOPIA 
FIN FINLAND 
FJI FIJI 
FLK FALKLAND ISLANDS (MALVINAS) 
FRA FRANCE 
FRO FAROE ISLANDS 
FSMMICRONESIA, FEDERATED STATES OF 
GAB GABON 
GBR UNITED KINGDOM 
GEO GEORGIA 
GHA GHANA 
GIB GIBRALTAR 
GIN GUINEA 
GLP GUADELOUPE 
GMB GAMBIA 
GNB GUINEA-BISSAU 
GNQ EQUATORIAL GUINEA 
GRC GREECE 
GRD GRENADA 
GRLGREENLAND
GTM GUATEMALA 
GUF FRENCH GUIANA 
GUM GUAM 
GUY GUYANA 
HKG HONG KONG 
HMD HEARD ISLAND AND MCDONALD ISLANDS 
HND HONDURAS 
HRV CROATIA 
HTI HAITI 
HUN HUNGARY 
IDN INDONESIA 
IND INDIA 
IOT BRITISH INDIAN OCEAN TERRITORY 
IRL IRELAND 
IRN IRAN, ISLAMIC REPUBLIC OF 
IRQ IRAQ 
ISL ICELAND
ISR ISRAEL 
ITA ITALY 
JAM JAMAICA 
JOR JORDAN 
JPN  JAPAN
KAZ  KAZAKSTAN
KEN KENYA 
KGZ KYRGYZSTAN 
KHMCAMBODIA 
KIRKIRIBATI 
KNA SAINT KITTS AND NEVIS 
KOR KOREA, REPUBLIC OF 
KWT KUWAIT 
LAOLAO PEOPLE'S DEMOCRATIC REPUBLIC 
LBN LEBANNON 
LBR LIBERIA 
LBY LIBYAN ARAB JAMAHIRIYA 
LCA SAINT LUCIA 
LIE LIECHTENSTEIN 
LKA SRI LANKA 
LSO LESOTHO 
LTU LITHUANIA 
LUX LUXEMBOURG 
LVA LATIVA 
MAC MACAU 
MAR MOROCCO 
MCO MONACO 
MDA MOLDOVA, REPUBLIC OF 
MDG MADAGASCAR 
MDV MALDIVES 
MEX MEXICO 
MHL MARSHALL ISLANDS 
MKD MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF 
MLI MALI 
MLT MALTA 
MMR MYANMAR 
MNG MONGOLIA 
MNP NORTHERN MARIANA ISLANDS 
MOZ MOZAMBIQUE 
MRT MAURITANIA 
MSR MONTSERRAT 
MTQ MARTINIQUE 
MUS MAURITUS 
MWI MALAWI 
MYS MALAYSIA 
MYT MAYOTTE 
NAMNAMIBIA 
NCL NEW CALEDONIA 
NER NIGER 
NFK NORFOLK ISLAND 
NGA NIGERIA 
NIC NICARAGUA 
NIU NIUE 
NLD NETHERLANDS 
NOR NORWAY 
NPL NEPAL 
NRU NAURU 
NZL NEW ZEALAND 
OMN OMAN 
PAK PAKISTAN 
PAN PANAMA 
PCN PITCAIRN 
PER PERU 
PHL PHILIPPINES 
PLW PALAU 
PNG PAPUA NEW GUINEA 
POL POLAND 
PRI PUERTO RICO 
PRK KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF 
PRT PORTUGAL 
PRY PARAGUAY 
PYFFRENCH POLYNESIA 
QAT QATAR 
REUREUNION 
ROM ROMANIA 
RUS RUSSIAN FEDERATION 
RWA RWANDA 
SAU SAUDI ARABIA 
SDN SUDAN 
SEN SENEGAL
SGP SINGAPORE
SGS SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS 
SHN SAINT HELENA 
SJM SVALBARD AND JAN MAYEN 
SLB  SOLOMON ISLANDS 
SLE SIERRA LEONE 
SLV EL SALVADOR 
SMR SAN MARINO 
SOMSOMALIA 
SPM SAINT PIERRE AND MIQUELON 
STP SAO TOME AND PRINCIPE 
SUR SURINAME 
SVK SLOVAKIA 
SVN SLOVENIA 
SWESWEDEN 
SWZ SWAZILAND 
SYCSEYCHELLES 
SYRSYRIAN ARAB REPUBLIC 
TCATURKS AND CAICOS ISLANDS 
TCD CHAD 
TGO TOGO 
THA THAILAND 
TJK TAJIKISTAN 
TKL TOKELAU 
TKM TURKMENISTAN
TMP EAST TIMOR 
TON TONGA 
TTO TRINIDAD AND TOBAGO 
TUN TUNISIA 
TURTURKEY 
TUV TUVALU 
TWN TAIWAN, PROVINCE OF CHINA 
TZA TANZANIA, UNITED REPUBLIC OF 
UGA UGANDA 
UKR UKRAINE 
UMI UNITED STATES MINOR OUTLYING ISLANDS 
URY URUGUAY 
USA UNITED STATES 
UZB UZBEKISTAN 
VAT HOLY SEE (VATICAN CITY STATE) 
VCT SAINT VINCENT AND THE GRENADINES 
VEN VENEZUELA 
VGB VIRGIN ISLANDS, BRITISH 
VIR VIRGIN ISLANDS, U.S. 
VNM VIET NAM 
VUT VANUATU 
WLF WALLIS AND FUTUNA
WSM SAMOA
YEM YEMEN 
YUG YUGOSLAVIA 
ZAF SOUTH AFRICA 
ZMB ZAMBIA 
ZWE ZIMBABWE 

2.1.9.18 MSH-18 Character set (ID) 00692

Definition: This field contains the character set for the entire message. Refer to HL7 Table 0211 - Alternate character sets for valid values.

In Australian usage only "ASCII" must be used (unvalued implies "ASCII").  "UNICODE UTF-8" and "8859/1" messages should only be used by specific agreement.

The International standard allows repeats of this field, but this standard has constrained it to a single character set for the entire message.

HL7 Table 0211 - Alternate character sets

ValueDescriptionComment
ASCIIThe printable 7-bit ASCII character set.(This is the default if this field is omitted)
8859/1The printable characters from the ISO 8859/1 Character set 
8859/2The printable characters from the ISO 8859/2 Character set 
8859/3The printable characters from the ISO 8859/3 Character set 
8859/4The printable characters from the ISO 8859/4 Character set 
8859/5The printable characters from the ISO 8859/5 Character set 
8859/6The printable characters from the ISO 8859/6 Character set 
8859/7The printable characters from the ISO 8859/7 Character set 
8859/8The printable characters from the ISO 8859/8 Character set 
8859/9 The printable characters from the ISO 8859/9 Character set  
ISO IR14  Code for Information Exchange (one byte)(JIS X 0201-1976). Note that the code contains a space,i.e. "ISO IR14".  
ISO IR87  Code for the Japanese Graphic Character set for information interchange (JIS X 0208-1990), Note that the code contains a space, i.e. "ISO IR87".  
ISO IR159  Code of the supplementary Japanese Graphic Character set for information interchange (JIS X 0212-1990). Note that the code contains a space, i.e. "ISO IR159".  
UNICODE The world wide character standard from ISO/IEC 10646-1-19933 Deprecated in HL7v2.6. Retained for backward compatibility
only as v 2.5. Replaced by specific Unicode
encoding codes.
UNICODE UTF-8UCS Transformation Format, 8-bit form. UTF-8 is a variable-length encoding, each code
value is represented by 1,2 or 3 bytes, depending on
the code value. 7 bit ASCII is a proper subset of
UTF but not before and after the hyphen.

† "UNICODE UTF-8" was introduced in HL7v2.6 and has been back ported into this HL7v2.4 localisation to allow use of UTF-8 character encoding.

Note: The field separator character must still be chosen from the printable 7-bit ASCII character set.

The repetitions of this field to specify different character sets apply only to fields of the, FT, ST, and TX data types.

The field MSH-18-character set is an optional, repeating field of data type ID, using IDs outlined in HL7 Table 0211 - Alternate character sets (or equivalents from "ISO 2375").

    • if the field is not valued, the default single-byte character set (ASCII ("ISO IR6")) should be assumed. No other character sets are allowed in the message.
    • if the field repeats, but the first element is NULL (i.e., present but unvalued), the single-byte ASCII ("ISO IR6") is assumed as the default character set.
    • if the sequence is present and the first element is specified, this character set is regarded as the default character set for the message. This must be a single-byte character set (i.e., "ISO IR6", "ISO IR13", "ISO IR14", "ISO IR100", etc.).
    • elements in the remainder of the sequence (i.e., elements 2..n) are alternate character sets that may be used. These may include multi-byte character sets (i.e., JIS X 0208).
    • the default character set should always be a single-byte character set. It should always have "ISO IR6" (ISO 646) or "ISO IR14" (JIS X 0201-1976) in the G0 area. 

2.1.9.19 MSH-19 Principal language of message (CE) 00693

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the principal language of the message. Codes come from ISO 639.

Note: In the Australian context use "en" for English. 

2.1.9.20 MSH-20 Alternate character set handling scheme (ID) 01317

        Alternative Character Sets are not used in Australia and this field is null. The information below is what appears in the international standard.

Definition: When any alternative character sets are used (as specified in the second or later components of MSH-18 character sets), and if any special handling scheme is needed, this component is to specify the scheme used, according to HL7 Table 0356- Alternate character set handling scheme as defined below:

HL7 Table 0356 - Alternate character set handling scheme

ValueDescription
ISO 2022-1994This standard is titled "Information Technology - Character Code Structure and Extension Technique". This standard specifies an escape sequence from basic one byte character set to specified other character set, and vice versa. The escape sequence explicitly specifies what alternate character set to be evoked. Note that in this mode, the actual ASCII escape character is used as defined in the referenced ISO document. As noted in HL7 International Standard 1.6.1., escape sequences to/from alternate character set should occur within HL7 delimiters. In other words, HL7 delimiters are basic one byte characters only, and just before and just after delimiters, character encoding status should be the basic one byte set.
2.3The character set switching mode specified in HL7 2.3, HL7 International Standard sections 2.8.28.6.1, and 2.9.2. Note that the escape sequences used in this mode do not use the ASCII "esc" character. They are "HL7 escape sequences" as defined in HL7 2.3, sec. 2.9 as defined in ISO 2022-1994 (Also, note that HL7 International Standard sections 2.8.28.6.1and 2.9.2 in HL7 2.3 correspond to HL7 International Standard sections 2.8.31.6.1and 2.9.2 in HL7 2.4.)
<null>This is the default, indicating that there is no character set switching occurring in this message.

2.1.9.21 MSH-21 Conformance statement ID (ID) 01598

Definition: Sites may use this field to assert adherence to a Conformance Statement published by HL7 or by a site. Conformance Statements contain detailed explanations of grammar, syntax, and usage for a particular message or set of messages. Examples of the use of Conformance Statements appear in HL7 International Standard Chapter 5, "Query."

Repetition of this field allows more flexibility in creating and naming conformance statements. For example, the first repetition could reference a standard conformance statement, and the second, just some changes to it.

Values for HL7-standard conformance statements appear in HL7 Table 0449 - Conformance statements as defined below.

HL7 Table 0449 - Conformance statements