Appendix 8 Simplified REF profile

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:

2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706&&L

Refer to HL7au:000040.4

Referral Level 1 conformance:

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.

MSH                                Message Header 
RF1                                Referral Information
{PRD}                              Provider Data
PID                                Patient Identification
[{AL1}]                            Allergy Information
{
	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 one OBR/OBX group which is indicated as clinical information as per section 4.4.1.4.1 OBR-4 codes in referral messages 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.

As older referrals may be included, the current referral must appear as the first OBR/OBX group.

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 OBR/OBX 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 OBR/OBX group must have at least one display segment.

For this profile, receivers must allow viewing the display segments for each OBR/OBX 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.1, HL7au: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 OBR/OBX groups which are other clinical/pathology/radiology reports as supporting information.

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 OBR/OBX segment groups and fields of the message (e.g. ORU) and include those in the REF message. It is important that the fields in these segments are preserved from the original sender, especially OBR-22 Results rpt/status chng (Refer to section 4.4.1.22). 

A8.10.2 Referral receivers

Receiving systems must display supporting information 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

Refer to HL7au:000032.3.

A8.11 Encapsulated data attachments

Attachments may be attached to any OBR/OBX group and shown appropriately.

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

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:000025, HL7au: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.

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.

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.

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.

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.

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.

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