# A Blockchain-Assisted Electronic Medical Records by Using Proxy Reencryption and Multisignature

Authors: Xiaoguang Liu; Jun Yan; Shuqiang Shan; Rongjun Wu
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Electronic medical records (EMR) have been commonly used in medical institutions in recent years. In particular, the combination of EMR and the cloud server has significantly improved the work efficiency and therapeutic level of the hospital. It also raises some security concerns, e.g., the information leaks. Blockchain has features including decentralization, traceability, openness, and tamper resistance. Therefore, the technology may be used to overcome the above flaws. In this paper, we introduce a new blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature. Firstly, blockchain makes the scheme have high-security performance without a trusty center. Secondly, we use proxy reencryption to protect personal medical data while helping doctors to access patients’ historical medical records. Moreover, the doctors have used a sequential multisignature, which is practical and can effectively improve security performance. The analysis results show that the proposed scheme can satisfy various security features of EMR and has an ideal computational and communication cost. Finally, the scheme is implemented to show its performance.


---

## Body

## 1. Introduction

With the full application of modern information technologies such as big data, cloud computing, and artificial intelligence in the medical field, medical informatization has exerted a significant influence on the optimal allocation of medical resources [1, 2]. EMR has emerged from this context, and it uses electronic devices (such as computers and smartphones) to store, manage, and transmit digitized medical records [3]. It can significantly enhance the work efficiency and therapeutic level of the hospital [4]. Also, EMR provides a judgment basis for dealing with medical malpractice [5]. When a patient goes to see a doctor, his/her medical history can help the doctor make an accurate diagnosis. However, most patients are often unable to detail their medical history due to long-time intervals and a lack of relevant expertise. It will affect the current diagnosis and increase the fiscal burden. Therefore, an ideal EMR should be able to help doctors timely obtain complete and accurate historical medical information. Furthermore, security and privacy preservation are crucial in EMR since medical information is sensitive and personal [6, 7].EMR has developed significantly in recent years of its remarkable advantages, such as transmitting fast and easy to use [8, 9]. Notably, the emergence of cloud storage is a new milestone in the development of EMR [10]. They move medical data from the traditional data center to a cheaper and safer cloud server. It can improve work efficiency and allow hospitals to invest more time and resources in diagnosis and care. Thus, researchers proposed many cloud-assisted EMR architectures in recent years. However, the privacy, confidentiality, and integrity of medical data will face more threats since the data is outsourced to a third party, i.e., the cloud [11]. For example, doctors can collude with the cloud server to modify their erroneous diagnoses in medical malpractice. So, how to improve the efficiency of data storage and data sharing while ensuring data security and protecting patient privacy is the focus of research [12, 13]. It is necessary to design a lightweight, efficient, and secure EMR system.Blockchain technology was introduced in 2008 [14]. It is a decentralized distributed (distributed in multiple locations and able to work together) database system. Blockchain has features of decentralization, tamper-resistant, openness, autonomy, and traceability. It can effectively overcome the adverse effects of centralization and reduce the cost of trust [15]. Therefore, blockchain may be a promising assisted technology of EMR, and it has received attention [16]. However, when blockchain technology is applied to the medical industry, it must be measured between improving efficiency and reducing cost. Only when appropriate blockchain technology is adopted and the system efficiency and operating cost are well balanced, can the business model be established. In addition, many problems are still unsolved before satisfying the practical application in recurrent [17, 18]. For example, (1) the data owner usually encrypts the data with the public key of the user or the session key of both parties, which leads to weak data sharing; (2) only the diagnosis of a single doctor was considered, regardless of a situation in which multiple doctors consult; (3) the cost of computing, communication, and storage is too high.In this paper, we propose a blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature, and we call it BC-EMR. In BC-EMR, a group key and a sequential multisignature are utilized to enhance data security (a diagnosis may be made by a doctor or multiple doctors) [19]. Proxy reencryption helps doctors to access patients’ historical medical records while protecting data [20]. Especially, blockchain technology has enabled BC-EMR to overcome many flaws in general cloud-assisted EMR and dramatically improve security [21]. BC-EMR has an ideal computational and communication cost. The main contributions are listed as follows:We establish a group key between a hospital’s server and the doctors of one team utilizing a lightweight one-to-many authentication protocol. It can protect the patient’s information.We propose a blockchain-assisted EMR in the cloud environment by using proxy reencryption and sequential multisignature. The proposed scheme not only can realize the safe storage of data but also make secure data sharing between doctors at different hospitals.The security analysis of BC-EMR is given. The results show that BC-EMR can satisfy various security features. It also can fend off some specific threats, such as illegal cooperation between doctors and the cloud. Finally, we compare the computational and communication cost of BC-EMR with three existing schemes and then have implemented BC-EMR.The remainder of the paper is organized as follows. In Section2, we introduce related works. The preliminaries are presented in Section 3. In Section 4, we introduce the details of BC-EMR. In Section 5, the security analysis of BC-EMR is given. In Section 6, we evaluate the performance of BC-EMR and implement it. Finally, we conclude our paper in Section 7.


## 2. Related Works

Ekblaw et al. [22] used the Ethereum platform to realize MedRec that is a medical information sharing platform combining medical blockchain and big data. The system makes use of blockchain, the embedded authentication system, the security system, and an accountability system, which can provide users with powerful security technology when dealing with sensitive information. Xia et al. [23] proposed a blockchain-based health data sharing architecture that only allows the invited (verified) users to access. Thus, it solves many of the access control challenges associated with sensitive data. They have also come up with a system called MeDShare in [24]. The scheme deals with the problem of sharing medical data with big data custodians in untrusted environments. It uses smart contracts and access control mechanisms to track data behavior. Xue et al. [25] proposed a medical blockchain system by combining the medical server and auditing server. Zhang et al. [26] used a hospital-owned private blockchain to store patients’ health data, and the consortium blockchain to store safety indexes for personal health data. In particular, the authors have described the details and implemented the scheme on JUICE. In [27], Ivan analyzed the feasibility of using blockchain to protect health data, the implementation barriers, and specific plans for transitioning from current technology to blockchain solutions. Cao et al. [28] proposed a secure cloud-assisted EMR. This scheme utilizes Ethereum platform-based blockchain to protect outsourced medical data. Because every operation of the EMR is put into the blockchain as a transaction, it has excellent security. Esposito et al. [29] comprehensively analyzed the potential of blockchain to protect medical data in the cloud. They also pointed out the practical challenges and future works. Israa et al. [30] elaborated on the benefits and threats of blockchain technology in healthcare. Abdellatif et al. [31] introduced a new smart and safe healthcare system, which takes advantage of edge computing and blockchain to allow for epidemic detection and remote monitoring. The system also allows for the secure exchange of medical data between local medical entities. Shen et al. [32] analyzed the topological relationship among participants in the process of income distribution and established some Shapley value models from simple to complex. Based on the analysis of distribution rules, the incentive effect of secure data sharing and the rationality of the design scheme is discussed. Patil et al. [33] proposed an efficient blockchain authentication protocol for the Internet of Things based on the secret computational model of a physically unclonable function, which can guarantee data provenance and data integrity. Based on the elliptic curve digital signature algorithm, Xiong et al. [34] introduced an efficient and large-scale batch verification scheme with group testing technology for blockchain-enabled IoMT. Zhang et al. [35] proposed a reliable and efficient system based on edge computing and blockchain. Simulation results show that the proposed method has better computational efficiency and higher reliability than the existing methods. Cheng et al. [36] designed a blockchain-based data-sharing network model for medical cyber-physical systems and used BAN logic to analyze security protocols. Saini et al. [37] built an access control framework based on smart contracts, which is built on top of distributed ledger (blockchain) to ensure EMR sharing between different entities involved in smart healthcare systems.In Table1, we give a comparison between the different schemes introduced above. For convenience, we let F1, F2, F3, F4, and F5 denote payment for the blockchain platform, consensus mechanism and reduce the pressure for the main chain, the demand for calculating power, and the private blockchain.Table 1
Comparison between existing schemes.
SchemesF1F2F3F4F5[22]√POW×Big×[23]×DPOS√Small√[24]×DPOS√Small√[25]×Improved DPOS√Small√[26]×DBFT√Big√[28]√Improved DPOS√Small√[36]×Improved DPOS√Small×[37]×POW√Small×Ours×Improved DPOS√Small√√Support; ×not-support.


