Healthcare Interoperability in Australia: A Practical Guide

Healthcare interoperability determines whether important patient information follows a person across general practice, hospitals, specialists, pharmacy and aged care, and whether clinicians can use it safely once it arrives. For Australian clinical leaders, health-service teams and technology buyers, the challenge goes beyond connecting two systems. Identity, structure, meaning, permissions and workflow all have to hold together. Understanding those layers reveals where Australia stands in 2026 and what to require from an integration.
What is healthcare interoperability?
Healthcare interoperability is the ability of different systems and products to exchange information while preserving its meaning, without special effort from the user. That final condition matters. A discharge summary arriving as a PDF may be a successful transfer, but the receiving clinician may still need to search, interpret and re-enter its contents before acting on them.
The Australian Digital Health Agency definition therefore focuses on transferring meaning, not simply moving files. Useful exchange gives the right authorised person information that is correctly matched, understandable and available inside the workflow where care happens.
Interoperability and integration are different
An integration is a connection between systems. Interoperability is the outcome that connection achieves.
A point-to-point interface can pull a patient’s name and appointment into another application. A deeper connection can also retrieve relevant clinical context, return structured information to the correct fields, preserve its source and flag failures for review. Both may be sold as “integrated”, even though they remove very different amounts of clinical and administrative work.
The four levels of interoperability
The four recognised levels build on one another. A hospital-to-GP medication handover shows why every level matters.
| Level | What it means | Medication handover example | What can still fail |
|---|---|---|---|
| Foundational | One system can send data to another. | The GP system receives a discharge summary. | The information may be unreadable or require manual entry. |
| Structural | Both systems preserve an agreed format and field structure. | Medicines, doses and instructions arrive in predictable fields. | Different codes or local terms may change the intended meaning. |
| Semantic | Both systems interpret the clinical meaning consistently. | The receiving system understands the medicine, dose, route and whether it was started, changed or ceased. | The information may reach the wrong person or sit outside the team’s workflow. |
| Organisational | Governance, identity, permissions and workflows support safe use across organisations. | The correct GP can review, reconcile and act on the change, with clear responsibility and an audit trail. | Poor adoption, training or local processes can still delay action. |
This is why Fast Healthcare Interoperability Resources (FHIR) alone does not complete the job. FHIR can define how data is represented and exchanged. Implementers still need consistent profiles, terminology, identity matching, authorisation, workflow design and clinical governance.

