Health Connect Australia Provider Directory FHIR Implementation Guide, published by Australian Digital Health Agency. This guide is not an authorized publication; it is the continuous build for version 0.3.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/AuDigitalHealth/HealthConnect/ and changes regularly. See the Directory of published versions

General Guidance

Page standards status: Informative

Conventions

Must support

This IG follows the approach taken in AU Core to must support and obligation.

Labelling an element Must Support means that systems that produce or consume resources SHALL provide support for the element in some meaningful way. The FHIR standard does not define exactly what 'meaningful' support for an element means, but indicates that a profile SHALL make clear exactly what kind of support is required when an element is labelled as Must Support.

In this IG, the meaning of Must Support is specified in terms of Obligation Codes in obligation extensions on the element definition. These obligations can also be applied at more granular levels, such as individual data type choices, terminology bindings, identifiers, or sub-elements.

To interpret elements labelled as must support follow the guidance in AU Core at Interpreting Profile Elements Labelled Must Support.

Must Support & Obligations for Actors

This implementation guide defines its own actors and obligations to specify actor-specific behaviour for data elements. While this IG builds upon AU Core profiles, the obligations defined there are not relevant here as those obligations apply to actors not included in this implementation guide. Only obligations on actors included in this implementation guide are relevant. The IG defines two actors with specific responsibilities:

  • Health Connect Provider Directory Responder Actor (server): The source for Health Connect Provider Directory data.
  • Health Connect Provider Directory Requester Actor (client): Systems that query and consume Directory data.

Generally the main obligations applied to each Actor within this IG are:

  • Health Connect Provider Directory Responder Actor with SHALL:populate-if-known obligation: The Health Connect Provider Directory Responder SHALL populate-if-known the data element in accordance with the FHIR obligation definition. This means that if the actor knows the correct value for the element it will include it. The obligation does not require the element to always be present, but when the actor has the relevant data and it is appropriate for the resource context, the element must be populated if known.

  • Health Connect Provider Directory Requester Actor with SHOULD:handle obligation: Client systems SHOULD be capable of receiving and processing the data element when it is present in responses in accordance with the FHIR obligation definition. This provides flexibility for implementers to support Directory data elements based on their specific use cases and integration requirements.

For elements without FHIR obligations:

  • Data elements that do not have specific FHIR obligations defined can be ignored by implementers unless explicitly required by their specific use case or local requirements.

Experimental dependencies

This table lists the experimental dependencies used within this specification at the time of publishing. We acknowledge that while not ideal, the reasons for doing so are valid and described below.

Reference Description
Australian Endpoint Payload Types ValueSet & CodeSystem These ValueSet and CodeSystem are published and maintained by HL7 Australia as part of the Australian Provider Directory Implementation Guide (see IG). The publisher currently classifies these as experimental; as a pre-existing standard we are simply adopting them as-is because they meet our requirements.
Australian Service Interfaces ValueSet & CodeSystem These ValueSet and CodeSystem are published and maintained by HL7 Australia as part of the Australian Provider Directory Implementation Guide (see IG). The publisher classifies these as experimental; as a pre-existing standard we are simply adopting them as-is because they meet our requirements.