The FHIR trend is still set to dominate in 2024. The ONC's rules are proving to be quite a challenge for vendors, as they need to provide a HL7® FHIR API with SMART on FHIR support for every client.
Many EHR vendors still have questions on reducing the burden of having so many FHIR servers. It’s simple: multitenancy is always the right answer.
In this article you will find out the answers to the following questions:
Multitenancy is a key benefit of SaaS ERP systems. In brief, it’s a way of providing shared resources to multiple customers (tenants), with each customer given their own dedicated environment.
The tenants are isolated from each other, meaning that the data of one will not be visible to another in any way. Users can access their own data without infringing on the privacy or data of other tenants.
This makes it an attractive option for businesses that need to share resources across multiple users but also need to maintain individual data privacy and security.
However, when discussing multitenancy, physical isolation should also be taken into consideration. The degree of physical isolation is flexible and can range from complete physical separation to a shared hosting space with each tenant having its own unique platform space.
The degree of physical isolation between different tenants is determined by the underlying technology, but it must generally provide complete logical isolation to ensure that each tenant’s data remains secure (Gartner).
.png)
Now let’s look at the benefits of multitenancy for EHR vendors and other platform services:
That being said, no solution is perfect. In terms of the host, multitenancy is more complicated than a single tenancy. We don’t stop at theory, so keep on reading!
Get started with the Aidbox FHIR Server for data storage, integrations, healthcare analytics, and more, or hire our team to support your software development needs.
FHIR doesn’t support multitenancy at the specification level. In fact, it doesn’t need to. However, lots of FHIR servers like Aidbox are taking the best of two worlds: FHIR and multi-tenant architecture. Learn more about multitenancy in the Aidbox documentation.
Multitenancy is a matter of internal architectural decisions. FHIR exposes FHIR_BASE_URL to make the functionality available to others. Every client of yours should get their own FHIR_BASE_URL. We will explain this in more detail later on.
.png)
Here we will explore some techniques which may help you build a highly shared solution. It also goes further in allowing you to migrate to a lower level of multitenancy on demand in the event that some clients need more dedicated resources. In order to implement it, we need to take a look at a few key steps:
At the end of the process, your client will have great confidence in their total isolation at the data and API level, which will be justified.
Explicitly defining tenants is crucial for two significant reasons:
Explicit tenant resources are a good place to track them and enter some specific custom configurations. You may consider introducing extra resources:
id: my-clinic resource
Type: Tenant
name: My Clinic
This is the reason we’re going for multitenancy in the first place. I suggest making the tenant an explicit property of every resource. It will open up a large space where you can store data, and will also allow you to carry out migration and evolve your infrastructure to meet performance requirements as they grow.
Tenancy is a meta property, so let's take Aidbox as an example and explore how we store it under the meta field in FHIR resources.
# Aidbox format
meta:
tenant:
id: my-clinic
resourceType: Tenant
# FHIR format
meta:
extension:
- url: <https://aidbox.app/tenant-id>
valueReference
reference: Tenant/my-clinic
This is an external representation. When it comes to the internal one, we may begin with a simple approach from an infrastructure point of view. We can store data in one database and one table per resource type.
The only strong restriction I can see is that you will have to implement filtering by tenant on the application level, which is a pretty reasonable cost for keeping your infrastructure as simple as possible.
In case a tenant requires more resources, produces a huge load and affects other tenants, you are always able to migrate their data into another database and run a dedicated instance of the same application for that tenant.
When all of your clients have a dedicated FHIR API, you need to provide them with a different FHIR_BASE_URL which their virtual FHIR Server will run on. There are two ways to do this:
Both options are OK, though the first looks more precise and cleaner.
If you have full access to your domain and can reserve subdomains for your tenants, you may consider putting the tenant ID into the domain name. Your application should also be able to work with different domains in the same instance, and it usually does.
Having the tenant ID in the URL path is also OK. It doesn’t require you to sacrifice so many domain names, even if you don’t have access to them. The FHIR API implements REST style, and the REST API doesn’t expect any sessions between requests, which means no browser cookies.
Now we have a dedicated FHIR API for every client, and the data in the storage belongs to tenants too. The finishing touch is dedicating the auth server. Why is this? You may be curious as to whether it’s possible to have one auth server. I believe that it is not, and here’s why.
Let’s say a user has an account in two different tenants. What do we have then? Can this user be simultaneously logged in to both tenants? Technically, yes. Google is a good example. You may use Google services and switch between accounts in a couple of clicks. But is this the UX (user experience) you’re looking for? I believe not. There two reasons for this:
But this does not stop here, as the auth server must be multi-tenant too. This can be achieved by following the same method we used to separate FHIR APIs for tenants: a dedicated AUTH_BASE_URL. It doesn’t matter if the tenant ID appears in the domain name or URL path. The only thing that matters is that tenants may simultaneously be logged in to all your auth servers and interact with your FHIR servers as independent entities.
There are four simple steps to achieving multitenancy:
Once you apply those four simple steps, you will be able to make a FHIR server with no extra infrastructure costs, since you need just to create a Tenant resource and virtual FHIR server, meaning that the auth server will be already deployed for it.
If some of your tenants outgrow their allocation, you can easily dedicate a higher level of isolation. You simply need to:
We have recently enhanced the system by adding organization-based hierarchical access control. This new feature allows for more flexible and precise data access management based on organizational hierarchy. Administrators can now set access permissions at various organizational levels, ensuring that users only see the data they are authorized to view. This improvement significantly enhances the security and manageability of the system, especially in large organizations with complex structures. Detailed information about the new functionality can be found in the Aidbox documentation.
To explore the implementation of a multi-tenant FHIR API in your EHR system, consider using the free version of Aidbox. It provides a robust environment to test and develop these capabilities, offering all the necessary tools without any feature limitations.
Author: Vlad Ganshin, Software Engineer at Health Samurai
If you are looking for a multi-tenant FHIR API that can take you into 2024 and beyond, try the ONC’s certified Aidbox FHIR API module today.
Get in touch with us today!
