Private health tech companies are increasingly building data platforms with FHIR at the center.
The logic is sound. Consolidate data from multiple sources and systems into a single “Platform”, and store it in a structured and well understood format. Make it available for AI, for research, for analytics, and for integrations with partners and customers.
FHIR is becoming the chosen mechanism to achieve all of this. In some cases it works, but often it fails and fails badly.
I see this from two directions. Projects I work on directly, and conversations I have with teams who are part-way through the journey and are starting to run into difficulties. Both tell the same story.
I watched one project lose two years of development and burn through close to $50 million before the problems were fully understood, and by then it was too late to fix. The platform project was abandoned.
The failure pattern is consistent enough that it’s worth documenting.
The profile of the companies that get this wrong
The common thread is a private company making a strategic decision. For them FHIR is not a regulatory requirement, it’s the foundation for something much larger. A data platform, a product rewrite, or a new revenue stream built on data that was previously locked away behind proprietary APIs and data schemas.
Two versions of this company show up repeatedly.
The first is an early-stage or scaling business building something new. They have a strong engineering team, real ambition and VC or private equity backing. They also have nobody in the room who has built a healthcare data system from scratch before.
The second is an established company re-imagining an existing product around FHIR. They have deep healthcare data experience in the organization, sometimes decades of it. But the platform build is treated as a greenfield project. The old expertise that got them to where they are today is seen as legacy thinking, and FHIR is seen as different enough that old rules no longer apply.
It’s the magic bullet, the same logic as “AI will solve everything“, and it’s just as dangerous.
This second failure is the $50 million failure. The expertise existed, but it was consciously left out of the room.
Ambition without the expertise to back it up
With FHIR-native or hybrid systems, the initial architecture diagram looks clean. A FHIR server sits at the centre, data flows in from multiple systems, and consumers access it via a standard API. The early months go well. The FHIR server integrates cleanly with existing cloud infrastructure, and data flows smoothly between apps, AI Agents and source systems.
The demos look impressive. (This should be a bumper sticker.)
The problems begin stacking up as the use cases get more complicated, reflecting the real-world and not the happy path scenarios. The data model then has to reflect reality and not assumptions.
For the first company, the gap is straightforward. They have competent technical architects but little healthcare data expertise. They have strong developers but they never had to think about terminology, patient identity or data governance before.
For the second, the gap is self-inflicted. The people who understand the data, who know where the complexity lies, are sidelined. FHIR is supposed to make their knowledge redundant, but it doesn’t. It just delays the moment when the project finds out.
Terminology – the most common point of failure
In almost every case where I’ve seen a FHIR data platform struggle, terminology is where the failure first manifests.
A data platform is only as useful as the data inside it. If Observations from three different source systems use three different coding systems, or the same codes with different meanings, the platform can’t do what it was built to do. AI can’t use it reliably, and research queries and analytical dashboards return inconsistent results.
Fixing this is not a configuration task. It requires terminology expertise that most private health tech companies do not have in-house and rarely think to hire soon enough. By the time the problem is visible, architectural decisions are locked in, partnerships have been made, and the cost to fix it is seen as too high.
But terminology is not a FHIR problem.
What makes this sort of failure so disappointing is that it’s a fixable problem that we’ve known about for decades. This makes the project failure a management failure.
FHIR is not the whole answer
A FHIR server validates and stores what you send it. That’s all it does.
Teams building FHIR-centric data platforms often discover late that several problems still need to be solved independently.
If consumers need to query the data analytically, a translation to OMOP or a data warehouse sync is often required. If data is coming in from multiple systems with different patient identifiers, you need an MPI. And if the platform is the source of truth for any of its data, then data governance processes need to be built.
Each of these is a project in itself, but they’re all manageable and well understood projects. There’s nothing new here. Discovered early, the wider platform project can succeed. Discovered after two years of development, they can be fatal.
At the second company, this is typically the point where you start seeing project leadership changes. The check has to be paid by someone.
What this means for you
If you’re building a FHIR data platform and starting to feel that things are not right, here are some questions to ask.
Has anyone on the team spent real time on terminology, or is it still “on the roadmap”? Has the MPI question been answered, or is there a shaky assumption that it won’t be required? Is there a plan for OMOP or analytical access, or has that been relegated to version 2?
None of these questions are hard to answer. What’s hard is acting on the answers early enough, when the costs are still manageable.
That $50 million didn’t disappear in one bad decision. It disappeared in a hundred small ones, each made by people who assumed someone else had the bigger picture covered. At the heart of all of this – false assumptions around FHIR.
---