Why EHR Interoperability is Still Failing After Twenty Years, and Why a Clinical Product Manager Can Be the One to Fix It
We have been trying to make EHRs talk to each other for two decades. The HITECH Act poured billions into digitizing records starting in 2009, on the promise that once everything was electronic, the data would flow. It didn’t. We digitized the silos instead of connecting them. Meaningful Use, the Cures Act, information blocking rules, TEFCA, FHIR: each was supposed to be the thing that finally cracked it. And here we are, still watching critical patient data remain behind the boundary between one system and the next.
That track record should tell you something. If twenty years of regulation, funding, and genuinely good technology haven’t solved it, the problem is that it wasn’t really ever purely technical. And it may not be readily solved by people who understand the technology but not the clinical workflow.
We all want it. Can anyone articulate exactly what they need?
Every health system says they want interoperability. It is in every strategy deck and every vendor demo. Connect our systems. Share our data. Make it work together.
Scratch the surface and the picture changes. Ask what data they need to receive and the room gets quiet. Ask what they need to send back out and people look at each other. Ask what clinical problem they are actually solving and you get a mission statement instead of an answer.
This is where EHR interoperability projects die, long before anyone writes code.
This is a clinical product problem, not just a product problem
The issue is that people think that once the problem is vague, you just need a good product manager to come in and define it. Bring in someone sharp, run discovery, write the requirements, ship it.
But EHR interoperability is not a generic product problem. A skilled product manager from fintech or e-commerce can run a flawless discovery process and still produce something dangerous, because the requirements in healthcare are not just business logic. They are clinical, based on clinical workflow and critical data points.
Consider what a non-clinical PM cannot see:
When you map problem list from one system to another, a generic PM treats it as a data field. A clinical PM knows that a reconciled problem list and an active diagnosis list are different things, hat the difference can drive the wrong clinical decision, and that the integration has to preserve which one it is.
When a lab result crosses systems, a generic PM moves the value. A clinical PM knows that an INR result without its reference range, critical values, and its collection time is not just incomplete, it is potentially misleading at the point of care.
When you decide which data flows into the EHR versus living in a separate platform, a generic PM optimizes for the cleanest architecture. A clinical PM knows that if the data does not land in the clinician’s actual workflow, at the moment of the decision, it will not get used, no matter how elegant the pipe is.
These are not edge cases. This is the substance of the work. The judgment about what data matters, in what form, at what moment, for what clinical decision, is the whole game. And that judgment does not come from a requirements template. It comes from having stood at the bedside, or having sat with the clinicians who do.
A problem as old as the railroad
The structural pattern is not new. In the mid-1800s, railroads were built on different track widths. Each system worked perfectly within its own territory. The breakdown came at the boundaries, where one line ended and another began. Cargo stopped. Wheels were swapped. Time and money bled out at every handoff.
Nobody had built a broken railroad. They had each built one optimized for themselves, without agreeing on how it would connect to anything else.
EHRs are the same. Epic works beautifully inside Epic. Meditech works inside Meditech. The breakdown happens at the boundary, and twenty years of effort have mostly failed to define what crossing that boundary is actually supposed to accomplish for patient care.
When the gap costs more than money
In the early days of 911, a call that crossed a county line could end up nowhere. The infrastructure existed. The intent existed. People wanted it to work. But each jurisdiction built its own system, and nobody answered the basic questions before the wires went in: what information has to move, which direction does it go, and what does success look like for the person on the other end of that call?
That is still the mistake in EHR interoperability. The technology conversation starts before the clinical problem conversation. And you cannot engineer your way out of a question you never asked, especially when the right question is a clinical one.
The questions a clinical product manager forces onto the table
Before any integration gets a green light, these have to be answered, and answered by someone who understands the medicine well enough to know when the answer is wrong.
What clinical problem are you solving? Not a goal, not a vision. A specific breakdown in care or workflow that has a name, a cost, and clinicians who feel it every day.
What data do you need, in what direction, and in what form? Receiving data from an EHR is one conversation. Sending data back in is harder, slower, and more political. Bi-directional exchange is its own category. And the form matters as much as the field: a value without its clinical context can be worse than no value at all.
Do you have the budget for what this actually takes? Not what you think it takes. Custom integration is expensive. Vendor connectors are not as turnkey as they are sold. Every EHR has its own quirks even when everyone claims to speak the same standard. Build in contingency, because something will not work the way the documentation promises.
The honest version
EHR interoperability is solvable. Some organizations do it well. But after twenty years, the pattern is clear: the ones that succeed are not the ones with the best technology or the biggest budget. They are the ones who put someone in the room who understands both the data and the clinical workflow, and who refused to let the build start until the clinical problem was actually defined.
That is the clinical product manager’s job. Not to manage the timeline. To make sure the problem is real, the data is right, the direction is set, and the clinical stakes are understood before anyone opens a single ticket.
The technology has been ready for years. What has been missing is the person who knows what to point it at.