Written and maintained by CASRAI Editorial Board
Last updated
In health informatics and research data management, blockchain medical records do not store raw clinical notes, diagnostic images, or laboratory values inside distributed ledger blocks. Instead, production and reference health-record architectures—pioneered by the MIT Media Lab and Beth Israel Deaconess Medical Center MedRec system and expanded across enterprise blockchain in healthcare deployments—use a hybrid on-chain/off-chain design. Encrypted electronic Protected Health Information (ePHI) remains inside institutionally governed off-chain repositories (hospital EHR databases or HL7 FHIR R4 servers), while a permissioned ledger stores only cryptographic SHA-256 integrity digests, off-chain database query pointers, patient consent state, and immutable access logs.
1. How Are Medical Records Stored on a Blockchain? On-Chain Pointers vs. Off-Chain ePHI
Writing unencrypted or even symmetrically encrypted patient records directly to an append-only ledger violates three foundational health-data engineering constraints:
- Replication and Confidentiality Exposure: Every validating node in a consortium network replicates the entire ledger state. Placing ePHI on-chain would broadcast sensitive clinical data across every participating organization’s infrastructure, conflicting with the HIPAA Minimum Necessary Standard (45 CFR § 164.502(b)) and long-term post-quantum decryption risks.
- Throughput and Payload Size Limits: Diagnostic imaging studies (DICOM volumes), genomic BAM/VCF files, and longitudinal HL7 C-CDA or FHIR bundles range from megabytes to gigabytes, whereas permissioned enterprise ledgers (such as Hyperledger Besu or Hyperledger Fabric) are optimized for compact state-transition transactions measured in kilobytes.
- Statutory Modification and Erasure Rights: Under 45 CFR § 164.526 (HIPAA Right to Amend) and GDPR Article 17 (Right to Erasure), covered entities and data controllers must be able to amend inaccurate medical records or erase revoked personal data—an operation that is impossible if the clinical payload itself is permanently baked into immutable blocks.
| Architectural Layer | Data Stored in Layer | Standards & Cryptographic Primitives |
|---|---|---|
| On-Chain Ledger Layer (Permissioned Consortium Nodes) |
|
Permissioned smart contracts, QBFT/Raft consensus, W3C Decentralized Identifiers (SSI in healthcare), RFC 3161 / ledger block timestamps |
| Off-Chain Stewardship Layer (Hospital EHRs, FHIR R4 Repositories, Research Enclaves) |
|
HL7 FHIR R4, USCDI, TLS 1.3 in transit, AES-256 at rest, OAuth 2.0 / SMART on FHIR |
2. How Does Decentralized Medical Record Sharing Work? The MedRec Three-Contract Pattern
To enable cross-institutional record discovery without centralizing ePHI into a single honeypot database, the ONC-recognized MedRec reference architecture defines three hierarchical smart contracts paired with an off-chain gatekeeper daemon at each provider site:
- Registrar Contract (RC): Maps institutional healthcare provider identifiers and patient identities to their cryptographic public keys and network routing policies.
- Patient–Provider Relationship Contract (PPR): Instantiated whenever a stewardship node (such as an academic medical center or diagnostic laboratory) creates or updates records for a patient. The PPR contract stores a formatted query string (the off-chain pointer to the hospital’s local database), the **SHA-256 hash** of the query result set, and an access-control list specifying which third-party clinicians or clinical trial investigators have patient-authorized read permissions.
- Summary Contract (SC): Acts as the patient’s master breadcrumb directory. The Summary Contract holds a list of references to every PPR contract associated with that patient across all hospitals, pharmacies, and clinics. When a patient presents at a new facility or enrolls in a multi-site clinical registry, the client application reads the Summary Contract to locate all historical provider relationships, requests the underlying FHIR resources directly from each provider’s off-chain gatekeeper over mutually authenticated TLS, and verifies that the downloaded payload’s SHA-256 digest matches the on-chain PPR hash.
3. HL7 FHIR `Provenance`, `AuditEvent`, and Enterprise Metadata Platforms
In research data management (`rdm`) and clinical trial eSource pipelines, permissioned ledgers and enterprise data-governance platforms (such as BurstIQ and Guardtime KSI) anchor standardized provenance metadata rather than ad-hoc JSON blobs:
- HL7 FHIR `Provenance` Anchoring: Whenever an off-chain FHIR resource (`Observation`, `QuestionnaireResponse`, `Consent`) is committed, the EHR generates an accompanying FHIR **`Provenance`** resource recording `Provenance.target` (the version-specific reference, e.g., `Observation/1042/_history/2`), `Provenance.recorded` (timestamp), `Provenance.activity` (create, update, append), `Provenance.agent` (the authoring practitioner or device), and `Provenance.signature`. Canonicalizing the resource and anchoring its SHA-256 digest on-chain proves mathematically during an FDA 21 CFR Part 11 or ICH E6(R3) inspection that no backdating or silent database alteration occurred.
- Reconciling Immutability with the HIPAA Right to Amend (45 CFR § 164.526): When a patient exercises their statutory right under 45 CFR § 164.526 to amend an inaccurate chart entry, the hospital updates the off-chain FHIR resource to a new version (`_history/3`) and appends the amendment link per § 164.526(c)(2). A new transaction is then written to the PPR contract containing the updated SHA-256 hash and pointer for `_history/3`. The ledger preserves an unbroken, non-repudiable provenance chain showing that version 2 was superseded by version 3 via an authorized amendment, while unauthorized parties can no longer retrieve the superseded off-chain record.
4. Frequently Asked Questions
How are medical records stored on a blockchain?
Medical records are never stored as raw clinical text or images inside blockchain blocks. Instead, healthcare architectures use a hybrid model: the actual Electronic Protected Health Information (ePHI)—formatted as HL7 FHIR resources or DICOM files—resides in encrypted off-chain hospital databases, while the permissioned blockchain stores only cryptographic SHA-256 hashes (for tamper detection), off-chain pointers (URIs/queries), and smart-contract access permissions.
Can blockchain secure patient medical records?
A permissioned blockchain secures the integrity, provenance, and access audit trail of medical records by making unauthorized off-chain data tampering mathematically detectable (any modification alters the record’s SHA-256 hash so it no longer matches the on-chain digest) and by enforcing cryptographic consent rules before an off-chain gatekeeper releases ePHI. However, off-chain storage servers still require standard HIPAA Physical and Technical Safeguards (AES-256 encryption, TLS 1.3, and role-based access control).
How does decentralized medical record sharing work?
In decentralized sharing models like MedRec, a patient’s Summary Contract tracks pointers to Patient–Provider Relationship (PPR) contracts across multiple clinics. When a patient authorizes a specialist or researcher via a cryptographic signature, the recipient queries the provider’s off-chain gatekeeper server; the gatekeeper verifies the on-chain permission, returns the off-chain HL7 FHIR record over TLS, and the recipient verifies the record’s authenticity against the on-chain SHA-256 hash.
