Speaking the Language of Australian Healthcare IT: A Practical Guide to the Systems, Standards, and Terms You’ll Actually Hear

Move from a US healthcare IT project to an Australian one, and the first thing you’ll notice is that half your vocabulary still works—EHR, FHIR, LOINC—and the other half doesn’t. Someone will mention “uploading a discharge summary to My Health Record” or ask whether a patient has an IHI, and if your only reference point is the American system, none of that maps cleanly. Australia solved similar interoperability problems with a genuinely different architecture, built around a national identifier system and a single shared record rather than the more fragmented, HIE-based US model. This is a walk through that architecture, term by term, in the order you’d actually encounter it on a project.

Terms in this paragraph

• EHR — Electronic Health Record; the digital system, at a practice or hospital, that holds a patient’s medical record — the same core concept as in the US, but in Australia it typically feeds into a separate national record rather than being the record patients and providers actually search
• FHIR — Fast Healthcare Interoperability Resources; the modern REST/JSON-based interoperability standard, used internationally including in Australia
• LOINC — Logical Observation Identifiers Names and Codes; the international standard for identifying lab tests and clinical observations, adopted in Australia largely as-is
• IHI — Individual Healthcare Identifier; a unique 16-digit number assigned to every person enrolled in Medicare or with a private health identifier, functioning as Australia’s national patient ID

The record that sits above all the others

The architectural centerpiece of Australian healthcare IT is My Health Record, a national, opt-out summary health record that sits above individual practice and hospital EHRs rather than replacing them. A GP’s local EHR remains the system of truth for day-to-day care, but discharge summaries, shared health summaries, prescription and dispense records, and pathology and diagnostic imaging reports get uploaded to My Health Record so that any treating provider, anywhere in the country, can see a patient’s history regardless of where it was created. This is a genuinely different model from the US, where interoperability happens more through point-to-point exchange and regional networks than a single national repository — and it shapes almost every integration decision you’ll make on an Australian project, because the question is rarely “how do we connect System A to System B” and much more often “how do we get this document correctly formatted and uploaded to the national record.”

Terms in this paragraph

• My Health Record — Australia’s national, opt-out digital health record that aggregates summary clinical documents from across the healthcare system
• GP — General Practitioner; a primary care doctor, typically a patient’s first and ongoing point of contact with the healthcare system 
• Shared Health Summary — a clinical document type uploaded to My Health Record, typically created by a patient’s usual GP, summarizing key health information
• Discharge Summary — a clinical document generated at the end of a hospital admission and uploaded to My Health Record

My Health Record is governed and operated by the ADHA (Australian Digital Health Agency), the federal body responsible for national digital health infrastructure, standards, and strategy — roughly analogous in role to the US ONC, though ADHA also directly operates the national record rather than only setting certification requirements for other vendors’ systems.

Terms in this paragraph

• ADHA — Australian Digital Health Agency; the federal agency responsible for national digital health strategy, standards, and operating My Health Record

Documents first, messages second

Where US hospitals lean heavily on HL7v2 for real-time, message-by-message data exchange, the Australian ecosystem leans more heavily on structured documents — particularly for anything destined for My Health Record. The dominant document format historically has been CDA (Clinical Document Architecture), an HL7 standard for representing clinical documents like discharge summaries and referrals in a structured, human-readable XML format. If you’re new to Australian health IT coming from a US background, expect to spend real time understanding CDA even if you’ve never touched it before — it’s still the backbone of much of the national document exchange, even as the country modernizes.

Terms in this paragraph

• CDA — Clinical Document Architecture; an HL7 standard for structured, human-readable clinical documents such as discharge summaries and referrals

That modernization is happening through FHIR, exactly as in the US, but implemented through an Australia-specific profile called AU Core (part of the broader AU FHIR Implementation Guide work led by ADHA and the Australian standards community). AU Core defines how FHIR resources — Patient, Observation, MedicationRequest, and the rest — should be structured and populated specifically for the Australian context, including how Australian identifiers and terminology systems slot into standard FHIR fields. Veterans in the field are watching FHIR and AU Core steadily extend beyond pilot projects into mainstream use, particularly as pharmacy and pathology systems modernize, though CDA-based document exchange with My Health Record remains the practical reality for most projects today.

Terms in this paragraph

• AU Core — the Australian national profile of FHIR, specifying how FHIR resources must be structured and populated for use in Australia
• AU FHIR Implementation Guide — the broader set of Australian FHIR implementation guidance that AU Core sits within, maintained by ADHA and the standards community

The vocabularies underneath the documents

Just as in the US, a document or message format only tells you how data moves — the meaning underneath is carried by separate terminology systems, and Australia’s are close cousins of the American ones but not identical.

SNOMED CT-AU is Australia’s national extension of SNOMED CT, maintained for the local market by the NCTS (National Clinical Terminology Service), which operates within ADHA. It plays the same role as SNOMED CT-US does across the Pacific — the primary coded vocabulary for diagnoses, procedures, findings, and body structures — but with Australia-specific extensions, refset content, and release governance. If you’re working across both markets, the concepts usually align closely with international SNOMED CT, but don’t assume a SNOMED CT-US code and a SNOMED CT-AU code are always the same string; check the release notes for local extensions before assuming equivalence.

Terms in this paragraph

