A permissioned ledger can carry PHI's paper trail, not the PHI

A permissioned ledger can carry PHI’s paper trail without carrying the PHI. The first wave of health care blockchain projects tried the opposite. They put medical records on a shared ledger and ran into the same wall. Records need to be corrected and eventually destroyed, and a ledger that every participant replicates forever does neither well. The conclusion most teams drew was that blockchain and protected health information (PHI) do not mix.

That conclusion is half right. HIPAA itself is more comfortable with an append-only record than the folklore suggests, because the Privacy Rule corrects records by appending amendments, not by erasing what came before. What breaks is everything around the data. Many organizations hold a copy, often for longer than any retention schedule allows, and nobody can recall those copies if an encryption key fails a decade from now.

This analysis, written by Redlake Research, works through where the conflict actually lies and what a permissioned ledger like Hyperledger Fabric can do about it. It ends with the health care problems a ledger is genuinely suited to. The short version is that a ledger should hold the evidence around PHI, such as consent and access events, and never the PHI itself.

Key takeaways

• HIPAA amends by appending. Under 45 CFR § 164.526, a covered entity accepts an amendment by identifying the affected records and appending or linking to the amendment. Nothing in the rule requires erasing the original.
• Replication is the real problem. Every node that holds PHI is another copy to protect, and another record that must eventually be destroyed under retention schedules a ledger cannot honor.
• Hashes of identifiers can still be PHI. A ledger keyed by a hash of a medical record number or Social Security number does not de-identify anyone, because HIPAA’s re-identification rule bars codes derived from information about the individual.
• Fabric’s private data model points the way. Fabric keeps private data on authorized peers only and writes a hash of it to the shared ledger. The private data can later be purged while the hash remains as evidence.
• Consent is the first record worth sharing. The revised rules for substance use disorder records, with a compliance date of February 16, 2026, make consent scope something every downstream recipient needs to know.
• The best use is the one HIPAA never got. The HITECH Act called for patients to see routine disclosures made through electronic records, including those for treatment and payment. HHS’s 2011 proposal for an access report was called technically unfeasible and was never finalized. A shared ledger of access events is the kind of system that could make it feasible.

HIPAA corrects records by appending, not erasing

The most common objection to immutable ledgers in health care is that patients have a right to correct their records. They do. But the right works differently than many assume.

Under 45 CFR § 164.526, an individual can ask a covered entity to amend PHI in a designated record set, and the entity must act within 60 days, with one extension of up to 30 days. If it accepts the amendment, it must identify the records affected and add the change by appending or otherwise providing a link to the location of the amendment. It must then tell the people the individual identifies, and others who may rely on the old information, about the change.

If the entity denies the request, the individual may file a statement of disagreement. The entity may write a rebuttal. Both are attached to the record, and future disclosures must include them or an accurate summary.

That is an append-only model. The original entry stays and the correction is linked to it. The history of the dispute becomes part of the record. A well-designed ledger represents exactly this, with an amendment that references the original entry and a chain showing who changed what and when. The Privacy Rule does not address deletion as a means of amendment at all.

So the right to amend is not where an immutable PHI ledger fails. The failures are elsewhere.

Where a ledger full of PHI does break

Every replica is another copy to protect

A blockchain’s integrity comes from replication. Every participant holds the ledger, so no single participant can rewrite it. For PHI, that same property multiplies risk. A network of 40 organizations that replicates clinical data gives each of them a full copy. A breach at any one of them exposes the data contributed by all of them.

HIPAA’s minimum necessary standard pulls in the opposite direction. Covered entities are expected to limit uses and disclosures to what a purpose requires. Replicating a patient’s record to organizations that have no relationship with that patient, so that the network can validate transactions, is difficult to square with that standard regardless of encryption.

Encryption ages

Encryption does not resolve the replication problem, because ledger data is meant to last indefinitely while keys and algorithms do not. A ciphertext replicated across dozens of organizations in 2026 will still exist in 2046. If a key is compromised, or an algorithm weakens, there is no way to recall the copies.

Security expectations are also rising. In December 2024, the HHS Office for Civil Rights proposed changes to the HIPAA Security Rule that would require encryption of electronic PHI at rest and in transit. The proposal would also require a network map showing how electronic PHI moves, updated at least every 12 months. It would remove the distinction between required and addressable implementation specifications. It had not been finalized at the time of writing. Even in its proposed form, it describes a regime in which an organization must know where every copy of electronic PHI lives. A replicated PHI ledger makes that inventory larger by design.

Retention schedules end in destruction

Medical records are kept for set periods, often defined by state law, and then destroyed. A ledger designed never to forget cannot follow a schedule that ends in destruction. The same is true of data covered by state consumer health privacy laws that give individuals deletion rights outside HIPAA. An architecture that cannot delete is an architecture that will eventually be out of compliance with someone’s retention rule.

Hashing an identifier does not de-identify it

A common workaround is to keep names off the ledger and index everything by a hash of a medical record number or a Social Security number. HIPAA’s de-identification rules close that door. Under 45 CFR § 164.514(c), a code used to re-identify de-identified data must not be derived from or related to information about the individual and must not be capable of being translated to identify the individual. A hash of an identifier is derived from that identifier, and a hash of a 9-digit number can be reversed by computing the hash of every possible value.

