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/Both

Message Type Applicability

Conformance point text

Comments

HL7au Identifier

Applicable to Senders/Receivers/Both

Message Type Applicability

Conformance point text

Comments

HL7au:000001

Senders/Receivers

Orders

Order 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

Receivers

Orders

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

 

HL7au:000001.2

Senders

Orders

When 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

Senders

Orders

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

Receivers

Results, Referrals

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

Senders

Orders, Results, Referrals

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

Receivers

Orders, Results, Referral

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

Senders

Orders, Results, Referrals

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

Senders

Orders, Results

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

Senders

Orders, 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

Senders

Results, Referrals

The message must contain at least one OBX display segment per OBR/OBX group.

**wording updated, same intention

HL7au:000008.1 (r2)

Senders

Results, 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)

Receivers

Results, 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 Receivers

Results

An 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 Receivers

Results

In 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 Receivers

Results

In an OBX display segment, the OBX-3 <name of coding system (IS)> must be valued "AUSPDI".

 

HL7au:000008.1.5

Senders

Results, Referrals

The OBX display segment(s) must be the last in a set of OBX segments in each OBR/OBX group, with the exception of digital signature OBX(s) which may be after the display segments OBXs. (Display segments can be identified by having AUSPDI OBX-3 <name of coding system>)

 

HL7au:000008.1.6

Receivers

Results, Referrals

When a display segment is shown, the earlier atomic OBX segments must not be rendered.

 

HL7au:000008.2

Senders

Results

There must NOT be conflicting content between the OBX display segment and the preceding OBX atomic data. A compliant rendering of the atomic data (if present) must contain the same clinical information.

 

HL7au:000008.2.1

Senders

Referrals

For OBX within the supporting information OBR/OBX groups. There must NOT be conflicting content between the OBX display segment and the preceding OBX atomic data. A compliant rendering of the atomic data (if present) must contain the same clinical information.

 

HL7au:000008.2.2

Senders

Referrals

For OBX within the current summary OBR/OBX group as indicated by OBR-4 as per section 4.4.1.4.1 OBR-4 codes in referral messages. There must NOT be conflicting content between the OBX display segment and the preceding OBX atomic data and the medication and allergy segments of the REF message.

 

HL7au:000008.3.1

Senders

Referrals

For Referrals Level 1:

The single OBR/OBX group of the message must contain an OBX display segment in PDF format.

For other profiles:

Each OBR/OBX group of the message must contain at least one of the following OBX display segments HTML, PDF, TXT (HL7 FT).

 

HL7au:000008.3.2

Senders

Referrals(L2)

If an RTF display segment is sent in an OBR/OBX group, then the same content must be sent in one of either HTML, PDF, or TXT (HL7 FT) same OBR/OBX group.

 

 

 

 

(HL7au:000008.2.3)

XHTML Display Segment

(HL7au:000008.2.3.1)

XHTML Display Segment - Sender

HL7au:000008.2.3.1.01

Senders

Results, Referrals

Any OBX HTML display segments must be valid HTML and conform to the Document Type defined in 'XHTML 1.0 Strict' standard. Refer to  http://validator.w3.org/ to validate XHTML content.

 

HL7au:000008.2.3.1.02

Senders

Results, Referrals

All embedded hyperlinks must be secure hyperlinks i.e. https:// . That is http:// is disallowed.

 

HL7au:000008.2.3.1.03

Senders

Results, Referrals

Sender must not use external style sheets. Internal style sheets are allowed.

Note: external stylesheets are a security risk and could affect presentation of content.

 

HL7au:000008.2.3.1.04

Senders

Results, Referrals

Sender must not use scripts e.g. JavaScript etc.

Note: active content is not allowed either inline or as external references.

 

HL7au:000008.2.3.1.05

Senders

Results, Referrals

Sender must not use the following elements:

  • base

  • link

  • xlink

  • frame

  • iframes

  • form

  • object

 

HL7au:000008.2.3.1.06

Senders

Results, Referrals

If there is an image map, senders must have an additional mechanism for communicating that information because there is no obligation on receiving systems to deal with image maps.

 

HL7au:000008.2.3.1.07

Senders

Results, Referrals

Embedded CSS shall conform to the CSS3 specification.

 

HL7au:000008.2.3.1.08

Senders

Results, Referrals

The core display of the report must be encapsulated in a 'div' element of html class ‘reportDisplay’.

 

HL7au:000008.2.3.1.09

Senders

Results, Referrals

Letter head information should be encapsulated in XHTML elements outside of the scope of the core display of the report identified by 'div' html class 'reportDisplay'.

 

HL7au:000008.2.3.1.10

Senders

Results, Referrals

Letter head images may not be embedded in the html but served externally.

 

HL7au:000008.2.3.1.11

Senders

Results, Referrals

External letter head image sources must not be used, except when used outside a 'div' 'reportDisplay' class html element and only when that 'div' it is present.

 

 

HL7au:000008.2.3.1.12

Senders

Results, Referrals

The core report must display in a readable way with the CSS removed.

 

HL7au:000008.2.3.1.13

Senders

Results, Referrals

Information in the core report data must not be hidden by CSS formatting directives. 

 

HL7au:000008.2.3.1.14

Senders

Results, Referrals

Image element "src" attributes must use the value "hl7v2://OBX.<setID>" where the setID reference the OBX in the message containing the Encapsulated Data (ED) image or Reference Pointer (RP) to the data, except for images which are a part of a letterhead as per HL7au:000008.2.3.1.10.

 

HL7au:000008.2.3.1.15

Senders

Results, Referrals

External images may be linked from the report body via a clickable link which the user can manually select.

e.g. to access a PACS image

 

 

 

 

 

(HL7au:000008.2.3.2)

XHTML Display segment - Receiver

HL7au:000008.2.3.2.01

Receivers

Results, Referrals(L2)

HTML display segments must be displayed using a HTML/CSS component that is compliant for rendering of XHTML and CSS3.

 

HL7au:000008.2.3.2.03

Receivers

Results, Referrals(L2)

Secure hyperlinks (https://) must be able to be clicked by a user and client application must enable navigation to secure https:// sites .

 

HL7au:000008.2.3.2.04

Receivers

Results, Referrals(L2)

Receiving software may filter or disable all embedded JavaScript.

 

HL7au:000008.2.3.2.05

Receivers