Blockchain for Healthcare Data: Consent, Audit Trails and Where It Actually Fits

The healthcare platform we've shipped has no blockchain in it. We built the patient portal for Diverse Community Healthcare: appointment booking, telemedicine, EHR integration and HIPAA-aligned access controls. A ledger wouldn't have made any of that better, and it would have made the compliance review harder.

That isn't a dismissal of the idea. There's a narrow set of problems in health data where a shared ledger genuinely helps, and a much larger set where it does damage. This post tries to draw that line clearly, from the point of view of engineers who build both blockchain systems and ordinary healthcare software. It isn't legal advice. Anything touching HIPAA or GDPR needs your own counsel to sign off on it.

Patient data never goes on chain

Start with the rule that rules out most of the pitches you'll hear. Protected health information does not belong on a blockchain, encrypted or not.

The reasons are mechanical. A blockchain replicates every record to every node, and it's designed so records can't be removed. Health data law assumes the opposite. GDPR's Article 17 gives people a right to erasure in many circumstances. HIPAA doesn't grant a general deletion right, but it does require covered entities to limit who can see PHI, and it lets patients request amendments to their records. A system where every participating node holds a permanent copy of a diagnosis fights all of that.

Encryption doesn't rescue it. Ciphertext on a public or widely shared ledger is there forever, and keys leak or outlive the algorithm protecting them. Data that's safe under today's encryption may not be in twenty years, and medical records stay sensitive for a patient's whole life. Writing encrypted PHI to a ledger is betting that no key involved is ever compromised, ever.

Hashes need care too. A hash of a full clinical document is fine as a fingerprint. A hash of a low-entropy value is not: date of birth plus postcode has few enough possible combinations that anyone can compute all of them and reverse the hash. Under GDPR, a hash that can be linked back to a person may still count as personal data. Our approach is to salt every commitment with a random value stored off chain alongside the data, so the on-chain value is meaningless without it. Deleting the salt then breaks the link between the chain and the person. Whether that satisfies an erasure request is a legal question, not a technical one, so treat it as a design choice to put in front of counsel rather than a guarantee.

What a ledger can do well

Once PHI is off the table, what's left is metadata about who was allowed to do what, and proof that it happened. That's where the useful cases are.

The strongest one, in our view, is tamper-evident access logging. The HIPAA Security Rule requires audit controls that record activity in systems holding electronic PHI, and every serious EHR keeps an access log. The weakness is that the log lives with the organisation being audited. If an insider looks up a neighbour's chart and an administrator later edits the log, there's no independent record. Periodically computing a Merkle root over the access log and anchoring that root to a ledger fixes this cheaply. Any later edit to a logged entry no longer matches the anchored root. No patient data leaves the building, and a single organisation can do it on its own by anchoring to a public chain. That's the same pattern we used in Blokstorage, where files stay off chain and only proof records are anchored.

Consent is the second. HL7 FHIR already has a Consent resource for recording that a patient allowed a given provider to see a category of records for a period. When consent is shared across organisations, the hard part is revocation: every party needs to see the current status, and nobody should be able to claim later that a revocation never arrived. A ledger entry per consent change (a salted hash of the Consent resource, its status and the signatures of the parties) gives every provider the same answer to "is this consent still in force?"

There's a trap here. A consent record can itself reveal sensitive facts. A consent to share records with a substance use treatment programme tells you something about the patient even if no clinical data is attached. Identifiers on chain need to be pseudonymous and different for each relationship, so nobody can line up a patient's consents across providers by looking at the ledger.

Third, sharing receipts. When provider A sends a record bundle to provider B, both sign a hash of the payload and the receipt goes on chain. Later disputes of the "we never received it" or "that's not what you sent" kind become answerable.

Fourth, and smaller, research provenance. Anchoring the hash of each dataset version used in a study lets anyone check later that the published analysis ran on the data the protocol said it would.

Patient-centric access, honestly

The most popular pitch in this area is "patients own their health data on the blockchain." Usually that means the patient holds a private key and signs every grant of access with a wallet.

It sounds good until you walk through a real week at a clinic. Patients lose phones and forget recovery phrases. An unconscious patient in an emergency department can't sign anything, so every design needs a break-glass path, and that path becomes the real access model. Children and patients with cognitive decline need delegated access through caregivers or legal guardians, so key management has to cover relationships as well as people. And anyone who has run user support for wallets knows how much help a key-based system needs. Through EOS Support we've closed more than 2,700 support tickets for blockchain users, and much of that work was helping people with wallets, accounts and transactions. Put that burden on patients and front-desk staff and you get a system nobody uses.

Our view is that patient-held keys can work for narrow, optional cases such as opting into a research programme, where a lost key costs the patient an opt-in rather than access to care. For clinical access, the patient-centric part should be the experience: a portal where people can see who looked at their record, grant and revoke sharing in plain language, and get a straight answer. The cryptography can sit behind that, held by institutions that have a security team.

The architecture we'd use

If several independent providers needed a shared consent registry or a cross-organisation audit trail, this is roughly how we'd lay it out.

PHI stays where it already lives, in each provider's EHR. Applications reach it through FHIR APIs, with SMART on FHIR handling app authorisation. A consent service writes FHIR Consent resources and, for each change, posts a salted hash with the new status to the ledger. Each provider's access log is rolled up into Merkle roots on a schedule (hourly is plenty) and anchored. Sharing receipts are signed by both sides and anchored the same way.

The ledger itself is small. For a group of known health systems or a regional exchange, a permissioned network where each member runs a node is the obvious choice: nothing on it is public, and membership mirrors the legal agreements that already exist between the providers. If the only goal is tamper evidence for one organisation's logs, skip the consortium and anchor roots to a public chain. Nobody can learn anything from a Merkle root.

Most of the effort lands off chain anyway: identity matching between providers, consent UX, key custody for each institution, and the integration work with each EHR. The ledger is maybe a tenth of the project. If a vendor's plan has those proportions reversed, ask why.

Why the portal we built has no ledger

Back to the Diverse Community Healthcare portal. It's a patient-facing access layer: secure login, appointment booking for in-person and virtual visits, telemedicine, and access to health records through integration with the clinical systems behind it. One organisation runs it and is accountable for it.

That last point decides everything. When a single operator owns the data and the system, the trust problems are handled by the normal toolkit: authentication and access control, audit logging in the systems of record, encryption, and contracts with the vendors who touch PHI. A ledger would have added another component to the security and privacy review and given patients nothing they could see or use. Spending that effort on booking and telemedicine that work reliably was the right call. (The infrastructure side of that kind of platform is a separate topic, covered in our post on cloud technology in healthcare.)

Where would we add one? If that portal became one of several independent providers sharing patients, and those providers needed a common answer to "who accessed this record, and under which consent," a shared audit trail anchored to a ledger would earn its place. The trigger is multiple organisations that need a record none of them controls alone. Until that exists, a well-run database is the more honest engineering.

If you're weighing a ledger for consent or audit in a health system, talk to us. We'll start by asking who else needs to trust the record.