To be deleted
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))
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. RE – Required, but can be empty. O – Optional. C – Conditional. CE – Conditional, but may be empty. X – Not used for this profile. - - The hyphen (-) Indicates the profile using the actor does not provide documentation of the structure containing the particular element or does not provide documentation of the particular element in the structure. For instance in a data type specification for CE, if a profile does not provide documentation of the CE data type, then each component of the data type would have a “-“ for the usage for the actor associated with that profile. |
Cardinality | Minimum and maximum number of times the element may appear. [0..0] Element never present. [0..1] Element may be omitted and can have, at most, one occurrence. [1..1] Element must have exactly one occurrence. [0..n] Element may be omitted or may repeat up to n times. [1..n] Element must appear at least once, and may repeat up to n times. [0..*] Element may be omitted or repeat an unlimited number of times. [1..*] Element must appear at least once, and may repeat unlimited number of times. [m..n] Element must appear at least m, and at most, n times. Cardinality applies only to message attribute tables and segment attribute tables. See section C.3.2 ((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 | ||