Blockchain-Based Electronic Medical Records System with Smart Contract and Consensus Algorithm in Cloud Environment

Abstract

The blockchain is a peer-to-peer distributed ledger technology that works on the precept of “write-once-read-only.” In a blockchain, pieces of information are arranged in the form of blocks, and these blocks are linked together using the hash value of previous blocks. The blocks in a blockchain mechanism are appended only, which means that once information is stored in a block and it cannot be changed; no one tampers the block’s content. The traditional electronic medical records (EMRs) based system stores the patients’ information in a local database or server, which provides centralization of information, and traditional EMRs are more centric on the health providers. So, security and sharing of patients’ information are difficult tasks in the traditional EMR system. The blockchain mechanism has the potential to resolve these existing problems. Due to the appended-only-ledger principle and decentralization of blocks between the network participants, blockchain technology is suited to the EMR system. In this article, first, we discuss all the existing EMR systems and discuss their drawbacks. Keeping all the drawbacks in our mind, we propose a blockchain-based medical record system that utilizes clouding technology for storage purposes. Furthermore, we have designed a smart contract and consensus algorithm for our proposed EMR. Our system only uses a permissioned blockchain model so that only verified and authenticated users can generate their data and participate in the data-sharing system.

1. Introduction

In the recent epoch, patients’ medical information is growing rapidly due to the collaboration of information technology (wearable Internet of things devices, e.g., wearable sensors) and the healthcare system. The patients’ medical information is important because it provides significant help for medical researchers as well as service providers to turn up with the proper result, which will help to diagnose patients [1]. Medical researchers and service providers often want to share patients’ data. So securely storing the patient data is a crucial task [2]. The traditional electronic medical record-based (EMR) system does this task. The EMR-based system provides real-time patient records, ease of access to these records, improved accuracy, sharing of patient data between different researchers, and safety and security to the patient data compared to the paper-based system [3]. In the paper-based system, maintaining and storing patient data is a difficult task (such as huge numbers of rooms are needed to store patients’ records, etc.), and the safety of records is also not guaranteed [4, 5]. Malicious users are easily able to do harmful activity in these records. To rectify these problems, the electronic medical record-based system is used in comparison to the paper-based system. But still, in the traditional EMRs-based system, many pitfalls are present.

1.1. Shortcoming of Existing Electronic Medical Record (EMR)-Based Systems

Currently, electronic medical records (EMRs)-based systems are widely popular because they can manage the huge volume of patients’ data and provide easy access to these data. But although, there are several drawbacks present in the existing EMRs-based system.(i)The EMRs-based system stores data related to a patient in a local database or server, which provides centralization to the patients’ data [6]. If users or service providers want to access the patients’ data, they directly access it without the patient’s intervention.(ii)The traditional EMRs-based systems are more centric on health providers. The health providers (i.e., hospitals, authorities, etc.) share the patient’s data without the patient’s knowledge. Therefore, they can manipulate the data. As a result, the originality and integrity of data are at high risk.(iii)The records of the patients are not secure and safe in the traditional EMRs-based system. Malicious users (or) attackers enter the EMR system due to the lack of security and privacy mechanism [7, 8] present in these systems, and then they tamper (or access) the patient’s data.(iv)The sharing of patients’ data in the traditional EMRs-based system becomes problematic because different health providers use different encryption methods and schemas [9]. (even if the patient has agreed to share the data with service providers).(v)Currently, IoT-based smart devices [4, 10, 11] (i.e., wearable sensors) are also generating the patient’s data. Generally, cloud servers (such as storage) are used to store patient’s data [12, 13]. But, this mechanism demands more cost and time in maintenance. Therefore, the system’s overall efficiency has degraded [14, 15].(vi)Due to the health providers’ centric approach, they can modify the patients’ data. So updating the medical records in the EMR system is also a big challenge.

In summary, the current EMR system has several pitfalls, such as centralized storage and inadequate access control mechanism. Therefore, a decentralized technique is highly required to store the patient’s data, and at the same time, it should provide privacy and security, proper access control mechanisms [16], and authenticity for the patients’ data [7, 17, 18]. The blockchain mechanism can solve the problems mentioned earlier. Due to its inherent characteristics, it is well suited to healthcare applications [4, 5, 14, 15].

1.2. Motivation behind the Proposed Work

