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

Australian Diagnostics and Referral Messaging - Localisation of HL7 Version 2.4, Release 2 is the Australian localisation of the international HL7 V2 Standard covering the Laboratory/Diagnostics result reporting and laboratory/radiology ordering specification. It has been expanded to include Referral messaging. The term "Diagnostics" covers non laboratory reporting including reporting of diagnostic imaging and non referral related clinical reporting (for example: echocardiography, respiratory function, endoscopy, stress testing, sleep studies). The term pathology in Australia covers all aspects of laboratory medicine including clinical and anatomical pathology domains. The relationship between Pathology Practices and their customers in Australia is considered by Government and others as similar to that between other consultant specialists and their customers. For that reason what HL7 would call an order is generally called a request here and the response by the pathology provider (a formal term meaning the responsible specialist(s)) is called a report.  For some disciplines such as microbiology, anatomical pathology, genetics and genomics the request is more by way of asking a clinical question expecting the pathology provider to understand the best way of answering it - eg Is this cancer, if so what type, and what is the prognosis? It is expected this form of requesting will become more common as laboratory medicine evolves. 

The use case here focuses on widely-available, well-standardized methods that will support the secure access to electronic laboratory orders and results and interpretations for clinical care by authorized parties and is driven by the need for timely electronic access to requested, referred and historical lab results. Requesting clinicians (the Placer) receive test results in the form of a HL7 V2 message, as a response to a request (electronic or paper) or as an unsolicited message by having the report directly sent by the pathology practice (the Filler) to the clinician for importation into their local systems. Referral messaging covers clinical referral between clinicians and hospitals and includes a patient history summary suitable for constructing a Virtual Medical Record for use in decision support and any pathology/radiology/diagnostics reports relevant to the referral. It also includes a Medication summary. 

This document tries to provide coverage for all laboratory messaging scenarios in the Australian context including public and private entities, hospital and community and public health entities. The referral messaging covers referral between medical practitioners, allied health and hospitals. It covers referral between practitioners, referral to hospitals and hospital discharge.

The Royal College of Pathologists of Australasia (RCPA) has developed a number of policies around safety in requesting and reporting of pathology including the use of terminology and the transmission of data.  These policies have been incorporated into this document.

This document and the specifications in it supersede those in AS 4700.2-2012 - Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and diagnostic imaging (diagnostics) and HB 262 (Rev)-2012 - Guidelines for messaging between diagnostic providers and health service providers, and AS 4700.6-2006 Implementation of Health Level Seven (HL7) Version 2.4 Part 6: Referral, discharge and health record messaging.

1.1 Purpose

This guide contains the necessary specifications for pathology requests and reports in Australian healthcare using the HL7 V2.4 protocol. Where appropriate aspects of later versions of HL7 V2  have been incorporated into this localization. Where this is done it is flagged as a variation from v2.4.

1.2 Audience

This guide is designed for use by analysts and developers who require guidance on optional and ambiguous elements of an Australian constrained HL7 Version 2.4.  Users of this guide must be familiar with the details of HL7 message construction and processing.  This guide is not intended to be a tutorial on that subject.

1.3 Scope

This specification covers the exchange of laboratory results from an appropriate requesting provider or organisation to the testing source and the transmission of the result from the testing source to the recipient.  One of the primary features of this implementation guide is its focus on key points of broad interoperability.  These key points include the following:

  • Use of strong identifiers for key information objects – These information objects include patients, orders, providers and organizations.  A strong identifier is one that uniquely identifies the object in question in a global fashion.  This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created.  For patients, providers and organsiations this is achieved through the use of the use of the Individual Healthcare Identifier (IHI), Healthcare Provider Identifier–Individual (HPI–I) and Healthcare Provider Identifier–Organisation (HPI–O). In places Medicare Provider numbers are used to provide for location specific provider identifiers. Healthcare Provider Identifier-Organisation (HPI-O) identifiers are not currently available for all organisations at the required level of granularity and alternative organisation identifiers are usually used.
  • Use of Vocabulary Standards ­ This guide calls for specific vocabulary standards for the exchange of laboratory information.  Use of standard vocabularies is important for a number of reasons.  Use of standard vocabularies allows broad distribution of healthcare information without the need for individual institutions to exchange master files for data such as test codes, result codes, etc.  Each institution ideally uses the standard codes or maps its own local vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a single island of information.  Standard vocabularies, particularly coded laboratory results, enable more automated decision support for patient healthcare, as well as more automated public health surveillance of populations.

