Security & privacy
The boring details
that make this trustworthy.
Docuity holds care records. That means the security story has to be plain, specific, and the same answer every time. Here is exactly what we do.
01 · Access
Two-key access, every session.
Every chart unlocks with two independent things: the patient code and the caregiver's identity.
The patient code is held by the patient and only the patient. It is hashed with Argon2id + a server-side HMAC pepper before storage. A caregiver who knows your name and birthdate cannot guess their way in — without the code, the chart stays closed.
The caregiver identifies themselves with their own credential — a passkey, an authenticator code, or a PIN — registered separately from any patient chart. Their account does not grant chart access on its own.
The two keys are checked on every chart open. The patient can rotate their code at any time, instantly revoking everyone who had access.
02 · Credentials
Passkey-first, with sensible fallbacks.
Passkey (WebAuthn)
Phishing-resistant, device-bound. Built on @simplewebauthn — origin and challenge verified server-side. Multiple passkeys per account, each with a label so you know what 'work-laptop' means.
TOTP code
A standard 6-digit authenticator code. The shared secret is encrypted at rest with AES-256-GCM; the QR code is shown exactly once at enrollment.
Numeric PIN
For users without authenticator apps or hardware passkeys. PIN is hashed with Argon2id; the same lockout policy applies as for the other factors.
The user chooses which factors they enrol. We require at least one survivor on the account at all times — you cannot delete your only credential and lock yourself out.
03 · Step-up
A fresh credential check before destructive changes.
A login session is not enough to make irreversible changes. Before we will let you remove a passkey, rotate a patient code, disable TOTP, or export an entire chart, you re-present a credential.
The credential check has a short freshness window. Once it expires, you step up again.
Step-up required for
- Removing a passkey, TOTP secret, or PIN
- Rotating a patient chart code
- Generating a clinical PDF or Excel export
- Granting a caregiver an admin role
- Bulk-deleting notes or attachments
04 · Encryption
In transit, at rest, and at the lookup.
In transit
TLS-1.3
HTTPS-only deployment. Cookies are HttpOnly + SameSite=Lax + Secure in production.
At rest
AES-256-GCM
TOTP secrets, recovery material, and other sensitive blobs are encrypted with an at-rest key kept outside the database.
Lookup
HMAC-SHA-256 pepper
User IDs and patient codes are HMACed with a server-side pepper before lookup — so a leaked DB dump cannot be brute-forced offline.
All hashed credentials (patient codes, PINs, invite tokens) use argon2id with the library defaults — memory-hard, side-channel resistant. The pepper and the at-rest key live in environment configuration, not the database, so stealing the DB is not enough to recover credentials.
05 · Audit
Every chart access leaves a trace.
Every login, every chart open, every export, every credential change writes a row to the access log: who, what, when, and where from (IP + user agent). The log is append-only from the app's perspective.
Patients can see who has accessed their chart and when. Operators can export the log for compliance reviews. Suspicious patterns (failed login bursts, access from unfamiliar IPs) are visible at a glance.
What we log
- Successful and failed logins (with method)
- Chart opens, scoped to patient + role + intent
- Note creation, edit, and deletion
- Credential add & remove, code rotation
- PDF and Excel exports
- AI calls — prompts and outputs are kept for explainability
06 · AI
What the AI sees, and what it doesn't.
The AI (Anthropic's Claude) receives only the chart fragments needed for the specific task — the photo for extraction, the day's notes for the daily summary, the recent vitals for trend analysis.
Inputs and outputs are stored alongside the resulting note, so every AI decision is traceable.
Guarantees
- No AI training: prompts go through the Anthropic API with no training opt-in.
- No cross-patient context: each call is scoped to a single chart.
- No hidden recommendations: every flag links back to the notes that produced it.
- No silent failures: AI errors surface in the UI rather than being swallowed.
07 · Scope
Self-hosted by design — and what that means for compliance.
Docuity is designed to hold real care records. The encryption, two-key access, step-up auth, and audit logging described above are the production security posture — not a placeholder.
The default deployment model is self-hosting. The chart lives on your hardware, on your network, under your operational control. We don't see the data, don't aggregate it, and don't phone home.
Because we don't operate the chart on your behalf, docuity is not a HIPAA covered entity or business associate. SOC 2 and HITRUST are organizational audits of an operator, not features of the software — if your buyer requires them, the operator (you) commissions them on your deployment, exactly as for any other self-hosted system.
Want help thinking through your threat model before you deploy? Or found something concerning? Email medic@docuity.com — security reports get a same-day reply.
Ready when you are
Open a chart and try the access model.
The fastest way to understand the two-key model is to walk a chart through registration, invite a caregiver, and rotate the code.