• SNOMED CT-AU — the Australian national extension of SNOMED CT, the coded clinical vocabulary for diagnoses, procedures, findings, and body structures
• NCTS — National Clinical Terminology Service; the ADHA-operated body that maintains SNOMED CT-AU and related Australian terminology assets

Medications, rather than being handled by a system as broad as RxNorm, are handled by the AMT (Australian Medicines Terminology) — technically a specialized subset of SNOMED CT-AU rather than a fully separate vocabulary, which is itself a meaningful architectural difference from the US, where RxNorm is maintained independently of SNOMED CT-US. AMT codes represent trade products, generic products, and their packaging in a structured hierarchy, and it’s what underlies electronic prescribing and dispensing records that flow into My Health Record. Anyone building medication-related integrations in Australia needs to internalize this early: you’re not looking up a separate medication dictionary, you’re navigating a medicines-specific branch of the same terminology system used for everything else clinical.

Terms in this paragraph

• AMT — Australian Medicines Terminology; the structured vocabulary for medicines, packaged as a subset of SNOMED CT-AU rather than a standalone system

Lab and clinical observations use LOINC, largely unchanged from its international form, which is one of the easier vocabularies to carry over directly from a US project — the codes themselves are the same, though local implementation guidance around which LOINC codes to use for which Australian pathology tests can still differ in practice.

Terms in this paragraph

• LOINC — Logical Observation Identifiers Names and Codes; used in Australia largely as the same international standard familiar from US projects

Identifiers, funding, and the regulatory backbone

Where the US ties billing to ICD-10-CM, CPT, and the NPI, Australia’s funding-side coding runs through a different set of systems entirely, tied to the country’s universal healthcare system, Medicare. The MBS (Medicare Benefits Schedule) lists the services Medicare will subsidize, each with its own item number, and is the closest analogue to CPT in that it drives billing for medical services. The PBS (Pharmaceutical Benefits Scheme) does the equivalent for subsidized medications, listing which drugs are government-subsidized and under what conditions — a layer that has no direct US equivalent, since US drug subsidy structures work very differently.

Terms in this paragraph

• Medicare — Australia’s universal public health insurance scheme
• MBS — Medicare Benefits Schedule; the list of Medicare-subsidized medical services, each with a billing item number
• PBS — Pharmaceutical Benefits Scheme; the scheme listing government-subsidized medications and their conditions of use

Identity in the Australian system runs through a small family of numbers rather than a single NPI-style identifier. Every patient enrolled in Medicare has the IHI mentioned earlier; every individual clinician has an HPI-I (Healthcare Provider Identifier – Individual), and every healthcare organization has an HPI-O (Healthcare Provider Identifier – Organisation). Together these three identifiers are what let My Health Record and other national systems know exactly who a document is about and who created it, and you’ll see all three required in almost any integration touching national infrastructure. Access to that infrastructure is itself gated by NASH (National Authentication Service for Health), which issues the digital certificates a healthcare organization needs to securely connect to My Health Record and other national services — worth knowing early, because getting a NASH certificate sorted out is a common early blocker on integration timelines that has nothing to do with your actual code. 

Terms in this paragraph

• HPI-I — Healthcare Provider Identifier – Individual; a unique national identifier for individual clinicians
• HPI-O — Healthcare Provider Identifier – Organisation; a unique national identifier for healthcare organizations
• NASH — National Authentication Service for Health; the PKI-based system issuing digital certificates required to connect to My Health Record and other national health infrastructure

Why this matters more than it looks

The throughline across all of this is that Australia made an early, deliberate choice to centralize — one national record, one identifier scheme, one terminology authority in ADHA and NCTS — where the US allowed a more decentralized, market-driven ecosystem to emerge and only later tried to stitch it together through certification requirements and frameworks like TEFCA. Neither approach is simply better; each explains different pain points. In Australia, the friction usually shows up as document-formatting and NASH-certificate overhead when connecting to the single national system. In the US, it shows up as reconciling genuinely different systems that were never designed to talk to each other at all. Understanding which problem you’re solving — centralized-access friction versus fragmented-system reconciliation — will tell you more about how to plan an Australian project than memorizing the acronyms ever will, though the acronyms are, admittedly, where you have to start.

For those further along, the arc worth watching is AU Core’s gradual expansion as FHIR adoption grows across pathology, pharmacy, and hospital systems, alongside ADHA’s ongoing modernization of My Health Record itself — both slowly shifting the ecosystem from document-centric CDA exchange toward the more granular, API-driven interoperability the US market adopted somewhat earlier.

A Practical Checklist for Australian Healthcare IT Projects

Before starting an Australian healthcare integration, technology leaders should establish clarity around the following questions:

1. What is the source of truth?

Identify which clinical system owns the operational information and which information needs to be shared externally.

2. Does the workflow involve My Health Record?

If it does, understand the relevant document, identity, authentication, and submission requirements early.

3. Which interoperability standard applies?

Determine whether the workflow relies on CDA, FHIR, AU Core, or a combination of standards.

4. Which terminology systems are required?

Establish where SNOMED CT-AU, AMT, LOINC, or other terminology requirements apply.

5. How will identity be handled?

Account for the IHI, HPI-I, and HPI-O where applicable.

6. What authentication dependencies exist?

NASH and associated certificate requirements should be considered as part of integration planning.

7. Where does governance sit?

Define how information is validated, monitored, audited, and controlled.

8. What happens when AI is introduced?

AI should operate within the same governed information environment rather than becoming a disconnected layer on top of fragmented data.

September 2026