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.
When this message is received and Acknowledgement message is produced and returned to the laboratory.
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.
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.
2.16 MESSAGE CONTROL SEGMENTS
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
HL7 Section Reference
All query segments have been moved to chapter 5