1.4 Conventions

This guide adheres to the following conventions:

  • The guide is constructed assuming the implementer has access to the 2.4 version of the HL7 Standard.  Although some information from the standard is included in this implementation guide, much information from the standard has not been repeated here.
  • Data types have been described separately from the fields that use the data types. 
  • No conformance information is provided for optional message elements.  This includes length, usage, cardinality, value sets and descriptive information.  Implementers' who want to use optional message elements should refer to the HL7 Standard to determine how these optional message elements will be used. Use of optional message elements should not change the interpretation of data sent using the standard elements.

The following table describes the various attributes used by this guide to document data type attribute tables, message structure attribute tables and segment attribute tables.  Not all attributes apply to all attribute tables.

Table 1-1. Message Element Attributes

Attribute

Definition

Seq

Sequence of the elements as numbered in the HL7 message element.  The Seq attribute applies to the data type attribute table and the segment attribute table.

Segment

Three-character code for the segment and the abstract syntax (e.g., the square and curly braces).

[ XXX ]              Optional

{ XXX }              Repeating

XXX                  Required

 [{ XXX }]           Optional and Repeating

Note that for segment groups there is no segment code present, but the square and curly braces will still be present.

The Segment attribute only applies to the Message attribute table.

Length

Maximum length of the element.  Lengths are provided only for primitive data types.

The length attribute applies to data type attribute tables and segment attribute tables.

Lengths should be considered recommendations, not absolutes.  The receiver can truncate fields, components and sub-components that are longer than the recommended length.  The receiver should continue to process a message even when a field, component, or sub-component length exceeds the maximum recommended length identified in this specification.

DT

Data type used by this profile for HL7 element.

The data type attribute applies to data type attribute tables and segment attribute tables.

Usage

Usage of the message element for this profile.  Indicates whether the message element (segment, segment group, field, component, or subcomponent) is required, optional, or conditional in the corresponding message element.  Usage applies to the message attribute table, data type attribute table and the segment attribute table.  See HL7 International standard section C.3.1 – Usage for documentation on how usage has been implemented in this guide.

Legal usage values are:

R – Required. 
HL7 Definition:  A conforming sending application shall populate all “R” elements with a non-empty value.  Conforming receiving application shall process (save/print/archive/etc.) or ignore the information conveyed by required elements.  A conforming receiving application must not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element.
Any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.

RE – Required, but can be empty. 
HL7 Definition:  The element may be missing from the message, but must be sent by the sending application if there is relevant data.  A conforming sending application must be capable of providing all "RE" elements.  If the conforming sending application knows the required values for the element, then it must send that element.  If the conforming sending application does not know the required values, then that element will be omitted.
Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but must be able to successfully process the message if the element is omitted (no error message should be generated because the element is missing).

O – Optional. 
HL7 Definition:  This code indicates that the Usage for this element has not yet been defined.  A usage of ‘Optional’ may not be used in ‘implementation’ profiles (no-optionality profiles).  Conformance may not be tested on an Optional field.  Narrower profiles may be defined based on this profile, and may assign any usage code to the element

C – Conditional. 
HL7 Definition:  This usage has an associated condition predicate (See HL7 International standard section 2.B.7.6, "Condition predicate").
If the predicate is satisfied: A conformant sending application must always send the element.  A conformant receiving application must process or ignore data in the element.  It may raise an error if the element is not present.
If the predicate is NOT satisfied:  A conformant sending application must NOT send the element.  A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it may raise an error if the element IS present.

