Health Records
Who owns your health data — you, or the institutions that hold it?
In the current system, health records live in hospital databases, insurance systems, and clinic EMRs. The patient is the subject of the data but rarely the controller. Sharing requires faxes, portals, and authorizations that expire, get lost, or get ignored. The patient cannot revoke access. The institution cannot prove they haven't shared.
Blockchain changes the ownership question, not the storage question. The data still needs to live somewhere reliable. The question is who holds the key.
The Architecture
Four Sui components, each solving a different piece:
| Layer | Component | Job |
|---|---|---|
| Identity | identity Move module | Patient's verifiable identity — who are you? |
| Storage | Walrus | Where does the data live? (encrypted blobs, epoch-based) |
| Access control | Seal | Who can decrypt it? (on-chain policy, IBE) |
| Computation | Nautilus TEE | Who can compute on it without seeing it? |
The key property: the hospital never holds the decryption key. They hold ciphertext only. Seal releases keys directly to authorized parties based on on-chain policy — the app server is not in the key distribution path.
Data Flow
1. Patient creates Identity object
identity module → unique patient_id on-chain
2. Provider uploads health record
Encrypted with patient's Seal public key before upload
Walrus stores ciphertext → returns blob_id (permanent reference)
blob_id recorded on-chain linked to patient_id
3. Patient creates access policy
Seal policy object: "DoctorCap issued by patient → can request key"
Only the patient can issue, modify, or revoke this capability
4. Doctor requests access
Presents DoctorCap + patient identity
Seal verifies on-chain policy
Seal releases decryption key directly to doctor
Move event logged — access permanently recorded on-chain
5. Doctor decrypts locally
Plaintext never touches app server
Record viewed in authorized client only
6. For computation (diagnosis, risk modeling)
Nautilus TEE receives encrypted blob
Computes inside secure enclave — plaintext never exposed to system
Posts AttestationObject on-chain proving the computation ran correctly
Access Policy Types
Seal supports multiple policy models for different clinical contexts:
| Context | Policy type | How it works |
|---|---|---|
| Primary care | Capability (DoctorCap) | Patient issues cap to named provider |
| Emergency access | Time-limited | Decrypt allowed until clock::timestamp_ms > expiry |
| Research (de-identified) | Threshold | M-of-N consent holders required |
| Insurance review | Time-limited + capability | Insurer holds cap valid for 30-day review window |
| Family consent | Multi-address | Multiple guardians must approve |
The patient controls which policy applies. They can issue new capabilities, revoke existing ones, and set time limits — all via Move transactions.
Walrus Storage
Walrus uses Red Stuff erasure coding — the same family as RAID but distributed across a network of storage nodes. Data survives up to 2/3 node failure. Epoch-based availability: set the epoch length at upload time. For health records, long epochs (52+ weeks) are appropriate.
| Record type | Typical size | Epoch recommendation |
|---|---|---|
| Structured record (JSON) | 1 KB – 100 KB | 52+ epochs (patient lifetime) |
| Lab results, imaging reports | 100 KB – 1 MB | 52+ epochs |
| DICOM imaging (MRI, CT) | 10 MB – 500 MB | 52+ epochs — cost is significant |
| Wearable telemetry batches | 1 KB – 10 MB per batch | 4–12 epochs (operational window) |
Cost scales with data volume × epoch length. A structured record at 52 weeks is negligible. DICOM imaging at patient-lifetime epochs requires a meaningful cost model upfront.
Regulatory Alignment
This architecture addresses specific HIPAA-equivalent requirements:
| Requirement | How this architecture satisfies it |
|---|---|
| Data encrypted at rest | Walrus stores ciphertext only — Seal encrypts before upload |
| Access audit trail | Move events record every Seal key request permanently |
| Minimum necessary access | Policy scopes — time-limited and capability-bound access |
| Patient right to revoke | Patient revokes DoctorCap via Move transaction |
| Computation integrity | Nautilus TEE attestation proves correct computation |
What this architecture does not provide: compliance certification, legal advice, or guarantee against regulatory interpretation. Architecture satisfies technical requirements — legal review is separate.
The Key Question
Does the patient ever need to trust the app server to protect their data?
If yes — the Seal policy is wrong. The architecture should work correctly even if the app server is compromised. Seal enforces access at the cryptographic layer. No key management on the server side means no breach vector from server compromise.
This is the design test for any health data architecture on this stack: when the server goes down, or gets hacked, or gets a government subpoena — does the patient's data remain private? With Seal, the answer is yes. The server never held the key.
Context
- Sui Protocols — Full protocol stack (Walrus, Seal, Nautilus)
- Sui Development — What we've built and deployed
- Verifiable Intent — Human consent chain for agent-mediated access
- Intelligent Hyperlinks — The infrastructure this builds on
Links
- Walrus Documentation — Storage protocol, pricing, epoch model
- Seal (Mysten Labs) — Identity-based encryption protocol
- Nautilus TEE — Trusted execution environment for Sui
Questions
If the patient controls access via a capability object, what happens when the patient loses access to their wallet — and is that better or worse than the current system?
- At what point does the cost of Walrus storage at patient-lifetime epochs become a design constraint rather than a negligible line item?
- If Nautilus proves a computation was correct without revealing the input, can that attestation serve as evidence in a legal dispute?
- Who pays gas for a patient issuing and revoking access capabilities — and does that fee structure create access barriers?