Sponsored by:

The Royal College of Pathologists of Australasia (RCPA)/HL7 Australia

HL7 Australia Orders and Observations Co-chairs:	Michael Legg, Michael Legg and Associates Andrew McIntyre, Medical Objects
Editors

Questions or comments regarding this document should be directed to Michael Legg at Michael Legg michael.legg@mlanda.com.au

Copyright © 2016 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. ((Need to check : HL7 Australia copyright statement))

IMPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it.

To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.

A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Table of Contents ((to be developed))

Index of Tables (( To be developed))

Table of Figures ((To be developed))

1.Introduction

The HL7 Version 2.4 Implementation Guide: Electronic Laboratory Ordering and Reporting, Release 1 is the version of the HL7 Lab Result Message. The use case 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 ordered, referred and historical lab results. Ordering clinicians receive lab test results as a response to an order by having the test results sent either directly to the clinician’s EHR system (local or remote) or to another clinical data system in support of the provisioning of historical results.

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 for the use of terminology and the transmission of data. These policies have been incorporated into this document.

1.1 Purpose

This guide contains the necessary specifications for laboratory orders and results reporting in Australian healthcare using the HL7 V2.4 protocol.

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

1.1.1 Message Element Attributes

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

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 apples 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 section C.3.1 – Usage for documentation on how usage has been implemented in this guide. In this implementation guide, usage has been divided by actor. This guide documents four separate actors: ((Check this content - will need to be updated)) Lab Result Sender ELR Receiver NHSN Receiver Lab to EHR Receiver Only the ELR Receiver actor is considered “Normative” in this guide. The other actors and the related profiles are provided as informational only. These non-normative usage columns have a grey background.[DMc1] See section 3.1 ((Check cross references)) for additional information about the various actors documented 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 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 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 ((Check cross references))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.

Note: In the tables throughout this document, Yellow = This Interoperability Specification does not support the use of this item. This corresponds with the Usage code “X”.

1.1.1.0 Usage Conformance Testing Recommendations

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

Table 1?2. Usage Conformance Testing Recommendations

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.1 Relevant Documents

1.1.1 Referenced Documents

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 – 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]® Systematized Nomenclature of Medicine Clinical Terms, International Health Terminology Standards Development Organisation, Copenhagen, Denmark www.ihtsdo.org

1.1.2 Key Australian Pathology Documents

NPAAC - Requirements for Information Communication (Thrid 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

[1] SNOMED CT® is a registered trademark of the International Health Terminology Standards Development Organisation

1.1 Key Words (( copied from V251_IG_SIF_LABRESULTS_R1_DSTUR2_2015SEP.pdf))

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 21192. The following definitions are excerpted from the RFC:
“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] http://www.ietf.org/rfc/rfc2119.txt

1.1 Important notes for pathology messaging

((Items 1-7 have been rewritten; however items 8 onwards need to be reviewed as they are a copy from the SA documents.))

Pathology message generators and receivers should be aware of the following important notes:

1) Pathology Information Transfer (PIT) protocol is not to be used in pathology messaging. Guidance is provided for display formats that replace PIT including XHTML, RTF, PDF or HL7 text – refer to section. ((Refer to appropriate appendices))

2) Examples and details illustrating the content, context and structure relevant to Australia are detailed in section xxxx ((to be updated))

3) Compliance, Conformance and Accreditation items for pathology messaging are included in this document and are being introduced to the NPAAC Guidelines.
Conformance items are marked within a box and are bold titled.

4) Guidance in the use of HL7 is given in the secure message delivery specification AS 5552-2013.

5) Some standard HL7 tables are user-defined. The tables and relevant values have been migrated to be contained in this Standard and Guideline and will be reviewed and updated as appropriate by the HL7 Australia Pathology Working Group.

6) All data is in ASCII display format (ox20 to 0x7E) with the one exception of segment terminator, which is carriage return (0x0D). Any references to hexadecimal representations relate to the ASCII form and not EBCDIC.

7) Important:
There is not necessarily a strict one-to-one relationship between the tests/panels that are ordered and the sets of results that are returned. Content-wise, what has been ordered is completed but this may not be so contextually. For example, if four distinct tests/panels are ordered then the results may be rationalized into only two or three sets for reporting purposes.

8) Therefore, results messages will be generated using a standard methodology which allows for systems that require a one-for-one match between ordered panels and resulting panels. See Clause 13.22 ((will need updating)) , Sending results.

9) With the introduction of Healthcare Identifiers it is important to note that when using a HPI-O the actual testing laboratory needs to be known and not just the organisation that the testing laboratory belonged to. It is a NATA/NPAAC guideline that the testing laboratory be indicated.

