Australian Provider Directory Implementation Guide (PD 2)

This page is part of the Australian Provider Directory IG (v2.0.1: PD 2 on FHIR R4) based on FHIR R4. This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

General Guidance

Introduction

There are a number of FHIR resource types used to record provider directory entries.

PractitionerRole and HealthcareService are the main searchable concepts and can be related to other resources, Practitioner, Organization, Location and Endpoint.

Searching for suitable PractitionerRole or HealthcareService can be made by search parameters on these resource types and/or via chained searches to the related resource types.

In this usage the PractitionerRole and HealthcareService resources are related to Endpoints (containing service connection details, such as secure messaging) and this allows communications to be made to a practitioner (in a role) or healthcare service based on the content of the associated Endpoint resource used.

Provider Directory Service Roles

This implementation guide is defined to allow multiple consumer systems to call multiple provider directory services reliably with a consistent interface and available data support.

Provider Directory Supplier implementations are server software systems that supply a provider directory service interface and data.

SRV01 Servers SHALL be capable of providing all resource types included in this guide.

SRV02 Servers SHALL be capable of providing all profile data elements marked as MUST SUPPORT.

SRV03 Servers SHALL comply to AU Provider Directory Implmementation Guide, AU Base Implmementation Guide and FHIR STU3 core constraints for all resource instances.

SRV04 Servers SHALL be capable of responding meaningfully to all search requests (in each resource definiition) that are marked as MUST SUPPORT.

SRV05 Servers MAY be capable of responding to search requests (in each resource definiition) that are marked as OPTIONAL.

SRV06 Servers MAY be capable of responding to other search requests that are FHIR core compliant OR custom searches (defined using CapabilityStatement supplied by the server).

Provider Directory Consumer implementations are client software systems that call provider directory services and consume data.

CLI01 Clients SHALL support meaningful consumption of all data elements marked as MUST SUPPORT.

CLI02 Clients SHALL allow receipt of the all resource types in this guide.

CLI03 Clients SHALL allow receipt of resource instances that are valid according to the AU Provider Directory Implmementation Guide, including FHIR STU3 core compliant elements not defined in this guide.

CLI04 Clients can assume that all search requests marked as MUST SUPPORT are available.

CLI05 Clients may use search requests marked as OPTIONAL but MUST inform the user if the call is not supported by the server.



Provider Directory Core Entity Relationships

PractitionerRole Associations

For directory service profiles the PractitionerRole resource has constrained relationships to Location, Organization, and Practitioner resource types.

This ensures that all practitioners in a role are associated to a location, organisation (providing services), and an individual practitioner (person) to support searching.



HealthcareService Associations

For directory service profiles the HealthcareService resource has constrained relationships to Location and Organization resource types.

This ensures that all health care service are associated to one location, and an organisation (providing service) to support searching.



Provider Directory Usage Sequence for Secure Messaging

Typical sequence describing endpoint search, HL7 V2 generation, secure message composition, secure message delivery via intermediary, acknowledgement response addressing, generation and delivery.



Component Roles

  1. USER
    • User of the PMS/CIS (practice management system/clinical information system) sending a message.
  2. PMS/CIS SENDER
    • The practice management system or clinical information system) formatting and sending a HL7 V2 REF/MDM message.
  3. SM CLIENT (SENDER)
  4. SM INTERMEDIARY
    • Secure messaging intermediary providing store and forward .
    • May provide routing to other secure messaging suppliers.
  5. PD FHIR SERVER
    • Provider directory FHIR API service adhering to this implementation guide.
    • May be federated across multiple provider directory suppliers to allow addressing suitable for forwarding to other secure messaging suppliers.
  6. SM CLIENT (RECEIVER)
  7. PMS/CIS (RECEIVER)
    • The practice management system or clinical information system) receiving the HL7 V2 REF/MDM message and processsing it.
    • On accept/reject of the received message formatting and sending a HL7 V2 ACK message.

