Trust is not a logo on a footer. It is the answer to a specific question a compliance officer is going to ask: if a regulator subpoenas the activity history for a single resident on a single day, can you produce a complete, immutable record of every system action and every human action, with the prompts, responses, and citations all linked?
If the answer involves grep, screenshots, or "we'll have to ask the vendor," the answer is no.
What an audit log entry actually contains
For every meaningful action — a chart review run, a recommendation drafted, a pharmacist edit, a facility notification — a useful audit record carries:
- action — a stable identifier like
synthesis.runorrecommendation.accepted - actor — the authenticated user (or service identity), tenant scope, and role
- resource — the record acted on, identified by stable IDs (never re-derived after the fact)
- prompt_hash — a SHA of the exact prompt sent to the model, so the prompt can be reproduced
- citation list — the source documents and rule IDs the synthesis drew on
- model + version — Anthropic model ID and any tenant-specific addendum version
- outcome — accepted, edited (with diff), rejected (with reason), or pending
- timestamp — UTC, monotonic, written server-side
The diff matters. When a pharmacist accepts an AI-drafted recommendation with edits, the saved record captures both the draft and the final, so a reviewer can see what the clinician changed and why. This is what proves the human stayed in the loop.
The BAA chain
HIPAA does not care that you use AI. It cares that PHI flows only through entities bound by a Business Associate Agreement, and that the chain is unbroken from the front-end through every backend service that touches the data.
For an AI-augmented clinical workflow, the chain typically includes:
- The application vendor — your direct BAA partner
- The model provider — when calling Anthropic, the BAA needs to cover the Claude inference path
- The cloud inference layer — AWS Bedrock provides BAA-covered access to Anthropic models, which is the path we use
- The database — Supabase Pro tier with BAA, with PHI confined to the Postgres layer
- The hosting layer — Render Pro with BAA covers the application servers and worker processes
Every one of these BAAs is on file and reviewable. There is no link in the chain that operates on PHI without a signed agreement.
Tenant-scoped row-level security
A multi-tenant clinical SaaS has exactly one acceptable answer to the question "what stops one customer from seeing another customer's data?" That answer is row-level security enforced at the database, not at the application layer.
Application-layer filters are a single bug away from a cross-tenant leak. Database RLS policies, written against authenticated tenant claims, make the leak structurally impossible at the data plane. A missing .eq("tenant_id", ...) in application code becomes a denied query at Postgres rather than a privacy incident.
The verification matters as much as the policy. Writing an RLS rule and trusting it is not the same as proving it.
Our cross-tenant pen-test suite runs 47 probes on every CI build. Each probe spins up two tenants, writes data as tenant A, then attempts to read or mutate that data as tenant B across every PHI-bearing surface — bundles, reviews, recommendations, notifications, audit log, synthesis history, attachments, the lot. A failing probe blocks merge.
What "immutable" really means
An audit log that the application can delete from is not an audit log. Two implementation choices keep ours honest:
- Append-only writes from application code. The application has INSERT-only permission on the audit table. UPDATE and DELETE require a service role that no application path holds.
- Database-level time-stamping. Timestamps are set by the database
default now()clause, not by the client. The client cannot post-date.
For high-acuity tables (recommendations, edits, send events) we additionally maintain a chained hash where each row references the prior row's hash, so any tampering is visible at row-replay time.
What a compliance officer should ask a vendor
If you are evaluating an AI-augmented clinical tool, the questions that actually surface the quality of the trail are:
- Show me the audit log for one resident, one day. Include actor, action, resource ID, model invoked, and citation list.
- Show me the BAA between you and your model inference provider.
- Show me your cross-tenant test suite output for the most recent CI build.
- Show me how I revoke a user and confirm every active session is invalidated.
- Show me how an exported audit report would look for a state inspector.
A vendor that can answer those five live, on a screen-share, in under ten minutes, has done the work. A vendor that has to come back to you with a written response has not.
The shape of trust
The auditability of a HIPAA-grade system is not a sales document. It is the immediate readability of its action history. When the questions come — and they will come — the system either has the answers in its own data, or it does not. There is no third option.