10) The example messages demonstrate the printed form of the message and are included to facilitate the reading of the document. The optimal message examples are electronic versions which can be validated in an appropriate message testing facility. Electronic versions of the messages can be more frequently updated than a complete review of this Standard and Guidelines. Therefore the example messages will be retained in the document for readability, but the source of truth for these messages will be the trusted messages stored at the Australian Healthcare Messaging Laboratory (AHML) (http://www.ahml.com.au/). Each example message that is stored at the AHML will be indicated in the text preceding the message. Refer to the electronic versions retained at AHML for updated Standard and Guidelines message examples and other example messages. ((Check with ML as to whats happening with electronic message examples.))

1.Messaging Infrastructure

1.1 Messaging Framework

1.1.1 Overview

A HL7 V2 message has a number of logical components and rules to enable transmission of data records. The segment contains the details to describe a single type of information. The structure of each segment type enables the different aspects of clinical information to be processed in a standardized way. For example, specific segments contain information for the patient (PID), order information (ORC) and results (OBX).

The combination of these segments in a standardized structure forms the HL7 message.

Where the essential concepts are:

(a) Messages are comprised of segments.

(b) Segments are comprised of fields.

(c) Fields may be divided into components.

(d) Components may be divided into sub-components.

A message segment is divided into fields with a field separator character (|)—the vertical bar (hex 7C).

1.1.2 Delimiters

This profile supports the use of the normal HL7 delimiters. It is recommended, but not required, that implementers be able to send messages using the standard HL7 delimiters. Receivers must be capable of receiving any legal delimiters that are sent in a particular message instance.

This table is pre-adopted from the HL7 Version 2.6, which offers information regarding best practices. The intent has not changed from Version 2.4. Note that this implementation guide includes additional constraints and explanations for the entries.

Table 2?1. Delimiters

Table 2?1. Delimiters
Delimiter	Required Value	Encoding Character Position	Description
Segment Terminator	<cr>	-	Terminates a segment record. This value cannot be changed by implementers. Additional Constraints and Explanation: The <cr> denotes the ASCII-013 (0x0D) carriage return character. There is a common misunderstanding that a linefeed character, or carriage return followed by a linefeed character, is allowed also. Neither HL7 nor this profile allows either of these two as part of the segment terminator. Only the ASCII-013 (0x0D) carriage return is allowed.
Field Separator	\|	-	Separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in each segment. Additional Constraints and Explanation: It is recommended that senders use ASCII-124 (0x7C) , the vertical bar (\|) character, as the field separator.
Component Separator	^	1	Separates adjacent components of data fields where allowed. Additional Constraints and Explanation: It is recommended that senders use ASCII-094 (0x5E) , the caret (^) character, as the component separator.
Repetition Separator	~	2	Separates multiple occurrences of a field where allowed. Additional Constraints and Explanation: It is recommended that senders use ASCII-126 (0x7E) , the tilde character (~), as the repetition separator.
Escape Character	\	3	Use the escape character with any field represented by an ST, TX or FT data type, or for use with the data (fifth) component of the ED data type. If no escape characters are used in a message, this character may be omitted. However, it must be present if subcomponents are used in the message. Best practice is always to include this character. Additional Constraints and Explanation: It is recommended that senders use ASCII-092 (0x5C), the backslash (\) character, as the escape character.
Subcomponent Separator	&	4	Separates adjacent subcomponents of data fields where allowed. If there are no subcomponents, this character may be omitted. Best practice is always to include this character. Additional Constraints and Explanation: It is recommended that senders use ASCII-038 (0x26), the ampersand (&) character, as the subcomponent separator.

ALI-xx ((Conformance point number - to be updated)) Conformance item: Only the standard delimiters ‘^ ~ \ &’ MUST BE used.

((Note ALI = Australian laboratory implementation conformance point))

1.1.1 Null Values In Fields Vs. Components

In HL7, a null value for a field is indicated by paired double quotes (|""|). The null value applies to the field as a whole, not to the components/subcomponents of the field. A null field value indicates that the receiver of the message should delete the corresponding set of information from the data store. For this implementation guide ((what is this document going to be referred to as?? - need to be consistent throughout document)) , null values within components and subcomponents are meaningless. For example, |lastname^firstname^""^^^^L| would be interpreted exactly as |lastname^firstname^^^^^L|. The components and subcomponents of a data type constitute a snapshot of the data. The set of data represented by the data type is handled as a complete set; therefore, using the null value to indicate a missing component or subcomponent is unnecessary.

‘No data’ is sent as an empty field ||. Leave the receiving field unchanged.

Where all fields are not populated then trailing field separators are not required to be included.

1.1.1 Lengths

For HL7 V2.4 there are no restrictions on the message length (refer to section 2.4, section 2.4, 2nd (c)); however in Australia for practical reasons it has been agreed that the total message size should be less than or equal to 16 MB. For transmitted messages greater than 16 MB there should be no expectation that it will be delivered, unless there are existing trading partner agreements in place.

ALI-x ((Conformance point number - to be updated)) : Message transmitters and receivers MUST be able to transmit and accept a message of up to 16 MB.

1.1 Segment names ((taken from section 4.4 of combined document and the edited from HL7 Intl manual))

The data fields are combined into logical groupings called segments. Segments are separated by segment separator characters. Each segment begins with a
three-character literal value that identifies it within a message and is terminated by a carriage return (0x0D).

Individual data fields are found in the message by their position within their associated segments. A segment contains only part of the information required for a message. Therefore a segment is only valid and only has meaning when combined with other related segments into a complete HL7 message. A new segment may have a different segment ID or the same segment ID as the previous segment with an incrementing ‘set-ID’ (read sequence) number field.

These are the HL7 segments that may be used:

Table 4?4. ((table number to be updated )) HL7 Message Segment Names
Code	Definition	Notes
MSH	Message header
MSA	Message acknowledgment
PID	Patient identification information	(demographics)
PV1	Patient visit information	(episode specific information)
IN1	Insurance	(used for health insurance)
GT1	Guarantor	(if not the same person as the subject of care)
AL1	Allergy	(allergies)
ORC	Common order information	(order header details, i.e. Request Order ID)
OBR	Observation request information	(request/result header (test/procedure) information)
OBX	Observation results	(result detail lines)
ERR	Error message	(convey a text message relative to the error)

NOTE: If an adverse reaction is required to be recorded an OBX segment should be used.

When messages are transmitted using files then the messages may be required to be enclosed within the following segments:

Table 4?5. ((table number to be updated )) HL7 Message Segments required for enclosing Messages Transmitted Using Files
Code	Definition	Notes
FHS	File header	May be omitted
BHS	Batch header	May be omitted
	Messages here
BTS	Batch trailer	Omitted if BHS is omitted
FTS	File trailer	Omitted if FHS is omitted

The following segments are not used:

Table 12?6 ((to be updated)). HL7 Message Segments NOT USED
Code	Definition	Notes
NTE	Additional notes	Must not be used. Compliant systems will ignore NTE segments. Use result comments see Clause 13.37 ((to be updated)).
Zxx	User defined segments	Must not be used. None are defined in this Handbook as they are not needed. A pathology provider cannot send Z segments and the receiver should ignore them to be compliant (See Conformance Statement HL7v2.4 Australian Pathology Implementation Guide Standard.20). Any message that used a Z segment would be noncompliant. Compliant systems will ignore Z segments.

Further detail on the composition and sequence of the segments is provided in the following sections.

1.1 Message format

This is a description of how segments are combined to produce a valid HL7 message.

Message segments can be required (mandatory), optional and/or repeating.

LEGEND:

XXX	Required
[XXX]	Optional
{XXX}	Repeating

Brackets may be nested.

NOTE: ‘Optional’ means it is not mandatory for the segment to be always present. However where it is necessary to be present then it is mandatory. For example: When the subject of care services are to be billed to a medical fund then the IN1 segment must be included.

Following is an illustration of an ORM (order message) message format:

Table 4?7 ((to be updated)) . HL7 ORM (order message) Message Format
Code	Definition	Notes
MSH	Message header	(required)
PID	Patient identification	(required)
[ PV1 ]	Patient visit	(optional)
[ IN1 ]	Insurance	(optional)
[ GT1 ]	Guarantor	(optional)
[{AL1}]	Allergy	(optional and repeating)
{	Start order group information	(repeating order group start)
ORC	Common order	(required)
[
OBR	Order detail	(required)
[{OBX}]	Observation/result detail	(optional and repeating)
]
}	End order group information	(repeating order group end)

NOTES:

This is a generalized format. See Clauses 4.2 ((to be updated)) and 4.3 ((to be updated)) for a more specific definition of the segments required in particular messages.
The PV1 segment is included for financial detail.

The preferred message formatting rule is:

(a) The OBR segment relates to one discrete panel or test code. The subject of care episode may involve several discrete tests. For orders this requires an {ORC-OBR} pair for each group ordered. For results there will be one OBR per panel of results.

(b) Each OBX segment relates to an individual analyte or component of a structured report or question/answer for each discrete panel, or in the context of orders, it will carry any clinical information required for interpretation of the result.

The ‘test results’ will contain as many OBX segments as are required to report the results. In the case of narrative-type results the complete result may be included in a single OBX segment with embedded text formatting control sequences.

NOTES:

It is recommended that separate episodes be transmitted as separate HL7 messages.
As part of the control mechanism of HL7 a unique ‘message control number’ is sent as part of the MSH segment. If several subject of cares or different subject of care episodes are included within a single message and one is rejected then by definition all must be rejected as there is a single ‘message control number’ for that transmission.

For orders that require a subject of care-specific interpretation of the pathology results by a knowledgebase, test results and order information for previous results may be provided in the same HL7 order message as supporting information.

This implies that one message will contain the orders/results for one subject of care. If there are several sets of orders to request or results to report which originate from a single visit for a subject of care then they can all appear in the same message. Conversely if the same subject of care has other results to be reported from a different visit then use a new message as the Filler Order Number will be different.

1.2 Field length

The recommended maximum length of a field is stated in AS 4700.2.

1.1 Data Types

1.1.1 Introduction

((DMc note: change all instances of the term "Clause" to the term "Section" as per HL7 rather than SA)) Clauses 4.2 to 4.30 ((to be updated)) define each of the field data types used in message segments. These are the main data types required and their use should conform to these rules.

The rules are generally standard HL7 with formatting/content as per AS 4700.1.2.4—2014. ((need to refer to HL7 V2.4 international))

HL7 protocols are maintained with exceptions based on:

(a) HL7 protocol allows user definition or ‘agreement between parties’; and

(b) AS 4700.X variations.

All components are defined but trailing ‘not used’ components are truncated.

Where examples are shown, lower case may be used for readability.

Field values may be upper case, lower case or sentence case.

1.1.2 CD – Channel definition

This data type is used for labelling of digital waveform data e.g. graphs, echo cardiographs.

Table 4?8((to be updated)). Channel Definition (CD) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Channel identifier	CM	Identifies the channel, consisting of a channel number and a channel name (optional).
2	Waveform source	CM	Identifies the source of the waveform connected to the channel.
3	Channel sensitivity/units	CM	Defines the channel sensitivity (gain) and the units in which it is measured.
4	Channel calibration parameters	CM	Consists of three optional sub-components, which define corrections to channel sensitivity, baseline, and channel time skew which may be derived from a calibration procedure.
5	Sampling frequency	NM	The sampling frequency in hertz of the channel
6	Minimum/maximum data values	CM	The minimum and maximum data values which can occur in this channel in the digital waveform data

The CD data type defines a recording channel which is associated with one of the values in each time sample of waveform data. Each channel has a number (which generally defines its position in a multichannel display) and an optional name or label (also used in displays). One or two named waveform sources may also be associated with a channel (providing for the use of differential amplifiers with two inputs).

1.1.3 CE – Coded element

This data type transmits codes and text associated with the code.

Table 4?9((to be updated)). Coded Element (CE) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Identifier	ST	The code for the item
2	Text	ST	Item description
3	Name of coding system	IS	Coding system being used
4	Alternate identifier	ST	An alternative code
5	Alternate text	ST	An alternative description
6	Alternate coding system	IS	An alternative coding system

The CE data type is generally used in areas like item level analyte descriptions.

Name of coding system must identify the source of the coding system. Use of 'L' is insufficient in this instance as the same item could be coded identically by different sources. The required format is:

NATA<NATA#><-version#>	The version number is optional.
NATAx{xxx}[-n{nnn}]	Where x{xxx} is the NATA number for the laboratory and n{nnn} is the version number of the item.

Both xxxx and nnnn are variable length and need only contain significant digits.

The ‘-’ (dash) separator delimits the items.

Example: NATA2184-3 version 3

Example of CE data type:

|14682-9^CREATININE^LN^Cr^CREATININE^NATA1234-007|

NOTE: NATA1234-007 denoting Local coding system, LN denoting LOINC coding system.

1.1.4 CM – Composite

This data type is a combination of other data types. It is used for MSH-9 Message Type and OBR-15 Specimen Source only.

No new CMs are allowed after HL7 version 2.2. The CM data type is maintained strictly for backward compatibility and may not be used for the definition of new fields.

1.1.5 CX – Extended composite ID with check digit

This data type is used for a complex identification number requiring certification.

Table 4?10((to be updated)). Extended Compostite (CX) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Identifier	ST	Primary ID
2	Check digit	ST	Check digit
3	Check digit scheme	ID	Check digit scheme. See HL7 Table 0061
4	Assigning authority	HD
5	Identifier type code	IS	Indicates what the value represents. See HL7 Table 0203
6	Assigning facility	HD

This data type is used in PID and PV1 segments where some subject of care identification such as Pension Card Number or Health Card number is used.

Refer to Clause 13.11 ((to be updated)) Patient identifiers for a complete discussion. ((query include the HB 262 blurb here))

Example:

\|AB1234567\|	A subject of care identifier of unknown origin
\|SMITHAB123\|	Internal Surgery Reference ID for subject of care
\|326154^2^M10\|	Check Digit via Modulus 10
\|4009887514^^^AUSHIC^MC\|	Medicare Number Include the card number as part of the primary ID.
\|8003608833357361^^^AUSHIC^NI\|	Individual Healthcare Identifier (IHI)

1.1.6 DT – Date

Format: YYYY[MM[DD]]

In prior versions of HL7, this data type was always specified to be in the format YYYYMMDD. In the v2.4 and future versions, the precision of a date may be expressed by limiting the number of digits used with the format specification YYYY[MM[DD]].

Example:

|20070805|

|201403|

1.1.7 ED – Encapsulated data

This data type transmits encapsulated data from a source system to a destination system. It contains the identity of the source system, the type of data, the encoding method of the data, and the data itself.

Table x-xx ((to be updated)). Coded Element (CE) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Source application	HD	A unique name that identifies the system which was the source of the data (may be left blank)
2	Type of data	ID	An ID data type that declares the general type of data.
3	Data subtype	ID	An ID data type declaring the format for the data of sub-component <main type>.
4	Encoding	ID	The type of encoding used to represent successive octets of binary data as displayable ASCII characters. See HL7 Table 0299
5	Data	ST	The data, using legal characters of the ST data type, encoded according to the method specified in component #4

The ED data type is used to convey images (see Clause 13.16) ((to be updated & include content here)) and display formats for reports (see Clause 13.15 and Appendices D and E) ((to be updated)). Refer to Appendix F ((to be updated)) for an example XHTML display segment using an ED datatype.

1.1.8 EI – Entity identifier

The entity identifier defines a given entity within a specified series of identifiers. The specified series, the assigning authority, is defined by components 2 through 4. The assigning authority is of the hierarchic designator (HD) data type (highlighted in bold) ((query delete the highlighted in bold)), but it is defined as three separate components in the EI data type, rather than as a single component as would normally be the case. This is in order to maintain backward compatibility with the EI’s use as a component in several existing data fields.

Table x-xx ((to be updated)). Entity Identifier(EI) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Entity identifier	ST	The first component, <entity identifier>, is usually defined to be unique within the series of identifiers created by the <assigning authority>, defined by a hierarchic designator, represented by components 2 through 4. (See Section 2.9.21, “HD - hierarchic designator”.)
2	namespace ID	IS	The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the data. User-defined Table 0363 – Assigning authority is used as the HL7 identifier for the user-defined table of values for this component.
3	universal ID	ST	The HD’s second component, <universal ID> (UID), is a string formatted according to the scheme defined by the third component, <universal ID type> (UID type). The UID is intended to be unique over time within the UID type. It is rigorously defined. Each UID must belong to one of the specifically enumerated schemes for constructing UIDs (defined by the UID type). The UID (second component) must follow the syntactic rules of the particular universal identifier scheme (defined by the third component).
4	universal ID type	ID	The HD's third component governs the interpretation of the second component of the HD. If the third component is a known UID refer to HL7 Table 0301 - Universal ID type for valid values, then the second component is a universal ID of that type.
	((?? how to remove this bottom row))

Conformance Guide: Entity Identifier

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: When used as a result or request identifier the NamespaceID and/or Universal ID MUST be populated (in addition to the Entity Identifier) to ensure uniqueness of the complete EI instance across organizations.

Example:

|817634^QML^2184^AUSNATA|

Most likely used in Placer and Filler Order Number|

1.1.9 FC—Financial class

This data type indicates a classification for billing purposes. It is used for PV1-20 Financial Class field only.

Table 4?12((to be updated)). Financial CLass (FC) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Financial Class	IS	Look up on user Table 0064
2	Effective date	TS	Contains the effective date/time of the person’s assignment to the financial class specified in the first component.

1.1.10 FT—Formatted text

This is derived from the string data type with embedded formatting codes.

For further information on use of FT, consult Appendix D and Clause 13.15 ((to be updated)), Display format of results.

1.1.11 HD—Hierarchic designator.

This data type is a multi-level field definition composed of three parts.

Table 4?13((to be updated)). Hierarchic designator (HD) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Namespace ID	IS	Some code or identifier.
2	Universal ID	ST	A description of the identifier or source of the identifier.
3	Universal ID type	ID	Authority who assigned this code to this description. Refer to HL7 Table 0301 - Universal ID type ((query remove link)) for valid values

The first component can exist by itself.

If the second exists then the third must exist—and vice-versa.

One use is placer/filler site identification.

Example:

|LAB^1234^AUSNATA|

NOTE: Be aware that ‘This means that if all components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components.’— HL7 V2.4, Section 2.9.21.

1.1.12 ID—Coded values for HL7 tables

This is a ST data type field used as an index to valid values from a standard HL7 defined table.

See Clause 14 ((to be updated or modified if the HL7 tables are removed or moved to another source)), Identified tables and occurrences for Sex Table 0001.

NOTES:

1 ID can only be used for HL7 defined tables.

2 Refer IS data type for user-defined tables.

1.1.13 IS—Coded values for user-defined tables

This is a ST data type field used as an index to valid values from a user-defined table.

See Clause 14, Identified tables and occurrences for Patient location Table 0260.

1.1.14 NA—Numeric array

This data type is used to represent a series (array) of numeric values, each one having a data type of NM, e.g. graph points from an echo cardiograph. A field of this type may contain a one-dimensional array (vector or row) of numbers. Also, by allowing the field to repeat, a two-dimensional array (table) of numbers may be transmitted using this format, with each row of the table represented as one repetition of the field. Arrays which have one or more values not present may be transmitted using this data type. ‘Not present’ values are represented as two adjacent component delimiters. If the absent values occur at the end of a row, the trailing component delimiters may be omitted. If an entire row of a table has no values, no component delimiters are necessary (in this case, there will be two adjacent repetition delimiters). The maximum number of values in one repetition of an NA format field is determined by the maximum field length.

Examples:

\|125^34^-22^-234^569^442^-212^6\|	vector of 8 numbers
\|1.2^-3.5^5.2~2.0^3.1^-6.2~3.5^7.8^-1.3\|	3 x 3 array of numbers
\|^2^3^4~5^^^8~9^10~~17^18^19^20\|	5 x 4 array of numbers with the values in positions (1,1), (2,2), (2,3), (3,3), (3,4), (4,1), (4,2), (4,3), and (4,4) not present

1.1.15 NM—Numeric

This data type is a number represented by a string of digits with leading +/- and an optional decimal point. No other non-numeric characters are allowed.

Examples:

|123|, |-12|, |156.7248|, |1.0|, |0.27|, |0.0001|

NOTES:

1 A value like >1000 or <10 is not numeric type.

2 Use SN (structured numeric) data type in this situation (see Clause 10.19).

3 Do not use ST.

4 Used for OBX segments where the data is numeric.

5 See NM (HL7 V2.4, Section 2.9.28).

1.1.16 PL—Person location

This specifies a subject of care location within a healthcare institution.

There is one reference in segment PV1 where it is used to indicate the ward/bed for an inpatient.

It is peculiar to a hospital environment and may require user-defined tables (IS type) if used in this context.

Table 4?14((to be updated)). Person location (PL) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Point of care	IS	Ward Code
2	Room	IS	Room Identifier
3	Bed	IS	Bed Number
4	Facility	HD	Facility Code
5	Location status	IS	if required
6	Person location type	IS	if required
7	Building	IS	if required
8	Floor	IS	if required
9	Location Description	ST	Hospital Name

Currently, there is no single Australian register of healthcare locations. Work on a register is underway and currently there are various identifiers such as the government provider numbers for private hospitals that may be used.

This item will have to be determined on a site-negotiated basis as different formats will most likely be used.

Example:

|W4C^R3^B1^TWH^^^^^WES|

1.1.17 RP—Reference pointer

This data type transmits information about data stored on another system. It contains a reference pointer that uniquely identifies the data on the other system, the identity of the other system, and the type of data.

Table 4?15((to be updated)). Reference pointer (RP) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Pointer	ST	A unique key assigned by the system that stores the data.
2	Application ID	HD	A unique designator of the system that stores the data
3	Type of data	ID	An ID data type that declares the general type of data.
4	Subtype	ID	An ID data type declaring the format for the data of subcomponent <main type>.

NOTE: See also HL7 V2.4, Section 2.9.37.

Usage Note:

When using RP with a URI/URL, the address is broken into two parts, an ‘application ID’ which is the portion of the address that identifies the application, and the ‘pointer’ which identifies the particular data. These parts are placed in component 2 and component 1 respectively. In general, the address is composed of scheme | server | path | query; the scheme and server are part of the application ID, and the query is part of the pointer. The path may be part of either. In practice, it doesn’t matter, as the full address is simply component 2 + component 1. The following two examples (from HL7 V2.7 Section 2.A.65.2) illustrate this:

Example 1:

A CDA document accessed by FTP at

ftp://www.saintelsewhere.org/cdasvc/u28864099/s9076500a/e77534/d55378.xml:

|/cdasvc/u28864099/s9076500a/e77534/d55378.xml^&ftp://www.saintelsewhere.

org&URI^text^x-hl7-cda-level-one|

Example 2:

An image on a web server at:

http://test/synapsestudy.asp?path=/All%20Studies/AccessionNumber=2011F0001000-1:

|?path=/All%20Studies/AccessionNumber=2011F0001000-1^ http://test/synapsestudy.asp&URI^IMAGE^JPEG|

1.1.18 SI—Sequence ID

This data type is a non-negative number in the form of a numeric (NM) field.

This item is used in the ‘Set-ID’ fields of PID/PV1/IN1/GT1/OBR/OBX segments.

1.1.19 SN—Structured numeric

This data type is used to express qualified numeric values. This type allows receiving systems to store the components separately—allowing the use of numeric fields in a database.

It is used for results that are below or above a cut-off point or a ratio or a range:

Examples:

<20		Below (or above) a critical point
1:6		Ratio
100-200		Values are inclusive: 100–200 means including 100 and including 200.
Table 4?16((to be updated)). Structured numeric (SN) Data type Components
Component Number	Component Name		Component Data Type	Notes
1	Comparator		ST	> or >= or < or <= or = or <>. The default is ‘=’.
2	Number		NM	Mandatory number
3	Separator		ST	- or + or / or . or :
4	Number		NM	Number or null

Examples:

Value	Interpretation
\|>^100\|	greater than 100
\|^100^-^200\|	equal to range of 100 through 200
\|^1^:^128\|	ratio of 1 to 128, e.g., the results of a serological test
\|^2^+\|	categorical response, e.g., occult blood positivity

1 The separator value ‘.’ is not recommended for use as it implies a decimal point.NOTES:

2 No examples can be found of its use in this context. ((query if this item can be deleted))

3 The use of 1.2:3.5 is ambiguous as both . and : can be separators.

4 Only single occurrences of the separator can be accommodated within the specification.

5 Reference Range (Item #575) is not data type SN. ((what is "item #575"??))

6 Results which are date and time are not SN.

7 See HL7 V2.4, Section 7.4.2.2 for other discussion.

1.1.20 ST—String

This data type is a left justified string of characters—no leading or trailing spaces.

All data is in ASCII display format (0x20–0x7E)

It is used for small fields (<200 characters). Use FT for longer strings.

Example:

|this is can be any string data|

1.1.21 TM—Time

Time conforms to HL7 protocol: HH[MM[SS[.SSSS]]][±ZZZZ])

Example:

\|0825\|
\|061215.25+1000\|
\|1015+1000\|
\|215923\| 1.1.22 TQ—Timing quantity This data type is most likely used for indicating when a service was performed. It is used in the ORC and OBR segments to hold the date, time and priority of a diagnostics order (request). See HL7 V2.4, Section 4.3. This is a complex data type that has been reduced to the minimum format for the Australian situation.
Table 4?17((to be updated)). Timing quantity (TQ) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Not used
2	Not used
3	Not used
4	Date and Time	TS	Format is YYYYMMDDHHMM
5	Not used
6	Priority	ST	R—routine (default) S—stat (urgent)

Example:

|^^^200710230915^^S|
|^^^200711071020|

urgent
routine

1.1.23 TS—Time stamp

Date:	YYYYMMDD
Time:	HHMM[SS]
Time Stamp:	YYYY[MM[DD[HHMM[SS][.S[S[S[S]]]]]]][±ZZZZ]
	YYYY	Century/year
	MM	Month
	DD	Day
	HH	Hours
	MM	Minutes
	SS	Seconds
	.SSSS	Tenths, hundredths, thousandths, ten-thousandths of seconds
	±ZZZZ	Time zone of sender relative to GMT

Example:

|200709121145|
|20071128142200+1000|

NOTE: Some TS fields may only require the date.

Examples:

Date and Time of Birth where ‘Time of Birth’ is not known: YYYYMMDD

Date of Birth where ‘Day of Birth’ is unknown: YYYYMM

Date of Birth where ‘Day of Birth’ and ‘Month of Birth’ are not known: YYYY

It is highly recommended that the time zone be included in date references. Systems will need to make allowance for daylight saving and cross-time-zone operations.

The HL7 protocol specifies fractions of seconds (to ten-thousandth) for precision and time zones relative to Universal Coordinated Time (previously GMT).

NOTE: All HL7 systems are required to accept the time zone offset. However, its implementation is application specific. The HL7 protocol allows conversion to a common representation for clinical systems where sender and receiver are in different time zones and where daylight saving is in effect.

±ZZZZ is the time zone of sender relative to GMT.

If used then use the time zone value of the sending system.

Example:

199708081430+1000 is 2:30 pm AEST.

In Australia there is a complexity of variations in time standards and time zones within and across the country. Therefore, differences within zones between standard and summer time and across zones are implicit. Sending/Receiving applications may require processes for time zone processing or they can be detected and ignored.

1.1.24 TX—Text

Conformance Guide: Text

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: The TX data type MUST NOT be used.

1.1.25 VID—Version identifier

This data type specifies the HL7 Version being used.

It comprises added definition for country and any variation to the standard version.

Table 4?18 ((to be updated)). Version identifier (VID) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Version ID	ID	from Table 0104
2	Internationalization Code	CE	AUS— see HL7 table 0399 for the 3-character codes as defined by ISO 3166-1:2006 (adopted as AS/NZS 2632.1:2008)
3	International Version ID	CE	Current international version base for this implementation.

Example:

\|2.4\|	This would be interpreted as a US HL7 V2.4 implementation.
\|2.4^AUS\|	The standard Australian implementation of HL7 V2.4
\|2.4^AUS^ISO3166-1\|	Coding System

It is presumed that all Australian implementations are AS 4700 compliant and therefore the |2.4^AUS^ISO3166-1| format should be used. ((query retain complaiance to AS 4700??))

1.1.26 XAD—Extended address

This data type is used for subject of care and doctor address.

Table 4?19((to be updated)). Extended address (XAD) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Street address	ST
2	Other designation	ST
3	City/suburb/town	ST
4	State	ST
5	Post code	ST
6	Country	ID
7	Address type	ID	HL7 Table 0190
8	Other geographic destination	Not used routinely
9	County/parish code	Not used
10	Census tract	Not used

Example:

|26 Lower Terrace^^Eastern Heights^QLD^4123^AUS|

|Coral Reef Hotel^^Rocky Point^Longreach^QLD^4730^AUS^H|

NOTE: Country is specified in HL7 as data type ID and that it should be a three-character code from ISO 3166 (identical to AS/NZS 2632). HL7 V2.4 may be at variance with AS 4590—2006. The HL7 standard usage is preferred.

1.1.27 XCN—Extended composite ID number and name for persons

This data type is used for representing doctor names.

Table 4?20((to be updated)). Extended composite id number and name for persons (XCN) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Identifier number	ST	Provider Number
2	Family name	ST
3	Given name	ST
4	Middle initial	ST
5	Suffix	ST	e.g. Jnr/Snr
6	Prefix	ST	e.g. Mr/Dr
7	Degree	ST
8	Source table	IS
9	Assigning authority	HD
10	Name type code	ID	See Table 0200. If not used legal name is assumed.
11	Identifier check digit	ST
12	Code identifying the check digit scheme employed	ID
13	Identifier type code	IS
14	Assigning facility	HD
15	Name representation code	ID	Not used

Examples:

|1234567P^SMITH^BILL^W^^DR^^^AUSHICPR|

HPI-I |8003619900015717^Smith^John^S^^DR^MD^^AUSHIC^^^^NPI|

1.1.28 XON—Extended organization name

This data type provides a composite name and identification number for organizations eg ORC-21.

Table 4?21((to be updated)). Extended organization name (XON) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Organization name	ST
2	Organization name type code	IS	Legal name, display name – use Table 0204 for suggested values
3	Identifier number	NM
4	Check digit	NM
5	Check digit scheme	ID
6	Assigning authority	HD
7	Identifier type code	IS
8	Assigning facility ID	HD

Examples:

|XYZ Medical Fund^^1234567|

Or

HPI-O:

| XYZ Organisation^L^8003621566684455^^^AUSHIC^NOI|

1.1.29 XPN—Extended person name

This data type is used for representing individual’s names.

Table 4?22((to be updated)). Extended Person name (XPN) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Family name	ST
2	First name	ST
3	Middle initial/name	ST
4	Suffix	ST	e.g. Jnr/Snr
5	Prefix	ST	e.g. Mr/Dr
6	Degree	ST
7	Name type		Not used. Always presumed to be Legal name. See Table 0200.
8	Name representation code		Not used

Example:

|Smith^Bill^W^Jnr^Mr|

|Jones^John^^^Dr|

1.1.30 XTN—Extended telecommunications number

This data type is used for representing the standard format for all telephone numbers.

NOTE:This is standard HL7.

Table 4?23. Extended telecommunications number (XTN) Data type Components
Component Number	Component Name	Component Data Type	Notes
1	Not used	-
2	Telecommunications use code	ID
3	Telecommunication equipment type	ID
4	Email address	ST
5	Country code	NM
6	Area code	NM
7	Phone number	NM
8	Extension	NM
9	Any text	ST

NOTE:For HL7 compatibility the leading component separators are included.

Example:

\|^WPN^PH^^61^7^32615492\|	International phone number
\|^WPN^PH^^^07^32615492\|	Interstate/intrastate phone number
\|^WPN^PH^^^^32615492\|	‘Local area’ phone number
\|^WPN^CP^^^^0412545585\|	Mobile phone number
\|^NET^Internet^J.Douglas@work.com\|	Email address

See note in HL7 V2.4, Section 2.9.55.4. For international use the recommended format is the delimited form using sub-fields 5-9 rather than the structured form of the first field.

1 Healthcare Identification ((similar content to the prev SA doc content - Diagnostic imaging content has been removed))

1.1 Patient (subject of care) identification

ISO/TS 22220:2011, Clause 3.2, defines subject of care as follows: ‘any person who uses or is a potential user of a health care service’, and notes, further, that ‘subjects of care can also be referred to as patients, health care consumers or subjects of care’. In general in this document, the broader term ‘subject of care’, which includes people who are well ‘patients’ under preventative care, is preferred to the term ‘patient’. However, the term ‘patient’ has been retained when it refers to a specific term or where its use is well-established or prescribed, as in HL7 Patient Identification (PID) Segment, or where it is part of an existing document title, for example AS 4700.1.2.4—2014, Implementation of Health Level Seven (HL7) Version 2.4, Part 1: Patient administration.

The PID segment permits transmission of all known subject of care identifiers.

For further information about subject of care identification and business processes, see SA HB 234—2012, Healthcare identifier HL7 implementation guide; also see AS 4846—2014, and AS 4700.1.2.4—2014. AS 4700.1.2.4-2014, contains information and references for healthcare identifiers, and readers are encouraged to refer to this document. ((query refer to these SA documents - all are still current ))

NOTES:

1. Subject of care identifiers may not necessarily be unique.

1.2 Site Identification

Placer and filler sites are specified uniquely by a code contained in the last three components of ORC-2/OBR-2 Placer Order Number and ORC-3/OBR-3 Filler Order Number. (These components of the entity identifier (EI) data type are the equivalent of the three components of the hierarchic designator (HD) data type.)

The second component of the EI data type (first component of the HD data type) can be populated with a composite identifier. Generally, unique identifiers should be chosen from a controlled namespace. The namespace IDs are listed in HL7 User-defined table 0300—Namespace ID; see usage notes against ORC-2 Placer Order Number in Table 8-1. ((ref to "table 8-1" to be checked/updated))

It is suggested that, for local use, a composite identifier comprise sub-components separated by dots.

The first sub-component should indicate the identifier. The second sub-component should indicate the controlled namespace.

Recognized national namespaces should be identified by a code whose format is determined by whether it is a pathology or diagnostic imaging order. National namespaces should start with ‘AUS’, followed by a unique code (e.g. AUSNATA). The identifier within the namespace precedes the namespace code.

For pathology namespaces:

Example: ‘Sussex Pathology^1234567^AUSNATA’, where ‘1234567’ is the NATA number of the laboratory.

Local namespaces should be identified by a unique code, preceded by the identifier.

Example: ‘AYR GP Surgery^AYBR32615492.BRIS^L’

An HD data type with an ISO ‘Object Identifier’ as a unique identifier can be used. The first component refers to the same identity as the second and third component (taken together). The example shows how this can be used to identify entities.

Example: Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID

NOTES:

1. Current Australian namespaces in use are ‘AUSHIC’ (Medicare Australia), ‘AUSDVA’ (Department of Veterans’ Affairs), ‘AUSNATA’ (National Australian Testing Authority) and ‘AUSHICPR’ (Australian Provider Number).

2. All Australian namespaces will be coded as ‘local’ in HL7 terms, unless they are part of an internationally recognized namespace. Namespaces ‘AUSHIC’, ‘AUSDVA,’ ‘AUSNATA’ and ‘AUSHICPR’ are internationally recognized namespaces that reference Australian assigning authorities.

3. The values ‘AUSNATA' and ‘AUSHICPR’ are added to User Table 0363 in HL7 V2.4 (see Appendix C). (( reference location to be updated))

Internet domain names are a suitable controlled namespace identifier where available. Their usage is defined in HL7 V2.4, section 2.9.21.3.

Example: ‘^www.sussexlis.com.au^DNS’

The use of the Healthcare identifiers, including Healthcare Practitioner Identifier—Individual (HPI-I) and Healthcare Practitioner Identifier—Organisation (HPI-O), is described in SA HB 234—2012, Healthcare identifier HL7 implementation guide. Refer to SA HB 234—2012 for further information and examples.

1.2.1 Placer facility or site guidance

The ‘Placer facility or site’ is the surgery, hospital, etc. It identifies the originating site of the order.

Each site requires a unique identifying code to attach to the order number.

Arbitrary assignment of codes by independent operators can result in replication.

Since there is no common identification criteria applied across all placer sites it may be useful to use the first two characters of the town prefixed to the telephone number as a unique identifier for surgeries, e.g. BR32615492. With regard to hospitals, negotiation between users will determine an appropriate site code, e.g. TWH-B for The Wesley Hospital in Brisbane and TWH-S for the Wesley Hospital in Sydney.

Sites should settle on a format for the ‘universal ID’ part and reinforce it with a text description of the practice in the ‘namespace ID code’ with an associated ‘^L’ to indicate that it is a local definition.

The ‘namespace ID’ can exist by itself as a description of the site.

The ‘namespace ID’ and the combination of the ‘universal ID’ and ‘universal ID’ type must identify the same entity.

Example:

	\|AYR GP SURGERY\|	namespace—ID only
OR
	\|AYR GP SURGERY^ay32615492^L\|	namespace—ID with a qualifier (AY for Ayr)
		Component three (^L) is mandatory if component two is used
		Component two is a telephone number from the Ayr area.
OR
	\|2.16.840.1.113883.2.3.99\|	HL7 OID

The Placer Site may be appended to order numbers and the like to provide uniqueness.

1.2.2 Filler facility or site guidance

These are diagnostics providers. It identifies who generates the results.

With the introduction of Healthcare Identifiers it is important to note that when using a HPI-O the actual testing laboratory needs to be known and not just the organisation that the testing laboratory belonged to. It is a NATA/NPAAC guideline that the testing laboratory be indicated. ((? this document requires instead of AS 4700.2 update)) AS 4700.2—201x Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and diagnostic imaging (diagnostics) requires that the NATA Accreditation Number be used as a unique identifier for provider laboratories.

The data type is HD.

Table 5?1. Hierarchic designator (HD) Data type for Filler Facility
Component Number	Component Name	Component Data Type	Notes
1	Namespace ID	IS	Laboratory or diagnostic imaging name
2	Universal ID	ST	NATA laboratory number
3	Universal ID type	ID	AUSNATA
3	Universal ID type	ID	\|LAB-name^NATA laboratory #^AUSNATA\|

Examples:

Assuming NATA laboratory number is 3715 for laboratory name ‘ACME Pathology’ :

|ACME Pathology ^3715^AUSNATA|.

The following examples uses an ISO ‘Object Identifier’ as an UID. The first component and the second and the third component (taken together) refer to the same identity.

MSH-4 |LAB1^1.2.3.4.5.6.7^ISO|

MSH-4 |8003621566684455^1.2.36.1.2001.1003.0.8003621566684455^ISO|

MSH-4 |^1.2.36.1.2001.1003.0.8003621566684455^ISO|

NOTE: The HPI-O may be omitted from the Namespace ID field.

1.3 Message Identifiers

1.3.1 Introduction

Normal HL7 messaging in the context of diagnostics messaging between diagnostics providers (fillers) and external requesters (placers) in Australia requires the data to be transmitted in messages that are most likely to be contained within files. In a non-real time situation this is essential.

Conformance Guide: Message Identifiers ((update to the consistent term to be used for this document))

HL7v2.4 Australian Pathology Conformance Statement Standard Date.XX: The receiver of a message MUST be able to verify that:

(a) This message is for this site;

(b) This message has not been received before; and

(c) No messages have been lost since the last received message.

This is achievable through combinations of the following:

(a) The use of a placer site code field, internal to the MSH segment, will identify the site for the message.

(b) The Message Control ID field, internal to the MSH segment, is the primary message identifier.

(c) A ‘site’ sequence number internal to the FHS/BHS/MSH segments can identify the correct receipt of messages by sequence.

(d) A File Number to identify an individual file from a particular site.

NOTE: The use of multiple sequence numbers may seem complex but it is necessary to control message identification across all sites in a two-way messaging context.

Remember that—

(i) many messages (with many internal message control IDs—to identify each individual message);

(ii) make up a site run (with a site sequence number—to verify receipt of runs );

(iii) make up a single file (with a file number—to identify this file from all other files for this site).

The complexity is associated with diagnostics providers having to control (and differentiate between) the many messages and files to many different sites. Therefore, the following Clauses may be biased towards the diagnostics providers’ viewpoint.

The Message Control ID is described in this Clause while site sequence numbers and file numbering/naming are discussed in Clause 12, Site sequence number and file naming as they are not formally part of the HL7 protocol.

NOTES:

(1) The Message Control ID does not imply any sequencing and cannot be relied upon to act as a check on the receipt of messages from any source.

(2) File Naming (where a number is used as part of the filename) cannot be used to check for the correct sequence of messages.

(3) The Site Sequence Number (if used) is the only valid sequencing check to ensure that all data that is sent to a site is received at that site.

(4) This section deals with Message Control ID only. See Clause 12, Site sequence number and file naming, describes the use and effect of Site Sequence Number and File Naming.

Clauses 5.3.2 to 5.3.7 ((references to be updated)) are provided as a working example of how the necessary level of control can be maintained and managed. It is not mandatory to adhere to the following methodology. However, implementers should familiarize themselves with the reasoning given for each issue and ensure that alternative methodologies provided meet these criteria.

1.3.2 Message control ID

Message control ID is sent in MSH-10 Message Control ID.

When a message is assembled it requires a unique message identifier called the Message control ID. It is generated by the sending system to distinguish this message from every other message that is sent from this site.

NOTES:

1 This is not an order number for a request nor is it a specimen number identifier used by the diagnostics provider. It is a unique internal identifier for this one message originating from a particular site in the context of Diagnostics Messaging.

2 As this is an internal field in a message it will not conflict nor cause problems when two messages with the same Message Control ID are received from two different placers/fillers. All systems should ensure that data tables are not keyed uniquely on this value.

For the receiver of the message the primary use for the ID is to indicate to the sending system which message is being acknowledged.

If a subject of care has results for multiple tests and these are all returned under one Message Control ID (i.e. one MSH with multiple OBRs) then if one result has an error all results in this message are rejected, not just the one in error. This occurs because there is only one message reference (Message Control ID) to which an error can be attached.

However, when multiple results are sent—each with individual MSH segments—then only the result in error is rejected and the others can be accepted because each result has its own Message Control ID.

The suggested format for the Message Control ID is a combination of two, or three, parts.

The first part is a control stub identifying the sending facility.

The second, and optional, part is the date in YYYYMMDD format.

The third part is a counter—an ever-incrementing number starting at 1.

The ‘sending facility’ in this context is not intended to be the form ‘QML^2184^AUSNATA’. It is not correct usage as the ‘AUSNATA’ component is being used out of context. A shortened version is recommended with a compromise being the first component of the sending facility only.

The use of the date in the ID is useful for obvious reasons.

The generalized form is:

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

Example:

qml_20020121.3

snp_20020117.61527

Placers could use their <site code> or <site code>_<date>:

gx_32615492.71

1.3.3 Acknowledgment messages

For ACK messages, the sending system must:

(a) Generate a new Message Control ID for its MSH segment; and

(b) Return the Message Control ID from the received message in the MSA segment.

Message error condition codes: (See HL7 Table 0357) below.

HL7 Table 0357 – Message Error Condition codes (MSA-6)
Code	Definition
0	Message accepted
100	Segment sequence error
101	Required field missing
102	Data type error
103	Table value not found
200	Unsupported message type
201	Unsupported event code
202	Unsupported processing ID
203	Unsupported version ID
204	Unknown key identifier
205	Duplicate key identifier
206	Application record locked
207	Application internal error

Clauses 3.4 to 3.7 describe the general sequence of an Order Placement/Results Delivery process.

The clauses are intended to provide an overview of the messaging and the associated message segments and message types. The actual content and field values and their meaning are not relevant at this time and no significance should be placed on them; they are used for completeness of the messages only to highlight content and the interrelationships of the fields between different message types.

1.3.4 Order[DMc1]

The order from the Placer is identified by a Placer Order Number and Placer Group Number.

The Order Identification information is carried in the ORC segment.

The Testing information is carried in the OBR segment.

Both segments are required to provide all of the necessary information.

The order identifications are an Order ID not a Message Control ID.

Generate a new Message Control ID to transmit the order.

MSH|^~\&|MDW2.8|gx_32615492^GOLD^L||QML^2184^AUSNATA|

199710300935+1000||ORM^O01^ORM_O01|gx_32615492.7|P|2.4^AUS|||AL|AL

(Message Control ID)

PID|

PV1|

ORC|NW|371436-1^gx_32615492^GOLD^L||gx_371436^gx_32615492^GOLD^L|

(Placer Order Number) (Placer Group Number)

OBR|1|371436-1^gx_32615492^GOLD^L||ELFT^Electrolytes Liver Func

ORC|NW|371436-2^gx_32615492^GOLD^L||371436^gx_32615492^GOLD^L|

OBR|2|371436-2^gx_32615492^GOLD^L||FBC^Full Blood Pro

The Message Type in the MSH segment is ORM.

The Trigger Event is O01

The Placer Group Number only occurs in the ORC segment.

There is an ORC/OBR pair for each required test. (Two requested tests in this case)

Field 1 in the OBR segment is a sequence number for panels being ordered.

1.3.5 Order Acknowledgement

The diagnostics provider returns the Placer message control ID in the MSA segment to acknowledge the order.

The acknowledgment is made using the Message Control ID.

If the order is being rejected an error message is returned in the MSA segment. Additional error information may be sent in an associated ERR segment.

The details being acknowledged are returned in the ORC and OBR segments.

MSH|^~\&|QMLPTX|QML^2184^AUSNATA|MDW2.8|gx_32615492^GOLD^L|

199710301123+1000||ORR^O02^ORR_O02|qml_19971129.271|P|2.4^AUS|||AL|AL

? (a new Message Control ID)

MSA|AA|gx_32615492.7

(Message ? Control ID from original Order Message)

PID|

PV1|

ORC|OK|371436-1^gx_32615492^GOLD^L||371436^gx_32615492^GOLD^L|IP|

OBR|1|371436-1^gx_32615492^GOLD^L||ELFT^Electrolytes Liver Func

ORC|OK|371436-2^gx_32615492^GOLD^L||371436^gx_32615492^GOLD^L|

OBR|2|371436-2^gx_32615492^GOLD^L||FBC^Full Blood Pro

The message type in the MSH segment is ORR. The trigger event code for ORR is (O02).

In response to an ORM message, an ORR message is strongly recommended, even where enhanced acknowledgment mode using an immediate ACK is being used.

NOTES:

1 Sending-MSH-5 = Receiving-MSH-3 (MDW2.8)

2 Sending-MSH-6 = Receiving-MSH-4 (gx_32615492^GOLD^L)

3 Sending-MSH-11 = Receiving-MSH-11 (P)

4 Sending-MSA-2 = Receiving-MSH-10 (gx_971129.7)

See HL7 V2.4, Section 2.13.1.2.1.

1.3.6 Results from filler

The diagnostics provider sends the results as an ‘unsolicited’ observation in a new message.

MSH|^~\&|QMLPTX|QML^2184^AUSNATA|MDW2.8|gx_32615492^GOLD^L|
19971030164500+1000||ORU^R01^ORU_R01|qml_19971129.10978|P|2.4^AUS|||AL|AL
PID|
PV1|
ORC|RE|
OBR|1
OBX|1|
OBX|2|
ORC|RE
OBR|2
OBX|1|
OBX|2|
OBX|3|
OBX|4|

The Message Type in the MSH segment is ORU.

The Trigger Event is R01.

1.3.7 Results acknowledgment

The placer returns the filler message control ID in the MSA segment to acknowledge the result.

MSH|^~\&|MDW2.8|gx_32615492^GOLD^L|QMLPTX|QML^2184^AUSNATA|
19971031095500+1000||ACK|gx_32615492.15|P|2.4^AUS
MSA|AA|qml_19971129.10978

The Message Type in the MSH segment is ACK.

NOTES:

1 Sending-MSH-5	= Receiving-MSH-3	(QMLPTX)
2 Sending-MSH-6	= Receiving-MSH-4	(QML^2184^AUSNATA)
3 Sending-MSH-11	= Receiving-MSH-11	(P)
4 Sending-MSA-2	= Receiving-MSH-10	(qml_19971129.10978)

See HL7 V2.4, Section 2.13.1.2.1

1.4 Representation of Healthcare Identifiers in HL7 Version 2 messaging

1.4.1 General

With the release of Healthcare Identifiers it is necessary to specify how these identifiers will be represented. Refer to SA AS 4700.1.2.4-2014 , Implementation of Health Level Seven (HL7) Version 2.4 - Patient administration , Clause 5.2.1, and SA HB 234—2012, Healthcare identifier HL7 implementation guide. ((Query include the detail in this document))

1 ORDER MANAGEMENT (( will need more work especially replacing the workflow diagrams)) ((DI content has been removed))

1.1 Introduction

Order management is the mechanism by which electronic requests for pathology are handled. This Clause details the principles for order management, specifically in relation to order management scenarios, and provides diagrams to represent each of them.

Conformance Statement: Order Management

HL7v2.4 Australian Pathology Implementation Guide Standard 3-1: The receiving system SHALL –

check that the message is addressed to the current receiving system;
check the uniqueness of received message; and
check that no messages have been lost since the last message received.

The system can claim conformance if it passes the listed set of conformance items.

1.2 General order management

1.2.1 General

Orders required for a single episode or request should be sent within one message, i.e. under a single message header (MSH) segment.

The order should be identified by a placer group number (contained in the ORC segment only).

Each ordered test within the episode or request should be placed in a single (ORC, OBR) segment pair and identified by a unique placer order number (contained in both the ORC and OBR segments).

Figure 3-1 ((to be updated)) illustrates the relationship between placer group number (PGN in the figure) and placer order numbers (PON in the figure).

Figure 6?1 ((a new diagram of different format needs to be added)). Relationship between placer group and placer order numbers

1.2.2 Use of group numbers and order numbers

1.2.2.1 General

Placer group number, placer order number and filler order number should be used in a clearly defined way.

To minimize the amount of site-specific negotiation, the recommended methodology is described below. This methodology provides a consistent mechanism to match results to orders where a one-to-one relationship between requested tests and test results is not possible. There are numerous circumstances where this occurs. The method remains consistent when one-to-one relationships do exist.

1.2.2.2 Placer Group Number

ORC-4 Placer Group Number is used to identify a particular episode or request and to link all tests that comprise that request (this is equivalent to an episode or request identifier). All tests from a particular episode or request should have the same placer group number, including add-on tests, reflex/self-determined tests and laboratory department generated investigation requests.

1.2.2.3 Placer Order Number

The placer order number is the order reference number generated by the placer site (surgery, hospital, etc.) when ordering pathology. It is a multi-component field comprising a unique number and the placer site identifier to ensure that the request does not duplicate a request from another site.

A separate placer order number should be used for each test in the episode or request. This allows each item in the episode or request to be individually referenced, especially in situations where part of the order is to be cancelled.

The method for generating a placer order number is to concatenate the placer group number with a ‘counter’ for each test in the request.

1.2.2.4 Filler Order Number

The filler order number is essentially an ‘acceptance or receipt number’ from the pathology provider to acknowledge that an order has been received and accepted. It may be sent when returning results to the placer. It should not be used to link results to orders, as there are instances where more than one filler order number could be generated in response to a single request.

In terms of pathology only, filler order number may equate to the laboratory number assigned to the specimen when it is collected.

Episode numbers are often not unique for each specimen, and in the context of the messages from one laboratory they shall be unique. One method of achieving this is to use the test code and a specimen counter which is appended to the episode number, e.g. episode number 07-1234, which includes three sputum samples and could have specimen numbers such as the following:

07-1234-SPU-1
07-1234-SPU-2
07-1234-SPU-3

Alternatively, if the laboratory is able to assign unique specimen numbers across departments, the test code may be omitted.

1.2.3 Specimen or episode and result identifiers

Historically, results have been identified by the laboratory/accession number. However, in HL7 ‘Orders’, chapter 4, and ‘Observations’, chapter 7, the pathology number is not available until the subject of care presents for specimen collection, which will generally be some time after the order has been submitted. The order and the collection are often two disparate events separated by time and distance.

When the pathology department receives an electronic request it shall respond with a filler order number. If several requests are received for the same episode (same placer group number) then an equivalent number of order responses will be sent.

The pathology department may adopt one of the following two positions:

(a) It may respond immediately to the order with a ‘receipt reference’ as the filler order number. When the subject of care eventually presents either for the specimen to be collected or for an examination, a number is allocated by the pathology department.
This number and the paperwork are linked to the original order, which is then entered against the order, and the order is activated.

(b) It may hold the order and not respond until either the specimen is collected or the subject of care presents and a pathology number is assigned to the specimen or request; it may then use this as the filler order number. The order is activated when the pathology number is entered and an order response can then be sent to the placer using the pathology number as the filler order number.

In an electronic environment, the pathology number is not required by the requestor to link results to an order; the placer group number/placer order number/filler order number should be used for this purpose.

1.2.4 Message conformance

Conformance Statement: Message conformance

HL7v2.4 Australian Pathology Implementation Guide Standard 3-2 ((to be updated)): When used as a result or request identifier, the Namespace ID and/or Universal ID MUST – be populated (in addition to the Entity Identifier (EI)) to ensure uniqueness of the complete EI instance across organizations.

1.3 Providing structured clinical information with an order

OBR-13 allows for brief text clinical notes (ST data type with field length of 300). Clinical information can also be provided in a structured form using associated OBX segments.

1.4 Diagnostics order management

1.4.1 Placer order management

1.4.1.1 Introduction

Placer order management is the process of managing orders between order placer and order filler. It allows the order placer to place a new order with the order filler. It also allows the order placer to cancel the order. To change order information, the order placer would cancel the initial order and place the new one. If used, recurring orders and panel orders are the subject of agreement between the order placer and the department system scheduler/order filler.

Recurring order: An order with a performance frequency greater than one.

Examples:

Pathology—Early morning sputum m/c/s times 3.

Panel order: A service item with more than one observation component.

Examples:

Pathology—A significant proportion of pathology is ordered by panels of individual tests, including FBC, UE, LFT.

1.4.1.2 Add-on tests/procedures

Add-on tests/procedures maintain the same placer group number as the original episode, with a new placer order number. Results are correlated with placer order number.

1.4.1.3 Reflex tests/procedures

Reflex tests/procedures will be associated with the original order by placer group number but may not have a placer order number. Placer applications shall be able to receive reports for which there is no placer order number.

1.4.1.4 Self-determined tests/procedures

Self-determined tests/procedures are generally not ordered by the placer—they are
self-determined by the pathologist. They will be associated with the original order by placer group number but may not have a placer order number. Placer applications shall be able to receive reports for which there is no placer order number.

1.4.1.5 Order management—new order from Order Placer

1.4.1.5.1 General

The placer system sends a new pathology order to the filler system. The filler system sends an acknowledgement back to confirm that the original message has been received (see Figure 3-2).

((replacement diagram to be added))

Figure 6?2. Order Management – New Order

1.4.1.5.2 Order control codes for specific trigger events

The order placer places a new order (control code = NW) for the department system scheduler/order filler. The order filler sends an acknowledgement message (control code = OK) ‘order accepted’.

1.4.1.5.3 Message semantics

The order start date/time is required in the ORC-9 field and the collection start date/time or exam date/time is required in the OBR-7 field.

1.4.1.6 Order management—order cancelled by order placer

1.4.1.6.1 General

The placer system cancels an order on the filler system. The filler system sends an acknowledgement back to confirm that the message has been received (see Figure 3-3).

Figure 6?3. Order Management – Cancel Order ((replacement diagram to be added))

1.4.1.6.2 Order control codes for specific trigger events

Order placer cancels an order (control code = CA).

Order placer discontinues (attempts to stop) an ongoing order (control code = DC). Order filler sends an acknowledgement (control code = CR) ‘cancelled as requested’.

1.4.2 Filler order management

1.4.2.1 Introduction

This transaction is used by the order filler to inform the order placer about the orders it creates and cancels, including the status of the orders it is fulfilling. If the order filler needs to change an order, it has to do so as a combination of order cancel followed by new order.

A one-for-one relationship between order placer number and order filler number should be established before the order filler creates new orders.

1.4.2.2 Filler order management—new order from order filler

1.4.2.2.1 General

The filler system places a new order. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-4). For an example ORM message, refer to Appendix B. ((to be updated))

