Multi Tenant Architecture Healthcare SaaS

What is multi-tenant architecture for healthcare SaaS?

Multi-tenant architecture for healthcare SaaS is a platform design in which one codebase and shared infrastructure serve many customer organizations, while each tenant's ePHI, encryption keys, audit logs and EHR credentials stay separated. The separation must hold in queries, caches, files, background jobs and support tools, and it must be proven by tests that try to cross it.

A tenant_id column is a starting point, not a control. Security reviewers at a health system will ask how one tenant is kept out of another tenant's data when a query, a job or an administrator makes a mistake.

Which tenancy model fits a healthcare product?

The right tenancy model depends on the customers' size, their contract demands and the operating cost the product can carry. Most platforms choose one default and keep a stronger option for customers who require it.

• Shared tables with row-level security: All tenants share tables, and the database enforces a tenant filter on every query. Lowest cost per tenant, but the filter and its tests carry all of the isolation.
• Schema per tenant: Each tenant has its own schema in a shared database. Isolation is clearer and per-tenant restore is easier, at the cost of more migrations to run.
• Database per tenant: Each tenant has its own database, often with its own encryption key. Strong isolation and simple tenant offboarding, with higher operating cost.
• Deployment per tenant: A full stack per customer, for tenants whose contracts require it. Strongest separation, and the closest to running many products.

A platform can also mix models: shared tables for small clinics and a dedicated database for a large health system. Design the data access layer so a tenant can move between models without code changes.

Write the chosen model into the security documentation for each customer. A health system's reviewer will want to know which model applies to them, not which models the platform supports.

How do you isolate tenants across data, keys, logs and credentials?

Isolate tenants in five layers, each with its own control and its own test. A failure in one layer is not rescued by the others, so each must hold on its own, including in code paths that run without a signed-in user, such as scheduled jobs and message consumers.

• 1. Request context: Resolve the tenant once, at authentication, from the token or the signed-in account. Pass it through every service call and background job, and reject any request where it is missing.
• 2. Data: Enforce the tenant filter in the database, for example with row-level security or separate schemas, not only in application code. Caches, search indexes and file storage use tenant-scoped keys and paths.
• 3. Keys: Use a separate encryption key per tenant for data at rest where the model allows it, so a tenant can be offboarded by retiring its key and a key compromise affects one tenant.
• 4. Logs and audit: Write the tenant on every access record, keep resource bodies out of shared logs, and make sure a tenant administrator can read only that tenant's audit trail.
• 5. EHR and FHIR credentials: Register a separate client per customer organization with its own secrets or key pairs, stored under tenant-scoped paths, so revoking one customer's access touches no one else.

Support and operations tools need the same model. A support engineer who can see every tenant's data is a documented exception with its own approval, logging and time limit, not the default role.

Noisy neighbors and per-tenant limits

A noisy neighbor is a tenant whose workload slows or blocks the others, and in healthcare it can delay clinical work for every customer. Per-tenant limits keep one tenant's spike inside its own budget.

• API limits: Rate limits per tenant and per client, so one integration retry storm cannot exhaust shared capacity.
• Job queues: Separate or weighted queues for exports, imports and report builds, so a large tenant's nightly job does not hold back another tenant's daytime work.
• Database load: Statement timeouts and connection pools sized per tenant or tier, and large tenants moved to their own database when their load demands it.
• Outbound EHR calls: Limits per customer organization that respect each EHR's own rate rules, so one tenant's sync does not get every tenant's client throttled.

Track usage per tenant from day one. Without per-tenant metrics, a slowdown shows up only as a platform problem, and nobody can tell which tenant caused it.

Write the limits into each customer agreement or service description. A tenant that knows its export quota plans around it, while a tenant that discovers it during a busy clinic morning opens a support case.

How do BAAs work when one platform serves many tenants?

