Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fix references

...

HL7au Identifier

Applicable to Senders/Receivers/BothMessage Type ApplicabilityConformance point text

Comments

Anchor
1
1
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. 

Anchor
1.1
1.1
HL7au:000001.1

ReceiversOrders

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

 

Anchor
1.2
1.2
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. 
Anchor
1.2.1
1.2.1
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 ) 

Anchor
2
2
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.
Anchor
3
3
HL7au:000003
Senders

Orders, Results, Referrals

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/or Universal ID (third component) and Universal ID type (4th component) must be populated.field optionality is still allowed ie. field may be completely unvalued

Anchor
4.1
4.1
HL7au:000004.1 (r2)

SendersOrders, Results, ReferralsTo 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/or 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 the uniqueness of this document identifier. Future updates to a document will use the same identifier in OBR-3.
Anchor
4.2
4.2
HL7au:000004.2
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 ORR/OBX group
Anchor
5
5
HL7au:000005
SendersOrders, Results, ReferralsTo 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 ie. field may be completely unvalued
Anchor
6
6
HL7au:000006
ReceiversOrders, ResultsTo 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. 
Anchor
7
7
HL7au:000007
SendersOrders, Results, Referrals

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 ie. field may be completely unvalued

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

**wordingupdated, same intention

Anchor
8.1
8.1
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)
 

Anchor
8.1.1
8.1.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.

Anchor
8.1.2
8.1.2
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. 
Anchor
8.1.3
8.1.3
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. 
Anchor
8.1.4
8.1.4
HL7au:000008.1.4
Senders and ReceiversResultsIn an OBX display segment, the OBX-3 <name of coding system (IS)> must be valued "AUSPDI". 
Anchor
8.1.5
8.1.5
HL7au:000008.1.5
SendersResults, ReferralsThe 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>)  
Anchor
8.1.6
8.1.6
HL7au:000008.1.6
ReceiversResults, ReferralsWhen a display segment is shown, the earlier atomic OBX segments must not be rendered. 
Anchor
8.2
8.2
HL7au:000008.2
SendersResultsThere 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.

 