CE – Conditional, but may be empty.
HL7 Definition:  This usage has an associated condition predicate (See HL7 International standard section 2.B.7.6, "Condition predicate").
If the predicate is satisfied: If the conforming sending application knows the required values for the element, then the application must send the element.  If the conforming sending application does not know the values required for this element, then the element shall be omitted.  The conforming sending application must be capable of knowing the element (when the predicate is true) for all 'CE' elements.  If the element is present, the conformant receiving application shall process (display/print/archive/etc.) or ignore the values of that element.  If the element is not present, the conformant receiving application shall not raise an error due to the presence or absence of the element.
If the predicate is not satisfied: The conformant sending application shall not populate the element.
The conformant receiving application may raise an application error if the element is present.

X – Not used for this profile.
HL7 Definition:  For conformant sending applications, the element will not be sent.  Conformant receiving applications may ignore the element if it is sent, or may raise an application error.

- - The hyphen (-) Indicates the profile using the actor does not provide documentation of the structure containing the particular element or does not provide documentation of the particular element in the structure.  For instance in a data type specification for CE, if a profile does not provide documentation of the CE data type, then each component of the data type would have a “-“ for the usage for the actor associated with that profile.

Cardinality

Minimum and maximum number of times the element may appear.

[0..0]   Element never present.

[0..1]   Element may be omitted and can have, at most, one occurrence.

[1..1]   Element must have exactly one occurrence.

[0..n]   Element may be omitted or may repeat up to n times.

[1..n]   Element must appear at least once, and may repeat up to n times.

[0..*]   Element may be omitted or repeat an unlimited number of times.

[1..*]   Element must appear at least once, and may repeat unlimited number of times.

[m..n]  Element must appear at least m, and at most, n times.

Cardinality applies only to message attribute tables and segment attribute tables.

See Section C.3.2 for additional information on how cardinality is handled in this guide.

Value Set

The set of coded values to be used with the field.  The value set attribute applies only to the data type attribute tables and the segment attribute tables.  The value set may equate with an entire code system part of a code system, or codes drawn from multiple code systems.

Note:  Where a table constraint is indicated, or where HL7 Version 2.6 standards are pre-adopted, the constrained or specified HL7 table is included below the data type table.

Name

HL7 descriptor of the message element.  Name applies to the message attribute table, data type attribute table and the segment attribute table.

Description/Comments

Context and usage for the element.  Description/Comments applies to the message attribute table, data type attribute table and the segment attribute table.

 

The following table provides some recommendations for testing the various usage codes described in the previous table.

Table 1-2. Usage Conformance Testing Recommendations

Usage

Recommendation

R Required

Required elements must be present in a message instance with the following caveats:

A required segment, which is contained within a segment group, is required only when the segment group is present in the message.  For instance if the segment group is RE, then when the segment group is present, the required segments in that group must be present.

A required field in a segment is required only when the segment itself is present in the message.  For instance if the segment is CE (conditional or empty) and the conditional predicate is satisfied, then the segment is present in the message and the required fields must be present in the segment.

A required component of a data type is required only when the field the data type is associated with is present in the message.

Testing of a required element generally involves generating both a fully populated message instance as well as a minimally populated message instance.  It may be necessary to generate specific test cases to handle separate segment groups, segments, etc. depending on the usage associated with these higher level elements within a message.

RE – Required, but can be empty

Since conformant senders must be able to show they can send this data, the primary mechanism for testing the RE usage would involve requiring the sender to transmit a “fully” populated message instance from their application.  In this case, the expectation is that the message will be generated by the application, not handcrafted.  The message would contain all data the sending application can populate in the message.  This generally means the sender would be populating in their application all data elements being tested, including those that are optional in the application.

O – Optional

Conformance testing for optional elements would not normally be performed.  If a particular implementation decides to use an optional element, it should create an implementation specific profile which further constrains this profile, making the optional element either required, required but may be empty, condition or conditional but may be empty, and then test the element in question based upon the assigned usage in that profile.

C – Conditional

Testing conditional elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. 

CE – Conditional, but may be empty

