Author: Clinovera Expert Team  ·  Last updated: May 2025

What is the difference between Australian FHIR and US FHIR?

Both countries use FHIR R4 (Release 4) as the base standard — the HL7 specification that defines resource types like Patient, Observation, Medication, and Encounter. The core resource structure is identical across jurisdictions.

The differences appear at the Implementation Guide (IG) layer. An Implementation Guide sits on top of FHIR R4 and specifies which identifiers are expected, which terminology systems are valid, which data fields are required, and how profiles and extensions must be structured.

In the US, that guide is US Core, aligned with the USCDI dataset and enforced through ONC interoperability rules. In Australia, the equivalent is AU Base and AU Core, aligned with AUCDI and national health infrastructure including My Health Record.

Australian FHIR and US FHIR share the same standard. They do not share the same implementation expectations.

How does the US FHIR architecture compare to Australian FHIR?

The table below compares a typical US FHIR integration stack with its Australian equivalent across key dimensions.

Both ecosystems align with the International Patient Summary (IPS) and International Patient Access (IPA) standards, preserving cross-border portability at the IPS/IPA level even where implementation details diverge.

What specifically changes when moving from US Core to AU Core?

Five areas require direct engineering work. None are configuration options — each requires deliberate implementation decisions and code changes.

1 · Patient Identifiers

In the US, cross-organisation patient matching relies on probabilistic MPI (Master Patient Index) algorithms — a mature, well-supported approach within the US ecosystem. In Australia, the IHI (Individual Healthcare Identifier) is a national, person-level identifier assigned to every Australian. Australian FHIR uses IHI as the authoritative cross-system key, making cross-organisation matching identifier-based rather than algorithmic.

Australian FHIR integrations also carry Medicare numbers and local MRNs, but these play supporting roles. IHI requires specific handling — identifier system, use, and value fields follow AU Base profile conventions that differ from US patterns, and IHI validation against the HI Service adds an additional integration step not present in US projects.

2 · Terminology Systems

SNOMED CT-US and SNOMED CT-AU use different national extensions, code sets, and release cycles. Any coded field using SNOMED must reference the correct national edition. Australian FHIR uses AMT (Australian Medicines Terminology) for medication coding instead of RxNorm. Terminology server configuration, value set bindings, and coded field validation all need to be rebuilt for the AU context.

3 · Required Data Elements: AUCDI vs USCDI

US Core defines required data elements from the USCDI. AU Core defines required fields from AUCDI (Australian Clinical Data for Interoperability). The datasets overlap significantly, but differences apply in both directions: some USCDI fields are absent from AUCDI, and some AUCDI fields have no US Core equivalent — for example, indigenous status, which uses AU-specific extension URLs and terminology with no US counterpart.

4 · Extensions and Custom Mappings

Three AU Base extensions required custom DTL (Data Transformation Language) code in the Clinovera Macquarie project (2024). None were available as configuration options in the standard InterSystems IRIS pipeline.

5 · My Health Record

Australia operates a national shared health record — My Health Record (MHR) — administered by the Australian Digital Health Agency (ADHA). My Health Record has no direct equivalent in the US in terms of national scope.

Two integration patterns are common in Australian FHIR projects:

• EHR via FHIR API — direct, real-time exchange between an application and an EHR system (Epic, Cerner, or other vendors). The most common pattern; uses standard AU Core profiles.
• My Health Record integration — supports cross-provider document exchange, national clinical summaries, and patient-level access. Required for specific regulatory workflows; adds profile constraints beyond AU Core.

My Health Record scope should be confirmed at the start of a project. Retrofitting MHR conformance onto an integration not designed for it adds rework that early planning avoids.

What does Australian FHIR look like in a real integration?

In the Macquarie General Hospital (MQH) project completed in 2024, Australian FHIR integration used InterSystems IRIS as the transformation engine connecting to the hospital EHR via AU Base-profiled FHIR APIs. The project required three custom DTL maps (extensions above), specific IHI identifier handling, and AMT-based medication coding throughout.

A Patient resource in an AU Core implementation carries a different profile URL — http://hl7.org.au/fhir/StructureDefinition/au-patient — different extension URLs, and different identifier systems compared to a US Core Patient. An AU Core validator flags standard US Core Patient output as non-conformant on multiple fields.

The practical result: a correctly built, FHIR R4-compliant US pipeline passes the base standard version check. It does not pass AU Core conformance validation without the changes described above.

How should a team approach an Australian FHIR integration project?

1. Audit against AU Core, not just FHIR R4. FHIR R4 compliance is a prerequisite, not a guarantee of AU Core conformance. Run AU Core validation on your existing pipeline early — not after the build is complete.
2. Define the identifier strategy before writing integration code. Determine how IHI, Medicare numbers, and local MRNs coexist in your data model. Patient search and matching logic depends on this decision, and changing it mid-project has cascade effects.
3. Switch terminology configurations to AU equivalents. Replace US Core value sets with AUCDI-aligned sets. Point validation tooling at AU terminology servers. Audit every coded field against AMT and SNOMED CT-AU.
4. Build AU-specific extensions as custom code. Indigenous status, religion, and birth place extensions each require a separate custom DTL map. Budget for this as distinct development work rather than a minor adjustment to existing mappings.
5. Confirm My Health Record scope at the start. If MHR participation is in scope, conformance requirements and profile constraints change. Determine this before finalising the integration design.
6. Use AU-specific implementation resources. HL7 Australia (hl7.org.au) maintains AU Base and AU Core Implementation Guides. The Australian Digital Health Agency (digitalhealth.gov.au) publishes MHR conformance requirements.

What stays the same between US FHIR and Australian FHIR?

Teams with strong FHIR R4 experience have the right foundation. The core of the standard is shared:

• FHIR R4 as the base standard
• Alignment with International Patient Summary (IPS) and International Patient Access (IPA)
• Core resource types: Patient, Observation, Medication, Encounter
• LOINC for lab observations
• Application ↔ EHR via FHIR API integration pattern
• SMART-on-FHIR for application authorisation

The differences appear at the Implementation Guide level and below. A developer familiar with US Core FHIR will recognise the structure immediately. The work is understanding where AU Core diverges and building for those divergences deliberately.

Why does implementation guide expertise matter more than FHIR expertise alone?

Integration teams with strong FHIR R4 skills have the right foundation for Australian FHIR work. The resource structure is familiar, the API pattern is the same, and the tooling overlaps significantly.

Where projects encounter difficulty is in treating FHIR R4 compliance as sufficient. It is not. AU Core adds conformance requirements that a correctly built, well-tested US FHIR pipeline will not automatically satisfy. The identifier model, terminology bindings, required extensions, and in-scope data elements all require jurisdiction-specific decisions and implementation work.

That expertise — knowing specifically where AU Core diverges from US Core and building for each divergence — determines whether conformance issues surface in planning or in QA.

Clinovera works across both the US and Australian FHIR ecosystems. Whether expanding a US integration into Australia or building in either market from the start, the implementation knowledge applies across both environments.