A ledger keyed this way holds identifiable information. If it also records that a person was referred to an oncologist, or approved for a behavioral health service, the ledger holds PHI even if no clinical document ever touches it.

A ledger is good at proving that something happened and that a record has not changed since. It is bad at forgetting, and health care requires forgetting on a schedule.

Fabric’s private data model shows the alternative

Hyperledger Fabric, now one of the projects of the Linux Foundation Decentralized Trust, is a permissioned ledger. Its participants are known organizations with certificates, not anonymous miners. According to the Linux Foundation’s announcement in September 2024, the projects developed under the Hyperledger Foundation, including Fabric, moved into LF Decentralized Trust, which launched with 17 projects and more than 100 founding members.

Fabric’s design is useful here because of how it handles data that only some participants should see. The Fabric documentation on private data describes private data collections, which let a subset of organizations on a channel share data without exposing it to the rest.

• The private data stays with authorized organizations. It is shared peer-to-peer and stored in a private state database only on the peers of organizations in the collection.
• Everyone else gets a hash. A hash of the private data is written to every peer’s ledger on the channel, after the usual endorsement and ordering. The documentation describes the hash as evidence of the transaction, usable for validation and audit.
• The ordering service never sees the data. It handles only hashes, which go into blocks like any other transaction data.
• Private data can be purged. Deleting a private data value removes it from current state but leaves its history in the peer’s private database. The documentation directs implementers to a purge function to remove it completely. Collections can also be configured to purge data automatically after it has gone unmodified for a set number of blocks.
• The hash outlives the data. Organizations can share the underlying data outside the ledger, and a recipient can recompute its hash and compare it with the one on the channel. Chaincode can read those hashes through a dedicated API even on peers outside the collection.

This combination solves several of the problems above. The data lives only where it must, and it can be removed when a retention period ends. What remains on the shared ledger, the hash, is enough to prove later that a document existed in a particular form at a particular time, without revealing what it said.

The design comes with 2 cautions. A hash of a short, predictable value can be reversed, so hashes of private data should include enough randomness, such as a salt kept with the private data, to resist guessing. And purging private data does not purge the metadata of the transaction. If the fact of the transaction is itself sensitive, such as a referral to a particular specialty, that fact must be represented in a way that does not reveal it.

What belongs on the ledger and what stays off it

Taking the HIPAA analysis and Fabric’s model together produces a fairly clear division.

A Redlake Research analysis based on the HIPAA Privacy Rule sections cited here and the Hyperledger Fabric private data documentation.

The left-hand column has something in common. Each entry is a claim about an event, such as a consent given or a record accessed. Health care has no shared system of record for events like these. Each organization keeps its own logs, and when organizations disagree, as they routinely do about whether a fax arrived or when a request was complete, there is no neutral record to settle it.

Prior authorization is a clear example. Under the federal decision clocks that took effect on January 1, Medicare Advantage and Medicaid plans must decide routine requests within 7 calendar days, counted from receipt. A signed, timestamped receipt that both the provider and the plan hold, written to a ledger at the moment of submission, would answer the most contentious question in the process. The clinical documentation itself would travel through the plan’s normal channels and never touch the ledger.

Consent is the first record worth sharing

Consent is the clearest case for a shared record, and the calendar is making it more pressing. Under the 2024 final rule revising the confidentiality rules for substance use disorder treatment records at 42 CFR part 2, organizations subject to the regulation must comply by February 16, 2026, according to the HHS fact sheet. The rule allows a single consent to cover all future uses and disclosures for “treatment, payment, and health care operations.” HIPAA covered entities and business associates that receive records under that consent may redisclose them as HIPAA allows. The records still cannot be used in legal proceedings against the patient without specific consent or a court order. And a new category of substance use disorder counseling notes, kept separate from the rest of the record, requires its own specific consent and cannot be disclosed under a broad one.

Each of those rules depends on a downstream recipient knowing what the patient agreed to. Today that knowledge travels as a copy of a form, or not at all. A consent entry on a shared ledger would hold a reference to the signed consent and its scope, updated if the patient revokes it. A recipient could then check scope before redisclosing, without seeing the underlying records.

The design constraint is strict. The fact that a patient received substance use disorder treatment is itself the protected information, so the consent form, and anything that reveals the kind of program behind it, stays off the ledger. What goes on is a pseudonymous key and a scope code that does not name the type of program, signed and timestamped by the organization that recorded it. The fact sheet also notes that patients gain a right to an accounting of disclosures of Part 2 records, with a compliance date to be set when the corresponding HIPAA Privacy Rule provision is revised. That is the same accounting problem described below, arriving from a different direction.

The access report HIPAA never got

The strongest case for a health care ledger is a requirement Congress wrote and HHS never implemented.

HIPAA’s accounting of disclosures, at 45 CFR § 164.528, lets an individual request a list of certain disclosures of their PHI made in the previous 6 years, with the recipient and purpose of each. But the rule excludes the disclosures that make up most of health care, those made to carry out “treatment, payment and health care operations.” A patient who wants to know which organizations looked at their record for those purposes has no right to that list.

