Designing sovereign medical data systems

Most medical-data systems are built backwards. The hospital owns the database. The patient logs in to see their own data as a favour. When the hospital changes vendors, the data is held for ransom by the previous one. When the vendor folds, the data is gone.

We started BioVault on the premise that this is the wrong default. Below is how we are thinking about the rebuild — what "sovereign" actually means in code, and where Argentine law, EU regulation, and the wider self-sovereign-identity literature converge with the engineering decisions.

The three roles

Any medical-data system involves at least three roles, and they should be cleanly separated in the architecture:

1. Steward — the person the data is about. The patient.
2. Custodian — the entity that operates the storage and indexing. A hospital, a lab, a clinic, a research consortium.
3. Consumer — the entity that needs to act on the data. A doctor in another country, a clinical trial, an insurer.

In legacy designs the custodian holds all three roles at once. That conflates ownership with operations and creates the wrong incentives at every layer. Sovereign design separates them by construction — the same separation Christopher Allen articulated in the 2016 "Path to Self-Sovereign Identity" essay that quietly shaped most of the decentralised-identity work since.

What "sovereign" actually means here

Sovereign does not mean self-hosted. It does not mean blockchain. It means the steward retains the rights that cannot be delegated — the right to know who accessed the record, the right to revoke access, the right to take the data with them when the relationship ends.

Those rights become enforceable when the system is designed for them. They are aspirational until then.

Concretely:

• Encryption keys are held by the steward, with recovery shares delegated to trusted parties they choose (family, lawyer, family doctor). The pattern follows SSSS / Shamir Secret Sharing the way Casa and Unchained use it for crypto custody, repurposed for medical records.
• Access logs are append-only and visible to the steward in real time, not "available on request within 30 business days". The European Health Data Space regulation is heading in this direction at the policy layer; the engineering work has to follow.
• Revocation is one click and propagates within seconds. Not a paper form mailed somewhere.
• Export produces a complete, portable, machine-readable copy of every record the steward has ever owned. HL7 FHIR is the obvious format, even when it is awkward.

The audit trail is the product

Trust in a medical system is built on evidence, not promises. The single most important feature is not the UI, not the analytics, not the integrations. It is the audit trail.

If the patient cannot prove who looked at their record yesterday, the system has failed already.

Every read is an event. Every write is an event. Every consent grant is an event. Every revocation is an event. The trail is append-only, signed, and visible in two places: the steward's dashboard and a secondary witness the custodian cannot tamper with.

This is also where on-chain logging earns its place — and only where it earns its place. Not for the medical record itself (that stays off-chain, encrypted), but for the proof of access. A signed hash of the access event, anchored to a chain the patient can verify independently, gives the steward a recourse that does not depend on the custodian's goodwill. W3C Verifiable Credentials is the standard worth following here.

Compliance is a floor, not a ceiling

In Argentina, the relevant frameworks are Ley 26.529 (patient rights), Ley 25.326 (data protection) and ANMAT's regulatory requirements when devices or trials are involved. In the EU, the General Data Protection Regulation Article 9 treats health data as a special category. In the US, HIPAA's Privacy Rule sets the baseline. None of these were written with sovereign architectures in mind.

The mistake is to design to the law and stop. The law is a floor.

The questions to ask above the floor are simpler and harder:

• If our company disappeared tomorrow, can the patient still access their data?
• If the custodian is acquired by a hostile party, what can they actually do with the data?
• If a regulator subpoenas a record, who is told?
• If the patient changes their mind in five years, can they erase everything?

A system that has good answers to those four questions is sovereign. The legal compliance falls out of the architecture, not the other way around.

What we will not do

A few things we have written down as non-negotiable:

• We will not send identifiable patient data to a third-party LLM, ever. Reasoning over medical records happens on infrastructure we control, with models we host or with vendors under a real BAA-equivalent contract. Anthropic's data usage policy is good but not sufficient.
• We will not introduce a "trust us" feature. If a feature depends on us being honest, the patient cannot verify, and the feature does not ship.
• We will not let the custodian see data they do not have an active, logged, time-bounded consent for. Not even for analytics. Not even anonymised — anonymisation in medical data is famously thin protection once you have any auxiliary data.

These constraints look painful on paper. In practice they are what makes the system worth building. Anyone can build a CRM for hospitals. Few will build infrastructure the patient actually owns.

Where we are

BioVault is in study-case phase, working with a small set of partners on the access log + consent layer first. Storage and search come second; integrations come third. The order matters: getting the rights model right is what gives every other layer its credibility. Reverse the order and you end up with another EHR.

If you are working in this space and any of the above resonates, write to us. We are picky about who we build with, but we are listening.

Further reading

• Path to Self-Sovereign Identity — Christopher Allen, 2016. The essay that named the category.
• W3C Verifiable Credentials Data Model 2.0. The standard our access-log signatures align with.
• European Health Data Space — official explainer. The policy framework most aligned with what we are building.
• Estimating the success of re-identifications in incomplete datasets — Rocher, Hendrickx, de Montjoye (Nature Communications, 2019). On why "anonymised" is rarely enough.

>  end of article · v0.1 · 2026