⛓ Patient-Controlled Health Record Blockchain Access

Decentralized Identifiers — Making the Patient the Root of Their Own Digital Identity

Every legacy patient portal identity is ultimately issued and controlled by a hospital, insurer, or vendor — the patient can be locked out, and their identity has no meaning outside that single system. Self-sovereign identity (SSI) inverts this: the patient generates their own cryptographic identity independent of any institution, and every subsequent healthcare relationship is layered on top of an identity the patient alone controls and can carry across providers for life.

• W3C DID: Identity standard (Decentralized Identifiers v1.0)
• W3C VC: Credential standard (Verifiable Credentials Data Model)
• Patient device: Key custody (private key never leaves wallet)
• None: Issuer dependency (no central authority required)

DID architecture, key generation, and the DID document

W3C Decentralized Identifier (DID) structure:

• A DID is a URI of the form `did:method:identifier` — e.g., `did:ethr:0x8f3a...` or `did:ion:EiA...` — that resolves to a DID Document rather than to a centrally-issued account record • At enrollment, the patient's wallet application (running on their phone or a hardware key) generates an asymmetric key pair locally: a private key that never leaves the device, and a public key published as part of the DID Document • The DID Document contains: the public key(s), authentication methods, and service endpoints (e.g., "here is where my off-chain data vault lives") — critically, it contains NO clinical data and no personally identifying information beyond what the patient chooses to publish • Resolution: any relying party (a hospital, a lab) can resolve `did:method:identifier` to the current DID Document via the appropriate DID method's resolution mechanism (on-chain registry lookup, DHT, or federated resolver network) — always retrieving the patient's current, self-updated keys, not a static institutional record

Why this differs fundamentally from a hospital-issued patient portal login:

• No issuer to petition: a hospital cannot revoke, suspend, or "reset" a DID the way it can a portal account — the patient holds the only private key that can authorize a change to the DID Document • Portable across providers: the same DID can be presented to any number of unrelated healthcare organizations, each of which independently verifies the same cryptographic proof of identity rather than maintaining siloed, incompatible logins • Key rotation and recovery: DID methods support key rotation (patient can add a new key and deprecate a compromised one without losing the DID itself) and social/guardian recovery schemes for lost-device scenarios, avoiding a single point of failure while still not requiring a central authority to hold custody

Verifiable Credentials (VCs) build on this foundation: a hospital can ISSUE the patient a cryptographically signed credential attesting to a fact ("this DID belongs to a patient with an active account at Hospital X"), which the patient stores in their wallet and selectively presents elsewhere — without the verifier needing to call the hospital back to confirm.

Keeping PHI Off the Chain — Encrypted Vaults with On-Chain Hash Pointers Only

A public or even permissioned blockchain is an immutable, widely replicated log — exactly the wrong place to store raw protected health information (PHI), since "immutable" also means "impossible to truly delete," conflicting directly with GDPR's right to erasure and creating an unbounded confidentiality liability if any key is ever compromised. The architectural solution used by essentially every serious patient-data blockchain project is to keep clinical data entirely off-chain, encrypted, and reference it on-chain only via a content hash and an access-control pointer.

• Hash + pointer only: On-chain content (zero raw PHI on ledger)
• EHR vault / IPFS-style CAS: Off-chain storage (content-addressed storage)
• Client-side: Encryption point (before data ever leaves device/EHR)
• HIPAA + GDPR: Regulatory driver (Art. 17 erasure incompatible w/ on-chain PHI)

The hybrid on-chain/off-chain architecture and why it is mandatory, not optional

The core tension: blockchains are append-only and replicated to every participating node — properties that are exactly backwards for medical confidentiality and for regulations that require the ability to permanently delete personal data on request.

Hybrid architecture resolves this by strict separation of concerns:

Off-chain layer (where the actual PHI lives): • Clinical documents, lab results, and imaging remain in the originating institution's EHR system, or in a dedicated encrypted patient-data vault (cloud storage or an IPFS-style content-addressed store) • Data is encrypted client-side, typically with a symmetric data-encryption key (DEK) generated per record or per document • The DEK itself is then encrypted ("wrapped") separately for each authorized recipient using that recipient's public key — so the vault operator, even with full access to the encrypted blob, cannot read the contents

