Appendix 10 Addressing messages using Australian Profile for Provider Directory Services (Normative)
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.
| HD Component | http://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 |
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.
| HD Component | http://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 |
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.
| XCN Component / sub-component | FhirResource element | Comment |
|---|---|---|
| <ID number (ST)> | PractitionerRole.identifier.value | Select an identifier common understood identifier from the PractitionerRole.identifier list. Also map the assigning authority component associated with the selected identifier. See below in this table for mapping description. |
| <family name (FN)> | ||
| <surname (ST)> | PractitionerRole.practitioner.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.practitioner.name[usual].given[0] | |
| <second and further given names or initials thereof (ST)> | PractitionerRole.practitioner.name[usual].given[1..*] | Concatenate with spaces separating names |
| <suffix (e.g., JR or III) (ST)> | PractitionerRole.practitioner.name[usual].suffix | |
| <prefix (e.g., DR) (ST)> | PractitionerRole.practitioner.name[usual].prefix | |
| <degree (e.g., MD) (IS)> | - | |
| <source table (IS)> | - | |
| <assigning authority (HD)> | The 3 assigning authority components below must relate to the same PractitionerRole.identifier instance used for mapping the <ID number (ST)> above. | |
| <namespace ID (IS)> | PractitionerRole.identifier.au-assigningauthority.namespace-id.valueString | |
| <universal ID (ST)> | PractitionerRole.identifier.au-assigningauthority.universal-id.valueString | |
| <universal ID type (ID)> | PractitionerRole.identifier.au-assigningauthority.universal-id-type.valueString | |
| <name type code (ID)> | PractitionerRole.practitioner.name[usual].use. Apply the concept mapping cm-name-use-v2. | See Table 0200 For usual use "D". For official use "L" |
| <identifier check digit (ST)> | ||
| <code identifying the check digit scheme employed (ID)> | ||
| <identifier type code (IS)> | PractitionerRole.identifier.type.coding.code | |
| <assigning facility (HD)> | - | |
| <name representation code (ID)> | - | |
| <name context (CE)> | See 3.29.16 Name context (CE). It is not necessary to populate this component with the resource type as in the case of HealthcareService as this PractitionerRole is the default resource to search. | |
| <identifier (ST)> | ||
| <text (ST)> | ||
| <name of coding system (IS)> | ||
| <name validity range (DR)> | ||
| <name assembly order (ID)> |
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.
| XCN Component / sub-component | FhirResource element | Comment |
|---|---|---|
| <ID number (ST)> | HealthcareService.identifier.value | Select an identifier common understood identifier from the HealthcareService.identifier list. Also map the assigning authority component associated with the selected identifier. See below in this table for mapping description. |
| <family name (FN)> | ||
| <surname (ST)> | HealthcareService.providedBy.name | e.g. 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.name | Name of the service. e.g. "General Practice" |
| <second and further given names or initials thereof (ST)> | HealthcareService.location.name | |
| <suffix (e.g., JR or III) (ST)> | ||
| <prefix (e.g., DR) (ST)> | ||
| <degree (e.g., MD) (IS)> | ||
| <source table (IS)> | ||
| <assigning authority (HD)> | The 3 assigning authority components below must relate to the same HealthcareService.identifier instance used for mapping the <ID number (ST)> above. | |
| <namespace ID (IS)> | HealthcareService.identifier.au-assigningauthority.namespace-id.valueString | |
| <universal ID (ST)> | HealthcareService.identifier.au-assigningauthority.universal-id.valueString | |
| <universal ID type (ID)> | HealthcareService.identifier.au-assigningauthority.universal-id-type.valueString | |
| <name type code (ID)> | "D" | See Table 0200 For usual use "D". For official use "L" |
| <identifier check digit (ST)> | ||
| <code identifying the check digit scheme employed (ID)> | ||
| <identifier type code (IS)> | HealthcareService.identifier.type.coding.code | |
| <assigning facility (HD)> | ? | |
| <name representation code (ID)> | ? | |
| <name context (CE)> | The purpose of this field when mapping a HealthcareService is to support the use case of a receiver performing a lookup using the FHIR directory service using HealthcaseService resource instead of PractitionerRole which is the default. See 3.29.16 Name context (CE). | |
| <identifier (ST)> | "HealthcareService" | |
| <text (ST)> | "Healthcare Service" | |
| <name of coding system (IS)> | "FHIR-ResourceType" | |
| <name validity range (DR)> | ||
| <name assembly order (ID)> |
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.
| XPN Component / sub-component | FhirResource element | Comment |
|---|---|---|
| <family name (FN)> | - | |
| <surname (ST)> | PractitionerRole.practitioner.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.practitioner.name[usual].given[0] | |
| <second and further given names or initials thereof (ST)> | PractitionerRole.practitioner.name[usual].given[1..*] | Concatenate with spaces separating names |
| <suffix (e.g., JR or III) (ST)> | PractitionerRole.practitioner.name[usual].suffix | |
| <prefix (e.g., DR) (ST)> | PractitionerRole.practitioner.name[usual].prefix | |
| <degree (e.g., MD) (IS)> | - | |
| <name type code (ID) > | PractitionerRole.practitioner.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)> | - |
A10.1.2.2.2.2 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.name as published in the directory of the messaging system being used for the transaction.
| XPN Component / sub-component | FhirResource element | Comment |
|---|---|---|
| <family name (FN)> | - | |
| <surname (ST)> | HealthcareService.providedBy.name | e.g. 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.name | Name of the service. e.g. "General Practice" |
| <second and further given names or initials thereof (ST)> | HealthcareService.location.name | e.g. "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)> | - |
A10.1.2.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))
A10.1.2.2.3.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.location address data type as published in the directory of the messaging system being used for the transaction.
| XAD Component / sub-component | FhirResource element | Comment |
|---|---|---|
| <street address (SAD)> | ||
| <street or mailing address (ST)> | PractitionerRole.location.address.line[0..*] | Concatenate each address.line separated by a comma ",". |
| <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)> |
A10.1.2.2.3.2 Healthcare Service providers
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-component | FhirResource element | Comment |
|---|---|---|
| <street address (SAD)> | ||
| <street or mailing address (ST)> | HealthcareService.location.address.line[0..*] | Concatenate each address.line separated by a comma ",". |
| <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)> |
A10.1.2.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).
A10.1.2.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.
| XTN Component / sub-component | FhirResource element | Comment |
|---|---|---|
| [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] | PractitionerRole.telecom.value | if ContactPoint.system is either phone, fax, pager, sms |
| <telecommunication use code (ID)> | PractitionerRole.telecom.use | Apply the concept mapping cm-contact-point-use-v2. |
| <telecommunication equipment type (ID)> | PractitionerRole.telecom.system | Apply the concept mapping cm-contact-point-system-v2. |
| <email address (ST)> | PractitionerRole.telecom.value | if ContactPoint.use.code = email |
| <country code (NM)> | ||
| <area/city code (NM)> | ||
| <phone number (NM)> | ||
| <extension (NM)> | ||
| <any text (ST)> |
A10.1.2.2.5.2 Healthcare Service providers
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-component | FhirResource element | Comment |
|---|---|---|
| [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] | HealthcareService.telecom.value | if ContactPoint.system is either phone, fax, pager, sms |
<telecommunication use code (ID)>
| HealthcareService.telecom.use | Apply the concept mapping cm-contact-point-use-v2. |
| <telecommunication equipment type (ID)> | HealthcareService.telecom.system | Apply the concept mapping cm-contact-point-system-v2. |
| <email address (ST)> | HealthcareService.telecom.value | if ContactPoint.use.code = email |
| <country code (NM)> | ||
| <area/city code (NM)> | ||
| <phone number (NM)> | ||
| <extension (NM)> | ||
| <any text (ST)> |
A10.1.2.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).
A10.1.2.7.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.identifier data type as published in the directory of the messaging system being used for the transaction.
There may be multiple identifiers in the PractitionerRole identifier list. It is important to map the routable identifiers 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-component | FhirResource element | Comment |
|---|---|---|
| <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.code | e.g. "VDI" or "UPIN" |
A10.1.2.7.2 Healthcare Service providers
A10.1.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-component | FhirResource element | Comment |
|---|---|---|
| <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.code | e.g. "VDI" / "UPIN" |
A10.1.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 Component | http://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 |
A10.1.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.
A10.1.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.
When using the Australian Profile for Provider Directory Services, the values from this field must match with the sending party's Endpoint[x].au-receivingapplication 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-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 Component | http://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 |
A10.1.3.2 MSH-5 Receiving application (HD)
Secondly the sender must specify the destination application for the message in MSH-5 Receiving 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.
When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's Endpoint[x].au-receivingapplication as published in the directory of the messaging system being used for the transaction when the extension is present.
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 Component | http://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 |
A10.2 Responsibilities of Receivers
Intended recipients which are Healthcare Services or inactive providers must be managed by the receiving system to ensure the message content is reviewed for triage. See HL7au:000025.1.1.
Received messages without an intended recipient which must be managed by the receiving system to ensure the message content is reviewed for triage. See HL7au:000025.1.2.
Further guidelines are available from the following
- SPIA - in particular Chapter 10 "Safe pathology reporting".
- RACGP - Standards for general practices.