Testing conditional but may be empty elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. 

X – Not used for this profile

Testing this usage code usually involves looking at both fully populated and minimally populated messages.  Note that the sending application may collect the data element in question, but it should not communicate that data element in message instances.

1.5 Key Words   

In this localisation we have attempted to use 'MUST' to mean that the definition is a mandatory requirement of the specification and 'SHOULD' to mean that there may exist circumstances where it is valid to not adopt the recommendation but the full implications must be understood and carefully weighed before choosing a different course. This is in line with usage with NPAAC and other useage in the Australian Pathology Sector. We have however drawn heavily on HL7 v2 Standards in writing the localisation. These have a wider use of terms meaning the same thing and so it should be the key words:  

“MUST” or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

“MUST NOT” or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

“SHOULD” or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

“SHOULD NOT” or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

“MAY” or the adjective "OPTIONAL", mean that an item is truly optional. One software supplier may choose to include the item to enable certain capabilities while another software supplier may omit the same item. In either case, the communication partner cannot be expected to either provide it (sender) or process it (receiver) without clear and voluntary agreement between the partners.

Any further constraining of optional segments/fields/components must be agreed to by both parties and cannot be made pre-requisite to sending/receiving messages to achieve the basic interoperability described in this guide. Therefore, a sender shall not require a receiver to accept any segments/fields/components marked as optional to successfully send a message. Likewise, a receiver shall not require a sender to send any segment/fields/components marked as optional to successfully receive such a message.

1.6 Related Documents

1.7 Overview of Pathology Messaging

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, optimizes file size and in Australia by default uses 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. It should be noted in Australia most paper requests are computer generated and so there is still the opportunity to close the loop between ordering and reporting.

Example Pathology Report Message
MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2^L|ACME Pathology^7654^AUSNATA|||20160612150255+1000||ORU^R01|BGC06121502965-8968|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL|AL|AUS
PID|||12345678^^^^MR~5432109876^^^AUSHIC^MC||ANTHONY^JENNIFER^KAY||19490709|F|||225 Wises Road^^BUDERIM^QLD^4551||^^^^^^54455055||||||4157269354
PV1|1|O||||||0488077Y^SMITH^RAY^^^DR^^^AUSHICPR^L^^^PRN|0191324T^SPECIALIST^ANDREW^^^DR^^^AUSHICPR^L^^^PRN
ORC|RE||15-57243112-CBC-0^ACME Pathology^7654^AUSNATA||CM|||||||0488077Y^SMITH^RAY^^^DR^^^AUSHICPR^L^^^PRN
OBR|1||15-57243112-CBC-0^ACME Pathology^7654^AUSNATA|CBC^MASTER FULL BLOOD COUNT^7654|||20151221|||||||201512211940||0488077Y^SMITH^RAY^^^DR^^^AUSHICPR^L^^^UPIN||From ACME"ACMEG4399292.oru" 17.03.2016||DR=UMA2P,LN=15-57243112,RC=Y||201603171124||HM|F||^^^201512210000|0488077Y^SMITH^RAY^^^DR^^^AUSHICPR^L^^^UPIN~0191324T^SPECIALIST^ANDREW^^^DR^^^AUSHICPR^L^^^UPIN||||123457Z&Davidson&John&&MBBS&Dr.
OBX|1|ST|15430-2^^LN||FULL BLOOD EXAMINATION||||||F
OBX|2|NM|718-7^Haemoglobin^LN||121|g/L|115-160||||F|||201512212329
OBX|3|NM|789-8^Red Cell Count^LN||3.8|10*12/L|3.6-5.2||||F|||201512212329
OBX|4|NM|4544-3^Haematocrit^LN||0.38||0.33-0.46||||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|9|NM|770-8^Neutrophils^LN||53|%|||||F|||201512212329
OBX|10|NM|751-8^Neutrophils^LN||4.7|10*9/L|2.0-7.5||||F
OBX|11|NM|736-9^Lymphocytes^LN||30|%|||||F|||201512212329
OBX|12|NM|731-0^Lymphocytes^LN||2.6|10*9/L|1.1-4.0||||F
OBX|13|NM|5905-5^Monocytes^LN||14|%|||||F|||201512212329
OBX|14|NM|742-7^Monocytes^LN||1.2|10*9/L|0.2-1.0|+|||F
OBX|15|NM|713-8^Eosinophils^LN||3|%|||||F|||201512212329
OBX|16|NM|711-2^Eosinophils^LN||0.26|10*9/L|0.04-0.40||||F
OBX|17|NM|706-2^Basophils^LN||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 an 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.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||||AUS
MSA|AA|BGC06121502965-8968

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 (ASCII 13) 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 delimiters 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 full structure of a ORU^R01 message (The main message used to deliver results) is detailed below. This is the full international message structure and in Australia PV1 has been made mandatory and some optional segments have been removed. The Australian message structure is detailed in the section on Observation Reporting.

