Plain words about how the chart is protected.

Every clinical query runs through a single per-request choke point that checks your active membership in the clinic, then scopes the query to that clinic. There is no path to a record that reads across clinics.

A request for a clinic you do not belong to is refused with a 403, and the refusal is written to that clinic's audit log. Malformed record identifiers are rejected before the database is ever touched.

Clinical reads and writes are recorded to an append-only log, one chain per clinic. Each entry stores the SHA-256 hash of the entry before it, so the whole chain can be recomputed and checked. Change or remove any row and the recomputation stops matching from that point on. This makes tampering evident.

In production a failed audit write does not fail silently. The request fails instead, so a clinical action cannot succeed unlogged.

Tamper-evident is not the same as tamper-proof. The chain proves that records were not altered after the fact; it does not by itself encrypt their contents.

This app never sees your password. Authentication happens in Docuity ID, with passkeys preferred. Sessions are cryptographically signed tokens paired with a server-side revocation check, so signing out takes effect right away.

Every state-changing request is checked against the app's exact origin, and sensitive actions such as signing a note carry an additional per-form token. If the revocation store cannot be reached, the app fails closed rather than guessing.

All traffic is served over TLS. Chart contents live in your PostgreSQL database. Their protection at rest is whatever your database and disk encryption provide in your deployment. Docuity EHR does not add field-level encryption on top of clinical data.

We call this out on purpose. If you run the hosted instance or host it yourself, disk and database encryption are a deployment decision, and an honest posture means naming it rather than implying more.