Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
Audit Logging for HIPAA Compliance
Audit logging is a core requirement of the HIPAA Security Rule. Every access, modification, and disclosure of PHI must be logged, retained, and protected from tampering.- Understand HIPAA audit requirements
- Design comprehensive audit log schemas
- Implement tamper-proof logging
- Build real-time alerting systems
- Meet retention and review requirements
Why Audit Logging Matters
Audit Log Schema Design
Core Audit Event Schema
Implementing the Audit Logger
Core Audit Service
Database Schema
FastAPI Integration
Audit Middleware
Log Integrity Verification
Verification Service
Real-time Alerting
Alert Configuration
Accounting of Disclosures
HIPAA requires providing patients with an accounting of disclosures of their PHI:Retention and Archival
Key Takeaways
Log Everything
Tamper-Proof
Real-time Alerts
Retain 6+ Years
Practice Exercise
Next Steps
PDPL Compliance
Encryption
Interview Deep-Dive
An OCR auditor asks you to demonstrate that your audit logs have not been tampered with over the past 3 years. How does your system prove this?
An OCR auditor asks you to demonstrate that your audit logs have not been tampered with over the past 3 years. How does your system prove this?
- The foundation is a hash chain (similar to a blockchain). Each audit log entry includes a SHA-256 hash of the previous entry, creating a cryptographic chain. If any entry in the chain is modified, inserted, or deleted, the hash chain breaks and verification fails. This gives you tamper-evidence, not just tamper-resistance.
- On top of the hash chain, each entry is digitally signed with an RSA or Ed25519 private key held in an HSM. The signing key never leaves the HSM, so even a database administrator cannot forge valid signatures. The auditor can verify any entry independently using the corresponding public key.
- We run automated daily verification that walks the entire chain from the previous day and stores a checkpoint record (timestamp, last verified event ID, computed hash, verification result). These checkpoints create a secondary integrity trail — if someone tampered with logs and re-computed hashes, the checkpoint hashes from before the tampering would not match.
- For the auditor, I would demonstrate: (1) run the chain verification tool against the requested time range and show zero integrity errors, (2) show the stored daily checkpoint records proving continuous verification, (3) show the HSM audit trail proving the signing key was never exported, (4) show the database triggers that prevent UPDATE and DELETE operations on the audit table.
- The append-only database design is the final layer: PostgreSQL triggers raise exceptions on any UPDATE or DELETE against the audit_logs table. The auditor role has SELECT-only permissions.
Design an audit logging strategy for a healthcare application that processes 50,000 patient record accesses per day. What do you log, how do you store it, and how do you keep it queryable for 6+ years?
Design an audit logging strategy for a healthcare application that processes 50,000 patient record accesses per day. What do you log, how do you store it, and how do you keep it queryable for 6+ years?
- What to log: every PHI access event with the full W5 — who (actor ID, role, IP, session), what (resource type, resource ID, patient ID, specific fields accessed), when (UTC timestamp with millisecond precision), where (service name, request ID, correlation ID), and why (action type, outcome, reason for access). For modifications, capture old and new values. For disclosures, capture the recipient and legal basis.
- Storage architecture: use a hot/warm/cold tiering strategy. Hot tier (0-90 days): PostgreSQL with partitioned tables (partition by month), full indexing on actor ID, patient ID, event type, and timestamp. This handles real-time queries, alerting, and active investigations. Warm tier (90 days to 2 years): compress and move to Elasticsearch for full-text search and dashboarding. Reduce indexing to save costs but maintain query capability. Cold tier (2-7 years): archive to S3 Glacier or similar, encrypted and compressed in Parquet format. Retrieval takes hours but costs pennies per GB.
- At 50,000 events per day, you are looking at roughly 18 million events per year. Over 7 years, that is approximately 125 million records. In PostgreSQL with JSONB columns, each event is roughly 2-4 KB, so the hot tier holds about 4.5 GB per quarter — very manageable. The cold archive over 7 years is around 250-500 GB compressed.
- Performance: use async batch writing (buffer events in memory, flush every 5 seconds or at 100 events, whichever comes first) to avoid impacting application latency. Partition tables by date for fast range queries and efficient archival of old partitions.
- Retention policy: automated monthly job detaches old partitions from hot storage, exports to encrypted Parquet, uploads to Glacier, stores an archive reference, then drops the hot partition. The archive reference enables retrieval if needed for an investigation or audit.
A nurse calls the help desk and says she accessed a patient record she should not have seen. She realized immediately and closed it. Is this a breach? What happens next?
A nurse calls the help desk and says she accessed a patient record she should not have seen. She realized immediately and closed it. Is this a breach? What happens next?
- First, the good news: this likely falls under one of the three HIPAA breach exceptions. Exception one is “unintentional acquisition by a workforce member acting in good faith and within the scope of authority, provided the information is not further used or disclosed.” If the nurse accidentally clicked the wrong patient chart, realized immediately, and closed it without copying, sharing, or acting on the information, this exception likely applies.
- However, you cannot just wave it away. You must still document the incident, conduct the four-factor risk assessment, and retain that documentation. The assessment would evaluate: (1) Nature of PHI — what fields did the nurse see? Name and demographics are lower risk than HIV status or mental health notes. (2) Who accessed it — an authorized healthcare worker bound by HIPAA is lower risk than an external party. (3) Was the PHI actually acquired or viewed — brief inadvertent viewing with immediate closure suggests low acquisition. (4) Mitigation — the nurse self-reported, which is strong mitigation.
- The audit log is critical here. It should show exactly when the nurse accessed the record, how long the session lasted (seconds, not minutes), which specific fields were displayed, and that no export, print, or copy operations occurred. This forensic evidence supports the exception determination.
- Even if it is not a reportable breach, log it as a security incident, review whether access controls should be tighter (why could this nurse see a patient outside her unit?), and use it as a training opportunity. The nurse’s self-reporting behavior is exactly what you want in your organization’s security culture — do not punish it.
Your SIEM fires an alert: a single physician account accessed 847 patient records in the last hour, compared to a baseline of 15-20 per hour. Walk me through your response.
Your SIEM fires an alert: a single physician account accessed 847 patient records in the last hour, compared to a baseline of 15-20 per hour. Walk me through your response.
- This is a classic anomaly detection alert and it could be legitimate or catastrophic. The first step is triage, not containment — you need context before cutting off a physician who might be in the middle of patient care.
- Immediate investigation (first 15 minutes): pull the audit logs for this account and examine the access pattern. Are the 847 records in the same department? Are they sequential (suggesting automated scraping) or scattered? What specific actions were performed — read-only views, exports, prints, modifications? Check the source IP and user agent — is this the physician’s normal workstation or an unusual device? Check whether MFA was used for this session.
- Scenario A (legitimate): the physician is running a quality improvement report, reviewing a panel of patients before a department meeting, or the account is used by a clinical system doing batch processing. In this case, refine your alerting threshold for this specific use case and document it.
- Scenario B (compromised account): the IP is from an unusual location, the access pattern is automated (regular intervals, sequential record IDs), or the physician is not scheduled to work today. Immediately disable the session (not the account — you might lock out the real physician), force re-authentication with MFA, and contain by blocking the source IP. Preserve all logs as forensic evidence.
- Scenario C (insider threat): the physician is deliberately accessing records beyond their treatment scope (snooping on celebrities, looking up personal contacts, or exfiltrating data before leaving the organization). This requires coordinating with the privacy officer, legal, and HR before confronting the physician.
- Regardless of scenario, document the alert, the investigation steps, the findings, and the resolution. If Scenario B or C, initiate the formal incident response process and assess whether a breach has occurred.