Health Connect Australia Provider Directory FHIR Implementation Guide

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 26.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/AuDigitalHealth/HCPD-Snapshot-26.0.0-HL7AU-Connectathon-Aug-25-26/ and changes regularly. See the Directory of published versions

Batch Request Results

Overview

This page describes step 3 of the Asynchronous Bulk Data Export Process Workflow - retrieving the request results.

Fetching results has four key components:

1. Preconditions
2. Request to server
3. Responses from server
4. Output file request

Preconditions

The following preconditions, as documented in the status polling function, SHALL be met before retrieving the results of a bulk data export request:

1. The client must have received a 200 OK response from the status polling request, indicating that the job is complete
2. The response's output.url must be stored for use in retrieving the results

Request to server

Using the full URL returned by the server in the completion manifest, the client retrieves each generated output file.

HTTP method

Output files are retrieved using the standard HTTP GET method against the output URL provided by the server. Clients use the URL as supplied and do not construct it.

Request body

No request body is required.

Example request

Request HTTP header

GET [base]/Binary/VMxYkAvCKldql5wVAW2G7OKfTIvLnOsn
Accept: application/fhir+ndjson

Request HTTP body

Absent

Responses from server

Success response

The server responds with a 200 OK status code and a Content-Location header indicating the location of the results file.

Response HTTP header

HTTP/1.1 200 OK
Content-Location: https://fhir-xrp.digitalhealth.gov.au/fhir/Binary/VMxYkAvCKldql5wVAW2G7OKfTIvLnOsn/_history/1
Content-Disposition: Attachment;
Content-Type: application/fhir+ndjson
Content-Length: 8058
Date: Tue, 11 Nov 2025 00:37:48 GMT

Output file request

Clients request the output files generated by the batch job by sending a GET request to each URL provided in the output array of the completion manifest.

Using the URLs supplied by the FHIR server in the Complete Status response body, a client MAY download the generated output files (one or more per resource type) within the time period specified in the Expires header (if present). If the requiresAccessToken field in the Complete Status body is set to true, the request SHALL include a valid access token.

The response format is controlled by the Accept header. Requesting application/fhir+ndjson returns the NDJSON content directly; requesting application/fhir+json returns a Binary resource with the NDJSON content Base64-encoded in Binary.data. See Retrieving export files.

The output files are in NDJSON format, with one FHIR resource per line.

Data visibility in export results

What an export contains depends on whether the request carried a _since parameter. Every _typeFilter query is augmented with the same state filters the Search API applies, except where _since switches that filtering off.

Full detail is on the Export API technical specification.

Snapshot extracts — without _since

A plain export is a filtered snapshot. Suppressed and inactive resources are absent from the output files. They are not delivered and then filtered; they are simply not there.

Because suppressed resources are absent, a snapshot cannot by itself tell a client that a resource it already holds has since been suppressed.

Delta extracts — with _since

A _since export is an incremental synchronisation feed and returns all states, including suppressed and inactive resources. Any client-supplied state constraint in a _typeFilter is discarded rather than honoured.

This is how a client learns that something it already holds has changed state. Client Requester Actors synchronising a local directory SHALL use _since exports for that purpose, and SHALL apply suppression filtering to the results before presenting data to end users.

Filtering the results

Clients determine visibility from two things in the returned resources:

• The suppressed extension, which is retained in responses precisely so consumers can determine visibility. Its presence on a resource in a _since extract means the resource SHALL be removed from, or hidden in, the local system.
• The active element (Practitioner, PractitionerRole, Organization, HealthcareService) or status element (Location, Endpoint), which carries the resource's active state. Location uses active / inactive; Endpoint uses active / off.

The internal deactivated extension is not part of the public API surface. It is added server-side, is never accepted from clients, and is stripped from read and search responses. Clients SHALL rely on active and status rather than looking for it.

For Organization, the includeSelf sub-extension decides whether the organisation itself counts as suppressed. Where includeSelf is false the extension is present purely as a propagation marker: the organisation is not suppressed and is still exported, while all its linked resources are. An export may therefore legitimately contain an Organization with none of its services, locations, roles, or endpoints, and clients SHALL NOT infer from an empty related-resource set that an organisation has no services.

Removing resources via the Export Response List

Suppressed identifiers are also communicated through an HCPD Export Response List accompanying the export, which carries the identifiers of resources to be removed rather than the resources themselves.

Client Requester Actors SHALL establish and maintain processes to resolve the identifiers in that List against their local records and purge the corresponding resources. Conformance with this requirement is mandatory.

The identifier systems used in the List are:

Example output file content

Each line of an NDJSON output file is a single FHIR resource. The example below is a Location as it would appear in an export.

