A ledger can forget PHI if each record has its own key. That sounds like a contradiction. The point of a permissioned ledger or an append-only log is that records cannot be quietly removed. We have argued for exactly that property, in our January piece on permissioned ledgers for PHI and in March on tamper-evident access logs.
But health data also has to be destroyed sometimes. A business associate agreement ends and the vendor must return or destroy the PHI it holds, or a retention period simply runs out. A system that can never forget anything cannot meet those obligations. The technique that resolves the conflict is called crypto-shredding.
Immutability and deletion are both requirements
Deletion obligations in health care are real, even though HIPAA does not give patients a general right to have their records erased. The Privacy Rule requires business associate agreements to provide that, at termination, the business associate will return or destroy all PHI it received or created for the covered entity, if feasible, and extend the agreement’s protections to anything it cannot return or destroy. State laws add their own retention and destruction rules, and any security program benefits from holding less data for less time.
Retention obligations are real too. Medicare Advantage organizations, for example, must retain records related to their contracts for 10 years. A review record supporting a coverage decision may need to survive audits and litigation long after the member has left the plan. The same record that must be kept for a decade may then have to be destroyed when the decade is over.
The difficulty is that data does not live in one place. Copies spread across servers and backups, and in a ledger design they reach other organizations too. Deleting a row from the primary database leaves every other copy in place. An immutable ledger or backup will not delete it at all, by design.
How crypto-shredding works
Crypto-shredding replaces the question of how to delete every copy of a record with a simpler one, which is how to make every copy unreadable at once.
The method uses envelope encryption. Each record, or each group of records shared for a particular purpose, is encrypted with its own data key. The data keys are themselves encrypted with a master key held in a key management system or hardware security module. The encrypted records can then be stored and replicated like any other data, including on a ledger.
When a record must be destroyed, the system destroys its data key, including every wrapped copy of it. The encrypted record may remain in a ledger or a backup, but without the key it cannot be read. A single action reaches every copy.
Destroying a key is the only way to delete data from every copy at once.
The approach has recognized standing. NIST’s media sanitization guidance, Special Publication 800-88, describes cryptographic erase as a sanitization technique. HHS’s breach notification guidance treats electronic media sanitized consistent with that publication as destroyed, according to the HHS guidance. It also treats PHI encrypted consistent with NIST guidance as secured, so long as the key has not been compromised. A record whose key has been verifiably destroyed is, in practical terms, no longer PHI that anyone can read.
Crypto-shredding also fits the integrity designs that ledgers provide. A ledger that holds hashes and commitments, rather than records, keeps its proofs after a key is destroyed, because the hash of the encrypted record has not changed. An organization can show that a record existed unaltered and that its key was destroyed on a particular date, all without revealing its contents.
Where it gets hard
The idea is simple. Doing it well depends on several design choices.
- Key granularity. A key per patient allows a patient’s records to be destroyed together but not selectively. A key per record allows precise destruction but multiplies the keys to manage. Many designs choose a key per patient per purpose, so that data shared for one use can be destroyed without touching data held for another.
- Key copies. A data key that has leaked into a log file or an unencrypted backup of the key store defeats the method. Keys need to live only in the key management system, and that system has to support verifiable destruction.
- Plaintext copies. Crypto-shredding reaches only data that was encrypted under the key. Anything decrypted and copied elsewhere in plain form, such as an analytics extract or a search index, has to be tracked and handled separately.
- Legal holds and minimum retention. Destruction must stop when a record is subject to a legal hold or has not reached its required retention period. The schedule that destroys keys has to know about both.
- Proof of destruction. The destruction itself should be recorded in a tamper-evident log, so that an auditor or a former business partner can verify when a key was destroyed and by whom.
None of these is unusual for a well-run key management program. They do require deciding, at the start, how data will be grouped under keys, because changing that later means re-encrypting everything.
What we build for
We build tools health plans use in utilization review, and the records behind those tools are both long-lived and sensitive. A review record holds clinical facts from a member’s chart alongside the reviewer’s decision and the reasons for it. Every decision we support must be reconstructable, and that has to hold for as long as regulators or courts may ask. When that period ends, the same records should become unreadable everywhere they were copied.
We think those 2 requirements are compatible if the keys are designed for them from the beginning. Records can be encrypted under keys grouped by member and purpose, with their integrity anchored in a tamper-evident log. The keys are then destroyed on a schedule that respects retention rules and legal holds. The decision trail stays provable for as long as it must, and then it is gone.
Immutability and the ability to forget are usually presented as opposites. With the right keys, a system can have both. No one can change the record while it exists, and no one can read it once it should no longer exist.