FHIR, OpenEHR and OMOP walk into a bar…

He’s back! And, once again, Adam Coombes, Product Owner – HealthStore®, takes a complex subject and distils it into something relatable whilst applying his trademark style and humour. This time, he tackles open healthcare standards – FHIR, OMOP, and OpenEHR. In this blog, Adam attempts to dispel some of the myths and confusion surrounding these standards and offers his perspective on the strengths of each as well as advice on when they should be used.

FHIR, OpenEHR and OMOP walk into a bar…

One orders a live feed of observations.
One pulls out a semantically structured discharge summary from 2007.
The other runs a cohort query across 4 million patients.

Actually, there isn’t a punchline, but it’s a familiar question (or argument 😊) if you work anywhere near health data:

“Should we be storing our patient records using FHIR, OpenEHR, or OMOP?”

The answer is: “Yes. Probably. It depends!”

In an effort to simplify things, what follows is my attempt to explore the kind of applications each model suits best, and why choosing the right one might just save you a lot of unnecessary pain (and JSON parsing!).

It’s also worth saying that other proprietary flavours are available, but I’m focusing here on open standards because, well, who wants to get tied in to any particular vendor, eh (especially when you want to migrate to a newer system that one of their competitors make)? For the record, open standard Clinical Data Repositories (CDRs) can help if you’re in that hole, but that’s another story for another day.

FHIR: the librarian for clinical data

So let’s start with FHIR. I’ve spoken before about FHIR-based CDRs being like libraries, where FHIR is the librarian. A FHIR repository can hold each piece of clinical data, whether it’s a blood pressure reading or a CT scan report, like a book on a shelf. The FHIR librarian keeps it indexed, filed, and can fetch you anything – from a word on a page to a shelf full. Built for exchange of, and real-time access to clinical data, FHIR is ideal for application integrations, APIs, and communication hubs. If your raison d’être is aggregating and enabling access to almost any clinical information, without the need to support workflows or pathways, and especially if you exist in a mixed-standards ecosystem, FHIR is your workhorse.

Let’s imagine a person who lives with type 2 diabetes, hypertension, and chronic kidney disease (CKD) who goes to their doctor complaining of shortness of breath and with symptoms of oedema. Their GP is rightly concerned and refers them into hospital. The electronic referral could include a FHIR MedicationStatement for existing prescriptions and a FHIR Condition Resource listing diabetes and CKD. Additionally, the admissions team could query local and national sources (e.g. a CDR, NHS Spine, etc.) for allergies, latest HbA1c, and recent diagnostic reports (e.g. ECGs, eGFR labs, etc.).

Here, FHIR really shows its strengths:

• Real-time access to clinical and related data
• Integration or federation between systems (GP, hospital, lab, even imaging!)
• Anything where a clinician (or clinical system) needs a fast answer.

💡Use FHIR when:

You’re building something that needs to connect to or retrieve from a multitude of different systems and show clinical data – securely, live, and on demand.

OpenEHR: the health record pedant

We all know that one person – the one who knows exactly what happened, when and why. The one who, when you ask “What… is the air-speed velocity of an unladen swallow?” replies “What do you mean? An African or European swallow?” (Forgive me for yet another Monty Python reference, this time from the feature film Monty Python and the Holy Grail. Here is a link to the scene on YouTube).

A provocative title, coupled with levity, yes. But this is certainly not a criticism. Designed for lifelong care records with strong semantic modelling and medico-legal audit trails, OpenEHR knows it all. Everything is saved. Properly. With context, structure, and an audit trail so good it could stand up in court. Each encounter or care episode is bundled into a ‘Composition’, stored inside an EHR, and versioned. You don’t just know that the patient had a blood test. You also know how, where and when it was measured (seated, supine, or standing); where that measurement is in a sequence of like measurements; whether it was pre-prandial or post (fasting or non-fasting)… and I assume you used Archetype 5.1.7.

Let’s follow our example patient from earlier as they’re admitted to hospital. The hospital uses an OpenEHR-based EPR to document the entire inpatient stay – so an OpenEHR Composition records the admission, including initial observations, admitting diagnosis, and input from nephrology and endocrinology. Another Composition captures the discharge summary, medication changes (e.g. added an ACE inhibitor), follow-up plans with cardiology, and diabetic foot clinic.

