FHIR did not solve healthcare interoperability

A new health-tech founder reads about FHIR for the first time and gets briefly optimistic. There is a standard. The standard is modern. The standard is REST-based, JSON-shaped, and OAuth-authenticated. Surely this means EHR integration is a solved problem.

Then they actually integrate with their first EHR, and within a week the optimism is gone. The standard exists. The implementations do not agree on it. The gap between "FHIR-compatible" on the marketing page and "talks to this specific Epic deployment" in practice is enormous, and it is where the actual integration work lives.

What FHIR is good for

The standard itself is a real achievement. It defines resource shapes for the entities that matter in healthcare — patients, observations, conditions, medications, encounters — in a way that is reasonably modern, reasonably extensible, and far more workable than the alternatives that came before.

If you are building greenfield, FHIR is the right choice. Your internal data model will end up looking like FHIR even if you do not start there, so starting there saves the inevitable rewrite.

If you are building a generic tool that consumes "FHIR data" without caring which system it came from, the standard gets you maybe 80 percent of the way. For demos, prototypes, and academic work, that is enough.

Where the trouble starts

The trouble starts when you have to talk to a real EHR in a real hospital network. There are three distinct gaps.

The vendor-specific gap. Epic, Cerner, Meditech, and Athena all expose FHIR endpoints. They do not all expose the same FHIR. Each has its own quirks — fields that are required by the standard but absent in their data, extensions that exist in their version but nowhere else, fields populated with different meanings in different deployments. The cliché in the industry is "if you've seen one Epic, you've seen one Epic." It is a cliché because it is true.

The deployment-specific gap. Even within one vendor, every hospital configures the system differently. Two Epic deployments at two different health systems will return data that conforms to the standard but means subtly different things. The way one site uses a particular observation code might overlap with how another site uses an entirely different one. Without local clinical knowledge, the data is correct and incomprehensible at the same time.

The historical-data gap. FHIR is modern. The data is not. Most clinical data in any production EHR predates the FHIR era and was originally encoded in HL7 v2, ICD-9, custom dictionaries, or free text. The FHIR endpoint sits over a translation layer, and the translation layer is incomplete, lossy, and full of edge cases. Asking "what medications has this patient ever been on?" via FHIR will get you a list. Whether the list is complete is a separate question, and the answer is almost always no.

What actually works

We have shipped a lot of EHR integrations. A few things that have held up.

Treat FHIR as a starting point, not a contract. Build your domain model the way it should look. Then build a translation layer between FHIR and your model, and treat that layer as the most fragile, most heavily tested part of your codebase. It is.

Test against real (de-identified) data, not the sandbox. Vendor sandboxes contain idealized data that the vendor's marketing team would not be ashamed of. Production data does not look like that. Get access to representative real data — anonymized, with the right BAAs in place — and run your code against it before you go live. The bugs you find this way are the bugs your customers would have found in week one.

Build for graceful degradation, not for completeness. Some patients will have data. Some will not. Some fields will be populated. Some will not. Most healthcare software fails in production not because the data is wrong, but because the software assumes data is there that is not. Code defensively, surface gaps to users honestly, and never silently default to "no value" when the answer might be "we do not know."

Have someone with clinical fluency on the team. The data is medical. The decisions about what to do when the data is ambiguous are medical decisions. If your team cannot tell the difference between a clinically meaningful gap and a meaningless one, the product will quietly make decisions that no clinician would endorse.

The honest summary

FHIR did not solve healthcare interoperability. It made the next decade of work possible, which is a different and more accurate thing to say. The actual integration work — the part that takes the time, the part that holds production together — sits on top of FHIR, not inside it. Anyone who tells you otherwise has either not shipped a real integration, or is selling one.