# Conformance - Health Connect Australia Provider Directory FHIR Implementation Guide v26.0.0

 ![](assets/images/adha-logo-light.svg) 

# Health Connect Australia Provider Directory FHIR Implementation Guide

26.0.0 - Trial

*  [FHIR IGs](https://implementer.digitalhealth.gov.au/fhir-resources) 
*  [Implementer Hub](https://implementer.digitalhealth.gov.au/) 
*  [Agency site](https://www.digitalhealth.gov.au) 

* [**Table of Contents**](toc.md)
* **Conformance**

## Conformance

This page records the conformance expectations for the Health Connect Provider Directory Implementation Guide. The IG defines two client actors:

* [Health Connect Provider Directory Requester Actor](CapabilityStatement-health-connect-provider-directory-requester.md)
* [Bulk Export Requester Actor](ActorDefinition-bulk-export-requester-actor-health-connect.md)

Client systems **SHALL** claim conformance to a **minimum of one actor**, but are **not required** to be conformant to both actors.

### FHIR conformance

As a healthcare provider-focused implementation guide, conformance requirements are centred on client systems' ability to parse, validate, and consume FHIR resources that conform to the HC profile specifications. Implementations SHALL demonstrate profile conformance by respecting the data structures defined in profiles and adhering to the structural definitions, cardinality constraints, invariants, and terminology bindings specified within the HC profiles when processing resources retrieved from the Health Connect Provider Directory.

#### Profiles and data structure conformance

Client systems claiming conformance as a **Health Connect Provider Directory Requester Actor** SHALL be able to correctly interpret and process resources conforming to the following target profiles, respecting their defined data structures:

* [HC Organization](StructureDefinition-hcpd-organization.md) — organisation-level data structure conformance for discovery and reads
* [HC Practitioner](StructureDefinition-hcpd-practitioner.md) — individual practitioner data structure conformance for discovery and reads

Client systems claiming conformance as a **Bulk Export Requester Actor** SHALL be able to correctly interpret and process bulk exported resources conforming to the following target profiles, respecting their defined data structures:

* [HCPD Export Request Parameters](StructureDefinition-hcpd-export-request-parameters.md) — parameters data structure conformance for initiating bulk export operations
* [HCPD Export Response List](StructureDefinition-hcpd-export-response-list.md) — list data structure conformance for processing removal operations in bulk export responses

For the profiles above, Health Connect Provider Directory Requester Actors SHOULD support discovery and retrieval operations (for example `search` and `read`) while ensuring they can correctly parse and utilize the structured data according to profile specifications. See the FHIR HTTP operations documentation ([FHIR HTTP operations](https://hl7.org/fhir/R4/http.html)) and the AU Core general requirements ([AU Core general requirements](https://hl7.org.au/fhir/core/2.0.0-ballot/general-requirements.html)) for full details. Health Connect Provider Directory Requester Actors SHOULD consult the target Server's `CapabilityStatement` to determine the exact set of supported interactions.

#### Search parameters and terminology

Where a SearchParameter is of type token, the Health Connect Provider Directory Requester Actor SHOULD supply `system|code` or `system|value` using the code systems and value sets referenced by the IG. If a system is not available, then a value alone may be supplied. However, implementers must have in place mechanisms that clearly identify or mark matching values belonging to different systems. The published IG and the target server's `CapabilityStatement` should be consulted for the authoritative list of recommended SearchParameters and the expected token ValueSets. Although some value sets may be `preferred` rather than `required`, Requesters are strongly recommended to adopt those value sets where appropriate to maximise interoperability and minimise integration effort. The exception here, being the [ValueSet: hl7VS-degreeLicenseCertificate](https://hl7.org.au/fhir/6.0.0-ballot/ValueSet-au-v2-0360-extended.html) which is applied to `Practitioner.qualification.code`. This value set is not optimal for the intended use case but is used in lieu of an established alternative.

Within the scope of this IG, the Requester actor is not required to support any SearchParameters, all are marked as SHOULD support. Implementers may leverage SearchParameters defined within this IG (including those inherited) as they see fit in accordance with their own use cases to interact with the Health Connect Provider Directory system.

#### Error handling

Health Connect Provider Directory Requesters SHALL correctly handle OperationOutcome responses and non-2xx HTTP responses returned by servers.

#### Conformance testing

Conformance tests SHOULD verify that Requester implementations can:

* Perform `search` and `read` interactions against Organization and Practitioner profiles
* Handle multiple-result searches and pagination
* Respect server-declared search parameters and handle unsupported parameters gracefully
* Properly process OperationOutcome responses and error conditions

This document is intentionally narrow in scope for the Requester actor.

#### Missing data

It is an expectation that [Health Connect Provider Directory Requester Actor](CapabilityStatement-health-connect-provider-directory-requester.md) implementers SHALL be able to handle cases where missing data exists. Where mandatory elements are missing, this will be indicated by the established convention in FHIR, i.e. supplying the extension [`DataAbsentReason`](https://hl7.org/fhir/R4/extension-data-absent-reason.html).

### Software conformance profile

A risk-based Provider Directory conformance profile will be developed for connecting systems to mitigate the identified risks and describe desired software behaviours. The software developer must ensure their system behaves in accordance with the desired behaviours outlined in the conformance profile and associated artefacts.

#### Software conformance assessment

The conformance assessment approach and the associated test specification will be developed for connecting systems. The software developer must demonstrate conformance to the relevant Conformance Profile in addition to meeting the FHIR conformance requirements in section above.

 ![](assets/images/adha-logo-light.svg) 

IG © 2026+ [Australian Digital Health Agency](https://www.digitalhealth.gov.au/). Package au.gov.digitalhealth.hcpd#26.0.0 based on [FHIR 4.0.1](http://hl7.org/fhir/R4/). Generated 2026-06-17

Links: [Table of Contents](toc.md) | [QA Report](qa.md) | [Version History](https://fhir.digitalhealth.gov.au/dh/history.html) | [Report an issue or propose a change](mailto:help@digitalhealth.gov.au) 

Publisher: [Australian Digital Health Agency](https://www.digitalhealth.gov.au) | ABN: 84 425 496 912, Level 25, 175 Liverpool Street, Sydney, NSW 2000 | Phone: [1300 901 001](tel:1300901001) | Email: [help@digitalhealth.gov.au](mailto:help@digitalhealth.gov.au) | [https://www.digitalhealth.gov.au](https://www.digitalhealth.gov.au) | [Privacy policy](https://www.digitalhealth.gov.au/about-us/policies-privacy-and-reporting/privacy-policy) | [Terms of Use](https://www.digitalhealth.gov.au/about-us/policies-privacy-and-reporting/terms-of-use)

![](cc0.png)
The Australian Digital Health Agency acknowledges the Traditional Custodians of Country throughout Australia, and their continuing connection to land, sea and community. We pay our respects to them and their cultures, and to Elders, past and present.