Business associate agreements stack in layers rather than replacing each other. The SaaS company signs a BAA with each covered-entity customer, and it signs its own BAAs with each subcontractor that creates, receives, maintains or transmits that PHI on its behalf.

• Customer layer: Each covered-entity tenant signs a BAA with the SaaS company, because the platform handles PHI on that customer's behalf.
• Subcontractor layer: The SaaS company signs BAAs with its cloud host, its backup and logging providers, and any engineering partner with access to PHI. HHS treats a cloud provider that holds ePHI as a business associate even when the data is encrypted and the provider holds no key.
• Tenants that are not covered entities: A business associate tenant, such as a billing company, signs a subcontractor-style BAA with the platform instead.
• Consumer tenants: A product sold straight to patients, with no covered entity involved, may sit outside HIPAA, in which case breach duties come from the FTC rule at 16 CFR Part 318.

Keep a BAA matrix with one row per tenant and per subcontractor, showing the signed agreement, the PHI involved and the breach notice terms. Isolation design and the matrix should tell the same story.

Check the agreements against the architecture whenever a vendor is added. A new log analytics tool or support platform that receives tenant data is a new subcontractor, and the BAA has to be in place before the first record is sent to it.

Which HIPAA and NIST controls map to tenant isolation?

Tenant isolation maps onto HIPAA Security Rule standards and onto NIST controls that address shared resources and component isolation. These are the citations worth putting in a customer security package.

• 45 CFR 164.308(a)(1) requires a risk analysis and a regular review of information system activity, such as audit logs and access reports, for every system holding ePHI.
• 45 CFR 164.312 lists unique user identification and audit controls as required technical safeguards, and lists encryption and decryption of ePHI as an addressable specification.
• 45 CFR 164.502(e) and 164.308(b) allow a business associate to share PHI with a subcontractor only with satisfactory written assurances, which is the subcontractor BAA.
• NIST SP 800-53 Revision 5 control SC-4 addresses information in shared system resources, and SC-7 boundary protection includes an enhancement for isolating system components.
• NIST SP 800-66 Revision 2 is NIST's resource guide for implementing the HIPAA Security Rule, with key activities for each standard.

The Security Rule does not name a tenancy model, row-level security or a key manager. Those are design choices that meet the standards, and the risk analysis is where the platform explains why they are reasonable.

Tenant isolation test plan

Run this test plan as a release gate, not a one-time audit. Each test tries to cross a tenant boundary and must fail.

• Cross-tenant read: A user of tenant A requests a known record of tenant B by ID through every API and gets a denial.
• Missing context: A request or job with no tenant context is rejected, not run against all tenants.
• Cache and search: A cached or indexed result from tenant B never appears in tenant A's responses.
• Files: Tenant A cannot list or download tenant B's files, exports or reports, even with a guessed path.
• Keys: Data written for tenant A cannot be decrypted with tenant B's key.
• Audit: Tenant A's administrator sees only tenant A's access records.
• Credentials: Revoking one customer's EHR client leaves every other tenant's integration running.
• Limits: A load test on one tenant leaves other tenants' response times within their normal range.

Keep the results with each release. When a customer's security team asks how isolation is proven, the answer is the latest test run, not a diagram.

How Agnotic can help

Tenant isolation is cheapest to build before the second customer signs. Agnotic Technologies builds multi-tenant platforms for healthcare product companies: tenant context resolved at authentication, database-enforced filters or separate schemas, per-tenant keys, tenant-scoped logs and EHR credentials, per-tenant limits, and the isolation test plan wired into the release pipeline.

Agnotic also reviews existing platforms against the test plan above and plans the move from shared tables to stronger models for customers that need them.

Sources

• eCFR: 45 CFR 164.308, Administrative safeguards
• eCFR: 45 CFR 164.312, Technical safeguards
• 45 CFR 164.502(e): Disclosures to business associates
• 45 CFR 164.504(e): Business associate contracts
• NIST CSRC: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST CSRC: SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
• HL7: SMART App Launch, backend services