US vs Australia FHIR: Why Translating Healthcare Data Is Harder Than Translating Languages

June 2026

One of the most common questions at the start of an international healthcare project goes something like this: “We know US FHIR well — how much of that carries over to Australia?” It feels like it should be straightforward. Same standard, same resource types, same general architecture. In practice, it’s closer to knowing one language and assuming another will be easy to pick up: the grammar looks familiar, but the vocabulary is different, the idioms don’t map across, and the mistakes you make are hard to predict in advance.

The US and Australia both run on FHIR R4, both follow international standards — and yet they use different patient identifiers, different medication terminologies, different required data fields, and different national infrastructure. Behind each of those differences sits a specific reason: local regulation, pharmaceutical market structure, the history of how that country’s healthcare system evolved. Understanding where the systems diverge, and why, is what determines whether a team hits those differences in planning or in QA.

Consider a patient named John: Type 2 diabetes, metformin, occasional headaches. A clinician reads this in seconds. The systems that need to exchange this data across national boundaries see something far more ambiguous. 

One Diagnosis, Several Representations

When John’s diabetes gets recorded, the code used depends not on the diagnosis itself but on why it’s being recorded.

A physician sees one condition. A system integrating data across countries may encounter several representations of the same diagnosis — each correct in its own context, none directly interchangeable with the others. This isn’t a flaw in any single system; it reflects the fact that clinical information is captured differently depending on whether it’s driving a reimbursement claim, a population health dashboard, or a patient summary document. The diagnosis is the same. The data model behind it is not.

Medications: Where It Gets More Complicated

If diagnoses are tricky, medications are often worse.

Unlike diagnoses, medications are tightly bound to the local market — to what’s approved, how it’s packaged, how it’s reimbursed, and what it’s called in the national drug catalog. The same active ingredient can have entirely different representations in two countries, because the product itself exists differently in each healthcare ecosystem.

John’s metformin seems like a universally understood concept. In practice, a direct code-to-code translation between RxNorm and AMT isn’t always possible — the granularity differs, the product catalog differs, and the reimbursement logic differs. The assumption that “same active ingredient = same code” is one of the most common traps in cross-border medication data exchange.

The Symptom Problem Nobody Talks About

Diagnoses and medications at least have clear coding systems attached to them. Symptoms are harder — and in some ways they reveal the deepest structural difference between the two ecosystems.

In FHIR, a symptom doesn’t have a fixed home. John’s headache could legitimately live in a Condition resource (if it’s persistent enough to warrant clinical management) or in an Observation resource (if it’s a point-in-time complaint). The specification itself acknowledges this boundary is blurry: the same headache can be either, depending on context and clinical judgment. This isn’t unique to any one country — it’s a known ambiguity in the standard.

What is different between the US and Australia is the terminology used to code that symptom once a clinician decides where to put it. US Core uses SNOMED CT-US value sets for clinical findings; AU Core uses SNOMED CT-AU — the Australian national extension, maintained by the Australian Digital Health Agency and released on a different schedule than its US counterpart. The concepts largely overlap, but Australian clinical practice has generated its own set of terms, reference sets, and preferred expressions that have no direct equivalent in the US edition. A pipeline validating symptom codes against US terminology servers will silently treat AU-specific codes as unknown — which tends to surface in QA testing rather than during development, by which point it requires rework.

The practical result: the structural question of where to put John’s headache is the same in both countries. The terminological question of how to code it once it’s there is not.

When Shared Standards Aren’t Enough

SNOMED CT is the clearest illustration of how two countries can use the same standard and still end up with incompatible data. But it’s worth looking at a case where the standard genuinely is the same in both countries — because even then, the problem doesn’t go away.

Both the US and Australia use LOINC to identify laboratory tests and observations, with no national extensions and no diverging editions. The code for serum creatinine is the same in Sydney and in Boston. And yet two organizations exchanging a LOINC-coded lab result can still disagree on whether the value is normal — because LOINC standardizes what is being measured, not how the measurement is interpreted, what reference ranges apply, or how data quality is managed locally.

This is the deeper pattern. Shared standards solve the naming problem. They don’t solve the meaning problem — and in healthcare interoperability, meaning is where the real work is.

What This Means for Development Teams

When teams start international healthcare projects, the early focus typically lands on APIs, authentication, cloud infrastructure, and data formats. Those are all necessary. But the hardest problems in interoperability are usually semantic rather than technical, and they surface late — after the pipes are in place, when changing something has cascade effects.

John’s diabetes, his metformin, his headaches: three straightforward clinical facts that fragment into incompatible representations the moment they cross a national boundary. The coding system changes. The terminology edition changes. The resource type that holds the data may change. And none of this is visible at the API level — a pipeline can be technically correct and semantically broken at the same time.

That’s why the questions that matter most in international projects aren’t about infrastructure. They’re about the specifics of each domain: 

• Do we have a terminology server configured for SNOMED CT-AU, or are we still validating against the US edition? 
• How does our pipeline handle a medication code from AMT that has no direct RxNorm equivalent? 
• If a symptom arrives as an Observation from the US system and needs to be stored as a Condition in the Australian one — who decides, and based on what rule? 
• Are our reference ranges for lab results calibrated to local clinical practice, or did we inherit them from the US implementation?

These questions can’t be answered by reading an API specification. They require clinical knowledge of both systems — not just technical knowledge of the standard both systems claim to implement.