Figure 6?4. Order Management – New Order from Filler

1.4.2.2.2 Order control codes for specific trigger events

Department system scheduler/order filler places an order (control code = SN).

Order placer replies (control code = NA).

1.4.2.3 Order management—status changed by filler

1.4.2.3.1 General

The filler system sends a status change to the order to the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-5).

Figure 6?5. Order Management – Status Changed ((replacement diagram to be added))

1.4.2.3.2 Order control codes for specific trigger events

Order filler changes status of order (control code = SC). Order placer sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.4 Filler order management—order rejected by the order filler

1.4.2.4.1 General

The filler system rejects an order from the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-6).

Figure 6?6. Order Management – Reject Order ((replacement diagram to be added))

1.4.2.4.2 Order control codes for specific trigger events

Department system scheduler/order filler rejects the order received from order placer (control code = OD).

If the order filler is unable to process an order, an ORR message will be sent to the order placer with an explanation/reason in ORC-16 (control code = DR).

NOTE: ORR is the ‘general order response message to any ORM (event O02)’; see HL7 V2.4, section 4.4.2.

1.4.2.5 Filler order management—order status update

1.4.2.5.1 General

The filler system sends a status update to the placer system. The placer system sends an acknowledgement back to confirm that the message has been received
(see Figure 3-7).