Anchor
8.2.1
8.2.1
HL7au:000008.2.1
SendersReferralsFor 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. 
Anchor
8.2.2
8.2.2
HL7au:000008.2.2
SendersReferralsFor 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.  
Anchor
8.3.1
8.3.1
HL7au:000008.3.1
SendersReferrals

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

 
Anchor
8.3.2
8.3.2
HL7au:000008.3.2
SendersReferrals(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. 
   
Anchor
8.2.3
8.2.3
(HL7au:000008.2.3)
XHTML Display Segment
Anchor
8.2.3.1
8.2.3.1
(HL7au:000008.2.3.1)
XHTML Display Segment - Sender
Anchor
8.2.3.1.1
8.2.3.1.1
HL7au:000008.2.3.1.01
SendersResults, 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.

 
Anchor
8.2.3.1.2
8.2.3.1.2
HL7au:000008.2.3.1.02
SendersResults, Referrals

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

 
Anchor
8.2.3.1.3
8.2.3.1.3
HL7au:000008.2.3.1.03
SendersResults, 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.

 
Anchor
8.2.3.1.4
8.2.3.1.4
HL7au:000008.2.3.1.04
SendersResults, Referrals

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

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

 
Anchor
8.2.3.1.5
8.2.3.1.5
HL7au:000008.2.3.1.05
SendersResults, Referrals

Sender must not use the following elements:

  • base
  • link
  • xlink
  • frame
  • iframes
  • form
  • object
 
Anchor
8.2.3.1.6
8.2.3.1.6
HL7au:000008.2.3.1.06
SendersResults, 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.

 
Anchor
8.2.3.1.7
8.2.3.1.7
HL7au:000008.2.3.1.07
SendersResults, ReferralsEmbedded CSS shall conform to the CSS3 specification. 
Anchor
8.2.3.1.8
8.2.3.1.8
HL7au:000008.2.3.1.08
SendersResults, ReferralsThe core display of the report must be encapsulated in a 'div' element of html class ‘reportDisplay’. 
Anchor
8.2.3.1.9
8.2.3.1.9
HL7au:000008.2.3.1.09
SendersResults, ReferralsLetter head information should be encapsulated in XHTML elements outside of the the scope of the core display of the report identified by 'div' html class 'reportDisplay'. 
Anchor
8.2.3.1.10
8.2.3.1.10
HL7au:000008.2.3.1.10
SendersResults, ReferralsLetter head images may not be embedded in the html but served externally. 
Anchor
8.2.3.1.11
8.2.3.1.11
HL7au:000008.2.3.1.11
SendersResults, 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.

 

 
Anchor
8.2.3.1.12
8.2.3.1.12
HL7au:000008.2.3.1.12
SendersResults, ReferralsThe core report must display in a readable way with the CSS removed. 
Anchor
8.2.3.1.13
8.2.3.1.13
HL7au:000008.2.3.1.13
SendersResults, ReferralsInformation in the core report data must not be hidden by CSS formatting directives.  
Anchor
8.2.3.1.14
8.2.3.1.14
HL7au:000008.2.3.1.14
SendersResults, ReferralsImage 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. 
Anchor
8.2.3.1.15
8.2.3.1.15
HL7au:000008.2.3.1.15
SendersResults, ReferralsExternal images may be linked from the report body via a clickable link which the user can manually select.eg. to access a PACS image
     
Anchor
8.2.3.2
8.2.3.2
(HL7au:000008.2.3.2)
XHTML Display segment - Receiver
Anchor
8.2.3.2.1
8.2.3.2.1
HL7au:000008.2.3.2.01
ReceiversResults, Referrals(L2)HTML display segments must be displayed using a HTML/CSS component that is compliant for rendering of XHTML and CSS3. 
Anchor
8.2.3.2.3
8.2.3.2.3
HL7au:000008.2.3.2.03
ReceiversResults, Referrals(L2)Secure hyperlinks (https://) must be able to be clicked by a user and client application must enable navigation to secure https:// sites . 
Anchor
8.2.3.2.4
8.2.3.2.4
HL7au:000008.2.3.2.04
ReceiversResults, Referrals(L2)Receiving software may filter or disable all embedded javascript. 
Anchor
8.2.3.2.5
8.2.3.2.5
HL7au:000008.2.3.2.05
ReceiversResults, Referrals(L2)Receiving software may suppress objects, iframes, forms with base/link/xlink 
Anchor
8.2.3.2.6
8.2.3.2.6
HL7au:000008.2.3.2.06
ReceiversResults, Referrals(L2)Receiving software may block access to insecure hyperlinks eg file://, http:// 
Anchor
8.2.3.2.7
8.2.3.2.7
HL7au:000008.2.3.2.07
ReceiversResults, Referrals(L2)It should be possible for users in receiving software to selectively hide content outside of the 'div' element of html class ‘reportDisplay’. 
Anchor
8.2.3.2.8
8.2.3.2.8
HL7au:000008.2.3.2.08
ReceiversResults, Referrals(L2)Receiving software should not selectively hide any html when no 'div' element of html class ‘reportDisplay’ is not present in XHTML content. 
Anchor
8.2.3.2.2
8.2.3.2.2
HL7au:000008.2.3.2.02
ReceiversResults, Referrals(L2)Receiver must support embedded images in XHTML that must be proper URLs suitable for browser use directly, or use the HL7 V2: scheme defined in the HTML Appendix.

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......" />
Anchor
8.2.3.2.9
8.2.3.2.9
HL7au:000008.2.3.2.09
ReceiversResults, Referrals(L2)XHTML containing images with a source referring back to an RP OBX segment using the 'hl7v2://OBX.<setID>' must be resolved so that the images are viewable.** Note that regular browsers do not support this feature directly, xhtml preprocessing is required before display with browser
Anchor
8.2.3.2.10
8.2.3.2.10
HL7au:000008.2.3.2.10
ReceiversResults, Referrals(L2)XHTML containing images with a source referring back to an ED OBX segment using the 'hl7v2://OBX.<setID>' must be resolved so that the images are viewable.** Note that regular browsers do not support this feature directly, xhtml preprocessing is required before display with browser
     
Anchor
8.2.4
8.2.4
(HL7au:000008.2.4)
PDF Display segment
Anchor
8.2.4.1
8.2.4.1
(HL7au:000008.2.4.1)
PDF Display segment - Sender
Anchor
8.2.4.1.1
8.2.4.1.1
HL7au:000008.2.4.1.1
SendersResults, ReferralsDocuments must be valid according to the PDF/A-1b profile. 
Anchor
8.2.4.1.2
8.2.4.1.2
HL7au:000008.2.4.1.2
SendersResults, ReferralsMust embed fonts 
Anchor
8.2.4.1.3
8.2.4.1.3
HL7au:000008.2.4.1.3
SendersResults, ReferralsMust not use encryption/password protection 
Anchor
8.2.4.1.4
8.2.4.1.4
HL7au:000008.2.4.1.4
SendersResults, ReferralsMust not use PDF Comments 
Anchor
8.2.4.1.5
8.2.4.1.5
HL7au:000008.2.4.1.5
SendersResults, ReferralsMust not restrict printing. 
Anchor
8.2.4.1.6
8.2.4.1.6
HL7au:000008.2.4.1.6
SendersResults, Referrals

Must not restrict copying.

 
Anchor
8.2.4.1.7
8.2.4.1.7
HL7au:000008.2.4.1.7
SendersResults, ReferralsMay use PDF digital signature 
Anchor
8.2.4.1.8
8.2.4.1.8
HL7au:000008.2.4.1.8
SendersResults, ReferralsMay use PDF restrict changes 
Anchor
8.2.4.1.9
8.2.4.1.9
HL7au:000008.2.4.1.9
SendersResults, ReferralsMay use PDF compression 
Anchor
8.2.4.2
8.2.4.2
(HL7au:000008.2.4.2)
PDF Display segment - Receiver
Anchor
8.2.4.2.1
8.2.4.2.1
HL7au:000008.2.4.2.1
ReceiversResults, ReferralsReceiver software must display the received PDF with a PDF viewer component. 
Anchor
8.2.4.2.2
8.2.4.2.2
HL7au:000008.2.4.2.2
ReceiversResults, ReferralsReceiver software must be capable of rendering PDF/A-1b content. 
Anchor
8.2.4.2.3
8.2.4.2.3
HL7au:000008.2.4.2.3
ReceiversResults, ReferralsReceiver must support embedded fonts. This is because content is laid out based on font metrics. 
Anchor
8.2.4.2.4
8.2.4.2.4
HL7au:000008.2.4.2.4
ReceiversResults, ReferralsReceiver must support PDF compression. 
Anchor
8.2.4.2.5
8.2.4.2.5
HL7au:000008.2.4.2.5
ReceiversResults, ReferralsReceivers may validate for PDF digital signatures. 
Anchor
8.2.4.2.6
8.2.4.2.6
HL7au:000008.2.4.2.6
ReceiversResults, ReferralsReceiver software must not allow changes to documents in all circumstances. This is irrespective of PDF flags to restrict changes. 
     
Anchor
8.2.4.3
8.2.4.3
(HL7au:000008.2.4.3)
RTF Display segment
Anchor
8.2.4.3.1
8.2.4.3.1
(HL7au:000008.2.4.3.1)
RTF Display segment - Sender
Anchor
8.2.4.3.1.1
8.2.4.3.1.1
HL7au:000008.2.4.3.1.1
SendersResults, ReferralsRTF must not contain nested tables (ie. tables inside tables) 
Anchor
8.2.4.3.1.2
8.2.4.3.1.2
HL7au:000008.2.4.3.1.2
SendersResults, ReferralsRTF must not contain active content such as Objected Linking and Embedding Objects (OLE), except with image rendition subject to site-specific negotiation. 
Anchor
8.2.4.3.1.3
8.2.4.3.1.3
HL7au:000008.2.4.3.1.3
SendersResults, ReferralsRTF must not contain embedded fonts 
Anchor
8.2.4.3.1.4
8.2.4.3.1.4
HL7au:000008.2.4.3.1.4
SendersResults, ReferralsRTF must not contain smart shapes/other drawing objects (convert these to PNG images) 
Anchor
8.2.4.3.1.5
8.2.4.3.1.5
HL7au:000008.2.4.3.1.5
SendersResults, Referrals

RTF must not contain smart tags

 
Anchor
8.2.4.3.1.6
8.2.4.3.1.6
HL7au:000008.2.4.3.1.6
SendersResults, ReferralsRTF must not contain change tracking markup or comments 
Anchor
8.2.4.3.1.7
8.2.4.3.1.7
HL7au:000008.2.4.3.1.7
SendersResults, ReferralsRTF must not contain section specific page layout 
Anchor
8.2.4.3.1.8
8.2.4.3.1.8
HL7au:000008.2.4.3.1.8
SendersResults, ReferralsRTF must not contain word forms 
Anchor
8.2.4.3.1.9
8.2.4.3.1.9
HL7au:000008.2.4.3.1.9
SendersResults, Referrals

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

 
Anchor
8.2.4.3.1.10
8.2.4.3.1.10
HL7au:000008.2.4.3.1.10
SendersResults, ReferralsBranding information may be presented in Header/footer/cross-references. 
Anchor
8.2.4.3.1.11
8.2.4.3.1.11
HL7au:000008.2.4.3.1.11
SendersResults, ReferralsWatermark must not be required to be viewed. 
Anchor
8.2.4.3.1.12
8.2.4.3.1.12
HL7au:000008.2.4.3.1.12
SendersResults, Referrals

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

 
Anchor
8.2.4.3.2
8.2.4.3.2
(HL7au:000008.2.4.3.2)
RTF Display segment - Receiver
   Note: Referral receivers may choose to support the required RTF receiver capability by allowing the user to launching a compliant external RTF viewer application (such as Microsoft Word Viewer / Microsoft Word). It is not a requirement to embed a viewer. 
Anchor
8.2.4.3.2.1
8.2.4.3.2.1
HL7au:000008.2.4.3.2.01
ReceiversResults, Referrals(L2)Receivers must process the \binXXXX control word and skip processing of RTF control words for XXX bytes.Refer to Word 2007: Rich Text Format (RTF) Specification, version 1.9.1 page 211 where it says "the reader must explicitly check each control word found to see if it is a \binN control, and if found, skip that many bytes before resuming its scanning for braces."
Anchor
8.2.4.3.2.2
8.2.4.3.2.2
HL7au:000008.2.4.3.2.02
ReceiversResults, Referrals(L2)Receivers must support tables, except for nested tables 
Anchor
8.2.4.3.2.3
8.2.4.3.2.3
HL7au:000008.2.4.3.2.03
ReceiversResults, Referrals(L2)Receivers must support hyperlinks 
Anchor
8.2.4.3.2.4
8.2.4.3.2.4
HL7au:000008.2.4.3.2.04
ReceiversResults, Referrals(L2)Receivers must allow secure https:// hyperlinks to be clickable and navigable into a web browser. 
Anchor
8.2.4.3.2.5
8.2.4.3.2.5
HL7au:000008.2.4.3.2.05
ReceiversResults, Referrals(L2)

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

 
Anchor
8.2.4.3.2.6
8.2.4.3.2.6
HL7au:000008.2.4.3.2.06
ReceiversResults, Referrals(L2)Receivers must support display of RTF columns 
Anchor
8.2.4.3.2.7
8.2.4.3.2.7
HL7au:000008.2.4.3.2.07
ReceiversResults, Referrals(L2)Receivers must support Lists including bullet and numbers. 
Anchor
8.2.4.3.2.8
8.2.4.3.2.8
HL7au:000008.2.4.3.2.08
ReceiversResults, Referrals(L2)

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

 
Anchor
8.2.4.3.2.9
8.2.4.3.2.9
HL7au:000008.2.4.3.2.09
ReceiversResults, Referrals(L2)Display of selected field values.Editors such as Microsoft Word allow form fields to be created such as combo boxes, radio buttons and check boxes which users can select a value from. This the selected field value refers to the answer which should be present in the RTF field.
Anchor
8.2.4.3.2.10
8.2.4.3.2.10
HL7au:000008.2.4.3.2.10
ReceiversResults, Referrals(L2)Receivers may support Header/footer/cross-references 
Anchor
8.2.4.3.2.11
8.2.4.3.2.11
HL7au:000008.2.4.3.2.11
ReceiversResults, Referrals(L2)Receivers may support watermarks 
Anchor
8.2.4.3.2.12
8.2.4.3.2.12
HL7au:000008.2.4.3.2.12
ReceiversResults, Referrals(L2)Receivers must display field values.This refers to fields such as page numbers. RTF senders should include the value in the field.
Anchor
8.2.4.3.2.13
8.2.4.3.2.13
HL7au:000008.2.4.3.2.13
ReceiversResults, Referrals(L2)Receivers may not calculate field values. 
Anchor
8.2.4.4
8.2.4.4
(HL7au:000008.2.4.4)
FT Display segment
Anchor
8.2.4.4.1
8.2.4.4.1
(HL7au:000008.2.4.4.1)
FT Display segment - Sender
Anchor
8.2.4.4.1.1
8.2.4.4.1.1
HL7au:000008.2.4.4.1.01
SendersResults, ReferralsSenders must escape '|' character to the field separator character escape sequence "\F\" 
Anchor
8.2.4.4.1.2
8.2.4.4.1.2
HL7au:000008.2.4.4.1.02
SendersResults, ReferralsSenders must escape '^' character to the component separator character escape sequence "\S\" 
Anchor
8.2.4.4.1.3
8.2.4.4.1.3
HL7au:000008.2.4.4.1.03
SendersResults, ReferralsSenders must escape '&' character to the sub-component separator character escape sequence "\T\" 
Anchor
8.2.4.4.1.4
8.2.4.4.1.4
HL7au:000008.2.4.4.1.04
SendersResults, ReferralsSenders must escape '~' character to the repeat character escape sequence "\R\" 
Anchor
8.2.4.4.1.5
8.2.4.4.1.5
HL7au:000008.2.4.4.1.05
SendersResults, ReferralsSenders must escape '\' character to the escape character escape sequence "\E\" 
Anchor
8.2.4.4.1.6
8.2.4.4.1.6
HL7au:000008.2.4.4.1.06
SendersResults, ReferralsSenders must escape new line character(s) to the escape sequence "\.br\" 
Anchor
8.2.4.4.1.7
8.2.4.4.1.7
HL7au:000008.2.4.4.1.07
SendersResults, ReferralsSenders must design FT content for presentation with a monospaced font 
Anchor
8.2.4.4.1.8
8.2.4.4.1.8
HL7au:000008.2.4.4.1.08
SendersResults, ReferralsSenders must not use "\Xdddd...\" hexadecimal data escape sequences 
Anchor
8.2.4.4.1.9
8.2.4.4.1.9
HL7au:000008.2.4.4.1.09
SendersResults, ReferralsSenders must not use "\Zdddd..\" locally defined escape sequences 
Anchor
8.2.4.4.1.10
8.2.4.4.1.10
HL7au:000008.2.4.4.1.10
SendersResults, ReferralsSenders must not use "\.ce\" escape sequences. 
Anchor
8.2.4.4.1.11
8.2.4.4.1.11
HL7au:000008.2.4.4.1.11
SendersResults, ReferralsSenders must not break FT content into multiple components or repeats. 
Anchor
8.2.4.4.1.12
8.2.4.4.1.12
HL7au:000008.2.4.4.1.12
SendersResults, ReferralsSenders must limit intended display line lengths to 80 characters. 
Anchor
8.2.4.4.1.13
8.2.4.4.1.13
HL7au:000008.2.4.4.1.13
SendersResults, ReferralsSenders must not use "\M" escape sequences. 
Anchor
8.2.4.4.1.14
8.2.4.4.1.14
HL7au:000008.2.4.4.1.14
SendersResults, ReferralsSenders must not use "\C" escape sequences. 
Anchor
8.2.4.4.2
8.2.4.4.2
(HL7au:000008.2.4.4.2)
FT Display segment - Receiver
Anchor
8.2.4.4.2.1
8.2.4.4.2.1
HL7au:000008.2.4.4.2.01
ReceiversResults, Referrals(L2)FT datatype content SHALL be displayed using monospaced font  
Anchor
8.2.4.4.2.2
8.2.4.4.2.2
HL7au:000008.2.4.4.2.02
ReceiversResults, Referrals(L2)Receivers must de-escape "\F\" to the field separator character '|'

 

Anchor
8.2.4.4.2.3
8.2.4.4.2.3
HL7au:000008.2.4.4.2.03
ReceiversResults, Referrals(L2)Receivers must de-escape "\S\" to the component separator character '^' 
Anchor
8.2.4.4.2.4
8.2.4.4.2.4
HL7au:000008.2.4.4.2.04
ReceiversResults, Referrals(L2)Receivers must de-escape "\T\" to the sub-component separator character '&' 
Anchor
8.2.4.4.2.5
8.2.4.4.2.5
HL7au:000008.2.4.4.2.05
ReceiversResults, Referrals(L2)Receivers must de-escape "\R\" to the repetition character '~' 
Anchor
8.2.4.4.2.6
8.2.4.4.2.6
HL7au:000008.2.4.4.2.06
ReceiversResults, Referrals(L2)Receivers must de-escape "\E\" to the escape character '\' 
Anchor
8.2.4.4.2.7
8.2.4.4.2.7
HL7au:000008.2.4.4.2.07
ReceiversResults, Referrals(L2)Receivers must start highlighting text whenever "\H\" escape sequence is encountered 
Anchor
8.2.4.4.2.8
8.2.4.4.2.8
HL7au:000008.2.4.4.2.08
ReceiversResults, Referrals(L2)Receivers must end highlighting text whenever "\N\" escape sequence is encountered. 
Anchor
8.2.4.4.2.9
8.2.4.4.2.9
HL7au:000008.2.4.4.2.09
ReceiversResults, Referrals(L2)Receivers must support "\.sp <number>\" escape sequences, and must maintain horizontal position while skipping positive <number> vertical spaces. (If <number> is not specified 1 must be assumed). 
Anchor
8.2.4.4.2.10
8.2.4.4.2.10
HL7au:000008.2.4.4.2.10
ReceiversResults, Referrals(L2)Receivers must support "\.br\" escape sequence and must begin a new left justified line. 
Anchor
8.2.4.4.2.11
8.2.4.4.2.11
HL7au:000008.2.4.4.2.11
ReceiversResults, Referrals(L2)Receivers must support the fill mode (word wrap) "\.fi\" escape sequence. This means that after this sequence is encountered a soft line break must be introduced when horizontal space runs out. 
Anchor
8.2.4.4.2.12
8.2.4.4.2.12
HL7au:000008.2.4.4.2.12
ReceiversResults, Referrals(L2)Receivers must support the no fill mode (no word wrap) "\.nf\" escape sequence. This means after this sequence is encountered a soft line break must not be introduced when horizontal space runs out. 
Anchor
8.2.4.4.2.13
8.2.4.4.2.13
HL7au:000008.2.4.4.
2.13
ReceiversResults, Referrals(L2)Receivers must support indent "\.in <number>\" escape sequences. This means that on encountering this sequence each subsequent new line should be indented by positive <number> characters until the end of the document or another indent escape sequence sets the indent state. 
Anchor
8.2.4.4.2.14
8.2.4.4.2.14
HL7au:000008.2.4.4.
2.14
ReceiversResults, Referrals(L2)Receivers must support temporary indent "\.ti <number>\" escape sequences. This means that on encountering this sequence the first character of the each line in the paragraph (ie until \.br\ is encountered) will be indented to the absolute <number> value of fixed-width characters from the left hand side (not relative to the current .in value). 
Anchor
8.2.4.4.2.15
8.2.4.4.2.15
HL7au:000008.2.4.4.
2.15
ReceiversResults, Referrals(L2)Receivers must support skip "\.sk <number>\" escape sequences. This means that on encountering a skip sequence that the next character position will be advanced by <number> spaces to the right. 
Anchor
8.2.4.4.2.16
8.2.4.4.2.16
HL7au:000008.2.4.4.
2.16
ReceiversResults, Referrals(L2)Receivers must ensure that 80 characters of text (using a non-proportional font) can be displayed without word wrapping the line of text. 
Anchor
8.2.4.4.2.17
8.2.4.4.2.17
HL7au:000008.2.4.4.
2.17
ReceiversResultsReceivers must support 8859/1 character encoding when specified in MSH-18. 
Anchor
10
10
(HL7au:000010)
Digital signatures
HL7au:000010Receivers

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

Anchor
10.1
10.1
HL7au:000010.1
ReceiversOrders, Results, Referrals(L2)If a digital signature is received in an OBX segment, then the signature and report content should if possible be verified and the results presented to the user on the display with the report. 
     
Anchor
19
19
HL7au:000019
Senders and ReceiversOrders, Results, Referrals(L2)

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.



Anchor
20
20
HL7au:000020
SendersOrders, Results, Referrals(L2)

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

 

Anchor
21
21
HL7au:000021
SendersResults, Referrals(L2)Data type TX must NOT be used as a value in the OBX-2 Value Type field.

 

     
Anchor
22
22
(HL7au:000022)
File and Batch Segments
Anchor
22.1
22.1
HL7au:000022.1
SendersOrders, Results, ReferralsIf the batch header is used it must specify individual message acknowledgement. No information from the file header/footer or batch segments must be used. 
Anchor
22.2
22.2
HL7au:000022.2
ReceiversOrders, ResultsAll messages between the batch header (BHS) and the file trailer (FTS) must be acknowledged individually. The batch itself is not acknowledged.

 

Anchor
22.3
22.3
HL7au:000022.3
SendersReferralsSenders must generate batches containing no more than 1 message.
Anchor
22.4
22.4
HL7au:000022.4
ReceiversOrders, Results, ReferralsReceivers must support receiving messages contained inside HL7 batch protocol or a stand alone HL7 message.
Anchor
23
23
HL7au:000023
SendersOrders, Results, ReferralsThe NTE segment must NOT be used in messages.

 

Anchor
24
24
(HL7au:000024)
Delimiters of ‘|^~\&’ from HL7 V2.4 must be used in the message.

 

Anchor
24.1
24.1
HL7au:000024.1
SendersOrders, Results, ReferralsFHS, BHS, and MSH segments must specify the Field separator character as '|' 
Anchor
24.2
24.2
HL7au:000024.2
SendersOrders, Results, ReferralsFHS, BHS, and MSH segments must specify the Components separator character as '^' 
Anchor
24.3
24.3
HL7au:000024.3
SendersOrders, ResultsFHS, BHS, and MSH segments must specify the Sub-components separator characteras '&' 
Anchor
24.4
24.4
HL7au:000024.4
SendersOrders, ResultsFHS, BHS, and MSH segments must specify the repeat separator character as '~' 
Anchor
24.5
24.5
HL7au:000024.5
SendersOrders, ResultsFHS, BHS, and MSH segments must specify the escape separator character as '\' 
 General Conformance Points
Anchor
25
25
HL7au:000025
Senders

Orders, Results, Referrals

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

 
Anchor
26
26
HL7au:000026
SendersResults

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.

 
Anchor
26.2
26.2
HL7au:000026.2
SendersReferralsWhen sending copies of the same referral to multiple providers, the MSH-10 Message control ID must be unique in each message produced for each recipient, and the PRD "IR: Intended recipient role must be set appropriately for the intended recipient for each message. 
Anchor
27
27
HL7au:000027
SendersOrders, Results, Referrals

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

 
Anchor
28
28
HL7au:000028
SendersResultsWhen there are multiple OBR segments in an ORU message, the OBR-3 Filler order number must be unique within messages. 
HL7au:000028.2SendersReferralsWhen there are multiple OBR/OBX groups in a REF message, each OBR-3 Filler order number pair must be unique for each OBR/OBX group. 
Anchor
29
29
HL7au:000029
 
SendersResults, ReferralsWhen re-transmitting/forwarding a message content from one system to another the MSH-4 Sending facility must be the re-transmitting/forwarding Sending facility (HD components) and not the original authoring organisation (HD components). 
Anchor
30
30
HL7au:000030
SendersResults, ReferralsWhen re-transmitting/forwarding a message's content from one system to another the MSH-10 Message control ID must be unique for each message. 
Anchor
31
31
HL7au:000031

Senders

Results, Referrals

When re-transmitting/forwarding a message's content from one system to another OBR-3.2 Filler order number.namespace ID must be used for the display of the authoring organisation e.g. |123456^Path Lab Name^43210^AUSNATA|. The Filler order number of a result must not be changed. 
Anchor
32
32
HL7au:000032
SendersResultsIn the ORU message the field OBR-24 "Diagnostic serv sect ID" must be valued and must have values from HL7 table 0074 - diagnostic service section. 
Anchor
32.2
32.2
HL7au:000032.2
SendersReferralsIn the REF message the field OBR-24 "Diagnostic serv sect ID" must be valued and must have values from HL7 table 0074 - diagnostic service section appropriate for the content in the OBR/OBX group. 
Anchor
32.3
32.3
HL7au:000032.3
Receivers

Results, Referrals

If the receiving system has a various categories for their inbound communications in their application. eg. Letters, Radiology, then each OBR/OBX group content must be added to those by classifying the OBR/OBX group content based on OBR-24 value. PHY, LAB, RAD are the most common ones. The system must map each value in HL7 Table 0074 - Diagnostic service section ID  to the appropriate category. 
Anchor
33
33
HL7au:000033
SendersResultsIn Pathology ORU messages the field OBX-3 "Observation identifier" should, if possible, have values from the LOINC coding system except for display segments and digital signature OBX. 
     
Anchor
34
34
(HL7au:000034)
Use of Codes
Anchor
34.1
34.1
HL7au:000034.1
SendersResults, ReferralsWhen using CE, CWE, CNE data types in an OBX segment in either OBX-3 (Observation Identifier) or as an Observation Value, if the system transmits both the public (e.g. LOINC) and local terminology, then the public (eg LOINC) code must appear in the identifier.  
Anchor
34.2
34.2
HL7au:000034.2
SendersResults, ReferralsWhen using CE, CWE, CNE data types in an OBX segment, in OBX-3 (Observation Identifier), if the system transmits both a public (e.g. LOINC) and a local terminology, then the local terminology must be transmitted in the second CE triplet i.e. the alternate identifier. 
Anchor
34.3
34.3
HL7au:000034.3
SendersResults, ReferralsWhen using CE, CWE, CNE data types in an OBX segment, In either OBX-3 (Observation Identifier) or as an Observation Value, if the system transmits both a public (e.g. LOINC) and a local terminology, then concepts from the different terminologies must convey the same clinical meaning. Generally this means there is no need to populate the Alternate Text field. 
Anchor
34.4
34.4
HL7au:000034.4
ReceiversResultsReceivers must recognize Result and Report comment LOINC codes and Template ID/Section Header LOINC codes and display appropriately.See 4.6 Specific LOINC codes
Anchor
40
40
(HL7au:000040)
MSH-12 Version ID Field Conformance Points
Anchor
40.1
40.1
HL7au:000040.1
SendersOrders, Results, Referrals, ACK, RRISenders conforming to this specification must specify "2.4" as the value of version ID (ID) component of MSH-12 Version ID (VID) 

Anchor
40.2
40.2
HL7au:000040.2 (r2)

SendersOrders, Results, Referrals, ACK, RRIMSH-12 Version ID <internationalization code (CE)> component must be valued "AUS&Australia&ISO3166_1" 
Anchor
40.3
40.3
HL7au:000040.3
SendersOrders, ResultsMSH-12 Version ID <internal version ID (CE)> component must be valued as "HL7AU-OO-201701&&L". (Note that the number scheme used in this identifier is HL7 date format: YYYYMM)** errata

Anchor
40.4
40.4
HL7au:000040.4 (r2)

SendersReferrals, RRI

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)
The RRI should echo the received MSH-12 <internal version (ID)>. This is a hint to the SMD agent as to the service category to be used.

Anchor
40.5
40.5
HL7au:000040.5

Receivers

Orders, Results, Referrals

Receiving systems must use MSH-12 to affect the behaviour of message processing, when supporting various versions of the HL7 message standards and profiles. 
   

Anchor
41
41
HL7au:000041 (r2)

SendersOrders, Results, Referrals, ACK, RRIThe country of origin of the message must be specified in MSH-17 Country code. For Australian originators the value must be "AUS". 
Anchor
40.5
40.5
HL7au:000040.5
SendersOrders, Results, Referrals, ACK, RRIMSH-19 must be valued as "en^English^ISO639". 
Anchor
43
43
(HL7au:000043)
MSH-4 Sending Facility conformance points
Anchor
43.1
43.1
HL7au:000043.1
SendersOrders, 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.

** errata was inconsistent with 44.2.1
Anchor
43.2
43.2
HL7au:00043.2
ReceiversOrders, Results, ReferralsMSH-4 – Sending Facility when using SMD with NASH certificates must be validated against the SMD sending organisation. The message must be rejected if the SMD certificate does not match. (This is an anti spoofing check)** This conformance point applies only to SMD Agent implementers, this check should be performed before handing off a the message to the receiving system.
Anchor
43.3
43.3
HL7au:00043.3
SendersOrders, Results, ReferralsWhen SMD is used with vendor based certificates and identifiers, then the components of the MSH-4 HD must match with content of the sender as valued in the provider directory and also as identified in the senders X.509 certificate.
Anchor
43.4
43.4
HL7au:00043.4
SendersOrders, Results, ReferralsWhen SMD is used with vendor based certificates and identifiers, then the components of the MSH-6 HD must match with content of the receiver as valued in the provider directory and also as identified in the senders X.509 certificate.need detailed component mapping from directory and x.509 certs
Anchor
44
44
(HL7au:00044)

Datatype conformance points

Anchor
44.0.1
44.0.1
HL7au:00044.0.1
SendersOrders, Results, ReferralsUser defined datatypes are prohibited in all segment fields, components, and subcomponents. (Note that this prohibits the use of user defined datatypes in varable datatype fields such as OBX-5). 
Anchor
44.1
44.1
(HL7au:00044.1)
CX datatype conformance points
Anchor
44.1.1
44.1.1
HL7au:00044.1.1
SendersOrders, Results, ReferralsCX <ID (ST)> component must be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components. 

Anchor
44.1.2
44.1.2
HL7au:00044.1.2 (r2)

SendersOrders, Results, ReferralsCX <assigning authority (HD)> component must be valued and must conform to sub points of HL7au:00044.2. 
Anchor
44.1.3
44.1.3
HL7au:00044.1.3
SendersOrders, Results, ReferralsCX <identifier type code (ID)> component must be valued with a valid value from HL7 Table 0203 - Identifier type. 
Anchor
44.2
44.2
(HL7au:00044.2)
HD Datatype conformance points
Anchor
44.2.1
44.2.1
HL7au:00044.2.1
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the HD Namespace ID component must contain the registered organisation name as registered by in the Medicare Australia HPOS/HI service, otherwise it must contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) 
Anchor
44.2.2
44.2.2
HL7au:00044.2.2
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the HD Universal ID component must contain the HPI-O formatted as 1.2.36.1.2001.1003.0.<hpio>, otherwise it must contain the registered NATA number for the laboratory as published by NATA ( www.nata.com.au ) 
Anchor
44.2.3
44.2.3
HL7au:00044.2.3
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the HD Universal ID Type component must be "ISO", otherwise if the laboratory NATA number is number used in HD Universal ID Type must be "AUSNATA". 
Anchor
44.2.4
44.2.4
HL7au:00044.2.4
SendersOrders, Results, ReferralsWhen SMD is used with vendor based certificates and identifiers, then the components of the HD must match with content of the receiver as valued in the provider directory and also as identified in the organisation's X.509 certificate. 
Anchor
44.3
44.3
(HL7au:00044.3)
EI datatype conformance points
Anchor
44.3.1
44.3.1
HL7au:00044.3.1
SendersOrders, Results, ReferralsThe EI Entity identifier component must be valued 
Anchor
44.3.2
44.3.2
HL7au:00044.3.2
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the EI Namespace ID component must contain the registered organisation name as registered by in the Medicare Australia HPOS/HI service, otherwise it must contain the registered NATA name for the laboratory as published by NATA ( www.nata.com.au ) 
Anchor
44.3.4
44.3.4
HL7au:00044.3.4
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the EI Universal ID component must contain the HPI-O formatted as 1.2.36.1.2001.1003.0.<hpio>, otherwise it must contain the registered NATA number for the laboratory as published by NATA ( www.nata.com.au ) 
Anchor
44.3.3
44.3.3
HL7au:00044.3.3
SendersOrders, Results, ReferralsWhen SMD with NASH certificates are used the EI Universal ID Type component must be "ISO", otherwise if the laboratory NATA number is number used in EI Universal ID Type must be "AUSNATA". 
Anchor
44.3.4
44.3.4
HL7au:00044.3.4
SendersOrders, Results, ReferralsWhen SMD is used with vendor based certificates and identifiers, then the components of the HD must match with content of the receiver as valued in the provider directory and also as identified in the organisation's X.509 certificate. 
Anchor
44.4
44.4
(HL7au:00044.4)
CE datatype conformance points
Anchor
44.4.1
44.4.1
HL7au:00044.4.1
SendersOrders, Results, ReferralsWhen an <identifier (ST)> component is specified, the <name of the coding system> must also be specified. 
Anchor
44.4.2
44.4.2
HL7au:00044.4.2
SendersOrders, Results, ReferralsIf no <identifier (ST)> component is specified then no <name of coding system> (primary coding system) must be specified 
Anchor
44.4.3
44.4.3
HL7au:00044.4.3
SendersOrders, Results, Referrals<text (ST)> component must be valued as what is intended for display to the user. (In some locations user display is not intended and the text may be blank.) 
Anchor
44.4.4
44.4.4
HL7au:00044.4.4
SendersOrders, ResultsWhen multiple codes are used LOINC codes (LN) must be placed first using the identifier rather than the alternate identifier.  
Anchor
44.4.5
44.4.5
HL7au:00044.4.5
SendersOrders, Results, ReferralsWhen an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. 
Anchor
44.4.6
44.4.6
HL7au:00044.4.6
SendersOrders, Results, ReferralsIf no <alternate identifier (ST)> component is specified then no <name of alternate coding system> must be specified 
Anchor
44.4.7
44.4.7
HL7au:00044.4.7
SendersOrders, Results, Referrals

