Appendix 5 Conformance Statements (Normative)

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

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

**wording updated, same intention

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||…

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.

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

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.

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

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.

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

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

Sender must not use the following elements:

• base
• link
• xlink
• frame
• iframes
• form
• object

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.

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.

Receivers may choose to parse the xml and replace the hl7v2 scheme content with a base64 encoded image from the appropriate OBX. eg.

<img src="data:image/png;base64,iV......" />

Must not restrict copying.

RTF must not contain smart tags

Clinical information must not be presented in Header/footer/cross-references.

All field values are up to date, as fields may not updated, only displayed as text.

Receivers must support display of RTF embedded bmp, gif, png, jpg, and emf.

Receivers must support display of nested lists with indication of logical nesting.

Orders, Results, Referrals(L2)

If a digital signature is received in an OBX segment, receiving systems must recognise the digital signature and not inadvertently process it as data for display.

Refer to Standards Australia publication HB 308HB 308 - Location of Digital Signatures in HL7v2

Digital signature OBX can identified by OBX-3 (CE) identifier component starting with "AUSETAV", and OBX-3 name of code system component "L")

A single message of up to 16 MB (16,777,216 bytes) must be able to be received by both the transmitters and receivers of messages.

Note: Larger sized messages are feasible, but only under specific trading partner agreements.

All message types and trigger event codes beginning with the letter “Z” are reserved for locally-defined messages and must NOT be used.