heygrc
HIPAA integrity of ePHI in code

Patient data that has not been quietly changed.

164.312(c)(1) is the HIPAA Security Rule's integrity standard: protect electronic protected health information from improper alteration or destruction. A common way to meet it (the addressable mechanism at 164.312(c)(2)) is to verify that a record has not been altered, with a hash or a signature. That verification lives in the code that reads and writes patient data.

How it shows up in a diff

The shapes the same control failure takes.

Integrity weakens when a change makes it possible for ePHI to be altered or destroyed without it being caught. The recurring shapes:

  • A record integrity check is removed

    A hash, checksum, or signature verification that detected tampering or corruption on a patient record is dropped, so an altered record is served as if intact.

  • A destructive write replaces a safe update

    A guarded update is changed to an overwrite or hard delete that destroys the prior record with no recovery or trail.

  • A guard against improper deletion is removed

    A safeguard that prevented records from being deleted improperly is taken out, so data can be destroyed when it should not be.

  • Write validation is dropped

    Validation on a write is removed, so malformed or corrupt ePHI can be persisted and later read as truth.

  • A record store becomes freely editable

    A tamper-evident or append-only constraint is loosened, so records can be changed without leaving a trace.

Worked example

A record integrity check, removed to speed up reads.

Patient records are stored with a hash, and each read verifies it to catch tampering or corruption. The check is showing up in profiling, so a change removes it. Reads get faster, and an altered or corrupted record would now be returned as if it were intact.

records/read.ts+0 -1
async function getRecord(id) {  const rec = await db.records.get(id)-  if (!verifyHash(rec, rec.hash)) throw new IntegrityError(id)  return rec}
heygrcHIPAA 164.312(c)(1)

Removing the verification means an improperly altered or corrupted patient record would be served without anyone noticing, which 164.312(c)(1) (integrity) expects you to protect against. Keep the integrity check; if it is slow, make it cheaper rather than dropping it.

What an auditor does with this

Integrity is checked against alteration and destruction.

A HIPAA review looks at how ePHI is protected from improper change: whether records can be altered or destroyed without detection, and whether there is a mechanism to confirm a record is what it should be. A change that removed an integrity check or turned a guarded update into a destructive one is the concrete gap, and it is visible in the diff to the read or write path.

What this is, and is not

A review, not a data-integrity platform.

heygrc flags changes that touch the integrity safeguard and cites the CFR reference so the fix happens in the pull request. It does not hash your records or run your backups. It catches the moment a change lets ePHI be altered or destroyed without detection, at the diff. heygrc is in early access.