Research note · Reviewed 2026 May · 9 min read

Blockchain around electronic health records

Where ledger designs help with health record exchange, where they get in the way, and the recurring pattern of keeping records off chain while putting commitments and consent on it.

Records exchange diagram with off-chain storage and on-chain commitments

Electronic health records are the area where blockchain projects most often promise the most and deliver the least. The narrative is easy to write: patients hold their records, ledgers track access, exchange becomes friction free, and the long-running interoperability story finally resolves. The reality has been more modest, and the projects that have made progress have done so by being specific about which part of the records problem they were actually addressing.

Records on chain is not the design

The first thing to settle is that putting raw clinical records on a chain is not the design any serious project uses. Records are large, structured, governed, and frequently amended. Public chains are tamper evident but not confidential. Permissioned chains are confidential within their participant set but operationally similar to a shared database. Either way, the clinical record itself stays where it already lives, under the access controls that already govern it.

What does sit on chain are smaller artefacts. Hashes that commit to a specific version of a record. Pointers that resolve to the record in its existing storage system. Capability tokens that authorise access. Consent receipts that document scope. Audit events that record who accessed what and when. Those artefacts are small enough to chain economically and structured enough to be useful.

Where the chain adds something

The clearest contribution is in the audit and provenance layer. Cross-institutional access logs are notoriously hard to reconcile, and a tamper-evident shared log of who saw what has obvious uses for incident response and patient transparency. A ledger that records access events without exposing the underlying data can be inspected by parties whose interests differ from the data custodian, which is most of the point.

The next contribution is in the consent layer. A patient who has authorised a hospital, a specialist, and a research project to use specific subsets of their record has a hard time keeping track of those authorisations in practice. Consent receipts on a ledger let the patient and the parties see a consistent picture of what is currently authorised. Revocation becomes a state change rather than a phone call.

The third contribution is in cross-organisation exchange. A ledger does not generate interoperability, but it can carry the metadata that makes exchange tractable: the identifier of the source record, the version, the access policy, and the participants involved. The exchange itself still uses the established message formats and vocabularies.

Where the chain gets in the way

Records have to be amended. Clinical errors are corrected. New information supersedes older information. A chain that treats every record as immutable can produce a misleading picture if it does not handle versioning carefully. The right pattern is to chain commitments to specific versions and to record the supersedence explicitly. The wrong pattern is to treat the chain as the record itself, which produces a system that cannot represent the most ordinary clinical events.

Patients also have rights to amendment and, in some contexts, to deletion. A chain that cannot accommodate those rights is a chain that cannot operate in clinical environments. The accommodation is usually to keep the data off chain and to handle deletion at the storage layer while leaving a tamper-evident gap in the access log. That works, but it has to be designed in from the start.

Patient-held records and the wallet problem

Patient-held records are a recurring proposal. The premise is that patients hold their own records, or at least the access keys to them, and grant access on demand. The protocol piece of that is workable. The operational piece runs into the same problem as decentralised identity: a meaningful fraction of patients cannot or will not manage keys, devices, and recovery flows. Designs that ignore that fraction produce a system that works for the easy population and fails for the hard one, which is often the population with the highest healthcare needs.

The deployments that have survived in this space invest heavily in custodial and recovery options. They treat the patient-held model as a design ideal rather than a universal requirement. They build for the populations that can use the model and design fallbacks for those who cannot. The covered fraction grows over time. The fallbacks remain.

Integration realities

A records project that does not integrate with existing record systems is a records project that does not have records. The integration work is the heart of the problem. Vocabularies have to be mapped. Identifiers have to be resolved. Message formats have to be supported. Conformance has to be tested. None of that is exotic, and none of that is optional. Projects that have an integration strategy tend to make progress. Projects that present integration as a future phase tend not to.

The chain choice is downstream of the integration strategy, not upstream. A project that picks a chain and then tries to figure out integration usually ends up redesigning the chain choice once the integration constraints are understood. The reverse order, integration first and chain choice second, produces less rework.

Patterns that have held up

The recurring pattern in projects that have produced something useful is unglamorous. Off-chain storage. On-chain commitments and consent. Audit logs whose access controls differ from the data's access controls. Explicit versioning. A patient-held layer with custodial fallbacks. Integration with the existing exchange standards rather than around them. A clear statement of what the project does and what it does not.

The patterns are not exclusive to blockchain. They are good practice in any cross-institutional records project. The ledger adds tamper evidence and shared state to that practice. It does not replace the practice.