Australia's biggest hospital networks are locked into Oracle and Epic, and hospital CIOs aren't about to hand Heidi the keys. But will Heidi's expansive shadow IT strategy eventually force the big EMRs' hand?
In general practice, Heidi II can theoretically use its AI agents to take over a clinician’s desktop, learn the interface of a practice management system in seconds, open every patient file, and extract structured data without any formal integration.
But general practice runs on relatively open, Windows-based systems with a competitive vendor market and GPs who own their own practices. The GPs can make their own calls.
Big EMR-enabled hospitals are different. A lot run on Oracle Health (formerly Cerner) and Epic – two deeply entrenched, heavily regulated, massively expensive enterprise EMR systems that can take decades to bed in.
The contracts are big, the customisation is deep, and in the public system, compliance requirements are extraordinary.
The idea of a third-party AI agent operating inside those systems – under a clinician’s credentials, indistinguishable from the clinician themselves – is the stuff of hospital CIO and CEO nightmares.
What hospitals will and won’t allow
No hospital system in Australia is going to allow Heidi to do what it has demonstrated it can do with Best Practice in general practice.
Hospital EMR systems handle some of the most sensitive data in the country and at scale. They are subject to strict access controls, audit trails and, increasingly, to conformance requirements linked to national infrastructure like the My Health Record.
Any software vendor seeking to formally integrate with these systems faces years of compliance work and regulatory review.
Oracle and Epic both operate on the assumption that they control the integration layer – that any third party accessing their systems does so through formally approved APIs, with visibility, logging, and accountability at every step.
Heidi’s formal integration strategy for hospitals is also complicated by a more fundamental problem: unlike GP software, hospital EMR systems don’t offer the kind of accessible, well-documented APIs that would make deep integration straightforward even if everyone wanted it.
The data architectures are complex, the customisation is wide, and the vendors have historically been reluctant to facilitate the kind of open interoperability that would let a competitor in through the front door.
That is, in theory, where things stand.
The shadow IT problem
The thing about Heidi’s scribe function – the thing that records, transcribes and summarises a clinical consultation – is that it doesn’t need any EMR integration at all.
The clinician runs Heidi on their phone or laptop during a consultation, Heidi does the transcription and drafts the clinical note, and the clinician then copies the relevant text into whatever EMR they’re using.
No integration. No API. No IT department involvement. No vendor awareness.
This is happening right now across a significant number of Australia’s major hospital networks. The hospital IT departments often have a good idea it’s happening and at what level. A couple we’ve talked to said the upside for their clinicians and the hospital was too big to clamp down on the problem too much.
The EMR vendors, of course, don’t like it.
Metro South Health – the large Queensland public hospital network covering the southern Brisbane metropolitan area – has gone considerably further. It has made a deliberate, network-wide decision to roll out Heidi’s scribe functionality to as many of its clinicians as possible.
This is an executive decision to use Heidi as a scribe layer across a network that runs on an enterprise EMR.
Metro South isn’t alone in considering this – other major networks are watching closely and having the same internal conversations.
The position being staked out here is that Heidi as a scribe is acceptable even in an EMR hospital environment because it sits outside the EMR. It records the consultation. It drafts the note. The clinician reviews and pastes. At no point does Heidi touch the EMR directly.
Although the EMR vendors are not thrilled about any of this, there’s not a great deal they can do about it when the scribe sits outside the system.
The compliance bind
Both Epic and Oracle Health have been working to get their own AI scribe products cleared and operational in an Australian hospital context.
That process has involved jumping through an extraordinary number of hoops – regulatory, compliance, contractual, governance – that come with being a formal part of a public hospital IT stack.
The Oracle product recently went live at its first Australian hospital site, we think on a trial basis.
Meanwhile, Heidi has been operating as a scribe at that same hospital, used by clinicians who didn’t wait for Oracle’s product, didn’t ask IT for permission, and didn’t go through any compliance process.
They downloaded an app, used it in their consultations, and got on with their day.
A senior figure at one of the major hospital EMR vendors, speaking on background, put it bluntly: their organisation is being held to a different standard.
They are subject to every compliance requirement, every governance hurdle, every piece of regulatory scrutiny that comes with being a formal participant in the system – and then they watch a competitor operate in the same environment with none of that overhead because the competitor has chosen not to formally integrate.
Local enterprise EMR leadership is genuinely concerned that the shadow IT strategy being pursued by Heidi and others might actually work – that by the time formal products are ready and cleared, the battle for clinical habit and preference may already be lost.
This is a structural problem without an easy answer. The compliance requirements exist for good reasons. Patient data at the level of detail captured in hospital EMR systems is extraordinarily sensitive.
The effect of those requirements is that the big vendors trying to do the right thing find themselves at a competitive disadvantage.
They don’t want to let third parties in for obvious commercial reasons, but while those third parties sit outside, they carry none of the massive compliance overhead of being the EMR of record.
Related
What Heidi II might change
The scribe situation, for all its competitive complexity, is still manageable from the perspective of the EMR vendors.
Heidi is outside the system. It’s a transcription, consult summary, and decision support tool – Heidi is not officially allowed to say it does decision support as the TGA will get upset with them, but we can, because it clearly does.
The clinician is still the one reading and writing within the EMR. The question of liability for what goes into the medical record remains with the clinician and the hospital.
Heidi II is a different proposition. It has agentic capability that would likely significantly improve the productivity of the clinician, the hospital, and the patient’s experience, if it were safely integrated with the EMR.
That’s going to become a real tension between the hospital C-suite and the big EMR vendors as time passes and the agentic innovation being deployed overseas becomes more and more compelling.
The RPA-style functionality that Heidi II has introduced to encourage the GP practice management vendors to co-operate can’t work in a hospital – well, it could theoretically, but it would be too slow, too compute-intensive, too costly, and too awkward from any compliance standpoint.
But the upside of connecting agentic functionality smoothly into the existing EMR is huge, and it is coming at hospital management fast.
Why has the hospital C-suite been prepared to overlook the rise of shadow IT in their organisations without intervening too much? They see the upside, and they can watch it unfold without being in the position of formal responsibility if something goes wrong. They are watching – and responsible – of course; they just can’t be officially held accountable for something they’ve never formally sanctioned.
If the C-suite has already crossed this bridge, how long are they going to wait for the EMR vendors to get their act together before they succumb to clinician pressure and formally ask their EMR to integrate with an outside AI vendor?
The strategic question for incumbents
The EMR vendors are not without options, but none of them are comfortable.
The current response is to accelerate their own AI product development while relying on governance and compliance pressure to keep agentic use cases from becoming normalised in hospital settings.
The hope is that by the time hospitals are seriously considering agent-mode AI, Oracle and Epic will have formal, compliant, integrated products that offer equivalent capability with full auditability and vendor support.
But that is not how things are panning out so far.
Heidi, and other AI vendors, free of the compliance drag of being the EMR of record, can focus and innovate considerably faster than the big EMR vendors.
NSW Health presents a particular case study in the constraints facing both sides.
The network is deeply committed to Epic – it is the largest single Epic network implementation in the world, representing an investment of such magnitude that any significant pivot away from Epic now feels unthinkable (who knows though if Labor loses the upcoming election).
Amid all this, NSW Health is understood to be appointing a panel of scribe products for its various local health districts to test and use as the Epic rollout continues across the state.
According to sources in eHealth NSW, that scribe panel has been chosen. But it hasn’t been announced yet, despite having been expected for months.
The expectation is that alongside Oracle and Epic’s own products, Heidi, Lyrebird, and possibly one or two others will be on that panel.
That would be a smart move by NSW Health – it would give them genuine leverage over their EMR vendor when it comes to pushing forward on agentic functionality in their hospitals.
For now, NSW Health clinicians are waiting for some formal way to use what many of them are already using informally.
Where this goes
The trajectory here has a certain inevitability to it.
Heidi’s scribe is already embedded at scale in Australian hospital networks – at Metro South, at other networks quietly following suit, and in the individual practices of an unknowable number of clinicians who have simply started using it.
The scribe use case is, in governance terms, manageable. It’s outside the EMR. The clinician remains accountable for what goes into the record.
The agentic use case is not yet in hospital settings in any formal sense. But the path from scribe to agent is not a long one.
A clinician who trusts Heidi with their consultations, who has been using it for months or years, who has watched it draft accurate clinical notes with minimal correction, is a clinician who is open to the idea of Heidi doing more.
The EMR vendors are not wrong to be concerned. They have to build compliant, integrated, formally approved AI products while a competitor can focus and move fast outside these constraints.
The EMR vendors are watching the clinical relationships with the outside AI vendors deepen in real time – and doing so with the knowledge that the technical case for integrating third-party agentic functionality is becoming harder to resist, especially once hospital management starts feeling the pressure from their own clinicians to do it.
For now, the firewall between the AI vendors and the EMR enterprise vendors is firmly in place.
For now …