Both <identifer> 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.

 
Anchor
44.4.8
44.4.8
HL7au:00044.4.8
SendersOrders, Results, ReferralsAlternate coding system must be a different from the primary coding system. As the 2 codes must describe the same concept the alternate text is optional. 
Anchor
44.5
44.5
(HL7au:00044.5)
CNE datatype conformance points
Anchor
44.5.1
44.5.1
HL7au:00044.5.1
SendersOrders, Results, ReferralsAn <identifier (ST)> component is specified, the <name of the coding system> must also be specified. 
Anchor
44.5.2
44.5.2
HL7au:00044.5.2
SendersOrders, Results, ReferralsIf no <identifier (ST)> component is specified then no <name of coding system> must be specified 
Anchor
44.5.3
44.5.3
HL7au:00044.5.3
SendersOrders, Results, Referrals<text (ST)> component must be valued and this must be what is intended for display to the user. 
Anchor
44.5.4
44.5.4
HL7au:00044.5.4
SendersOrders, Results, ReferralsWhen an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. 
Anchor
44.5.5
44.5.5
HL7au:00044.5.5
SendersOrders, Results, ReferralsIf no <alternate identifier (ST)> component is specified then no <name of alternate coding system> must be specified 
Anchor
44.5.6
44.5.6
HL7au:00044.5.6
SendersOrders, Results, Referrals<alternate text (ST)> component must be valued and this must be what is intended for display to the user. 
Anchor
44.6
44.6
(HL7au:00044.6)
CWE datatype conformance points
Anchor
44.6.1
44.6.1
HL7au:00044.6.1
SendersOrders, Results, ReferralsWhen an <identifier (ST)> component is specified, the <name of the coding system> must also be specified. 
Anchor
44.6.2
44.6.2
HL7au:00044.6.2
SendersOrders, Results, ReferralsIf no <identifier (ST)> component is specified then no <name of coding system> must be specified 
Anchor
44.6.3
44.6.3
HL7au:00044.6.3
SendersOrders, Results, Referrals<text (ST)> component must be valued and this must be what is intended for display to the user. 
Anchor
44.6.4
44.6.4
HL7au:00044.6.4
SendersOrders, Results, ReferralsWhen an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified. 
Anchor
44.6.5
44.6.5
HL7au:00044.6.5
SendersOrders, Results, ReferralsIf no <alternate identifier (ST)> component is specified then no <name of alternate coding system> must be specified 
Anchor
44.6.6
44.6.6
HL7au:00044.6.6
SendersOrders, Results, Referrals<alternate text (ST)> component must be valued and this must be what is intended for display to the user. 
Anchor
44.7
44.7
(HL7au:00044.7)
XCN datatype conformance points
Anchor
44.7.1
44.7.1
HL7au:00044.7.1
SendersOrders, Results, ReferralsXCN <ID (ST)> component must be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components. 
Anchor
44.7.2
44.7.2
HL7au:00044.7.2
SendersOrders, Results, ReferralsXCN <assigning authority (HD)> component must be valued and valid. 
Anchor
44.7.3
44.7.3
HL7au:00044.7.3
SendersOrders, Results, ReferralsXCN <name type code (ID)> component must be valued and valid from HL7 Table 200. 
Anchor
44.7.4
44.7.4
HL7au:00044.7.4
SendersOrders, Results, ReferralsXCN <identifier type code (ID)> component must be valued with a valid value from HL7 Table 203. 
Anchor
44.7.5
44.7.5
HL7au:00044.7.5
SendersOrders, Results, ReferralsXCN <family name (FN)> :<surname (ST)> sub-component must to be valued. 
Anchor
44.7.6
44.7.6
HL7au:00044.7.6
SendersOrders, Results, ReferralsXCN <given name (ST)> should be valued. 
Anchor
44.8
44.8
(HL7au:00044.8)
TS datatype conformance points
Anchor
44.8.1
44.8.1
HL7au:00044.8.1
SendersOrders, Results, ReferralsCorrect timezone must be specified 
     
