PaperlayerView exact revision on arXiv

Source-linked AI summary

FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data

Peng Zhang, Jules White, Douglas C. Schmidt, Gunther Lenz, S. Trent Rosenbloom

arXiv:1807.03227v1cs.CYcs.CR

TL;DR

Siloed clinical systems hinder secure, scalable information exchange needed for collaborative care. The paper analyzes ONC requirements and presents FHIRChain, a blockchain architecture and DApp using FHIR data and digital health identities. Its case study demonstrates decentralized, verifiable, fine-grained data sharing, while semantic interoperability and legacy-system compatibility remain limitations.

  • Problem

    Secure and scalable clinical data sharing is needed for collaborative decision support, but existing systems create interoperability and exchange barriers.

  • Method

    The paper designs FHIRChain around ONC requirements, combining FHIR data elements, blockchain smart contracts, token-based exchange, modular components, and digital health identities.

  • Results

    FHIRChain supports decentralized, verifiable, fine-grained clinical data exchange, with modular lightweight references and on-chain storage complexity O(hash(N) + ϵ).

  • Takeaways & Limitations

    The architecture provides a blockchain-based approach for clinical data sharing that is designed to meet ONC interoperability requirements and support collaborative decision support.

  • Takeaways & Limitations

    FHIRChain does not address semantic interoperability beyond FHIR and may not interoperate with legacy systems that use standards such as HL7 v2.

Abstract

from arXiv · show

Secure and scalable data sharing is essential for collaborative clinical decision making. Conventional clinical data efforts are often siloed, however, which creates barriers to efficient information exchange and impedes effective treatment decision made for patients. This paper provides four contributions to the study of applying blockchain technology to clinical data sharing in the context of technical requirements defined in the "Shared Nationwide Interoperability Roadmap" from the Office of the National Coordinator for Health Information Technology (ONC). First, we analyze the ONC requirements and their implications for blockchain-based systems. Second, we present FHIRChain, which is a blockchain-based architecture designed to meet ONC requirements by encapsulating the HL7 Fast Healthcare Interoperability Resources (FHIR) standard for shared clinical data. Third, we demonstrate a FHIRChain-based decentralized app using digital health identities to authenticate participants in a case study of collaborative decision making for remote cancer care. Fourth, we highlight key lessons learned from our case study.

S. Trent Rosenbloomc

The paper identifies blockchain, smart contracts, decentralized apps, interoperability, digital health identity, clinical data sharing, and cancer care as its key topics.

  • The paper concerns blockchain and smart contracts for decentralized clinical data sharing.

1. Introduction

Secure, scalable, interoperable data sharing is needed for collaborative clinical decision making, but healthcare remains constrained by siloed systems, security concerns, weak trust relationships, and scalability barriers. The paper analyzes ONC requirements and presents FHIRChain and a remote cancer-care DApp to address these challenges.

  • Motivation: Secure and scalable exchange across providers supports timely, privacy-sensitive collaborative treatment decisions.Patients receive care from multiple providers who need current health information.
  • Motivation: Telemedicine and tumor boards use shared expertise to improve diagnostic and treatment decisions, including for regions lacking specialized cancer care.
  • Barriers: Healthcare data sharing faces security and privacy concerns, weak inter-entity trust, and scalability limits involving bandwidth, firewalls, response time, and transaction speed.
  • Contributions: FHIRChain analyzes ONC interoperability requirements and uses FHIR data elements with token-based exchange for decentralized, verifiable sharing without centralized duplication.
  • Contributions: A FHIRChain DApp uses digital health identities for authentication and access authorization while sharing specific structured information rather than entire documents.
  • Contributions: The paper identifies future extensions for broader stakeholder coordination and patient access, while noting unresolved semantic interoperability, malpractice, and unethical data-use issues.

2. Overview of Blockchain

