Australian Digital Health Standards
Australian Digital Health Standards
Australia’s digital health technical standards layer is maintained by two bodies: the Australian Digital Health Agency (ADHA), which runs the national infrastructure, and HL7 Australia, which publishes the national FHIR profile set. For a builder connecting to Australian health systems, understanding the identifier schemes, terminology services, and profile requirements is essential before attempting any integration.
For the legal framework — Privacy Act 1988, My Health Record Act obligations, and notifiable data breaches — see Australian Privacy Act and Health Data.
ADHA (Australian Digital Health Agency)
ADHA is the national body responsible for Australia’s digital health infrastructure, established by the Australian Government. Its core responsibilities include operating the My Health Record system, maintaining the National Clinical Terminology Service, supporting the development of national standards including AU Base FHIR profiles, and coordinating digital health strategy across the states and territories.
ADHA’s developer portal (developer.digitalhealth.gov.au) is the primary point for API documentation, sandboxes, and onboarding guidance for builders connecting to national systems.
AU Base FHIR profiles
AU Base is the Australian national baseline FHIR R4 profile set, published and maintained by HL7 Australia. It is the AU equivalent of US Core — the shared conformance baseline for national health data exchange.
AU Base vs AU Core
A critical distinction that trips up many implementers:
- AU Base is the national baseline — it defines Australian extensions and identifiers but imposes minimal cardinality requirements. Most elements remain optional.
- AU Core is a stricter conformance layer built on AU Base, defining what a conformant Australian system must support. It is the AU equivalent of US Core’s “Must Support” obligations.
Regulatory and procurement requirements reference AU Core, not just AU Base. AU Base without AU Core conformance is not a compliance target.
Key AU-specific extensions and identifiers
The most important extension additions for the Australian context:
Individual Healthcare Identifier (IHI) — the national patient identifier, issued by Services Australia. It is a 16-digit number and the AU equivalent of the NHS number or NHI.
{
"system": "http://ns.electronichealth.net.au/id/hi/ihi/1.0",
"value": "8003608333647261"
}Healthcare Provider Identifier — Individual (HPI-I) — identifies individual healthcare providers:
{
"system": "http://ns.electronichealth.net.au/id/hi/hpii/1.0",
"value": "8003619166674595"
}Healthcare Provider Identifier — Organisation (HPI-O) — identifies healthcare organisations:
{
"system": "http://ns.electronichealth.net.au/id/hi/hpio/1.0",
"value": "8003621566684455"
}Medicare Card Number and DVA (Department of Veterans’ Affairs) Number are also defined as identifier slices on the AU Base Patient profile, reflecting Australian entitlement identifiers used in billing and benefits.
Indigenous status (http://health.gov.au/fhir/CodeSystem/indigenous-status) — records Aboriginal and/or Torres Strait Islander status. Required for most government health reporting.
AU Base Patient highlights
The AU Base Patient profile expects:
- IHI as an identifier slice (optional in AU Base, required in AU Core)
- Medicare card number slice where applicable
- Name with family name present
- Indigenous status extension for government-funded health services
My Health Record FHIR API
The My Health Record system is transitioning from CDA document exchange toward FHIR, but the rollout is incremental. As of late 2025:
- Established: FHIR API for Prescription and Dispense records (linked to the electronic prescribing programme)
- Evolving: FHIR API access for pathology and diagnostic imaging reports
- Legacy CDA: Shared Health Summaries, Discharge Summaries, Event Summaries continue to be exchanged as CDA documents for most workflows
Practical implication: A system that needs to read or write to My Health Record today must implement both CDA handling (for the document types not yet migrated) and FHIR (for the newer services). Plan for a hybrid for at least the medium term.
Authentication for My Health Record
Provider-facing MHR access requires NASH PKI certificates (see below). Consumer-facing access uses myGovID (the consumer digital identity service), implemented as an OAuth2/OIDC flow via Services Australia.
Conformance for MHR-connected systems
Systems connecting to MHR must conform to ADHA’s specific conformance profiles, which are published on the ADHA developer portal and build on AU Base. These include specific profiles for Prescription records, Immunisation records, and shared summaries. Standard AU Base conformance is not sufficient — check the ADHA-specific IG for the document type you are implementing.
National Clinical Terminology Service (NCTS)
NCTS is ADHA’s national terminology service, providing access to clinical coding systems used in Australian health settings.
SNOMED CT Australian Edition
The SNOMED CT Australian Edition is released twice yearly (January and July) and includes the SNOMED CT International Edition plus Australian extensions. The extension adds clinical content relevant to Australian practice, including the Australian Medicines Terminology (AMT) as a SNOMED reference set.
Access to SNOMED CT for use in Australian health IT products is licensed through ADHA for Australian organisations at no direct cost, provided the use is within the permitted territory.
Australian Medicines Terminology (AMT)
AMT is Australia’s national terminology for medicines, published as a SNOMED CT reference set within the SNOMED Australian Edition. Understanding its concept hierarchy is essential for medication FHIR resources in Australia:
| AMT concept type | What it represents | Use case |
|---|---|---|
| MP (Medicinal Product) | The therapeutic substance and form without a specific brand | Allergy/intolerance recording, clinical decision support |
| MPP (Medicinal Product Pack) | MP with a specific pack size | Order quantity |
| TP (Trade Product) | The branded product | Brand-specific prescribing |
| TPUU (Trade Product Unit of Use) | Branded product in a specific dispensing unit | Dispensing |
| MPUU (Medicinal Product Unit of Use) | Generic unit of use | Prescribing |
| CTPP (Containered Trade Product Pack) | Specific packaged brand | Pharmacy claims |
For prescribing via MedicationRequest, AMT MPP or MPUU codes are the expected coding. System URI: http://snomed.info/sct (AMT concepts are SNOMED CT codes within the AU Edition).
Accessing NCTS
ONTOSERVER — CSIRO’s SNOMED CT FHIR terminology server — is used by ADHA as the national terminology server for Australia. It is accessible via FHIR API and supports $expand, $lookup, and $validate-code operations against SNOMED CT Australian Edition, LOINC, and other code systems.
Healthcare Identifiers and the HI Service
The Healthcare Identifiers Service (HI Service), operated by Services Australia, is the authoritative registry for IHI, HPI-I, and HPI-O numbers.
Lookup and verification of healthcare identifiers is done via the HI Service APIs. Systems can:
- Search by demographics to retrieve an IHI
- Verify an IHI against stored demographics
- Lookup HPI-I or HPI-O by provider/organisation details
HI Service API access requires NASH PKI certificates and is governed by the Healthcare Identifiers Act 2010. Accessing the HI Service for purposes other than identifying individuals for care is restricted.
Operational note: IHI numbers have a status (Active, Deceased, Provisional, Unverified). Systems receiving IHI numbers from external sources should verify status before using them as the primary patient identifier. An Unverified IHI has not been matched to a confirmed identity; a Provisional IHI is issued when full demographic verification is incomplete.
NASH PKI
The National Authentication Service for Health (NASH) issues PKI (Public Key Infrastructure) certificates for healthcare organisations and practitioners connecting to national health infrastructure.
Certificate types
| Type | Used for |
|---|---|
| NASH Organisation Certificate | System-to-system authentication to national services (HI Service, MHR) |
| NASH Individual Certificate | Individual provider authentication (smartcard-based) |
| NASH Device Certificate | Device/system authentication for automated pipelines |
NASH certificates are X.509 certificates issued under the ADHA certificate policy. They are distinct from general-purpose SSL/TLS certificates and are required specifically for Australian national health service connections.
Integration pattern
System-to-system calls to MHR and the HI Service use mutual TLS (mTLS) with the NASH organisation certificate. The certificate is presented at the TLS handshake level, not as a bearer token. This is different from the OAuth2/JWT patterns common in FHIR API integrations — allow for the additional infrastructure (certificate storage, rotation, renewal) in system design.
NASH certificates have a 2-year validity period and must be renewed before expiry. Expired certificates immediately block access to national services — certificate renewal should be a tracked operational task with lead time.
MBS and PBS codes in FHIR
Medicare Benefits Schedule (MBS): Australia’s schedule of medical services eligible for Medicare rebate. MBS item numbers appear in billing and claiming workflows. In FHIR, they appear as ServiceRequest.code or Procedure.code with system http://ns.electronichealth.net.au/id/medicare-benefits-schedule-item.
Pharmaceutical Benefits Scheme (PBS): The national subsidised medicine programme. PBS item codes identify specific pharmaceutical preparations eligible for subsidy. They appear in MedicationRequest and dispense records. PBS codes are managed by the Department of Health; system URI: http://pbs.gov.au/code/item.
For clinical coding, use AMT (medication names/forms). For subsidy and billing, use PBS item codes. These are complementary coding layers on the same MedicationRequest, not alternatives.
Onboarding as an Australian digital health supplier
Connecting to national systems (MHR, HI Service) requires formal registration through ADHA’s onboarding process:
- Register with ADHA — organisation and system registration
- NASH certificate application — apply via the ADHA certificate authority
- Conformance testing — validate against ADHA’s published test scenarios
- Privacy and security assessment — evidence of Privacy Act compliance, security controls, and incident response capability
- Production access — granted after conformance testing passes and governance review is complete
State-level systems (e.g., NSW Health’s eHealth systems, VIC DHHS systems) have their own onboarding processes separate from ADHA’s national programme. A national ADHA registration does not automatically grant access to state systems.
See also
- Australian Privacy Act and Health Data — Privacy Act 1988, My Health Record Act, NDB scheme
- FHIR Profiling — how profiles and conformance work
- FHIR Terminology — CodeSystem, ValueSet, FHIR terminology operations