Figure 6?7. Order Management – Status Update ((replacement diagram to be added))

1.4.2.5.2 Order control codes for specific trigger events

Department system scheduler/order filler updates an order status (control code = SC). Order filler sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.6 Filler order management—order cancelled by the order filler

1.4.2.6.1 General

The filler system cancels an order on the placer system. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-8).

Figure 6?8. Order Management – Order Cancelled ((replacement diagram to be added))

1.4.2.6.2 Order control codes for specific trigger events

Department system scheduler/order filler cancels the order previously received from order placer (control code = OC). Order filler sends an acknowledgement (control code = OK) ‘accepted’.

1.4.2.7 Order management – battery replaced or cancelled by filler

1.4.2.7.1 General

The filler system cancels an order or replaces a battery of tests/procedures. The placer system sends an acknowledgement back to confirm that the message has been received (see Figure 3-9).

Figure 6?9. Order Management – Replace/Cancel Order ((replacement diagram to be added))

1.4.2.7.2 Order control codes for specific trigger events

Order filler cancels a test/procedure or battery of tests/procedures (control code = CA). Order placer sends an acknowledgement (control code = CR) ‘cancelled as requested’.

1 Acknowledging Messages

Systems that use the HL7 protocol are required to acknowledge the receipt and/or processing of a message.