Many pitfalls exist in the traditional electronic medical records (EMRs) system, which motivated us to propose a new framework for the EMR system using blockchain technology. A few of them are discussed here.(i)In the traditional EMR system, patients’ data is stored in the central database, and in a centralization system, the “single-point-failure” problem exists. This existing problem motivates us to design a new system in which patients’ data is stored in a decentralized way such that if any node fails, then also we will be able to retrieve the patient’s data. The blockchain mechanism is well suited for the abovementioned problem.(ii)In the traditional EMR system, the security and privacy of patients’ data in vulnerable. The present system does not provide a sufficient solution for these problems. With the integration of blockchain technology in the current EMR system, patient data security and privacy can be achieved.(iii)The traditional EMR systems are more centric on health providers. They share the patients’ data without the knowledge of patients. To rectify this problem, a suitable system is needed where patients are the central authority for sharing their medical data with other providers.(iv)In the traditional EMR system, health providers cannot share the patient’s data, even if patients concur to share their data. The reason behind this problem is that health providers use different schemas to store the data in their local databases.

So, a proper mechanism is needed which can resolve all these problems. Blockchain technology has the potential to resolve all these problems.

1.3. Major Contributions

This article presents the following contributions:(i)We have rigorously performed the literature review for the blockchain-based electronic medical health record system and then we have also discussed the shortcomings of the existing system.(ii)A proposed framework for an electronic medical health record system with blockchain technology has been proposed by considering all aspects of the EMR system.(iii)We have designed a smart contract algorithm using a finite state machine for the proposed EMR system.(iv)We have also designed a consensus algorithm for the proposed EMR system.(v)Finally, we have given some future research challenges with security concerns.

1.4. Organization of the Article

The rest of the article is organized as follows: the literature review for the EMR system is presented in Section 2. Section 3 deals with the proposed architecture with smart contract and consensus algorithm, followed by concluding remarks for the article in Section 4.

2. Related Works

Many authors attempted to solve the problems of the traditional EMRs based system by using the blockchain mechanism [4, 5, 19, 20]. Some authors also used the smart contracts mechanism to solve it. Uddin et al. [4] proposed “A Patient Agent (PA) Based Remote Patient Monitoring (RPM) Architecture.” Every patient has its own patient agent in their architecture, which is stored on the patient local server (PLS). In their architecture, PA selects one node as a miner among the available nodes, and the miner’s work is to generate a hash value of the current block. Xia et al. [5] proposed a blockchain-based data-sharing scheme. The framework proposed by Xia et al. addresses the problem associated with sensitive data stored in the cloud environment. The authors suggest the patient-centric solution in [12] for health data sharing system, using a private blockchain. Azaria et al. [19] proposed a MedRec: a decentralized record management system to handle electronic medical records using blockchain technology. The problem with the proposed architecture is the security of the individual database. They did not address this problem, and the key management problem remains unsolved in the proposed architecture. Chen et al. [20] proposed a new business process for medical information sharing based on a blockchain mechanism. The proposed approach is “patient-centric,” where patients are the central authority for viewing and sharing their medical records. The limitation of this method is the smart contract mechanism.

Yang and Li [7] proposed a blockchain-based architecture for EHRs systems, using a new incentive mechanism to create a new block. The architecture works on top of the existing database, which healthcare provider maintains. Griggs et al. . [13] proposed blockchain-based smart contracts to secure remote patient monitoring. The proposed framework uses a private (permissioned) blockchain. Al Omar et al. [8] proposed a permissioned blockchain-based healthcare data management system to attain privacy and security. The proposed solution is a “Patient-Centric” approach in which the patient is the sole authority to keep the data on a blockchain. Dubovitskaya et al. [9] proposed a blockchain-based healthcare data management framework, especially for electronic medical records (EMRs) systems. They provide a secure and trustable framework for sharing in the EMR system. Novikov et al. [21] presented a decentralized blockchain-based infrastructure to store patients’ electronic medical records (EMRs) in a healthcare system.

Table 1 compares the existing blockchain-based medical records system concerning blockchain taxonomy (i.e., smart contracts, consensus algorithm, authentication, key management, and 51% attacks, etc.). In Table 1, two abbreviations are used: ND and PB. In this specific column, PB means the type of blockchain is permissioned blockchain, and ND means that the authors did not discuss the type of blockchain. The solution provided by the authors is applicable for both permissioned and permissionless blockchains. ND means that the respective authors did not discuss the corresponding blockchain taxonomy in other columns. Table 2 compares the existing approach with its advantage and disadvantage.

Table 1 

The comparison of existing approaches with their advantages and disadvantages.

Table 2 

