A world where the best of AI meets a struggling but well-meaning government sharing by default and myHR program in the middle and healthcare gets better.
I’ve spent a lot of column inches this year arguing that Australia’s Sharing by Default program is now potentially being built for a world that no longer exists.
After all, it’s a centralised government with My Health Record-first architecture, designed before agentic AI made “log into a portal and read a static upload” look a little like a fax machine does today.
But people like me love to fantasise about stuff we have no real idea about, and write it out like it’s something easy and nearby. But the alternative idea of a native AI system that just somehow expands like brain cells in a growing embryo to become something revolutionary is probably a good deal more far-fetched at this point in time than the working interoperability architecture of the government’s Sharing by Default plan, if you stop to think about it even a little.
Can anyone put enough flesh on the idea of de novo plus market forces native AI network for anyone to seriously give away any of our current quite comprehensive, but olden-day planning?
McKinsey are the idiots who first proposed a native AI health network, not me
In November 2025, McKinsey’s healthcare practice published “The coming evolution of healthcare AI toward a modular architecture” in which they described how healthcare has been flooded with narrow “point solutions” (ambient scribes, single-task AI tools), and how via agentic AI these points will eventually consolidate toward a modular, agentic “mesh” of interoperable tools and data sources.
Voila, you don’t need the My Health Record or Sharing by Default!
The paper says: “AI solutions with proven traction, frictionless workflows, agile development cycles, and clear differentiation from EHR-native tools have the potential to withstand the pressure” of consolidation, meaning agile, well-built, genuinely interoperable products will evolve and connect, while the clunky, legacy, siloed ones won’t.
There are competing open protocols emerging specifically to make the idea of an agentic interoperability mesh actually work.
These include Google’s Agent-to-Agent (A2A) protocol, backed by more than 50 technology and consulting partners including Salesforce, ServiceNow, Deloitte and McKinsey itself, standardises how independent AI agents from different vendors discover and coordinate with each other.
Anthropic’s Model Context Protocol (MCP) does the complementary job of standardising how an AI system connects to external tools and data sources, turning what used to be a custom-integration nightmare into something closer to plug-and-play.
If you combined all this with the FHIR/HL7 standards Australia is already committed to, would that be some sort of path to a distributed interoperable AI native network?
McKinsey gets things wrong a lot, and so do I
That’s all pretty theoretical. And McKinsey, like most consultants, has a lot of technology forecast clangers in its cupboard.
In 2017 the company predicted that AI would create more jobs than it destroys, then in 2018, the same team predicted 15% of the global workforce would lose their jobs to automation by 2030, alongside a wildly precise-sounding claim that 555 to 890 million new jobs would be created.
A possible native cloud AI network path example in Australia?
Consultmed is an Australian cloud-based, FHIR-enabled digital referral and Advice & Guidance platform in which GPs send referrals, specialists respond, everything runs through REST APIs and HL7 FHIR rather than fax machines.
It launched at Sydney Children’s Hospitals Network in 2023, and within three months had rolled out across 50+ hospital departments. After much hard work on the part of the founders trudging from hospital network to hospital network (everything is siloed in hospitals here), the product now supports more than 45,000 health professionals and runs across 15+ major public and private health networks, including South Western Sydney LHD, Alfred Health and Amplar Health.
It’s integrated to Medical Director, MediRecords and Best Practice, so it’s theoretically connected all these GPs to all those hospitals, the specialists in between, and back.
It’s getting the feel of its own network effect. Each new hospital network that joins makes it more logical for the next one to join too, because the GPs and specialists on the other end are already using it.
Nobody centrally planned this. The tech was there and the vendor is filling a genuine need.
Now maybe extend this sort of logic outward.
On the EMR front, Australia has a small but real bench of cloud-native, FHIR-capable platforms that could plausibly knit together the same way, including MediRecords (cloud-native, multi-site, already running Queensland Health and ADF deployments), Gentu (Magentus’s cloud practice management product, sitting alongside its legacy desktop product Genie), Cliniko and Halaxy (cloud-native allied health platforms with growing GP capability), Coreplus (allied health/integrated GP), and the cloud-enabled layers of the big hospital EMRs – Epic and Oracle Health.
Do providers or vendors need to wait here for a centralised government infrastructure and some legislation to catch things up?
In part, the answer is maybe.
The case for continuing the MyHR build
1. It’s a backup. Whatever else you think of it, a centrally held, legislatively protected national record is a genuine fallback if a distributed network has gaps, outages, or a vendor goes under or goes bad. It’s some government control and involvement.
2. It’s already half-built. The idea is still okay, albeit a bit outdated now by AI, but no one yet knows how much. And abandoning sunk infrastructure has its own cost.
3. Critically, several pieces of the MyHR build and its associated privacy legislation are almost certainly load-bearing infrastructure for a native AI network too.
The Provider Directory – and the governance of how it’s kept current – is likely a very helpful lookup any distributed agentic network could piggyback on, MyHR-centric or not.
Sparked’s FHIR accelerator work and Australia’s SNOMED CT-AU terminology binding are standards work that any interoperable system, native or MyHR-routed, will sensibly lean on.
And most importantly individual Healthcare Identifiers (IHIs) are a baseline identity, privacy and governance data set that any good interoperable healthcare system, regardless of architecture or technology, needs.
Every architecture – MyHR-first or fully distributed – needs a reliable way to know that “this patient” in System A is the same person as “this patient” in System B. Same for providers. It’s not a MyHR-specific problem to solve; it’s a foundational one, and Australia already has the infrastructure and legislative basis (the Healthcare Identifiers Act, now updated via the November 2025 Regulatory Reform Omnibus Act) built for it.
Related
The question of conformance as a forcing function
The ADHA is now setting hard timelines – final My Health Record FHIR conformance profiles published by mid-2027, no new conformance assessments against the old CDA (Clinical Document Architecture) standard from mid-2028, no new CDA-based connections at all from the end of 2028, and full retirement of CDA connections by mid-2029.
The ADHA’s Peter O’Halloran put it bluntly:
“Health services and individual clinicians will not be able to be paid if they can’t share data with My Health Record in a manner that is conformant.”
If that hasn’t scared a lot of our vendors into going a lot faster in getting prepared for what the DoHDA and the ADHA are requiring soon, nothing probably will.
Medicines data is next in line – online prescribing services are expected to be sharing by default from 2027, backed by $47.5 million in the 2026-27 Budget.
That’s a brutal deadline for a lot of vendors. Moving from CDA (essentially structured documents) to FHIR (atomic, queryable, real-time-capable data) is a fundamental architecture change, not a patch.
Here’s a consultant-esque forecast for you. More than half of Australia’s clinical software vendors will not survive this transition.
The ones running on legacy desktop architectures with thin capital reserves simply won’t have the engineering runway to rebuild in time or the money.
So far the government is taking the position of “no money” to help at all in this transition, a very different stance to that taken in the US at this point of changeover.
Some vendors are obviously better prepared and cash ready than others.
So, why not both the native AI network and the centralised Sharing by Default?
The ADHA’s own stated endpoint isn’t actually “everything routes through MyHR forever”.
The logic they’re running is that forcing every vendor through a single, brutal, FHIR-based conformance bar now means that once every major system is conformant, those systems will be able to share data directly, point-to-point, with each other and with patients.
So, not necessarily via MyHR as the permanent middleman.
MyHR conformance is being used as the forcing mechanism to drag the entire vendor ecosystem onto a common standard, after which point-to-point native sharing becomes possible precisely because everyone was made to speak the same language first.
That’s not incompatible with the “native AI mesh” and Consultmed network effect scenario.
A sleeper: some vendors are betting MyHR becomes a default EMR
Some newer cloud AI vendors appear to be positioning themselves on the idea that My Health Record itself becomes something close to a default, minimum-viable EMR – good enough that they can use it as their backend (as we’ve covered with MBSPro’s patient app) and use that as a wedge into EMR incumbent markets they currently can’t crack.
MBSPro is the clearest example. A company like Heidi, which currently can’t get meaningful traction in general practice because of Best Practice and Lyrebird’s incumbent stranglehold on that market, could plausibly follow the same playbook down the track.
What fades away in either version of this future
What happens to HealthLink (secure messaging), HotDoc and HealthEngine (patient-facing booking and directory layers) in a world where either a native FHIR mesh or a fully conformant MyHR lets systems and patients connect directly via a government-maintained provider directory of all things?
Its core value today is being the connective tissue between otherwise-incompatible systems and patients.
If interoperability becomes a solved, standards-based problem – via either path or both – that specific “we’re the bridge” value proposition gets structurally weaker.
Not necessarily fatal; being the trusted consumer-facing brand patients already use to book appointments is a real moat on its own. But the secure-messaging and directory function specifically looks like exactly the kind of layer a properly interoperable system, native or MyHR-routed, is designed to make redundant.
Can the ADHA deliver?
Something I’ve not contemplated in this story until now is that the ADHA’s and DoHDA’s conformance push is dragging the vendor ecosystem toward the technical substrate (FHIR, standardised identifiers, a maintained provider directory) that a native, distributed AI mesh would need anyway.
Using MyHR mandates as the whip rather than the destination.
Consultmed shows the organic, bottom-up version of network formation is real and already working without anyone mandating it.
It’s entirely feasible that Australia ends up with both. That’s if the ADHA and DoHDA can work out how to better execute. There is a lot to actually build still and none of it is easy.
The hardest point of possible failure? Probably the centralised live updating centralised provider directory.
On this point there are vendors the ADHA could be working with on the problem other than just HealthDirect – HotDoc, HealthEngine and HealthLink have a big stake in the game and lots of existing brand, traction and use with both providers and patients.
What could happen? A MyHR persisting as a centralised system backup data alongside a distributed, agentic, point-to-point network layer built on user intent and need.
And a pretty brutal software vendor cull.