Why connected information matters in Australia
Australian care often crosses organisational and software boundaries. A person may move from a GP to pathology, imaging, a specialist clinic, hospital and community pharmacy, then return to primary care. At each handover, missing context can lead to repeated questions, delayed follow-up, duplicate work and clinical risk.
The problem remains visible in day-to-day practice. The Agency’s 2025 Interoperability Survey included 792 healthcare providers and 33 follow-up interviews. Providers reported using digital methods to search for clinical information 44% of the time, up from 31% in 2022. Yet 20% reported using a printer at least 20 times a day, and information exchange still relied heavily on email, fax, post, phone calls and patients carrying information themselves.
The same survey found that 72% of respondents interacted with GP clinics, while only 20% of GP clinics used digital systems to send patient information outwards. Respondents connected difficulty accessing information with gaps, delays, loss of patient trust and patient-safety risks. These findings reflect a practical reality: digitising a local record does not connect a care journey.
Effective interoperability supports:
- Safer clinical review: clinicians can see permitted information in context and identify discrepancies before making decisions.
- Continuity of care: referrals, results, discharge information and medication changes can follow the patient across settings.
- Less manual handling: structured import and write-back reduce printing, scanning, copy-and-paste and repeated data entry.
- Patient participation: people can access key information and exercise available controls over who can see it.
- Better service planning: permitted, consistent data can support quality improvement and population-level analysis.
These benefits depend on data quality and responsible use. Fast access to an incorrectly matched patient, an outdated medicine or a result stripped of context creates a different risk rather than solving the original one.
The building blocks of healthcare interoperability in Australia
Australia uses a combination of national infrastructure, international exchange standards and Australian data specifications. Each solves a different part of the problem.
Reliable identity
The Healthcare Identifiers Service assigns identifiers to individuals, practitioners and organisations. Individual Healthcare Identifiers (IHIs), Healthcare Provider Identifier-Individuals (HPI-Is) and Healthcare Provider Identifier-Organisations (HPI-Os) help systems associate information with the right participants in a healthcare event.
Identity controls still need operational safeguards. Systems must handle demographic changes, duplicate records, mismatches and uncertain matches without silently filing information against the wrong patient.
A shared exchange method
Health Level Seven (HL7) standards provide common ways to exchange clinical information. HL7 v2 remains widespread in established hospital environments. FHIR uses modular resources and modern application programming interfaces (APIs), which can support more granular requests and updates. Substitutable Medical Applications and Reusable Technologies (SMART) on FHIR adds a standard approach for launching authorised applications inside an electronic health record with patient and user context.
The standard name is only a starting point. Two products can both support FHIR while using different versions, profiles, resources, required fields or update behaviour. An implementation guide and tested conformance criteria turn the broad standard into a dependable connection.
Consistent data and terminology
AU Core sets minimum expectations for recording, searching and retrieving core information through FHIR in an Australian context. Australian Clinical Data for Interoperability (AUCDI) defines a reusable foundation for the clinical data itself. The Australian edition of SNOMED Clinical Terms (SNOMED CT-AU) and the Australian Medicines Terminology give systems a shared vocabulary for clinical concepts and medicines.
Australia strengthened this baseline in 2026. Under the updated My Health Record requirements, AU Core is required for FHIR connections to My Health Record, and AUCDI is the content reference where its scope covers the information being uploaded. Relevant systems must also meet applicable conformance profiles and terminology requirements. The current requirements specify the version through the relevant implementation guide or conformance profile.
National sharing services
My Health Record is a secure online summary of key health information. It can make reports, shared health summaries, discharge summaries and other documents available across settings, subject to access and consumer controls. It remains a summary, rather than a complete clinical record, so clinicians use it alongside local records and other sources.
Since 1 July 2026, public and private pathology and diagnostic imaging providers must upload in-scope written reports authored by or on behalf of a pathologist or radiologist to My Health Record within the required timeframe, unless an exception applies or an extension has been granted. The requirement does not include diagnostic images. Patients or their representatives can request that a report is not uploaded. The Agency’s Share by Default guidance sets out the scope, exceptions and evidence requirements.
What healthcare interoperability does not guarantee
Interoperability can improve access without guaranteeing that every item is current, complete or clinically appropriate. A safe implementation keeps these boundaries visible:
- Availability is not completeness. A connected source may contain only part of the patient’s history.
- Standard structure is not correct data. Mapping, entry and patient-matching errors can still travel between systems.
- Access is not authority to use everything. Privacy, purpose, role, consent or other authorisation requirements still apply.
- Automation is not clinical sign-off. Drafts, reconciliations and imported information still need the review defined by the clinical workflow.
- Successful transmission is not successful care. Teams need responsibility, alerts, downtime processes and a way to resolve failed or conflicting information.
Australian Privacy Principle 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access, modification or disclosure. The OAIC security guidance makes clear that interoperability needs technical and organisational controls. Encryption is one control among access management, audit logging, monitoring, staff practice, vendor governance and safe disposal.
How to assess an interoperable system
Start with a clinical scenario, such as receiving a discharge medication change or returning a reviewed consult note to the patient record. Then require evidence for the whole path.
- Define the care outcome. Name who needs which information, at what point, and what decision or action it supports. “FHIR enabled” is not an outcome.
- Trace data in both directions. Identify the source of truth, fields read, fields written, triggers, timestamps, provenance and any manual step. Confirm whether “integration” means a schedule feed, document export, structured write-back or a two-way workflow.
- Specify the standards precisely. Record the supported version, implementation guide, terminology release, authentication method and conformance evidence. Include an approach for future standards updates in the contract.
- Test difficult cases. Include duplicate names, changed demographics, unavailable services, partial records, corrected results, withdrawn access and failed write-back. Confirm how staff see, quarantine, reconcile and retry an error.
- Keep clinical review in the design. Define who checks imported or generated information, what is editable, what is filed, and who remains accountable for sign-off.
- Measure workflow performance. Track manual re-entry, time to access useful information, failed or mismatched transfers, corrections, duplicate work and clinician experience. Interface uptime alone can hide an unusable workflow.
The Agency’s procurement guidelines help Australian organisations put standards and conformance requirements into sourcing and contracts. Clinical, privacy, security, informatics and frontline workflow expertise should all be represented in evaluation and testing.
Interoperability for clinical AI
Clinical AI shows the difference between a feature that works and a workflow that works. An ambient AI scribe may prepare a useful draft note, yet leave clinicians to find the correct patient, copy text between windows and file it manually. Each extra handoff creates another opportunity for omission, duplication or information being saved to the wrong place.
Our clinical AI platform supports patient-context launch through SMART on FHIR or secure launch options. Depending on the clinical system and environment, approved documentation can be written back through FHIR, HL7 v2 or partner API pathways. Lyrebird also integrates with widely used Australian practice and hospital systems. Clinicians review, edit and approve draft output before it is written to the patient record. Our integration overview explains the available pathways, while the integration scorecard helps teams distinguish a basic connection from structured, two-way support.
The same assessment still applies: confirm which data enters the workflow, which fields receive approved output, how patient identity is carried, what happens when a write-back fails, and how the organisation audits use. A standards badge cannot answer those questions on its own.
Connected care is achieved at the point where trustworthy information becomes usable in a real clinical workflow. If your team is planning clinical AI across a practice, hospital or health service, we can map an integration approach around your systems and governance requirements.




