Health data privacy and consent on shared infrastructure

Privacy is the first place biomedical blockchain projects either earn credibility or lose it. The architecture decisions made in the privacy and consent layer almost always set the ceiling for everything that comes after. A project that gets the consent model right can usually find workable answers to identity, audit, and interoperability. A project that hand-waves the consent layer rarely recovers.

The simple version of the problem is that healthcare records are sensitive, the regulatory expectations around them are non-trivial, and the parties who hold them have reasons to share some of the contents some of the time. The hard version is that "consent" in this domain is not a single thing. It is a stack of overlapping authorisations, jurisdictional rules, and clinical workflows that have to coexist. A ledger is only useful here if it engages with that complexity rather than reducing it to a single signature.

What goes on chain and what stays off it

The first decision in any credible design is what actually touches the ledger. Sensible projects keep the underlying clinical data off chain entirely. The on-chain footprint is restricted to commitments, hashes, pointers, capability tokens, or consent receipts. The data itself stays in the storage system that already has the right access controls and the right operational posture.

This boundary is not a stylistic preference. It is forced by a combination of technical and regulatory facts. Public chains are tamper evident but not confidential. Permissioned chains are confidential within their participant set but not invisible to participants. Either way, raw protected health information on chain is a bad idea, and the projects that have tried it have either narrowed the design or quietly shelved it.

Consent is not a single signature

A useful consent model for biomedical data has several distinct elements. There is the patient or research participant's authorisation, which is the document people usually point to. There is the scope of the authorisation, which describes what data, for which purposes, by which parties, and for how long. There is the revocation path, which states how the authorisation can be withdrawn and what happens to copies of the data that have already been released. There is the audit log, which records what was actually done and by whom.

Static consent forms tend to collapse those elements into one document. That works for the moment of signing but does not survive contact with cross-institutional data sharing. A ledger-backed approach can keep the elements separate: the authorisation as a verifiable credential, the scope as a structured policy, the revocation as a state change, and the audit as a tamper-evident log of access events.

None of that is automatic. The project has to design each element deliberately. The recurring failure mode is to encode the authorisation cleanly and then leave the scope, revocation, and audit elements implicit. The result is a system that looks rigorous but cannot answer the questions a regulator actually asks.

Privacy guarantees and their limits

Cryptographic tools can carry real privacy guarantees. Hashes commit to data without revealing it. Zero-knowledge proofs allow assertions about data without exposing the data itself. Capability tokens can be scoped to a single purpose and a single recipient. Selective disclosure credentials can reveal age without revealing date of birth.

Those primitives are useful, but they are not a privacy programme. A project still has to decide which fields warrant which treatment, how identifiers are generated and rotated, how re-identification risk is managed when datasets are combined, and how the consent state is interpreted when an authorisation references data that no longer exists in its original form. Cryptography helps, but the privacy programme is mostly governance, with cryptography as a load-bearing component.

Audit trails versus surveillance

Audit logging has to walk a careful line. The point of the audit trail is to detect misuse and to support accountability. The risk is that a comprehensive log of every access event becomes, in effect, a surveillance database. The mitigations are familiar: minimise what the log records, separate the log's access control from the data's access control, and make sure the audit is reviewable by parties whose interests differ from the data custodian.

Ledger-backed audit logs make tampering hard, which is the point. They do not, by themselves, make the audit log appropriate. A poorly designed log is still a poorly designed log, even when it is tamper evident.

Regulatory context

This site is not a legal resource. It does not give regulatory advice and does not interpret specific privacy law for specific situations. The general posture, however, is that any biomedical blockchain project handling identifiable health information needs to engage seriously with the relevant privacy framework. In the United States that includes the rules and guidance summarised in the federal health information privacy guidance, alongside any state-specific rules, research-specific frameworks, and institutional policies.

Internationally, the picture is even more layered. Projects that operate across jurisdictions usually find that the harder constraint is not the technology but the legal interoperability of the consent terms across the parties involved. A consent model that works inside one regulatory regime can become unworkable the moment a second regime is introduced. That is a governance problem, not a ledger problem.

Patterns that hold up

A few patterns recur in projects that hold up under review. Data minimisation by default. Off-chain storage with on-chain commitments. Granular scopes attached to verifiable credentials rather than monolithic consent. Revocation paths that are tested, not just declared. Audit logs whose access controls differ from the data's access controls. A clear statement of what happens when the chain itself changes.

None of those patterns are exotic, but together they distinguish the projects that have something to show from the projects that have only a deck. The same patterns underpin the related work on decentralised identity and the records track, since identity, consent, and records cannot be separated cleanly in practice.

Where to go from here

For the standards picture that sits underneath these patterns, see the standards note. For the practical implementation issues around records, the EHR note goes deeper. For directory-level context, the methodology page describes how the directory treats privacy and consent claims that cannot be confirmed from primary material.