A founder I spoke to had done what most technically-minded founders do: he’d researched the integration landscape before building. He knew the major EHR platforms supported FHIR. He’d read the documentation, looked at the API endpoints, and concluded that connecting his product to hospital data would be reasonably straightforward. He put a six-week integration timeline in his roadmap and moved on to other problems.
Eight months later, the integration still wasn’t in production.
Not because his team was incompetent. Not because the EHR vendor was uncooperative in any obvious way. But because “FHIR-compliant” turned out to mean something much narrower than he had assumed. The data he needed wasn’t available through the standard endpoints. Some fields were mapped differently than the spec suggested. Certain clinical data types required proprietary extensions that needed a separate credentialing process to access. And the sandbox environment he’d tested against behaved differently from the production environment at the actual health system.
He had built his roadmap around a standard. What he actually encountered was an implementation of that standard, shaped by a vendor with its own architecture, its own commercial interests, and its own definition of how much openness was enough.
That gap, between what a standard promises and what an implementation delivers, is where most healthcare integration projects lose months they didn’t budget for.
Start Here: What HL7 and FHIR Actually Are
Before getting into why implementations fall short, it helps to be clear on what these standards actually do, because “HL7” and “FHIR” get used interchangeably in a lot of conversations where they shouldn’t be.
Think of healthcare data like a letter. HL7 is the agreed-upon format for writing that letter: what goes in the envelope, how the sections are labeled, what order information appears in. It has been around since the late 1980s and exists in several versions, the most widely deployed being HL7 v2, which you will still find running in the background of nearly every hospital system in the US today. It is not elegant. It is not modern. But it works, and it is everywhere.
FHIR, which stands for Fast Healthcare Interoperability Resources, is something different. It is not just a message format. It is an interoperability framework built for the web, using the same conventions that power modern APIs: REST, JSON, OAuth. Where HL7 v2 was designed to move data between systems inside a hospital, FHIR was designed to make healthcare data accessible to external applications over the internet, the way you’d pull data from any modern platform.
The practical difference matters. HL7 v2 messages get exchanged through point-to-point interfaces that someone has to configure, maintain, and troubleshoot on both ends. FHIR APIs, in theory, let a developer query patient data the same way they’d query a weather API or a mapping service. That’s the promise. That’s what made founders like the one in the opening story reasonably optimistic.
The problem is what sits between the standard and the implementation.
Why the Gap Exists: EHR Vendors Built Their Own World First
The major EHR platforms were not built around FHIR. They were built, in most cases, over decades, around proprietary data models, proprietary workflows, and proprietary interfaces that predate modern interoperability thinking by a generation.
When FHIR arrived and regulators began mandating its adoption, these vendors didn’t rebuild from scratch. They layered FHIR on top of what already existed. Which means the FHIR API you’re connecting to is often a translation layer sitting in front of a much more complex internal structure that was never designed to be openly queried.
Here is where it gets practically important for anyone building on top of these systems.
FHIR defines a set of resources: Patient, Encounter, Observation, Medication, Condition, and so on. Each resource has a defined structure. But the standard also allows for extensions, additional fields that a vendor or organization can add to capture data that the base spec doesn’t cover. This is a reasonable design choice. Healthcare is complex and no standard can anticipate every clinical data type.
The problem is that major EHR vendors have used this extensibility extensively. The result is a version of FHIR that is technically compliant with the standard but practically requires vendor-specific knowledge to work with. You can connect to the API. But reading the data meaningfully, mapping it correctly, and handling the edge cases requires understanding not just FHIR but that vendor’s particular flavor of FHIR.
Red flag: If your integration plan says “we’ll connect via FHIR” without specifying which EHR, which version, which profile, and which data elements you actually need, you don’t yet have an integration plan. You have an intention.
What “FHIR-Compliant” Actually Means in Practice
Compliance with FHIR is not a binary. It is a spectrum, and vendors know exactly how to position themselves at the compliant end while controlling how much of their data universe is actually reachable.
A vendor can truthfully say they support FHIR R4 while only exposing a subset of resources through that API. They can support read access without supporting write access. They can make certain resources available to credentialed partners while restricting others. They can implement the standard correctly for the data types regulators specifically mandate while leaving everything else behind a separate commercial agreement.
This is not necessarily bad faith. Some of it is legitimate data governance. Some of it is the genuine complexity of translating a decades-old proprietary data model into a modern API layer. But the practical effect, from a builder’s perspective, is that “this EHR supports FHIR” tells you very little about whether you can actually get the data your product needs, in the shape you need it, at the latency your product requires, without a separate commercial negotiation.
Reality check: The question is never “does this EHR support FHIR?” The questions are: which resources are exposed, at what fidelity, under what access terms, and what does production access actually require beyond the developer sandbox?
Where HL7 v2 Still Lives and Why It Matters
It is tempting to treat HL7 v2 as legacy infrastructure that FHIR is gradually replacing. The reality is more complicated.
HL7 v2 messages still power most of the real-time clinical event notifications that health systems rely on: admissions, discharges, transfers, lab results, order updates. These are the ADT feeds, the ORM messages, the ORU results that flow between EHRs, labs, pharmacies, and ancillary systems dozens of times per minute in a functioning hospital.
FHIR has not replaced this. For many use cases, it hasn’t even gotten close. If your product needs to know when a patient is admitted to a hospital in real time, you are almost certainly looking at an HL7 v2 ADT feed, not a FHIR subscription. If you need lab results pushed to your application as they are resulted, you are probably looking at HL7 v2 ORU messages.
This matters for founders because the integration story is often not one standard but two, or sometimes three if claims data is also involved. FHIR for patient record queries, HL7 v2 for real-time event streams, X12 EDI for claims and eligibility. Each has its own interface setup, its own maintenance overhead, and its own set of vendor-specific quirks.
If you only remember one thing: the EHR’s FHIR API is the front door. A lot of the data you actually need for a functioning clinical product is still coming through the side entrance, via HL7 v2 interfaces that haven’t changed much since the early 2000s.
The Economics Underneath the Standards
Here is the part that doesn’t appear in the documentation.
Major EHR vendors generate meaningful revenue from integration. Implementation fees, interface activation charges, app marketplace certifications, partner program tiers. When a vendor quotes a six-figure fee to activate an integration for a new health system, they are not being obstructionist in an obvious sense. They are monetizing access to their installed base, the same way any platform business does.
This creates a structural dynamic that no standard, on its own, resolves. The vendor has a financial incentive to make some integrations easy, specifically the ones that run through their own marketplace and generate platform revenue, and a weaker incentive to make arbitrary third-party access cheap and frictionless. FHIR mandates have pushed the floor up. They have not changed the ceiling.
The result is a tiered reality. If you build inside a major EHR’s app ecosystem, use their approved integration pathways, and distribute through their marketplace, access can be relatively straightforward. If you are building something that sits outside that ecosystem, or that competes with functionality the EHR vendor is building themselves, the commercial friction goes up considerably.
Decision rule: Before you commit to an integration architecture, find out whether your product fits inside or outside your target EHR vendor’s commercial ecosystem. That answer will shape your timeline, your cost, and your negotiating position more than any technical decision you make.
What This Means Before You Build
The founders who navigate EHR integrations well are not necessarily the most technically sophisticated ones. They are the ones who asked the commercial and operational questions early, before they wrote the integration into their roadmap as a six-week line item.
Specifically, before you scope any EHR integration, you need answers to these questions:
- Which specific data elements does your product need, and are they exposed through the standard FHIR endpoints at your target EHR, or do they require proprietary extensions or separate credentialing?
- Does your use case require real-time event data, in which case you are likely dealing with HL7 v2 feeds, not just FHIR queries?
- What does production access actually require beyond sandbox access, in terms of credentialing, security review, and commercial agreements?
- Does your product sit inside or outside the EHR vendor’s commercial ecosystem, and have you priced in what that means for your integration cost and timeline?
- Have you scoped the integration against a real health system environment, not just developer documentation?
- Is your product’s core value proposition intact if the integration takes significantly longer or costs significantly more than your current estimate?
Closing
The standards are real. FHIR has meaningfully improved what is possible in healthcare interoperability compared to a decade ago. Regulators have raised the floor, and that matters.
But a standard is not an implementation. And an implementation is shaped as much by economics as by engineering. The major EHR vendors built proprietary systems over decades, layered standards on top when required, and monetized the access layer in between. That is not a conspiracy. It is rational business behavior. And it is the environment every founder building on healthcare data is operating in, whether they’ve priced it into their roadmap or not.
The founders who move fastest through this are not the ones who found a technical shortcut. They are the ones who understood the commercial reality early, built their integration strategy around it, and stopped treating “the standard exists” as a synonym for “the integration is simple.”
Those are different things. In healthcare, almost always, they are very different things.