Legend:

"{}"  Repeat

"[]" Optional 

Australian ORU^R01 Message Structure
ORU^R01           Unsolicited Observation Message
MSH Message Header
{
    PID Patient Identification
    [
       [PD1] Additional Demographics
       [{NK1}] Next of Kin/Associated Parties
       PV1 Patient Visit
       [PV2] Patient Visit - Additional Info
    ]
    {
        [ORC] Order common
        OBR Observations Report ID
        [CTD] Contact Data
        {
            [OBX] Observation/Result
        }
    }
}
[DSC] Continuation Pointer

Note that the message structure has been constrained compared with the international standard. This link demonstrates the original message structure: International ORU Structure

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

In the PV1 segment, in field 9, the provider this message was delivered to is indicated as "0191324T^SPECIALIST^ANDREW^^^DR^^^AUSHICPR^L^^^PRN"

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^ACME Pathology^7654^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.

In the case of an electronic order a ORM^O01 message is sent to the laboratory and this is responded to with a ORR^O02 message.

Example Order Message
MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||ACME Pathology^7654^AUSNATA|20160814205041+1000||ORM^O01^ORM_O01|XX08142050015-2604|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL|AL|AUS
PID|1|....
PV1||O||||||||||||||V1||||BULKBILL
ORC|NW|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||BGC-00013065^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||||201608142050+1000|||0191324T^SPECIALIST^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||201608142049+1000||||||Buderim GE Centre
OBR|1|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||26604007^Full Blood Count^SCT|||||||L|||||0191324T^SPECIALIST^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^^^^^R|254327KW^BLOGGS^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^Pregnant:False~^Fasting:True~^Radiotherapy:False~^Hormonal Therapy:False
OBX|1|FT|11492-6^History and Physical Notes^LN||This is a test message\.br\||||||F|||201608142050+1000

This message is requesting a Full Blood Count encoded as "26604007^Full Blood Count^SCT" from ACME Pathology Laboratories encoded as "ACME Pathology^7654^AUSNATA" with an order number of "BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID". "ORC|NW|" indicates this is a new order. In the order we specify the ordering provider in the ORC segment which is "0191324T^SPECIALIST^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN" and request a copy be sent to "254327KW^BLOGGS^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN" in the OBR Segment.

The response to this message is as below

The ORR response to an order message
MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.4 (Build 6896) [win32-i386] {SVV=78;DBV=76}^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|20160814205104+1000||ORR^O02|BGC08142051838-6830|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL|AL|AUS
MSA|AA|XX08142050015-2604
PID|1|....
ORC|OK|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||BGC-00013065^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||||201608142050+1000|||0191324T^SPECIALIST^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||201608142049+1000||||||Buderim GE Centre
OBR|1|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||26604007^Full Blood Count^SCT|||||||L|||||0191324T^SPECIALIST^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^^^^^R|254327KW^BLOGGS^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^Pregnant:False~^Fasting:True~^Radiotherapy:False~^Hormonal Therapy:False

The ORR message confirms the tests ordered back to the placer and may contain the laboratory number(s).