The HITECH Act of 2009 was meant to change that for disclosures made through electronic health records. In 2011, HHS proposed an access report that would have listed everyone who electronically viewed a patient’s information, with the date and nature of each access. According to GovInfoSecurity’s reporting in May 2018, the proposal drew more than 400 comments, mostly negative, calling it technically unfeasible and expensive. HHS’s Office for Civil Rights said it planned to withdraw the proposal and seek new input. No rule implementing the HITECH provision has been finalized.

The objections in 2011 were reasonable. Each organization’s access logs lived in different systems with different definitions of an access event. Assembling a single report across a hospital and a health plan, let alone their vendors, would have required integrations that did not exist.

A permissioned ledger addresses that problem directly. If each participating organization writes a signed access event, indexed by a patient key that is not derived from the patient’s identifiers, a patient’s access report becomes a query rather than a project. The events contain no clinical content. They record who accessed a record and under which authority. The organizations already generate these logs for security purposes. The ledger gives them a common format and a shared place to put them.

This would not make the access report legally required. It would make it cheap enough that the reasons for not requiring it would weaken.

What health care’s first networks show

Health care has seen ledger networks with significant backing. In 2022, Avaneer Health announced $50 million in seed funding from a group of backers that included Aetna and Cleveland Clinic, according to Healthcare IT News. The network described its focus as administrative exchange between organizations, including prior authorization, built using blockchain technology and HL7 FHIR.

The choice of focus is telling. The founders pointed the network at administrative transactions between organizations, which is where shared records of events help most, rather than at storing clinical records. The public reporting does not describe how the network divides data between the ledger and other systems, so it is not possible to say from it how closely the network follows the division described here.

Where Redlake stands

This section is commentary. It describes how Redlake Research would design a ledger for health data, based on the analysis above.

1. No PHI on the shared ledger, ever. Clinical content travels through existing channels or private collections that can be purged. The shared ledger holds hashes and event receipts.
2. Patient keys that are not derived from identifiers. Each network assigns random pseudonymous keys and keeps the mapping off the ledger, under the same controls as any identifier, consistent with the re-identification rule in 45 CFR § 164.514(c).
3. Every event signed by the organization that caused it. In Fabric terms, endorsement policies require the parties to a transaction to sign it, so a receipt for a prior authorization request carries the signatures of both the provider and the plan.
4. Purge by design. Private data collections are configured with retention limits that match the longest applicable schedule, and purge is tested, not assumed.
5. Start with the disputes. The first use cases should be the ones where organizations already disagree about what happened, such as receipt times and consent scope. Those are the problems a shared record of events solves, and they carry the least risk.

A ledger that follows these rules is not a medical record. It is closer to a notary for the health system, one that can say with confidence what happened and when, without ever knowing what the document said.

About this analysis

Basis. This analysis relies on the HIPAA Privacy Rule sections cited, as published by the Legal Information Institute, and on HHS Office for Civil Rights fact sheets. The Fabric material comes from the project’s private data documentation and the Linux Foundation’s announcement of LF Decentralized Trust. News reporting supplied the history of the 2011 accounting of disclosures proposal and the Avaneer Health funding. It is an analysis of design and regulatory fit, not legal advice.

Data notes.

• The Security Rule changes are a proposal. Final requirements may differ.
• The description of the 2011 access report proposal and its withdrawal comes from 2018 news reporting, not from the Federal Register documents themselves.
• The design rules in the commentary section, including the consent entry described under 42 CFR part 2, are Redlake Research’s views and are labeled as such.

Sources

• Legal Information Institute, 45 CFR § 164.526, Amendment of protected health information
• Legal Information Institute, 45 CFR § 164.528, Accounting of disclosures of protected health information
• Legal Information Institute, 45 CFR § 164.514, Other requirements relating to uses and disclosures
• HHS Office for Civil Rights, HIPAA Security Rule notice of proposed rulemaking fact sheet, December 27, 2024
• HHS Office for Civil Rights, Fact sheet on the 42 CFR part 2 final rule, February 2024
• Hyperledger Fabric, Private data
• Linux Foundation, Linux Foundation Decentralized Trust launches with 17 projects, 100+ founding members, September 16, 2024
• GovInfoSecurity, OCR plans do-over for accounting of disclosures proposal, May 15, 2018
• Healthcare IT News, Avaneer Health network gets $50M boost

Frequently asked questions

Can protected health information be stored on a blockchain under HIPAA?

HIPAA does not prohibit it outright, and its amendment rule works by appending rather than erasing. But replication across organizations and retention schedules that end in destruction make storing PHI on a shared ledger a poor design.

Is a hashed patient identifier de-identified under HIPAA?

No. Under 45 CFR § 164.514(c), a re-identification code may not be derived from information about the individual. A hash of a medical record number or Social Security number is derived from it and can often be reversed.

How does Hyperledger Fabric keep private data off the shared ledger?

Fabric’s private data collections store the data only on authorized organizations’ peers and write a hash of it to the channel ledger. The private data can be purged while the hash remains as evidence.