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.
Data coordination across multiple health care facilities has become increasingly important for many emerging health care applications. Distrust has been recognized as a key barrier to the success of such applications. Leveraging blockchain technology could provide potential solutions tobuild trust between data providers and receivers by taking advantage of blockchain properties such as security, immutability, anonymity, decentralization, and smart contracts. Many health technologies have empirically proven that blockchain designs fit well with the needs of health care applications with certain degrees of success. However, there is a lack of robust architecture to provide a practical framework for developers to implement applications and test the performance of stability, efficiency, and scalability using standard blockchain designs. A generalized blockchain model is needed for the health care community to adopt blockchain technology and develop applications in a timely fashion.
This study aimed at building a generalized blockchain architecture that provides data coordination functions, including data requests, permission granting, data exchange, and usage tracking, for a wide spectrum of health care application developments.
An augmented, 3-layered blockchain architecture was built on a private blockchain network. The 3 layers, from bottom to top, are as follows: (1) incorporation of fundamental blockchain settings and smart contract design for data collection; (2) interactions between the blockchain and health care application development environment using Node.js and web3.js; and (3) a flexible development platform that supports web technologies such as HTML, https, and various programing languages. Two example applications, health information exchange (HIE) and clinical trial recruitment, were developed in our design to demonstrate the feasibility of the layered architecture. Case studies were conducted to test the performance in terms of stability, efficiency, and scalability of the blockchain system.
A total of 331,142 simulated HIE requests from accounts of 40,000 patients were successfully validated through this layered blockchain architecture with an average exchange time of 11.271 (SD 2.208) seconds. We also simulated a clinical trial recruitment scenario with the same set of patients and various recruitment criteria to match potential subjects using the same architecture. Potential subjects successfully received the clinical trial recruitment information and granted permission to the trial sponsors to access their health records with an average time of 3.07 seconds.
This study proposes a generalized layered blockchain architecture that offers health technology community blockchain features for application development without requiring developers to have extensive experience with blockchain technology. The case studies tested the performance of our design and empirically proved the feasibility of the architecture in 2 relevant health application domains.
The health care industry generates abundant health data from various sources [
Facing the challenges of data coordination, blockchain is considered to be a disruptive technology that fits the needs of many health care applications [
As the features of decentralized transaction validation—ensured data provenance, data sharing, data integration, and flexibility of smart contracts—fit well with the needs of many health care applications, there have been many efforts to apply blockchain to areas of health care, such as HIE, pharmaceutical supply chains, and clinical trial management [
This was an extended study of previous blockchain application designs and an exploration of a new generalized layered architecture, as shown in
Compared with traditional blockchain architecture, this study proposed a generalized blockchain system that fits a wide spectrum of health care applications for cross-site data coordination. The layered architecture provides a blockchain platform with predefined functions for data collection for developers to implement health care applications without an extensive experience of blockchain. We explained the blockchain environment setup and the new layered architecture in the Methods section, followed by case studies and simulation results in the Results section to demonstrate the feasibility, scalability, and compatibility of the architecture for health care application development.
Overall layered blockchain architecture. The transaction layer consists of 2 smart contracts to manage data access tasks. The interfacing layer interacts with the blockchain environment, graphical user interfaces, and other blockchain adapters. The application layer provides a flexible platform for health care application development. The figure shows the general process of data requests using the architecture. EHR: electronic health record.
The blockchain network offers advantages in managing digital assets [
As blockchain is a fully distributed system, we have built 3 layers on the top of the private blockchain network:
Data requests from one health facility to another trigger certain functions of smart contracts through the
To build the blockchain system, each health care facility is required to provide at least one blockchain node, which is an electronic device that can install the blockchain system. In our setting, each node runs the official Go implementation of the Ethereum protocol on an Ubuntu Linux server. To connect the blockchain with EHR systems, we have developed a blockchain adapter, which is a blockchain node designed to abide by the local data access policies set by individual health care facilities [
To ensure the security of health care data and meet the needs of current EHR operations, our blockchain system does not store patient data. There are two main reasons for this. First, it is not practical to store a large chunk of health care data in a blockchain because of the health care facilities’ policies of sharing health information and blockchain storage constraints [
Each blockchain user, including the blockchain adapter, is represented by a hash value (account address) derived from the public key generated by the blockchain [
The foundation of our layered architecture is a private Ethereum blockchain, which involves an immutable chain of data blocks consisting of committed ledgers and multiple blockchain nodes synchronously maintaining the same chain of data blocks. In the overall architecture, this layer ensures data immutability, decentralized consensus, data transparency, and traceability. The private blockchain is initiated from a starting node with special settings to make the blockchain unique. The smart contracts are deployed through the starting node when the private blockchain is built. All the participating nodes from health care facilities must obtain permission from the starting node to join the system. This procedure will disallow unauthorized parties from joining the system. As the participating nodes joined into the system, the blockchain will automatically generate accounts for their blockchain adapters. All other users, such as patients and health care providers, need to opt into the system through health care facilities. The blockchain accounts will be generated for the users from each health care facility as soon as the applicants’ identities are proven.
The private blockchain stores all the transactions for (1) patients and health care facilities granting, revoking, and denying access to their EHR data; (2) authentication of patients and health care providers to retrieve the EHR data; and (3) health care facilities to store metadata for patient visits. The transactions will record the receiver, sender, contained data, and the timestamp into the blocks through blockchain adapters. Users can also make transactions in the backend blockchain console through the blockchain node. These transactions still need to pass smart contract regulations to become effective. Most users will interact with the graphical user interfaces (GUIs) built on the
The
The
Main part of the electronic health record manager smart contract code that defines the metadata structure. Blockchain adapters must extract the information and calculate the encrypt keys and then store them into the smart contract. The record will automatically associate with the adapter’s blockchain ID.
Extract the patient ID from the EHR data set.
Find a public key associated with the patient from the
Generate a random
Encrypt the EHR data set using data key and store the encrypted data to an
Use the patient’s public key to encrypt the data key. Call the encrypted data key “key cipher.”
Submit the following metadata to the blockchain:
Patient ID.
Encrypted data set location as a URL.
Key cipher.
Associated blockchain adapter ID.
The blockchain adapters will generate public and private key pairs following the Diffie-Hellman protocol using Node.js. The data encryption and decryption settings ensure that the data belonging to the patient is only decrypted by the health care facility that produced the data. The key cipher makes the data key more secure and can only be computed when the data owner is known.
Example of a patient’s metadata retrieved through blockchain. The information is decoded by the Remix web-based integrated development environment, which is connected to the retrieving blockchain node. The patient’s metadata contain data location, key cipher, data set ID, data set description, and creation time.
A scenario is described in this section to show the process of health care provider X retrieving patient A’s EHR. Through a mobile application or web browser with biometric authentication, Patient A can grant access privileges to health care provider X using the application program interface (API) to set data permission on the
Verify health care provider X’s permission to access patient A’s records through the
Retrieve patient A’s metadata from the
Request the encrypted EHR data set from the remote health care facility via an https service provided by blockchain adapter.
Retrieve the encrypted data using encrypted data set location information in EHR metadata.
Decrypt the EHR data set. This step involves decrypting the key cipher using the patient’s private key to obtain the data key that decrypts the EHR data set.
Similar processes will be used for sharing data between health care facilities and for patients retrieving their own EHR records. The entire process will be performed automatically through the blockchain adapter.
The
We implemented blockchain adapters as a Node.js application and used the web3.js package for interfacing with a blockchain node and https.js package for https secure web services. web3.js is also available in the Python library as web3.py. The https-based web services are mainly used for communication among blockchain adapters. The blockchain adapter is embedded as software that will install the missing component automatically, such as node.js and web3.js.
Blockchain adapter components and functions. Blockchain adapter extracts the metadata from the electronic health record, encrypts the electronic health record, stores the encrypted electronic health record into the secured data store, and maps the patient ID and data ID to the blockchain account. Blockchain adapters use https to interact with other adapters and communicate with the foundation private blockchain network through a blockchain interface. API: application program interface; EHR: electronic health record.
From the security and reliability point of view, the following design guidelines are strictly followed for the blockchain adapter:
Blockchain adapter is modeled as a nonhuman blockchain user and has its own private and public key pair when the blockchain account or address is established. The public key is made public via the
The https service uses a separate key and certificate file.
The Diffie-Hellman key agreement protocol is used for data set encryption.
When one blockchain adapter fails, transactions (data set exchange) with the associated organization will be interrupted, but transactions among all other organizations will not be affected.
With the above
To test the feasibility of our layered architecture, we built a blockchain environment that contains 1 starting node and 4 health care facility nodes. All the nodes have installed an Ubuntu 18.04.2 operating system and Go Ethereum with the default PoW setting. A blockchain adapter has been installed to each node to communicate with the blockchain and its own secured data store, which was implemented using MongoDB. We created 100 accounts for health care providers and 10,000 patient accounts on each health care facility node of patients’ records from the Surveillance, Epidemiology, and End Results database [
After setting up the environment, we implemented 2 applications to interact with our blockchain system. The applications are built off-chain but can communicate with the blockchain system using node.js. These 2 applications are examples of the potential use of the layered blockchain architecture. We tested the accuracy, scalability, and speed of our system. We made the following assumptions to simulate the 2 processes: (1) each clinical site has provided at least one node to the system, (2) each clinical site agrees to connect the blockchain adapter to the secured data store, and (3) patients have authorized the blockchain system as well as the 2 applications to access their health records.
This application provides an interface for users to manage access to personal health care records through the
The simulation only contains the period of interactions with the blockchain. Retrieving data is an off-chain process through the https portal and varies with different health care facilities. From our simulation results, the system breaks at a certain point when the scale reaches 14 transactions per second (TPS). We simulated 331,142 access-granting transactions. All the transactions have successfully retrieved the records except the last second’s 14 transactions due to reaching the Ethereum scalability limitation. The average time of writing a transaction to a block is 11.271 (SD 2.208) seconds. We did not find a correlation between TPS and validation time. All health care providers received the metadata in an average of 1.73 seconds.
In this study, the scalability of the blockchain using various transaction frequencies from 1 to 14 TPS through blockchain adapters was tested.
Box plot of simulation results for 1 to 13 transactions per second groups. The boxes show the different quantiles of time cost related to different scales of transactions per second.
To prove the compatibility of our layered blockchain system, another application was implemented as subject recruitment for clinical trials. This application involves posting criteria, granting permission, and data exchange. To use this application, each clinical trial sponsor needs to provide at least one blockchain node with a blockchain adapter installed. All patients who want to participate in clinical research are required to opt into the application so that they can receive the recruitment criteria. This application involves the following procedures:
Clinical research recruiters will send recruitment criteria to the opted-in patients in the
Patients who received the criteria can check whether they are matched. If they are interested in clinical research, they can authenticate the clinical research recruiter to access their EHR.
Recruiters will be notified by the blockchain of whether any patients have granted their permissions to access their data. Then, they will retrieve patient data for precise matching.
The recruiters will notify the patients if they are matched and send further instructions.
We have implemented a GUI to demonstrate the usage of this application. Patients need to opt for this application to receive the current clinical trial recruitment information. We randomly selected 4 sponsors to post their recruitment criteria using their blockchain adapters through the blockchain
Graphical user interface for patients to permit clinical trial sponsors to access their data. The graphical user interface shows the patient’s blockchain address, opt-in status, current recruiting trials’ basic recruitment criteria, and permission options. When the patients select the recruiting trial and click submit, the sponsor will be added to their access list in the USER manager smart contract through the blockchain adapter.
This paper described an augmented layered blockchain system in development for most health care applications involving data coordination across multiple health care facilities. The design of this layered architecture provides generic functions and methods for application developers to securely collect data from different sources without requiring extensive experience of the blockchain technology. The layered architecture allows users the ability to audit the legitimacy of previously occurring transactions but prevents users from modifying any components in the blockchain. The features of blockchain provide a solution to current data coordination challenges. The blockchain-based approach extends the ownership of the EHR data set to each patient. On the basis of decentralized features of blockchain technology for peer-to-peer transactions, this approach can greatly reduce the health care data set sign-off and release. Data security and authenticity are also guaranteed by the immutability of the blockchain and smart contract–regulated data exchange.
Through our simulation process, our system empirically proved the feasibility of the architecture for health care applications. We also tested the scalability of our blockchain system and provided an optimal solution to avoid blockchain scalability constraints. Our future work will continue to evaluate the validation mechanism to improve the blockchain performance and add an AI component on the
The main limitation of our approach is the setup requirement from each participating site. Each health care facility is required to provide at least one blockchain node to the system and keep an encrypted EHR outside of the operation EHR for registered patients into the secured data stores that can communicate with blockchain adapters. Patients will potentially also need to provide blockchain nodes such as mobile devices to exchange and store their personal health records generated by their personal medical devices. The performance of the model can be affected by the properties of the blockchain node. If a single node creates a mass of transactions at the same time through the blockchain adapter, this action will use up all the memory and break the node before it is sent to the blockchain.
artificial intelligence
application program interface
electronic health record
graphical user interface
health information exchange
Ministry of Science and Technology in Taiwan
Proof of Work
transactions per second
This research was supported in part by the University of Missouri Informatics and Data Science Research Initiatives (YZ and CS), the Ministry of Science and Technology in Taiwan (MOST) under grant numbers MOST 108-2634-F-468-001, and MOST 108-2511-H-468 -002 from through Pervasive Artificial Intelligence Research Laboratories (YC and ZS).
None declared.