Prove who touched
the record.
Most audit tools ingest patient data to work — enlarging your breach surface. This one runs on digests, so adopting it shrinks your PHI footprint.
RankShieldMD's access audit produces tamper-evident, cryptographic proof of every access to a patient record — who, when, what action, and why — while never storing protected health information. Each access event is sealed to an append-only, post-quantum-signed transparency log, supporting HIPAA §164.312(b) and §164.528 with evidence you can verify.
A log you can edit
isn't a control.
HIPAA §164.312(b) requires audit controls — mechanisms that record and examine activity in systems with electronic PHI. But conventional logs have two weaknesses. They're mutable: an insider or attacker with enough access can rewrite the record of what they did. And they usually sit with the PHI they track, enlarging your breach surface. RankShieldMD removes both — the record is tamper-evident and contains no PHI at all.
Prove the access.
Not the data.
Every access — view, export, disclose, amend — becomes a structured event: 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 name, MRN, or any identifier, which are rejected at the guard. It's sealed to an append-only transparency log, post-quantum-signed, and anchored. Denied, break-glass, and unverified attempts are sealed too — precisely the events an investigator needs.
Adopting it
shrinks your risk.
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 identities, it strengthens your audit trail without becoming another store of PHI to secure and breach-report. Adopting it reduces the protected data in play while increasing the strength of your evidence — and speeds vendor assessments and BAAs.
The people who answer
the OCR letter.
Primarily health-system CISOs, privacy officers, and compliance teams who own HIPAA audit controls and respond to accounting-of-disclosures requests, patient complaints, and OCR inquiries — and who want tamper-evident evidence rather than a log they have to vouch for. Also HIEs and organizations exchanging records. Access provenance runs on the same fabric as clinical-AI decision provenance and device identity — one platform, many proofs.
Prove access.
Protect the data.
Give every patient-record access a tamper-evident, PHI-free receipt — evidence you can verify and hand to an auditor, without ever expanding your protected-data footprint. Run an access flow from your environment through the ledger and verify the result yourself.
What is a PHI-free HIPAA access audit?
A PHI-free HIPAA access audit is a tamper-evident, cryptographically-sealed record of every access to a patient record — who, when, what action, and why — that never stores protected health information. HIPAA's audit-controls standard (§164.312(b)) is operation-level and data-specific: it requires mechanisms that record and examine activity in systems containing electronic PHI. Ordinary API and inference logs are neither operation-level nor tamper-evident, and they usually sit with the very PHI they track, enlarging your breach surface. RankShieldMD is built the other way. Every access — view, export, disclose, amend — becomes a structured event carrying the verified identity of the actor, 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. Two principles govern the design and we hold to both honestly: prove the access, not the data, and adopting it shrinks your PHI footprint rather than growing it. It supports §164.312(b) and §164.528; it does not by itself make an organization HIPAA compliant.
What does HIPAA §164.312(b) actually require?
It requires audit controls: hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. The standard is deliberately technology-neutral, but its intent is specific — you must be able to reconstruct who did what to ePHI, and you must be able to examine that record when misuse is suspected. In practice most organizations satisfy this with application logs, database logs, or an EHR's built-in access reports. 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 of what they did, 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 very control that is supposed to reduce risk becomes another copy of protected data to secure and breach-report. RankShieldMD supports §164.312(b) while closing both gaps. It records every access as a structured event and makes that record examinable and independently verifiable, but it does so 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.
Why isn't a normal audit log good enough?
Because a log you can edit is not a control — it is a convenience. HIPAA §164.312(b) asks you to record and examine activity, but it says nothing about whether the record can be trusted once someone with access decides to rewrite it. Conventional API logs, database logs, and inference logs are mutable by design: they are optimized for operations and debugging, not for surviving a hostile insider or a determined attacker. Anyone who can reach the log store can often alter timestamps, delete entries, or reorder events, and nothing about the log itself reveals that it happened. A tamper-evident record is fundamentally different. It relies on cryptographic chaining and write-once, append-only storage, so every event is bound to the ones before it; altering or removing a single sealed entry breaks the chain and fails verification. Ordinary logs are neither chained nor write-once, which is precisely why they cannot answer the one question that matters after an incident — can you prove this record was not changed. There is a second problem. Because normal logs sit alongside the PHI they describe, they enlarge your breach surface: a log full of names and MRNs is one more protected-data store to encrypt, monitor, and report on if it is exposed. RankShieldMD's ledger holds only digests and verified identities, so it is worthless to a thief and adds no protected data to defend.
How do you audit access without storing PHI?
By recording verifiable statements about an access rather than its protected contents. When an access occurs, RankShieldMD 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 the verified identity of the actor, the action taken, the purpose of use, the outcome, and the time. The digest is deterministic, so the same patient always produces the same value; that is what lets you build a who-accessed-this trail and answer an accounting-of-disclosures request under §164.528. But the function is one-way: the digest cannot be reversed back into an identity, so the ledger reveals nothing protected even to someone who steals the whole thing. Each event is then cryptographically chained, sealed to an append-only transparency log, signed with composite ML-DSA-65 and Ed25519, and externally anchored so the structure is pinned in time. Denied, break-glass, and unverified attempts are sealed alongside successful ones, because those are exactly the events an investigator needs. The protected data stays where it belongs, governed by the clinical systems built for it; RankShieldMD holds only the cryptographic proof of the access. You get a stronger audit trail and, at the same time, one fewer copy of PHI to defend.
How does PHI-free auditing reduce risk instead of adding to it?
Because most security tooling makes you copy clinical data to work, and every copy of PHI is another thing you have to secure, monitor, and breach-report. 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. RankShieldMD inverts that trade. Because it operates on one-way digests and verified 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 simply less to review and less to indemnify. The honest framing matters here. This does not make you HIPAA compliant; compliance is your organization's overall posture. What it does is let you meet the intent of §164.312(b) and support §164.528 with evidence that is both harder to forge and safer to hold than the log it replaces.
HIPAA evidence, PHI-free.
Record and examine activity
- Every access sealed to a tamper-evident, append-only log
- Keyed by a one-way digest — never the patient's identity
- Break-glass, denied, and unverified attempts all captured
- Independently verifiable by your team or an auditor
Supports the requirement. It does not by itself constitute HIPAA compliance.
Who accessed this patient
- Purpose-tagged: treatment / payment / operations / disclosure / research
- A cryptographically-sealed, verifiable who-accessed-this trail
- Produced without adding to your protected-data footprint
- Handed over as evidence — not a log you have to vouch for
PHI-free by construction — digests only. Adopting it shrinks your PHI footprint.
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. 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. The proposed Security Rule updates on MFA and encryption are proposed, not final.
Tamper-evident, not just logged
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.
Ask RankShieldMD about HIPAA access auditing.
What is a PHI-free HIPAA access audit?
It is a tamper-evident record of every access to a patient record — who, when, what action, and why — that never stores protected health information. Instead of the patient name or MRN, RankShieldMD seals a one-way sha256 digest of the patient reference, the verified identity of the actor, the action, and the purpose of use. Adopting it strengthens your audit trail without adding another store of PHI to secure.
Why is a normal audit log not good 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 the log itself enlarges your breach surface. A PHI-free, tamper-evident ledger removes both weaknesses: the record cannot be silently altered, and it contains no protected data to steal.
Who is this built for?
Primarily health-system CISOs, privacy officers, and compliance teams who own HIPAA audit controls and answer accounting-of-disclosures requests, patient complaints, and OCR inquiries. It also fits health information exchanges and any organization exchanging records that needs tamper-evident evidence rather than a log it has to vouch for.
Does the audit system store patient data?
No. It stores one-way 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 does it audit access without storing PHI?
The patient reference is reduced to a one-way sha256 digest at the guard. The same patient always produces the same digest, so you can prove a who-accessed-this trail and answer disclosure requests, but the digest cannot be reversed back to an identity. The medical data stays in the clinical systems built for it; RankShieldMD holds only the cryptographic proof of the access.
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 BAAs.
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.
What events get sealed?
Every access — view, export, disclose, amend — becomes a structured event 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 are sealed too, because those are precisely the events an investigator needs when something goes wrong.
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.
What does HIPAA §164.312(b) require?
The audit-controls standard requires covered entities to implement mechanisms that record and examine activity in information systems containing or using electronic PHI. It is operation-level and data-specific. RankShieldMD supports it with tamper-evident, PHI-free access records that record and can be examined. It supports the requirement; it does not by itself make you HIPAA compliant.
How does it relate to §164.528 accounting of disclosures?
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, without adding to your protected-data footprint.
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. The proposed HIPAA Security Rule updates on MFA and encryption are still proposed, not final. We are careful never to claim otherwise.
What does it take to integrate?
Route access events from your environment — EHR, HIE, or application layer — through RankShieldMD at the point of access. It captures digests and verified identities only; raw PHI is rejected at the guard. You receive sealed, verifiable evidence you can hand to an auditor. It sits alongside your systems, not inside the clinical pathway, so adoption does not expand your protected-data footprint.
Stronger evidence. Less PHI to defend.
Run an access flow from your environment through the ledger and verify the result yourself.