On Fabric, the hard part of keeping PHI off chain is the hash. Hyperledger Fabric gives a network of payers and providers the tools to keep protected health information out of its blocks. Channels limit who shares a ledger, and private data collections send sensitive records only to the organizations entitled to them. What every peer on the channel receives instead is a hash of each private record, kept as permanent evidence.
That hash is the design’s strength and its weak point. It lets any member prove what was shared and when. It is also derived from health information. HIPAA’s de-identification rule says a code that lets de-identified data be re-identified must not be derived from information about the individual, and a hash of a patient’s request is derived from exactly that. A network that keeps PHI off the chain still has to decide what its hashes reveal and how to make them unlinkable when a relationship ends.
The design described here is a payer and provider network on Fabric, built for prior authorization receipts and decisions, taken layer by layer and then mapped to the HIPAA Security Rule.
Key takeaways
- Channels set the first boundary. Every member of a channel holds the same public ledger, so channel membership is itself a disclosure decision.
- Private data stays with authorized peers. Fabric sends private data directly to authorized organizations, and the ordering service never sees it.
- Purge leaves evidence behind. Since Fabric v2.5, a purge removes private data from state and history while keeping its hash on the ledger.
- The hash needs its own protection. Predictable data should carry a random salt. Destroying every copy of the salt at the end of a relationship makes the remaining hashes unlinkable.
- Endorsement decides who must agree. Key-level policies can require the payer’s signature for a decision and both parties’ signatures for a change to the clock.
- Fabric covers only what it holds. Its controls map onto each technical safeguard for the ledger, but the PHI it does not hold still needs every safeguard.
What the network has to do
Start with the job. A payer and its contracted provider groups touch every prior authorization request, and so do the clearinghouses and review vendors between them. Our piece on shared ledger receipts argued that each of them should write a receipt when a request passes through. The network described here carries those receipts and each later change in status.
The requirements follow from that job.
- No PHI in blocks. Nothing written to the shared ledger should identify a patient.
- Each party sees only its own requests. A provider group should not learn which patients another group has sent to the same payer.
- Proof that both sides can check. A receipt or a decision should be verifiable by the parties to the request without anyone’s permission.
- A clean exit. When a contract ends, a party must be able to return or destroy PHI where that is feasible.
- Keys that stay in hardware. Signing keys should never sit in a file on a server.
The exit requirement shapes everything else. Under 45 CFR § 164.504(e), a business associate contract must require the associate to “return or destroy all protected health information” it still maintains at termination, if feasible. Data written into an append-only chain is the hardest kind to return or destroy. Our January analysis of permissioned ledgers concluded that a ledger should carry the paper trail of PHI rather than the PHI itself. This design starts there and works out the details.
Channels decide who is in the room
A Fabric channel is a private subnet with its own ledger. Every peer that joins a channel receives every block on it. Channel membership is therefore a disclosure decision, made before any data is written.
Fabric’s documentation draws the line between its 2 privacy tools plainly. Channels fit when entire transactions and ledgers must stay confidential to their members. Private data collections fit when transactions are shared among several organizations but only some of them should see part of the data, according to the Fabric documentation on private data.
For a payer network, the natural unit is 1 channel per payer. Its contracted provider groups and vendors join as members. A channel for each provider group would hide even the volume of requests between groups, but it would multiply the channels a payer must run. A single channel for a whole region would be simpler and would expose too much.
Even with no PHI on the chain, the public ledger shows which organizations exchanged requests and when. In a small specialty network, that pattern can say more than it seems. Entries should identify organizations rather than clinicians, and a referral pattern between 2 parties should never be readable by a third.
The ordering service deserves the same scrutiny. Ordering nodes assemble every channel transaction into blocks, so whoever runs them sees what the public ledger holds. They never see private data. Fabric’s Raft ordering tolerates crashed nodes but assumes its operators are not malicious. Fabric v3.0 added an ordering service based on Byzantine fault tolerance, which the project advises using where true decentralization is required, according to its release notes.
In most payer networks, the payer will run the ordering service. Raft is a reasonable choice when the members accept that arrangement. A network whose members do not trust any single operator is the case for the newer option.
What goes on the chain, and what never does
The core of the design is a strict division of data. The table shows where each kind of data lives.
| Data | Where it lives | Why |
|---|---|---|
| Clinical documents and notes | Each organization’s own systems | PHI that must be returned or destroyed when a contract ends |
| Patient and member identifiers | Each organization’s own systems | Directly identifying |
| Diagnosis and procedure codes for a request | Each organization’s own systems | Identifying when combined with dates and providers |
| The salt for each request | Each party’s private data collection on Fabric | Needed by both sides to verify a fingerprint, and removable by purge |
| The request fingerprint, a salted hash | The public channel ledger | Proves which version of a request was sent without revealing it |
| Timestamps and status codes | The public channel ledger | Drive the decision clock that both sides must be able to read |
| Organization identifiers | The public channel ledger | Show which party wrote each entry |
Our proposed design.
The clinical content never enters Fabric at all. It travels the way it does today, through the Prior Authorization API or another channel. What Fabric holds is a set of commitments about that content, along with the salts that give those commitments meaning.
A request’s life on the network
A single request shows how the pieces fit together.
- Submission. The provider’s system sends the request to the payer through the API, as it would today. It also generates a random salt and computes a fingerprint of the request as sent. It writes the fingerprint to the channel and keeps the salt in its own implicit collection.
- Receipt. The salt travels to the payer with the request, outside the ledger. The payer’s system recomputes the fingerprint from what it received. If the 2 match, it writes a receipt entry and stores its own copy of the salt.
- The clock. Chaincode computes the decision deadline from the receipt time and the type of request. Changing that deadline takes both parties’ signatures.
- Status and decision. Each pend or decision becomes a new entry signed by the payer. The decision entry records whether a clinician or an automated rule made it.
- Exit. Each party purges its copy of the salt when its own duty to keep the record ends. The fingerprint and the timeline stay on the ledger, linked to nothing anyone can read.
The fingerprint covers the request exactly as sent. If a document is added or changed later, the new version produces a new fingerprint, so both sides can see which version each entry refers to.
Private data collections
Private data in Fabric travels outside the blocks. It is “sent peer-to-peer via gossip protocol to only the organization(s) authorized to see it,” according to the Fabric documentation. The ordering service “does not see the private data.” A hash of the data is written to the ledger of every peer on the channel, and the documentation says “the hash serves as evidence of the transaction.” Peers use it to validate state, and auditors can use it to check a record.
Collections are defined with a few settings that matter for PHI, described in the private data reference. The memberOnlyRead setting restricts reads to clients of member organizations, and memberOnlyWrite blocks writes from non-members. The requiredPeerCount setting sets how many peers must receive the data before endorsement succeeds, which guards against losing it. The blockToLive setting controls how long the data lives in the private database, measured in blocks.
Since Fabric v2.0, every organization also has an implicit collection of its own. In this design, each party keeps its copy of a request’s salt in its implicit collection. Because the hash of each copy sits on the channel ledger, the other party can confirm that both hold the same value without either revealing it. Applications pass the salt to chaincode in the proposal’s transient field, so it is not recorded in the transaction itself.
Why the hash still needs care
A hash of predictable data can be reversed by guessing. Fabric’s reference recommends adding a random salt to predictable private data, so that “a matching hash cannot realistically be found via brute force.” A request fingerprint built from a member number and a date of service is predictable. With a random salt, it is not.
The legal question is harder. HIPAA lets a covered entity attach a re-identification code to de-identified data only if the code “is not derived from or related to information about the individual,” under 45 CFR § 164.514(c). A fingerprint of a request is derived from exactly that information. The rule does not address ledgers, but it points to a cautious reading. A network should treat its fingerprints as sensitive for as long as anyone holds the salt.
That reading also suggests the exit. Once every copy of a request’s salt is purged, the fingerprint can no longer be matched to the request it came from. Our piece on deleting the key rather than the block made the same argument for encrypted data. Here the salt plays the role of the key.
Purging, and what purge leaves behind
Fabric v2.5, released in March 2023, added a purge feature that “enables purging the history of private data from a peer” while “preserving a hash of the private data as immutable evidence on the blockchain,” according to the release notes. Applications call PurgePrivateData rather than DelPrivateData, because a simple delete leaves the history in the peer’s private database. The feature requires the channel’s application capability to be set to V2_5.
Purge is not instant on every peer. The reference notes that historical values remain in the private database until the next purge interval. For a salt, that delay is acceptable, because the fingerprint stays unlinkable to anyone who did not already hold the salt.
The blockToLive setting is a poor fit for retention rules written in years. It counts blocks, and the number of blocks depends on traffic. A Medicare Advantage organization must keep its records for 10 years under 42 CFR § 422.504(d). A network that serves such plans should purge salts on a schedule tied to the retention rule, or at the end of a contract, rather than on a block count.
A hash proves that something happened. Destroying the salt decides when it stops pointing to anyone.
Who must sign
Every change on the ledger raises 2 questions, who had to sign it and whether those signatures can be trusted. Fabric answers the first with endorsement policies and the second with its identity layer.
Endorsement policies
Endorsement is Fabric’s rule for who must agree before a change counts. Chaincode-level policies are agreed by channel members when they approve a chaincode definition. Collection-level policies can override them for writes to private data. Key-level policies, set from within chaincode, override both for a specific key, according to the endorsement policy documentation.
Key-level policies fit prior authorization well, because different parts of a request’s record belong to different parties.
- The submission entry carries the provider’s signature, since only the provider can say what it sent.
- The receipt and each decision carry the payer’s signature, since only the payer can say what it received and decided.
- The decision deadline cannot change without both signatures, because a clock that 1 party can reset protects no one.
At commit, every peer validates each transaction against the policy for every key it writes. A transaction that touches several keys must satisfy all of their policies. No single party can slip a change into the record that its counterpart has not signed where a signature is required.
Keys and identities
Every organization in a Fabric network has its own membership service provider, usually backed by its own certificate authority. Identities are X.509 certificates. Fabric v3.0 added Ed25519 as a signing algorithm alongside ECDSA.
Signing keys belong in hardware. Fabric uses the PKCS#11 standard to talk to hardware security modules, and peers and orderers can keep their identity keys in an HSM, according to the HSM guide. The same guide notes that TLS keys must be file-based, so they need protection of their own.
A plan’s signature on a decision is evidence in any later dispute. A key that can be copied off a server is weaker evidence than one that never leaves the hardware. When a key is compromised, the organization revokes its certificate. Peers then stop accepting signatures from it.
Mapping the design to HIPAA
The Security Rule’s technical safeguards in 45 CFR § 164.312 apply to electronic PHI wherever it lives. Fabric can meet them for what the ledger holds. The PHI that never enters Fabric still needs every safeguard in the systems that hold it.
| Safeguard | What Fabric provides | What stays with each organization |
|---|---|---|
| Access control | Channel membership, with member-only reads for private data | Access to PHI in its own systems, including emergency access |
| Audit controls | The identity of the signers on every transaction | Logs of who viewed PHI outside the ledger |
| Integrity | Hashes and endorsement that make changes to recorded data detectable | The integrity of clinical records held off chain |
| Person or entity authentication | An X.509 identity for every node and client | Authentication of the people behind each client |
| Transmission security | TLS between nodes | Encryption of PHI sent through APIs and other channels |
Compiled from 45 CFR § 164.312 and the Fabric documentation cited in this analysis.
The bar may rise. HHS proposed in December 2024 to remove the distinction between required and addressable specifications, and to require encryption of electronic PHI at rest and in transit, according to its fact sheet. HIPAA Journal reported in July 2026 that the final rule is now penciled in for July 2027. A network designed today should assume encryption will be required everywhere PHI sits.
HIPAA’s amendment rule already works the way a ledger does. A covered entity amends a record by “identifying the records in the designated record set that are affected by the amendment and appending or otherwise providing a link to the location of the amendment,” under 45 CFR § 164.526. A correction on the ledger works the same way. It is a new entry that references the old one, and the old one stays visible.
What the design does not solve
A ledger does not secure the systems around it. The clinical records in this design live where they live today, and they face the same risks. Fabric protects the evidence about those records, not the records themselves.
Governance remains the hard part. Someone has to admit members and run the ordering service. Someone also has to pay for the nodes. The network also needs a process for an entry that a party believes is wrong. None of those questions has a technical answer.
The 2-party case may not need a ledger at all. Between a single provider and a single payer, a digitally signed receipt does most of the work, as our June piece noted. A shared ledger earns its cost when several organizations touch a request and none of them should be trusted to keep the only record.
Key loss is a real risk. A party that loses its signing keys can lose the ability to act on the network until new certificates are issued, and a party that loses its salts loses the ability to prove what its fingerprints meant. Both need recovery plans that do not undo the purge rules.
Where Redlake stands
Redlake builds tools that health plans use in utilization review. Our rules require that every decision can be reconstructed, and this design is how we think a network of organizations should make that possible. The ledger holds the timeline. Each party holds its own record of the reasons.
A machine can say yes, but only a person can say no. The ledger can record which of the 2 made each decision without recording anything about the patient. Signed by the payer, that single fact would let a provider or an auditor see whether a denial came from a clinician.
Every recommendation shows its reasons. In this design, the reasons stay in the decision record each party keeps, linked to the ledger by a fingerprint that only the parties can read. We think that split, evidence shared and content kept apart, is the right default for any ledger that touches health care.
About this analysis
Method. A design study, drawing on Hyperledger Fabric’s documentation and release notes and on HIPAA’s regulations. No deployed network is described, and no performance figures are reported.
Data notes. Fabric features are described as of the version 3.1 documentation. The legal reading of fingerprints under 45 CFR § 164.514(c) is this analysis’s interpretation, not guidance from HHS. The Security Rule changes described are proposals.
Sources. Hyperledger Fabric documentation (version 3.1). Fabric release notes for v2.5 (March 2023). HIPAA regulations in 45 CFR part 164. Medicare Advantage regulations at 42 CFR § 422.504. HHS fact sheet on the proposed Security Rule changes (December 2024). HIPAA Journal (July 2026 update).
Frequently asked questions
Should PHI go on a permissioned ledger?
In most designs, no. A ledger is hard to amend and harder to erase, while business associate contracts require PHI to be returned or destroyed where feasible. A ledger works best as a record of evidence about PHI held elsewhere.
What does private data purge remove?
Since Fabric v2.5, PurgePrivateData removes private data from a peer’s state and from its private data history. A hash of the data remains on the channel ledger as evidence.
Is a hash of PHI still protected health information?
HHS has not addressed the question directly. HIPAA’s de-identification rule bars re-identification codes derived from information about the individual, which suggests caution. A salted hash whose salt has been destroyed cannot be linked back to the record it came from.
Does the design satisfy HIPAA on its own?
No. Fabric can support the technical safeguards for what the ledger holds. The PHI kept in each organization’s systems still needs its own safeguards.
When is a ledger worth the cost?
When several organizations touch the same request and none should keep the only record. Between 2 parties, a signed receipt usually does the job.