The HIPAA Audit Log Schema We Use in Every Healthcare Project

Most engineering teams treat HIPAA audit logging as a compliance checkbox. They add a log table, write a row every time someone touches a patient record, and consider it done. This is the approach that fails a compliance audit — or worse, fails in production when someone needs to reconstruct exactly what happened to a specific patient record and by whom. Audit logging in a real HIPAA system is not a simple append-only table. It is an architectural decision that touches your data model, your API layer, and your infrastructure. Here is what we actually build.

What the HIPAA Security Rule requires from your audit controls

The Security Rule requires that covered entities implement "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." The key word is activity — not just reads and writes, but the full lifecycle of every interaction with PHI: who accessed it, what they did, from what system, at what time, and what the record contained at that moment in time.

This translates to five requirements your audit log must satisfy: completeness (every PHI access is logged — no gaps), immutability (audit records cannot be modified or deleted), queryability (you can reconstruct the full history of any patient record or user session), integrity (the logs themselves have not been tampered with), and retention (audit records are kept for at least six years from creation or last effective date).

The schema we use in production

Our baseline audit log table, in MySQL:

The patient_id column is critical and frequently overlooked. When a user accesses a document that belongs to a patient, you need to be able to answer "what PHI belonging to patient X was accessed?" — not just "what documents were accessed?" Without an explicit patient_id on every audit row, this query becomes a join-heavy reconstruction that breaks down at scale.

The access patterns your audit log must support

Build your indexes around these queries, because these are what a compliance officer or auditor will ask for: all actions by a specific user in a date range; all accesses to a specific patient's records; all exports of PHI in the last 30 days; all failed authentication attempts from a specific IP; the complete state history of a specific resource. Your composite indexes should be: (actor_id, event_at), (patient_id, event_at), (resource_type, resource_id, event_at), and (action, event_at).

Immutability and retention

The audit log table must be append-only. No UPDATE, no DELETE — enforced at the database user level by granting only INSERT and SELECT to the application's audit log writer. Retention enforcement should be a separate process that archives rows older than six years to cold storage (S3 Glacier or equivalent) rather than deleting them. The archive itself needs to be verifiable — we include the checksum column in the export and store a manifest hash of each archived batch.

The implementation pattern that works at scale

Write audit events asynchronously via an internal event bus — synchronous audit writes in the request path add latency to every PHI operation and create a single point of failure. The application publishes an audit event to a queue; a dedicated audit writer consumes the queue and writes to the database. Use a dead-letter queue for failed writes and alert on queue depth — a growing backlog means audit records are not being written, which is a compliance incident.