## 3. Preliminaries

### 3.1. Blockchain

Blockchain is a novel application of distributed data storage, peer-to-peer transmission, and consensus mechanism, etc. [38]. As shown in Figure 1, a blockchain system consists of many blocks, and each block contains a block header and a block body. The block header includes the hash value of the current block, the timestamp, the hash value of the previous block, and so forth. Block body stores some transaction records. Its main characteristics are listed as follows:(1)
Decentralization: there are numerous nodes distributed in the blockchain network, which can be freely connected to exchange information without any third institution.(2)
Tamper resistance: after the information is added to the blockchain by consensus mechanism, all nodes will record it. Each block contains the hash value of the previous block. If a block’s data is modified, all the blocks behind that block need to be changed, which is almost impossible.(3)
Traceability: blockchain stores all data through the block data structure, and any data stored in the blockchain can trace its origin through the chain structure.(4)
Openness: any node can get the ledger of the whole network. Except for the information of the parties directly related to the data being encrypted by asymmetric encryption technology, other data is open to all nodes.(5)
Autonomy: the use of a consensus mechanism in blockchain enables all nodes in the whole system to freely and securely exchange, record, and update data.Figure 1
The basic structure of blockchain.


### 3.2. The Basic Requirements of EMR

(1)
Security and Privacy Preservation. (a) The system can resist malicious attacks on medical data such as forgery attacks, modification attacks, replay attacks, guess attacks, man-in-the-middle attacks, and trackable attacks. (b) Nonrepudiation. The participants cannot deny the historical data generated by themselves. (c) Confidentiality. The data transmitted and stored in the network is sensitive personal information, so the system needs to resist data leakage. (d) Authenticity. The data cannot be illegally modified. For example, in the cloud environment, the system can prevent doctors and the cloud from conspiring to tamper with medical data.(2)
Data Sharing. Authorized third parties such as other doctors can access the patient’s historical medical data with the consent of the patient. In particular, these data may be generated from different doctors at different hospitals.(3)
Patient Control. Patients can control other people’s access to their historical medical records.(4)
Uniform Standard. There are uniform data standards and sharing principles among all participants in the system, which is conducive to improving the efficiency and stability of the system.


### 3.3. Bilinear Map

LetG1 and G2 denote two multiplicative groups, respectively, and they have the same prime order p. If a map e:G1×G1⟶G2 satisfies the following three properties, then e is called the bilinear map [39]:(1)
Bilinear: for any pointsA,B∈G1 and any points a,b∈ℤp∗, eAa,Bb=eA,Bab is satisfied.(2)
Nondegeneracy: there is a pointA∈G1 so that eA,A≠1, 1 is G2 ’s an identity element.(3)
Computability: for any pointsA,B∈G1, eA,B can be computed within polynomial time.


### 3.4. Intractable Problems

(1)
Discrete Logarithm Problem (DLP): knowing two pointsA and B in G1 and A=Bn, it is hard to find n∈ℤp∗ so that A=Bn.(2)
Computational Diffie–Hellman Problem (CDH): knowing pointA in G1, for a given A,Am,An, it is hard to compute Amn, where m,n∈ℤp∗.


### 3.5. Proxy Reencryption

Proxy reencryption means that a delegateA generates a proxy reencryption key PKA⟶B of a delegatee B and then sends PKA⟶B to the agent. The agent uses PKA⟶B to convert the ciphertext encrypted with A ’s public key PKA to the ciphertext encrypted with B ’s public key PKB. It does not need to use A ’s private key to decrypt the ciphertext, and we will list the details as follows [40]:(1)
A encrypts the plaintext M with PKA, i.e., CA=EAPKA,M.(2)
A generates the proxy reencryption key RKA⟶B for B and sends CA and RKA⟶B to the agent.(3)
The agent convertsCA into CB utilizing RKA⟶B, where CB is M’s ciphertext encrypted with PKB. Notably, the agent only makes the transformation service of ciphertext and does not know M.(4)
The agent sendsCB to B that decrypts it using its private key to get M.


### 3.6. Sequential Multisignature

Sequential multisignature is a particular digital signature scheme. It means that multiple users sign the message in a specific order [19, 41]. A general sequential multisignature usually needs to execute the following four algorithms, i.e., Setup, Key Generation, Sign, and Verify:(1)
Setup: the key generation center (KGC) inputs a security parameter and generates system parameterpara, and system master key.(2)
Key Generation: givenpara, users Nii=1,2,…,n generate their private key SKi and then compute their own public key PKi by inputting SKi.(3)
Sign: the signerNii=2,…,n orderly verifies the partial signature si−1 of the previous signer Ni−1. If it is valid, Ni outputs own partial signature si signed by SKi.(4)
Verify: the verifier verifies the signatures by inputtingm,IDi,PKi,sni=1,2,…,n and the order of signature.


## 3.1. Blockchain

Blockchain is a novel application of distributed data storage, peer-to-peer transmission, and consensus mechanism, etc. [38]. As shown in Figure 1, a blockchain system consists of many blocks, and each block contains a block header and a block body. The block header includes the hash value of the current block, the timestamp, the hash value of the previous block, and so forth. Block body stores some transaction records. Its main characteristics are listed as follows:(1)
Decentralization: there are numerous nodes distributed in the blockchain network, which can be freely connected to exchange information without any third institution.(2)
Tamper resistance: after the information is added to the blockchain by consensus mechanism, all nodes will record it. Each block contains the hash value of the previous block. If a block’s data is modified, all the blocks behind that block need to be changed, which is almost impossible.(3)
Traceability: blockchain stores all data through the block data structure, and any data stored in the blockchain can trace its origin through the chain structure.(4)
Openness: any node can get the ledger of the whole network. Except for the information of the parties directly related to the data being encrypted by asymmetric encryption technology, other data is open to all nodes.(5)
Autonomy: the use of a consensus mechanism in blockchain enables all nodes in the whole system to freely and securely exchange, record, and update data.Figure 1
The basic structure of blockchain.


## 3.2. The Basic Requirements of EMR

(1)
Security and Privacy Preservation. (a) The system can resist malicious attacks on medical data such as forgery attacks, modification attacks, replay attacks, guess attacks, man-in-the-middle attacks, and trackable attacks. (b) Nonrepudiation. The participants cannot deny the historical data generated by themselves. (c) Confidentiality. The data transmitted and stored in the network is sensitive personal information, so the system needs to resist data leakage. (d) Authenticity. The data cannot be illegally modified. For example, in the cloud environment, the system can prevent doctors and the cloud from conspiring to tamper with medical data.(2)
Data Sharing. Authorized third parties such as other doctors can access the patient’s historical medical data with the consent of the patient. In particular, these data may be generated from different doctors at different hospitals.(3)
Patient Control. Patients can control other people’s access to their historical medical records.(4)
Uniform Standard. There are uniform data standards and sharing principles among all participants in the system, which is conducive to improving the efficiency and stability of the system.


