This guide is for architects and engineering leads deciding how to represent clinical data in an Australian product. The FHIR vs CDA question here has a sharper answer than the global debate suggests: the standards aren't competing for the same jobs. Each is mandatory in specific places, optional in others, and absent from a few where HL7 v2 still quietly does the work.
Here's the map — where each is required, what AU Base and AU Core actually are, and how to architect so the answer can keep changing without a rewrite.
FHIR vs CDA: the short answer
- CDA is required for clinical document upload to My Health Record. If you're sending Shared Health Summaries, Event Summaries, Discharge Summaries or similar to the national record via the B2B Gateway, you're producing CDA. No amount of FHIR enthusiasm changes this today.
- FHIR is where new work happens — the My Health Record FHIR Gateway for reading record content, AU Core for structured data exchange, AU eRequesting for pathology and imaging requests, and most new state and vendor APIs.
- HL7 v2 still carries enormous volume — pathology and imaging results, and most secure messaging payloads. Any product consuming results or referrals will meet it.
Where CDA is required, and what that involves
My Health Record's document repository is built on CDA. Each document type has a CDA Implementation Guide with Schematron rules published on the Digital Health Developer Portal, and documents are uploaded as signed CDA packages — the full mechanics are in the My Health Record integration guide.
Two properties of Australian CDA matter architecturally. First, the narrative block is the clinically authoritative content: what a human reads is the rendered document, so generating narrative faithfully from your structured data is a correctness requirement, not cosmetics. Second, conformance is per document type — the effort scales with how many document types you claim, which is why sensible products start with one or two.
The Agency is progressively modernising My Health Record around FHIR — the FHIR Gateway's read APIs are real and expanding — but document upload obligations for connected clinical software remain CDA-based today. Watch the Agency's roadmap; don't build a new product assuming CDA authorship disappears on a schedule you don't control.
Where FHIR applies: AU Base, AU Core and the Sparked pipeline
Australian FHIR standardisation runs through HL7 Australia and the Sparked AU FHIR Accelerator — a CSIRO-convened community of the Agency, the Department, vendors and providers producing national implementation guides. The two you must be able to tell apart:
- AU Base — the foundational profiling layer: Australian representations of FHIR R4 resources (Medicare and DVA numbers, IHI/HPI-I/HPI-O identifiers, Australian address and medicine representations). It's the vocabulary, not a contract — you rarely 'conform to AU Base'; you build with it.
- AU Core — the exchange contract: a US-Core-style specification defining minimum data and RESTful API expectations (which profiles, which search parameters, which interactions a conformant system supports). This is what tenders and integration requirements increasingly cite, and it's where conformance claims attach.
What to actually target
For new structured-data interfaces, target AU Core profiles on FHIR R4 and say so precisely — 'AU Core conformant' is a checkable claim about specific profiles and interactions, where 'we support FHIR' is marketing. Beyond AU Core, the Sparked pipeline is producing domain guides (AU eRequesting for diagnostics ordering among them); if you're in one of those domains, track the guide's maturity before inventing your own profiles. Terminology comes from the National Clinical Terminology Service — SNOMED CT-AU and AMT — regardless of which syntax carries it.
The HL7 v2 reality check
Pathology results, imaging reports, and the referral traffic moving over secure message delivery are overwhelmingly HL7 v2 today. A clinical product that consumes results will spend more engineering effort on v2 parsing and rendering quirks than on either CDA or FHIR. Plan for it: v2 isn't legacy debt to be scheduled away, it's a live interface with decades of local dialect.
A quick decision map
By use case, as things stand today:
- Uploading clinical documents to My Health Record → CDA, per document-type implementation guide, via the B2B Gateway.
- Reading My Health Record content from an app → FHIR, via the My Health Record FHIR Gateway's read APIs.
- A new structured-data API between systems → FHIR R4 with AU Core profiles, stated precisely.
- Diagnostics ordering → FHIR, via the AU eRequesting implementation guide as it matures.
- Consuming pathology and imaging results → HL7 v2 (with some PIT legacy), and it will stay that way for a while.
- Referrals over secure messaging → HL7 v2 payloads over SMD today, with CDA in some pathways.
- Prescriptions → the exchange's conformance-defined interfaces; not a format you choose.
Architectural guidance
The teams that handle this landscape well stop treating any wire format as their data model. Keep a clean internal clinical model — FHIR-shaped is a reasonable choice, given where the ecosystem is heading — and generate CDA, FHIR resources, or v2 messages at the edges. CDA authorship in particular should be an output pipeline (structured data in, valid signed package out) with the implementation-guide specifics quarantined in one place.
This is also the only sane posture for the transition years ahead: My Health Record modernisation, AU Core adoption, and jurisdiction programs will keep shifting which format is required where. An edge-generated format is a sprint of work to add; a format baked into your storage layer is a migration.
Common failure modes and gotchas
- Building FHIR-only and hitting the CDA wall. The most common startup mistake in this domain: a clean FHIR product that discovers My Health Record upload conformance six months before a tender requires it. If the national record is in your future, cost CDA authorship into the roadmap on day one.
- CDA narrative and entries disagreeing. Generating structured entries and narrative through separate code paths produces documents where the human-readable content contradicts the machine-readable content. Clinicians read the narrative; safety reviews will too. Generate one from the other.
- Taking 'FHIR support' at face value. A vendor claiming FHIR may mean R4, R4B, a US Core shape, or a handful of bespoke profiles. Integration estimates depend on the actual profiles and interactions — ask for the CapabilityStatement, and check it against AU Core if that's your requirement.
- Version drift. AU Base and AU Core target FHIR R4; libraries and examples floating around target R4B or R5. Mixing them produces subtle validation failures. Pin versions explicitly across your toolchain.
- Treating v2 as a temporary shim. Products that consume results 'temporarily, until FHIR' accumulate an untested v2 path that handles the majority of their clinical data. Resource it like the primary interface it is.
- Rolling your own terminology handling. SNOMED CT-AU and AMT are large, versioned, and centrally distributed via the NCTS. Hand-maintained code lists drift within months and fail conformance checks that validate against current terminology.
Choosing between FHIR and CDA for an Australian build — or needing both? CareForge designs clinical data architectures that pass conformance on today's requirements without betting the product against tomorrow's. Book an intro call.
Last reviewed: July 2026