The Data Warehouse is openEHR's Strongest Use Case Right Now
Why openEHR works better as a silver layer in your data warehouse than as a CDR, and what that means for clinical data at scale.
I’ve worked in healthcare IT for about a decade now. I think most problems that plague the field are due to: 1) inconsistent data models; 2) bad sync. If one could reliably solve both of these problems, then we might see fundamentally different kinds of technology used to solve old problems.
Healthcare is one of those fields where a simple business process spans multiple entities. If you go see your primary care provider for a headache, they might get your blood work from a lab, refer you to a specialist for further evaluation, and your payer pays all of them for their services. A seemingly simple encounter with a healthcare system could easily span 5-20 business entities.
Every one of these entities usually has at least one “system of record”. The system of record is the source of truth. It captures the process and workflows of the entity, and enables people to work on a shared truth. Other industries have it too. The most common is the CRM used by sales and customer support teams.
This is important because the system of record builds object permanence. Otherwise you risk treating each customer like they are new every time (banks have this problem). Sometimes when an entity uses multiple systems of record and they don’t really talk well to each other, you start seeing symptoms of object impermanence. Maybe they ask you for your name and insurance for the third time, if you have any allergies, or if you’ve had any procedures in the past.
This problem, when solved within a single business entity, is usually referred to as “intra-operability”, which is gluing things into a single record within a single organization. It’s usually called a “Longitudinal Health Record” or a “Shared Care Record”.
The ideal that most people strive towards in healthcare is that the longitudinal health record is also shared across different entities, across their systems of record. This is “inter-operability”.
To me, this is fundamentally a synchronization problem. You’re trying to sync data between different systems of record. When this happens within an organization, it’s called intra-operability; across business boundaries, inter-operability.
These problems shouldn’t have different solutions. But why does this not happen today?
Traditionally, most care was delivered in a single institution and a single system of record, where a single global truth was sufficient. And most of the “inter-operability” was through messaging protocols that treated data from the outside as a second-class citizen to the primary system of record. HL7v2 feeds, IHE, and C-CDA exports all create a simplified, reduced version of the actual state in the system of record to be sent to other entities, and when receiving data, they selectively accept what makes sense to their system of record and reject the rest.
Let’s formalize these problems.
1. Inconsistent data models
When two systems of record store the information in incompatible ways, the transfer of records from one entity to another will always be lossy. There is loss in both data and context when mapping data from one data model to another.
2. Bad sync
When the only allowed way to move data between two systems of record is through another intermediary messaging model like HL7v2 or IHE or C-CDA, that model itself becomes the bottleneck. Even when both of the systems of record share the same data models (e.g. same EHR version connected via a national network), the movement of information can only be as rich as the intermediary messaging model allows. Each system of record also needs to build interfaces for handling incoming and outgoing data, and most of the time, a good amount of data is lost when translating between the data model of the system of record and the messaging model.
This is like throwing around updated versions of a Word document by email, except the Word document loses 50% of its content every time. It’s the digital version of the telephone game, except people’s lives are at stake.
The exception here in healthcare seems to be DICOM and PACS. Both of them evolved to have a single way to retrieve and store data. This came about because you didn’t want to invest in a million-dollar MRI machine only for it to stop working when you change your PACS system.
DICOM has consistent data models, and a good mechanism to sync so data is not lost between systems when it’s sent across.
I think Epic (the major EMR vendor today, but hey, all systems of record tend toward monopolies, and credit where it’s due!) solves both problems well enough for the structured clinical record.
Within an Epic instance, almost all data is stored in a single global InterSystems Caché/IRIS database called Chronicles (their entire stack is still built on MUMPS, which is a programming language as well as a database). There might be multiple applications, but they all use the same data models (which, believe it or not, you can check out here), and there is no syncing problem to solve, because they are literally running on the same database instance.
One could go really far with a single Epic instance. There are sometimes dozens of different business entities that use the same Epic instance, especially when they have tight business relationships.
When you have multiple Epic instances across multiple business entities, Epic uses their own syncing protocols like Epic CareEverywhere (and now Epic Nexus) that faithfully synchronize across these different Epic instances better than is possible across other EHRs. Now they have different products for labs, payers, and more. When they extend the same data models and sync protocol to other products, suddenly you are not losing context and data as a business process spans these different entities.
This almost feels like magic because of how poorly data models and sync in general are generally handled in the industry. If someone gets it right, it becomes a business advantage for all business entities involved in the value chain to just adopt their entire software line, because “it just works”.
I’m not advocating that everyone just adopts Epic!
This could also work if organizations agreed on 1) consistent data models and 2) how to sync data. And this is possible!
1. Solving for consistent data models
Most data models in healthcare are designed by committee, for one specific exchange use case. Governments design their own special FHIR profiles, HL7v2 message profiles, or C-CDA templates. These models represent what everyone in the room agreed they could transmit, not what clinical care actually looks like.
There is one approach I find quite appealing: maximal clinical modeling with unified terminology. The openEHR CKM is probably one of the best examples here.
Human beings are mostly the same worldwide. Healthcare business processes (even the unique snowflakes) are mostly accomplishing the same outcomes. So if you capture everything possible that a clinician might care about, you end up with a “maximal clinical model”. Add a unified terminology like SNOMED CT to that, and you have a consistent global data model.
Why maximal? Because you can never predict which fields another entity will need. You can always take a subset of a maximal model later, but you can never recover a data point that was never captured.
Maximal models also remove the need for negotiation.
A minimal common model (e.g. FHIR’s 80/20) forces everyone to argue about which fields get cut, while a maximal model simply grows as new use cases show up.
But these models should also be easy to implement. I’ve written about flattening these maximal models into plain SQL tables that any developer can use in their products without too much effort. If you think different vendors adopting a common data model within their databases is crazy, you’d be right! But if we don’t, we’re just left playing the telephone game forever.
2. Solving sync
The data models for transmitting information between systems CANNOT be different from the consistent data models of representation we just talked about. As soon as we have an intermediary messaging model, we’re back to lossy translation on both ends.
“openEHR for storage and FHIR for messaging” is a compromise, not the ideal we should strive for.
Messages like HL7v2 and REST APIs like FHIR still represent snapshots of the data in one system of record. Moving this to another system still loses context of the exact order of changes that led to a particular state.
This is still like throwing a Word doc back and forth over email. What we really need is something different. Like Google Docs, built from the ground up for collaborative editing.
So what does good sync look like?
The fundamental building blocks of these kinds of applications are called CRDTs, and they have interesting properties. Each system of record can emit a stream of deltas as changes to the database take place. These deltas can be merged in any order and still converge to the same state.
How sync happens has been solved in databases using streaming replication protocols. But the problem we’re really dealing with is distributed syncing, or being able to merge the state across different systems once all the deltas arrive.
We’ve dealt with this ourselves, especially when we had to build the openEHR CDR syncing service for 8M people in Catalonia.
Today, mature implementations like Automerge exist. This wasn’t the case a few years ago.
Different business entities can choose to auto-accept deltas from trusted peers, hold patient-contributed data for review, and reject what doesn’t meet their policies.
You can also transmit a redacted version or limited set of data through these deltas. These deltas could also be transmitted by any means: you should be able to sync over the internet, on a pen drive, over the BitTorrent network, or through decentralized protocols like IPFS or iroh.
There are a lot of properties worth borrowing from the local-first software essay by Ink & Switch.
This, to me, should be the fundamental building block of moving data around. Sync, not messaging or REST.
We have the technology for all this to work. We are just so thinly spread out in healthcare that we spend most of our time solving the problems of the previous decade, and it’s hard to invest time and energy in what should be.
I don’t have all the answers, but once in a while, it’s nice to wonder what the next generation of healthcare interoperability might look like.
Related articles
View all
I Built Something A Few Weeks Ago
My mother-in-law needed a clinical trial. My wife and I, both doctors, had a hard time finding the right one. I decided to try to solve it.
Can openEHR just be SQL tables?
I make the case that SQL could be the solution to simplifying the layers of complexity in health data architecture. This is a written version of my talk at EHRCON 25.
