This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.jmir.org/, as well as this copyright and license information must be included.
With increased specialization of health care services and high levels of patient mobility, accessing health care services across multiple hospitals or clinics has become very common for diagnosis and treatment, particularly for patients with chronic diseases such as cancer. With informed knowledge of a patient’s history, physicians can make prompt clinical decisions for smarter, safer, and more efficient care. However, due to the privacy and high sensitivity of electronic health records (EHR), most EHR data sharing still happens through fax or mail due to the lack of systematic infrastructure support for secure, trustable health data sharing, which can also cause major delays in patient care.
Our goal was to develop a system that will facilitate secure, trustable management, sharing, and aggregation of EHR data. Our patient-centric system allows patients to manage their own health records across multiple hospitals. The system will ensure patient privacy protection and guarantee security with respect to the requirements for health care data management, including the access control policy specified by the patient.
We propose a permissioned blockchain-based system for EHR data sharing and integration. Each hospital will provide a blockchain node integrated with its own EHR system to form the blockchain network. A web-based interface will be used for patients and doctors to initiate EHR sharing transactions. We take a hybrid data management approach, where only management metadata will be stored on the chain. Actual EHR data, on the other hand, will be encrypted and stored off-chain in Health Insurance Portability and Accountability Act–compliant cloud-based storage. The system uses public key infrastructure–based asymmetric encryption and digital signatures to secure shared EHR data.
In collaboration with Stony Brook University Hospital, we developed ACTION-EHR, a system for patient-centric, blockchain-based EHR data sharing and management for patient care, in particular radiation treatment for cancer. The prototype was built on Hyperledger Fabric, an open-source, permissioned blockchain framework. Data sharing transactions were implemented using chaincode and exposed as representational state transfer application programming interfaces used for the web portal for patients and users. The HL7 Fast Healthcare Interoperability Resources standard was adopted to represent shared EHR data, making it easy to interface with hospital EHR systems and integrate a patient’s EHR data. We tested the system in a distributed environment at Stony Brook University using deidentified patient data.
We studied and developed the critical technology components to enable patient-centric, blockchain-based EHR sharing to support cancer care. The prototype demonstrated the feasibility of our approach as well as some of the major challenges. The next step will be a pilot study with health care providers in both the United States and Switzerland. Our work provides an exemplar testbed to build next-generation EHR sharing infrastructures.
Timely sharing of electronic health records (EHR) across providers is essential for prompt medical care. For instance, transition and coordination of care for cancer patients are very common phenomena. A patient’s history of health, tests, diagnoses, and treatments provides necessary knowledge for physicians to make clinical decisions. Access to EHR history is also preferred by individual patients to support personal and family engagement with user-centric control of data sharing and access [
EHR data are highly private and sensitive. According to the Health Insurance Portability and Accountability Act (HIPAA) [
Ecosystems for health information exchange (HIE) aim to ensure that patient data from EHR are securely, efficiently, and accurately shared nationwide. However, HIEs have limited adoption, and many regional networks are still isolated [
HIEs are generally designed as a single, fully trusted entity that is solely responsible for managing and storing EHR data from multiple participating hospitals. While a centralized system may be easier to manage, it suffers from a single point of failure and may prove to be a performance bottleneck for real-world deployment. In addition, a centralized authority with access to sensitive health information has proven to have more security and privacy concerns from end users. The experience with GoogleHealth wallet [
Blockchain technologies have recently emerged with tremendous momentum based on the success of the Bitcoin cryptocurrency [
In this paper, we propose ACTION-EHR, a patient-centric, secure, trustable EHR data sharing framework with permissioned blockchain framework that can not only accelerate the data sharing process but also enable patients to take action on their own EHR data for sharing with full access control. The system will not only allow individual patients to stay at the center of their care but also enable medical practitioners and researchers to have fast, secure data access to enhance cancer treatment with significantly reduced cost and improved efficiency.
Blockchain is a peer-to-peer distributed ledger technology that provides a shared, immutable, and transparent append-only register of all the transactions that happen in the network [
Blockchain technology relies on public key infrastructure (PKI) and employs cryptographic primitives such as digital signatures and asymmetric encryption. In case of an asymmetric encryption scheme [
We restrict our work by following the settings of the permissioned blockchain technology for highly sensitive EHR [
Hyperledger Fabric [
In Hyperledger Fabric, smart contracts are implemented by the chaincode. The chaincode is defined by its logic and associated world state (state). The chaincode logic is a set of rules that define how the transactions will be executed and how the state will change. The logic can be written using general-purpose programming language. The state is a database that stores the information in a form of key-value pairs, where the value is an arbitrary byte array. The state also contains the block number to which it corresponds. The ledger manages the blockchain by including an efficient cryptographic hash of the state when appending a block. This enables efficient synchronization if a node was temporary offline, minimizing the amount of stored data at the node.
ACTION-EHR (patient-centric, blockchain-based EHR management) is a permissioned blockchain-based system for EHR data sharing and integration. Each hospital will provide a blockchain node integrated with its own EHR system to form the blockchain network, and a web application will be used by patients and doctors to initiate EHR sharing transactions. To achieve scalability for the EHR data, ACTION-EHR takes a hybrid data management approach, where metadata on data sharing will be stored on the chain and shared EHR data will be encrypted and stored off-chain in HIPAA-compliant cloud-based storage. A patient (or his health care proxy) will be able to initiate a record-sharing request and define sharing permissions, thus having full control of the shared data. PKI-based [
The system model for ACTION-EHR, a distributed patient-centric blockchain-based electronic health record data sharing system based on permissioned blockchain technology and implemented using Hyperledger Fabric v1.4. ECA: enrollment certificate authority; HIPAA: Health Insurance Portability and Accountability Act; TCA: transaction certificate authority; TLS-CA: transport layer security certificate authority; UI: user interface.
ACTION-EHR consists of the following components: peer node, SU, client-server web application, MS, orderer, and HIPAA-compliant cloud storage (CS).
The peer node (1-n) is a peer in the EHR blockchain network representing a health care institution. As each hospital has its own EHR system, the peer node will have access to the EHR system for pulling data for sharing. The peer node has a web server, EHR integration layer, chaincode defining the sharing operations, and a database (ie, CouchDB [
The SU is an end user of the system. Currently, there are 2 SU roles available: patient and caregiver. We also assume that at every hospital, there is a trusted user with a role of administrator for registering new users. The user management will be automatized once the system is integrated into the clinical data flow, and the electronic identity management system in a hospital (ie, ID cards) can be used. The identity of the administrator, as well as the identities of the users, is maintained by a CA.
A client-server web application is used for SUs, who will access the system through a web client (user interface provider). A web server is deployed on each peer node, which interacts with the chaincode. A hospital administrator (Admin) enrolls the users and retrieves the data from the local EHR database. To ensure that the software is trustworthy, the source code can be digitally signed and made available as open source for verification.
The MS is an entity that manages the network identities of all member organizations and users but does not have access to the EHR data or metadata stored on the blockchain. Before registering a peer, the MS uses a trusted database (such as the National Practitioner Data Bank) to verify the peer. To relax the assumptions and provide stronger security and distributed trust, collective authority servers could substitute for a single MS [
The orderer is a service that provides the verification and ordering of the transactions.
The HIPAA-compliant CS is a server where highly sensitive health care data in an encrypted form are stored according to the access-control policy specified by the patient. The CS is used to support exchange of large files such as medical images and can also be employed when constructing the full history of the patient data.
Based on this design, Action-EHR provides the following two user scenarios for the patient and caregiver, respectively.
Communication between the components of the ACTION-EHR system (single organization). EHR: electronic health record.
A patient can log in into the web platform using a web application. The patient can then share his health care data (using automatic fetching via a “record sharing service” responsible for verification of the patient’s existence, the data existence, and pulling the data) from the local database, emulating the hospital database management system with registered caregivers from hospitals that form the blockchain network. To share the data with a caregiver, the patient will need to specify the caregiver, the category of the data to be shared, and for which period of time this caregiver will be able to access the data. The transaction is generated automatically based on the information provided by the patient via the web application and is broadcasted in the network. Simultaneously, prior to being uploaded to the cloud, the data are encrypted. The corresponding transactions that define the metadata of the uploaded data are then added to the ledger.
A caregiver can log into the system and query the ledger to view the permissions specified by the patient, download from the CS with respect to the permissions, and decrypt the data. The patient can revoke the permission given earlier to the doctor by updating the ledger with the corresponding transaction. The patient can also retrieve all historical transactions from the blockchain in chronological order. This can be also used for auditing purposes. Permissions can also be indirectly used to delete the data corresponding to the patient. If the patient wants to delete his data from the CS, he can modify the permissions on the blockchain accordingly. Implementation of the data-deletion process is the next step in our future work.
One major challenge for sharing EHR data over blockchain is scalability, as EHR data such as images can be large. Due to the distributed replicated nature of a blockchain network, storing and replicating EHR data on the network for sharing are infeasible, as the large data volume will significantly slow performance. Instead, we propose a hybrid data management approach: All metadata (such as transactions, metadata of EHR, access control) are stored on the chain, but shared sensitive EHR data are stored and managed in a HIPAA-compliant cloud. We adopted Amazon Web Services (AWS), which provides HIPAA compliance through the “AWS Business Associate Addendum” [
The components of the Hyperledger Fabric are provided in the form of virtual containers — a standard unit of software that packages code and all its dependencies. However, in a real-work scenario, each peer will be physically located on the hospital premises; thus, we have to be able to run each peer on a separate machine. For metadata management on-chain, we take a key-value approach, where the “key” is a pseudonym of the patient (that can be generated as a randomly selected combination of letters and numbers or using a hash function), and the value represents the metadata represented in a JavaScript Object Notation document stored in a chaincode state database CouchDB [
To interact with the chaincode and manage the users (patients and caregivers), a web portal and set of methods that allow communication between the user interface and the server (chaincode) are required. For testing purpose, we created a simulated EHR database with example patients, EHR data, and caregivers for each node. The web portal of the applications makes asynchronous calls to the representational state transfer application programming interfaces implemented in Javascript. The technologies used to implement the web portal are HTML, cascading style sheets, and Javascript, as well as open-source Bootstrap libraries.
Following best practices for applied cryptography, we ensured that all the SUs possess 2 different key pairs for signing and encryption. The keys are generated during the registration phase. With his secret key for signing (SKSU), the SU signs every transaction when exploiting the functionality of the chaincode. Users can verify the authenticity of the transactions and permissions by verifying the digital signature. A hybrid cryptosystem (ie, a cryptosystem that combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem [
The properties of the blockchain technology, architecture design, implementation approaches, and cryptographic interfaces guarantee the protection of the sensitive data that flow in the system. These include the following privacy and security properties: data integrity, confidentiality, authenticity, and availability according to the access-control policy, as well as unlinkability between system metadata and the corresponding patient's identity for any unauthorized user (ie, only the users authorized by the patient are permitted to link the patient's identity and his record stored on the blockchain).
In this section, we present our solution prototype that demonstrates the feasibility of the approach. We describe the data model and the data sharing transaction that are in-line with the system model and required functionalities defined in the section, System Model of ACTION-EHR.
To present ACTION-EHR, we use the example of sharing EHR data between oncology information systems for radiation oncology. The EHR data include radiation, medical, and surgical information to assist radiation oncologists and medical physicists to manage different types of medical data, develop oncology-specific care plans, and monitor radiation doses for patients. We also describe one-organization and multiple-organization settings, both of which have been implemented.
However, while such approach is easier to set up and maintain, it may not be the best fit in practice: The MS is then required to manage the identities of all the users from different hospitals. Moreover, a certain level of centralization is unavoidable, as separate designated entities are required to host the MS and the orderer.
In order to address this issue and provide better levels of decentralization and trust, we employed the concept of organizations from Hyperledger Fabric to create a network of hospitals (as shown in
Communication between the components of the ACTION-EHR system (multiple organizations). CLI: command line interface; MSP: membership service provider.
The data structure of the metadata and electronic health record (EHR) data stored on the blockchain and cloud server, respectively. CS: cloud storage.
The block containing the information about the permissions is organized as follows. Each permission corresponds to an ID, with which a caregiver is registered in the system. Every permission specifies the timeframe (“from: to:”) during which the clinician has the right to “read the patient's data that fall into a specific ‘data category’ and to upload the data to the cloud repository (“write”).” “Timestamp” enables the patient to update and track access control changes. For patient P to revoke the right for caregiver C to access a specific type of data provided by other caregivers, patient P has to add a new permission with another time frame. To do so, the patient needs to update the ledger by sending the corresponding transaction.
Clinical metadata is a block that contains information about all the data files uploaded to the cloud by the clinicians or the patient himself. The metadata items are categorized based on the semantics of the corresponding data files. Every item contains an ID for the clinician that uploaded the data (“doctor ID”) or a patient's pseudonym, a pointer to the file that is stored in the cloud (“path to file”) and the hash of the data file (“hash(file)”) to ensure unforgeability of the data stored in the cloud, and the “timestamp” of the moment when the data file was uploaded. It is not necessary to use a digital signature for the file instead of the hash, as the entire content of the transaction that contains doctor ID and hash(file) is digitally signed by the doctor that uploads the file.
The web application is an implementation of a user interface that provides users easy access to the functionalities of our prototype. There are 3 views of the web portal: administrator (to be merged with the identity management system in a hospital once the prototype is fully integrated into the clinical dataflow), patients (user), and caregivers (user).
The administrator page shows the list of all the patients and doctors from the hospital that are registered in the system. It is possible to enroll a new user via the administrator page by invoking the MS and verifying that the credentials were generated for this user. Through this page, it is also possible to customize the interface (eg, to add or remove a new department or new roles; extending the functionality by adding new roles such as nurse or laboratory scientist is planned for the future development of ACTION-EHR).
When the patient logs in to the patient portal, he can access the patient-specific functionalities of the prototype (
Web portal (patient view): p1 can add a new permission for caregiver d1 (“read” the data for the specified time interval and immediately “revoke” the permission given to the specified caregiver).
Permission history of a specific patient (p3).
The portal for caregivers (as shown in
Web portal for the caregiver: view data.
Web portal for the caregiver: download data.
To achieve the required functionalities of ACTION-EHR (see System Model of ACTION-EHR), we designed the system architecture and data structure of on-chain and off-chain storage. We defined and implemented the data-sharing protocol with respect to the health care scenario and developed the chaincode accordingly. We created the web application that serves as a user interface and enables interaction with the chaincode. To ensure interoperability and seamless integration of our system into the clinical dataflow, we implemented an independent pluggable module that provides conformance with the Fast Healthcare Interoperability Resources (FHIR) standard.
Given the health care environment for which our system has been developed, it is of high importance to ensure security and privacy of multiple data types of different sensitivity levels. Our system guarantees privacy rights and security properties (data integrity, availability, confidentiality, authenticity, and unlinkability) for the following types of data: EHR data, metadata (including permissions or access control policy), and cryptographic keys and user credentials.
It is challenging to apply a relatively new technology that is not yet framed by government rules and regulations in a highly regulated health care environment. Some technical limitations of our prototype, especially related to the application domain, are highlighted in the paragraphs that follow.
The risk of having a single point of failure of the system can occur if the deployment of the system is not done correctly (if only a single orderer and single CA are employed). Using Kafka cluster and multiple CAs (such as in [
In the health care domain, emergency situations occur regularly, and data might be required urgently. If an unconscious patient arrives at a medical institution and the access control policy is defined such that that no caregiver from the medical institution has a right to access the patient’s EHR, it is impossible to update the permissions and grant caregiver access to the data. Robust and secure “break-glass” mechanisms for emergency situations are required to address this limitation.
According to the new General Data Protection Regulation in Europe, a patient has “the right to be forgotten.” This right might not be easily compatible with the immutability principles of the current implementations of the blockchain technology used in this work; the patient cannot delete his metadata record from the ledger. Applying different cryptographic techniques such as asymmetric encryption, threshold encryption, and proxy re-encryption, as well as principles of redactable blockchains (as proposed in [
In this section, we describe recent related work employing blockchain technology to achieve fast, secure, and privacy-preserving sharing of EHR. We also underline the differences with our work described in this paper.
A recent review [
The two most mature prototypes are MedRec and FHIRchain. MedRec [
In the space of applying permissioned blockchain technology in health care, the following studies share some similarities with our approach. The work presented by Liang et al [
Analysis of the challenges that need to be addressed in the health care industry, as well as the potential benefits of employing blockchain technology, especially a permissioned implementation, can be found in the studies by Krawiec et al [
Peterson et al [
Storing data on blockchain can restrict the data volumes that can be efficiently managed and can violate the rights of the patient (ie, to delete data or withdraw from participation in a research study). Motohashi et al [
Pournaghi et al [
A plethora of existing blockchain platforms and various prototypes built on top of the technologies can aggravate the lack of interoperability between health care systems that is highly relevant due to multitude EHR systems with different interfaces. Thus, ensuring interoperability between different blockchain platforms is of high importance and shall be considered as one of the possible directions for future work. Moreover, due to custom privacy requirements and individual needs of different patients, one can think of a multiple-ledger design: a patient-specific or even case-specific ledger [
In health care, a distributed ledger can be seen as a shared immutable and transparent history of all the actions performed by eHealth users; these actions include defining access control policies and sharing, accessing, and modifying the data. This work presents the architecture of the framework for the specific data sharing case for radiation oncology and the implementation of a prototype that ensures privacy, security, availability, and granular access control over highly sensitive patient data. The methodology is general and can be easily extended to support other types of patient care.
The functionality of the prototype meets the requirements from a medical practice perspective. To ease the adoption of the prototype, we implemented an independent pluggable module that conforms with the FHIR standard. Our next step is to set up a pilot network of health care institutions in the United States and Switzerland for further testing of ACTION-EHR with patient data. Once adopted by the health community, such a system will reduce the turnaround time for data sharing, improve decision making for medical care, and reduce the overall cost.
Security analysis.
Amazon Web Services
certificate authority
cloud storage
enrollment certificate authority
electronic health record
Fast Healthcare Interoperability Resources
health information exchange
Health Insurance Portability and Accountability Act
membership service
Practical Byzantine Fault Tolerance
public key infrastructure
solution user
transaction certificate authority
transport layer security certificate authority
user interface
None declared.