Sequence

  1. USER SEARCH
    • User performs a provider search in there client application.
    • This will likely include search parameters to use on search calls.
  2. SEARCH (1)
    • Search on PractitionerRole and/or HealthcareService (and related resources) can be done on PD FHIR Server.
    • Available search parameters are defined in Quick Start section of each profile which may be combined as the client application supports.
    • For example search by active status, secure messaging support, payload support and provider number. 
      GET https://sqlonfhir-aupd.azurewebsites.net/fhir/PractitionerRole?active=true&identifier=http://ns.electronichealth.net.au/id/medicare-provider-number|2426621B&endpoint.connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&endpoint.payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1&_include=PractitionerRole:endpoint&_include=PractitionerRole:location&_include=PractitionerRole:organization&_include=PractitionerRole:practitioner
    • For example search by active status, secure messaging support, payload support and practitioner family name 
      GET https://sqlonfhir-aupd.azurewebsites.net/fhir/PractitionerRole?active=true&practitioner.family=Smith&endpoint.connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&endpoint.payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1&_include=PractitionerRole:endpoint&_include=PractitionerRole:location&_include=PractitionerRole:organization&_include=PractitionerRole:practitioner
    • For example search by active status, secure messaging support, payload support and individual specialty in postcode 
      GET https://sqlonfhir-aupd.azurewebsites.net/fhir/PractitionerRole?active=true&location.address-postalcode=3010&specialty=http://snomed.info/sct|17561000&endpoint.connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&endpoint.payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1&_include=PractitionerRole:endpoint&_include=PractitionerRole:location&_include=PractitionerRole:organization&_include=PractitionerRole:practitioner
    • Can perform an independent Endpoint lookup based on results or a direct lookup as below.
    • Example lookup endpoint directly by the secure messaging target identifier directly - vendor or other target (perhaps stored in local directory) 
      http://sqlonfhir-aupd.azurewebsites.net/fhir/Endpoint?status=active&identifier=http://ns.electronichealth.net.au/smd/target|http://ns.argusdca.com.au/smd/id/hostname/ACC5408570000002&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.hl7.org.au/hl7v2/profiles/HL7AU-OO-REF-SIMPLIFIED-201706-L1
  3. SEARCH RESPONSE (1)
    • A FHIR Bundle (searchset) is returned as the search result.
    • Example a PractitionerRole search response with one PractitionerRole and included resources returned.
    • Example a HealthcareService search response with one HealthcareService and included resources returned.
    • Depending on search made on PD FHIR Server this will likely contain details:
      • PractitionerRole, Practitioner, Location, Organization, Endpoint.
      • HealthcareService, Location, Organization, Endpoint.
  4. USER SELECT
    • Details of the results received are presented to the user.
    • The user can select the desired receiver as needed.
  5. GENERATE HL7 V2 REF/MDM
  6. SEND HL7 V2 REF/MDM
    • Drop outbound HL7 V2 REF/MDM file or send via local SM CLIENT API.
  7. SEARCH (2)
    • For independent HL7 V2 sender processing (no Endpoint knowledege) can lookup Endpoint details via search by Receiving Facility.
    • Examples - lookup Endpoint by HL7 V2 content using AU PD search parameter extensions for delivery via secure messaging. 
      GET https://jdfhir.test.medical-objects.com.au/rest/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=8003623233355378&au-receivingfacility-universal-id=1.2.36.1.2001.1003.0.8003623233355378&au-receivingfacility-universal-id-type=ISO&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012 

      GET http://sqlonfhir-aupd.azurewebsites.net/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=CIB&au-receivingfacility-universal-id=877F9695-1298-4E6A-B432-0FDD46AD80B8&au-receivingfacility-universal-id-type=GUID&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012
  8. SEARCH RESPONSE (2)
  9. COMPOSE SECURE MESSAGE (1)
    • Use details in the Endpoint result to compose standard SMD messages AS 5552—2013 — E-Health Secure Message Delivery.
    • Utilise Endpoint result content for composing message including:
      • Endpoint.identifier (Secure Messaging Target Identifier) - destination reference (to SMD receiverOrganisation element).
      • Endpoint encryption-certificate-pem-x509 extension (PEM X509 Certificate) - encrypting certificate (for SMD encryptedPayload production).
      • Endpoint.payloadType - type of message payload (to SMD serviceCategory element).
      • Endpoint.contentType - method of interfacing (to SMD serviceInterface element).
  10. DELIVER (1)
  11. RETRIEVE (1)
  12. IMPORT HL7 V2 REF/MDM
    • Import HL7 V2 REF/MDM for PMS/CIS application level processing (accept/reject).
  13. SEARCH (3)
    • For independent HL7 V2 receiver processing can use the inbound HL7 V2 content (MSH Sending Facility) to perform a lookup to obtain path for HL7 V2 ACK message delivery
    • Examples - lookup Endpoint by HL7 V2 content using AU PD search parameter extensions for ACK delivery via secure messaging 
      GET https://jdfhir.test.medical-objects.com.au/rest/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=8003623233355378&au-receivingfacility-universal-id=1.2.36.1.2001.1003.0.8003623233355378&au-receivingfacility-universal-id-type=ISO&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012 

      GET http://sqlonfhir-aupd.azurewebsites.net/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=CIB&au-receivingfacility-universal-id=877F9695-1298-4E6A-B432-0FDD46AD80B8&au-receivingfacility-universal-id-type=GUID&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012
  14. SEARCH RESPONSE (3)
    • A FHIR Bundle (searchset) is returned with Endpoint details needed to deliver ACK.
    • Example an Endpoint search response with one Endpoint resource returned.
    • Use information to format the HL7 V2 ACK message.
  15. GENERATE HL7 V2ACK
    • Use same method to format HL7 V2 ACK as GENERATE HL7 V2 REF/MDM.
  16. SEND HL7 V2 ACK
    • Drop outbound HL7 V2 ACK file or send via local SM CLIENT API.
  17. SEARCH (4)
    • For independent HL7 V2 ACK send processing can use the outbound HL7 V2 content (MSH Receiving Facility) to perform a lookup to obtain path for HL7 V2 ACK message delivery
    • Examples - lookup Endpoint by HL7 V2 content using AU PD search parameter extensions for ACK delivery via secure messaging 
      GET https://jdfhir.test.medical-objects.com.au/rest/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=8003623233355378&au-receivingfacility-universal-id=1.2.36.1.2001.1003.0.8003623233355378&au-receivingfacility-universal-id-type=ISO&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012 

      GET http://sqlonfhir-aupd.azurewebsites.net/fhir/Endpoint?status=active&au-receivingfacility-namespace-id=CIB&au-receivingfacility-universal-id=877F9695-1298-4E6A-B432-0FDD46AD80B8&au-receivingfacility-universal-id-type=GUID&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012
    • Example - if known lookup endpoint by the secure messaging target identifier - vendor or other target for ACK message delivery via secure messaging 
      http://sqlonfhir-aupd.azurewebsites.net/fhir/Endpoint?status=active&identifier=http://ns.electronichealth.net.au/smd/target|http://ns.argusdca.com.au/smd/id/hostname/ACC5408570000002&connection-type=http://hl7.org.au/fhir/CodeSystem/smd-interfaces|http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010&payload-type=http://hl7.org.au/fhir/CodeSystem/endpoint-payload-type|http://ns.electronichealth.net.au/ack/sc/deliver/hl7Ack/2012
  18. SEARCH RESPONSE (4)
    • A FHIR Bundle (searchset) is returned with Endpoint details needed to deliver ACK
    • Example an Endpoint search response with one Endpoint resource returned.
    • Use information to compose a secure message containing ACK.
  19. COMPOSE SECURE MESSAGE (2)
    • Use same method to compose ACK secure message as COMPOSE SECURE MESSAGE (1).
  20. DELIVER (2)
    • Use same method to compose ACK secure message as DELIVER (1).
  21. RETRIEVE (2)
    • Standard retrieval of secure message HL7 V2 ACK response as per RETRIEVE (1).
  22. IMPORT HL7 V2 ACK
    • Import HL7 V2 ACK for PMS/CIS application processing.