Skip to main content
← All articles

CI Gated AU Core FHIR Integration for Australian Healthcare Developers

Decorative FHIR integration title card

FHIR is the recommended API-first standard for exchanging healthcare data, and for Australian projects that means aligning early to AU Core profiles and the My Health Record FHIR Gateway. The single most important early move is to pick AU Core-aligned profiles and mapping your identity and conformance requirements before writing a line of integration code. Get that sequencing wrong and you’ll be reworking data models mid-build.

TL;DR:

  • Ensuring early alignment with AU Core profiles and the My Health Record FHIR Gateway is crucial to avoid costly data model rework during development.
  • Most Australian systems still run HL7 v2 internally, with FHIR primarily serving as the integration layer for real-time queries and modern applications.
  • Choosing the correct integration pattern—direct, gateway, or event-driven—is vital, with validation of server capabilities before designing endpoints to prevent future rework.
  • Reliable patient identity matching via the Healthcare Identifiers service and strict governance on terminology bindings are essential to prevent duplicate records and semantic errors.
  • Prioritize a few high-value data exchanges and automate conformance testing early to ensure scalable, accurate implementation across clinical workflows.
Meddle
Connect Patients With The Right Care
Meddle helps patients find practitioners who understand their needs through AI-powered matching and simpler appointment booking.

Table of Contents

What is FHIR integration in healthcare? How does it differ from HL7 v2/CDA?

FHIR (Fast Healthcare Interoperability Resources) organises clinical information into discrete resources, such as Patient, Observation, and MedicationRequest, each accessible through standard REST interactions. You read, search, create, and update these resources over HTTP, much like any modern web API. That’s a genuinely different model from what most legacy Australian systems were built around.

HL7 v2 moves data through point-to-point messages triggered by clinical events, like ADT feeds firing on patient admission. CDA packages entire clinical documents, discharge summaries, referral letters, as structured XML. Both formats work, but they’re rigid: a small schema change can break every downstream consumer.

FHIR’s resource granularity fixes that. You can request a single lab result instead of parsing a whole document, and a CapabilityStatement tells you exactly what a server supports before you connect.

  • HL7 v2: fast, message-based, still dominant in pathology and pharmacy feeds
  • CDA: document-based, useful for discharge summaries and referrals
  • FHIR: resource-based REST API, best for real-time queries and modern app integration

Legacy formats aren’t disappearing soon. Most Australian hospitals still run HL7 v2 internally, with FHIR sitting at the integration edge, translating outward.

AU Core, AU Base, and My Health Record: what must you build against?

Australian FHIR work runs on two layered implementation guides. AU Core sets the minimum expectations every conformant system must meet, things like which fields are mandatory on a Patient resource and which search parameters a server must support. AU Base sits on top, adding Australia-specific concepts HL7’s base spec doesn’t cover, like Medicare card numbers and PBS item codes.

If your integration touches My Health Record directly, you’re working against the My Health Record FHIR® Gateway, which publishes R4 artefacts, an NPM package with validation JSON and schema files, and example resource instances you can test against before going near production data.

A few things worth flagging before you start:

  • You’ll need registration and technical prerequisites cleared with the Australian Digital Health Agency before Gateway access opens up
  • Procurement processes are increasingly enforcing conformance to these guides rather than treating them as optional, a shift analysts have flagged as a national trend
  • The Agency’s FHIR training courses cover FHIR fundamentals, SMART on FHIR, and project management framing, worth booking early if your team is new to this

Skipping AU Base because “the base FHIR spec already covers patients” is one of the more common early mistakes. It doesn’t, not for Medicare and PBS fields Australian systems depend on daily.

Which integration pattern should you use: REST APIs, SMART on FHIR, or file-based exchange?

Most Australian integrations land on one of three patterns, and picking the wrong one early costs you rework later.

A CapabilityStatement published by every conformant FHIR server tells you what resources, search parameters, and operations it actually supports, so query that before you design a single endpoint call. Skipping this step is how teams end up hardcoding assumptions that break the moment a vendor upgrades their server.

SMART on FHIR handles the authorisation layer for user-facing apps, like a clinician-facing dashboard pulling patient records through delegated access. It uses OAuth2 under the hood, issuing scoped tokens tied to a specific patient or practitioner context. This pattern suits situations where a human is actively authorising access in the moment, rather than a system-to-system batch job.

SMART on FHIR delegated access flow

File-based FHIR exchange still matters for ETL and batch workloads, nightly patient list syncs, bulk immunisation records, that sort of thing. NDJSON bundles work well here, but they demand the same validation rigour as live API calls; a malformed bundle silently corrupting overnight is worse than a live call failing loudly.

For architecture, three patterns cover most real deployments:

  1. Direct server/client: your system talks straight to a FHIR server, simplest option for small integrations with one counterpart
  2. Gateway pattern: a middleware layer handles auth, transformation, and retries, better for multiple upstream and downstream systems
  3. Event-driven ingestion: queue-based consumption of FHIR bundles or subscription notifications, best for high-volume, near-real-time needs like admission alerts

Pro Tip: Build your transformation layer to fail loudly and specifically. A silent data-mapping error between your legacy system and a FHIR resource is far more dangerous than a rejected API call, because nobody notices until a clinician is looking at the wrong medication list.