NOTES:

1 Only messages are acknowledged.

2 Batches are not acknowledged. (Refer to HL7 V2.4, Section 2.15.3.3.)

There are two acknowledgment modes—the required mode is specified in the MSH segment. The two modes are:

Table 7?1. HL7 Message Acknowledgement Modes
Mode	Notes
Original Mode:	Application level. This means that the receiving systems has accepted responsibility for the data and then an acknowledgment is issued to the sender.
Enhanced Mode:	Accept level and/or application level. The Accept acknowledgement is sent when 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 acknowledgement may be used to return the resultant status to the sending system.

The recommended method is Enhanced Mode—acknowledgment on receipt of the message.

The acknowledgment codes are:

Table 7?2. HL7 Message Acknowledgement Codes
Value	Description
AA	Original mode: Application Accept Enhanced mode: Application acknowledgment: Accept
AE	Original mode: Application Error Enhanced mode: Application acknowledgment: Error
AR	Original mode: Application Reject Enhanced mode: Application acknowledgment: Reject
CA	Enhanced mode: Accept acknowledgment: Commit Accept
CE	Enhanced mode: Accept acknowledgment: Commit Error
CR	Enhanced mode: Accept acknowledgment: Commit Reject

The placer and filler sites should agree to use the same acknowledgment mode to prevent any misinterpretation of the acknowledgment being received. Further information on the use of Original Mode and Enhanced Acknowledgment Mode is contained in the HL7 V2.4, Sections 2.13.1 and 2.13.2.