## 3.3. Bilinear Map

LetG1 and G2 denote two multiplicative groups, respectively, and they have the same prime order p. If a map e:G1×G1⟶G2 satisfies the following three properties, then e is called the bilinear map [39]:(1)
Bilinear: for any pointsA,B∈G1 and any points a,b∈ℤp∗, eAa,Bb=eA,Bab is satisfied.(2)
Nondegeneracy: there is a pointA∈G1 so that eA,A≠1, 1 is G2 ’s an identity element.(3)
Computability: for any pointsA,B∈G1, eA,B can be computed within polynomial time.


## 3.4. Intractable Problems

(1)
Discrete Logarithm Problem (DLP): knowing two pointsA and B in G1 and A=Bn, it is hard to find n∈ℤp∗ so that A=Bn.(2)
Computational Diffie–Hellman Problem (CDH): knowing pointA in G1, for a given A,Am,An, it is hard to compute Amn, where m,n∈ℤp∗.


## 3.5. Proxy Reencryption

Proxy reencryption means that a delegateA generates a proxy reencryption key PKA⟶B of a delegatee B and then sends PKA⟶B to the agent. The agent uses PKA⟶B to convert the ciphertext encrypted with A ’s public key PKA to the ciphertext encrypted with B ’s public key PKB. It does not need to use A ’s private key to decrypt the ciphertext, and we will list the details as follows [40]:(1)
A encrypts the plaintext M with PKA, i.e., CA=EAPKA,M.(2)
A generates the proxy reencryption key RKA⟶B for B and sends CA and RKA⟶B to the agent.(3)
The agent convertsCA into CB utilizing RKA⟶B, where CB is M’s ciphertext encrypted with PKB. Notably, the agent only makes the transformation service of ciphertext and does not know M.(4)
The agent sendsCB to B that decrypts it using its private key to get M.


## 3.6. Sequential Multisignature

Sequential multisignature is a particular digital signature scheme. It means that multiple users sign the message in a specific order [19, 41]. A general sequential multisignature usually needs to execute the following four algorithms, i.e., Setup, Key Generation, Sign, and Verify:(1)
Setup: the key generation center (KGC) inputs a security parameter and generates system parameterpara, and system master key.(2)
Key Generation: givenpara, users Nii=1,2,…,n generate their private key SKi and then compute their own public key PKi by inputting SKi.(3)
Sign: the signerNii=2,…,n orderly verifies the partial signature si−1 of the previous signer Ni−1. If it is valid, Ni outputs own partial signature si signed by SKi.(4)
Verify: the verifier verifies the signatures by inputtingm,IDi,PKi,sni=1,2,…,n and the order of signature.


## 4. The Proposed BC-EMR

### 4.1. System Model

In this section, the details of BC-EMR will be given. We use the sequential multisignature of [41] and the proxy reencryption of [42] to construct the scheme. As shown in Figure 2, BC-EMR mainly consists of four entities, i.e., a doctor team, a patient, a hospital, and a cloud server. In BC-EMR, a patient first registers at the hospital. If the identity is approved, the hospital server assigns a medical team to the patient based on the initial condition. Then, the server and members of the team establish a group key that is used to protect the patient’s diagnosis results. In the diagnosis, when a doctor receives a message from the former doctor, he/she first verifies previous all doctors’ signatures. If it passes, the doctor will make the diagnosis and broadcast his/her signature in the blockchain. Otherwise, he/she requests the former doctor to resend the message. When the last doctor has finished the signature, he/she encrypts the result by using the patient’s public key and sends the ciphertext to the cloud server. The ciphertext and signatures will be stored in the cloud and blockchain, respectively, if the signatures pass the verification. Different doctors at different hospitals have the right to access the patient’s medical history with the patient’s consent. BC-EMR includes the following five phases, i.e., Initialization, Group key generation, Diagnose, Data storage, and Data sharing. In Table 2, we give the used notations in the paper.Figure 2
The basic structure of BC-EMR.Table 2
Notations.
Notationp,qTwo prime numbersSMThe system managerHiTheith hospitalPjThejth patientDkThekth doctorPK.The public keySK.The private keyID.The identitysThe diagnosis ordergThe generator ofG1KGCThe key generation centerE.EncryptionD.DecryptioneThe bilinear mapH.The hash functionMACThe message authentication codeγThe security parameter


### 4.2. Initialization

(1)
SM inputs a security parameter 1γ, selects the bilinear map e:G1×G1⟶G2 and a random number g¯∈G1 , where G1 and G2 are two multiplicative groups with the same prime order p. g is a generator of G1. Four hash functions are defined as follows: H0:0,1∗⟶G1, H1:0,1≤l⟶G1, H2:0,1≤l⟶G1, and H3:G2⟶0,1γ,  where l is the length of the verification keys [42]. Besides, SM selects a random number x∈ℤp∗ as the system master key, and the public key Y=gx. The public parameters of BC-EMR are p,g,Y,g¯,H0,H1,H2,H3,e,G1,G2. In BC-EMR, we limit the number of the signer reissues the signature to no more than N.(2)
HospitalHi selects a random number hi∈ℤp∗ as its private key and the public key PKi=ghi.(3)
PatientPj selects a random number pj∈ℤp∗ as the private key and sets PKj=gpj as the public key.(4)
DoctorDk randomly selects dk1,dk2,dk3∈ℤp∗, computes Ak=gdk1, Bk=gdk2, and Ck=gdk3. The private key is dk1,dk2,dk3 and the public key PKk=Ak,Bk,Ck.


### 4.3. Group Key Generation

When a patientPj sees a doctor in the hospital Hi, Pj sends an identity IDj and symptoms to HOi ’s server securely. If the identity is legal, the server first selects a random number λj∈ℤp∗, computes Pj ’s pseudoidentity PIDj=EhiIDj⊕λj‖λj and sends it to Pj. It also assigns initial doctors Dkk=1,…,n to make a diagnosis according Pj ’s condition, sends the evidence α∈0,1∗ and a diagnosis order s to Pj, and sends a signature timestamp T, α, and s to Dkk=1,…,n securely. Especially, as in Figure 3, a group key between Hi and Dkk=1,…,n will be set to protect medical information. The details are given as follows:(1)
Hi chooses a random number li∈ℤp∗ , computes Ui=gli, and sends IDi,Ui to Dk.(2)
Dk randomly selects a number lk∈ℤp∗ , computes Vk=glk, and sends IDk,Vk to Hi.(3)
Hi computes si=Vkli, MACi=MACsiIDk,Vk,Ui, and sends MACi to Dk.(4)
Dk computes sk=Uilk and MACk=MACskIDk,Vk,Ui. If MACi=MACk, Dk computes MACk†=MACskIDi,Ui,Vk,sk and sends MACk† to Hi. Otherwise, ⊥.(5)
Hi computes MACi†=MACsiIDi,Ui,Vk,si and checks MACi†=MACk†. If not, ⊥. Otherwise, Hi computes K=V1li…Vnli and M=EsiK, and then sends M to Dk.(6)
Dk decrypts M using sk to get the group key K.Figure 3
The group key generation.The correctness of the above protocol is based on the following equation(1)si=Vkli=glilk=Uilk=sk.


### 4.4. Diagnosis

