PHI access logs should be tamper-evident, not just kept. The HIPAA Security Rule’s audit controls standard, at 45 CFR § 164.312(b), requires covered entities to put in place mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Nearly every organization that handles PHI keeps some kind of access log to meet it.
Far fewer can prove that the log is complete. Access logs usually live in databases and log stores administered by the same technical staff whose access they record, and sometimes by vendors with even broader rights. A log that can be edited without a trace shows who looked at a record only as well as everyone with write access has behaved.
Logs are evidence, and evidence can be edited
The cases that reach federal regulators show why the log matters. In 2017, Memorial Healthcare System in Florida agreed to pay $5.5 million after the electronic records of 115,143 people were accessed improperly. Most of that access came through a former employee’s login credentials, which were used for about a year before anyone noticed. The Office for Civil Rights said at the time that organizations “must implement audit controls and review audit logs regularly.”
In 2023, Yakima Valley Memorial Hospital in Washington agreed to pay $240,000 after 23 security guards in its emergency department looked at the records of 419 people without a work reason.
Investigators in cases like these first want an account of who opened each record and when. The log is the only source of that account. If it can be altered or rebuilt after the fact, every conclusion drawn from it is weaker. And the scenario a log most needs to withstand is the one where someone with privileged access has a reason to change it.
The Security Rule already applies this logic to PHI itself. Its integrity standard requires policies to protect electronic PHI from improper alteration or destruction, and an addressable specification calls for electronic mechanisms to corroborate that it has not been altered. The access log deserves the same protection.
How a hash chain works
The core technique is old and simple. Each log entry includes a cryptographic hash of the entry before it. Change or delete a single old entry and the hash no longer matches. That breaks every link after it. The edit does not become impossible, but it becomes visible.
A Merkle tree extends the idea to large volumes. Entries are grouped into a tree of hashes. The single hash at the top, called the root, summarizes everything beneath it. With the root in hand, anyone can cheaply check that a particular entry is included in the log. They can also check that today’s log extends last week’s rather than rewriting it. The web already depends on this design. Certificate Transparency uses append-only Merkle tree logs so that browsers and auditors can detect certificates that were issued and then hidden. RFC 9162 specifies the design.
A hash chain alone has a gap, because whoever runs the log could rebuild the whole chain after an edit. The fix is to publish the root somewhere the log operator does not control. That can be an external timestamping service or a permissioned ledger shared with another organization, as we described in our January piece on permissioned ledgers for PHI. Once a root has been anchored outside, rewriting history means getting every outside party to agree to it.
A log that the people it watches can edit is a diary, not evidence.
What goes on the ledger, and what stays off
A tamper-evident log does not mean putting PHI on a blockchain. The ledger should hold commitments rather than records. Those commitments are Merkle roots signed and timestamped by the systems that produced them. The log entries themselves, which say who opened a record and when, stay in the organization’s own encrypted store, under its normal access controls.
That division has practical benefits. The ledger reveals nothing about patients even to the organizations that share it, and the organization keeps control of retention for the underlying entries. An auditor who needs to check a single access can receive that entry and a short proof that it belongs under an anchored root, without seeing the rest of the log.
The scheme holds up in practice only with 3 design choices.
- Log at the source. Entries should be written and hashed by the application that served the record. Hashing at write time protects them before they pass through any system that could reorder or drop them.
- Anchor on a schedule. Publishing roots every few minutes limits the window in which an undetected edit could occur, and it costs very little.
- Check routinely. Tamper evidence helps only if someone verifies the chain. An automated daily check that recomputes the hashes and compares them with the anchored roots turns a theoretical guarantee into an operating control.
None of this replaces reviewing the log. The Memorial case turned on access that no one looked at for a year. A tamper-evident log makes review trustworthy. It does not make review happen.
What we build for
We build tools health plans use in utilization review, and one of our rules is that every decision can be reconstructed. That rule depends on a record of what the system recommended and what the reviewer decided, including everyone who opened the member’s file along the way. If that record could be quietly changed, the reconstruction would be only as good as the last person to touch it.
We think the trail behind a coverage decision should be tamper-evident by design, with its integrity anchored outside the system that produced it and verified as a matter of routine. The same structure serves an access log and a decision log alike.
The cost of this approach is low, and most of the pieces are standard. The benefit shows up on the day it is needed. When a regulator or a court asks what happened, the answer comes with a proof that nobody has edited it since.