Healthtech Interoperability Standards for AI in Australia

Building an AI feature on top of clinical data in Australia is not the same problem as building one on top of a CRM or a logistics dataset. The data model, the consent rules, and the regulator all change. This guide walks through the standards and requirements a technical leader needs to understand before shipping an AI-enabled healthtech product in Australia — FHIR, My Health Record integration, the Australian Digital Health Agency's (ADHA) role, and where the Therapeutic Goods Administration (TGA) fits.

A note on scope: this is an engineering and architecture guide, not legal advice. Regulatory guidance in this space changes, and requirements vary by product classification. Confirm current obligations directly with ADHA and the TGA, and involve health law counsel before deployment.

What is healthtech interoperability and why does it matter for AI products?

Healthtech interoperability is the ability for clinical systems, records, and applications to exchange and correctly interpret patient data without custom point-to-point integration for every connection. For an AI product, interoperability determines whether your model can access data at all, in what shape, and under what governance. An AI feature that cannot integrate cleanly with a hospital's patient administration system or a GP's practice management software will not get adopted, regardless of how good the model is.

This matters more for AI products than traditional software because AI features typically need broader, longitudinal data access — history, medications, pathology results — to be useful. That breadth increases both the integration surface area and the compliance obligations.

What is FHIR and why does it matter for AI-enabled healthtech?

FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard that defines how healthcare information is structured and exchanged as discoverable, RESTful API resources — patients, observations, medications, encounters, and more. In Australia, HL7 Australia maintains localised implementation guides, commonly referred to as AU Base and AU Core, which constrain the global FHIR specification to Australian identifiers, terminologies, and clinical workflows.

For AI-enabled products, FHIR matters in two ways. First, it is increasingly the expected integration surface for connecting to electronic medical records, pathology systems, and My Health Record itself — building to FHIR from day one reduces the number of bespoke integrations you will otherwise need to maintain. Second, FHIR resources give you a consistent, well-typed data model to build feature pipelines and training data extraction against, rather than reverse-engineering proprietary HL7v2 message formats or vendor-specific database schemas. Many Australian clinical systems still run on older HL7v2 messaging underneath, so a realistic architecture often needs to support both FHIR APIs and legacy HL7v2 feeds during a transition period.

How does My Health Record integration work for AI products?

My Health Record is Australia's national digital health record system, operated by ADHA, that gives individuals and authorised healthcare providers a shared view of a patient's health information. Connecting to it is a formal, governed process — not an open API you can call after signing up for a developer key.

Organisations that want to connect typically need to go through a conformance and registration process with ADHA, demonstrate compliance with the My Health Records Act 2012 and associated rules, and integrate with supporting national infrastructure such as the Healthcare Identifiers (HI) Service and the National Authentication Service for Health (NASH) for identity and authentication. Access is generally scoped to registered healthcare provider organisations, which has a direct implication for AI vendors: most healthtech companies building AI features will integrate indirectly, through a customer's existing conformant clinical system, rather than connecting to My Health Record directly. Confirm the current conformance and vendor pathway with ADHA before committing to an architecture, as processes and eligibility criteria are periodically updated.

What does the Australian Digital Health Agency require for interoperability?

ADHA is the government agency responsible for national digital health infrastructure, standards, and strategy, including My Health Record, the HI Service, and Australia's broader interoperability roadmap. ADHA does not certify AI models, but it does set and maintain the technical and governance standards that any system touching national health infrastructure must meet.

In practice, this means technical leaders should treat ADHA's published standards — including its FHIR implementation guides, security and conformance requirements, and clinical safety guidance — as the baseline architecture constraint, not an afterthought layered on at the end of a build. Designing your data ingestion, consent handling, and audit logging around these standards from the start is materially cheaper than retrofitting them once a pilot customer asks for a conformance statement.

Where does the TGA fit in regulating AI-enabled medical software?

The Therapeutic Goods Administration regulates software that meets the definition of a medical device — commonly called Software as a Medical Device (SaMD) — under the Therapeutic Goods Act 1989. Whether your AI feature is a regulated medical device depends on its intended purpose: software that provides general wellness information or basic administrative support is typically out of scope, while software that is intended to diagnose, monitor, or inform treatment decisions is more likely to be captured.

The TGA has issued specific reforms and guidance addressing clinical decision support software and AI/ML-based products, including some exemptions for lower-risk clinical decision support tools that meet defined transparency conditions. Because classification drives everything downstream — quality management requirements, clinical evidence expectations, and post-market surveillance obligations — this determination should be made early, ideally before architecture decisions lock in a workflow that would be difficult to remediate later. This is a regulatory classification exercise that needs specialist input; do not assume your AI feature is exempt without confirming it against current TGA guidance.

Comparing integration paths for AI-enabled healthtech

There is no single correct integration path — the right choice depends on what data you need, which systems your customers already run, and how directly you need to connect to national infrastructure.

Integration path	Typical use case	Relative complexity	Governance overhead
FHIR API to a customer's clinical system	Reading/writing structured clinical data within a single provider's system	Moderate	Moderate — depends on customer's own compliance posture
HL7v2 message feed	Integrating with legacy hospital or pathology systems	Higher (older, less structured)	Moderate
Indirect My Health Record access via a conformant vendor	Viewing shared health summaries within an existing clinical workflow	Higher	High — inherits the vendor's conformance and consent obligations
Direct My Health Record conformance	Building a registered healthcare provider system that connects to the national record	Highest	Highest — full ADHA conformance, HI Service, NASH

What should technical leaders do before deploying AI on clinical data?

Before any clinical data reaches a model, technical leaders should have answered four questions: what is the TGA classification of the feature, what data standard (FHIR AU Core, HL7v2, or proprietary) will the integration use, what consent and access model applies under the Privacy Act and the My Health Records Act, and how will model outputs be logged and audited for clinical safety review. Answering these after a pilot is underway is where most healthtech AI projects lose months.

A practical build sequence looks like: confirm regulatory classification with specialist counsel and, where needed, the TGA; design the data layer around FHIR AU Core from the outset even if your first customer only supports HL7v2, so you are not re-architecting later; build consent, audit, and access-control logging into the pipeline rather than the model; and only then invest in the AI feature itself. This sequencing mirrors how we approach data infrastructure work generally — the pipeline discipline has to exist before the model is trustworthy — and it applies to AI engineering on clinical data specifically, where audit trails and explainability are not optional extras.

For healthtech companies still running on legacy patient management systems, standards compliance is often blocked by the underlying application architecture rather than the AI layer itself. In that situation, an incremental application modernisation approach — decoupling data access behind FHIR-conformant interfaces before touching the AI feature — tends to de-risk the project more than attempting both at once. If you are still forming the product strategy, working through classification and data-access questions as part of an AI product strategy engagement, before committing engineering resources, is the cheaper place to find these constraints.

More broadly, our insights cover the adjacent engineering and AI-adoption questions this guide doesn't — from choosing between RAG and fine-tuning to assessing organisational AI readiness.

If you're navigating FHIR integration, My Health Record conformance, or TGA classification for an AI feature and want a second set of eyes on the architecture before you commit engineering time, get in touch — we're happy to talk through where the real constraints sit for your specific product.