(1)
Pj shows α and PIDj to D1 as the evidence, so that D1 makes a diagnosis or accesses the history records of Pj. If it is legal, D1 first generates a diagnosis m1, randomly selects r1∈ℤp∗, computes R1=gr1, X1=R1d12+d13, W1=H0m1,T, Q1=W1d11X1 and c1=EKm1. Then D1 sends the signature message c1,PIDj,R1,Q1 to D2. Meanwhile, D1 broadcasts signature PK1,PIDj,R1,Q1 in the blockchain; please see Figure 4 for the structure of block. In BC-EMR, each block is used to store one patient’s information such as all doctors’ signatures.(2)
Pj shows α to Dkk=2,…,n. If it is legal, Dk confirms whether he/she received ck−1,PIDj,Rk−1,Qk−1 before Tk=kT. If not, Dk requests Dk−1 to resend the message. Then, Dk decrypts ck−1 to get m1,…,mk−1 and verifies the following:(2)eQk−1,g=∏i=1k−1eWi,Aie∏i=1k−1BiCii,Rk−1.If it is true,Dk first randomly selects rk∈ℤp∗, generates diagnosis mk, computes Rk=Rk−1grk, Xk=Rkdk2+kdk3, Zk=∏i=1k−1BiCiirk, Wk=H0m1m2…mk,T, and Qk=Wkdk1Qk−1XkZk. Then Dk encrypts the results m1‖m2…‖mk as ck=EKm1m2…mk and sends the signature ck,PIDj,Rk,Qk to Dk+1. Meanwhile, Dk boardcasts signature PKk,PIDj,Rk,Qk in the blockchain. Thus, the final diagnosis is m=m1m2…mn and the signature message is cn,PIDj,Rn,Qn.(3)
Dn encrypts the results m using Pj ’s public key PKj to generate the ciphertext Cj. We will give the details as follows:(a)
Dn selects a general signature key pair PK,SK and sets PK=A(b)
Dn randomly selects a number r∈ℤp∗ and computes B=PKjr, C=eg,H1Ar⊕m, D=H2Ar, E=g¯r, F=ePKj,H0αr, and G=H3F(c)
Dn signs the message C,D,E,G using SK and outputs the ciphertext Cj=S,A,B,C,D,E,G, where S is the signature(d)
Dn sends ciphertext Cj and PIDj to the cloud serverFigure 4
The structure of block in the hospital’s blockchain.


### 4.5. Data Storage

In BC-EMR, every doctor is the general node of the blockchain. The cloud server andHOi ’s server are the supernodes, and they are responsible for verifying the signature message. That is, if the signature message passes their verification, all nodes will put the current signatures about the patient Pj in a block and update their stored records. The verification scheme is that the supernodes check the following equation:(3)eQn,g=∏i=1neWi,Aie∏i=1nBiCii,Rn.If it is true, the supernodes send a confirmation message in the blockchain so that all nodes accept the signatures aboutPj, put them in a block, and update the stored records. Otherwise, ⊥.


### 4.6. Data Sharing

When the doctorDk in the hospital Hd makes a diagnosis for the patient Pj, Pj ’s medical history in other hospitals Hi may help Dk. Therefore, if Dk wants, he/she can obtain these records with the consent of Pj. The details are as follows:(1)
Dk and Pj send their identities and request to SM. If it is passed, SM sends a notice to Hi, and the server of Hi extracts the ciphertext Cj=S,A,B,C,D,E,G from the cloud server and sends it to SM. In addition, Pj sends a trapdoor Tα=H0αpj to Dk.(2)
Dk and Pj send the private keys dk1 and pj to SM, respectively. Then, SM outputs the reencryption key rkj↔k=dk1/pj.(3)
SM checks the signature S on C,D,E,G, i.e., eB,H2A=ePKj,D, and eB,g¯=ePKj,E. If any of them fails, ⊥. Otherwise, SM computes B′=Brkj↔k=PKjrkj↔k×r=gpjrdk1/pj=gdk1r=Akr and sends the ciphertext S,A,B′,C,D,E,G to Dk.(4)
Dk checks the signature S, i.e., eB′,H2A=eAk,D, eB′,g¯=eAk,E, and G=H3eB′,Tα1/dk1. If any of them fails, ⊥. Otherwise, Dk recovers the message m=C⊕eB′,H1A1/dk1.


## 4.1. System Model

In this section, the details of BC-EMR will be given. We use the sequential multisignature of [41] and the proxy reencryption of [42] to construct the scheme. As shown in Figure 2, BC-EMR mainly consists of four entities, i.e., a doctor team, a patient, a hospital, and a cloud server. In BC-EMR, a patient first registers at the hospital. If the identity is approved, the hospital server assigns a medical team to the patient based on the initial condition. Then, the server and members of the team establish a group key that is used to protect the patient’s diagnosis results. In the diagnosis, when a doctor receives a message from the former doctor, he/she first verifies previous all doctors’ signatures. If it passes, the doctor will make the diagnosis and broadcast his/her signature in the blockchain. Otherwise, he/she requests the former doctor to resend the message. When the last doctor has finished the signature, he/she encrypts the result by using the patient’s public key and sends the ciphertext to the cloud server. The ciphertext and signatures will be stored in the cloud and blockchain, respectively, if the signatures pass the verification. Different doctors at different hospitals have the right to access the patient’s medical history with the patient’s consent. BC-EMR includes the following five phases, i.e., Initialization, Group key generation, Diagnose, Data storage, and Data sharing. In Table 2, we give the used notations in the paper.Figure 2
The basic structure of BC-EMR.Table 2
Notations.
Notationp,qTwo prime numbersSMThe system managerHiTheith hospitalPjThejth patientDkThekth doctorPK.The public keySK.The private keyID.The identitysThe diagnosis ordergThe generator ofG1KGCThe key generation centerE.EncryptionD.DecryptioneThe bilinear mapH.The hash functionMACThe message authentication codeγThe security parameter


## 4.2. Initialization

(1)
SM inputs a security parameter 1γ, selects the bilinear map e:G1×G1⟶G2 and a random number g¯∈G1 , where G1 and G2 are two multiplicative groups with the same prime order p. g is a generator of G1. Four hash functions are defined as follows: H0:0,1∗⟶G1, H1:0,1≤l⟶G1, H2:0,1≤l⟶G1, and H3:G2⟶0,1γ,  where l is the length of the verification keys [42]. Besides, SM selects a random number x∈ℤp∗ as the system master key, and the public key Y=gx. The public parameters of BC-EMR are p,g,Y,g¯,H0,H1,H2,H3,e,G1,G2. In BC-EMR, we limit the number of the signer reissues the signature to no more than N.(2)
HospitalHi selects a random number hi∈ℤp∗ as its private key and the public key PKi=ghi.(3)
PatientPj selects a random number pj∈ℤp∗ as the private key and sets PKj=gpj as the public key.(4)
DoctorDk randomly selects dk1,dk2,dk3∈ℤp∗, computes Ak=gdk1, Bk=gdk2, and Ck=gdk3. The private key is dk1,dk2,dk3 and the public key PKk=Ak,Bk,Ck.


## 4.3. Group Key Generation

