Multi-Tenant Architecture

In a federated healthcare environment, guaranteeing strict data isolation between different institutions, departments, or research consortiums is critical. ColabBio tackles this through a robust Multi-Tenant Architecture built directly on top of Kubernetes primitives.

Tenant Isolation Strategy

ColabBio avoids mixing tenant data at the database layer (no shared schemas). Instead, it provisions completely isolated environments for each tenant.

1. Namespace Isolation

Each tenant (e.g., Hospital A, Research Group B) is assigned its own dedicated Kubernetes Namespace.

Inside this isolated namespace, the tenant runs its own dedicated instances of:

• Clinical Data Store: Their own private OMOP CDM PostgreSQL database and DICOM archive.
• Compute Workloads: Their own Nextflow orchestration engine and Machine Learning jobs.
• Federated Learning Node: Their own local weights aggregator that communicates with the global network.

2. Generic Platform vs. Tenant Projects

ColabBio source code and deployments are strictly divided to prevent accidental data leakage:

• Generic Platform Components (cb-*): Services like the Ingress Controller, IAM Identity Provider, and the core Virtual File System (MedVFS) engine. These run globally and route traffic or provide foundational services.
• Tenant-Specific Projects (e.g., WSI_MIL): Repositories or directories that contain specific model training jobs, data ingestion pipelines, or tenant-specific configurations.

Casuistry: Deployment Models

Depending on the trust level, regulations, and infrastructure capabilities of the clinical partner, ColabBio supports several multi-tenant models:

Model A: Logical Isolation (Shared Cluster)

Multiple tenants share a single, massive Kubernetes cluster (e.g., a centralized cloud GKE cluster).

• Isolation: Handled via Kubernetes Namespaces, Network Policies, and dedicated Persistent Volumes (PVs).
• Use Case: A single hospital network managing multiple internal research departments, or a cloud SaaS offering for smaller clinics.

Model B: Physical Edge Isolation (Federated Clusters)

Each tenant hosts their own physical MicroK8s cluster inside their own firewall (Hospital Datacenter).

• Isolation: Air-gapped or heavily firewalled physical networks.
• Federation: The tenant’s local Federated Learning Node securely reaches out over TLS to a central ColabBio aggregator to exchange model weights. Raw OMOP or DICOM data never leaves the hospital’s edge.
• Use Case: Cross-institutional research (e.g., Hospital A in Spain and Hospital B in Germany collaborating on an ML model without moving patient data).

Security & Access Control

Traffic destined for a specific tenant is intercepted at the global Ingress layer. The global Identity and Access Management (IAM) system validates the user’s OIDC token. If the user does not have RBAC permissions for that specific tenant’s namespace, the API request is rejected before it ever reaches the tenant’s isolated network segment.