Anchor
44.10
44.10
(HL7au:00044.10)
ED datatype conformance points
Anchor
44.10.1
44.10.1
(HL7au:00044.10.1)
ED datatype - Senders
Anchor
44.10.1.1
44.10.1.1
HL7au:00044.10.1.1
SendersResults, ReferralsED <type of data (ID)> must be valued. 
Anchor
44.10.1.2
44.10.1.2
HL7au:00044.10.1.2
SendersResults, ReferralsED <data subtype (ID)> must be valued. 
Anchor
44.10.1.3
44.10.1.3
HL7au:00044.10.1.3
SendersResults, ReferralsED <encoding (ID)> must be valued. 
Anchor
44.10.1.4
44.10.1.4
HL7au:00044.10.1.4
SendersResults, ReferralsED <data (ST)> must be valued. 
Anchor
44.10.1.5
44.10.1.5
HL7au:00044.10.1.5
SendersResults, ReferralsWhen the ED <subtype (ID)> component is valued with a MIME sub-type value, then the corresponding MIME type must be used in the <Type of data (ID)> component. 
Anchor
44.10.1.6
44.10.1.6
HL7au:00044.10.1.6
SendersResults, ReferralsWhen the ED <subtype (ID)> component is valued with a HL7 2.4 defined <Subtype (ID)> (Table 0291)  value, then the corresponding HL7 2.4 type of data (Table 0191) must be used in the <Type of data (ID)> component. 
Anchor
44.10.2
44.10.2
(HL7au:00044.10.2)
ED datatype - Receivers
Anchor
44.10.2.1
44.10.2.1
HL7au:00044.10.2.1
ReceiversResults, ReferralsReceivers must process <type of data (ID)> component case insensitively. 
Anchor
44.10.2.2
44.10.2.2
HL7au:00044.10.2.2
ReceiversResults, ReferralsReceivers must process <data subtype (ID)> case insensitively. 
Anchor
44.10.2.3
44.10.2.3
HL7au:00044.10.2.3
ReceiversResults, ReferralsReceivers must process the <encoding (ID)> component case insensitively. 
   
