Why Australian health systems still do not talk to each other

Ask a patient what interoperability means and you will not hear "FHIR R4". You will hear that the specialist already has the letter, except they do not. That the hospital can see the GP notes, except they cannot. That last month's imaging is on a disc in the glovebox because that was the only export the radiology software offered.

Australia is not short of national digital-health infrastructure. It has a Healthcare Identifiers Service, a My Health Record, a terminology stack, and years of agency strategy documents. It also has vendor contracts, local workarounds, and a daily clinical habit of asking the same allergy question again because trusting the last screen has bitten people before.

This is a report on why the pipes still leak. It is not a buyer's guide to any clinical information system, and it is not a claim that one more standard will finish the job.

The patient's version: the computer is down

"The computer is down" is a phrase that covers at least four different failures.

The practice software is actually offline. The internet link to a cloud product is up, but the login service is not. The software is fine, and the secure message from the emergency department sat in a queue no one is watching. Or the record is open, the patient is in front of you, and the relevant note lives in a different product that this screen has never met.

From the waiting room those are the same event. The appointment runs late. The history is taken again. A medicine is prescribed without the hospital discharge that would have changed the choice.

Clinicians add their own dialect. They talk about interfaces, outages, and "it did not come through". Patients experience a system that asked them to go digital and then lost the file.

The honest technical translation is that most Australian clinical software was built as a practice or hospital product, not as a node on a network. Connecting those products is extra work. Extra work loses to billing, rostering, and the inbox.

The Healthcare Identifiers Service, without the brochure

The Healthcare Identifiers Service is one of the less glamorous national pieces, and one of the more necessary. It issues and maintains identifiers so that software can talk about the same person, the same clinician, and the same organisation.

Three numbers, three jobs

• An Individual Healthcare Identifier (IHI) is for the person receiving care.
• A Healthcare Provider Identifier–Individual (HPI-I) is for the clinician.
• A Healthcare Provider Identifier–Organisation (HPI-O) is for the service.

The point is matching. If two systems use different local patient numbers, they need a shared way to decide that Jane A. Smith born on this date is not Jane Smith born on that date. The IHI is that shared way, usually looked up against Medicare or DVA details rather than recited by the patient.

When the match fails, you get duplicates. When the match is too eager, you get a merge. Both errors are dangerous. Both are common enough that experienced reception staff treat identity as a clinical act.

The HI Service does not move notes. It does not decide who is allowed to see a diagnosis. It does not make a GP product open a hospital product. It only reduces the odds that a perfect interface still attaches the letter to the wrong person.

If your name, date of birth or Medicare number is messy — a recent marriage, a transliteration, a newborn not yet enrolled — the identifier layer will be messy too. That is not a reason to avoid the service. It is a reason to treat registration as more than admin.

FHIR in plain English

FHIR, pronounced "fire", is a family of specifications from HL7. The current pitch is that health software should exchange information the way modern web software does: structured resources, predictable queries, less custom glue.

In plain English, FHIR is a shared filling system. A patient, an allergy, a prescription, an appointment and a lab result each have an expected shape. If two products both speak FHIR, one can ask the other for "the allergy list for this IHI" without inventing a private format.

That is the upside. The limits are easier to miss in a slide deck.

What FHIR does not do

FHIR does not force a vendor to expose anything. A system can be "FHIR capable" and still hide the useful resources behind a paid module, a closed partner program, or a local decision not to turn the endpoint on.

FHIR does not standardise meaning by itself. Two products can both send a "condition" and mean different things by the onset date. Australia still needs national profiles — agreed subsets and terminology bindings — or the payload is only cosmetically common. The Australian Digital Health Agency and the wider standards community have been working on those profiles. Working on them is not the same as every general practice being able to use them on a Tuesday.

FHIR does not replace workflow. A perfect allergy resource is useless if nobody looks at it, or if the receiving software dumps it into an unreviewed inbox.

Think of FHIR as a grammar. Grammar does not write the letter, post the letter, or make the specialist read the letter.

A national standard is not a national conversation. Two systems can both "do FHIR" and still have nothing to say to each other that a clinician would trust.

Vendor lock-in is not a conspiracy theory

Australian general practice is concentrated in a small number of clinical information systems. Hospitals run a different, also concentrated, set. Aged care, allied health, ambulance and community services add more. Each product is a business. Each interface is a negotiation.

Lock-in shows up as export fees, as "preferred" messaging networks, as imaging that will only open in the vendor's viewer, and as contracts that make a practice pause before switching. It also shows up as staff skill. A nurse who can fly through one inbox is not interchangeable with a new product on a Monday morning.

None of that requires malice. It is what a market looks like when the buyer is a busy practice and the switching cost includes data migration, printer chaos, and a week of slower consults.

Policy can lean on this. Procurement can demand open interfaces. The Agency can publish conformance. None of those tools abolish the incentive to keep the valuable data close. If you want a sceptical test of a vendor's interoperability claim, ask for the list of resources a third party can actually pull today, for a practice of your size, without a custom statement of work.

The same scepticism belongs in conversations about electronic referrals and secure messaging. A referral that leaves one clinical system as a PDF attachment is better than a fax. It is not a structured handover. It is a digital printout with a nicer audit trail.

My Health Record as a lowest common denominator

My Health Record is the national summary the public is told to use when the local systems do not talk. That is a reasonable emergency use. It is a poor substitute for interoperability.

What usually lands in the record is a slice: some medicines, some documents a clinician or the patient uploaded, some pathology and imaging if the labs are connected, an event summary if someone made time. What does not land is the working GP record. The long problem list with the half-finished thoughts. The social context. The letter that is still a draft.

Clinicians know this, which is why many still do not rely on it for decisions that matter. Patients often do not know this, which is why they are baffled when a hospital says it cannot see "all my files".

Used well, the national record reduces some repeated collection. Used as the main integration strategy, it teaches vendors they can remain islands and still tick a national box. A lowest common denominator is useful when the alternative is nothing. It is a problem when it becomes the ambition.

Access control is a separate issue, covered in our privacy reporting. Interoperability people sometimes skip it. They should not. A pipe that can move a mental-health letter to the wrong endpoint is not a technical success.

What would actually move the needle

There is a serious, unromantic list. It does not fit on a conference badge.

Make identifiers boring and correct. Fund the reception time that takes. Publish which products can send and receive which FHIR resources in production, not in a pilot. Treat secure messaging inboxes as clinical work, with names on the roster. Stop calling a PDF an interface. Put interface obligations in the contracts that PHNs, states and private hospital groups already sign. Measure failed matches and unreviewed messages the way we measure waiting times.

Patients can do less than the brochures imply, but not nothing. Keep a current medicines list. Ask, when a test is ordered, how the result will get to the usual GP. Decline the disc if a proper electronic send is on offer. If a hospital discharge says the GP has been sent a summary, ring if it has not arrived in a few days. That is not the patient's job in an ideal system. It is self-defence in this one.

For clinicians and managers, the practice and systems hub is where we keep the rest of this argument: referrals, agency machinery, records, and the gap between a strategy PDF and a Monday morning outage.

A standard will not apologise for you

When the screen is blank, nobody wants a lecture on HL7. They want the letter, the allergy, the last eGFR. FHIR and the HI Service are how software engineers try to make that less random. They are worth supporting. They are not worth mythologising.

Australia does not have a single health computer that goes down. It has hundreds of products that were never really introduced to each other, a national summary that holds a polite subset, and a workforce that has learned to ask the patient again.

Until the interfaces are ordinary, "the computer is down" will remain the most accurate piece of consumer health technology we have.