The MSA segment "MSA|AA|XX08142050015-2604" indicates this message has been accepted and the ORC value of "ORC|OK|" indicates the order has been accepted.

The combination of the ORU^R01 report message and its response and the ORM^O01 order message and its acknowledgement are the backbone of pathology messaging. The details of the order and report messages are covered in subsequent sections. Segments common to all message processing are covered in this section. In some settings the messages and segments used in the examples will be all that is encountered in normal usage but the international standard covers similar messages used in queries for orders and results and these will be seen in some settings but are not covered in this guide.

Messages can be batched into files using a single batch inside a File Header structure as illustrated below. In Australia only one Batch is supported but a batch can contain any number of messages. The main purpose of this wrapper is to ensure the collection of messages has not been truncated in transport as the file should end with a BTS and FTS and this should be checked for when processing files.  The specification of the segments used in many HL7v2 message types is provided in section 2.1, where usage notes and some example values are provided.

 

Message Structure for Batches
FHS
BHS
  {
    MSH
    {Any segments required by message}
  }
BTS
FTS
Example of Message in File Header
FHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000
BHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000
MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:0.12.8 (Build 310)^L|Demo Practice^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|||20050417220634+1000||ORU^R01|20050417.736428|P|2.4^AUS&&ISO3166_1^HL7AU.ONO.1&&HL7AU|||AL|AL|AUS
PID|1||100333^^^Medical-Objects&7C3E3682-91F6-11D2-8F2C-444553540000&GUID^SR^Demo Practice&1FFA8984-7166-4655-B195-7B4FFFD2F136&GUID||TESTER^Testy^^^Mr^^L||19900101|M|||3 Drury Lane^^NAMBOUR^QLD^4560^AUS^H||61(07)54455055^PRN^PH^^61^07^54455055|||||||||||||||||N
PV1|1|O||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|RE||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID||CM|||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Practice^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|11486-8^Chemotherapy Record^LN|||20050417+1000|||||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||From Demo Practice in File 20050417.736425 dated 17.04.2005||LN=E062CF28-A67B-45D6-A5F8-B1423EDFB093||200504172206+1000||PHY|C||^^^20050417+1000|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||0191322W&ANDERSON&THOMAS&&&Dr&&AUSHICPR&AUSHICPR
OBX|1|NM|3141-9^Weight^LN||70|kg^^ISO+|||||F
OBX|2|NM|28325-9^Performance Status^LN||2||||||F
OBX|3|ST|21946-9^Chemotherapy Rx^LN||CHOP||||||F
OBX|4|FT|11486-8^^LN||This is a record of chemo being given.\.br\||||||F
BTS|1||1
FTS|1

 

ACKNOWLEDGEMENT PROCESSING

The HL7 standard specifies two levels of acknowledgement processing: Original and Enhanced Modes.

(a) Original Mode, specifies that the message be acknowledged at the application level. The reasoning is that it is not sufficient to know that the underlying communications system guaranteed delivery of the message. It is also necessary to know that the receiving application processed the data successfully at a logical application level.

(b) Enhanced mode, The HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message. After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.

This standard requires the use of Enhanced Mode Acknowledgment.

 

 

  • No labels

