HIPAA Compliance rules

Handlers must verify the requester’s role and a valid consent/relationship (e.g., care team assignment) before disclosing ePHI; include Purpose-Of-Use in the decision and audit the outcome.

Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.

Any PR that adds or modifies telemetry/analytics must prove that no PHI leaves the boundary. Use irreversible tokenization or hashing (HMAC with secret salt) for identifiers and document the data dictionary.

Never write Protected Health Information (PHI/ePHI) to logs. Redact fields like name, SSN, MRN, DOB, address, diagnoses, and lab results; store only non-identifying metadata and a stable request trace id. If logging is required for troubleshooting, replace values with consistent tokens and record access separately in the audit log.

When reading from PHI tables, project only authorized fields and avoid SELECT *. Implement whitelists per role and document them. Reject requests lacking a Purpose-Of-Use justification.

Applications serving ePHI must require HTTPS, disable insecure ciphers, and enable HSTS with preload and includeSubDomains. Reject cleartext HTTP requests.

Emergency access to ePHI must go through a dedicated break_glass path that requires reason, approver, limited time window, and automatic post-incident review. The PR must include changes to the audit log schema and runbook.

Access tokens, HMAC salts, and KMS keys for PHI flows must come from a secret manager or encrypted credentials store; forbid committing secrets or .env files to the repo.

Write ePHI backups to storage with server-side encryption (SSE-KMS) and least-privilege access; disallow public ACLs and cross-account access without a BAA. Record the KMS key id in metadata.

Endpoints under /admin or privileged routes that can view or export ePHI must enforce multi-factor authentication and recent re-auth (e.g., within 15 minutes).

For any handler that reads or writes ePHI, write an append-only audit record with user id, patient id, action (READ_PHI/WRITE_PHI), purpose-of-use, timestamp, and request id. Prevent deletion or mutation of audit entries.

Changes that create new ePHI stores must also include retention configuration and a scheduled purge job aligned to policy (e.g., 6 years). Document tables/collections covered and add tests for TTL behavior.