Anchor
44.11
44.11
(HL7au:00044.11)
RP datatype conformance points
Anchor
44.11.1
44.11.1
(HL7au:00044.11.1)
RP datatype (senders)
Anchor
44.11.1.1
44.11.1.1
HL7au:00044.11.1.1
SendersResults, ReferralsRP <pointer (ST) > component must be valued 
Anchor
44.11.1.2
44.11.1.2
HL7au:00044.11.1.2
SendersResults, ReferralsRP <application ID (HD)> component must be valued 
Anchor
44.11.1.3
44.11.1.3
HL7au:00044.11.1.3
SendersResults, ReferralsRP <type of data (ID)> component must be valued 
Anchor
44.11.1.4
44.11.1.4
HL7au:00044.11.1.4
SendersResults, ReferralsRP <subtype (ID)> component must be valued 
Anchor
44.11.1.5
44.11.1.5
HL7au:00044.11.1.5
SendersResults, ReferralsWhen the RP <subtype (ID)> component is valued with a MIME sub-type value, then the corresponding MIME type must be used in the <Type of data (ID)> component. 
Anchor
44.11.1.6
44.11.1.6
HL7au:00044.11.1.6
SendersResults, ReferralsWhen the RP <subtype (ID)> component is valued with a HL7 2.4 defined <Subtype (ID)> (Table 0291)  value, then the corresponding HL7 2.4 type of data (Table 0191) must be used in the <Type of data (ID)> component. 
Anchor
44.11.1.7
44.11.1.7
HL7au:00044.11.1.7
ReceiversResults, Orders, Referrals

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.

