Every software developer in the world has used Stack Overflow. It’s a question and answer website created in 2008 where you can get help from other developers on virtually any topic. For 15 years it was the “go to” website for asking questions and searching for answers on minute technical and coding details.
But it has a flaw. It only accepts questions about programming that are laser focused. Broad questions such as “What is the best approach to…” are not allowed and are promptly closed. If you have such a question you’re out of luck . There’s no corresponding website you can go to for help.
FHIR has a similar problem.
There are many resources out there to help you with detailed questions. Questions about data mapping, terminology choices, resource and element usage.
The FHIR documentation does a fantastic job here and Implementation Guides go a long way to addressing the finer details of specific domains. And the FHIR chat forum is full of helpful experts who will answer your questions in great detail. The more tightly focused your question the more helpful these experts are.
But the “StackOverflow Problem” is real.
Wider discussions around how best to build FHIR solutions are almost impossible to find. If you’re a technical architect tasked with building a solution that uses FHIR, you’re left entirely to your own devices to work out the best way to do it.
There are no “best practices” to draw upon.
If you’re working on a national program to share your country’s patient data via FHIR, all that’s open to you are historic DevDays videos where a technical representative from one country or another discusses their own implementation at a PowerPoint level.
No technical detail, no discussion of trade-offs, not much help at all really.
Here are a few examples of questions that architects or product leaders might need to answer for their FHIR project:
- How do I build a solution that exposes our Oracle data via FHIR APIs?
- Should data providers be given write access to our FHIR server?
- Is FHIR Native the best approach to take for our use case?
- How do we choose between FHIR server vendors?
- What is the best way to keep a FHIR server in synch with our core databases?
- Should we allow unknown extensions into our FHIR server?
- How do we handle Master Data Management and “golden records” in FHIR?
There are many more — so many more.
You will not find answers to these or similar questions online. You will rarely find in-depth discussions about them.
The reason for this may be that HL7 as an organization does not see itself as having a role to play in how “implementers” build their FHIR APIs and manage their FHIR data. They don’t offer any guidance on the architectural or implementation sides and the wider community seems to have accepted this.
Maybe these technical conversations are happening behind closed doors somewhere — at FHIR Connectathons or DevDays. But if they are, they really should be happening in public.
Where does this leave us?
Every organization from small businesses to huge government agencies have to work all of these technical implementation details out for themselves. Which leads to a host of different solutions — some good and some bad.
The costs of making the wrong decisions are huge:
- Project delays and rewrites
- Cost overruns
- Weak implementations in production
- Data quality issues
- Patient access problems
How did technical architects in other fields work around the limitations of the StackOverflow website?
They read definitive 800 page architecture and design books from O’Reilly or Wiley that directly addressed their questions. Books like “Enterprise Integration Patterns” and “Designing Data-Intensive Applications”.
They read detailed blog posts from other technical people who faced and addressed similar problems.
Until we have these or similar resources for FHIR, we’re left with every technical implementer working things out for themselves — reinventing the wheel time after time after time.
Problem is, sometimes those wheels are square!
---