On-chain layer (what the ledger actually stores): • A content hash (e.g., SHA-256) of the encrypted document — proves the document has not been tampered with since the hash was recorded, without revealing its contents • A pointer/URI to where the encrypted blob can be retrieved (vault address or content-addressed identifier) • Access-control state: which wrapped-DEK entries exist for which authorized DIDs, and their expiry — see Stage 3

Erasure compatibility: • Because the chain never held the plaintext (or even a decryptable ciphertext) — only a hash and a pointer — "deleting" a patient's data for GDPR purposes means deleting the off-chain blob and destroying the wrapped keys • Once the encrypted blob is gone and no wrapped-key copies exist that could decrypt a cached copy, the on-chain hash becomes cryptographically meaningless — a hash of nothing retrievable — satisfying erasure requirements without needing to rewrite the immutable chain itself

This pattern (MIT Media Lab's MedRec project, and most production health-data blockchain pilots since) treats the chain purely as a coordination and audit layer — "who is allowed to access what, and who did access what" — while all confidentiality-sensitive bytes stay in conventional, deletable, access-controlled storage systems.

Granular, Time-Limited Consent — Encoding Access Rules the Patient Actually Controls

Paper and portal-based consent is coarse and stale: a signature on an intake form often grants indefinite, broad access that outlives the clinical relationship by years. A consent smart contract makes access rules explicit, machine-enforced, and inherently temporary — the patient specifies exactly which record types, for what purpose, and for how long, and the contract itself — not a records clerk's memory — enforces the boundary.

• Per record-type: Grant scope granularity (e.g. labs only, not full chart)
• 1h – 30d: Default grant durations (patient-selectable, self-expiring)
• Contract-level: Enforcement layer (not just application UI)
• On scope change: Re-consent trigger (new purpose requires new grant)

Consent contract state machine and scoped access-grant mechanics

Anatomy of a consent smart contract transaction:

When a patient grants access, they sign a transaction containing: • Grantee DID: the specific provider (or provider organization) being authorized • Scope: which record categories are covered — e.g., "lab results from the last 12 months" or "imaging studies only" — never an undifferentiated "everything" grant by default • Purpose: the stated reason (treatment, second opinion, research with separate consent track) — many jurisdictions' consent frameworks require purpose limitation, and encoding it on-chain creates an auditable justification trail • Expiry: an explicit timestamp or duration after which the grant auto-invalidates — no action required from the patient to end access

Contract state machine: • `Pending` → `Active` (once patient signature is confirmed on-chain) → `Expired` (automatically, once block.timestamp exceeds the grant's expiry) or `Revoked` (if the patient explicitly ends it early — see Stage 5) • Only in the `Active` state does the contract release the wrapped decryption key material a provider needs to actually read the off-chain data — an expired or revoked grant simply will not release it, regardless of what the requesting application believes

Why self-expiring grants matter operationally: • Legacy systems' biggest access-control failure mode is not malicious breach but forgotten permissions — a provider who saw a patient once, five years ago, who technically still has portal access because no one remembered to revoke it • A default-expiring grant flips the failure mode: access silently and safely lapses unless the relationship is active enough that the patient (or an automated renewal tied to an ongoing episode of care) proactively extends it

Re-consent on scope change: • If a provider needs access beyond an existing grant's scope (e.g., they had lab-only access but now need imaging for the same patient), the contract requires a distinct new consent transaction rather than silently expanding the original grant — preventing scope creep from ever happening without an explicit, logged patient action

From Grant to Chart — FHIR-Compatible Retrieval Once Access Is Authorized

An access grant is only useful if it results in a clinician actually being able to open a usable chart. The retrieval step bridges the blockchain's access-control decision to real clinical workflows by returning data in FHIR R4 — the interoperability standard every modern EHR already speaks — so a granted provider experiences this as a normal record pull, not a cryptography exercise.

• HL7 FHIR R4: Exchange format (industry-standard clinical API)
• Scoped derived key: Credential released (not the master private key)
• Contract check → vault pull: Query pattern (two-step verified retrieval)
• Seconds: Typical retrieval latency (once grant verified on-chain)

The two-step retrieval flow and FHIR resource mapping

Step 1 — On-chain authorization check: A provider's system, attempting to pull a patient's record, first queries the consent smart contract: "is there an Active grant from patient DID X to provider DID Y covering scope Z?" The contract returns a yes/no plus, if yes, a cryptographic capability — typically a derived, scope-limited decryption credential rather than exposing the patient's actual private key or a universal master secret. This derived-key approach means even a compromised provider system only leaks decryption ability for the specific narrow scope it was granted, not the patient's entire record set.

Step 2 — Off-chain data retrieval and decryption: With a valid capability in hand, the provider's system retrieves the encrypted blob(s) from the off-chain vault using the pointer recorded in Stage 2, unwraps the data-encryption key using the capability, and decrypts locally. The retrieved plaintext is then mapped into FHIR R4 resources — Observation (labs), DiagnosticReport (imaging/pathology), MedicationStatement, AllergyIntolerance, and so on — the same resource types the provider's EHR already knows how to render and file into the patient's chart within that institution.

Why FHIR compatibility is the make-or-break design choice: • Nearly every EHR vendor already implements FHIR R4 APIs (driven by US ONC Cures Act interoperability rules and analogous mandates elsewhere) — building the blockchain layer's OUTPUT in FHIR means it plugs into existing clinical software with no bespoke integration per institution • Without FHIR compatibility, a patient-controlled record system becomes yet another silo clinicians must separately log into and manually reconcile — which is precisely the fragmentation this architecture is meant to eliminate • The blockchain and off-chain vault are invisible plumbing from the clinician's point of view; what they experience is a chart that populates once consent exists, and that stops populating the moment it does not

Instant Revocation and a Permanent Audit Trail — Consent That Actually Means Something

The final, and arguably most consequential, capability is what happens when the patient changes their mind. Because the access rule lives in a smart contract rather than scattered across every institution's own access-control list, revocation is a single signed transaction that immediately and provably ends access everywhere — paired with an immutable log that lets the patient, and any auditor or regulator, answer definitively who accessed what and when.

• Immediate, contract-level: Revocation propagation (single transaction, all readers)
• None — append-only: Audit log mutability (every grant/request/revoke logged)
• Full access log: Patient-visible history (via wallet app, always available)
• HIPAA accounting of disclosures: Compliance relevance (audit trail satisfies § 164.528)

Contract-level revocation semantics and the immutable audit log

Revocation mechanics:

• The patient signs a `revoke(grantId)` transaction; the contract immediately flips that grant's state from `Active` to `Revoked` • Critically, this is enforced at the CONTRACT level, not merely by an application choosing to respect it: any subsequent attempt to retrieve the scoped decryption capability for that grant fails at the smart contract's own logic, regardless of which application or institution is making the request • This is a meaningful improvement over legacy portal permissions, where "revoking" access in one hospital's system does nothing to a copy of the record a different institution already downloaded and retained locally — though it is worth noting that data ALREADY decrypted and stored locally by a provider before revocation is not retroactively erased; revocation prevents future access, and paired off-chain data-retention agreements (or, for particularly sensitive scopes, single-use / non-cacheable access patterns) address the retained-copy question

Immutable audit trail:

• Every state-changing event — grant issued, grant expired, data retrieval, revocation — is written as a permanent, timestamped log entry on the ledger, attributed to the exact DIDs of patient and provider involved • This log cannot be edited or deleted by either party after the fact — a materially stronger guarantee than a hospital's internal access log, which the hospital itself (as data controller) technically has the ability to alter or purge • The patient can view this complete history directly through their wallet application at any time, without submitting a formal records request to any institution — a functional realization of HIPAA's "accounting of disclosures" right (45 CFR § 164.528), which in legacy systems often takes weeks of manual compilation to produce

Why this closes the loop on patient control: • Identity (Stage 1) without enforceable, revocable consent would just be a fancier login • Consent (Stage 3) without instant, contract-enforced revocation would still leave the patient dependent on institutional goodwill to actually stop access • Only the combination — self-sovereign identity, encrypted off-chain storage, granular time-boxed grants, standards-based retrieval, and immediate contract-level revocation with an unforgeable audit trail — delivers on the premise that the patient, not any single institution, is the actual owner and gatekeeper of their own health record

Because revocation is enforced by the smart contract itself rather than by application-layer trust, a patient who revokes a grant has a cryptographic guarantee — not merely a hospital's policy promise — that no further data will be released under that grant, and a permanent, self-auditable log of exactly who accessed their record and when, satisfying accounting-of-disclosures obligations that traditionally require a formal request and weeks of turnaround.