Getting multi-tenancy in FHIR wrong can be an expensive mistake.
I can’t help but feel that this should be a solved problem by now – with no uncertainties – but it’s not.
Unless by “solved” you mean choosing from one of 7 different approaches.
I wrote about this in my Weekly Insights newsletter last week and got some great responses. There are innovative solutions out there.
At a high level, there are two ways to achieve multi-tenancy.
1. Physical separation of data
– One FHIR server or database per tenant
2. Logical separation of data
– Everyone’s data in the same FHIR server
Depending on which country you’re building for or selling to, either approach can work.
Physical separation is always going to be safer but it’s also a lot more expensive. Unfortunately, you don’t always have a choice – sometimes you have to eat the cost.
Here’s the problem.
Multi tenancy decisions are usually made early in the project, around the same time as the FHIR server decisions.
- Do we build or do we buy?
- If we buy, which server provider do we choose?
It’s the worst time to make such an important decision as FHIR knowledge on the technical and business sides is generally at its lowest.
If you make the wrong decision around multi-tenancy, how wrong it is might not become clear until a year or two later.
At which point it’s either impossible to fix or hugely expensive to fix. Costs go up, release deadlines are not met, legal and compliance are on your back.
That’s how serious this is.
You can read the full post here.
---