A10.1 Addressing Introduction

The purpose of this appendix is to describe the method of population of HL7 fields and when using the Australian Profile for Provider Directory Services, and also how applications may use certain HL7 fields to initiate a search on the provider directory to find more information about a healthcare provider referenced in the HL7v2 message.

Message addressing happens at three layers, the involved individuals, the organisations involved and the applications involved in the message transaction.

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

Other message types, including Acknowledgements (ACK), Referral responses (RRI), Order (ORM) messages and Order Responses (ORR), do not have an individual intended recipient and are always routed using facility/organisational addressing, and optionally application level addressing.

A10.1.1 Facility/Organisational level addressing

The first layer is the facility/organisation level

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

When using the Australian Profile for Provider Directory Services, the values from this field must match with the sending party's Endpoint[x].au-receivingfacility for receiving acknowledgements or responses to this message 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.

A10.1.1.2 MSH-6 Receiving facility (HD)

Secondly the sender must specify the destination for the message in MSH-6 Receiving 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.

When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's 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.

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

Depending on the message type Individual recipient addressing is achieved using either the HL7 XCN datatype or for referral message individual provider/recipient level addressing is performed using the PRD segments. See the sections below for mappings for each.

For ORU messages PV1-9 (XCN datatype) is designated as the target provider for the message.

A10.1.2.1 XCN Datatype

This XCN data type (see section 3.29 XCN - extended composite ID number and name for persons) is used extensively appearing in the PV1, ORC, RXO, RXE, OBR and SCH segments, as well as others, where there is a need to specify the ID number and name of a person.

Below are a list of common XCN datatypes contained within message segments. The PV1-9 Target doctor is critical for result delivery on ORU messages, OBR-28 Result copies .

Result copies to informs the receiver of other recipients of the report, and in the context of an order message (ORM) allows specification of result copy recipients.

Populating these fields correctly allows for querying the provider directory for further information about the provider.

• 2.2.2.7 PV1-7 Attending doctor (XCN) 00137

• 2.2.2.8 PV1-8 Referring doctor (XCN) 00138

• 2.2.2.9 PV1-9 Consulting doctor (XCN) 00139

• 2.2.2.17 PV1-17 Admitting doctor (XCN) 00147

• 2.2.2.52 PV1-52 Other healthcare provider (XCN) 01274

• 2.2.3.13 PV2-13 Referral source code (XCN) 00714

• 4.4.1.10 OBR-10 Collector identifier (XCN) 00244

• 4.4.1.16 OBR-16 Ordering provider (XCN) 00226

• 4.4.1.28 OBR-28 Result copies to (XCN) 00260

• 5.4.1.10 ORC-10 Entered by (XCN) 00224

• 5.4.1.11 ORC-11 Verified by (XCN) 00225

• 5.4.1.12 ORC-12 Ordering provider (XCN) 00226

• 5.4.1.19 ORC-19 Action by (XCN) 00233

• 4.4.2.16 OBX-16 Responsible observer (XCN) 00584

• 7.3.10.18 IAM-18 Statused by person (XCN) 01563

• 7.3.11.12 ORC-12 Ordering provider (XCN) 00226

• 7.3.16.14 RXO-14 Ordering provider's DEA number (XCN) 00305

• 7.3.16.15 RXO-15 Pharmacist/treatment supplier's verifier ID (XCN) 00306

The sending system should populate these fields according to the provider directory information which will facilitate downstream directory reverse lookups on the provider identifier either on the PractitionerRole or HealthcareService resource.

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 XCN datatype component and subcomponents. 

A10.1.2.1.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 and related PractitionerRole.practitioner resources as published in the directory of the messaging system being used for the transaction.

A10.1.2.2.1 Healthcare Service Providers

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

A10.1.2.2 PRD Segment

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 all PRD segments according to the same rules.

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

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

A10.1.2.2.2.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.practitioner resource as published in the directory of the messaging system being used for the transaction.