Page tree
Skip to end of metadata
Go to start of metadata

A8.1 Purpose

The purpose of this simplified REF profile is to enable widespread messaging by compliant implementations through reducing the requirements on implementers by specifying a smaller constrained subset of the patient referral message.

A8.2 Conformance

A8.2.1 Conformance Levels

This profile defines 2 levels of conformance.

A8.2.1.1 Referral Level 1

Level 1 focuses on baseline receiving capability of a single OBR observation group containing a PDF display segment. Receivers must to be able to display this PDF display segment. Senders must send a PDF display segment. There is no requirement on receivers to be able to display other display segment types if present. Atomic data may still be present. Attachments are not supported in Level 1.

A8.2.1.2 Referral Level 2

Level 2 allows for multiple OBR observation groups and guarantees receivers support all display segment types (HTML, PDF, RTF,  TXT (FT)).  Senders may choose which display segment formats to send but must send at least one. Attachments are supported in this level. 

A8.2.1.3 Referral Level 1 & 2 Common requirements

Note that both levels require that atomic data such as allergy/medication/patient history data can be received without error. The display segment(s) of level 1 and 2 are required to represent any atomic data. There is no requirement to process the atomic data for viewing by a user.

A8.2.2 Conformance Statements

Many of the conformance statements that apply to this profile also apply to other uses of the broader standard such as pathology messages such as ORU, so these stated in a common place.

Refer to Appendix 5 Conformance Statements (Normative) for a list of conformance statements that aren't referenced here. The table there indicates relevant points by "Referrals" in the Message Type Applicability column of the table.

In the following sections some of these conformance statements in Appendix 5 will be referenced simply by citing the HL7au: identifier for the conformance point, however, not every required point will be referenced in this section.

A8.3 Sender Conformance

Senders must signal conformance with these profile levels by populating MSH-12 Version ID field with the following components for all messages part of the profile:

Referral Level 2 conformance:

MSH-12 Version ID field content
2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706&&L

Refer to HL7au:000040.4

Referral Level 1 conformance:

MSH-12 Version ID field content
2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L

A8.4 Receiver Conformance

Receivers may indicate conformance to the simplified REF profiles in a directory or communicated in out-of-band site to site agreement.

Identifiers derived from the following can be used

 
HL7AU-OO-REF-SIMPLIFIED-201706
HL7AU-OO-REF-SIMPLIFIED-201706-L1

If a directory requires an identifier in the form of a URI then the following must be specified to indicate receiver conformance to this profile.

A8.4.1 Referral Level 1

For REF^I12 messages:

http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1

For RRI^I12 (referral response) messages:

http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706/RRI

A8.4.2 Referral Level 2

For REF^I12 messages:

http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706

For RRI^I12 (referral response) messages:

http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706/RRI

A8.5 Simplified REF profile message structure

For the purposes of compliance with this profile, the REF_I12 structure of chapter 7 is replaced with the following message structure.

Constrained REF_I12 message structure
MSH                                Message Header 
RF1                                Referral Information
{PRD}                              Provider Data
PID                                Patient Identification
[{AL1}]                            Allergy Information
{
	ORC                            Common Order
	OBR                            Observation Request
	{OBX}                          Observation/Result
}
PV1                                Patient Visit
[PV2]                              Patient Visit Additional Info
[{                            
    ORC                            Common Order 
    RXO                            Pharmacy/Treatment Order
    {RXR}                          Pharmacy/Treatment Route
    [{RXC}]                        Pharmacy/Treatment Component Order
    [{OBX}]                        Observation/Result
}]

 

This profile uses the same RRI_I12 message structure as specified in Chapter 7 Patient Referral.

 

A8.6 Character Set

All receivers must support ASCII character. Refer to HL7au:00048.3.2.

Character set 8859/1 and UNICODE UTF8 are unsupported by this profile.

 

A8.7 Clinical Information

The referral message must contain exactly one ORC/OBR/ group which is indicated as clinical information (ORC-1 Order Control = 'IN') which is the main body of the referral. It must include one or more display segments formats which represent all atomic information. Refer to 8.7 Atomic Information. References to attachments must be included in the display segment.

The OBR-24 Diagnostic serv sect ID (ID) (Section 4.4.1.24) must be valued. Refer to HL7au:000032.2.

A8.7.1 Senders