The comparison of existing approaches with their advantages and disadvantages.

3. Proposed Architectures

3.1. System Overview

Our proposed architecture comprises the following components (or entities): a central authority and a management system, known as CAMS, a list of the service provider (e.g., doctors, insurance companies, and research organizations, etc.), the user (generally, a patient), a pool of Data Lake, hash generators, and a cloud server. These entities are connected using a decentralized peer-to-peer architecture. The architecture of the proposed system is shown in Figure 1.

Figure 1 

Proposed architecture.

3.2. Role and Responsibilities of the Involved Entities

(i)Central Authority and Management System (CAMS): the CAMS is responsible for generating a pair of keys and issuing the same keys using the cryptographic mechanism to the user and service provider. The proposed framework utilizes the permissioned blockchain system. If any new user or service provider wishes to join the system, firstly, they take permission from CAMS. Here permission means that the CAMS authenticate them because the new user or service provider may be a malicious user. CAMS is also responsible for managing the entire system. CAMS has a list of users and service providers who are already present in the network. If any new user or service provider joins, then after the process of key generation and authentication, CAMS updates the list, which tells that currently how many users and service providers exist in the system.(ii)User: the user is generally a patient who wants services from service providers. All users have a copy of smart contracts which tells about the agreement or set of protocols—the copy of smart contracts issued by the CAMS. If any user wishes for services from service providers, this request is checked by smart contracts. If smart contracts are executed correctly, then, only the user can take the services from service providers; otherwise, not. The service providers are doctors, hospital authorities, insurance claim companies, and medical researchers, etc.(iii)Service providers: service providers provide their services to the user according to the need of the user. Service providers are doctors, insurance companies, laboratory offices, and scientific researchers, etc. The user consults with a doctor for specific medical treatment. The doctor gives suggestions accordingly. Doctors often suggest a specific medical test according to the user’s problem. For this, the user goes to the laboratory office (inside or outside the hospital) to perform the test. If the laboratory office gives the result immediately to the patient, then the patient shows these results to the doctor and gets suggestions for some medicine, if required. Sometimes laboratory office directly gives the result to the doctor. Many users also take insurance plans like health insurance plans and term insurance plans according to their needs; therefore, insurance companies have also come into the picture as service providers. Pharmaceutical companies interact with doctors and insurance companies to brand and sell their medicine. Scientific researchers interact with different service providers (doctors, pharmaceutical companies, and users) for their research. Due to all these activities, a huge volume of data is generated. The EMRs system without a blockchain cannot handle this (as discussed in section 1). But by using the blockchain with EMRs system, trust in a patient’s data increases and transparency of the entire system (iv)Pool of data lake: the pool of Data Lake contains the bunch of data that users and service providers generate. Service provider gives their services (a patient consults a doctor and provides description of health records and insurance records) to the user; and all these huge amounts of data are kept inside the pool of Data Lake. The pool of Data Lake is a container (or database) used only to store the generated data.(v)Hash generators: the hash generators generate the hash value of the current block. The hash generators module takes the data from a pool of Data Lake and converts it into the size of a specified block. First, they validate the block. After the validation process, they keep the block inside the blockchain system. CAMS specifies the size of the block. In the proposed system, more than one hash generators exist. The CAMS module picks the suitable hash generator, depending on the existing performance of hash generators. So at any point in time, only one or two online hash generators are available.(vi)Cloud server: the cloud server only stores the blocks in the blockchain network. Our proposed architecture uses the cloud server instead of a local database because the volume of data is high. As per the discussion in section 2, these blocks are connected by using the hash value of previous blocks, so tampering with the data in any block is impossible. If scientific researchers want to use the patient's data for research purposes, they can use it with the user’s permission only. Without the user’s permission, scientific researchers, as well as service providers, are not able to take and share the user's data. Since the user data are stored in the blockchain system, using the cryptographic mechanism, it provides security for tamper-proof and immutable of user data.

3.3. Algorithm for the Proposed System

The algorithm for the proposed system is as follows:(i)Step 1. CAMS authenticates the user who wants services from the service provider.(ii)Step 2. If the user’s authentication is successful, then the user is granted to take services from providers; otherwise, the error message is generated: authentication is not successful.(iii)Step 3. If a new user wants to join the system, the new user may join after CAMS approval. The CAMS generates the pair of keys, and steps 1 and 2 are repeated.(iv)Step 4. The user consults with service providers, and the data generated by them are kept in a pool of Data Lake.(v)Step 5. The hash generators collect the data from the Data Lake pool, verify it, convert it into a block, and add it to a blockchain by using the previous block’s hash value. This step is repeated after a while.(vi)Step 6. Steps 4 and 5 are repeated for every user who wants services from the provider.(vii)Step 7. Finally, the blockchain is stored in a cloud server.

