Is openEHR the Linux of clinical data standards?

openEHR is technically superior to FHIR as a clinical data model but the market doesn’t seem to care.

This article is not a comparison of the two standards. It’s an examination of why openEHR is not dominant. People who have worked seriously with both standards know what openEHR does better than FHIR. That argument has been won, but winning hasn’t driven adoption in any meaningful way.

What follows is an attempt to explain why.

The Linux parallel

Linux never won the desktop battle. Despite being superior to Windows in many respects, that superiority was not significant enough for ordinary users to warrant a move from Windows or Mac, and the commercial ecosystem did not step up to make it simpler. But it won on servers, in the cloud and on mobile.

openEHR may be the Linux of clinical data standards.

The people who understand it deeply are convinced, but the market hasn’t followed. Better documentation, more archetypes or another well-attended conference won’t fix that.

Where openEHR has won

Adoption is real. Norway, Slovenia, Catalonia, Ireland (I have reservations here, but that’s another article) and pockets of Australia. These are not trivial implementations.

But the pattern is consistent. Small countries or regions with nationalized health systems, strong central coordination and a willingness to take clinical informatics seriously.

These are preconditions, not coincidental characteristics. Remove central coordination and the implementation deteriorates. Remove the political will to fund clinical informatics long-term and the standard cannot be implemented correctly. Remove the nationalized system and the commercial incentives are not there.

The wins are real but the conditions that produced them are narrow.

Where openEHR has not won

Epic, Oracle and Meditech have not moved to openEHR and there is no indication that it’s even on their roadmap (insiders can correct me if I’m wrong here). They have no visible incentive to do so and the regulatory environment in their largest markets has not created one.

InterSystems, Microsoft and Google are heavily invested in FHIR. That investment increases each year with new products, open source projects and active participation in the FHIR ecosystem. Has anyone seen Microsoft or Google at an openEHR conference?

The US market sets the direction for global health IT investment. It settled on FHIR due to regulation and stayed there. openEHR is rarely mentioned. This means the largest source of commercial health IT investment in the world is now committed to a different standard.

The skills gap

openEHR requires clinical informatics expertise that does not correspond to any standard career path. You cannot post a job description and fill these roles easily.

FHIR skills are already scarce. openEHR skills are scarcer still and harder to develop. The standard requires people who can combine clinical knowledge and technical implementation at a level that takes years to develop. Because adoption has been concentrated in national systems, the private sector never developed these skills in significant numbers. The talent pool has stayed small as a result.

Projects that proceed without that expertise implement openEHR badly. They lose the clinical benefits that justified choosing it, while paying the full cost in complexity, timeline and maintenance. This is not an argument against openEHR as a standard. It’s an argument about the gap between what the standard demands and what most project teams can realistically deliver.

The commercial vacuum

Better (better.care) is a credible vendor with a genuine national-scale track record. It’s also a company of around 200 people. There are other players and an open source project, but none with Better’s implementation history.

None of the dominant global EHR vendors or cloud providers have adopted openEHR in a significant way. The commercial ecosystem that would point to mainstream adoption does not exist.

Compare this to the FHIR ecosystem. Multiple enterprise server vendors, three major cloud platforms with managed FHIR servers, a strong open-source server landscape, SDK support across every major programming language and a developer community that is now large enough to support almost weekly connectathons around the world.

Technical merit alone will not close that gap.

What the working groups are telling us

Over the past year, formal working groups have gotten together specifically to address the gap between FHIR and openEHR. There was a multi-day event held in Dublin earlier this year that brought HL7 and openEHR leadership together.

This is significant. It’s evidence that the problem is being acknowledged at the highest levels. But it also points to a market that has not delivered those solutions on its own.

For a long time the openEHR position, stated or unstated, was that technical superiority would eventually drive adoption. But openEHR is over 25 years old and that position is harder to hold onto than it once was. The Dublin meeting signals something more pragmatic – an acknowledgement that the path forward runs alongside FHIR and not around it.

The Red Hat problem

The only credible path that I can see to broader openEHR adoption is a vendor abstracting away the complexity, and in doing so reducing the skills barrier so that ordinary project teams can implement openEHR successfully without a dedicated clinical informatics team.

But that tooling would almost certainly be proprietary. Any adopting business or organization would have to learn the vendor’s platform, which would lead to lock-in. The standard would be open in principle but one vendor would own the only viable implementation path in practice.

Red Hat solved this problem for Linux. The model worked because enterprise Linux adoption was large enough to support a substantial commercial business and because IBM eventually gambled on it with a $34 billion acquisition.

openEHR does not have an equivalent resolution in sight. The market is smaller, the commercial returns are harder to project and there is no acquirer of that scale waiting to step in. The Red Hat parallel is interesting because the ending is different.

My conclusion

openEHR will continue to serve the market it already excels in. Small, nationally coordinated health systems where genuine clinical informatics skills already exist. I don’t see it winning more mainstream adoption or being adopted in a meaningful way by private business. I don’t see large vendors building products to compete with Better.

For most organizations, FHIR is good enough.

“Good enough” includes major commercial backing and investment, regulatory mandates and a growing developer ecosystem. That’s hard to beat, despite openEHR’s technical advantages.

A caveat

The one variable worth watching is AI. If AI tooling genuinely lowers the barrier to openEHR implementation by turning clinical knowledge into working archetypes and writing AQL, then the skills problem becomes less significant. That could change the outcome.

But it would need to happen quickly, and the tooling would need to be genuinely open rather than locked to a single vendor. Otherwise it accelerates the Red Hat problem rather than solving it. That outcome is possible but it’s not imminent.

---

Download my “FHIR Architecture Decisions” book

Discover more from Darren Devitt

Subscribe now to keep reading and get access to the full archive.

Continue reading