{"resourceType":"Location","id":"example-healthconnect-mobile-healthcare-unit-1","meta":{"versionId":"3","lastUpdated":"2026-01-22T03:51:37.146+00:00","profile":["http://digitalhealth.gov.au/fhir/hcpd/StructureDefinition/hcpd-location"]},"extension":[{"url":"http://digitalhealth.gov.au/fhir/cc/StructureDefinition/amenity","valueCodeableConcept":{"coding":[{"system":"https://healthterminologies.gov.au/fhir/CodeSystem/facility-amenity-1","code":"wheelchairAccess","display":"Wheelchair Access"}]}}],"identifier":[{"type":{"coding":[{"system":"http://terminology.hl7.org.au/CodeSystem/v2-0203","code":"NATAS","display":"NATA Site Number"}],"text":"NATA Site Number"},"system":"http://hl7.org.au/id/nata-site","value":"162899"},{"type":{"coding":[{"system":"http://terminology.hl7.org.au/CodeSystem/v2-0203","code":"LSPN","display":"Location Specific Practice Number"}],"text":"LSPN"},"system":"http://ns.electronichealth.net.au/id/location-specific-practice-number","value":"123333"},{"type":{"coding":[{"system":"http://terminology.hl7.org/CodeSystem/v2-0203","code":"XX","display":"Organization identifier"}]},"system":"http://digitalhealth.gov.au/fhir/hcpd/id/hcpd-local-identifier","value":"26ff4c29-692f-45c7-8df7-99cf6b5a8c09"}],"status":"active","name":"Mobile Healthcare Unit - Sydney CBD","alias":["CBD Mobile Unit"],"telecom":[{"system":"phone","value":"(02) 1234 5678","use":"work"},{"system":"email","value":"info@location.com.au","use":"work"}],"address":{"type":"physical","text":"123 Bay Terrace WYNNUM QLD 4178 Australia","line":["123 Bay Terrace"],"city":"WYNNUM","state":"QLD","postalCode":"4178","country":"AU"},"position":{"longitude":151.2093,"latitude":-33.8688},"managingOrganization":{"reference":"Organization/example-healthconnect-organization-1"}}

A resource returned by a _since extract carries its current state in active or status, and carries the suppressed extension where it has been suppressed. The example below is a suppressed, still-active Practitioner as it would appear in a delta extract — the client SHALL purge or hide this record locally.

{"resourceType":"Practitioner","id":"example-healthconnect-practitioner-9","meta":{"lastUpdated":"2026-03-02T21:14:07.882+00:00","profile":["http://digitalhealth.gov.au/fhir/hcpd/StructureDefinition/hcpd-practitioner"]},"extension":[{"url":"http://digitalhealth.gov.au/fhir/cc/StructureDefinition/suppressed","extension":[{"url":"suppressedBy","valueCodeableConcept":{"coding":[{"system":"http://digitalhealth.gov.au/fhir/cc/CodeSystem/responsible-party-type","code":"practitioner-initiated","display":"Practitioner initiated"}]}}]}],"identifier":[{"system":"http://ns.electronichealth.net.au/id/hi/hpii/1.0","value":"8003619900015717"}],"active":true,"name":[{"family":"Jones","given":["Alison"],"prefix":["Dr"]}]}

Example HCPD Export Response List

The accompanying List identifies resources the client SHALL purge from its local system. Each entry.item.identifier carries the system and value pair of a resource to be removed.

{"resourceType":"List","id":"example-hcpd-export-response-list-1","meta":{"lastUpdated":"2026-03-24T10:30:00+10:00"},"status":"current","mode":"changes","title":"HCPD Export Response List - resources to be removed","date":"2026-03-24T10:30:00+10:00","entry":[{"item":{"identifier":{"system":"http://ns.electronichealth.net.au/id/hi/hpio/1.0","value":"8003626566707032"}}},{"item":{"identifier":{"system":"http://ns.electronichealth.net.au/id/hi/hpii/1.0","value":"8003619900015717"}}},{"item":{"identifier":{"system":"http://digitalhealth.gov.au/fhir/hcpd/id/hcpd-local-identifier","value":"pr-54321-example"}}},{"item":{"identifier":{"system":"http://digitalhealth.gov.au/fhir/hcpd/id/hcpd-local-identifier","value":"hs-67890-example"}}},{"item":{"identifier":{"system":"http://digitalhealth.gov.au/fhir/hcpd/id/hcpd-local-identifier","value":"loc-24680-example"}}},{"item":{"identifier":{"system":"http://digitalhealth.gov.au/fhir/hcpd/id/hcpd-local-identifier","value":"ep-13579-example"}}}]}