When a patientPj sees a doctor in the hospital Hi, Pj sends an identity IDj and symptoms to HOi ’s server securely. If the identity is legal, the server first selects a random number λj∈ℤp∗, computes Pj ’s pseudoidentity PIDj=EhiIDj⊕λj‖λj and sends it to Pj. It also assigns initial doctors Dkk=1,…,n to make a diagnosis according Pj ’s condition, sends the evidence α∈0,1∗ and a diagnosis order s to Pj, and sends a signature timestamp T, α, and s to Dkk=1,…,n securely. Especially, as in Figure 3, a group key between Hi and Dkk=1,…,n will be set to protect medical information. The details are given as follows:(1)
Hi chooses a random number li∈ℤp∗ , computes Ui=gli, and sends IDi,Ui to Dk.(2)
Dk randomly selects a number lk∈ℤp∗ , computes Vk=glk, and sends IDk,Vk to Hi.(3)
Hi computes si=Vkli, MACi=MACsiIDk,Vk,Ui, and sends MACi to Dk.(4)
Dk computes sk=Uilk and MACk=MACskIDk,Vk,Ui. If MACi=MACk, Dk computes MACk†=MACskIDi,Ui,Vk,sk and sends MACk† to Hi. Otherwise, ⊥.(5)
Hi computes MACi†=MACsiIDi,Ui,Vk,si and checks MACi†=MACk†. If not, ⊥. Otherwise, Hi computes K=V1li…Vnli and M=EsiK, and then sends M to Dk.(6)
Dk decrypts M using sk to get the group key K.Figure 3
The group key generation.The correctness of the above protocol is based on the following equation(1)si=Vkli=glilk=Uilk=sk.


## 4.4. Diagnosis

(1)
Pj shows α and PIDj to D1 as the evidence, so that D1 makes a diagnosis or accesses the history records of Pj. If it is legal, D1 first generates a diagnosis m1, randomly selects r1∈ℤp∗, computes R1=gr1, X1=R1d12+d13, W1=H0m1,T, Q1=W1d11X1 and c1=EKm1. Then D1 sends the signature message c1,PIDj,R1,Q1 to D2. Meanwhile, D1 broadcasts signature PK1,PIDj,R1,Q1 in the blockchain; please see Figure 4 for the structure of block. In BC-EMR, each block is used to store one patient’s information such as all doctors’ signatures.(2)
Pj shows α to Dkk=2,…,n. If it is legal, Dk confirms whether he/she received ck−1,PIDj,Rk−1,Qk−1 before Tk=kT. If not, Dk requests Dk−1 to resend the message. Then, Dk decrypts ck−1 to get m1,…,mk−1 and verifies the following:(2)eQk−1,g=∏i=1k−1eWi,Aie∏i=1k−1BiCii,Rk−1.If it is true,Dk first randomly selects rk∈ℤp∗, generates diagnosis mk, computes Rk=Rk−1grk, Xk=Rkdk2+kdk3, Zk=∏i=1k−1BiCiirk, Wk=H0m1m2…mk,T, and Qk=Wkdk1Qk−1XkZk. Then Dk encrypts the results m1‖m2…‖mk as ck=EKm1m2…mk and sends the signature ck,PIDj,Rk,Qk to Dk+1. Meanwhile, Dk boardcasts signature PKk,PIDj,Rk,Qk in the blockchain. Thus, the final diagnosis is m=m1m2…mn and the signature message is cn,PIDj,Rn,Qn.(3)
Dn encrypts the results m using Pj ’s public key PKj to generate the ciphertext Cj. We will give the details as follows:(a)
Dn selects a general signature key pair PK,SK and sets PK=A(b)
Dn randomly selects a number r∈ℤp∗ and computes B=PKjr, C=eg,H1Ar⊕m, D=H2Ar, E=g¯r, F=ePKj,H0αr, and G=H3F(c)
Dn signs the message C,D,E,G using SK and outputs the ciphertext Cj=S,A,B,C,D,E,G, where S is the signature(d)
Dn sends ciphertext Cj and PIDj to the cloud serverFigure 4
The structure of block in the hospital’s blockchain.


## 4.5. Data Storage

In BC-EMR, every doctor is the general node of the blockchain. The cloud server andHOi ’s server are the supernodes, and they are responsible for verifying the signature message. That is, if the signature message passes their verification, all nodes will put the current signatures about the patient Pj in a block and update their stored records. The verification scheme is that the supernodes check the following equation:(3)eQn,g=∏i=1neWi,Aie∏i=1nBiCii,Rn.If it is true, the supernodes send a confirmation message in the blockchain so that all nodes accept the signatures aboutPj, put them in a block, and update the stored records. Otherwise, ⊥.


## 4.6. Data Sharing

When the doctorDk in the hospital Hd makes a diagnosis for the patient Pj, Pj ’s medical history in other hospitals Hi may help Dk. Therefore, if Dk wants, he/she can obtain these records with the consent of Pj. The details are as follows:(1)
Dk and Pj send their identities and request to SM. If it is passed, SM sends a notice to Hi, and the server of Hi extracts the ciphertext Cj=S,A,B,C,D,E,G from the cloud server and sends it to SM. In addition, Pj sends a trapdoor Tα=H0αpj to Dk.(2)
Dk and Pj send the private keys dk1 and pj to SM, respectively. Then, SM outputs the reencryption key rkj↔k=dk1/pj.(3)
SM checks the signature S on C,D,E,G, i.e., eB,H2A=ePKj,D, and eB,g¯=ePKj,E. If any of them fails, ⊥. Otherwise, SM computes B′=Brkj↔k=PKjrkj↔k×r=gpjrdk1/pj=gdk1r=Akr and sends the ciphertext S,A,B′,C,D,E,G to Dk.(4)
Dk checks the signature S, i.e., eB′,H2A=eAk,D, eB′,g¯=eAk,E, and G=H3eB′,Tα1/dk1. If any of them fails, ⊥. Otherwise, Dk recovers the message m=C⊕eB′,H1A1/dk1.


## 5. Solutions to the Basic Requirements

BC-EMR has provided for the advantages described in Subsection3.1 since it uses blockchain. Especially, the scheme is based on the sequential multisignature of [41] and the proxy reencryption of [42]. They are proven secure in the random oracle model, which is based on the hardness of the CDH problem and the modified DBDH problem, respectively, and please see [41, 42] for the full formal proof.In this subsection, we will show why BC-EMR satisfies the basic requirements of BMR. In Table3, we list the comparison results about BC-EMR and the other three blockchain-based EMR schemes ZL, CZ, and AS. Here, the schemes in [26, 28, 37] are denoted as ZL, CZ, and AS, respectively.Table 3
Comparison of the basic requirements.
SPDSPCUSM1M2M3M4M5M6NRCOAUZL√√√×√√√√√√√√CZ√√√×√√√√√××√AS√√√×√√√√√√√√BC-EMR√√√√√√√√√√√√√Support; ×not-support.


### 5.1. Security and Privacy Preservation (SP)