Senders must place "PHY" into OBR-24 Diagnostic serv sect ID (ID) (Section 4.4.1.24)

A8.7.2 Receivers

Where multiple inboxes are used in a receiving system, the value of OBR-24 must be used to direct the data to the appropriate inbox. Refer to HL7au:000032.3.

A8.8 Atomic information

A8.8.1 Receiver

Whenever atomic data is present a receiving system can just display the display segment, but must not fail to process a message containing atomic data.

A8.8.2 Sender

Unlike laboratory messages it is allowable for senders to include whatever atomic data is available. The display segment can include data items that are not present as atomic data.

Atomic information for the message will be allergies, medications and observations. If atomic medications are include they must be represented in the RXO segment groups. If the atomic allergy information is included, it must be represented in the AL1 segments. Observations which can be represented as part of the HL7v2 Virtual Medical Record (HL7v2 VMR) should use that structure to do so. Refer to Appendix 9 HL7v2 Virtual Medical Record for instructions on how to use that. Further observations which cannot be represented in the structures already provided may use additional OBX observation segments inside the referral clinical information group but must not share the OBX-4 sub ID root with the HL7v2 VMR (i.e. They must not be "1" or start with "1." as this is reserved for the HL7v2 VMR) (Refer to 7.3.13 OBX and 4 Observation Reporting).

Atomic information should be supplied where available.

All atomic information must be redundant in the sense that it must also be represented within the display segments of the same ORC/OBR group.

Refer to HL7au:000008.2.1 and HL7au:000008.2.2.

A8.9 Display Segments

Display segments are defined in Section 7.5 Display Segments and 4.5 Display Segments.

Each ORC/OBR group must have at least one display segment.

For this profile receivers must allow viewing the display segments for each ORC/OBR group. Refer to HL7au:00103.3.

Refer to the conformance points under HL7au:000008 that apply to referral messages.

 

Senders must send one or more display formats in the following form HTML, PDF, TXT (HL7 FT). HL7au:000008.3.1

Senders may send RTF is optional extra display format. HL7au:000008.1HL7au:000008.3.2

Receivers must be able to support the display of all display formats HL7au:000008.1.1. (Some may be viewed with an embedded viewer and external viewer, while others may be viewed with just an external viewer e.g. RTF).

A8.10 Supporting Observations or Performed Services.

The referral message may contain zero or more ORC/OBR groups which are indicated as supporting information (ORC-1 Order Control = 'RE'). These may be forwarded copies of reports such as pathology tests or radiology reports or other documents.

A8.10.1 Referral creators/senders

Referral creators must be provided an opportunity to select diagnostic items to include in the referral composition. The sender's system must copy from the selected items the original ORC/OBR/OBX segment groups and fields of the message (e.g. ORU) and include those in the REF message, ensuring that the ORC-1 Order control (ID) (Refer to 7.3.11.1) value is replaced with the value 'RE'. It is important that the fields in these segments is preserved from the original sender, especially OBR-22 Results rpt/status chng (Refer to section 4.4.1.22). Since ORC is optional in the ORU message, it may be necessary for the system to synthesis a ORC segment, including required fields and be consistent.

A8.10.2 Referral receivers

Receiving systems must display supporting information indicated by ORC-1 Order Control value of 'RE' to the user along with the main body of the referral as well as file these appropriately into the correct area based on OBR-24 Diagnostic serv sect ID (ID) (Section 4.4.1.24) value. 

Where receiving implementations have inbox categories such as "Pathology", "Radiology" and "Clinical"/"Other" in their systems, implementers must refer to HL7 Table 0074 - Diagnostic service section ID and direct data to these appropriate inboxes. Here is an example mapping for such a scenario (informative only).

An example mapping of HL7 Table 0074 - Diagnostic service section ID where a system might have bins for "Pathology" / "Radiology" and "Other" is provided below - This is Informative

Value
Description
Pathology / Radiology / Other
AUAudiologyOther
BGBlood GasesPathology
BLBBlood BankPathology
CGCytogeneticsOther
CUSCardiac UltrasoundRadiology
CTHCardiac CatheterizationOther
CTCAT ScanRadiology
CHChemistryPathology
CPCytopathologyPathology
EC

Electrocardiac (e.g. ECG, EEC, Holter)

Other
ENElectroneuroOther
GE †GeneticsOther
HMHaematologyPathology
ICUBedside ICU MonitoringOther
IMMImmunologyPathology
LAB