See 4.6 Specific LOINC codes
Anchor
44.11.1.5
44.11.1.5
(HL7au:00044.11.1.5)
Encoding URLs into RP datatype
Anchor
44.11.1.5.1
44.11.1.5.1
HL7au:00044.11.1.5.1
SendersResults, ReferralsWhen "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the URL must be specified by the concatenation of the RP <application ID (HD)> component, <universal id (ST)> sub-component followed by the RP <pointer (ST)>. 
Anchor
44.11.1.5.2
44.11.1.5.2
HL7au:00044.11.1.5.2
SendersResults, ReferralsWhen "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the RP <application ID (HD)> component-<namespace id (IS)> sub-component must not be valued. 
Anchor
44.11.1.5.3
44.11.1.5.3
HL7au:00044.11.1.5.3
SendersResults, ReferralsWhen "URI" is specified in RP <application ID (HD)> component - <universal id type (ID)> sub-component value: the RP <application ID (HD)> component, <universal id (ST)> sub-component must be the scheme | server and application path parts of the URL. 
     
     
Anchor
45
45
(HL7au:00045)
Message Acknowledgement
Anchor
45.1
45.1
HL7au:00045.1
ReceiversOrdersReceivers of a valid ORM Order messages must produce an application level acknowledgement - order response message ORR and transmit it back to the original sender, when specified by MSH-16. 
Anchor
45.2
45.2
HL7au:00045.2
ReceiversResultsReceivers of valid ORU result messages must produce an application level acknowledgement - ACK^R01 and transmit it back to the original sender, when specified by MSH-16. 
Anchor
45.3
45.3
HL7au:00045.3
ReceiversOrders, Results, ReferralsReceiving systems unable to process a HL7 message must produce the appropriate reject or error application level application level acknowledgement and transmit it back to the sender, provided that the message has a valid MSH and Sending Facility and MSH Control ID field. 

