Casual use of the term “FHIR database” needs to be actively discouraged.
It pops up all the time in meetings and in demos, and it leads to misunderstandings and unmet expectations at all levels.
It’s easy to forget that for most developers and stakeholders FHIR is only one part of a much larger application or solution.
It’s what they call to get data and it’s what they call to save data.
And when they do this they’re often using an SDK that conceals the fact that they’re calling an API at all. Many SDKs look and behave similar to the ORMs they use to access regular relational databases.
So the confusion is understandable. But that doesn’t mean it’s not a problem.
When developers look on FHIR as a database they assume lots of things.
- That FHIR gives them the same functionality as a database
- That they can run OR clauses in queries
- That different APIs will be consistent
- That they will receive what they ask for (without truncation)
- That _count will be accurate
When business stakeholders see FHIR as a database they make their own set of assumptions.
- That queries will be fast
- That backups will be easy
- That loading data into FHIR will be quick and straight forwards
- That BI and other analytical tools can work easily with that data
This last is particularly invasive.
It always comes as a surprise to the business when they learn that none of the intensive queries they want to run to populate screens and reports filled with aggregated metrics are possible.
That a whole new application complete with a costly data warehouse and syncing process needs to be built to enable this.
So let’s say it again: FHIR is NOT a database.
---