Regional laboratory (departments not distinguishable)

Pathology
MBMicrobiologyPathology
MCBMycobacteriologyPathology
MYCMycologyPathology
NMRNuclear Magnetic ResonanceRadiology
NMSNuclear Medicine ScanRadiology
NRS

Nursing Services Measures

Other
OUSOB UltrasoundRadiology

OT

Occupational TherapyOther
OTHOtherOther
OSLOutside LabPathology
PHRPharmacyOther
PTPhysical TherapyOther
PHY

Physician (Hx. Dx, admission note, etc)

Other
PFPulmonary FunctionOther
RADRadiologyRadiology
RUSRadiology UltrasoundRadiology
RC

Respiratory Care (therapy)

Other
RTRadiation TherapyOther
RXRadiographRadiology
SRSerologyPathology
SP

Histology and Anatomical Pathology

Pathology
TXToxicologyPathology
VUSVascular UltrasoundRadiology
VRVirologyPathology
XRCCineradiographOther

Refer to HL7au:000032.3.

A8.11 Encapsulated data attachments

Attachments may be attached by to the main clinical information of the referral indicated by ORC-1 Order Control "IN", or to any additional performed services observations.

Refer to Section 4.26 Encapsulated data attachments and conformance points under HL7au:00101.

A8.12 Addressing

Message addressing happens at three layers.

Patient Referral (REF) messages have both facility/organisational and intended provider/individual recipient level addressing, and optionally application level.

Referral responses RRI are always routed based on MSH-6 and MSH-4 fields.

A8.12.1 Facility/Organisational level addressing

The first layer is the facility/organisation level

A8.12.1.1 MSH-4 Sending facility (HD)

Firstly the sender must indicate that it is sending the message by setting the components of the MSH-4 Sending facility (HD) (Section 2.1.9.4). The values for this must be the ones which have been published in the directory of the secure messaging system being used for the messaging transaction. Refer to sub points of HL7au:000043, and points  HL7au:000025HL7au:000029.

 

A8.12.1.1.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from sending party's HealthcareService.Endpoint[x].au-receivingfacility as published in the directory of the messaging system being used for the transaction.

Each component of the MSH-4 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingfacility as per the following table.

HD Componenthttp://hl7.org.au/fhir/StructureDefinition/au-receivingfacility extension
<namespace ID (IS)> namespace-id
<universal ID (ST)>universal-id
<universal ID type (ID)>universal-id-type

 

A8.12.1.2 MSH-6 Receiving facility (HD)

Secondly the sender must specify the destination for the message in MSH-6 Sending facility(HD) (Section 2.1.9.6) as per the values provided by the secure messaging system's directory that will be used to transmit the message.

A8.12.1.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.Endpoint[x].au-receivingfacility as published in the directory of the messaging system being used for the transaction.

Each component of the MSH-6 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingfacility as per the following table.

HD Componenthttp://hl7.org.au/fhir/StructureDefinition/au-receivingfacility extension
<namespace ID (IS)> namespace-id
<universal ID (ST)>universal-id
<universal ID type (ID)>universal-id-type

 

A8.12.2 Intended Provider/Individual recipient level addressing

The second layer is the individual provider level. This layer is used by the receiving software to deliver the received message to the intended recipient. (It may also be used by the secure messaging systems as a backup routing mechanism to resolve endpoints where MSH-6 Receiving facility (HD) cannot be used based on provider to organisational mappings available in those systems.)

For the referral message individual provider/recipient level addressing is performed using the PRD segments.

Although for a specific message only 2 providers are necessary, additional providers involved with the patient care must also have their PRD segments populated from a reliable provider directory source such that receivers can utilise the information and include those providers in future correspondence, this means that PRD-2 and PRD-7 must be populated for a all PRD segments according to the same rules.

A8.12.2.1 PRD-1 Provider role (CE)

For details of this field refer to Refer to 7.3.3.1 PRD-1 Provider role (CE).

Sending systems must indicate a single authoring provider of the message by indicating the PRD segment as "AP" in PRD-1 (see Table 0286)

Sending systems must indicate a single intended provider recipient for each message by indicating that provider's PRD segment with "IR" in PRD-1.

Both of these are done using PRD segments (see 7.3.3 PRD - Provider Data segment).