Throughout all this, templates and archetypes ensure SNOMED and LOINC-coded data is recorded.

OpenEHR delivers:

• Lifelong shared care records
• Medico-legal grade provenance from structured, longitudinal records of clinical decisions and semantic traceability
• It preserves the story and the reasoning (e.g. for decision support tools that need clinical nuance).

💡Use OpenEHR when:

You want the whole story of the patient – semantically structured, clinically meaningful, and safe enough for your governance team to sleep at night.

OMOP: the spreadsheet maestro

I once worked with an accountant who would spend whole days working on his spreadsheets. I’d be there talking about issues with deliveries, bills of materials, or purchase orders and he would sit silently entering numbers into different cells as fast as I could talk. At the end, he would simply hit ‘update’ or something and smile at me; and I would know it was time to go. This is OMOP – quiet, efficient, and slightly terrifying. It doesn’t care about your narrative – only structured facts. OMOP isn’t really trying to be a clinical record at all. It’s your mega-spreadsheet – standardised, normalised, and optimised for crunching numbers across populations.

Everything’s coded. Conditions, drugs, measurements, procedures, all tagged with SNOMED, RxNorm, LOINC etc. Perfect if your application needs to find “all hypertensive patients over 65 who were prescribed ACE inhibitors in Q1”.

Speaking of which, let’s return to our patient one last time. A few months after discharge, the patient’s hospital stay is de-identified and loaded into an OMOP model as part of an NHS regional analytics program. All conditions (heart failure, CKD, diabetes) are transformed into standard concept IDs (e.g. SNOMED, RxNorm):

• Lab values go into MEASUREMENT
• Diagnoses into CONDITION_OCCURRENCE
• Procedures like echocardiogram into PROCEDURE_OCCURRENCE etc.

Public health analysts then run a study:

“Are older diabetic patients more likely to be readmitted within 30 days after ACE inhibitor initiation?”

Our patient’s anonymized journey becomes one of thousands feeding a model that flags high-risk patients earlier next time.

OMOP enables:

• Research and real-world evidence to improve patient outcomes
• Cohort discovery tools
• AI/ML model training on population data.

💡 Use OMOP when:

You need to find a cohort of patients who meet criteria for trials, or you’re trying to analyse trends, build predictive models, or measure outcomes at scale.

So FHIR, OpenEHR or OMOP – which one should you use?

The truth? In modern platforms, we expect to see all three – each playing a role in a layered architecture:

• FHIR helps you find and communicate the facts
• OpenEHR records the facts and their meaning
• OMOP counts the facts to predict the future.

They’re not in competition – they’re playing different instruments in the same orchestra. You just need to make sure your app’s not trying to use a flute as a drumstick.

For context, my company’s Clinical Data Repository (CDR), HealthStore®, uses a FHIR repository to store meta data about imaging, documents and almost any other unstructured data, as well as fully structured data, like results. We chose that particular route because we can take data from a vast array of clinical systems. Most of them don’t support any of the three standards I’ve mentioned, but our approach allows us to standardise, re-vitalise, and communicate that clinical information, and makes it easy for us to integrate with systems that do support any of those standards as we’ve proved at HIMSS for the last two years.

I don’t proclaim to be an expert, just an interested party. If what I’ve written gets you thinking, or if you just want to point out I should have said ‘Archetype 5.1.8.3a’ earlier on, drop your thoughts or war stories in an email to: adam.coombes@bridgeheadsoftware.com or seek me out on LinkedIn here. I’d love to hear from you.

Adam Coombes is Product Owner for BridgeHead’s HealthStore® Clinical Data Repository. His goal is to enhance care delivery by enabling healthcare providers to create a safe, available, and complete clinical history for patients and make it easy to move data in and out of HealthStore, as and where needed.

 

Adam is an established Business Analyst, Product Owner, and self-confessed ‘physics geek’. For the last 15 years, he has worked with clinical and technical teams to develop solutions that improve patient outcomes.