Digital health software in regulated contexts
Where blockchain-flavoured tools sit inside the broader regulated software picture, and which claims warrant particular caution when evaluating biomedical blockchain projects.
Regulated software is the part of the field where caution earns its keep. Biomedical blockchain projects often touch the perimeter of regulated software, sometimes by accident. Misreading where that perimeter sits is one of the more reliable ways to get a project into trouble it could have avoided. This note is not regulatory advice. It is a description of how the regulated software picture interacts with the kinds of designs common in biomedical blockchain.
Not all healthcare software is regulated the same way
The first thing to notice is that "healthcare software" is not a single category. Wellness apps, administrative tools, clinical decision support systems, and software embedded inside medical devices sit on very different regulatory shelves. A workflow tool that schedules appointments and a system that influences a treatment decision are not comparable in the eyes of any serious regulator, even if they look similar in a screenshot.
Biomedical blockchain projects can sit on any of those shelves. A consent receipt tool typically does not. A supply chain track-and-trace system for pharmaceuticals usually has its own dedicated regime. A patient-controlled records project that starts to make recommendations about care can drift into a different category than it began in. The drift is what tends to catch projects off guard.
Where the perimeter usually sits
A useful rule of thumb is to ask whether the software is intended to inform a clinical decision, automate a clinical action, or otherwise influence the diagnosis, treatment, or management of a patient's condition. If yes, the project is closer to the regulated perimeter and needs to engage with the relevant regulatory framework deliberately. If no, the project is generally further from the perimeter, although other regimes around privacy, billing, or device interoperability may still apply.
For a federal-level overview of the regulator's framing in the United States, the digital health policy context page is a reasonable starting point. It does not answer specific questions about specific products, but it sets out the categories and the rationale clearly.
How blockchain features interact with regulatory expectations
A few common patterns in biomedical blockchain projects deserve specific care. Tamper-evident logs are useful for audit and incident response, but they do not by themselves satisfy quality system or post-market surveillance expectations. Verifiable credentials can support identity proofing, but they do not replace whatever access control or training requirements the regulated workflow already has. Smart contracts that automate parts of a workflow have to be evaluated as software changes, with the same change control discipline expected of any other update.
The risk is that the cryptographic guarantees lull a project into thinking the regulatory and quality system work has been done. It has not. The ledger proves what happened, not that the design that produced it was fit for purpose.
Claims that warrant caution
Several claims appear regularly in healthcare blockchain marketing and tend to deserve a closer look. Claims that a product "replaces" a regulated process. Claims that on-chain audit trails make a separate quality system redundant. Claims that decentralisation removes the need for a responsible party. Claims that token-based incentives produce clinically meaningful behaviour change. Claims that the product is "compliant" without naming the specific framework, version, and scope.
None of those are automatically false, but they are claims that should be supported by something more substantial than a deck. The directory treats them as the project's own claims and labels confidence accordingly when independent confirmation is missing.
What credible engagement looks like
Projects that engage seriously with the regulated software picture tend to share a few habits. They distinguish between what their product does and what an adjacent system does. They name the standards and frameworks they conform to, with version and scope. They describe their change control and configuration management. They treat security incidents and post-market surveillance as ongoing obligations, not a one-time exercise. They are realistic about which clinical decisions their product touches.
That posture is not unique to blockchain projects, but it shows up disproportionately in the projects that survive a regulator's review without surprises. It also tends to correlate with the projects that integrate well with existing clinical IT estates, because regulators and IT directors are looking for many of the same signals.
Where blockchain sits in the regulated picture
The honest summary is that a ledger does not change a project's regulatory category. A wellness app that adds a chain is still a wellness app. A clinical decision support tool that adds a chain is still a clinical decision support tool. The category is set by what the product does, who uses it, and how it influences care. The ledger is an implementation detail, important for some questions and irrelevant for others.
This framing is useful when reading project pitches. The chain choice is rarely the most consequential decision in the architecture. The far more consequential decisions are about scope, intended use, integration surface, and the responsibilities the project's operators are taking on.
Where to read next
For the privacy and consent picture that runs underneath this material, see privacy and consent. For the standards layer the regulated software picture sits on top of, see the standards note. For directory-level handling of regulatory claims, see the methodology page, which describes how the site treats compliance assertions that cannot be confirmed from primary material.