In file based transfers the preferred method is to generate individual acknowledgments for order/result messages into a similarly named file for return to the sender. See Clause 12, Site sequence number and file naming for more information. The acknowledgments generated will usually be returned to the placer (requesting surgery) or filler (diagnostics provider) on the next ‘connect’ for data download.

It is usual to generate acknowledgments immediately on receipt of the message. However, systems should ensure that acknowledgments are generated within a reasonable time of receipt and only when they are committed to the system’s data tables.

For data sent in a ‘batch/file’ context see HL7 V2.4, Section 2.15.3, HL7 Batch Protocol.

1 Acknowledging Messages ((as extracted from AS 4700.2))

Systems that use the HL7 protocol are required to acknowledge the receipt and/or processing of a message.

NOTES:

1 Only messages are acknowledged.

2 Batches are not acknowledged. (Refer to HL7 V2.4, Section 2.15.3.3.)

There are two acknowledgment modes—the required mode is specified in the MSH segment. The two modes are:

Table 7?1. HL7 Message Acknowledgement Modes
Mode	Notes
Original Mode:	Application level. This means that the receiving systems has accepted responsibility for the data and then an acknowledgment is issued to the sender.
Enhanced Mode:	Accept level and/or application level. The Accept acknowledgement is sent when 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 acknowledgement may be used to return the resultant status to the sending system.