In addition to the Authoring and Intended Recipient providers, an appropriate provider role must be set for each provider according to the referral scenario.

A8.12.2.2 PRD-2 Provider name (XPN)

For details of this field refer to Refer to 7.3.3.2 PRD-2 Provider name (XPN).

This field is where the name of the provider for the PRD must be populated. For the intended recipient and authoring provider, these fields must be populated from the provider directory service of the secure messaging system being used to transmit the message. 

Two classes of provider are supported:

  • Individual Practitioner providers
  • Healthcare Service Providers

Each class of provider has different mapping rules for population from the provider directory into PRD-2 Provider name (XPN) name component and subcomponents. (See 7.3.2.2 PRD-2 Provider name (XPN)).

A8.12.2.2.1 Individual Practitioner providers
A8.12.2.2.1.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's PractitionerRole.practioner resource as published in the directory of the messaging system being used for the transaction.

XPN Component / sub-componentFhirResource elementComment
<family name (FN)>- 
<surname (ST)>PractitionerRole.practioner.name[usual].family 
<own surname prefix (ST)>- 
<own surname (ST)>- 
<surname prefix from partner/spouse (ST)>- 
<surname from partner/spouse (ST)>- 
<given name (ST)> PractitionerRole.practioner.name[usual].given[0] 
<second and further given names or initials thereof (ST)>PractitionerRole.practioner.name[usual].given[1..*]Concatenate with spaces separating names
 <suffix (e.g., JR or III) (ST)>PractitionerRole.practioner.name[usual].suffix 
<prefix (e.g., DR) (ST)>PractitionerRole.practioner.name[usual].prefix 
<degree (e.g., MD) (IS)> - 
<name type code (ID) >PractitionerRole.practioner.name[usual].use. Apply the concept mapping cm-name-use-v2.

See Table 0200

For usual use "D". For official use "L"

<name representation code (ID)>- 
<name context (CE)>- 
<name validity range (DR)> - 
<name assembly order (ID)>- 

A8.12.2.2.2 Healthcare Service Providers
A8.12.2.2.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.name as published in the directory of the messaging system being used for the transaction.

XPN Component / sub-componentFhirResource elementComment
<family name (FN)>- 
<surname (ST)>HealthcareService.providedBy.nameeg. The medical centre's name
<own surname prefix (ST)>- 
<own surname (ST)>- 
<surname prefix from partner/spouse (ST)>- 
<surname from partner/spouse (ST)>- 
<given name (ST)> HealthcareService.nameName of the service. eg. "General Practice"
<second and further given names or initials thereof (ST)>HealthcareService.location.nameeg "Essendon"
 <suffix (e.g., JR or III) (ST)>  
<prefix (e.g., DR) (ST)>  
<degree (e.g., MD) (IS)>   
<name type code (ID) >"D"

See Table 0200

For usual, use "D". For official, use "L"

<name representation code (ID)>- 
<name context (CE)>- 
<name validity range (DR)>- 
<name assembly order (ID)>- 

 

A8.12.2.3 PRD-3 Provider address (XAD)

For details of this field refer to Refer to 7.3.3.3 PRD-3 Provider address (XAD).

This field is where the name of the recipient be populated. These fields must be populated from the provider directory service of the secure messaging system being used to transmit the message.

Two classes of provider are supported:

  • Individual Practitioner providers
  • Healthcare Service Providers

Each class of provider has different mapping rules for population of fields from the provider directory into PRD-3 Provider address (XAD) name component and subcomponents. (See 7.3.3.3 PRD-3 Provider address (XAD))

A8.12.2.3.1 Individual Practitioner providers
A8.12.2.3.1.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's PractitionerRole.location address data type as published in the directory of the messaging system being used for the transaction.

XAD Component / sub-componentFhirResource elementComment
<street address (SAD)>  
<street or mailing address (ST)>PractitionerRole.location.address 
<street name (ST)>  
<dwelling number (ST)>  
<other designation (ST)>  
<city (ST)>PractitionerRole.location.address.city 
<state or province (ST)>PractitionerRole.location.address.state 
<zip or postal code (ST)>PractitionerRole.location.address.postalCode 
<country (ID)>PractitionerRole.location.address.country 
<address type (ID)>PractitionerRole.location.address.type

Map values for postal or office.

postal = 'M'

physical = 'O'

