Consent is enforced in the database, not an app setting.
Names, roles and read-paths are database rules. No checkbox UI can weaken what the database refuses.
The patient grants access
Access is granted scope by scope — diagnostics, pharmacy, referrals — and revocable at any time. The grant is the patient's, not the clinic's.
Denial always wins
A denied scope fails closed. No fallback, no override, no silent default-open. The refusal is written to the ledger like every other event.
Every read is audited
The ledger is append-only and hash-linked: each entry commits to the one before it. A removed or altered record breaks the chain on inspection.
Try refusing.
This is the whole product in one gesture. Flip a switch. Watch the ledger. Deny everything — nothing breaks, because denial is a first-class state, not an error.
interactive · no data leaves this page
Access scopes
Chain
append-onlyA read request arrives.
A clinic, lab, or pharmacy asks for a scope. The request names the actor, the scope, and the moment.
The gate checks the grant.
The database matches the request against the patient's declared scopes. Fail-closed: a check that cannot complete is a denial.
Deny ink writes the line.
The refusal lands in the append-only ledger with the same weight as a grant. Nothing is overwritten, nothing is quietly dropped.
Named as unshipped, not claimed: scheduling, billing, messaging, analytics and the patient app come next. Nothing on this page is a promise about dates.
Ask us anything.
Diligence readers get the same answer clinics do: the mechanism, the rule, the receipt.
Ask us anythingyour patient data never touches this page