The recommended method is Enhanced Mode—acknowledgment on receipt of the message.

The acknowledgment codes are:

Table 7?2. HL7 Message Acknowledgement Codes
Value	Description
AA	Original mode: Application Accept Enhanced mode: Application acknowledgment: Accept
AE	Original mode: Application Error Enhanced mode: Application acknowledgment: Error
AR	Original mode: Application Reject Enhanced mode: Application acknowledgment: Reject
CA	Enhanced mode: Accept acknowledgment: Commit Accept
CE	Enhanced mode: Accept acknowledgment: Commit Error
CR	Enhanced mode: Accept acknowledgment: Commit Reject

The placer and filler sites should agree to use the same acknowledgment mode to prevent any misinterpretation of the acknowledgment being received. Further information on the use of Original Mode and Enhanced Acknowledgment Mode is contained in the HL7 V2.4, Sections 2.13.1 and 2.13.2.

In file based transfers the preferred method is to generate individual acknowledgments for order/result messages into a similarly named file for return to the sender. See Clause 12 ((to be updated)), Site sequence number and file naming for more information. The acknowledgments generated will usually be returned to the placer (requesting surgery) or filler (diagnostics provider) on the next ‘connect’ for data download.

It is usual to generate acknowledgments immediately on receipt of the message. However, systems should ensure that acknowledgments are generated within a reasonable time of receipt and only when they are committed to the system’s data tables.

