Health-Tech
EHR Interoperability Explained
By Miracle Olajuyigbe 8 min read
A woman arrives at an emergency department at eight in the evening with abdominal pain. She had a CT scan eleven days ago at a hospital across the city. She knows this. She says so twice.
The department cannot see the images or the report. There is a portal, in theory, but nobody on the night shift has a login, and the other hospital’s records office rings out because it is eight in the evening.
So the registrar orders another CT. A second dose of radiation, a four-hour delay, a scanner slot another patient needed, and a bill somebody pays.
Meanwhile her medication list is being rebuilt from memory. She names four drugs, forgets the fifth, and is unsure about the dose of the third. Her antibiotic allergy is written down, accurately and in detail, in a computer twelve kilometres away.
That is what “data silos” means. Not an architectural abstraction. A repeated scan, a half-remembered drug list, and a doctor deciding with an incomplete picture while the complete one sits an hour’s drive away.
Interoperability is the work of stopping that. FHIR is the best mechanism anyone has built for it so far. Here is what it fixes, and what it very much does not.
Three levels, and only one of them is hard
The textbook definition is “the ability of systems to exchange and use information.” All the difficulty lives in the second half.
Level one: the data moves. One system sends, another receives. A PDF arriving by secure email clears this bar.
Level two: the data arrives in a shape that can be read. The receiving system can parse it and file each piece correctly. This is a diagnosis, that is a medication, this one is a blood pressure.
Level three: the data means the same thing at both ends. Not just “this field holds a lab result,” but “this is a kidney function result, comparable to the one from March, and it should trigger the dose-adjustment rule.”
Most integration projects clear level one, mostly manage level two, and stall at level three. When a vendor says their product is interoperable, the only question worth asking is which level they mean.
How the pieces fit together
The health record system stores everything in its own internal filing structure, which is proprietary and built for the vendor’s own software rather than for outsiders. You do not get to reach into the database directly, and you should not want to.
An API is the controlled door into it. Think of it as a service window: it defines what an outside application is allowed to ask for, how it proves who it is, and what comes back. Without one, integration means screen-scraping, direct database access, or overnight file dumps, all fragile and two of which will fail a security review.
HL7 version 2 has quietly carried most clinical data movement since the late 1980s and still does. It is a message format. An admission fires off one type of message, a lab result another, and a routing engine passes them between systems.
It works, and it is thoroughly proven. It has two limitations. Messages get pushed at you when events happen, so a system receives what it is sent but cannot ask a question on demand. And the standard is loose enough that everybody implemented it slightly differently, which is why integration engineers joke that if you have seen one HL7 interface, you have seen exactly one HL7 interface. Every connection is bespoke work.
CDA was the attempted fix, built around structured documents. Genuinely useful for sending a summary of care. But it is document-shaped, so you receive the whole discharge summary and go hunting inside it for the one result you wanted.
FHIR made a different choice, and it is the choice that matters.
Instead of moving documents, FHIR breaks clinical information into small standard pieces called resources. There is a standard shape for a patient, another for a single lab result, another for a prescription, an allergy, a diagnosis, an appointment. Each piece can be requested on its own, and pieces reference each other, so a result knows which patient and which visit it belongs to.
Think of them as Lego bricks. Every system speaking FHIR builds from the same bricks with the studs in the same places, so a piece produced by one hospital clicks straight into software written by someone who has never met them.
And retrieving data looks like an ordinary web request. Ask for a patient and you get that patient. Ask for their kidney function results since January and you get exactly those, in the same everyday data format that powers most modern apps.
That accessibility is not cosmetic. It changed who can build healthcare software. The old standards needed specialists who had spent years learning healthcare’s private dialect. FHIR needs a competent web developer and a good implementation guide.
Why it took hold now
People have been attempting this since the 1980s, so the fair question is why this attempt stuck.
A stable target. Release 4, published in 2019, was the first version where core parts came with a commitment not to break them later. Before that, building on FHIR meant building on shifting ground, and companies do not invest in shifting ground.
Regulation stopped making it optional. In the United States, the 21st Century Cures Act and the rules implementing it require certified record systems to offer standardised access to a defined set of data, and deliberately obstructing the flow of patient information now carries penalties. That turned FHIR support from a selling point into a compliance requirement, which is a much more dependable way to make an industry move.
Apps became portable. A companion standard called SMART on FHIR defines how an outside application logs in, gets permission for specific data only, and opens inside the record system with the right patient already loaded. Add CDS Hooks, which lets an outside service offer a suggestion at a precise moment such as when a doctor opens an order screen, and one application can be written once and sold into many different hospitals. Before that, every sale meant a fresh integration project.
There is also bulk export, for when you need thousands of patients at once for analytics or research rather than one at a time. If you are building anything that works on populations, read that part first.
What to actually ask a vendor
“Are you FHIR-compliant?” is close to meaningless. Everyone says yes. Ask these instead.
Which version, and profiled against which implementation guide? Base FHIR is a framework with enormous optionality. The implementation guide is what makes two systems genuinely agree.
Which resources, and can we write as well as read? This is where answers get evasive, and it is the most revealing question here. Reading data is broadly available and fairly mature. Writing data back into the record is narrower, more restricted, and sometimes unavailable for exactly the thing you need. If your product depends on pushing an assessment or an order back, establish that on day one, not in month five.
What is not covered, and what happens then? Which workflows fall back to older messaging, to documents, or to somebody retyping. There will be some. A vendor claiming otherwise has not checked.
Which coding systems, and who does the mapping? FHIR carries codes; it does not standardise them for you. Ask whether results come back with standard international codes or the hospital’s own internal ones, and who is responsible for translating the rest.
This is where level-three interoperability quietly dies. A perfectly formed FHIR result containing a hospital’s private lab code is beautifully structured and completely useless to you.
Can we test before signing? Sandbox access, and ideally a trial against a de-identified extract of real records. Vendor sandboxes are clean. Production data is not, and the gap between them is where project timelines die.
What are the rate limits? Requests per second, concurrent connections, real bulk export throughput. Software that must load a patient summary in two seconds depends entirely on this.
What does the connection cost? Per-interface fees, marketplace listing fees, annual maintenance, per-transaction charges, and whether any of it scales with volume. These are negotiable more often than buyers assume.
How is patient matching handled? Without a national patient number, matching records across organisations means probabilistic guessing from names, birthdates, and addresses. Ask about the false-match rate and what happens when a match is uncertain. This problem is bigger than most technical evaluations allow for.
Asking these does more than assess capability. It signals that you know where the difficulty actually sits, which reliably improves the conversation.
What FHIR does not fix
Agreeing on the container is not agreeing on the contents. Two hospitals can both be fully conformant and still disagree about what counts as an active problem, when a visit ends, or which internal code maps to which standard concept. The envelope is standardised. What goes inside it is a local habit.
Extensions fragment things. FHIR allows extensions so real requirements the standard missed can still be met. Necessary, and also an escape hatch. Heavy use of custom extensions recreates the old bespoke-integration problem inside a modern standard.
Incentives often point the other way. For a vendor with a dominant position, making data easy to move lowers the cost of leaving, and lowering your customers’ cost of leaving is not a natural commercial instinct. Regulation has pushed back and moved things measurably. It has not made the tension vanish.
Consent and governance are unsettled. Who may see what, for what purpose, with whose permission, and how that permission travels between organisations. FHIR provides ways to record those decisions. Whether a group of organisations agrees on a shared policy and honours it is a legal question, and it is the one that most often stalls a technical connection that already works.
And none of it helps where the record is on paper. Much of the world runs on paper or on systems with no external access at all. The meaningful question there is not which version to adopt. It is whether the referral letter arrives.
Where this leaves you
If you are building software that touches clinical data, FHIR is the right foundation. That is no longer a close call. The tooling is decent, the standard is stable, regulation is behind it, and the alternative is a custom integration for every customer.
Just be clear about what you are buying. FHIR gets data out of one system and into yours in a shape you can read. It does not guarantee the data means the same thing at both ends, that you can write anything back, or that the organisation on the other side wants the exchange to happen at all.
The scan repeated at eight in the evening is rarely blocked by a missing standard. It is blocked by a login nobody has, a policy nobody wrote, and an arrangement where no one at either hospital is measurably worse off when the transfer fails.
Solve the technical layer. Then go and look at the other three, because that is where the second CT actually came from.