(a)
Malicious attacks (MA)Forgeryattack (M1): to get the doctor’s private key to generate a legal signature, the adversary must solve DLP intractable problem. Especially, it is not feasible to falsify the diagnosis by the cloud server or the collaboration between the patient and the cloud server. The reason is that they also can not get the doctors’ legal signatures from the hospital’s server or SM can detect any forged information by verifying the signatures stored in the blockchain. So, BC-EMR can resist the forgery attack.Modificationattack (M2): in BC-EMR, the last doctor encrypts the diagnosis results with the patient’s public key and outsources them to the cloud. If an adversary wants to modify them, it first needs to obtain the patient’s private key and the cloud’s permission. To get the private key illegally, the adversary must solve DLP intractable problem. Therefore, it is not possible. More importantly, BC-EMR stores the doctors’ signatures of their diagnoses in the blockchain. Then, it is easy to detect the modification to the diagnosis results, even if the patient’s private key is leaked or the patient (or doctor) cooperates with the cloud. Thus, BC-EMR can resist the modification attack.Replayattack (M3): BC-EMR has introduced the timestamp T. Dk will confirm whether he/she received the message before Tk=kT. It is impossible to change timestamp T since the signatures stored in the blockchain contain it. Any modification to T is easily detected, and thus BC-EMR can resist the replay attack.Guessattack (M4): in BC-EMR, the system sets the number of resigning as N. If the number of resigning exceeds N, the signature terminates. It can be to limit the number of attacks effectively and resist the guessing attack.Man−in−the−middleattack (M5): protection against the man-in-the-middle attack follows from the protection against the forgery attack, modification attack, and replay attack.Trackableattack (M6): the patient and hospital generate different random numbers including li, lk, and ri in each execution of BC-EMR. Thus, there is no constant value in the transmitted or stored messages, and the adversary can not trace the action. Therefore, our BC-EMR can resist the trackable attack.(b)
Nonrepudiation (NR): blockchain technology makes BC-EMR satisfy traceability. We can search the origin of any record stored in the blockchain by the chain structure and the doctor’s signature. Thus, no participant can deny the data generated by himself/herself.(c)
Confidentiality (CO): before diagnosis, the hospital server will set a pseudoidentity for each patient. During the diagnosis, the patient will use the pseudoidentity to interact with doctors. The doctors will encrypt the diagnosis results with the group key, and only members of the medical team can get them. When the diagnosis is over, the last doctor will encrypt the result with the patient’s public key before storing it in a cloud server. If the adversary wants to get the patient’s private key to decrypt the ciphertext, he/she needs to solve the DLP intractable problem. So BC-EMR has ideal confidentiality.(d)
Authenticity (AU): no one but the patient can decrypt the ciphertext of diagnosis since the final doctor encrypts diagnosis results with the patient’s public key. Doctors have stored the signatures of diagnoses in the blockchain, and these violations are easy to spot.


### 5.2. Data Sharing (DS)

The scheme has utilized proxy reencryption technology. If the doctor has obtained the consent of the patient, he/she will get the ciphertext encrypted by their public key. Then the doctor accesses the patient’s historical medical records by decrypting the ciphertext. That is, BC-EMR realizes data sharing between different doctors at different hospitals.


### 5.3. Patient Control (PC)

When a doctor needs to know the patient’s historical records of another hospital, the doctor must get the ciphertext that is encrypted by his/her public key. However, the original ciphertext is encrypted by the patient’s public key. The transformation of ciphertext needs to be completed bySM using the reencryption key that is computed by SM utilizing the patient’s private key. So, the patient can control the doctor to access the historical data.


### 5.4. Uniform Standard (US)

In hospitals’ BC-EMR systems, we can use a uniform standard such as the same encryption algorithm. It is beneficial to implement data sharing and other functions.In Table3, we give the comparison results of BC-EMR, ZL, CZ, and AS according to the basic requirements. We can know that ZL and AS can not resist the guess attack. CZ not only can not resist the guess attack but also can not satisfy patient control and make the essential data sharing.Remarks. Without the blockchain, if a doctor tries to forge EMR that has been outsourced to a cloud server in a medical accident, he/she can incentivize the cloud server to forge or modify the existing EMR at will. This is consistent with reality. The introduction of blockchain makes the scheme resistant to threats such as doctor-cloud collusion to forge or modify EMR without additional security mechanisms, strong hypotheses, and trusted entities. In other words, blockchain plays a key role in ensuring security in BC-EMR. Moreover, in BC-EMR, blockchain only stores some lightweight information such as the doctors’ signatures, and diagnostic results are stored in the cloud, thus reducing the burden of blockchain and facilitating the future implementation of the scheme.


## 5.1. Security and Privacy Preservation (SP)

(a)
Malicious attacks (MA)Forgeryattack (M1): to get the doctor’s private key to generate a legal signature, the adversary must solve DLP intractable problem. Especially, it is not feasible to falsify the diagnosis by the cloud server or the collaboration between the patient and the cloud server. The reason is that they also can not get the doctors’ legal signatures from the hospital’s server or SM can detect any forged information by verifying the signatures stored in the blockchain. So, BC-EMR can resist the forgery attack.Modificationattack (M2): in BC-EMR, the last doctor encrypts the diagnosis results with the patient’s public key and outsources them to the cloud. If an adversary wants to modify them, it first needs to obtain the patient’s private key and the cloud’s permission. To get the private key illegally, the adversary must solve DLP intractable problem. Therefore, it is not possible. More importantly, BC-EMR stores the doctors’ signatures of their diagnoses in the blockchain. Then, it is easy to detect the modification to the diagnosis results, even if the patient’s private key is leaked or the patient (or doctor) cooperates with the cloud. Thus, BC-EMR can resist the modification attack.Replayattack (M3): BC-EMR has introduced the timestamp T. Dk will confirm whether he/she received the message before Tk=kT. It is impossible to change timestamp T since the signatures stored in the blockchain contain it. Any modification to T is easily detected, and thus BC-EMR can resist the replay attack.Guessattack (M4): in BC-EMR, the system sets the number of resigning as N. If the number of resigning exceeds N, the signature terminates. It can be to limit the number of attacks effectively and resist the guessing attack.Man−in−the−middleattack (M5): protection against the man-in-the-middle attack follows from the protection against the forgery attack, modification attack, and replay attack.Trackableattack (M6): the patient and hospital generate different random numbers including li, lk, and ri in each execution of BC-EMR. Thus, there is no constant value in the transmitted or stored messages, and the adversary can not trace the action. Therefore, our BC-EMR can resist the trackable attack.(b)
Nonrepudiation (NR): blockchain technology makes BC-EMR satisfy traceability. We can search the origin of any record stored in the blockchain by the chain structure and the doctor’s signature. Thus, no participant can deny the data generated by himself/herself.(c)
Confidentiality (CO): before diagnosis, the hospital server will set a pseudoidentity for each patient. During the diagnosis, the patient will use the pseudoidentity to interact with doctors. The doctors will encrypt the diagnosis results with the group key, and only members of the medical team can get them. When the diagnosis is over, the last doctor will encrypt the result with the patient’s public key before storing it in a cloud server. If the adversary wants to get the patient’s private key to decrypt the ciphertext, he/she needs to solve the DLP intractable problem. So BC-EMR has ideal confidentiality.(d)
Authenticity (AU): no one but the patient can decrypt the ciphertext of diagnosis since the final doctor encrypts diagnosis results with the patient’s public key. Doctors have stored the signatures of diagnoses in the blockchain, and these violations are easy to spot.


## 5.2. Data Sharing (DS)

The scheme has utilized proxy reencryption technology. If the doctor has obtained the consent of the patient, he/she will get the ciphertext encrypted by their public key. Then the doctor accesses the patient’s historical medical records by decrypting the ciphertext. That is, BC-EMR realizes data sharing between different doctors at different hospitals.


## 5.3. Patient Control (PC)

When a doctor needs to know the patient’s historical records of another hospital, the doctor must get the ciphertext that is encrypted by his/her public key. However, the original ciphertext is encrypted by the patient’s public key. The transformation of ciphertext needs to be completed bySM using the reencryption key that is computed by SM utilizing the patient’s private key. So, the patient can control the doctor to access the historical data.


## 5.4. Uniform Standard (US)