Blockchain is a decentralized, immutable ledger that validates and records transactions without a trusted central authority. Its properties make blockchain attractive for securely and scalably sharing clinical data and supporting collaborative decision-making.

  • Bitcoin blockchain: Bitcoin distributes transactions to peer-to-peer network maintainers, who verify transactions and group them into blocks.The maintainers, called miners, validate available transactions before adding them to the blockchain.
  • Blockchain structure: Blockchain records ordered, validated transactions in a continuously growing and immutable list.Figure 1 depicts the blockchain structure.
  • Consensus: Proof of work achieves consensus by incentivizing miners and discouraging rogue actors from manipulating or controlling the system.Miners receive small cryptocurrency rewards for contributing hardware and electricity.
  • Immutability: Cryptography secures a block’s transaction history from tampering after the block is added.
  • Smart contracts: Ethereum extends blockchain through smart contracts that autonomously execute conditions, store information, and update state.Smart-contract operations are published as transactions and are deterministic and verifiable by miners.
  • Healthcare relevance: Decentralization and immutability remove the need for a trusted central authority and support privacy-conscious clinical communication.The paper examines leveraging blockchains to share clinical data securely and scalably for collaborative decision support.

3. Related Work Summary and Comparison

Prior work explored blockchain-based health information exchange, medical-record management, interoperability, identity, and security challenges. FHIRChain instead emphasizes blockchain-interfacing design choices aligned with ONC requirements, using digital identities and token-based access exchange for clinical collaboration.

  • Blockchain healthcare research: Related work examined blockchain opportunities for health information exchange and collaboration among patients, providers, and healthcare organizations.
  • Blockchain healthcare research: Healthcare blockchain research addressed broad industry challenges, use cases, health-system design recommendations, and assessment metrics related to ONC requirements.
  • Challenges: Reviews identified medical-record and healthcare-ledger applications alongside confidentiality, scalability, and 51% attack challenges.
  • Challenges: Proposed mitigations included encrypting sensitive data, storing it off-chain, retaining partial verified transactions on-chain, and using private networks.These techniques target confidentiality and blockchain scalability.
  • Permissioned systems: Permissioned blockchain platforms supported authorized-user access, authentication, medical-record sharing, and interoperability with provider data storage.
  • Interoperability: FHIR-related work proposed Proof of Interoperability, requiring miners to verify clinical messages against FHIR structural and semantic standards.
  • Digital identities: HIE of One used blockchain-based identities and digital wallets to secure access to patient data stored in EHR systems without storing patient information on the blockchain.
  • FHIRChain: FHIRChain was designed around ONC interoperability requirements and decoupled its smart-contract and blockchain-interfacing decisions from any particular blockchain framework.This distinguishes its architecture from designs centered on a specific blockchain infrastructure or consensus mechanism.

4. Technical Requirements for Blockchain-Based Clinical Data Sharing

The paper analyzes five ONC requirements for clinical data sharing and derives corresponding blockchain design challenges involving privacy, scalability, permissioning, interoperability, and modularity.

  • ONC requirements: ONC requirements call for interoperable, secure, private, and evolvable health IT systems that support authorized clinical data sharing.They emphasize identity proofing, encryption and key control, computable permissions, standardized structured data, and modularity.
  • Security and privacy: Blockchain openness can expose sensitive health information, even when encrypted, because future flaws in algorithms or implementations may reveal contents.The design must therefore address privacy risks created by immutable, publicly accessible records.
  • Scalability: Blockchain replication propagates every transaction and data record to all nodes, creating scalability challenges and public-chain transaction fees as data changes.Each addition or modification must be distributed across nodes, increasing storage, propagation, and cost burdens.
  • Permissioning: Blockchain smart contracts cannot use off-chain permission services such as OAuth, requiring alternative mechanisms for accurate and trustworthy access authorization.The paper identifies permissioning as a key blockchain-design component.
  • Interoperability: Interoperability requires structured, standardized, granular clinical data with contextual metadata, motivating enforcement of established standards such as FHIR.The paper links readable collaborative decision support to commonly accepted clinical data formats rather than new exchange formats.
  • Modularity: Blockchain immutability complicates modular evolution because modifying smart-contract code creates a new contract instance and can invalidate dependencies.The paper recommends loosely coupled components and later applies the MVC pattern.

5. FHIRChain: a Blockchain-Based Architecture for Clinical Data Sharing

