The biomedical blockchain landscape

Biomedical blockchain has a credibility problem that it largely inflicted on itself. A decade of presentations promising that ledgers would fix interoperability, eliminate medical errors, and put patients in control of their data has left clinicians, IT directors, and research leads slightly allergic to the term. The interesting work in the field deserves better, because the interesting work is narrower than the marketing has ever made it sound and it survives a closer look.

This note maps the field as it actually behaves. It avoids the temptation to treat every healthcare data problem as a candidate for a ledger. It pays attention to where the approach saves real work, where it merely shifts work somewhere harder to audit, and where it is being used as a stand-in for governance that no one wanted to write down.

The four properties that make a ledger useful

The strongest filter for whether a biomedical project is well-served by a ledger is the combination of four properties. The parties involved do not fully trust each other. The history needs to be tamper-evident, not just protected. The timing of events matters in a way that a single party's clock cannot settle. And there is at least one identifier or pointer that has to be shared across organisations without exposing the underlying data.

When those properties line up, the design space opens. Clinical trial event records, where sponsors, sites, and contract research organisations have legitimate reasons to disagree about exactly when an amendment took effect. Verifiable credentials for clinicians who move between hospitals and need their licensure history to travel with them. Consent receipts that have to survive a vendor migration intact. Track-and-trace metadata for pharmaceuticals where the supply chain is genuinely multi-party.

When the properties do not line up, the ledger is overhead. A patient portal with one provider, one storage system, and one regulator does not need a distributed ledger any more than it needs a multi-cloud failover. The same applies to most internal hospital workflows. The bottleneck is rarely tamper evidence; it is data quality, integration cost, and clinician time.

What the field does not solve

A ledger does not turn bad data into good data. If a measurement enters the chain wrong, it stays wrong, and the chain just makes the error more durable. A ledger does not replace interoperability standards. It does not remove the need for a vocabulary and a model that two systems agree on. A ledger does not perform clinical validation, regulatory compliance, or privacy review on the team's behalf. Those obligations still belong to the people running the system.

This matters because most failed biomedical blockchain projects fail at one of those boundaries. They assume the chain will paper over an interoperability gap, or they treat the cryptographic guarantees as a substitute for the legal and governance arrangements they were supposed to encode. The chain proves what happened. It does not prove that what happened was right.

Where the strongest implementations sit

Look across the projects that have stayed alive for more than three years and a pattern emerges. They tend to be narrow. They tend to put very little on chain. The chain holds pointers, hashes, or commitments, not raw clinical data. Identity proofing, consent state, and audit metadata are the most common payloads. The actual records stay in their existing systems, governed by the same access controls they already had.

This is consistent with the broader literature on biomedical blockchain with practical implementations, which tends to find that the durable use cases are the ones that resisted the temptation to put everything on chain. The same paper trail also makes clear how much of the early ambition was undermined by trying to use ledgers as general-purpose databases. That is not what they are good at, and the projects that learned the lesson the hard way produced the cleaner second-generation designs.

How to read project claims

A few heuristics survive contact with real projects. If the marketing language emphasises tokens before workflows, the project is probably more interested in fundraising than infrastructure. If the architecture diagram puts clinical records on chain, the project either has not thought carefully about privacy or is using the word "record" loosely. If the consent model is described in a single sentence, it is almost certainly underspecified.

The stronger signals are quieter. A clear statement of what is on chain and what is off chain. A consent model that names the parties and the revocation path. An integration plan with at least one existing standard that clinicians already use, even if reluctantly. A description of how the project behaves when the underlying chain forks, halts, or sunsets. None of those are exciting, which is part of why they are reliable.

The categories worth watching

Several categories continue to produce work that holds up. Consent and access management, where verifiable receipts and granular scopes give patients and research participants something they cannot get from a static signed PDF. Clinical trial integrity, where timestamped protocol versions and event commitments make audit prep noticeably less painful. Decentralised identifiers for clinicians, where the credentialing problem has been ugly for decades and the protocol stack now exists. Healthcare supply chain, particularly for high-value pharmaceuticals, where the multi-party logistics genuinely benefit from shared tamper-evident records.

Other categories remain harder. Patient-controlled records have produced a long list of interesting prototypes and a much shorter list of deployments that have survived contact with clinicians. Genomic data marketplaces face hard limits from the identifiability of the underlying data, regardless of the chain choice. Tokenised health incentive schemes have not produced durable health outcomes in any of the published studies, although the marketing of them remains energetic.

What this site does with the field

The directory side of this site treats those categories as the primary axis. The research notes provide context for each. The methodology page describes how projects are categorised and how confidence labels are applied. The combination is meant to be useful to people who actually have to evaluate this work, whether for procurement, research design, or simple curiosity.

For the supporting material on standards and implementation, see the standards note. For the privacy and consent track, see health data privacy and consent. For the identity layer, the decentralised identity note covers what works and what does not. The trial integrity note and the records note cover the two domains where most of the durable implementations have landed.

Reading list and next steps

If you are new to the field, the shortest useful path is to start with the standards note, move to privacy and consent, and then pick the domain note that matches the problem you actually need to solve. The directory will give you a sense of who is working on each category. The methodology page will tell you how to read the confidence labels without over-interpreting them.