Trust Center

Who can reach a record, and how that is proven on every request.

• Server-side authentication on every account data route

  Authentication is self-hosted in our own database. Routes serving account data authenticate server-side and never trust a client assertion. There is exactly one deliberately public surface — the emergency card share link — and it is described below rather than left for you to find.

• The one public surface is owner-created, scoped, and revocable

  The emergency card share link is unauthenticated by design, so emergency clinicians can open it from a printed QR code without an account. The 256-bit token in the URL is the credential: only its SHA-256 hash is stored, a revoked link is indistinguishable from one that never existed, views are rate-limited and audit-logged before any data is served, and the owner chooses section by section what appears. No file is ever reachable through it.

• Resource ownership enforced on every read and write

  Clinics, patients, consultations, files, and chat sessions are ownership-checked server-side before any record is returned or modified.

• Plan and feature gating enforced server-side

  Client-side interface state is never treated as a permission boundary. Every gate is re-checked on the server.

• Time-limited, revocable sharing grants

  Record sharing is scoped, expiring, and revocable, with expiration and revocation enforced at access time rather than at issue time.

• Database-backed authentication rate limiting

  Sign-in and share-attempt rate limits are enforced against durable state, not per-instance memory.

How records and files are stored, validated, and kept separated.

• Private object storage with short-lived signed access

  Uploaded files are stored outside the application database in private storage and served only through ownership-checked, expiring signed URLs. No file is publicly addressable.

• Encryption in transit and at rest

  TLS in transit, with HSTS enforced. Health records and stored files are encrypted at rest across both the database and object storage.

• Upload format validation before storage

  Every upload is checked against its full file body rather than its declared type or extension, and unsupported or active content is rejected before it is stored. This is format validation, not malware scanning.

• Per-file size ceilings and content hashing

  Every upload carries a recorded byte size and SHA-256 content hash, enforced against a plan ceiling.

• Retrieval scoped to the requesting user

  AI retrieval over your documents is scoped to your own vault or an explicitly authorized clinic patient. Retrieval cannot cross an ownership boundary.

• Deleted and quarantined records excluded everywhere

  Records that are deleted, quarantined, or unauthorized are excluded from reads, search, AI retrieval, and every sharing surface — not merely hidden in the interface.

What we can prove after the fact about who accessed what.

• Append-only audit log enforced by the database

  Update and delete on the audit trail are blocked by database triggers, not by application convention. The application cannot rewrite its own history.

• Single audit write path, with failures propagated

  All audit writes pass through one helper that stamps request context. A failed audit write fails the operation, because an access we cannot record is an access we do not permit.

• Actor identity survives account deletion

  Audit records retain a pseudonymous actor snapshot after a user is erased, so accountability outlives the account without retaining the identity.

• Complete grant lifecycle history

  Creation, revocation, and rate-limited share attempts are recorded across every sharing type, so who was given access to what, by whom, and when it was withdrawn reconstructs fully.

Design choices that keep sensitive data out of places it should never reach.

• Health content is structurally excluded from logs

  A dedicated logging helper carries identifiers, statuses, and counts only. Health content never enters log lines, metric labels, error messages, or URLs.

• Patient records carry no direct identifiers

  The clinical patient record has no name, date of birth, email, or phone columns. It was designed without them rather than having them stripped later.

• Model training is opt-in, de-identified, and human-reviewed

  No record becomes training-eligible without explicit consent, de-identification, and approval by a human reviewer. Nothing collected before consent is ever included.

• Consent recorded with version, scope, and timestamp

  Every consent decision is versioned, so an agreement always maps to the exact text that was shown. Materially changed terms require a fresh decision.

• Outbound reference lookups gated in code

  Public drug and lab reference services receive only bare catalogue codes and canonical names. The gate is enforced at the point of egress and refuses rather than guessing.

Baseline hardening at the transport, browser, and schema layers.

• Enforced security response headers

  Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, frame-ancestors deny, Referrer-Policy, and Permissions-Policy are set on application responses.

• Database-level integrity constraints

  CHECK constraints protect plans, roles, file types, chat modes, message roles, and confidence ranges. Partial unique indexes prevent duplicate active grants.

• Timezone-safe timestamps

  Application timestamps are stored with timezone, so expiry and audit comparisons cannot drift with deployment region or daylight saving.

What you can do with your own record, without asking us.

• Self-serve full export, on every plan

  One click in Settings exports your profile, conversations, health observations, timeline notes, file metadata, and consent history as a single JSON document. Files are separately downloadable from the Vault.

• Self-serve account deletion

  Deletion is confirmed by an emailed code and takes effect after a 30-day grace window, after which stored file bytes, records, chunks, and embeddings are destroyed. Grants you hold over other people's records are revoked first.

• Individual record deletion with a defined destruction window

  Files, notes, and conversations you delete leave every surface immediately and are permanently destroyed within 30 days. Temporary chats are fully deleted within 24 hours.