Anchor
45.4
45.4
HL7au:00045.4 (r2)

ReceiversReferralsReceivers of valid (parsable) REF^I12 result messages must produce an application level acknowledgement - RRI^I12 and transmit it back to the original sender. 
Anchor
45.5
45.5
HL7au:000
45.5
SendersReferralsSenders of REF^I12 messages must have the capacity to receive and process RRI^I12 referral response (acknowledgement) messages and indicate success to the sender of the message, and report failures indicated in the response. 
Anchor
45.6
45.6
HL7au:000
45.6
SendersReferralsSenders of REF^I12 messages must publish in their secure messaging directory their capability to receive RRI^I12 acknowledgement messages. 

Anchor
45.7
45.7
HL7au:00045.7

SendersReferralsSecure 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 SMD agent must produce an error acknowledgement and return it to the sending application. 
Anchor
45.8
45.8
HL7au:000
45.8
ReceiversOrders, Results, Referrals, Acknowledgement, Referral ResponseReceivers must copy exactly all components of the received message's MSH-3 Sending Application field into the MSH-5 Receiving Application field of the acknowledgement / response message that they produce. 
Anchor
45.9
45.9
HL7au:000
45.9
ReceiversOrders, Results, Referrals, Acknowledgement, Referral ResponseReceivers must copy exactly all components of the received message's MSH-4 Sending Facility field into the MSH-6 Receiving Facility field of the acknowledgement / response message that they produce. 
Anchor
46
46
(HL7au:00046)
General HL7
Anchor
46.1
46.1
(HL7au:00046.1)
Sender Escaping Rules
Anchor
46.1.1
46.1.1
HL7au:00046.1.1

Senders

Orders, Results, ReferralsSenders must escape | characters as '\F\' in all fields, components, subcomponents 
Anchor
46.1.2
46.1.2
HL7au:00046.1.2
SendersOrders, Results, ReferralsSenders must escape '^' characters as '\S\' in all HL7 fields, components and subcomponents 
Anchor
46.1.3
46.1.3
HL7au:00046.1.3
SendersOrders, Results, ReferralsSenders must escape '&' characters as '\T\' in all HL7 fields, components and subcomponents 
Anchor
46.1.4
46.1.4
HL7au:00046.1.4
SendersOrders, Results, ReferralsSenders must escape '~' characters as '\R\' in all HL7 fields, components and subcomponents 
Anchor
46.1.5
46.1.5
HL7au:00046.1.5
SendersOrders, Results, ReferralsSenders must escape '\' characters as '\S\' in all HL7 fields, components and subcomponents 
Anchor
46.2
46.2
(HL7au:00046.2)
Receiver Escaping Rules
Anchor
46.2.1
46.2.1
HL7au:00046.2.1
ReceiversOrders, Results, ReferralsReceivers must unescape '\F\' escape sequences to character '|' for all fields, components, subcomponents 
Anchor
46.2.2
46.2.2
HL7au:00046.2.2
ReceiversOrders, Results, ReferralsReceivers must unescape '\S\' escape sequences to character '^' for all fields, components, subcomponents 
Anchor
46.2.3
46.2.3
HL7au:00046.2.3
ReceiversOrders, Results, ReferralsReceivers must unescape '\T\' escape sequences to character '&' for all fields, components, subcomponents 
Anchor
46.2.4
46.2.4
HL7au:00046.2.4
ReceiversOrders, Results, ReferralsReceivers must unescape '\R\' escape sequences to character '~' for all fields, components, subcomponents 
Anchor
46.2.5
46.2.5
HL7au:00046.2.5
ReceiversOrders, Results, ReferralsReceivers must unescape '\E\' escape sequences to character '\' for all fields, components, subcomponents 
Anchor
46.3
46.3
HL7au:00046.3
SendersOrders, Results, ReferralsAll fields required by HL7 segments table must be validly valued. 
Anchor
46.4
46.4
HL7au:00046.4
ReceiversOrders, Results, ReferralsReceiving implementations when receiving HL7 messages and converting their contents to data values must ignore segments, fields, components, sub-components, and extra repetitions of a field that are present but were not expected.HL7 2.4 2.11
Anchor
46.5
46.5
HL7au:00046.5
ReceiversOrders, Results, ReferralsReceiving implementations when receiving HL7 messages and converting their contents to data values must treat segments that were expected but are not present as consisting entirely of fields that are not present HL7 2.4 2.11
Anchor
46.6
46.6
HL7au:00046.6
ReceiversOrders, Results, ReferralsReceiving implementations when receiving HL7 messages and converting their contents to data values must treat fields and components that are expected but were not included in a segment as not present.
HL7 2.4 2.11
Anchor
47.1
47.1
HL7au:00047.1
SendersOrders, Results, ReferralsMSH-15 Accept acknowledgement type (ID) must be valued AL 
Anchor
47.2
47.2
HL7au:00047.2
SendersOrders, Results, ReferralsMSH-16 Application acknowledgement type (ID) must be valued AL 
Anchor
48.1
48.1
HL7au:00048.1
SendersOrders, Results, Referrals

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.

 
Anchor
48.2
48.2
HL7au:00048.2
SendersOrders, Results, ReferralsWhen MSH-18 is valued and is not "ASCII" encoding the message must not contain characters less than ASCII 32, except for ASCII 13 which must only be used as segment separator. 

Anchor
48.3.1
48.3.1
HL7au:00048.3.1 (r2)

SendersOrders, ResultsMSH-18 may only contain one of the following values "", "ASCII", "UNICODE UTF-8", "8859/1"** errata "UNICODE UTF-8" was incorrectly added as "UTF-8"
Anchor
48.3.2
48.3.2
HL7au:00048.3.2
SendersReferralsMSH-18 must only contain one of the following values "", "ASCII".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.

Anchor
48.3.3
48.3.3
HL7au:00048.3.3

SendersOrders, Results, ReferralsThe encoding of characters in the message must match the value specified in MSH-18 
Anchor
48.4
48.4
HL7au:00048.4
SendersOrders, ResultsWhen "UNICODE" is specified in MSH-18 a byte order mark (BOM) must be present at the start of the transmission. 
Anchor
49.1
49.1
HL7au:00049.1
SendersOrders, Results, ReferralsMSH-9 Message type <message type (ID)> component must be valued. 
Anchor
49.2
49.2
HL7au:00049.2
SendersOrders, Results, ReferralsMSH-9 Message type <trigger event (ID)> component must be valued. 
Anchor
49.3
49.3
HL7au:00049.3
SendersOrders, Results, ReferralsMSH-9 Message type <message structure (ID)> component must be valued. 

Anchor
50.1
50.1
HL7au:00050.1

Pathology Sending


Anchor
50.1.2
50.1.2
HL7au:00050.1.2

Senders (Pathology only)ResultsWhen sending pathology messages OBX-3 must be valued according to the APUTS standard where a code is available. 
Anchor
50.1.3
50.1.3
HL7au:00050.1.3
Senders (Pathology only)Results

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

 
Anchor
50.1.4
50.1.4
HL7au:00050.1.4
Senders (Pathology only)Results

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

 
Anchor
50.1.5
50.1.5
HL7au:00050.1.5
Senders (Pathology only)ResultsThe OBX-6 (Units) <name of coding system (IS)> component must be "UCUM". 
Anchor
50.1.6
50.1.6
HL7au:00050.1.6
Senders (Pathology only)ResultsThe OBX-7 References range (ST) should be valued as the APUTS harmonised reference intervals where defined and applicable. 
Anchor
50.1.7
50.1.7
HL7au:00050.1.7
Senders (Pathology only)ResultsDisplay segments must be produced according to the APUTS Chapter 7 rendering rules. 
Anchor
50.2.1
50.2.1
HL7au:00050.2.1
ReceiversResultsWhere a receiving system renders an atomic pathology result it must comply with the rendering APUTS Chapter 7 rendering rules. 
Anchor
50.2.2
50.2.2
HL7au:00050.2.2
ReceiversResultsWhen rendering a cumulative table or graph of pathology data, do not combine series which have different LOINC codes or have the "Do not combine" flag indicated in any repeat of OBX-17 which is indicated by "765921000168105^Do not combine laboratory test result^SCT".See 4.13
Anchor
60.1
60.1
HL7au:00060.1
Senders

