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.

Orders, Results, Referrals

The sending facility must ensure their MSH-4 Sending facility identifier is unique.

When sending a report to multiple "copy to " doctors the MSH-10 Message control ID must be unique in each message produced for each recipient.

When re-transmitting a message the MSH-10 Message control ID must be unique.

Senders

Results, Referrals

Results, Referrals

MSH-12 Version ID <internal version ID (CE)> component must be valued as

"HL7AU-OO-REF-SIMPLIFIED-201706&&L" (for Level 2) or

"HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L" (for Level 1). 

(Note that the number scheme used in this identifier is HL7 date format: YYYYMM)

Orders, Results, Referrals

MSH-4 – Sending Facility must be filled in with the sending facility HPI-O when sending a message via Secure Message Delivery (SMD) and secured by NASH Certificates.

The format must be "registered organisation name in HI service^1.2.36.1.2001.1003.0.<hpio>^ISO" where <hpio> is a 16-digit number.

The identifier is essentially used to locate the endpoint of the sending facility and will be used by the receiving facility to return an acknowledgement.

Both <identifier> and <alternative identifier> must reflect the same concept in each of the primary and alternate coding system respectively. Each code may reflect differing levels of granularity within each coding system as the level of granularity differs between coding systems.

Both <identifier> and <alternative identifier> must reflect the same concept in each of the primary and alternate coding system respectively. Each code may reflect differing levels of granularity within each coding system as the level of granularity differs between coding systems.

Both <identifier> and <alternative identifier> must reflect the same concept in each of the primary and alternate coding system respectively. Each code may reflect differing levels of granularity within each coding system as the level of granularity differs between coding systems.

Receivers must understand that a LOINC code of 60572-5 (Report Template ID) signifies the identifier of the report template used to structure the data and not render as patient data.

Secure messaging agents must ensure that there is a valid referral response entry in their provider directory before proceeding to transmit the message. If not, the sending SMD agent must produce an error acknowledgement and return it to the sending application. When using Australian Profile for Provider Directory Services, the sending SMD agent must ensure that it has registered endpoints containing au-receivingfacility that match the outbound message's MSH-4 and au-receivingapplication match MSH-3.

Senders

*Varied from HL7 2.4 2.11

When MSH-18 is unvalued or valued as "ASCII" the message must contain only characters in the range ASCII 32 to ASCII 127 and cursor return ASCII 13 which must only be used as segment separator.

It is hoped to allow "UNICODE UTF-8" in a future version, but this depends on widespread receiver support. Receivers are encouraged to develop capability for UTF-8.

** errata "UNICODE UTF-8" was incorrectly added as "UTF-8"

The OBX-6 (Units) <text (ST)> component of the primary identifier must be valued according to APUTS preferred unit for the term.

The OBX-6 (Units) <identifier (ST)> component of the primary must be the case sensitive UCUM code.

Orders, Results, Referrals

Adapted from HL7 Conformance Implementation Manual.

The current referral summary OBR/OBX group must appear as the first OBR/OBX group in the message.

Results, Referrals(L2)

Receivers may support encapsulated data attachments MIME type/subtype such as OpenXML Documents:
application/vnd.openxmlformats-officedocument.wordprocessingml.document

application vnd.openxmlformats-officedocument.spreadsheetml.sheet

For the current "Referral Summary" OBR/OBX group (indicated by the OBR-4 code as per section 4.4.1.4.1 OBR-4 codes in referral messages) in the referral message, the display segment must reflect content from taht OBR/OBX group as well as the Allergies, and Medication segments of the REF message. 

For a PRD-7 <ID number (ST)> the correct matching <type of ID number (IS)> and <other qualifying info (ST)> must be used as per table Table 7.3.3.7.1 - Valid PRD-7 component matches

Orders, Results, Referrals, Acknowledgment, Referral Response