3.4. Smart Contract Algorithm of the Proposed System

As per discussion, in Figure 2 in section 2.6, smart contracts are based on the state machine model, and the state machine model is always a deterministic state machine model. Smart contracts are define the set of rules, which are written in the form of the program (or scripts). This set of scripts are stored on all the nodes of the blockchain system. In turn, the blockchain nodes execute these scripts to perform certain activities or transactions in the network [22, 23]. By using the same concept, we also propose a deterministic state machine model for the proposed system since a deterministic state machine model is represented as a directed graph, and a directed graph consists of a set of vertices and a set of edges. In the deterministic state machine model, these sets of vertices are referred to as a set of states, and a set of edges is referred to as a transition from one state to another state or in the same state. The advantage of showing the smart contracts using the state machine model is that it is very easy for the developer to write the code by seeing the flow of the state machine. Moreover, it triggers the events to achieve the necessary behavior, which suits the EMR system. Furthermore, disclosing the smart contract code to external parties is not required. They can predict the system behavior and write the code with add-on requirements. Our proposed state machine consists of 4 states: labeled as state 0, state 1, state 2, and state 3. The user is represented as state 0; CAMS is represented as state 1; service providers are represented as state 2. State 3 is called a dead state. The proposed state machine model is shown in Figure 2.

Figure 2 

Smart contract using a finite state machine.

1 Require: Actions such as Authentication, Violation, Permission, No Action 2 Ensure: Messages such as Authentication successful, Error and abort, Permission granted, No Action required 3 FOR STATE 0 AND STATE 1:Action: Authentication, violation, No action 4 If (f(Action) = = Authentication) then 5 f(Message) = authentication is successful; 6 move: S (1)   S(0); 7 Else if (f(Action) = = No Action) then 8 f(Message) = No action required; 9 move: S (0)   S(0); 10 Else if (f(Action) = = Violation) then 11 f(Message) = error and abort;; 12 move: S (3)   S(0); 13 End if 14 FOR STATE 2:Action: Permission, violation, No action. 15 If (f(Action) = = Permission) then 16 f(Message) = take permission; 17 move: S (1)   S(2); 18 Else if (f(Action) = = No Action) then 19 f(Message) = No action required; 20 move: S (2)   S(2); 21 Else if (f(Action) = = Violation) then 22 f(Message) = error and abort; 23 move: S (3)   S(2); 24 End if 25 FOR STATE 3:Action: Permission, authentication, violation, No action 26 If (f(Action) = = Permission/Authentication/Violation/No Action) then 27 f(Message) = error and abort; 28 move: S (3)   S(3); 29 End if

Algorithm 1 

Smart contracts as state machine model.

In the state machine model, certain actions are defined: Authentication, No Action, Violation, and Permission. This set of actions is used to transition from one state to another. For example, if the machine is in state 0 and the action is Authentication, then the machine automatically moves from state 0 to state 1. If the machine is in state 1 and the action is Violation, then the machine automatically moves from state 1 to state 2. If the machine is in state 2 and the action is No Action, then the state does not change and so on (see Algorithm 1).

The solidity programming language can be used to implement the proposed smart contract for the EMR system. It is a statically-typed programming language influenced by other languages such as JavaScript, C++, and Python. Moreover, this language is designed to run on the Ethereum Virtual Machine (EVM). The Remix IDE with the solidity version 0.5.10 is used to execute the suggested smart contract. Remix IDE provides a convenient platform to deploy smart contracts. It provides three different environments (JavaScript VM, Injected Web3, and Web3 Provider) to execute and deploy smart contracts [24]. Furthermore, the execution cost plays a crucial role when smart contracts are executed in any of these three environments. Execution cost determines the total cost (in terms of “gas”) required to execute the defined computational operations.

3.5. Consensus Mechanism for Proposed System

The consensus algorithm is the set of rules to reach a common viewpoint or agreement. The consensus algorithm is designed so that, after executing the block, all the nodes (or majority of nodes) in a network agree that the block is valid and can be included in the blockchain network. Once the agreement is done, no node can change the decision. For the proposed system, we also designed a consensus mechanism for the verification and validation of a new block [25]. In our proposed architecture, a new block is verified and validated with the help of hash generators. The main work of hash generators is to validate the block (whether the correct user sends the block or data or not because it may be possible that malicious users send the data in a pool of data lake, so validation is needed) and after the validation of new block, generate the hash value of new block, and finally add them in a blockchain.