Patient matching is where a lot of well-built FHIR integrations quietly go wrong. Without reliable identity resolution through the Healthcare Identifiers (HI) Service, you end up with duplicate patient records scattered across systems, a risk implementation reviews consistently flag as one of the highest-impact failure modes in real deployments.

Security design follows standard OAuth2 and SMART scope principles, but the discipline matters more in healthcare than most domains:

  • Design access tokens around least-privilege scopes, request only the resource types and actions a given app genuinely needs
  • Build consent models that handle partial visibility correctly, a patient may consent to share medication data but not mental health notes
  • Log every access event; audit trails aren’t optional in a regulated data environment
  • Limit blast radius by scoping API credentials per integration, not per organisation

The Digital Health Agency’s interoperability plan puts identity and secure information sharing at the centre of its national priorities through 2028, and for good reason: a matching error doesn’t just cause a technical bug, it risks clinical harm.

How do you test and validate a FHIR integration before going live?

Conformance testing isn’t a final QA step, it belongs in your CI pipeline from the first commit. The My Health Record FHIR Gateway’s NPM package ships validation JSON and schema files specifically so you can automate this rather than eyeballing sample payloads.

A practical roadmap looks like this:

  1. Pull the AU Core and AU Base profile definitions into your CI pipeline as validation gates
  2. Reject non-conformant builds automatically, don’t let a failed terminology binding merge to main
  3. Track validation pass rate and failed-call rate as release metrics, not just uptime
  4. Re-run validation against updated Gateway artefacts whenever the Agency publishes a new version

Treat validation failures as blocking, not advisory. A payload that passes your internal tests but fails AU Core validation will fail in production, just later and more expensively.

What are the most common FHIR implementation pitfalls?

Semantic drift is the quiet killer of otherwise solid FHIR builds: two systems both claim to support the same resource, but interpret a coded field differently because nobody locked down the terminology binding. Systematic reviews of FHIR deployments consistently identify this, alongside identifier mismatches and weak governance, as the recurring failure pattern across projects.

Mitigation isn’t complicated, but it does need discipline:

  • Lock terminology bindings early and document them, don’t leave coded fields open to interpretation
  • Treat HI Service conformance as a day-one requirement, not a later add-on, to avoid duplicate patient records
  • Build an extension governance policy with version checks at ingest, so vendor-specific extensions don’t quietly diverge over time
  • Start with two or three high-value exchanges, referrals and medication lists are a common starting pair, align them to AU Core, then automate validation before scaling further

Pro Tip: Don’t try to FHIR-enable your entire data estate in one release. Teams that pick a narrow, high-value exchange first and prove the conformance pipeline works are the ones that scale smoothly later.

Delivery tips for rolling out FHIR in your organisation

Prioritise two or three high-value exchanges and automate conformance checks before you scale wider. Build a benefits case tied to actual clinical workflow gains, fewer duplicate referrals, faster medication reconciliation, so stakeholders see the payoff. Before kickoff, map your stakeholders, plan your identity approach, lock terminology bindings, and get CI validation running. Skip any one of these and you’ll be retrofitting it under pressure later.

— Taylor

How Meddle fits into your FHIR-enabled rollout

If your clinic or practice is weighing up integration options, Meddle gives allied health providers a practical way to plug patient matching, scheduling, and referral automation into a broader interoperability strategy without building every connector from scratch.

Meddle

Meddle’s platform includes CRM integration support and a practice management dashboard built for the referral and scheduling workflows allied health teams run daily, so a FHIR-enabled data layer has somewhere useful to land on the clinic side. Meddle is squarely focused on allied health, physiotherapy, psychology, occupational therapy, speech pathology, dietetics, exercise physiology, podiatry, and related fields, which makes it one practical piece of a wider FHIR rollout rather than a replacement for your core clinical systems.

CRM Integration is available as an add-on, and you can see how the platform’s matching and booking workflow actually works before deciding. Check current pricing and plans to see which option fits your practice’s integration needs.

Authoritative resources for your FHIR build

Bookmark these before you start: the HL7 FHIR specification for resource and interaction definitions, the My Health Record FHIR Gateway for AU-specific artefacts, and the Agency’s FHIR training courses for team upskilling.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources

FAQ

Will FHIR replace HL7 entirely?

Not in the near term. FHIR is steadily replacing HL7 v2 and CDA for new API-driven integrations, but many Australian systems still rely on HL7 v2 messaging internally, with FHIR increasingly sitting at the integration edge.

What’s the difference between HL7 and FHIR?

HL7 v2 sends event-triggered messages and CDA packages full clinical documents, while FHIR breaks data into discrete, individually queryable resources accessed through a standard REST API.

What are the FHIR healthcare standards used in Australia?

Australian implementations build on the base HL7 FHIR specification, layered with AU Core for minimum conformance requirements and AU Base for Australia-specific fields like Medicare and PBS identifiers.

What are the disadvantages of FHIR?

FHIR implementations commonly struggle with semantic drift between systems, patient identity mismatches, and the governance overhead needed to keep terminology bindings and extensions consistent across vendors.

Does Meddle support FHIR-based integrations?

Meddle offers CRM integration and API support suited to allied health scheduling and referral workflows, making it a practical piece of a broader FHIR-enabled rollout rather than a full clinical FHIR server.