In hospitals’ BC-EMR systems, we can use a uniform standard such as the same encryption algorithm. It is beneficial to implement data sharing and other functions.In Table3, we give the comparison results of BC-EMR, ZL, CZ, and AS according to the basic requirements. We can know that ZL and AS can not resist the guess attack. CZ not only can not resist the guess attack but also can not satisfy patient control and make the essential data sharing.Remarks. Without the blockchain, if a doctor tries to forge EMR that has been outsourced to a cloud server in a medical accident, he/she can incentivize the cloud server to forge or modify the existing EMR at will. This is consistent with reality. The introduction of blockchain makes the scheme resistant to threats such as doctor-cloud collusion to forge or modify EMR without additional security mechanisms, strong hypotheses, and trusted entities. In other words, blockchain plays a key role in ensuring security in BC-EMR. Moreover, in BC-EMR, blockchain only stores some lightweight information such as the doctors’ signatures, and diagnostic results are stored in the cloud, thus reducing the burden of blockchain and facilitating the future implementation of the scheme.


## 6. Performance Evaluation

In this section, we will evaluate BC-EMR from the following two aspects: (1) computational and communication cost; (2) the implementation of BC-EMR.


### 6.1. Computational and Communication Cost

In this subsection, we will compare the main computational cost and communication cost of BC-EMR, ZL, CZ, and AS.SM usually has sufficient computational power and storage capacity, so we consider the burden on the patient and the last doctor of the team (the last doctor is responsible for outsourcing data, he/she needs to pay for more cost than other doctors). The comparison results of computational cost are shown in Table 4. Here, m denotes the scale multiplication operator in G1, e denotes the exponentiation operation in G1, b denotes the bilinear pairing operation. We ignore the remaining operations because of their low computational cost.Table 4
Comparison of the computational cost.
SchemePatientDoctorZL7m17+λm+7e+4bCZ5e+nm2bAS5m9mBC-EMR2e11+ne+n+9bIn Table4, λ is the size of the disease keyword set [26]. On the doctor’s side, ZL has the highest computational cost of 17+λm+7e+4b since λ is usually large such as 1000 in ZL. The cost of CZ is lower than BC-EMR, but it can not satisfy a critical feature of EMR, i.e., the data sharing between doctors. CZ also omits the authentication between the server and doctors in generating the treatment key, and the current doctor only verifies the previous doctor’s signature. But BC-EMR will make the authentication in creating the group key, and the current doctor verifies previous all doctors’ signatures. The cost of AS is also lower than BC-EMR on the doctor’s side, but the scheme needs to decrypt the ciphertext using the patient’s private key and then encrypt the EMR using the shared secret key in the process of data sharing. Every time generation and management of the shared secret key both are consuming cost and there is a risk of data leakage. So BC-EMR has higher security, and the additional computational cost is worthy. In addition, the results in [43] show that the computational cost of the operation e is approximately two times that of the operation m. So, on the side of the patient, we can find that BC-EMR has the lowest computational cost of 2e. It is worthy to note that doctors often have relatively reliable computational power, and it is vital to reduce the computational burden on patients.In Table5, we will give the main communication cost of the three schemes. x and t denote the size of the element in the ciphertext space and the size of the timestamp, respectively. np is the number of the private blockchain’s verifiers in ZL, and Dp is the size of personal data in AS. We use the supersingular curve EFq with order p over the finite field GFq. To give a more explicit comparison of communication cost, we assume the prime number p is 160 bits, the prime number q is 1024 bits, the point in G1 is 1024 bits, the point in G2 is 512 bits, the point in the ciphertext space, the hash value, and α all are 160 bits, the timestamp, the order message s, and the identity all are 32 bits, the security parameter γ is 512 bits, np=3 in ZL, l is 512 bits, and Dp is 1024 bits. In Figure 5, we give the comparison diagram of communication cost versus λ (without loss of generality, we assume n=3). Besides, we provide a comparison diagram of communication cost versus the number of doctors n in Figure 6. In ZL, λ=1000, but we set λ=200 for clearly showing the comparison results in Figure 6.Table 5
Comparison of the communication cost.
SchemeCommunication costZLλ+12G1+G2+5ℤp∗+13⌊2/3np⌋+t+x+ID+2HashCZ3n+1G1+nℤp∗+2n+1ID+nHash+2x+n+1tAS3G1+ID+4x+Hash+ℤp∗+t+DpBC-EMR3n+8G1+2G2+2ℤp∗+5ID+n+6x+2Hash+n+2α+nt+2γ+2l+n+1sFigure 5
Communication cost comparison versusλ.Figure 6
Communication cost comparison versusn.We can see from Figure5 that the communication cost of ZL linearly increases with λ. The communication cost of CZ, AS, and BC-EMR is constant versus λ. Since λ is usually relatively large such as 1000 in ZL. So, ZL has the highest communication cost. In Figure 6, the communication cost of CZ and BC-EMR both linearly increase with n, and the communication cost of BC-EMR is higher than CZ’s. AS has the lowest communication cost, and an important reason is that the scheme does not consider the case that multiple doctors generate the EMR for a patient. In addition, as mentioned in the analysis of computational cost, CZ can not satisfy some features such as data sharing. AS requires decrypting the ciphertext using the patient’s private key and then encrypting the EMR using the shared key to make data sharing. Every time the shared key is generated and managed, there is cost, and it will also increase the risk of EMR data leakage. Thus, the above results show that BC-EMR can achieve a better balance among security, basic requirements, computational cost, and communication cost. So it is an ideal EMR scheme.


### 6.2. Implementation of BC-EMR

In this subsection, we will give some implementation results of BC-EMR. The experiment usedPython 3.7.4 as the programming language. Specially, we used the C language library PBC (v0.5.14) for bilinear pairing calculations, pypbc to call the PBC library in Python, and Python’s encryption algorithm library pycryptodome (v3.9.0) to implement AES encryption. We used a computer equipped with an Intel Core i7-9750H CPU @ 2.60 GHz and 15.6 GB of memory to run our experimental program. The operating system is Manjaro Linux 64 bit, the desktop environment is KDE (v5.61.0), and the kernel version is 4.19.69-1-MANJARO. During the experiment, we started multiple processes on the experimental computer. Each procedure was bound to a separate port and communicated with each other using sockets. In this way, we simulated the behavior of different roles in each phase of the scenario. All values are the average result of 100 times experiments.We consider three security levels for BC-EMR, i.e., level 1 (p=160 bits, q=1024 bits), level 2 (p=224 bits, q=2048 bits), and level 3 (p=256 bits, q=3072 bits). In Table 6, we assume n=3 and summarize the phased computational costs for three security levels. The corresponding histogram is given in Figure 7. The result shows that the computational costs of the five stages increase as the security level increases. Besides, in Figure 8, we consider the computational delay versus n. We can find that the computational delays of the initialization phase and data sharing phase have no significant change. With the increase in the number of doctors, the other three stages’ computational delays all significantly increase. The computational delay of the diagnostic phase is the fastest growing. The reason is that as the number of doctors increases, BC-EMR needs to perform more time-consuming exponential operations and bilinear pairing operations.Table 6
Phased time costs whenn = 3 (ms).
PhasesSecurity levelsLevel 1Level 2Level 3Initialization62.78280.17704.80Group key generation83.30405.80905.90Diagnose296.601366.902220.30Data storage30.10167.14307.40Data sharing193.30971.502125.50Figure 7
Phased time costs whenn = 3.Figure 8
Computational delay for three security levels. (a) Level 1. (b) Level 2. (c) Level 3.
(a)(b)(c)