1 Require: Authentication value, Validation value, Genesis block 2 Ensure: New block, Blockchain length, Nonce-value SP[n] = list of service providers; HG[] = hash generators; Per[] = performance for hash generators; BCl = block chain length;    = authenticating value provided by hash generators;  = validating value provided by hash generators; BC: Blockchain; B0: Genesis block; 3 ; 4 ; 5 ; 6 ; 7 For do 8 Execute Per[HG[i]]; 9 End for 10 Per Per[HG[0]]; 11 For do 12 If then 13 Per Per[HG[i]]; 14 End if 15 End for 16 Display: Selected hash_generator) 17 For do 18 Check authentication of selected hash_generator; 19 If then 20 ; 21 End if 22 End for 23 If then 24 Display: Authentication is successful; 25 End if 26 Create a new block by using the selected hash_generator 27 For do 28 Check validation of new_block by all hash_generators; 29 If then 30 ; 31 End if 32 End for 33 If then 34 Display: Validation is successful; 35 End if 36 While (TRUE) do 37 Calculate the Proof_Hash value for new_block; 38 If then 39 ; 40 End if 41 Change Nonce_value; 42 End while

Algorithm 2 

A consensus algorithm for proposed architecture

In the proposed architecture, more than one hash generator exists but only one hash generator is responsible for validating and generating the hash value of the new block. The work of other hash generators is to validate the new block. The selection of hash generators is based on the previous performance of the hash generators or on the stake or wealth deployed in the network because the service providers also act as hash generators. The reason behind this is if the service providers act as a hash generator, based on their wealth deployed in a system, then the chance of malicious activity is very less because in that case, if they are performing a malicious activity, they are damaging their own wealth. In the proposed system, two categories of hash generators exist. In the first category, only one hash generator exists which is responsible for both validating as well as generating the hash value of the new block, and in the second category, remaining hash generators exist which are responsible for validating the new block only (see Algorithm 2).

3.5.1. Consensus Mechanism of the Proposed System

(1)In the first phase, after the selection of the hash generator, the remaining hash generators first authenticate this selected hash generator. If [ceiling (N/2)] number of hash generators authenticates this selected hash generator (assume that in a system “N” number of hash generators exist, excluding the selected one), then authentication is successful and it proceeds further; otherwise, the system aborts it with a message: authentication not successful; error message.(2)In the second phase, the selected hash generator picks the data from the pool of Data Lake, converts it into a block, and sends the new block to other hash generators for validation. All the hash generators, including the selected one, validate the new block. If [floor (N/2) +1] number of hash generators, validate the new block (assume that in a system “N” number of hash generators exist, excluding selected one, +1 is used for selected hash generator) then validation of a new block is successful and it proceeds further, otherwise, the system aborts it with a message: validation not successful; error message.(3)In the third phase, the selected hash generator generates the hash value of the new block and is added to the blockchain system.

4. Conclusion

In this article, we present the blockchain-based novel approach for electronic medical records (EMRs) systems. The proposed blockchain-based system provides several advantages compared to traditional electronic medical records-based systems. Traditional EMRs systems are more centric on healthcare providers. Whereas the proposed BMRS approach is centric on the patient only, which means that if the healthcare providers want to access the patient’s data, they can access and share the patient’s data with the patient’s permission, which is an advantage over the traditional EMRs system. In the proposed architecture, hash generators are responsible for the maintenance of the blockchain system, including the creation of a new block, validation of a new block, and finally, adding the block to the blockchain network. The service providers also act as hash generators. The proposed system considers both smart contracts mechanism as well as a consensus mechanism. The smart contracts mechanism is based on the state machine modal. Hash generators use the consensus algorithm to authenticate the healthcare providers and to validate new blocks.

In future work, our research team will try to incorporate the incentive mechanism with its mathematical model and provide a solution for the mitigation of various attacks, such as routing attacks and phishing attacks that increase the security of the EMR system.

Data Availability

The datasets generated or analyzed during the current study are not publicly available because the data are strictly confidential because the manuscript is based on patient records that are maintained electronically. The authors understand that these data are to be maintained confidentially and hence they are not provided in the manuscript or elsewhere.

Conflicts of Interest

The authors declare that they have no conflicts of interest.