How do the different FHIR server providers handle or recommend you handle multi-tenancy?
In this context multi-tenancy refers to patient and clinical data that is being stored for a number of different entities or “tenants”. Think of a tenant as a hospital, a clinic, an organization, even a country or region. How you define a tenant will depend on your data and your use case.
The key concern is that the data belonging to each tenant must be kept separated. It should never be possible for one tenant to access another tenant’s data.
If I run a FHIR search query to get Patient resources, I should only ever see MY patients, not yours.
Compliance
Before looking at the different approaches let’s look at the different forms that healthcare data compliance takes around the world. By compliance I’m talking about HIPAA, HITECH and their equivalents. This affects which multi-tenancy approach you might choose, especially if your databases or FHIR servers are hosted in the cloud.
When it comes to compliance and regulations, countries and regions tend to fall into one of two camps, with some crossover between them.
Camp 1
Physical separation of data is either required or preferred. Physical separation means each tenant’s data sits inside a separate and isolated database or FHIR server, reducing the risk of one tenant accessing another tenant’s data.
Camp 2
Logical separation of data is acceptable, assuming that the required security and access restrictions are in place to prevent one tenant from accessing another tenant’s data. Logical separation means that the data from 2, 20 or 200 hospitals can sit inside the same database or the same FHIR server so long as measures are taken to keep each tenant’s data secure.
This means that the country in which your customers reside will play a key role in your choice of approach to multi-tenancy, and from there in your choice of FHIR server provider.
Approach 1: One FHIR server per tenant (physical separation)
This is possible with ALL commercial FHIR servers and is the recommended approach from providers such as Microsoft Azure and others. Short of a bug that inadvertently shares access credentials, it is next to impossible for data from one tenant to be exposed to another.
The downside to this approach is that it can be very expensive.
If your multi-tenant use case is such that one tenant represents one country, then this approach can work as the number of tenants would be small and finite, making the number of FHIR servers required equally small and finite.
But if your use case means hundreds or more tenants, where each tenant represents a unique hospital or clinic, costs can start adding up quickly.
You could also find yourself badly exposed if the vendor increased prices or changed their pricing structure.
Approach 2: One FHIR API, separate database per tenant (physical separation)
A less commonly implemented approach from commercial vendors, but not at all uncommon for companies and organizations who implement their own FHIR server or API.
The data for each tenant is stored in a separate PostgreSQL, SQL Server or MongoDB, while the application layer that feeds the API requests is shared.
Here you get all the benefits of physical data separation without the need to pay for one complete FHIR server per tenant. FHIR servers can be considerably more expensive that simple SQL databases.
An example of a company who implements this approach is InterSystems, with their “Iris for Health” platform.
Approach 3: Shared FHIR server, resource filtering (logical separation)
One FHIR server populated with data from multiple tenants. This almost always requires a lot of work on your side to implement.
Examples of server providers who either recommend or implement this approach:
- Firely
- AWS
- Health Samurai
Each provider recommends doing this in slightly different ways, from adding a security label containing a tenant ID to each resource as it’s created or updated, to adding an extension to the Meta element of a resource containing a reference link to an Organization resource that represents the tenant.
The extra work required to enable this sort of feature usually involves building a proxy or gateway in front of the FHIR server and dynamically altering the request and response bodies to manage the extra resource elements. The work involved here should not be underestimated.
It’s also worth mentioning that a lot of care would be required to ensure queries were altered before they reach the FHIR server to enforce tenant ID parameters in every query and to ensure a tenant could only see and change their own data.
Expect server performance to suffer as a result.
Treat this approach with extreme caution. While it may be useful for test and QA servers, it feels fragile for production use.
Approach 4: Shared FHIR server, database partitioning (logical separation)
A less common approach involving partitioning of the underlying database. As with approach 3, this involves storing data from multiple tenants in the same FHIR server, but differs in that associating each resource with a particular tenant happens at the underlying database level and not in the raw FHIR resources themselves.
Essentially, using database columns in place of FHIR security labels and extensions.
The only server provider I know of that has implemented this feature is Smile Digital Health (HAPI), and even for them it’s a recent addition. As the tenant identification is happening at the database level, the performance issues that you would expect from approach 3 would not apply and a large part of the work to implement the feature is carried out by the server provider.
Which to Choose?
Going back to our two camps that most countries fall into, Camp 1 leans towards physical separation of data, making Approaches 1 and 2 the recommended paths to take.
Camp 2 allows for logical separation of data, which means Approaches 3 and 4 are viable.
Your choice here should be driven almost entirely by your target customer and market. If all or even some of your customers or potential customers are in Camp 1 countries, then you need to be looking at one FHIR server or one database per tenant (1 or 2).
If all of your customers or potential customers are in Camp 2 countries, then you could consider going with one of the logical separation approaches (3 or 4).
The key lesson from all of the above is that when you are planning your multi-tenancy approach, your first meetings should not be technical, they should be with your sales and marketing teams and with your legal and compliance people.
- Who will you be selling to?
- Where are they located?
- What rules or expectations apply?
Your multi-tenancy approach is a crucial decision and it needs to be made with great care. It’s one of those cases where keeping your technical people in the dark about future sales plans can be catastrophic. Changing the approach you take to multi-tenancy or changing FHIR server providers to achieve the same result is not a trivial undertaking.
Whatever choice you make, you’ll be stuck with it for a long while.
---