9 Comments

  1. I'm not sure the 'Australian ORU^R01 Message Structure' is correct or rather what we want to ask for in australia on this page?

    As it is, we stated that all segment under the MSH Segment, as a group,  can repeat.

    Here is what we have above:

    ORU^R01           Unsolicited Observation Message
    MSH Message Header
    { <- Should this be here?
        [
           PID Patient Identification
                 ...etc
    So that would allow a message with this segment structure:
    MSH
      PID 
      PV1
      ORC 
      OBR
        OBX
      PID
      PV1
        ORC
        OBR
          OBX
    ...etc
    Oddly, I went looking at the international standard and yes, in fact, this is what the standard allows and what is seen here is almost a direct copy. But again,  I ask, does anyone here actual expect to receive a single message (and not a Batch message) that have many different patients reports in it?  Ref: Internation HL7 V2.4 Standard, Section 7.3.1

    I am aware of Message Segment Groups (as per the .xsd snippets below) and realise that this repetition is of the 'ORU_R01.PATIENT_RESULT' Message Segment group and once again here in the xsd files it is permitted in the international standard but still the question stands for our implementation.
    Furthermore, in the OUL message structure (of which we are not using although it has a similar intent) the repetition was dropped. Ref: Internation HL7 V2.4 Standard, Section 7.3.2

    So in summary, What we have is technically correct, yet is it what we want people to do? Have you ever seen messages in Australia like this, do you think any system are equipped to handle this type of message? Don't we expect one patient per message and then many messages and patient per HL7 Batch (FHS, DHS)?

    Maybe, I'm just the odd one out here and this is being used, I've just never seen it or expected it. Maybe we do leave it this way just to be safe and backwards compatible if someone is doing this today.  It does comply with the international standards but we could also further constrain it if we wanted to. I also just looked at AS4700.2-2012 and HB262 and both do not state the repetition discussed, so it is newly added in this standard.

    HL7 V2 schema xsd snippets

    ORU

    <xsd:complexType name="ORU_R01.CONTENT">
      <xsd:sequence>
        <xsd:element ref="MSH" minOccurs="1" maxOccurs="1"/>
        <xsd:element ref="ORU_R01.PATIENT_RESULT" minOccurs="1" maxOccurs="unbounded"/>
        <xsd:element ref="DSC" minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
    </xsd:complexType>

    OUL

    <xsd:complexType name="OUL_R21.CONTENT">
      <xsd:sequence>
        <xsd:element ref="MSH" minOccurs="1" maxOccurs="1"/>
        <xsd:element ref="NTE" minOccurs="0" maxOccurs="1"/>
        <xsd:element ref="OUL_R21.PATIENT" minOccurs="0" maxOccurs="1"/>
        <xsd:element ref="OUL_R21.VISIT" minOccurs="0" maxOccurs="1"/>
       <xsd:element ref="OUL_R21.ORDER_OBSERVATION" minOccurs="1" maxOccurs="unbounded"/>
        <xsd:element ref="DSC" minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
    </xsd:complexType>

     
    1. Angus, you are probably right that many systems would not handle multiple PID per ORU. I'm uncertain as the the use case, perhaps bulk loading of information? Multiple messages could do that however. Multiple patients associated with the report? eg. twins? how is that handled? Does it mean that the report that follows applies to both patients or just the last PID?

       

      Constraining it may be a good idea. I'd be interested also in others thoughts on it.

       

      I think if it weren't in AS4700.2 / HB262 then we should probably not introduce it here.

      1. What about tissue typing reports?

        The report will show full PID details of the patient/recipient, and at least the ID of the potential donor. And if the potential donor is a blood relative, there is no reason not to show the full PID details.

        Constraining it may prohibit at least this type of use cases.

         

        1. Thanks Stephen for the info.

          Another thought is if we are allowing for this perhaps we should specifically address this in receiver conformance statements in Appendix 5, as its likely not to work well otherwise as many systems probably assume a single patient.

          1. Hi Jared,

            Suggest that also to include use cases and example data.

            Use case 1 - Tissue typing report involving patient/recipient and unrelated potential donor. Patient/recipient PID data include: full patient PID data; potential donor PID data include: ID, Age, Sex

            Use case 2 - Tissue typing report involving patient/recipient and genetically related potential donor. Patient/recipient ID data include: full patient PID; potential genetic related donor: full PID details

             

  2. I'm concerned that if we go down this path we are taking on a very complex beast.

    1. agreed. This doesn't stop site-site specific negotiation, but it is precluded in the general case.

  3. I agree with the view that if it hasn't been part of the specifications that we should NOT introduce it here.  It was not our intention to make changes that had not had a high level of consensus around them and had been well thought through. 

  4. For future-proofing this document, we should change any references to the ihtsdo website to http://www.snomed.org/ now that they are SNOMED International , an IHTSDO company.