HIPAA evidence,
without the PHI.
Ordinary API and inference logs are mutable and full of patient data. This audit trail is tamper-evident, PHI-free, and something an auditor can verify without trusting you.
HIPAA audit controls under §164.312(b) require mechanisms that record and examine activity in systems that contain or use electronic PHI — but that is only meaningful if the record is tamper-evident and captured at the operation level. RankShieldMD supports it with tamper-evident, PHI-free records: a one-way sha256 digest of the patient reference, a verified actor identity, and an append-only, post-quantum-signed log, supporting §164.312(b) and §164.528 with evidence you can verify.
Your AI log is
editable evidence.
Clinical AI now reads charts, drafts orders, and touches PHI at machine speed — and the only record of it is usually an inference log. Those logs share the two weaknesses of every ordinary API log. They're mutable: anyone with enough access can rewrite what the model did. And they sit with the PHI they track, enlarging your breach surface. When OCR or a patient asks what your AI accessed, an editable log full of identifiers is the wrong answer to be holding.
Record and examine.
Provably.
The audit-controls standard asks you to record and examine activity in systems with electronic PHI. RankShieldMD does it at the operation level: every access — human or AI — becomes a structured event carrying the verified actor identity under RFC 9421, the action, the purpose, the outcome, and a one-way sha256 digest of the patient reference. It's sealed to an append-only, post-quantum-signed log. Recording the activity and proving the recording wasn't altered are different guarantees — the standard's intent is served by the second.
Who accessed
this patient?
Section §164.528 gives patients the right to an accounting of certain disclosures. Because every access is purpose-tagged — treatment, payment, operations, disclosure, research — and the patient reference is a deterministic one-way digest, RankShieldMD assembles a cryptographically-sealed, verifiable who-accessed-this trail that includes AI inferences alongside human access. You answer the request with evidence, not another copy of protected data to secure.
Auditing AI access
shrinks the footprint.
Most security tooling ingests clinical data to function — every system that copies PHI enlarges your breach exposure. RankShieldMD is built the other way. Because it operates on digests and verified identities, it strengthens your audit trail without becoming another store of PHI to secure and breach-report. Auditing AI access to PHI this way reduces the protected data in play while increasing the strength of your evidence — and speeds vendor assessments and BAAs.
Prove the access.
Protect the data.
Give every AI and EHR access to PHI a tamper-evident, PHI-free receipt — evidence you can verify and hand to OCR or an auditor, without ever expanding your protected-data footprint. Run an access flow from your environment through the ledger and verify the result yourself.
HIPAA compliance software for AI and EHR access to PHI
This is HIPAA compliance software in a specific, honest sense: it produces tamper-evident, PHI-free evidence of every AI and EHR access to a patient record — who, when, what action, and why — that supports HIPAA §164.312(b) audit controls and §164.528 accounting of disclosures without storing protected health information. HIPAA audit controls under §164.312(b) require mechanisms that record and examine activity in systems containing or using electronic PHI, and that requirement is only meaningful if the record is tamper-evident and captured at the operation level. Ordinary API and inference logs are neither: they are mutable, and they usually sit with the very PHI they track, enlarging your breach surface. RankShieldMD is built the other way. Every access — a clinician viewing a chart, an export, a disclosure, or an AI model running an inference against PHI — becomes a structured event carrying the verified identity of the actor under RFC 9421, the action, the purpose of use, the outcome, and a one-way sha256 digest of the patient reference. The name, MRN, and every other identifier are rejected at the guard, so no protected data ever enters the record. Each event is cryptographically chained, sealed to an append-only transparency log, signed with composite ML-DSA-65 and Ed25519, and externally anchored, so the trail is both stronger and safer than a conventional log. It supports §164.312(b) and §164.528; it does not by itself make an organization HIPAA compliant, and any vendor that claims a product can is worth a hard second look.
How do you make an AI audit trail HIPAA-compliant?
You make it defensible by separating the proof from the data and making the record tamper-evident: capture verifiable statements about each AI access to PHI rather than its clinical contents, and seal them so they cannot be silently rewritten. The requirement to satisfy is §164.312(b) audit controls — record and examine activity in systems with electronic PHI — and its intent is only met when the record survives the person who might want to alter it. RankShieldMD does this in a fixed shape. When a model runs an inference against PHI, it captures the verified identity of the actor under RFC 9421, the action, the purpose of use, the outcome, and a one-way sha256 digest of the patient reference; the raw identifiers are rejected at the guard before anything is sealed. It then chains that event, seals it to an append-only transparency log, signs it with composite post-quantum cryptography, and anchors the log root externally so the whole structure is pinned in time. An auditor can recompute the hash chain and confirm the signed root with standard tools, without access to your systems and without trusting RankShieldMD. Tamper with the model, the record, or the order of events, and verification returns false. The honest boundary matters: this produces evidence that supports §164.312(b), but no software makes a trail HIPAA compliant on its own, because compliance is your organization's overall posture across administrative, physical, and technical safeguards.
What audit log does HIPAA require for AI and EHR access?
HIPAA does not name a product or a format; §164.312(b) requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI. The standard is deliberately technology-neutral, but its intent is specific — you must be able to reconstruct who did what to ePHI, including what an AI model did, and you must be able to examine that record when misuse is suspected. Most organizations satisfy this today with application logs, database logs, EHR access reports, or model inference logs. Those mechanisms record activity, but they carry two structural weaknesses the standard never anticipated. First, they are mutable: an insider or an attacker with sufficient privileges can alter or delete the record, and the audit trail meant to catch misuse becomes editable by the person misusing it. Second, they usually live with the PHI they track, so the control that is supposed to reduce risk becomes another copy of protected data to secure and breach-report. RankShieldMD supports the requirement while closing both gaps. It records every access — human and AI — as a structured, examinable event on a tamper-evident, append-only log that contains no PHI at all. Recording the activity and being able to prove the recording was not altered are different guarantees, and the standard's intent is served far better by the second. The related standards travel with it: §164.312(a) access control and §164.312(e) transmission security are supported by the verified identity bound to every event.
How do you answer a HIPAA accounting-of-disclosures request for AI access?
You answer it by producing a purpose-tagged, verifiable trail of everything — human or model — that touched a given patient reference, without exposing the identity itself. Section §164.528 gives patients the right to an accounting of certain disclosures of their PHI, and the practical difficulty is assembling that trail across systems when AI now accesses records alongside people. RankShieldMD makes it tractable because every access, including each AI inference against PHI, is sealed as a structured event carrying a purpose of use — treatment, payment, operations, disclosure, or research — and a one-way sha256 digest of the patient reference. The digest is deterministic, so the same patient always resolves to the same value across the log; that is what lets you build the who-accessed-this list and separate the disclosures §164.528 concerns from routine treatment access. But the function is one-way, so the trail reveals no identity even to someone who steals the entire ledger, and the purpose is sealed with the event, so it cannot be relabeled after the fact without breaking the hash chain. You hand the requester, or OCR, a cryptographically-sealed trail that anyone can verify, rather than a log whose integrity you personally have to vouch for. And you do it without adding to your protected-data footprint, because the accounting is assembled from digests and verified identities, never from names or MRNs. It supports responding to §164.528; the response itself remains your organization's to make.
How do you pass an OCR audit for clinical-AI access to PHI?
You pass by producing evidence, not assertions — and the strongest evidence is a record an auditor can verify without trusting you. When the HHS Office for Civil Rights reviews your audit controls, the question underneath §164.312(b) is whether activity in systems with electronic PHI was recorded and can be examined. For clinical AI, that means being able to show what each model accessed, when, under what purpose, and with what outcome — including the failed, denied, and break-glass attempts, which are often exactly what an investigator wants. RankShieldMD produces that record in a tamper-evident, PHI-free form: every AI and human access is a structured event, cryptographically chained and sealed to an append-only, post-quantum-signed log, keyed by a one-way digest rather than an identity. An OCR reviewer, or your own counsel, can recompute the hash chain and confirm the signed root with standard tools, which turns your audit position from we log this into here is a record you can independently check. It is worth stating plainly that no vendor can promise an OCR outcome, and this page does not. RankShieldMD supports the audit by giving you verifiable evidence; the result still depends on your organization's overall posture across the administrative, physical, and technical safeguards HIPAA requires. A honest tool improves the evidence you bring to the review — it does not decide the review, and any vendor claiming to guarantee a clean audit should be treated with suspicion.
How do you audit AI access to PHI without expanding your breach surface?
By recording verifiable statements about an access rather than its protected contents, so the audit trail holds no PHI to breach. The instinct behind an audit control is protective, but the conventional implementation is quietly self-defeating: to record who touched a record, the log stores the record's identifiers, and now the audit trail is itself a concentrated store of protected data. If it leaks, you have a reportable breach in the very system meant to demonstrate diligence — and clinical AI makes this worse, because inference logs can capture prompts and outputs dense with PHI. RankShieldMD inverts the trade. When an access occurs, it reduces the patient reference to a one-way sha256 digest at the guard; the name, MRN, and every other identifier are rejected before anything is sealed. Around that digest it records only the verified actor identity, the action, the purpose, the outcome, and the time. Because the ledger operates on digests and identities rather than raw PHI, it strengthens your audit trail without becoming another store of protected data to secure and breach-report. Adopting it reduces the protected data in play while increasing the strength of your evidence — the opposite of the usual security tax. That inversion has a practical downstream benefit: vendor security assessments and business associate agreements move faster when the tool in question holds no PHI, because there is less to review and less to indemnify. The current HIPAA Security Rule frames measures like MFA and encryption as addressable; the January 6, 2025 NPRM proposes making them mandatory, but that change is proposed, not final, and we describe it that way.
What we are careful never to claim.
PHI-free by construction
Patient references are reduced to one-way sha256 digests at the guard; names, MRNs, and identifiers are rejected before anything is sealed. Operating on digests shrinks your PHI footprint. The ledger is useless to anyone who steals it — there is no protected data inside.
Supports — does not make you compliant
It produces verifiable evidence that supports §164.312(b) audit controls and §164.528 accounting of disclosures. No software makes you HIPAA compliant or certified; compliance is your organization's overall posture. Any vendor claiming to make you HIPAA compliant should be treated with suspicion. The January 6, 2025 Security Rule NPRM on MFA and encryption is proposed, not final.
Tamper-evident and quantum-safe
Events are cryptographically chained and write-once, signed with composite ML-DSA-65 and Ed25519. Ordinary API and inference logs are neither chained nor tamper-evident, which is why they can be rewritten without a trace. It is quantum-safe, not quantum-proof.
Ask RankShieldMD about HIPAA-compliant AI audit trails.
What does HIPAA §164.312(b) require for an audit trail?
The audit-controls standard requires covered entities to implement mechanisms that record and examine activity in information systems that contain or use electronic PHI. It is operation-level and data-specific. For an AI or EHR audit trail to meaningfully satisfy the intent, it has to be tamper-evident and capture activity at the operation level. RankShieldMD supports §164.312(b) with tamper-evident, PHI-free records that record and can be examined. It supports the requirement; it does not by itself make you HIPAA compliant.
How do I make an AI audit trail HIPAA-compliant?
Route each AI or EHR access to PHI through a record that captures the verified identity of the actor, the action, the purpose of use, the outcome, and a one-way sha256 digest of the patient reference — never the identity itself. Seal each event to an append-only, post-quantum-signed transparency log and anchor it externally so it is tamper-evident and independently verifiable. RankShieldMD produces evidence that supports §164.312(b); no software makes the trail compliant on its own, since compliance is your organization’s overall posture.
Why are ordinary API and inference logs not enough?
Ordinary API and inference logs are mutable and usually sit alongside the PHI they track. An insider or attacker with enough access can rewrite the record of what they did, and nothing about the log reveals it happened. The log itself also enlarges your breach surface because it is one more store of protected data. A PHI-free, tamper-evident ledger removes both weaknesses: the record cannot be silently altered, and it holds no protected data to steal.
What events should a compliant AI access trail capture?
Every access — view, export, disclose, amend, and each AI inference against PHI — with the verified identity of the actor, the action, the purpose of use, the outcome, and a digest of the patient reference. Denied, break-glass, and unverified attempts should be sealed too, because those are precisely the events an investigator needs when something goes wrong. RankShieldMD seals all of these, including the failures.
How does this support a §164.528 accounting-of-disclosures request?
Section §164.528 gives patients the right to an accounting of certain disclosures of their PHI. Because every access is purpose-tagged — treatment, payment, operations, disclosure, or research — RankShieldMD produces a cryptographically-sealed, verifiable who-accessed-this trail that supports responding to those requests. The patient reference is a one-way digest, so the same patient always resolves to the same value across the log, letting you assemble the trail without adding to your protected-data footprint.
Can I answer a disclosure request for AI access to a patient record?
Yes. Because AI inferences against PHI are sealed as structured, purpose-tagged events on the same ledger as human access, you can produce a single verifiable trail of every actor — human or model — that touched a given patient reference. The digest is deterministic, so you can build the who-accessed-this list; it is one-way, so the trail reveals no identity even to someone who steals the whole log.
Does the trail distinguish treatment from disclosure?
Yes. Each event carries a purpose of use — treatment, payment, operations, disclosure, or research — so the accounting can separate the disclosures §164.528 concerns from routine treatment access. The purpose is sealed with the event, so it cannot be relabeled after the fact without breaking the hash chain.
Does the audit system store patient data?
No. It stores one-way sha256 digests of patient references plus event metadata and verified identities — never names, MRNs, or other identifiers. Raw PHI is rejected at the guard before anything is sealed, so it is PHI-free by construction. The ledger is useless to anyone who steals it because there is no protected data inside.
How can you audit AI access without expanding the breach surface?
By recording verifiable statements about an access rather than its protected contents. The patient reference is reduced to a one-way digest at the guard, and only that digest, the verified identity, and the event metadata are sealed. Because the ledger holds no PHI, it is not another protected-data store to secure and breach-report. You strengthen the audit trail while reducing, not increasing, the protected data in play.
Does adopting it increase our PHI footprint?
No — it decreases it. Most security tooling ingests clinical data to function, and every system that copies PHI enlarges your breach exposure. Because RankShieldMD operates on digests and verified identities, it adds audit strength without becoming another store of protected data to secure and breach-report. That also speeds vendor assessments and business associate agreements, because there is simply less to review.
What makes the record tamper-evident?
Each event is cryptographically chained and sealed to an append-only transparency log, signed with composite ML-DSA-65 and Ed25519, and externally anchored. Altering or removing a sealed record breaks the hash chain, so verification returns false. Ordinary logs and inference logs are neither chained nor write-once, which is exactly why they can be rewritten without a trace.
Can I verify the evidence myself?
Yes. Every sealed event can be independently verified by your team or an outside auditor by recomputing the hash chain and confirming the post-quantum-signed log root with standard tools. You hand over evidence that anyone can check, rather than a log whose integrity you personally have to vouch for.
How do you pass an OCR audit for clinical-AI access to PHI?
You pass by producing evidence, not assertions. When OCR reviews your audit controls, a tamper-evident, independently-verifiable trail of every access — including AI inferences and the failed, denied, and break-glass attempts — lets you demonstrate that activity was recorded and can be examined, which is the intent of §164.312(b). RankShieldMD produces that evidence in a PHI-free form. It supports the audit; the outcome still depends on your organization’s overall posture, and no vendor can promise an OCR result.
Will this make us HIPAA compliant or certified?
No software does. RankShieldMD produces verifiable evidence that supports specific HIPAA requirements — §164.312(b) audit controls and §164.528 accounting of disclosures — but compliance is your organization’s overall posture across administrative, physical, and technical safeguards. Any vendor that tells you their product makes you HIPAA compliant or HIPAA certified should be treated with suspicion. We are careful never to claim otherwise.
Do the 2025 HIPAA Security Rule changes require MFA and encryption now?
Not yet. The HIPAA Security Rule NPRM published on January 6, 2025 proposes making measures such as multi-factor authentication and encryption mandatory rather than addressable. Those are proposed, not final; the rule has not been finalized, so the addressable framework in the current Security Rule still governs. RankShieldMD supports the direction of travel — verified identity under RFC 9421 and transmission security under §164.312(e) — but we describe the NPRM accurately as proposed.
How does verified actor identity fit HIPAA access control?
HIPAA §164.312(a) requires access control, and §164.312(e) requires transmission security. RankShieldMD binds every sealed event to a verified actor identity using RFC 9421 message signatures, so the record proves who acted, not merely that someone did. That verified identity is what turns an access log into evidence. It supports §164.312(a) and §164.312(e); it does not replace your access-control and encryption program, which remain your organization’s responsibility.
Stronger evidence. Less PHI to defend.
Run an AI or EHR access flow from your environment through the ledger and verify the result yourself.