HIPAA audit trail, 45 CFR § 164.312(b)

Status

Verdifax does not make any organization HIPAA compliant, and HHS does not certify products or vendors as compliant. Verdifax does not currently sign Business Associate Agreements, so do not send protected health information to Verdifax-hosted services. The mapping below is relevant to 45 CFR § 164.312(b) audit controls and is for your own assessment.

What § 164.312(b) actually says

"Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

That sentence is intentionally technology-neutral. It doesn't specify a format, a retention period, or a verification model. Whether an organization's audit controls are sufficient is for that organization, its risk analysis, and its auditors and regulators to decide.

Where audit trails fail in AI systems

A typical AI clinical-decision-support system produces a recommendation, the recommendation is logged with a timestamp + user id + model version, and that's the audit record. Two problems:

1. The log is editable by anyone with database access. The integrity of the audit record depends entirely on the operator's promise to not modify it.
2. The log doesn't reproduce the decision. If a clinician disputes the recommendation, "the model said X" is the entire audit trail, there's no way to reconstruct exactly what the model saw and how the recommendation was generated.

Both problems are exactly what Verdifax is designed to address.

Mapping

Practical pattern

For a clinical decision support model:

import verdifax

# 1. Send hashes, never raw PHI or model output that may contain PHI.
import hashlib
phi_hash = hashlib.sha256(patient_record_canonical.encode()).hexdigest()
output_hash = hashlib.sha256(model_output.encode()).hexdigest()

receipt = verdifax.attest(
    payload=f"phi_hash:{phi_hash}\nrecommendation_hash:{output_hash}",
    program_id="<your-clinical-program-id>",
    route_id="cdss-recommendation-v3",
    registry_record_hash="<your-registry-record-hash>",
)

# 2. Store ALONGSIDE the recommendation in your existing audit log.
audit_db.insert({
    "patient_id": patient.id,         # internal id, stays in your own system
    "user_id": clinician.id,
    "recommendation": model_output,
    "verdifax_seal": receipt.manifest_hash,
    "timestamp": utcnow(),
})

The seal goes in your existing audit table. When the incident-response team needs to verify a specific recommendation later, they check the stored seal against the run's sealed record: GET /runs/{id}/verify re-derives the manifest hash server-side from the stored manifest fields, and the open-source verifier recomputes the audit bundle's section hashes offline and confirms each is bound to that manifest hash. Re-submitting the same inputs would create a new run with a different hash, so the check works from the sealed record, not from the inputs.

Why hash the PHI rather than seal the raw bytes

HIPAA's minimum necessary standard (45 CFR § 164.502(b)) limits uses and disclosures of PHI to the minimum necessary for the purpose. The Verdifax seal needs the identity of the input, not its contents. SHA-256 of the canonical PHI representation gives you input-identity without placing the PHI itself in the seal record. A hash of a short or guessable value can be confirmed by guessing, so a hash is not automatically de-identified. [Pending review by counsel: whether hashes or metadata derived from PHI are themselves PHI in a given deployment.] Keep the model output in your own audit log, as the example does, and send Verdifax only hashes and internal identifiers.

Continue

• Sample audit response
• SOX § 404 IT controls