Versions Compared

Old Version 76

changes.mady.by.user Former user

Saved on

compared with

New Version 77

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update date

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

...

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

Anchor
table1-1
table1-1
Table 1-1. Message Element Attributes

Attribute

Definition

Seq

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

Segment

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

[ XXX ]              Optional

{ XXX }              Repeating

XXX                  Required

 [{ XXX }]           Optional and Repeating

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

The Segment attribute only applies to the Message attribute table.

Length

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

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

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

DT

Data type used by this profile for HL7 element.

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

Usage

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

Legal usage values are:

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

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

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

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

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

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

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

Cardinality

Minimum and maximum number of times the element may appear.

[0..0]   Element never present.

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

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

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

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

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

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

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

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

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

Value Set

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

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

Name

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

Description/Comments

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

 

...

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

Anchor
table1-2
table1-2
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.

...

...