Research note · Reviewed 2026 May · 9 min read

Evaluating blockchain healthcare startups

A structured frame for reading biomedical blockchain startup material without endorsing or dismissing it on first glance.

Evaluation worksheet with categories for scope, deployment, governance, and credibility signals

Evaluating biomedical blockchain startups well is a question of asking the right questions in the right order. The wrong order is starting with the chain choice. The right order is starting with what the project does, who it does it for, and how it operates, then working down to the chain choice late in the conversation. This note describes a structured frame for that reading, designed to be neutral and to surface differences between projects that look similar on a first pass.

None of this constitutes endorsement of any specific project. The directory's posture is descriptive and conservative. The questions below are the ones the directory itself uses when classifying projects and assigning confidence levels.

What does the project actually do

The first question is what the project does at the level of a specific user with a specific job. Not what it could do in principle. Not what its long-term vision implies. What it does now, for whom, and in what setting. A project that can answer this in a paragraph without using the word "platform" is in a better position than one that cannot.

The answer should be testable. Either the project has users who do the described thing, or it is in pilot, or it is in development, or it is a proposal. The categories are not a ranking, but they are different categories, and a project that conflates them is doing its readers a disservice.

What category of work is involved

Different categories of work carry different obligations. A consent receipt tool, an audit log, a credentialing system, a supply chain tracker, a research data registry, and a clinical decision aid sit in different categories with different regulatory, privacy, and safety expectations. A project that operates across categories has to engage with each of them. A project that does not know which category it is in has a problem it has not yet diagnosed.

The directory's industry-focus taxonomy is built around these categories deliberately. The categories are not perfect, but they are stable enough to support comparison. A project that fits cleanly into one category is easier to evaluate than a project that claims to span several.

How is privacy handled

The privacy answer separates the projects that have engaged with the field from those that have not. A credible answer identifies what data is on chain (usually only commitments), what data is off chain, who controls the off-chain storage, how consent is structured and revoked, and how the relevant privacy framework is being engaged. An answer that consists of "the data is encrypted" or "the chain is private" is not engaging with the question.

The framework piece matters because privacy in healthcare is jurisdictional. A project operating in multiple jurisdictions has to address each, and the project that has done so will say which frameworks it is working under and what the implications are. The project that has not is taking on a risk it may not have noticed.

How is identity handled

The identity question is similar. A credible answer separates identifier, credential, and identity proofing. It names the issuers involved. It describes how authentication works for the actual users. It addresses recovery when users lose access. It distinguishes identity from consent rather than collapsing them. An answer that asserts "self-sovereign identity" without engaging with those questions is a slogan, not a design.

What does the project not do

A credible startup pitch includes a clear statement of what the project does not do. Out-of-scope is as important as in-scope. A project that claims to be the platform for everything healthcare is doing something other than serious engineering work. A project that names a specific scope, with specific boundaries, is one whose claims can be evaluated against reality.

The directory categorises ambitious-scope claims conservatively, even when the underlying team is strong. The reason is that ambitious scope tends to evolve over time, and the project that survives is often one that has narrowed deliberately. Narrowing late is fine. Failing to narrow is the warning sign.

Operational signals

A few signals correlate with seriousness without proving it. Documentation that is current and detailed. A change log that reflects actual ongoing work. Conformance testing against the standards the project claims to support. Security disclosures with timely fixes. A team page that describes responsibilities rather than only celebrities. A clear answer to what happens when the project's primary funder or sponsor changes direction.

None of those signals is sufficient on its own. Together they distinguish projects that are operating an enterprise from projects that are running a campaign. The directory weighs them in aggregate when assigning confidence levels.

Token mechanics, where present

Where a project has a token mechanic, additional questions apply. What is the token for, in concrete terms a non-cryptographic reader can understand. How is its value related to the system's utility. How is it treated by the relevant jurisdictions. What happens to the system if the token's market collapses. How does the project distinguish itself from systems that exist primarily to generate token activity.

The directory's posture toward token-flavoured projects is that the token mechanic neither qualifies nor disqualifies. It does add evaluation work that has to be done deliberately. Projects that handle that work clearly are categorised on the same basis as projects without tokens. Projects that handle it poorly are categorised accordingly.

Warning signs without verdicts

Several recurring patterns warrant additional caution. Compliance claims without a specific framework or scope. Privacy claims that consist only of "the data is anonymised." Identity claims that conflate self-custody with self-sovereignty. Endorsement claims without confirmable sources. Hospital, university, or research-centre affiliations stated as ongoing without confirmable sources. Token mechanics framed primarily as wealth creation. Roadmaps that promise transformation without specifying the next quarter.

None of those is a verdict. Each is a signal that the directory weighs when assigning confidence. The directory does not blacklist projects. It categorises them, labels confidence, and lets the reader form their own view.

How the directory uses this frame

The frame above is the basis for the directory's classification work. The industry-focus taxonomy answers the category question. The confidence labels reflect the evidence available about each project. The methodology page describes how the labels are applied and how projects can request review. The intent is to give the reader a structured picture of the field rather than a curated list of recommendations.

If a project's material disagrees with how the directory describes it, the submit page outlines the update process. Confidence labels are adjustable when new evidence is presented. The directory does not, and will not, certify projects.