Australian Pathology Table of Contents
Australian Diagnostics and Referral Messaging - Localisation of HL7 Version 2.4, Release 12 is the Australian localisation of the the international HL7 V2 Laboratory ordering and result reporting specification. The term pathology in Australia covers all aspects of laboratory medicine including clinical and anatomical pathology domains. The relationship between Pathology Practices Standard covering the Laboratory/Diagnostics/Clinical result reporting, laboratory/radiology ordering specification and patient referral. 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, while the term “radiology” is understood to include all diagnostic imaging modalities, whether X-ray based or other (e.g. ultrasound).
The relationship between pathology and radiology 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 e.g. 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, wellIn radiology, it is generally necessary for the request to include clinical information relevant to the purpose of the request, to enable the optimal choice, and interpretation, of the examination. It is also frequently necessary that the request contain information relevant to safety issues that may arise from performance of the test, such as contrast allergies, renal disease, etc.
The use case here focuses on widely-available, well-standardized methods that will support the secure access to electronic laboratory orders and radiological requests 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.
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 Royal College of Pathologists of Australasia (RCPA) has developed a number of policies around safety in requesting and reporting 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.
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:
...
Images generated in the course of a radiological procedure are not sent in an HL7 message. Depending on the referrer’s requirements, and local technical capabilities, images may be made available on traditional analogue film (rapidly becoming obsolete), portable digital media, or, increasingly, in digital form via an online electronic portal.
Referral messaging covers clinical referral between clinicians and hospitals, as well as hospital discharge and includes a patient history summary suitable for constructing a Virtual Medical Record for use in decision support and can include any pathology/radiology/diagnostics reports relevant to the referral. It also includes a Medication summary.
This document tries to provide coverage for all laboratory and radiological 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. Similarly, the Royal Australian and New Zealand College of Radiologists has defined minimum requirements for the content of referrals and reports. Standardised terminology for radiological procedures is being developed, and will be progressively implemented throughout the sector.
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 and radiology 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 or clinical referral from an appropriate requesting provider or organisation to the testing/consulting source and the transmission of the result from the testing source or clinician 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 organisations 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 populationsmore automated decision support for patient healthcare, as well as more automated public health surveillance of populations.
- Use of consistent specifications across Laboratory/Radiology/Clinical usage. The specification of segment usage and display rules is common to all message types allowing documents to be carried in multiple message types (ORU^R02 or REF^I12) and displayed/processed using common logic in receiving software. This permits the packaging of reports (laboratory/radiology/clinical) for the purpose of referral messaging with no loss of atomic data, identifiers or terminology, preserving the potential for decision support and allows consistent result filing and display by the receiver.
1.4 Conventions
This guide adheres to the following conventions:
...
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 AttributesAnchor table1-1 table1-1
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.length exceeds the maximum recommended length identified in this specification. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length (See HL7 International V2.4 Section 2.7.5, “Repetition”). Each occurrence of a repeating field may contain the number of characters specified by the field’s maximum length. (See HL7 International V2.4 Section 2.7.2, “Maximum length.”) |
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. RE – Required, but can be empty. O – Optional. C – Conditional. CE – Conditional, but may be empty. X – Not used for this profile. - - 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.
| Anchor | ||||
|---|---|---|---|---|
|
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. |
...
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 usage 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:
...
“SHOULD NOT” or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior behaviour described with this label.
...
- HL7 V2.4 - Health Level Seven Standard Version 2.4: Health Level Seven Inc., Ann Arbor 2000 – www.hl7.org
- LOINC® - Logical Observation Identifier Names and Codes, Users Guide, Indianapolis: Regenstrief Institute - www.regenstrief.org/medinformatics/loinc/
- METeOR - AIHW 2010b. Metadata Online Registry (METeOR), Canberra: AIHW. Viewed 11 October 2011 Viewed 7 August 2018 – http://meteor.aihw.gov.au/content/index.phtml/itemId/268110
- RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies – http://www.freesoft.org/CIE/RFC/1521/
- SNOMED CT[1]® CT® - Systematized Nomenclature of Medicine Clinical Terms, International Health Terminology Standards Development Organisation, Copenhagen, Denmark - http://www.ihtsdosnomed.org/
- NPAAC - Requirements for Information Communication (Thrid Third Edition, 2013) National Pathology Accreditation Advisory Council - http://www.health.gov.au/internet/main/publishing.nsf/Content/health-npaac-docs-InfoComm.htm
- APUTS - Australian Pathology Units and Terminology Standards and Guidelines v2.3, 2016. The Royal College of Pathologists Australasia - https://www.rcpa.edu.au/Library/Practising-Pathology/PTIS/APUTS-Downloads
AS 4700.2-2012 - Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and diagnostic imaging (diagnostics) - http://infostore.saiglobal.com/store/Details.aspx?ProductID=1602624
- HB 262 (Rev)-2012 - Guidelines for messaging between diagnostic providers and health service providers - http://infostore.saiglobal.com/store/Details.aspx?ProductID=1507388
- AS 4846:2014 Person and provider identification in healthcare - https://infostore.saiglobal.com/en-au/Standards/AS-4846-2014-1753860/
...
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 (Informative). 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.
...
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. e.g. 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 e.g. \.br\ replaces a line break in the original text.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
ORU^R01 Unsolicited Observation Message
MSH Message Header
{
[PID Patient Identification
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 |
...
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 e.g. Line 7 "718-7^Haemoglobin^LN") and a data type, in this case mostly Numeric(NM).
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 |
1.8 ACKNOWLEDGEMENT PROCESSING
The International HL7 standard specifies two levels of acknowledgement processing: Original and Enhanced Modes.
...
(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 Australian HL7 standard requires the use of Enhanced Mode Acknowledgment and this is described in 8 Acknowledgement.