Multi-tenant, and the tenants have relationships

Multi-tenant usually means isolation: each customer in a sealed box. Diagnostic data does not work that way. A laboratory reports to a practice, the practice consults a specialist at another organization, a delegated biller codes the case, a firm holds a lien on the receivable, and the patient stands outside all of them holding a legal right to the whole thing. The interesting part of the model is not the walls. It is the doors.

Four layers, not one

Organization

The contracting entity. A laboratory, a practice group, a firm, a management company. Owns the agreement and the data classes in scope.

Sub-organization

Location, division, or department. Real, addressable, and permissioned independently, because a practice with eleven sites does not want one worklist and a pathology group with two divisions does not want shared sign-out.

Role

What a member can do inside their own organization. Coarse enough to administer, specific enough that a coder is not a clinician and a front-desk user cannot open a molecular panel.

Grant

An edge that crosses a tenant boundary, attached to a case or a matter, with an expiry. Grants are the entire cross-organization access story. There is no standing permission to look at another tenant's data.

Enforcement has a floor

Application code decides what to show. The database decides what can be read at all. Both are necessary and only the second one holds when the application has a bug, which it eventually will.

• Row-level policy in the database keyed to tenant and grant, evaluated on every query rather than assembled in application logic.
• A policy decision point for attribute and relationship checks that are too expressive for a table of roles, with decisions logged.
• Deny by default. A new data class is invisible until a rule releases it, which means the failure mode of forgetting to write a rule is a support ticket rather than a breach.
• No shared administrative account has read access to clinical data. Support access is a break-glass event.

Break-glass

There are real emergencies: a critical result routed to a tenant that cannot be reached, an integration failure during a sign-out backlog, a patient in an emergency department whose prior pathology is behind a grant that expired. Pretending otherwise produces shared passwords.

1. The user states a reason from a fixed list plus free text. Access is not granted against an empty reason field.
2. Access is granted for a bounded window, scoped as narrowly as the situation allows.
3. The affected tenant's administrator is notified when it happens, not in a monthly report.
4. Every break-glass event is reviewed. A user with a pattern of them has a workflow problem, a training problem, or a permissions problem, and all three are worth finding.

The audit record is a product surface

Access logging is usually built for a hypothetical future investigator. Ours is built to be read: a patient can see who accessed their record, an administrator can see what left their tenant, and a firm can see exactly what was produced on a matter and when. The same record answers an accounting of disclosures request without a special project.