HIPAA, reviewed in the pull request.
The HIPAA Security Rule splits into administrative, physical, and technical safeguards. The technical safeguards, in 45 CFR 164.312, are the ones a codebase implements: access control, encryption, audit controls, integrity, authentication, transmission security. For any system that touches electronic protected health information, those are decided by the change in front of you.
ePHI does not announce itself in a diff.
The hard part of HIPAA in code is that protected health information looks like any other data in a payload. A change that adds a field, a log, or an integration can quietly start moving ePHI through a path that was never built to safeguard it, and nothing in the code flags that the data is now regulated. heygrc reads the change against the technical safeguards and names the one it touches, so the safeguard is checked at the moment ePHI starts flowing somewhere new, not after a breach.
The technical safeguards a review can actually catch.
Each row is a real CFR reference and the kind of change that trips it. heygrc cites the safeguard on the finding, not a vague PHI note.
- 164.312(a)(1)access control
A role broadens, an authorization check is dropped, or a new path reaches electronic protected health information (ePHI) that it should not.
- 164.312(a)(2)(iv)encryption of stored ePHI
An encryption-at-rest setting on a store of ePHI is removed or downgraded, or ePHI lands in a new store with no encryption configured.
- 164.312(b)audit controls
A change removes or narrows the recording of access to, or activity on, systems that hold ePHI, weakening the audit trail the safeguard expects.
- 164.312(c)(1)integrity
A checksum, validation, or tamper check that protected ePHI from improper alteration or destruction is removed.
- 164.312(d)person or entity authentication
An authentication step is skipped on a path to ePHI, or a session or service identity is weakened so the system can no longer verify who is acting.
- 164.312(e)(1)transmission security
ePHI starts moving over a channel that is no longer encrypted: a TLS floor drops, verification is disabled, or an internal hop falls back to plain HTTP.
A removed audit hook that weakens 164.312(b).
A pull request refactors the record viewer and drops the call that logged who opened a patient record. The access still works; it just stops being recorded.
async function viewRecord(user: User, patientId: string) {
- await audit.record("phi.view", { user: user.id, patientId }) return records.get(patientId)
}This stops recording access to a patient record. 164.312(b) (audit controls) expects systems holding ePHI to record activity that uses it, and access logs are how an investigation later reconstructs who saw what. Keep the audit call, or route it through the new code path so the record of access survives the refactor.
A review, not a HIPAA program.
heygrc flags changes that touch a HIPAA technical safeguard and cites the CFR reference so the fix happens in the pull request. It does not perform your risk analysis, sign a Business Associate Agreement, or cover the administrative and physical safeguards the rule also requires. It catches the change early so a technical safeguard holds in code review instead of surfacing after an incident. heygrc is in early access.