Orders, Results, Referrals

HL7 message elements with a usage of R (required) must be valued. 
Anchor
60.2
60.2
HL7au:00060.2
SendersOrders, Results, ReferralsHL7 message elements with a usage of RE (required or empty) must be valued, except if the data is unknown to the sending application. 
Anchor
60.3
60.3
HL7au:00060.3
SendersOrders, Results, ReferralsHL7 message elements with a usage of C (conditional) must be valued when the associated predicate is satisfied.From HL7 Conformance Implementation Manual.
Anchor
60.4
60.4
HL7au:00060.4
SendersOrders, Results, ReferralsHL7 message elements with a usage of C (conditional) must not be valued when the associated predicate is not satisfied.From HL7 Conformance Implementation Manual.
Anchor
60.5
60.5
HL7au:00060.5
SendersOrders, Results, ReferralsHL7 message elements with a usage of CE (condition or empty) must be valued when known to the application, and must be unvalued when the application does not know the value. 
Anchor
60.6
60.6
HL7au:00060.6
SendersOrders, Results, ReferralsSending application must be capable of knowing which conditional elements to populate when conditonal rules (predicate) are satisfied for conditional or empty elements.

Adapted from HL7 Conformance Implementation Manual.

Anchor
60.7
60.7
HL7au:00060.7
SendersOrders, Results, ReferralsHL7 message elements with a usage of CE (condition or empty) must not be valued when the associated predicate (conditonal rule) is not satisfied.Adapted from HL7 Conformance Implementation Manual.
Anchor
61.1
61.1
HL7au:00061.1
ReceiversOrders, Results, ReferralsIf a HL7 message element with a usage of CE is not present, the receiving application shall not raise an error due to the presence or absence of the element. 
     

Anchor
100.1
100.1
HL7au:00100.1 (r2)

SendersReferrals

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



Anchor
100.2
100.2
HL7au:00100.2
ReceiversReferrals(L2)The receiver when displaying the inbound referral, must primarily show the content of a referral letter display segment belonging the Clinical Information for the referral OBR/OBX group indicated by the OBR-4 code as per section 4.4.1.4.1 OBR-4 codes in referral messages. 

Anchor
100.3
100.3
HL7au:00100.3 (r3)

ReceiversReferrals(L2)The receiver must also show clearly that there is supporting information for the referral and allow the user to view those, each must have a either a PDF/HTML/TXT/RTF display segment.  
Anchor
101.1
101.1
HL7au:00101.1
SendersResults, Referrals(L2)Each OBR/OBX group may contain arbitrary encapsulated data attachments as per 4.26 Encapsulated data attachments. 
Anchor
101.2
101.2
HL7au:00101.2
Senders

Results, Referrals(L2)

Encapsulated data attachments must use Base64 encoding. 
Anchor
101.3
101.3
HL7au:00101.3
SendersResults, Referrals(L2)Senders must not send critical data in encapsulated data attachments, since it may be unreliable in that the MIME type may be unsupported by the receiver and content unviewable. 
Anchor
101.4
101.4
HL7au:00101.4
ReceiversResults, Referrals(L2)While displaying the content for each OBR/OBX group any encapsulated data attachments as described in 4.26 Encapsulated data attachments must be listed to the user. 
Anchor
101.5
101.5
HL7au:00101.5
ReceiversResults, Referrals(L2)Encapsulated data attachments listed to the user in the previous point must be accessible to the user if a suitable viewer for the MIME type and MIME subtype is available on the system. 
Anchor
101.6
101.6
HL7au:00101.6
ReceiversResults, Referrals(L2)Receivers must support viewing attachments with MIME type/subtype of application/pdf and text/html. 
Anchor
101.7
101.7
HL7au:00101.7
ReceiversResults, 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

 
Anchor
101.8
101.8
HL7au:00101.8
ReceiversResults, Referrals(L2)Receiver systems must restrict access to attachments of trusted MIME types (the trusted MIME types may be configurable according to an organisation policy). 

Anchor
102.1.2
102.1.2
HL7au:00102.1.2 (r2)

SendersReferralsFor the "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 Report template ID OBX must be included when atomic data is to be provided and it must specify the unique root sub id in OBX-4 subID. eg sub id "1" 

Anchor
102.2.1
102.2.1
HL7au:00102.2.1 (r2)

SendersReferralsFor the "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, atomic data must be sent in OBXs with their appropriate OBX-2 value as specified the method specified in Appendix 9 HL7v2 Virtual Medical Record 

Anchor
102.2.2
102.2.2
HL7au:00102.2.2 (r2)

SendersReferralsFor the "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, atomic data must be sent in OBXs with their appropriate OBX-3 value as specified the method specified in Appendix 9 HL7v2 Virtual Medical Record 

Anchor
102.2.3
102.2.3
HL7au:00102.2.3 (r2)

SendersReferralsFor the "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, atomic data must be sent in OBXs with their appropriate OBX-4 subID value relative to the subID specified in the Report template ID OBX as specified the method specified in Appendix 9 HL7v2 Virtual Medical Record 

Anchor
103.3
103.3
HL7au:00103.3 (r2)

SendersReferrals

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. 

 

Anchor
104.1.1
104.1.1
HL7au:00104.1.1

SendersReferralsThere must be exactly one PRD with a PRD-1 value of "AP" (Authoring Provider) in the REF message. 
Anchor
104.1.2
104.1.2
HL7au:00
104.1.1
ReceiversReferralsThe receiving system must identify the authoring provider in its display of the message content (indicated by "AP" in the associated PRD-1). 
Anchor
104.2.1
104.2.1
HL7au:00
104.2.1
SendersReferralsThere must be exactly one PRD with a PRD-1 value of "IR" (Intended Recipient) in the REF message. 
Anchor
104.2.2
104.2.2
HL7au:00
104.2.2
ReceiversReferralsThe receiving system must present the referral message to intended recipient indicated by PRD-1 value of "IR". 

Anchor
104.7.0
104.7.0

HL7au:00104.7.0 (r2)

SendersReferralsPRD-7 must have at least 1 repeat (for providers receiving electronic communication). 

Anchor
104.7.1.2
104.7.1.2
HL7au:00104.7.1.2

SendersReferralsPRD-7 <ID number (ST)> must be valuedwith a location or organisationally scoped identifier (for providers receiving electronic communication). 

Anchor
104.7.1.3
104.7.1.3
HL7au:00104.7.1.3 (r2)

SendersReferralsPRD-7 <ID number (ST)> must not contain an HPI-I value (for providers receiving electronic communication).HPI-I values must be qualified by the HPI-O. See NPIO in HL7 Table 0203 - Identifier Type.

Anchor
104.7.1.4
104.7.1.4
HL7au:00104.7.1.4

SendersReferrals

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

 
Anchor
104.7.2.1
104.7.2.1
HL7au:00104.7.2.1
SendersReferralsPRD-7 <type of ID number (IS)> must be valued from User-defined Table 0363 - Assigning Authority 
Anchor
104.7.3.1
104.7.3.1
HL7au:00104.7.3.1
SendersReferrals<other qualifying info (ST)> must be a valued from HL7 Table 0203 - Identifier Type. 
     

Anchor
110.1
110.1
HL7au:00110.1

Senders

Orders, Results, Referrals, Acknowledgment, Referral Response

Senders must populate the MSH-3 Sending application (HD) field components as per the values specified in the provider directory of their secure messaging system being used.The intent of this point is to enable a receiver the ability to lookup the sender in the directory, which will allow return messaging. This also applies to senders of acknowledgements.
Anchor
110.2
110.2
HL7au:00110.2
SendersOrders, Results, Referrals, Acknowledgment, Referral ResponseSenders must populate the MSH-4 Sending facility (HD) field components as per the values specified in the provider directory of their secure messaging system being used.The intent of this point is to enable a receiver the ability to lookup the sender in the directory, which will allow return messaging. This also applies to senders of acknowledgements.
     

...