In large FHIR projects, the problems rarely show up at the start.
In the early months everything looks on-track. Endpoints respond, data flows, and there is a general sense that things are moving in the right direction.
The cracks usually start to appear six to twelve months in.
- Missing expertise is identified (terminology, clinical domain, FHIR itself)
- New data requirements appear for the first time
- Legal and compliance are pulled in and begin questioning decisions that were already made
- The commercial viability of earlier technical choices is questioned
- Technical requirements struggle to get approval because they don’t map cleanly to user-facing features
From that point on, project leadership often enters a cautious and nervous state. Plans are revisited, shortcuts are proposed and scope is reduced or dropped.
Someone inevitably asks “Why are we using FHIR?” or suggests changing direction entirely.
In Chapter 3 of my book I describe this as a low tolerance for change.
This is usually not a technical problem. It’s a signal that the organization does not have the tolerance to take a multi-year, cross-domain project through to completion.
The reversals, the questioning of earlier decisions and the push for shortcuts are all part of the same problem.
The answer is often an incremental approach – moving to FHIR one domain or one requirement at a time.
It may mean starting with a facade to meet an immediate regulatory requirement and moving slowly toward a hybrid architecture. It may mean building a read-only hybrid system that exposes a single domain, adding others one by one. It may mean putting FHIR-native on hold and making use of master data management processes that already exist in your legacy systems.
If you’re seeing some of this already, don’t expect it to resolve itself. It usually points to earlier decisions that need to be revisited. If you want a fresh, independent perspective, we should have a call.
The book: https://darrendevitt.com/fhir-architecture-decisions-book/
---