Your patients' data isn't here. It never was.

HIPAA governs protected health information: data that identifies a person and relates to their care. Your EHR is full of it. MedAligna holds none of it, and the reason is structural rather than a matter of policy: there is nowhere in this product to put a patient.

We schedule staff, not patients. What we store is employment data: who works Tuesday night, whose licence expires in March, how many hours someone worked last week. Employment records are not PHI under HIPAA, even when the employer is a hospital. The closest we come is a census count: the grid knows there are eighteen patients on the unit tonight, because that is what a nurse-to-patient ratio is computed against. Eighteen is a number. It identifies nobody.

Which means the honest answer to “what happens if you get breached?” is the strongest one available: your patients are not in the blast radius, because their data was never here. An attacker who took everything we hold would have a staff roster. No badge on a website gets you that, and unlike a badge, it is not a claim anyone can argue with; you can verify it yourself from the table below.

Some deployments are different: home-care client records are the usual case, since a client's name and address tied to receipt of care is protected health information. If that is you, talk to us and we will walk you through exactly how it is handled.

Every tenant table in MedAligna carries the organisation it belongs to, and every one of them has a row-level security policy attached in Postgres. The policy compares that organisation against the memberships of whoever is authenticated, and it is evaluated by the database on every read and every write. Not by a middleware layer, not by an ORM scope, not by a WHERE clause a developer has to remember on a Friday.

The distinction matters because of how multi-tenant data actually leaks. Almost nobody is breached by a cryptographic failure; they are breached because one query out of four thousand forgot its filter, and that query returned everyone's rows to the wrong account for eight months before anybody noticed. Under row-level security, the forgetful query is the safe failure: a select with no organisation filter returns zero rows, not every row. The bug shows up as an empty screen during development rather than as a disclosure in production.

This is tested on every commit, and the test is written adversarially rather than hopefully. It authenticates as one organisation's administrator, queries another organisation's staff table with no filter whatsoever (the exact query a hostile or incompetent client would send) and asserts that the result is empty. If someone adds a new table and forgets its policy, that test is what fails, and it fails before the code ships rather than afterwards.

The same boundary holds for the contested writes that make scheduling interesting. When two nurses tap “claim” on the last open night in the same second, the decision is made inside the database under a row lock, with eligibility re-checked while the lock is held. There is no second write path around it. That is a correctness property rather than a security one, but it comes from the same principle: the rules live where the data lives, because that is the only place they cannot be bypassed by the next feature.

Credentials live in a wallet attached to the person rather than to the employer, and the permission is asymmetric on purpose: an employer can read a credential record and cannot edit or delete it. That is enforced by the same row-level policies as everything else, which means it is not a promise about our intentions: a manager who is one nurse short at five in the morning cannot reach into a record and move an expiry date, however much she would like to. Only the person whose licence it is can change what it says.

The documents themselves (the scanned licence, the BLS card) are not on a public URL waiting to be guessed. They sit in private storage and are reachable only through short-lived signed links issued to someone who has already been authorised to see them. And on the one class of record that genuinely is protected health information, home-care client records, every read is logged separately, not merely every change. Access logging that only records writes answers the wrong question: the interesting event is usually somebody looking.