FHIRChain is a general blockchain-based architecture for clinical data sharing that connects siloed systems through standardized data references, secure tokens, and auditable smart contracts.

  • Overview: FHIRChain addresses ONC requirements through a blockchain-mediated architecture designed for secure and scalable sharing across distributed clinical data sources.The architecture also underpins a decentralized app for collaborative cancer-care decision making.
  • Architecture: FHIRChain normalizes heterogeneous clinical data silos with FHIR and connects them to blockchain through secure database connectors.The connectors expose access tokens to references rather than directly exposing the underlying data.
  • Access control: Secure access tokens are recorded in smart contracts to support decentralized access and traceability.The contracts also maintain immutable, timestamped logs of grants, token consumption, users, and accessed resources.
  • Digital health identity: FHIRChain uses public-key cryptography to create digital health identities that authenticate participating providers without directly exposing personal information on-chain.Public keys represent identities, while corresponding private keys authenticate service use.
  • Secure data exchange: Instead of storing encrypted health data on-chain, FHIRChain exchanges encrypted reference pointers that preserve provider data ownership and reduce exposure risk.Lightweight metadata transactions are more efficient in time and cost than exchanging original data sources.
  • Consistent data formats: FHIRChain enforces FHIR by validating whether generated reference pointers follow FHIR API standards.FHIR uses compact, readable JSON and is compatible with many software libraries and packages.
  • Modularity: FHIRChain separates data storage from other system components so upgrades can occur without losing access to existing users or permission information.Its modular design minimizes the need to create new contract versions when other components change.

6. Case Study: Applying FHIRChain to Create a Prototype DApp

The FHIRChain DApp prototype supports remote tumor-board collaboration by combining digital identities, FHIR-based reference pointers, tokenized permissions, and blockchain logging. The case study reports modular, scalable, fine-grained, and cryptographically supported data sharing, while identifying interoperability, misuse, deployment-cost, and governance limitations.

  • Case-study setup: The DApp customizes FHIRChain for collaborative clinical decision making through a remote tumor-board case study.It was implemented against a private Ethereum testnet and uses three Solidity smart contracts.
  • Case-study setup: Provider registration maps directory identifiers to automatically generated public encryption and signing keys for digital identity and authentication.The Registry smart contract maintains registered providers’ digital health identities.
  • Case-study setup: FHIR-based reference pointers connect the DApp to cancer-patient data entries, with paths validated against FHIR APIs.The DApp uses two cancer patient databases and the HapiFHIR public test server.
  • Reported benefits: Token-based access exchange logs sharing requests and supports provider-specific authorization and revocation.The Access smart contract records which resource is shared or unshared, with whom, by whom, and when.
  • Reported benefits: Reference pointers and hashes keep exchanged information lightweight, yielding on-chain storage complexity O(hash(N) + ϵ) rather than storing the original data.The design also avoids electronically transmitting the data itself across institutional boundaries.
  • Reported benefits: Public-key cryptography supports identifiability and authentication, while authorized users can approve or revoke access immediately.Authentication requires the private key paired with a registered public key, although replacing lost or stolen keys is straightforward.
  • Limitations: The prototype does not resolve semantic interoperability, may not support legacy systems lacking FHIR, and cannot control clinical malpractice or public-blockchain deployment costs.Semantic interoperability still requires expert ontology inspection and mapping; public deployment would introduce transaction costs.
  • Limitations: Permissioned healthcare deployments may face collusion risk, although the paper considers a 51% attack unlikely unless major stakeholders collude.The assessment assumes management by relatively large healthcare entities.

7. Concluding Remarks

FHIRChain combines blockchain, FHIR standards, public-key cryptography, and decentralized applications to support secure, scalable clinical data sharing while preserving data ownership and source security. The prototype addresses ONC interoperability requirements, records metadata and permissions, and identifies remaining evaluation and patient-identity challenges.

  • FHIRChain addresses five ONC interoperability requirements: user identifiability and authentication, secure exchange, permissioned access, consistent formats, and modularity.
  • Blockchain stores reference information, public-key associations, permissions, and audit logs without storing the clinical data itself.This decentralized metadata storage avoids a single point of failure or record corruption and creates traceable permission histories.
  • FHIR resource APIs and blockchain pointers let users retrieve properly formatted data directly from source databases while maintaining original data ownership.After authentication, the referenced data is downloaded from its source rather than uploaded to or downloaded through the blockchain.
  • Public-key cryptography supports digital health identities through private-key authentication, signed-pointer integrity checks, and replacement keys for lost or stolen keys.The paper also notes that patient key management is difficult because private keys are harder to remember than passwords and require technical training.
  • The FHIRChain-based DApp demonstrates blockchain’s potential for effective healthcare data sharing while maintaining the security of original data sources.The authors identify future extensions for additional stakeholders and patient record access, alongside more rigorous performance evaluation and patient-focused identity management.
Loading 1807.03227v1…