For data sent in a ‘batch/file’ context see HL7 V2.4, Section 2.15.3, HL7 Batch Protocol.

1 BILLING INFORMATION ((as extracted from AS 4700.2))

1.1 Funding source

Funding source is specified in PV1-20 Financial Class.

METeOR 553314 ‘Funding source for hospital patient’ lists the following codes:

Table 8?1. METeOR 553314 ‘Funding source for hospital patients’ codes
Code	Definition
01	Health service budget (not covered elsewhere)
02	Health service budget (due to eligibility for Reciprocal Health Care Agreement)
03	Health service budget (no charge raised due to hospital decision)
04	Department of Veterans' Affairs
05	Department of Defence
06	Correctional facility
07	Medicare Benefits Scheme
08	Other hospital or public authority (contracted care)
09	Private health insurance
10	Worker's compensation
11	Motor vehicle third party personal claim
12	Other compensation (e.g. public liability, common law, medical negligence)
13	Self-funded
88	Other funding source
Supplementary values:	http://meteor.aihw.gov.au/ui/helpWindow.phtml?itemId=tag.helpMeteorItemOtherPermissibleValues
98	Not known

1.2 Billing category

Billing category is sent in PV1-21 Charge Price Indicator.

Currently there is no agreed controlled vocabulary for billing category. As an interim solution, the following agreed Australian billing category codes should be used:

AUSM85 85% of Medicare schedule fee

AUSM75 75% of Medicare schedule fee

AUSM100 Medicare schedule fee

AUSAMA Australian Medical Association recommended fee

Local codes: the BLG segment is used to provide billing information on the ordered service to the filling application. By site-specific agreement, local billing codes may be used. These should be prefixed with ‘LB_’ (as per HL7 V2.4, Table 0396—‘Coding System’) to indicate the local domain of the code list. The next three characters identify the originator of the code, e.g. LB_QMLxxxx.

Browser not supported