## 6.1. Computational and Communication Cost

In this subsection, we will compare the main computational cost and communication cost of BC-EMR, ZL, CZ, and AS.SM usually has sufficient computational power and storage capacity, so we consider the burden on the patient and the last doctor of the team (the last doctor is responsible for outsourcing data, he/she needs to pay for more cost than other doctors). The comparison results of computational cost are shown in Table 4. Here, m denotes the scale multiplication operator in G1, e denotes the exponentiation operation in G1, b denotes the bilinear pairing operation. We ignore the remaining operations because of their low computational cost.Table 4
Comparison of the computational cost.
SchemePatientDoctorZL7m17+λm+7e+4bCZ5e+nm2bAS5m9mBC-EMR2e11+ne+n+9bIn Table4, λ is the size of the disease keyword set [26]. On the doctor’s side, ZL has the highest computational cost of 17+λm+7e+4b since λ is usually large such as 1000 in ZL. The cost of CZ is lower than BC-EMR, but it can not satisfy a critical feature of EMR, i.e., the data sharing between doctors. CZ also omits the authentication between the server and doctors in generating the treatment key, and the current doctor only verifies the previous doctor’s signature. But BC-EMR will make the authentication in creating the group key, and the current doctor verifies previous all doctors’ signatures. The cost of AS is also lower than BC-EMR on the doctor’s side, but the scheme needs to decrypt the ciphertext using the patient’s private key and then encrypt the EMR using the shared secret key in the process of data sharing. Every time generation and management of the shared secret key both are consuming cost and there is a risk of data leakage. So BC-EMR has higher security, and the additional computational cost is worthy. In addition, the results in [43] show that the computational cost of the operation e is approximately two times that of the operation m. So, on the side of the patient, we can find that BC-EMR has the lowest computational cost of 2e. It is worthy to note that doctors often have relatively reliable computational power, and it is vital to reduce the computational burden on patients.In Table5, we will give the main communication cost of the three schemes. x and t denote the size of the element in the ciphertext space and the size of the timestamp, respectively. np is the number of the private blockchain’s verifiers in ZL, and Dp is the size of personal data in AS. We use the supersingular curve EFq with order p over the finite field GFq. To give a more explicit comparison of communication cost, we assume the prime number p is 160 bits, the prime number q is 1024 bits, the point in G1 is 1024 bits, the point in G2 is 512 bits, the point in the ciphertext space, the hash value, and α all are 160 bits, the timestamp, the order message s, and the identity all are 32 bits, the security parameter γ is 512 bits, np=3 in ZL, l is 512 bits, and Dp is 1024 bits. In Figure 5, we give the comparison diagram of communication cost versus λ (without loss of generality, we assume n=3). Besides, we provide a comparison diagram of communication cost versus the number of doctors n in Figure 6. In ZL, λ=1000, but we set λ=200 for clearly showing the comparison results in Figure 6.Table 5
Comparison of the communication cost.
SchemeCommunication costZLλ+12G1+G2+5ℤp∗+13⌊2/3np⌋+t+x+ID+2HashCZ3n+1G1+nℤp∗+2n+1ID+nHash+2x+n+1tAS3G1+ID+4x+Hash+ℤp∗+t+DpBC-EMR3n+8G1+2G2+2ℤp∗+5ID+n+6x+2Hash+n+2α+nt+2γ+2l+n+1sFigure 5
Communication cost comparison versusλ.Figure 6
Communication cost comparison versusn.We can see from Figure5 that the communication cost of ZL linearly increases with λ. The communication cost of CZ, AS, and BC-EMR is constant versus λ. Since λ is usually relatively large such as 1000 in ZL. So, ZL has the highest communication cost. In Figure 6, the communication cost of CZ and BC-EMR both linearly increase with n, and the communication cost of BC-EMR is higher than CZ’s. AS has the lowest communication cost, and an important reason is that the scheme does not consider the case that multiple doctors generate the EMR for a patient. In addition, as mentioned in the analysis of computational cost, CZ can not satisfy some features such as data sharing. AS requires decrypting the ciphertext using the patient’s private key and then encrypting the EMR using the shared key to make data sharing. Every time the shared key is generated and managed, there is cost, and it will also increase the risk of EMR data leakage. Thus, the above results show that BC-EMR can achieve a better balance among security, basic requirements, computational cost, and communication cost. So it is an ideal EMR scheme.


## 6.2. Implementation of BC-EMR

In this subsection, we will give some implementation results of BC-EMR. The experiment usedPython 3.7.4 as the programming language. Specially, we used the C language library PBC (v0.5.14) for bilinear pairing calculations, pypbc to call the PBC library in Python, and Python’s encryption algorithm library pycryptodome (v3.9.0) to implement AES encryption. We used a computer equipped with an Intel Core i7-9750H CPU @ 2.60 GHz and 15.6 GB of memory to run our experimental program. The operating system is Manjaro Linux 64 bit, the desktop environment is KDE (v5.61.0), and the kernel version is 4.19.69-1-MANJARO. During the experiment, we started multiple processes on the experimental computer. Each procedure was bound to a separate port and communicated with each other using sockets. In this way, we simulated the behavior of different roles in each phase of the scenario. All values are the average result of 100 times experiments.We consider three security levels for BC-EMR, i.e., level 1 (p=160 bits, q=1024 bits), level 2 (p=224 bits, q=2048 bits), and level 3 (p=256 bits, q=3072 bits). In Table 6, we assume n=3 and summarize the phased computational costs for three security levels. The corresponding histogram is given in Figure 7. The result shows that the computational costs of the five stages increase as the security level increases. Besides, in Figure 8, we consider the computational delay versus n. We can find that the computational delays of the initialization phase and data sharing phase have no significant change. With the increase in the number of doctors, the other three stages’ computational delays all significantly increase. The computational delay of the diagnostic phase is the fastest growing. The reason is that as the number of doctors increases, BC-EMR needs to perform more time-consuming exponential operations and bilinear pairing operations.Table 6
Phased time costs whenn = 3 (ms).
PhasesSecurity levelsLevel 1Level 2Level 3Initialization62.78280.17704.80Group key generation83.30405.80905.90Diagnose296.601366.902220.30Data storage30.10167.14307.40Data sharing193.30971.502125.50Figure 7
Phased time costs whenn = 3.Figure 8
Computational delay for three security levels. (a) Level 1. (b) Level 2. (c) Level 3.
(a)(b)(c)


## 7. Conclusion

In this paper, we proposed a blockchain-based EMR in the cloud environment. A lightweight one-to-many authentication protocol is given to set a group key, which is used to protect the patient’s diagnosis results before storing them in the cloud. The proxy reencryption is utilized to make secure data sharing between doctors at different hospitals. Blockchain and sequential multisignature technologies ensure that the stored medical information is safe. Especially, BC-EMR can resist threats such as doctor-cloud collusion to forge or modify EMR. The analysis shows that BC-EMR has a lower computational cost on the side of the patient. It is very important for EMR since the patients usually rely on resource-limited mobile devices. Besides, BC-EMR can satisfy more basic requirements and security features. So the extra computational cost on the side of the doctor and the extra communication cost compared with CZ both are worthy. That is, BC-EMR is a practical EMR. Of course, as the analysis results show, the method presented in this paper has some shortcomings, such as a slightly higher cost of communication. Since blockchain is a massive ledger backup measure, these deficiencies will directly reduce the system performance. So the balance between efficiency, security, and cost remains at the heart of what we do next.



---

*Source: 6737942-2022-02-01.xml*