Data Isolation
How the platform ensures one clinic can never see another clinic's data.
The Problem
In a multi-tenant platform — where many clinics share the same infrastructure — the biggest risk is data leaking between clinics. A bug in the code, a misconfigured query, or an authorization mistake could theoretically expose one clinic's patient records to another.
How We Solve It
Data isolation is enforced at the database level, not just the application level. This is called Row-Level Security (RLS).
Every piece of data in the system belongs to an organization (clinic). When a specialist at Clinic A logs in, every database query they trigger is automatically filtered to Clinic A's data only — by the database itself.
What this means in practice
- A bug in application code cannot accidentally expose Clinic B's data to Clinic A. The database rejects any query that crosses boundaries, regardless of what the application asks for.
- There is no "super-query" that bypasses isolation. Even the application developers cannot accidentally write code that crosses clinic boundaries during normal operation.
- Auditors can verify isolation directly. The security policies are defined in the database schema — they can be inspected and tested independently of the application code.
How it works
When a user logs in, three pieces of information are set on their database connection:
- Who they are — their user identity
- Which clinic they belong to — their organization
- What role they have — admin, specialist, customer service, etc.
Every table in the database has a policy that says: "Only return rows where the organization matches the current user's organization." This policy is enforced by the database engine on every query — SELECT, INSERT, UPDATE, and DELETE.
Portable patient profiles
Patient profiles are the one exception to strict clinic isolation. A patient's basic personal information (name, date of birth, allergies) is portable — it belongs to the patient, not to any clinic. However:
- A clinic can only see a patient's full profile after the patient signs a profile-sharing consent for that specific clinic
- Clinical records (appointments, forms, treatment plans, reports) are always isolated — they never cross clinic boundaries
- Consent records are per-clinic — signing at Clinic A does not share with Clinic B
Additional Protections
| Layer | What It Does |
|---|---|
| Database-level isolation (RLS) | Enforces clinic boundaries on every query |
| Application-level authorization (RBAC) | Controls what each role can do within their clinic |
| Audit logging | Records every data access and mutation |
| Encryption at rest | Sensitive fields encrypted even within the database |
| Network isolation | Database not exposed to the internet — only accessible from the application |
For developers
Technical details — RLS policy definitions, session variable setup, dual connection pool architecture, and RBAC middleware — are available in the RLS Policies and RBAC Permissions reference.