Decentralised identity in healthcare

Decentralised identity is one of the parts of the field where the protocol work has run noticeably ahead of the deployment work. The specifications are real, the tooling exists, and the use cases in healthcare are recognisable. The harder question is whether the identity infrastructure can survive contact with the clinical workflows it is supposed to help. The honest answer is that some of it can, and some of it cannot, and the distinction is not always intuitive.

Identifier, credential, and identity proofing

It helps to separate three things that get blurred together. An identifier is a stable name for an entity. A credential is a signed statement about that entity, issued by some authority. Identity proofing is the process that links the identifier and the credentials back to a specific real-world person, organisation, or device. The three are related but not interchangeable, and the design questions for each are different.

The relevant protocol stack is mature enough that the identifier layer can be treated as settled for most purposes. The reference specification is the decentralized identifier standard, which defines how identifiers can be created and resolved without depending on a single central authority. That is useful, but it is not the same as identity proofing, which still has to be done by someone with the authority and the operational discipline to do it.

What works in healthcare identity

The strongest fit is provider credentialing. Clinicians move between hospitals, jurisdictions, and roles. Their licensure status, board certifications, and continuing education records are exactly the kind of statements that benefit from being verifiable, portable, and revocable. Verifiable credentials issued by licensing boards and educational institutions can be presented selectively, checked offline, and revoked when the underlying status changes. The current paper-and-PDF workflow is inefficient enough that even a partial improvement saves real time.

Patient identity is harder. The identifier piece is tractable. The credential piece is workable for some categories, such as insurance enrolment or research participation. The identity proofing piece is where the workflow tends to stall, because the operational realities of clinical onboarding involve people who do not have stable credentials, devices, or comfort with key management. A protocol that assumes the patient holds their own keys runs into populations who cannot or will not hold them, and the fallback plan has to be designed in from the start.

Identity is not consent

A second framing error is treating identity and consent as the same problem. They are not. Identity establishes who is making a claim or accessing a resource. Consent establishes that the claim or access is authorised. The two systems interact constantly, but the boundary between them is real. Conflating them produces designs in which a successful identity proof is treated as a blanket consent, which is exactly the failure mode that consent frameworks were built to prevent.

The cleaner architecture keeps identity and consent in separate planes. Identifiers and credentials manage who the parties are. Consent receipts and capability tokens manage what they are allowed to do. Audit logs record what they did. The three planes can be linked, but they are not collapsed.

Authentication, authorisation, and the protocol gap

The identity protocols on their own do not perform authentication or authorisation in the usual sense. A decentralised identifier resolves to a document. A verifiable credential is a signed statement. The pieces that decide whether a presented credential is acceptable, whether the presenter is currently authorised, and whether the action requested is in scope still have to be implemented by the relying party. Projects that under-invest in that gap can present identity claims and still get the policy decisions wrong.

That gap is particularly visible in healthcare because the access control models are intricate. Role-based access, attribute-based access, break-glass overrides, jurisdiction-specific exceptions, and research-specific allowances coexist. A decentralised identity layer can carry many of the inputs to that policy machinery. It does not replace the machinery itself.

Risks of over-claiming

Several over-claims appear regularly. That decentralised identity "puts patients in control" of their data, when in practice control is heavily mediated by issuers, verifiers, and the institutions that actually hold the records. That self-sovereign identifiers eliminate the need for trusted issuers, when in fact issuer trust is exactly the thing that makes a credential useful. That zero-knowledge proofs solve the identifiability problem in research, when in fact identifiability is mostly a function of the data itself, not the identity protocol.

None of those claims are entirely wrong, but they tend to be stated in stronger forms than the underlying technology supports. The directory's posture is to treat them as the project's framing rather than confirmed properties of the system.

Deployment patterns that survive

The deployments that have held up tend to do a few things consistently. They start from a narrow population where the operational realities can be controlled. They invest in issuer infrastructure rather than treating it as someone else's problem. They build their relying party machinery deliberately. They have a serious answer for key management and recovery, including for users who lose phones, change devices, or stop engaging entirely. They keep the identity layer separate from the consent layer.

The deployments that have not held up tend to invert one or more of those choices. They assume universal device ownership. They underestimate issuer governance. They collapse identity into consent. They treat key recovery as an afterthought. The pattern repeats often enough to be predictive.

Where to go next

For the privacy posture that interacts with identity at every step, see privacy and consent. For the standards layer that the identity stack sits inside, see the standards note. For directory-level treatment of identity projects, see the methodology page, which describes how the site categorises identity work alongside the rest of the field.