<other geographic designation (ST)>  
<county/parish code (IS)>  
<census tract (IS)>  
<address representation code (ID)>   
<address validity range (DR)>  
<date range start date/time (TS)>  
<date range end date/time (TS)>  


A8.12.2.3.2 Healthcare Service providers
A8.12.2.3.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's HealthcareService.location address data type as published in the directory of the messaging system being used for the transaction.

XAD Component / sub-componentFhirResource elementComment
<street address (SAD)>  
<street or mailing address (ST)>HealthcareService.location.address 
<street name (ST)>  
<dwelling number (ST)>  
<other designation (ST)>  
<city (ST)>  HealthcareService.location.address.city 
<state or province (ST)>HealthcareService.location.address.state 
<zip or postal code (ST)>HealthcareService.location.address.postalCode 
<country (ID)> ^HealthcareService.location.address.country 
< address type (ID)>HealthcareService.location.address.type

Map values for postal or office.

postal = 'M'

physical = 'O'

<other geographic designation (ST)>  
<county/parish code (IS)>  
<census tract (IS)>  
<address representation code (ID)>   
<address validity range (DR)>  
<date range start date/time (TS)>  
<date range end date/time (TS)>  

A8.12.2.5 PRD-5 Provider communication information (XTN)

For details of this field refer to Refer to 7.3.3.5 PRD-5 Provider communication information (XTN).

A8.12.2.5.1 Individual Practitioner providers

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's PractitionerRole.telecom data type as published in the directory of the messaging system being used for the transaction.

 

A8.12.2.5.1.1 Australian Profile for Provider Directory Services
XTN Component / sub-componentFhirResource elementComment
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] PractitionerRole.telecom.valueif ContactPoint.use.code is either phone, fax, pager, sms
<telecommunication use code (ID)> PractitionerRole.telecom.useApply the concept mapping cm-contact-point-use-v2.
<telecommunication equipment type (ID)> PractitionerRole.telecom.systemApply the concept mapping cm-contact-point-system-v2.
<email address (ST)>PractitionerRole.telecom.valueif ContactPoint.use.code = email
<country code (NM)>  
<area/city code (NM)>   
<phone number (NM)>  
<extension (NM)>  
<any text (ST)>  
A8.12.2.5.2 Healthcare Service providers
A8.12.2.5.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's HealthcareService.telecom data type as published in the directory of the messaging system being used for the transaction.

XTN Component / sub-componentFhirResource elementComment
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] HealthcareService.telecom.valueif ContactPoint.use.code is either phone, fax, pager, sms

<telecommunication use code (ID)> 

 

HealthcareService.telecom.useApply the concept mapping cm-contact-point-use-v2.
<telecommunication equipment type (ID)> HealthcareService.telecom.systemApply the concept mapping cm-contact-point-system-v2.
<email address (ST)>HealthcareService.telecom.valueif ContactPoint.use.code = email
<country code (NM)>  
<area/city code (NM)>   
<phone number (NM)>  
<extension (NM)>  
<any text (ST)>  

A8.12.2.7 PRD-7 Provider identifiers (CM)

For details of this field refer to Refer to 7.3.3.7 PRD-7 Provider identifiers (CM).

A8.12.2.7.1 Individual Practitioner providers
A8.12.2.7.1.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's PractitionerRole.identifier data type as published in the directory of the messaging system being used for the transaction.

There may be multiple identifiers in the PractionerRole identifier list. It is important to map the routable identifers in the order specified in the directory entry.  Note that HL7v2 systems often will consider only the first repeat of this field.

CM Component / sub-componentFhirResource elementComment
<ID number (ST)>PractitionerRole.identifier.value 
<type of ID number (IS)>PractitionerRole.identifier.au-assigningauthority.namespace-id 
<other qualifying info (ST)>PractitionerRole.identifier.type.coding.codeeg. "VDI" or "UPIN"
A8.12.2.7.2 Healthcare Service providers
A8.12.2.7.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving provider's HealthcareService.identifier data type as published in the directory of the messaging system being used for the transaction.

 

CM Component / sub-componentFhirResource elementComment
<ID number (ST)>HealthcareService.identifier.value 
<type of ID number (IS)>HealthcareService.identifier.au-assigningauthority.namespace-id 
<other qualifying info (ST)>HealthcareService.identifier.type.coding.codeeg. "VDI" / "UPIN"

 

