Multi-Tenancy in FHIR Servers: Benefits & Implementation

Explore what multi-tenancy in FHIR servers can offer! This article delves into the fundamentals of multi-tenancy architecture, compares it with single-tenancy, and highlights its significant benefits for managing sensitive healthcare data.

The ever-evolving healthcare IT ecosystem constantly seeks enhanced security, scalability, and cost-effectiveness. One innovative solution that holds promise in this domain is the introduction of multi-tenancy in FHIR servers.

This article will delve into multi-tenancy in the FHIR server landscape and examine its advantages.

What Is Multi-Tenancy?

At its core, multi-tenancy is an architecture in which a single instance of software supports multiple tenants (customers). Every tenant’s data and configurations remain isolated and invisible to other tenants, even though they operate on the same server. In the context of an FHIR server, every FHIR resource is stored in a unified database but distinguished based on ownership.

Single-tenant vs Multi-tenant process

For better understanding, imagine you’re living in a large apartment complex. Each apartment unit (tenant) is separate, and residents cannot access other units without the right key. Similarly, FHIR servers that support multi-tenancy ensure that different tenants can’t access or modify each other’s data, even though they’re on the same server.

Why Multi-Tenancy Is Desirable in FHIR Servers:

  1. Data Isolation and Security: Since the healthcare sector deals with sensitive patient data, data protection is paramount. With multi-tenancy, even though resources are housed in a single system, one tenant cannot access or modify another tenant’s data, upholding data integrity and security.
  2. Cost Efficiency: Instead of maintaining multiple server instances for different organizations or user groups, multi-tenancy allows you to host multiple tenants on a single server, reducing infrastructure costs.
  3. Scalability: As new tenants come on board, the multi-tenant server can accommodate them without setting up new instances, providing a scalable solution for growing organizations.
  4. Simplified Maintenance and Upgrades: With a single server to manage, IT teams can execute maintenance tasks, software updates, or security patches more efficiently, ensuring all tenants benefit simultaneously.

The Multi-Tenancy Process on an FHIR Server

The process by which an FHIR server manages multi-tenancy can be intricate, as it requires ensuring data segregation, security, and efficient access to data for each tenant. 

To better understand what happens when an FHIR server manages multi-tenancy, let’s examine the step-by-step breakdown of the multi-tenancy management process within an FHIR server. We will also talk about multi-tenancy in Kodjin FHIR Server.

1. Tenant Identification:

  • Initialization: Upon any incoming request, the server first identifies the tenant. This could be based on an API key, a custom header, a token, or a subdomain. To distinguish between different tenants, Kodjin FHIR Server supports an access token containing tenant information for external clients.

2. Database Segregation:

  • Data Partitioning: Depending on the architecture choice, the server may either use:
    • Separate Databases: Every tenant has its database.
    • Shared Database, Separate Schemas: A single database but different schema for each tenant.
    • Shared Database, Shared Schema: A single database and schema, but data from different tenants is marked with identifiers.

In the Kodjin FHIR Server, we utilize a single database to store resources, but each is isolated by different ownership.

3. Request Processing:

  • Tenant Context: Once the tenant is identified, the server sets a context for that tenant, ensuring all subsequent operations in that request’s lifecycle are restricted to that tenant’s data.
  • Resource Handling: CRUDS (Create, Read, Update, Delete, Search) operations are directed to the correct partition, schema, or set of records based on the tenant context.
  • Common Resources Accessibility: The Kodjin FHIR Server recognizes that resources might be common to all tenants. In the Kodjin FHIR server, such resources are explicitly listed in an ‘exclude-resources’ object in the multi-tenancy configuration, ensuring they remain accessible to every tenant.

4. Access Control & Security:

  • Role-Based Access Control (RBAC): After identifying a user’s role within a tenant, permissions within a token determine which resources they can access or modify. In the Kodjin FHIR Server, the RBAC module is pivotal in identifying the tenant’s owner based on access token claims.

5. Query Execution:

  • Tenant-Aware Filtering: When querying the database, the server adds filters to ensure that only data related to the current tenant context is fetched.
  • Validation: Before executing any write operations, the server validates that the operation is consistent with the tenant’s context.

6. Performance and Scaling:

  • Resource Allocation: Depending on usage patterns, the server might allocate different resources or prioritize workloads for different tenants.
  • Auto-Scaling: In cloud environments, the server can automatically scale resources up or down based on individual tenant demands.

Managing multi-tenancy in an FHIR server is about maintaining a delicate balance between shared efficiencies and tenant-specific isolations. An FHIR server with multi-tenancy should provide the benefits of shared infrastructure and services while ensuring each tenant’s data remains isolated, secure, and readily accessible.

Kodjin FHIR server implements multi-tenancy using authorization tokens, ensuring data security. This system ensures every tenant’s data is isolated, making it an efficient solution for organizations managing data, FHIR data export, and exchange for multiple clients or departments.

Additionally, besides the standard CRUDS operation, the Kodjin FHIR Server supports multi-tenancy for bulk export and import operations, FHIR subscriptions, and resource versions.

You can read more about how multi-tenancy works on Kodjin in our documentation


The healthcare sector’s emphasis on patient data privacy and the need for scalable and cost-effective IT solutions make multi-tenancy on FHIR servers a compelling choice. Moreover, the integration of a FHIR facade enhances the interoperability, making data accessibility seamless and secure. Kodjin FHIR Server, with its comprehensive implementation of multi-tenant FHIR API, offers organizations a robust platform that balances flexibility, security, and efficiency.

Organizations keen on adopting a future-proof IT architecture should consider integrating multi-tenancy in their FHIR servers, leveraging the myriad benefits it brings.

Post author

Andrii Krylov

Product Owner at Edenlab

More article about Blog about FHIR

Let`s chat

We would be glad to share more details about our enterprise-level FHIR software solutions and other cases based on the HL7 FHIR standard.

    Your form has been submitted successfully

    We will contact your shortly

    Kodjin White Paper

    Please leave your email to get Kodjin White Paper

      By downloading files from this site you agree to the Policy

      The Kodjin White Paper has been successfully sent to your email

      We have sent a copy to your email

      Back to website content