Australian Diagnostics and Referral Messaging - Localisation of HL7 Version 2.4, Release 2 is the Australian localisation of the international HL7 V2 Standard covering the Laboratory/Diagnostics result reporting and laboratory/radiology ordering specification. It has been expanded to include Referral messaging. The . The term "Diagnostics" covers non laboratory reporting including reporting of diagnostic imaging and non referral related clinical reporting (for example: echocardiography, respiratory function, endoscopy, stress testing, sleep studies). The term pathology in Australia covers all aspects of laboratory medicine including clinical and anatomical pathology domains. The relationship between Pathology Practices and their customers in Australia is considered by Government and others as similar to that between other consultant specialists and their customers. For that reason what HL7 would call an order is generally called a request here and the response by the pathology provider (a formal term meaning the responsible specialist(s)) is called a report. For some disciplines such as microbiology, anatomical pathology, genetics and genomics the request is more by way of asking a clinical question expecting the pathology provider to understand the best way of answering it - eg Is this cancer, if so what type, and what is the prognosis? It is expected this form of requesting will become more common as laboratory medicine evolves. The term "Diagnostics" covers non laboratory reporting including Radiology reporting and non referral related clinical reporting.
The use case here focuses on widely-available, well-standardized methods that will support the secure access to electronic laboratory orders and results and interpretations for clinical care by authorized parties and is driven by the need for timely electronic access to requested, referred and historical lab results. Requesting clinicians (the Placer) receive test results in the form of a HL7 V2 message, as a response to a request (electronic or paper) or as an unsolicited message by having the report directly sent by the pathology practice (the Filler) to the clinician for importation into their local systems. Referral messaging covers clinical referral between clinicians and hospitals and includes a patient history summary suitable for constructing a Virtual Medical Record for use in decision support and any pathology/radiology/diagnostics reports relevant to the referral. It also includes a Medication summary.
...
The Royal College of Pathologists of Australasia (RCPA) has developed a number of policies around safety in requesting and reporting of pathology including the use of terminology and the transmission of data. These policies have been incorporated into this document.
...
The following table describes the various attributes used by this guide to document data type attribute tables, message structure attribute tables and segment attribute tables. Not all attributes apply to all attribute tables.
Table 1-1. Message Element AttributesAnchor table1-1 table1-1
Attribute | Definition |
Seq | Sequence of the elements as numbered in the HL7 message element. The Seq attribute applies to the data type attribute table and the segment attribute table. |
Segment | Three-character code for the segment and the abstract syntax (e.g., the square and curly braces). [ XXX ] Optional { XXX } Repeating XXX Required [{ XXX }] Optional and Repeating Note that for segment groups there is no segment code present, but the square and curly braces will still be present. The Segment attribute only applies to the Message attribute table. |
Length | Maximum length of the element. Lengths are provided only for primitive data types. The length attribute applies to data type attribute tables and segment attribute tables. Lengths should be considered recommendations, not absolutes. The receiver can truncate fields, components and sub-components that are longer than the recommended length. The receiver should continue to process a message even when a field, component, or sub-component length exceeds the maximum recommended length identified in this specification. |
DT | Data type used by this profile for HL7 element. The data type attribute applies to data type attribute tables and segment attribute tables. |
Usage | Usage of the message element for this profile. Indicates whether the message element (segment, segment group, field, component, or subcomponent) is required, optional, or conditional in the corresponding message element. Usage applies to the message attribute table, data type attribute table and the segment attribute table. See HL7 International standard section C.3.1 – Usage for documentation on how usage has been implemented in this guide. Legal usage values are: R – Required. RE – Required, but can be empty. O – Optional. C – Conditional. CE – Conditional, but may be empty. X – Not used for this profile. - - The hyphen (-) Indicates the profile using the actor does not provide documentation of the structure containing the particular element or does not provide documentation of the particular element in the structure. For instance in a data type specification for CE, if a profile does not provide documentation of the CE data type, then each component of the data type would have a “-“ for the usage for the actor associated with that profile. |
Cardinality | Minimum and maximum number of times the element may appear. [0..0] Element never present. [0..1] Element may be omitted and can have, at most, one occurrence. [1..1] Element must have exactly one occurrence. [0..n] Element may be omitted or may repeat up to n times. [1..n] Element must appear at least once, and may repeat up to n times. [0..*] Element may be omitted or repeat an unlimited number of times. [1..*] Element must appear at least once, and may repeat unlimited number of times. [m..n] Element must appear at least m, and at most, n times. Cardinality applies only to message attribute tables and segment attribute tables. See Section C.3.2 for additional information on how cardinality is handled in this guide. |
Value Set | The set of coded values to be used with the field. The value set attribute applies only to the data type attribute tables and the segment attribute tables. The value set may equate with an entire code system part of a code system, or codes drawn from multiple code systems. Note: Where a table constraint is indicated, or where HL7 Version 2.6 standards are pre-adopted, the constrained or specified HL7 table is included below the data type table. |
Name | HL7 descriptor of the message element. Name applies to the message attribute table, data type attribute table and the segment attribute table. |
Description/Comments | Context and usage for the element. Description/Comments applies to the message attribute table, data type attribute table and the segment attribute table. |
...
The following table provides some recommendations for testing the various usage codes described in the previous table.
| Anchor | ||||
|---|---|---|---|---|
|
Usage | Recommendation |
R – Required | Required elements must be present in a message instance with the following caveats: A required segment, which is contained within a segment group, is required only when the segment group is present in the message. For instance if the segment group is RE, then when the segment group is present, the required segments in that group must be present. A required field in a segment is required only when the segment itself is present in the message. For instance if the segment is CE (conditional or empty) and the conditional predicate is satisfied, then the segment is present in the message and the required fields must be present in the segment. A required component of a data type is required only when the field the data type is associated with is present in the message. Testing of a required element generally involves generating both a fully populated message instance as well as a minimally populated message instance. It may be necessary to generate specific test cases to handle separate segment groups, segments, etc. depending on the usage associated with these higher level elements within a message. |
RE – Required, but can be empty | Since conformant senders must be able to show they can send this data, the primary mechanism for testing the RE usage would involve requiring the sender to transmit a “fully” populated message instance from their application. In this case, the expectation is that the message will be generated by the application, not handcrafted. The message would contain all data the sending application can populate in the message. This generally means the sender would be populating in their application all data elements being tested, including those that are optional in the application. |
O – Optional | Conformance testing for optional elements would not normally be performed. If a particular implementation decides to use an optional element, it should create an implementation specific profile which further constrains this profile, making the optional element either required, required but may be empty, condition or conditional but may be empty, and then test the element in question based upon the assigned usage in that profile. |
C – Conditional | Testing conditional elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. |
CE – Conditional, but may be empty | Testing conditional but may be empty elements generally means a special test case must be developed based upon the specific conditional rule or conditional predicate documented for the element. |
X – Not used for this profile | Testing this usage code usually involves looking at both fully populated and minimally populated messages. Note that the sending application may collect the data element in question, but it should not communicate that data element in message instances. |
...