I work with a lot of different organizations at various stages of their FHIR development. My role is often to prevent mistakes before they happen. Sadly, this isn’t always possible.
Too often I find myself helping them correct mistakes that they’ve already made – sometimes months or even years earlier.
The most common and costly mistakes I see are in FHIR architecture and vendor selection.
- Letting data flow into or out of the server in the wrong way
- Using the wrong FHIR server provider
- Treating the FHIR server as a database
- Building FHIR solutions over two years that are not adequate to requirements
All before a first commercial version is released. All before a single real Patient resource enters or leaves the server.
Why does this happen?
Decisions around FHIR servers and FHIR architecture tend to be made early in a project. If an organization is new to FHIR this is the time when the technical team has the least experience of FHIR.
Lack of experience = poor decisions.
What I see happening is organizations adopt an “easy” FHIR option to get them started. They then build on top of this easy option – all with a view to revisiting that early decision at a later date.
As most of us know, “quick and dirty” decisions have a habit of sticking around for the long haul in software development. The business thinks the FHIR decisions are made. Data is flowing. Nothing appears to be broken. Screens are populated and AI seems to be working.
For good or ill the FHIR decisions are made.
What are those “easy” options?
The most common easy option is going with a managed FHIR server from one of the big cloud providers.
If your application is built on top of AWS, Azure or Google Cloud, that initial easy FHIR decision will usually be to go with their FHIR servers.
- Easy to spin up
- Easy to integrate into existing data flows
- Easy to authenticate against
- Easy to build into terraform scripts
The easy decision is made and the various teams spend the next 18 months building their apps and solutions on top of it.
What happens next?
Things start to get complicated.
As the project matures, more and more focus is given to the detailed plumbing of the applications.
- Multi-tenancy
- Master data management
- Data Governance
- Syncing with core databases and data warehouses
At which point senior technical leaders – who may not have been a part of the project years earlier – begin to revisit those early FHIR decisions. “Easy” starts to look costly. Meetings are had with sales and technical teams at AWS or Google or Microsoft.
Realization creeps in that many of the early decisions were wrong. That current solutions and vendors are inadequate. That the team did not have the experience to make the right decisions two years ago.
Everything has to be re-examined and decisions have to be re-made.
- New architectural diagrams are produced
- A “hybrid” approach to FHIR is adopted
- Meetings are had with different server vendors
- Timelines are pushed out by 12 months
- Sales and marketing teams are told to reset expectations
- Some people lose their jobs
I’ve seen this happen enough times to know that it’s a general problem. When caught early it can be fixed. But for this to happen there has to be a willingness to forego those “easy” options early on. To invest time and resources in building the right foundation at the start.
Not every organization has the ability to do this. Too often leadership is driven by short term targets and deadlines.
If any of this sounds familiar, reach out and we’ll have a chat. These problems can be fixed but there has to be a willingness to fix them and to pay the price that that fix entails.
---