/
Appendix 5 Conformance Statements (Normative)

Appendix 5 Conformance Statements (Normative)

Conformance Statements have been developed to help in formulating conformance testing of pathology messaging implementations in Australia against this Implementation Guide. The list below is not exhaustive. The entries are included here primarily if they:-

  • are important from a safety or quality perspective, or
  • are commonly not correctly implemented, or
  • are at variance with the base HL7 v2.4 specifications.

Conformance of messages to base HL7 2.4 standards is otherwise assumed, and individual conformance tests or test applications may check against the base specification.

The following table indicates whether a conformance statement applies to a message sender, a message receiver, or both. In the case where a conformance statement applies to a message sender, it is expected that automated conformance checking can be carried out on one or more real or sample messages. For testing conformance of receiving implementations, the behaviour of the system must be observed in response to one or more real or sample messages.

The table of conformance statements indicates, for each statement, if it applies to order messages only, result messages only, or both.

Note: For the conformance points, generally the rule is stated first followed by the reason.  The reason may also be referenced in other sections.

Note: HL7au Identifiers in () parenthesis are headings/groupers and not conformance points in themselves.

Conformance points which are revised will have their revision number in brackets after their HL7au identifier. For example HL7au:00000x.y.z (r2).

The values of Message Type Applicability column and their meanings are: -

  • Orders = ORM messages
  • Results = ORU messages
  • Referrals = All REF messages (includes all profiles)
  • Referrals(L1) = Simplified Referral Profile Level 1
  • Referrals(L2) = Simplified Referral Profile Level 2
  • Acknowledgement = ACK messages
  • Referral Response = RRI messages

HL7au Identifier

Applicable to Senders/Receivers/BothMessage Type ApplicabilityConformance point text

Comments

HL7au:000001
Senders/ReceiversOrdersOrder addressing - Senders and receivers must ensure an order message is addressed using MSH-6 Receiving facility, as per rules in sub points of HD Datatype conformance heading HL7au:00044.2. 

HL7au:000001.1

ReceiversOrders

The system must actively reject an order message where the MSH-6 Receiving Facility does not identify their organisation

 

HL7au:000001.2
SendersOrdersWhen using SMD refer to HL7au:000044.2 otherwise; senders should address order messages in MSH-6 Receiving facility using the NATA number if available. 
HL7au:000001.2.1
SendersOrdersIn MSH-6 the namespace ID should contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) 

HL7au:000002 (r2)

ReceiversResults, ReferralsThe system receiving messages must ensure that any document identifiers (OBR-3 Filler order number (EI)) in the received message are fully specified, with the authoring organisation's HD qualifying the identifier. This is done by testing that all components of Entity Identifier (EI) are valued, and when not returning error acknowledgement.Document updating depends on a reliable document identifier and without a namespace for the identifier safe updating/corrections to documents is not possible.

HL7au:000003 (r2)

Senders

Orders, Results, Referrals

If OBR-2 is valued, then to ensure the uniqueness of the Entity Identifier (EI) in OBR-2 (Placer Order Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated.field optionality is still allowed i.e. field may be completely unvalued

HL7au:000004.1 (r3)

SendersOrders, Results, ReferralsIf OBR-3 is valued, then to ensure the uniqueness of the Entity Identifier (EI) in OBR-3 (Filler Order Number) for a result identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated.It is vital that a unique identifier within the authoring facility HD is used in the first component. The ability to issue corrected documents depends on the uniqueness of this document identifier. Future updates to a document will use the same identifier in OBR-3.

HL7au:000004.2 (r1)

ReceiversOrders, Results, ReferralOlder results with identical Entity Identifier (EI) in OBR-3 (Filler Order Number) to that of a newly received result message (by comparing OBR-22 Rpt/Status Change Date/Time field) must be replaced with the new message, and the older marked as deleted/superseded.This applies independently to each OBR/OBX group

HL7au:000005 (r2)

SendersOrders, Results, ReferralsIf ORC-2 is valued, then to ensure the uniqueness of the Entity Identifier (EI) in ORC-2 (Placer Order Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated.field optionality is still allowed i.e. field may be completely unvalued

HL7au:000006 (r3)

SendersOrders, ResultsIf ORC-3 is valued, then to ensure the uniqueness of the Entity Identifier (EI) in ORC-3 (Filler Order Number) for a result identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. 

HL7au:000007 (r2)

SendersOrders, Results, Referrals

If ORC-4 is valued, then to ensure the uniqueness of the Entity Identifier (EI) in ORC-4 (Placer Group Number) for a request identifier across different organisations, the Entity identifier (first component) in addition to the Namespace ID (second component) and Universal ID (third component) and Universal ID type (4th component) must be populated. 

field optionality is still allowed i.e. field may be completely unvalued

(HL7au:000008)Display Segments
HL7au:000008
SendersResults, ReferralsThe message must contain at least one OBX display segment per OBR/OBX group.

**wording updated, same intention

HL7au:000008.1 (r2)

SendersResults, Referrals

Display segments must use the appropriate valid values within the AUSPDI coding system in OBX-3 for the content that is represented in it:

  • OBX||ED|HTML^Display format in HTML^AUSPDI||^text^HTML^A^<?xml
    version="1.0"…

  • OBX||ED|PDF^Display format in PDF^AUSPDI||^application^pdf^Base64^

  • OBX||ED|RTF^Display format in RTF^AUSPDI||

  • OBX||FT|TXT^Display format in text^AUSPDI||

(Referral Level 1 receivers are only required to support PDF display segments. See HL7au:000008.3.1)
 

HL7au:000008.1.1 (r4)

ReceiversResults, Referrals

For Referrals Level 1

Receivers must be capable of displaying PDF (either via an embedded viewer or an external viewer)

For other profiles:

Receivers should be capable of displaying all display formats HTML, PDF, RTF, TXT (HL7 FT) (either via an embedded viewer or an external viewer), and must provide users access to all of these in an external viewer application if they are unable to fully display the format.

*This conformance point was relaxed 31/10/2017.

Some formats may be viewed with an embedded viewer and external viewer, while other formats may be viewed with just an external viewer e.g. RTF). It is important that all can be accessed and viewed.

HL7au:000008.1.2
Senders and ReceiversResultsAn OBX display segment is identified using OBX-3 Identifier (CE-1) and Name of Coding System (CE-3) components. The text component of the CE may be blank and only CE1 and CE-3 components need to match. 
HL7au:000008.1.3
Senders and ReceiversResultsIn an OBX display segment, the OBX-2 Value Type field must match its corresponding display format specified in OBX-3 Identifier (ST) component as per table Display Format codes in Section 4.5 Display Segments. 
HL7au:000008.1.4
Senders and ReceiversResultsIn an OBX display segment, the OBX-3 <name of coding system (IS)> must be valued "AUSPDI". 
HL7au:000008.1.5