A8.12.2.7.3 FHIR Extensions for HL7 v2 Assigning Authority (HD)

An extension has been defined in the Australian FHIR Profile for allowing all components of the HL7 v2 Assigning Authority field. This can be used in various places where assigning authorities are used, such as in HL7v2 datatypes XCN, XON, CX.

HD Componenthttp://hl7.org.au/fhir/StructureDefinition/au-assigningauthority extension
<namespace ID (IS)> namespace-id
<universal ID (ST)>universal-id
<universal ID type (ID)>universal-id-type

 

A8.12.3 Application level addressing

The third layer is the application level addressing. Receivers may publish in their directory entries their desired receiving application. This allows for application based routing within an organisation. Senders must respect the published receiving application as published in the directory and value the appropriate MSH application fields accordingly.

A8.12.3.1 MSH-3 Sending application (HD)

Firstly the sender application must indicate that it is sending the message by setting the components of the MSH-3 Sending application (HD) (Section 2.1.9.3). The values for this must be the ones which have been published in the directory of the secure messaging system being used for the messaging transaction. 

A8.12.3.1.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from sending party's HealthcareService.Endpoint[x].au-receivingapplication as published in the directory of the messaging system being used for the transaction.

Each component of the MSH-3 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingapplication as per the following table.

HD Componenthttp://hl7.org.au/fhir/StructureDefinition/au-receivingapplication extension
<namespace ID (IS)> namespace-id
<universal ID (ST)>universal-id
<universal ID type (ID)>universal-id-type

 

A8.12.3.2 MSH-5 Receiving application (HD)

Secondly the sender must specify the destination application for the message in MSH-5 Sending application (HD) (Section 2.1.9.5) as per the values provided by the secure messaging system's directory that will be used to transmit the message.

A8.12.3.2.1 Australian Profile for Provider Directory Services

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.Endpoint[x].au-receivingapplication as published in the directory of the messaging system being used for the transaction.

Each component of the MSH-5 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingapplication as per the following table.

HD Componenthttp://hl7.org.au/fhir/StructureDefinition/au-receivingapplication extension
<namespace ID (IS)> namespace-id
<universal ID (ST)>universal-id
<universal ID type (ID)>universal-id-type

A8.13 Referral Acknowledgement

Conforming receiving systems of patient referrals messages must respond by sending and referral acknowledgement message back to the original sender of the received patient referral. Refer to 7.2.2 Patient Referral Acknowledgement Message structure (RRI_I12).

See HL7au:00045.4

Senders must be capable of receiving and processing an RRI^I12 message. See HL7au:00045.5


Senders must publish their ability to receive a RRI in the provider directory. See HL7au:00045.6

Before sending a referral message, Secure Messaging agents must validate that there is a valid referral response RRI entry in the provider directory. See HL7au:00045.7

  • No labels

2 Comments

  1. This message breaks all the rules for local extensions and localisation. The ORC segment in the first group means that no one, using a standard HL7 Parser, can parse this message. Hence, this message structure is not allowed by HL7 International rules. Standards Australia (IT-14-6-6) got wrapped over the knuckles by HL7 International when they introduces the "Australian REF message". Further more, this message structure and the associated RRI response, do not carry sufficient semantic information to support the workflows required to support meaningful electronic referrals. Because of both of these facts, Standards Australia (IT-14-6-6) tried to drop the Australian REF message and tried to adopt the Collaborative Care Message from 2.7, which are 2.4 compatible. In fact Standards Australia (IT-14-6-6) drafted the Collaborative Care Messages, which were adopted by HL7 International and incorporated in HL7 V 2.7. Unfortunately delays in the release of V2.7 meant that IT-14-6-6 was effectively disbanded before the Australian REF message could be withdrawn. But it should be withdrawn and we should not be using it.

    1. This is being discussed in the HL7 O&O meeting at present and this is the committee response:

      "For this work we were following existing messaging practice in Australia which in turn was based on the AS 4700.6-2006 Implementation of Health Level Seven - HL7 -  Version 2.4. Our intention is to aid standardisation so that interoperability might be achievable more quickly.

      Vendors in Australia appear to want to use only a single message to transfer the various data pieces which would otherwise be moved by multiple messages.

      It is recognised by the committee that the message structure does not align with Chapter 11 in HL7 v2.4 (International). 

      We would welcome and value your participation in the committee."