FHIR is not a silver bullet.
It won’t solve all of your problems and it’s unlikely to satisfy all of your business requirements.
FHIR comes with it’s own set of limitations that businesses often fail to understand — at least at the outset. It’s new technology, and like a lot of new technology it attracts great hopes and expectations.
Key limitation: FHIR is not a database!
Your developers understand this, but the business often does not.
FHIR is an API that sits on top of your data. That data source may be a database, a data warehouse, or a disparate set of data sources brought together under the FHIR umbrella.
Compared to databases, APIs are slow, cumbersome and generally limited in how you can use them.
A fully implemented FHIR API allows you to search across a wide set of resource types using a host of search parameters. But that API request is NOT the same as a database query.
Does your product or business have a requirement for an “Analytical Dashboard”?
What I’m referring to is a fancy UI of some kind that displays aggregated metrics drawn from all the data you’ve gathered over time.
These dashboards are all the rage.
You cannot populate these screens from a FHIR API. It’s simply too slow and doesn’t have the querying capability to allow you to extract the precise figures your screens require.
For this you need a real database or data warehouse.
If you want your dashboard to show accumulated data and if you want to draw that data from your FHIR server, you have no choice but to synch your FHIR data with a regular database or data warehouse and run your queries from there.
This comes with the extra workload of building the FHIR data syncing mechanism and maintaining the second data repository — all non trivial.
In short, a whole other project.
Follow up:
- SQL on FHIR
- Azure Fabric FHIR
- AWS FHIR Redshift
- Google FHIR BigQuery
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.