A Blockchain-Based Secure Inter-Hospital EMR Sharing System

Abstract

In recent years, blockchain-related technologies and applications have gradually emerged. Blockchain technology is essentially a decentralized database maintained by the collective, and it is now widely applied in various fields. At the same time, with the growth of medical technology, medical information is becoming increasingly important in terms of patient identity background, medical payment records, and medical history. Medical information can be the most private information about a person, but due to issues such as operation errors within the network or a hacking attack by a malicious person, there have been major leaks of sensitive personal information in the past. In any case, this has become an issue worth studying to ensure the privacy of patients and protect these medical materials. On the other hand, under the current medical system, the patient’s EMR (electronic medical record) cannot be searched across the hospital. When the patient attends the hospital for treatment, repeated examinations will occur, resulting in a waste of medical resources. Therefore, we propose a blockchain-based secure inter-hospital EMR sharing system in this article. Through the programmatic authorization mechanism by smart contracts, the security of EMR is guaranteed. In addition to the essential mutual authentication, the proposed scheme also provides and guarantees data integrity, nonrepudiation, user untraceability, forward and backward secrecy, and resistance to replay attack.

1. Introduction

Background

With the rapid growth of information technology, our lives are more convenient now than in the past. Our surroundings are full of IT-related services and applications; one of them is medical diagnosis and treatment services. In order to implement the long-term development goals of medical diagnosis and treatment, the government focuses on livelihood issues such as protection of medical information, medical payment, medical data application, medical data storage sharing, medical information transactions, and predictive analysis [1,2,3,4,5]. In order to achieve these goals, some technologies, such as data protection, encryption, and cloud computation, are used [6,7,8,9,10].

At the same time, with the growth of medical technology, medical information is becoming increasingly important in terms of patient identity background, medical payment records, and medical history. In the past, medical records were transmitted through paper, and with the development of technology, these medical records were electronically stored in private servers in hospitals [11,12,13,14,15]. Medical information can be the most private information about a person, but due to issues such as operation errors within the network or a hacking attack by a malicious person, there have been major leaks of sensitive personal information in the past [16,17,18,19,20]. In any case, this has become an issue worth studying in order to ensure the privacy of patients and protect these medical materials.

On the other hand, under the current medical system, the patient’s medical record cannot be searched across the hospital. For example, when a patient is originally diagnosed and treated in hospital A, and then visits hospital B, hospital B must perform the same examination again, resulting in a waste of medical resources. Furthermore, when a patient seeks medical treatment, the physician does not know the medical history of the patient relating to other hospital visits in the past, and this also increases the medical risk and reduces the accuracy of the diagnosis [21,22,23,24,25]. Therefore, inter-hospital medical record access is a very important goal.

Besides this, blockchain-related technologies and applications have gradually emerged in recent years [26,27,28,29,30]. Blockchain technology is essentially a decentralized database maintained by the collective. It has the characteristics of high reliability and high confidentiality and has the strong prospect of effectively solving the trust problem between the two parties. Credit is the basis for the production and maintenance of social relations between people and organizations. At present, people mainly use regulations, systems, laws, contractual agreements, etc. to restrict credit problems. These methods cannot solve credit problems because of many subjective factors. The decentralization of the blockchain allows all users who join the blockchain to participate in the data authenticity proof, abandoning the shortcomings of the traditional certification system, the single certification center [31,32,33,34].

According to the WHO (World Health Organization) forum [35], the emergence of blockchain technology has provided solutions for medical resource management in recent days. Blockchain technology allows hospitals, patients, and other parties to share data within the blockchain, without worrying about the security and integrity of the data [36,37,38]. Through smart contracts, patients can authorize medical staff to access their medical information, so that medical staff can understand this information and provide better care services. Moreover, through blockchain technology, the patient’s EMR (electronic medical record) is directly obtained from the server of the original hospital, so the content of the EMR will not be limited to a specific format. Compared with the current EMR sharing mode [39,40], better integrity and timeliness can be achieved with this method.

Although some scholars have previously proposed secure medical systems, there is still a lack of security mechanisms for an inter-hospital medical system [41,42,43,44]. Therefore, we propose a blockchain-based secure inter-hospital EMR sharing system in this article. When the patient visits hospital A to seek medical services, hospital A will store medical records in the server of hospital A, and hospital A will also inform the patient about the results. When the patient goes to hospital B to seek further medical diagnosis or treatment, hospital B can obtain the previous medical records from hospital A without conducting the same examination again. This can prevent the waste of medical resources and achieve higher medical quality and efficiency. It achieves security, privacy, and efficiency in the proposed inter-hospital medical system [45,46].

The remainder of this article is arranged as follows. Section 2 shows the preliminary and security requirements of the proposed blockchain-based secure inter-hospital EMR sharing system. Section 3 shows the proposed blockchain-based secure inter-hospital EMR sharing system. Section 4 shows the security and efficiency analysis of the proposed scheme. Section 5 offers conclusions.

2. Preliminary and Security Requirements

2.1. Preliminary

2.1.1. BAN Logic Model

The Burrows–Abadi–Needham (BAN) logic proof model [47] is usually applied to prove the correctness of a protocol or scheme. The BAN logic proof model has been widely applied by many security-related articles to prove whether the proposed protocol or scheme achieves mutual authentication. The following descriptions are the BAN logic-related notations:

$P|\equiv X$:	$P$ trusts $X$, or $P$ is qualified to trust $X$.
$P⊲X$:	$P$ catches sight of $X$. $P$ can review and duplicate $X$, when somebody sends $P$ a message that contains $X$.
$P|~X$:	$P$ said $X$ before. $P$ sometimes sent a message that included $X$.
$P|\Rightarrow X$:	$P$ has jurisdiction over $X$. It should be trusted that $P$ is an authority on $X$.
$<X{>}_Y$:	This indicates that $X$ combined with $Y$.
$\#(X)$:	$X$ is the latest, which means $X$ has never been sent previously.
$P\stackrel{K}{\leftrightarrow }Q$:	The shared key $K$ is used for communication by $P$ and $Q$.
$P\stackrel{S}{\iff }Q$:	Only $P$, $Q$, and their trusted subjects know the secret $S$.

2.1.2. Elliptic Curve Group

Digital network systems are essential technologies in our daily life, with large amounts of documents and information being transmitted and exchanged over them. Thus, it is very important to guarantee the security of these transmitted and exchanged messages. To ensure the security of these important documents and messages, several digital encryption systems have therefore been proposed by researchers. The elliptic curve cryptography [48] was proposed in 1985, and the length of its message is shorter than that of the Rivest–Shamir–Adleman (RSA) encryption system. A brief introduction to the elliptic curve group technology and its corresponding difficultly mathematical problems as follows:

Allowing $F_q$ to be a prime finite field, $E/F_q$ is an elliptic curve defined over the prime finite field $F_q$, and $P$ is a generator for a cyclic additive group of the composite order $q$. The point on $E/F_q$ is together with an extra point $\Theta$, which is called the point at infinity, and it forms a group $G=\{(x,y):x,y\in F_q;(x,y)\in E/F_q\}\cup \{\Theta \}$. $G$ is a cyclic additive group of composite order $q$. Scalar multiplication over $E/F_q$ can be computed as $tP=P+P+\dots +P$, which is added t times.

The following problems exist for the elliptic curve Diffie–Hellman (ECDH) method:

Computational Diffie–Hellman (CDH) Problem: $aP$ and $bP$ are given first, and where $a,b\in R$. $Z_q{}^{*}$ and $P$ are the generators of $G$, the value $abP$ is computed.

Decisional Diffie–Hellman (DDH) Problem: $aP$, $bP$ and $cP$ are given first, and where $a,b,c\in R$. $Z_q{}^{*}$ and $P$ are the generators of $G$, then whether $cP=abP$ or not is confirmed, and this is equal to confirming whether $c=ab\mathrm{mod}q$ or not.

2.1.3. Smart Contract

The smart contract was proposed by Nick Szabo [49], a cross-disciplinary legal scholar, and it can be traced back to 1995. The following is the definition of a smart contract: a smart contract is a set of promises defined in digital form, including contract participants. The promised agreement can be executed on it. Blockchain technology can achieve collaboration and trust between multiple enterprise entities through smart contracts, thereby expanding the scope and depth of mutual cooperation between parties.

With the development of medical technology, medical data records a large amount of information about the patient’s identity background, medical history, and medical payment records. Blockchain technology can record and encrypt medical records, as in bookkeeping. The records are kept by patients themselves and can be used at any time when they visit different medical institutions, which fully guarantees privacy and security. Through the smart contract, patients can authorize medical staff to access their medical information, so that medical staff can examine this information and provide better care services.

2.2. Security Requirements

The following list shows the security requirements for a blockchain-based secure inter-hospital EMR sharing system [28,29,30,31,32,33,34].

2.2.1. Mutual Authentication

The information receiver must be capable of confirming the legal identity of the information’s sender during the message transmission process. Therefore, each party must be able to confirm the legal identity of the other party in an EMR sharing system environment. If any two parties can confirm one another’s legal identity, then the proposed system achieves mutual authentication.

2.2.2. Data Integrity

The system is vulnerable to malicious attacks in the form of modification for any message transmitted in an unencrypted network environment. This means that the information delivered to the receiver is not the original information transferred by the sender. Therefore, the integrity of the transferred message must be ensured, and the message must also be protected against tampering during the transmission.

2.2.3. User Untraceability

Malicious attackers may also try to trace a person’s mobile device, and they can then determine his/her physical location. Therefore, a blockchain-based secure inter-hospital EMR sharing system must prevent such positional tracking.

2.2.4. Resisting Replay Attacks

The transmitted information between the personal mobile device and the hospital medical device may also be intercepted by malicious attackers, and then malicious attackers can impersonate a legitimate transmitter and send the same information to the predetermined receiver. Such a condition represents a critical gap in personal data security and therefore must be prevented in a blockchain-based secure inter-hospital EMR sharing system.

2.2.5. Forward and Backward Secrecy

If a malicious attacker compromises the session key which is established between the personal mobile device and the hospital medical device, he/she may use the compromised session key for future malicious communications or to obtain previously transmitted messages. A blockchain-based secure inter-hospital EMR sharing system thus ought to achieve forward and backward secrecy.

2.2.6. Non-Repudiation

When the receiver receives the message sent by the sender, the sender may deny sending the message. Therefore, the message sent by the sender must be signed with the secret key of the sender. The receiver can verify the received message with the public key of the sender, and then the sender cannot deny sending the message. A blockchain-based secure inter-hospital EMR sharing system should thus achieve nonrepudiation.

3. The Proposed Scheme

3.1. System Architecture

The framework of the blockchain-based secure inter-hospital EMR sharing system is shown in Figure 1 [50,51].

There are four parties in the scheme:

(1)

Blockchain Center: The blockchain center belongs to the government medical institution. The blockchain center manages all personal mobile devices and hospital medical devices. All patients and hospitals must register in the blockchain center with their mobile devices and hospital medical devices, then the patient and the hospital can authenticate each other.

(2)

Patient: The patient carries a personal mobile device. The personal mobile device stores verification messages about the identity of the patient. After this, when the patient visits the hospital to seek medical services, the hospital and the patient can achieve mutual authentication through the personal mobile device. Thus, the personal mobile device can also hold the medical index of the hospital that was visited previously and will be provided to other hospitals in the future as an index for medical records.

(3)

Hospital A: The doctor uses a medical device in hospital A. When the patient visits hospital A with a symptom, hospital A and the patient will verify one another’s identity first. After this, hospital A will diagnose the patient. Hospital A will store medical records in the server of hospital A, and hospital A will also inform the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device.

(4)

Hospital B: The doctor uses a medical device in hospital B. When the patient goes to hospital B to extend treatment for a symptom that was previously diagnosed in hospital A, hospital B and the patient will also verify one another’s identity first. After this, hospital B will obtain the medical index of hospital A from the personal mobile device of the patient. Then, hospital B will request the patient’s medical records from hospital A. After diagnosis, hospital B will store medical records in the server of hospital B, and hospital B will also inform the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device.

Figure 1. The framework of the blockchain-based secure inter-hospital EMR sharing system.

Figure 1. The framework of the blockchain-based secure inter-hospital EMR sharing system.

• All personal mobile devices carried by patients and all medical devices used by hospital A and hospital B must be registered in the blockchain center through a secure channel. The patient, hospital A, and hospital B send their universally unique IDs to the blockchain center. The blockchain center returns information that includes parameters calculated by elliptic curve group technology.
• When the patient carries his/her mobile device to hospital A to seek medical services, hospital A and the patient must authenticate one another’s identity first. After mutual authentication between the patient and hospital A, the doctor of hospital A diagnoses the patient. After diagnosis, the doctor of hospital A stores the medical records of the patient in the server of hospital A, and the doctor of hospital A will also inform the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device.
• When the patient carries his/her mobile device and visits hospital B for extended treatment of a symptom that was previously diagnosed in hospital A, hospital B and the patient will also verify one another’s identity first. After mutual authentication between the patient and hospital B, the doctor of hospital B obtains the medical index of hospital A from the personal mobile device of the patient. Then, the doctor of hospital B requests the medical records of the patient from hospital A. After the doctor of hospital B obtains the encrypted medical records from hospital A and performs a diagnosis, the doctor of hospital B stores the medical records of the patient in the server of hospital B. The doctor of hospital B also informs the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device.

3.2. System Initialization Phase

In the system’s initialization stage, the blockchain center calculates some parameters and publishes the public parameters for patients with personal mobile devices and hospitals with medical devices.

Step 1:

The blockchain center chooses a $k$-bit prime, $p$, and determines the tuple of the elliptic curve group $(F_p,E/F_p,G,P)$.

Step 2:

The blockchain center then chooses $s$ as a secret key and computes

$$PK=sP,$$

(1)

as a public key.

Step 3:

Finally, the blockchain center chooses a hash function $(H_1(\cdot ),H_2(\cdot ),H_3(\cdot ))$ and then publishes $(F_p,E/F_p,G,P,PK,H_1(\cdot ),H_2(\cdot ),H_3(\cdot ))$ to all patients with personal mobile devices and hospitals with medical devices.

3.3. Smart Contract Initialization

In the proposed architecture, blockchain technology is applied. During the medical treatment process, some key information will be saved and verified through the blockchain. The key information in the blockchain is defined in the smart contract. The following is the blockchain smart contract structure for medical treatment information.

struct patient information smart contract ptinf{     string patient id;     string patient detail;     mapping medical record; } struct hospital A information smart contract hainf{     string hospital A id;     string hospital A detail; }

struct hospital B information smart contract hbinf{     string hospital B id;     string hospital B detail; } struct medical record smart contract mrinf{     string diagnosis id;     string diagnosis detail; }

In the proposed smart contract, we have developed key information that will be stored in the blockchain. In the structure of the patient information smart contract, we developed the field of patient ID (identification), patient detail, and mapping to the medical record. In the structure of the hospital A smart contract, we developed the fields of hospital A ID and hospital A detail. In the structure of the hospital B smart contract, we developed the fields of hospital B ID and hospital B detail. In the structure of the medical record smart contract, we developed the fields of diagnosis ID and diagnosis detail. In the initialization phase, the blockchain center also issues the public and private key pairs for all roles. Besides this, there will be a variable that records the current blockchain state in the blockchain smart contract architecture.

3.4. Patient Registration Phase

The patient mobile device carried by the patient must register with the blockchain center. At this stage, the patient registers with the blockchain center and obtains the public and private keys for message signatures and key messages for encryption. When the patient registers with the blockchain center, the blockchain center will add the registration information of the patient to the blockchain through a smart contract. The patient registration phase of the proposed scheme is demonstrated in Figure 2.

Step 1:

The patient chooses his/her universally unique identity, $I{D}_{PAT}$, and sends it to the blockchain center.

Step 2:

The blockchain center chooses a random number, $r_{PAT}$, and calculates

$$R_{PAT}=r_{PAT}P,$$

(2)

$$h_{PAT}=H_1(I{D}_{PAT},R_{PAT}),$$

(3)

$$S_{PAT}=r_{PAT}+h_{PAT}s,$$

(4)

If the identity $I{D}_{PAT}$ is valid, the blockchain center calls the smart contract ptins as follows:

function patient insert smart contract ptins( string patient id, string patient detail, mapping medical record) {     count ++;     patient id. count = id;

patient detail. count = detail;     mapping medical record = null; } string patient keypairs;

and it then sends $(R_{PAT},S_{PAT},P{K}_{PAT},S{K}_{PAT})$ to the patient.

Step 3:

The patient verifies

$$S_{PAT}P\stackrel{?}{=}{R}_{PAT}+H_1(I{D}_{PAT},R_{PAT})PK.$$

(5)

If the verification is passed, then the patient stores $(R_{PAT},S_{PAT},P{K}_{PAT},S{K}_{PAT})$ in his/her mobile device.

3.5. Hospital Registration Phase

The medical device used by hospital A or hospital B must register with the blockchain center. At this stage, hospital A or hospital B registers with the blockchain center and obtains the public and private keys for message signatures and key messages for encryption. When hospital A or hospital B registers with the blockchain center, the blockchain center will add the registration information of hospital A or hospital B to the blockchain through the smart contract. The hospital registration phase of the proposed scheme is shown in Figure 3 and Figure 4.

Figure 3. The hospital A registration phase of the proposed scheme.

Figure 3. The hospital A registration phase of the proposed scheme.

Step 1:

Hospital A chooses a unique identity, $I{D}_{HPA}$, and sends it to the blockchain center.

Step 2:

The blockchain center chooses a random number, $r_{HPA}$, and calculates

$$R_{HPA}=r_{HPA}P,$$

(6)

$$h_{HPA}=H_1(I{D}_{HPA},R_{HPA}),$$

(7)

$$S_{HPA}=r_{HPA}+h_{HPA}s,$$

(8)

If the identity $I{D}_{HPA}$ is valid, the blockchain center calls the smart contract hains as follows:

function hospital A insert smart contract hains( string hospital A id, string hospital A detail) {     count ++;     hospital A id. count = id;

hospital A detail. count = detail; } string hospital A keypairs;

and it then sends $(R_{HPA},S_{HPA},P{K}_{HPA},S{K}_{HPA})$ to hospital A.

Step 3:

Hospital A verifies

$$S_{HPA}P\stackrel{?}{=}{R}_{HPA}+H_1(I{D}_{HPA},R_{HPA})PK.$$

(9)

If the verification passes, then hospital A stores $(R_{HPA},S_{HPA},P{K}_{HPA},S{K}_{HPA})$ in the medical device.

Figure 4. The hospital B registration phase of the proposed scheme.

Figure 4. The hospital B registration phase of the proposed scheme.

Step 1:

Hospital B chooses a unique identity, $I{D}_{HPB}$, and sends it to the blockchain center.

Step 2:

The blockchain center chooses a random number, $r_{HPB}$, and calculates

$$R_{HPB}=r_{HPB}P,$$

(10)

$$h_{HPB}=H_1(I{D}_{HPB},R_{HPB}),$$

(11)

$$S_{HPB}=r_{HPB}+h_{HPB}s,$$

(12)

If the identity $I{D}_{HPB}$ is valid, the blockchain center calls the smart contract hbins as follows:

function hospital B insert smart contract hbins( string hospital B id, string hospital B detail) {     count ++;     hospital B id. count = id;

hospital B detail. count = detail; } string hospital B keypairs;

and it then sends $(R_{HPB},S_{HPB},P{K}_{HPB},S{K}_{HPB})$ to hospital B.

Step 3:

Hospital B verifies

$$S_{HPB}P\stackrel{?}{=}{R}_{HPB}+H_1(I{D}_{HPB},R_{HPB})PK.$$

(13)

If the verification passes, then hospital B stores $(R_{HPB},S_{HPB},P{K}_{HPB},S{K}_{HPB})$ in the medical device.

3.6. Initial Treatment Authentication and Communication Phase

When the patient carries his/her mobile device to hospital A to seek medical services, hospital A and the patient must authenticate one another’s identity first. After mutual authentication between the patient and hospital A, the doctor of hospital A diagnoses the patient. After diagnosis, the doctor of hospital A stores the medical records of the patient in the server of hospital A, and the doctor of hospital A will also inform the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device. The initial treatment authentication and communication phase of the proposed scheme is shown in Figure 5.

Step 1:

The patient chooses a random number, $a$, calculated by

$$T_{PAT}=aP$$

(14)

and then sends $(I{D}_{PAT},R_{PAT},T_{PAT})$ to hospital A.

Step 2:

Hospital A chooses a random number, $b$, calculated by

$$T_{HPA}=bP,$$

(15)

$$P{K}_{PAT}=R_{PAT}+H_1(I{D}_{PAT},R_{PAT})PK,$$

(16)

$$K_{AP1}=S_{HPA}{T}_{PAT}+bP{K}_{PAT},$$

(17)

$$K_{AP2}=b{T}_{PAT},$$

(18)

and the session key

$$SE{K}_{AP}=H_2(K_{AP1},K_{AP2}).$$

(19)

Hospital A then calculates

$$CH{K}_{PA}=H_3(SE{K}_{AP},T_{PAT}),$$

(20)

and sends $(I{D}_{HPA},R_{HPA},T_{HPA},CH{K}_{PA})$ to the patient.

Step 3:

The patient calculates

$$P{K}_{HPA}=R_{HPA}+H_1(I{D}_{HPA},R_{HPA})PK,$$

(21)

$$K_{PA1}=S_{PAT}{T}_{HPA}+aP{K}_{HPA},$$

(22)

$$K_{PA2}=a{T}_{HPA},$$

(23)

and the session key

$$SE{K}_{AP}=H_2(K_{PA1},K_{PA2}).$$

(24)

The patient then verifies

$$CH{K}_{PA}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{PAT})$$

(25)

to check the legality of hospital A. If the verification passes, the patient calls the smart contract hachk as follows:

function hospital A check smart contract hachk(     string hospital A id,     string hospital A detail) {

return hospital A id. exist;     return hospital A detail. exist; }

The patient then calculates

$$c_{PAT}=E_{SE{K}_{AP}}(message)$$

(26)

$$CH{K}_{AP}=H_3(SE{K}_{AP},T_{HPA})$$

(27)

and sends $(I{D}_{PAT},c_{PAT},CH{K}_{AP})$ to hospital A.

Step 4:

Hospital A verifies

$$CH{K}_{AP}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{HPA}),$$

(28)

to check the legality of the patient. If the verification passes, the session key $SE{K}_{AP}$ between the patient and hospital A is established successfully. Hospital A calls the smart contract ptchk as follows:

return patient id. exist;     return patient detail. exist;     mapping medical record. exist; }

function patient check smart contract ptchk(     string patient id,     string patient detail,     mapping medical record) {

Hospital A then decrypts the received message

$$message=D_{SE{K}_{AP}}(c_{PAT}),$$

(29)

to obtain the information about the patient’s symptoms. After the diagnosis of the patient, hospital A stores the medical records of the patient in the server and generates the encrypted basic inspection report and certificate $Cer{t}_{HPA}$

$$c_{HPA}=E_{SE{K}_{AP}}(EMR,Cer{t}_{HPA}),$$

(30)

$$Si{g}_{HPA}=S_{S{K}_{HPA}}(EMR,Cer{t}_{HPA}),$$

(31)

If the identity $I{D}_{PAT}$ is valid, the hospital A calls the smart contract mrins and ptins as follows:

function patient insert smart contract ptins( string patient id, string patient detail, mapping medical record) {     mapping medical record = medical record; } sign string hospital A key ( medical record);

function medical record insert smart contract mrins( string diagnosis id, string diagnosis detail) {     count ++;     diagnosis id. count = id;     diagnosis detail. count = detail; }

and sends $(I{D}_{HPA},c_{HPA},Si{g}_{HPA})$ to the patient.

Step 5:

The patient decrypts the received message,

$$(EMR,Cer{t}_{HPA})=D_{SE{K}_{AP}}(c_{HPA}),$$

(32)

verifies the signature,

$$(EMR,Cer{t}_{HPA})\stackrel{?}{=}{V}_{P{K}_{HPA}}(Si{g}_{HPA}).$$

(33)

and receives the encrypted basic inspection report from hospital A.

3.7. Inter-Hospital Authentication and Communication Phase

When the patient carries his/her mobile device and visits hospital B for extended treatment of a symptom that was previously diagnosed in hospital A, hospital B and the patient will also verify one another’s identity first. After mutual authentication between the patient and hospital B, the doctor of hospital B obtains the medical index of hospital A from the personal mobile device of the patient. Then, the doctor of hospital B requests the medical records of the patient from hospital A. After the doctor of hospital B obtains the encrypted medical records from hospital A and performs a diagnosis, the doctor of hospital B stores the medical records of the patient in the server of hospital B. The doctor of hospital B also informs the patient about the results. The patient keeps the diagnostic results and medical index in his/her mobile device. The inter-hospital authentication and communication phase of the proposed scheme is shown in Figure 6.

Step 1:

The patient chooses a random number, $c$, calculated by

$$T_{PAT2}=cP,$$

(34)

and then sends $(I{D}_{PAT},R_{PAT},T_{PAT2})$ to hospital B.

Step 2:

Hospital B chooses a random number, $d$, calculated by

$$T_{HPB}=dP,$$

(35)

$$P{K}_{PAT}=R_{PAT}+H_1(I{D}_{PAT},R_{PAT})PK,$$

(36)

$$K_{BP1}=S_{HPB}{T}_{PAT2}+dP{K}_{PAT},$$

(37)

$$K_{BP2}=d{T}_{PAT2},$$

(38)

and the session key,

$$SE{K}_{BP}=H_2(K_{BP1},K_{BP2}).$$

(39)

Hospital B then calculates

$$CH{K}_{PB}=H_3(SE{K}_{BP},T_{PAT2}),$$

(40)

and sends $(I{D}_{HPB},R_{HPB},T_{HPB},CH{K}_{PB})$ to the patient.

Step 3:

The patient calculates

$$P{K}_{HPB}=R_{HPB}+H_1(I{D}_{HPB},R_{HPB})PK,$$

(41)

$$K_{PB1}=S_{PAT}{T}_{HPB}+cP{K}_{HPB},$$

(42)

$$K_{PB2}=c{T}_{HPB},$$

(43)

and the session key,

$$SE{K}_{BP}=H_2(K_{PB1},K_{PB2}).$$

(44)

The patient then verifies

$$CH{K}_{PB}\stackrel{?}{=}{H}_3(SE{K}_{BP},T_{PAT2})$$

(45)

to check the legality of hospital B. If the verification passes, the patient calls the smart contract hbchk as follows:

function hospital B check smart contract hbchk(     string hospital B id,     string hospital B detail) {

return hospital B id. exist;     return hospital B detail. exist; }

The patient then calculates

$$c_{PAT2}=E_{SE{K}_{BP}}(message)$$

(46)

$$CH{K}_{BP}=H_3(SE{K}_{BP},T_{HPB})$$

(47)

and sends $(I{D}_{PAT},c_{PAT2},CH{K}_{BP})$ to hospital B.

Step 4:

Hospital B verifies

$$CH{K}_{BP}\stackrel{?}{=}{H}_3(SE{K}_{BP},T_{HPB}),$$

(48)

to check the legality of the patient. If the verification is passed, the session key $SE{K}_{BP}$ between the patient and hospital B is established successfully. The hospital B calls the smart contract ptchk as follows:

function patient check smart contract ptchk(     string patient id,     string patient detail,     mapping medical record) {

return patient id. exist;     return patient detail. exist;     mapping medical record. exist; }

Hospital B then decrypts the received message

$$message=D_{SE{K}_{BP}}(c_{PAT2}),$$

(49)

and receives the encrypted diagnostic results and medical index from hospital A. Hospital B then requests the medical records of the patient from hospital A.

Step 5:

Hospital B chooses a random number, $e$, calculated by

$$T_{HPB2}=eP,$$

(50)

and then sends $(I{D}_{HPB},R_{HPB},T_{HPB2})$ to hospital A.

Step 6:

Hospital A chooses a random number, $f$, calculated by

$$T_{HPA2}=fP,$$

(51)

$$P{K}_{HPB}=R_{HPB}+H_1(I{D}_{HPB},R_{HPB})PK,$$

(52)

$$K_{AB1}=S_{HPA}{T}_{HPB2}+fP{K}_{HPB},$$

(53)

$$K_{AB2}=f{T}_{HPB2},$$

(54)

and the session key,

$$SE{K}_{AB}=H_2(K_{AB1},K_{AB2})$$

(55)

Hospital A then calculates

$$CH{K}_{BA}=H_3(SE{K}_{AB},T_{HPB2}),$$

(56)

and sends $(I{D}_{HPA},R_{HPA},T_{HPA2},CH{K}_{BA})$ to hospital B.

Step 7:

Hospital B calculates

$$P{K}_{HPA}=R_{HPA}+H_1(I{D}_{HPA},R_{HPA})PK$$

(57)

$$K_{BA1}=S_{HPB}{T}_{HPA2}+eP{K}_{HPA},$$

(58)

$$K_{BA2}=e{T}_{HPA2},$$

(59)

and the session key,

$$SE{K}_{AB}=H_2(K_{BA1},K_{BA2}).$$

(60)

Hospital B then verifies

$$CH{K}_{BA}\stackrel{?}{=}{H}_3(SE{K}_{AB},T_{HPB2})$$

(61)

to check the legality of hospital A. If the verification passes, hospital B calculates

$$c_{HPB}=E_{SE{K}_{AB}}(message)$$

(62)

$$CH{K}_{AB}=H_3(SE{K}_{AB},T_{HPA2})$$

(63)

and sends $(I{D}_{HPB},c_{HPB},CH{K}_{AB})$ to hospital A.

Step 8:

Hospital A verifies

$$CH{K}_{AB}\stackrel{?}{=}{H}_3(SE{K}_{AB},T_{HPA2})$$

(64)

to check the legality of hospital B. If the verification is passed, the session key $SE{K}_{AB}$ between hospital B and hospital A is established successfully.

Hospital A then decrypts the received message

$$message=D_{SE{K}_{AB}}(c_{HPB})$$

(65)

and receives the medical record request from the patient. Hospital A then generates the encrypted medical records of the patient

$$c_{HPA2}=E_{SE{K}_{AB}}(EMR),$$

(66)

$$Si{g}_{HPA2}=S_{S{K}_{HPA}}(EMR),$$

(67)

and sends $(I{D}_{HPA},c_{HPA2},Si{g}_{HPA2})$ to hospital B.

Step 9:

Hospital B decrypts the received message

$$EMR=D_{SE{K}_{AB}}(c_{HPA2}),$$

(68)

verifies the signature,

$$EMR\stackrel{?}{=}{V}_{P{K}_{HPA}}(Si{g}_{HPA2}).$$

(69)

If the verification passes, and hospital B calls the smart contract mrchk as follows:

string diagnosis id, string diagnosis detail) {     return diagnosis id. exist;     return diagnosis detail. exist; }

verify string hospital A key ( hospital A information, patient information); function medical record check smart contract mrchk(

Hospital B then receives the encrypted medical records of the patient from hospital A.

Step 10:

After the diagnosis of the patient, hospital B stores the medical records of the patient in the server and generates the encrypted basic inspection report

$$c_{HPB2}=E_{SE{K}_{BP}}(EMR,Cer{t}_{HPB}),$$

(70)

$$Si{g}_{HPB}=S_{S{K}_{HPB}}(EMR,Cer{t}_{HPB}),$$

(71)

If the identity $I{D}_{PAT}$ is valid, hospital B calls the smart contract mrins and ptins as follows:

function patient insert smart contract ptins( string patient id, string patient detail, mapping medical record) {     mapping medical record = medical record; } sign string hospital B key ( medical record);

function medical record insert smart contract mrins( string diagnosis id, string diagnosis detail) {     count ++;     diagnosis id. count = id;     diagnosis detail. count = detail; }

and sends $(I{D}_{HPB},c_{HPB2},Si{g}_{HPB})$ to the patient.

Step 11:

The patient decrypts the received message,

$$(EMR,Cer{t}_{HPB})=D_{SE{K}_{BP}}(c_{HPB2}),$$

(72)

verifies the signature,

$$(EMR,Cer{t}_{HPB})\stackrel{?}{=}{V}_{P{K}_{HPB}}(Si{g}_{HPB}).$$

(73)

and receives the encrypted basic inspection report from hospital B.

4. Security Analysis

4.1. Mutual Authentication

The BAN logic proof model is applied in order to prove that mutual authentication is achieved between different parties in each phase of the proposed scheme.

In the initial treatment authentication and communication phase of the proposed scheme, the main goal of the scheme is to authenticate the session key establishment between the patient, P, and hospital A, HA.

G1:	$P|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
G2:	$P|\equiv HA|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
G3:	$HA|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
G4:	$HA|\equiv P|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
G5:	$P|\equiv I{D}_{HPA}$
G6:	$P|\equiv HA|\equiv I{D}_{HPA}$
G7:	$HA|\equiv I{D}_{PAT}$
G8:	$HA|\equiv P|\equiv I{D}_{PAT}$

According to the initial treatment authentication and communication phase, BAN logic is applied in order to produce an idealized form as follows:

M1:	$(<I{D}_{PAT},R_{PAT},T_{PAT}{>}_{P{K}_{HPA}},<H(SE{K}_{AP},T_{HPA}){>}_{CH{K}_{AP}})$
M2:	$(<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{PAT}},<H(SE{K}_{AP},T_{PAT}){>}_{CH{K}_{PA}})$

To analyze the proposed scheme, the following assumptions are made:

A1:	$P|\equiv \#(T_{PAT})$
A2:	$HA|\equiv \#(T_{PAT})$
A3:	$P|\equiv \#(T_{HPA})$
A4:	$HA|\equiv \#(T_{HPA})$
A5:	$P|\equiv HA|\Rightarrow P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
A6:	$HA|\equiv P|\Rightarrow P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
A7:	$P|\equiv HA|\Rightarrow I{D}_{HPA}$
A8:	$HA|\equiv P|\Rightarrow I{D}_{PAT}$

According to these assumptions and the rules of BAN logic, the main proof of the initial treatment authentication and communication phase is as follows:

• Hospital A, HA, authenticates the patient, P.

  We derive the following statement by M1 and the seeing rule:
  $HA⊲(<I{D}_{PAT},R_{PAT},T_{PAT}{>}_{P{K}_{HPA}},<H(SE{K}_{AP},T_{HPA}){>}_{CH{K}_{AP}})$	(Statement 1)
  We derive the following statement by A2 and the freshness rule:
  $HA|\equiv \#(<I{D}_{PAT},R_{PAT},T_{PAT}{>}_{P{K}_{HPA}},<H(SE{K}_{AP},T_{HPA}){>}_{CH{K}_{AP}})$	(Statement 2)
  We derive the following statement by (Statement 1), A4, and the message meaning rule:
  $HA|\equiv P|~(<I{D}_{PAT},R_{PAT},T_{PAT}{>}_{P{K}_{HPA}},<H(SE{K}_{AP},T_{HPA}){>}_{CH{K}_{AP}})$	(Statement 3)
  We derive the following statement by (Statement 2), (Statement 3), and the nonce verification rule:
  $HA|\equiv P|\equiv (<I{D}_{PAT},R_{PAT},T_{PAT}{>}_{P{K}_{HPA}},<H(SE{K}_{AP},T_{HPA}){>}_{CH{K}_{AP}})$	(Statement 4)
  We derive the following statement by (Statement 4) and the belief rule:
  $HA|\equiv P|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$	(Statement 5)
  We derive the following statement by (Statement 5), A6, and the jurisdiction rule:
  $HA|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$	(Statement 6)
  We derive the following statement by (Statement 6) and the belief rule:
  $HA|\equiv P|\equiv I{D}_{PAT}$	(Statement 7)
  We derive the following statement by (Statement 7), A8, and the jurisdiction rule:
  $HA|\equiv I{D}_{PAT}$	(Statement 8)

• The patient P authenticates the hospital A HA.

  We derive the following statement by M2 and the seeing rule:
  $P⊲(<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{PAT}},<H(SE{K}_{AP},T_{PAT}){>}_{CH{K}_{PA}})$	(Statement 9)
  We derive the following statement by A1 and the freshness rule:
  $P|\equiv \#(<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{PAT}},<H(SE{K}_{AP},T_{PAT}){>}_{CH{K}_{PA}})$	(Statement 10)
  We derive the following statement by (Statement 9), A3, and the message meaning rule:
  $P|\equiv HA|~(<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{PAT}},<H(SE{K}_{AP},T_{PAT}){>}_{CH{K}_{PA}})$	(Statement 11)
  We derive the following statement by (Statement 10), (Statement 11), and the nonce verification rule:
  $P|\equiv HA|\equiv (<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{PAT}},<H(SE{K}_{AP},T_{PAT}){>}_{CH{K}_{PA}})$	(Statement 12)
  We derive the following statement by (Statement 12) and the belief rule:
  $P|\equiv HA|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$	(Statement 13)
  We derive the following statement by (Statement 13), A5, and the jurisdiction rule:
  $P|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$	(Statement 14)
  We derive the following statement by (Statement 14) and the belief rule:
  $P|\equiv HA|\equiv I{D}_{HPA}$	(Statement 15)
  We derive the following statement by (Statement 15), A7, and the jurisdiction rule:
  $P|\equiv I{D}_{HPA}$	(Statement 16)

By (Statement 6), (Statement 8), (Statement 14), and (Statement 16), it can be proven that, in the proposed scheme, the patient P and hospital A HA authenticate each other. Moreover, it can also be proven that the proposed scheme can establish a session key between the patient P and hospital A HA.

In the proposed scheme, hospital A authenticates the patient by

$$CH{K}_{AP}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{HPA}).$$

If it passes the verification, hospital A authenticates the legality of the patient. The patient authenticates hospital A by

$$CH{K}_{PA}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{PAT}).$$

If it passes the verification, the patient authenticates the legality of hospital A. The initial treatment authentication and communication phase of the proposed scheme thus guarantees mutual authentication between hospital A and the patient.

In the inter-hospital authentication and communication phase of the proposed scheme, the main goal of the scheme is to authenticate the session key establishment between the patient P and hospital B HB and also between hospital B HB and hospital A HA.

G9:	$P|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
G10:	$P|\equiv HB|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
G11:	$HB|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
G12:	$HB|\equiv P|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
G13:	$P|\equiv I{D}_{HPB}$
G14:	$P|\equiv HA|\equiv I{D}_{HPB}$
G15:	$HB|\equiv I{D}_{PAT}$
G16:	$HB|\equiv P|\equiv I{D}_{PAT}$
G17:	$P|\equiv P\stackrel{SE{K}_{AP}}{\leftrightarrow }HA$
G18:	$HB|\equiv HA|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$
G19:	$HA|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$
G20:	$HA|\equiv HB|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$
G21:	$HB|\equiv I{D}_{HPA}$
G22:	$HB|\equiv HA|\equiv I{D}_{HPA}$
G23:	$HA|\equiv I{D}_{HPB}$
G24:	$HA|\equiv HB|\equiv I{D}_{HPB}$

According to the inter-hospital authentication and communication phase, BAN logic is applied in order to produce an idealized form as follows:

M3:	$(<I{D}_{PAT},R_{PAT},T_{PAT2}{>}_{P{K}_{HPB}},<H(SE{K}_{BP},T_{HPB}){>}_{CH{K}_{BP}})$
M4:	$(<I{D}_{HPB},R_{HPB},T_{HPB}{>}_{P{K}_{PAT}},<H(SE{K}_{BP},T_{PAT2}){>}_{CH{K}_{PB}})$
M5:	$(<I{D}_{HPB},R_{HPB},T_{HPB2}{>}_{P{K}_{HPA}},<H(SE{K}_{AB},T_{HPA2}){>}_{CH{K}_{AB}})$
M6:	$(<I{D}_{HPA},R_{HPA},T_{HPA}{>}_{P{K}_{HPB}},<H(SE{K}_{AB},T_{HPB2}){>}_{CH{K}_{BA}})$

To analyze the proposed scheme, the following assumptions are made:

A9:	$P|\equiv \#(T_{PAT2})$
A10:	$HB|\equiv \#(T_{PAT2})$
A11:	$P|\equiv \#(T_{HPB})$
A12:	$HB|\equiv \#(T_{HPB})$
A13:	$P|\equiv HB|\Rightarrow P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
A14:	$HB|\equiv P|\Rightarrow P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$
A15:	$P|\equiv HB|\Rightarrow I{D}_{HPB}$
A16:	$HB|\equiv P|\Rightarrow I{D}_{PAT}$
A17:	$HB|\equiv \#(T_{HPB2})$
A18:	$HA|\equiv \#(T_{HPB2})$
A19:	$HB|\equiv \#(T_{HPA2})$
A20:	$HA|\equiv \#(T_{HPA2})$
A21:	$HB|\equiv HA|\Rightarrow HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$
A22:	$HA|\equiv HB|\Rightarrow HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$
A23:	$HB|\equiv HA|\Rightarrow I{D}_{HPA}$
A24:	$HA|\equiv HB|\Rightarrow I{D}_{HPB}$

According to these assumptions and the rules of BAN logic, the inter-hospital authentication and communication phase is as follows:

c.

Hospital B, HB, authenticates the patient, P.

We derive the following statement by M3 and the seeing rule:
$HB⊲(<I{D}_{PAT},R_{PAT},T_{PAT2}{>}_{P{K}_{HPB}},<H(SE{K}_{BP},T_{HPB}){>}_{CH{K}_{BP}})$	(Statement 17)
We derive the following statement by A10 and the freshness rule:
$HB|\equiv \#(<I{D}_{PAT},R_{PAT},T_{PAT2}{>}_{P{K}_{HPB}},<H(SE{K}_{BP},T_{HPB}){>}_{CH{K}_{BP}})$	(Statement 18)
We derive the following statement by (Statement 17), A12, and the message meaning rule:
$HB|\equiv P|~(<I{D}_{PAT},R_{PAT},T_{PAT2}{>}_{P{K}_{HPB}},<H(SE{K}_{BP},T_{HPB}){>}_{CH{K}_{BP}})$	(Statement 19)
We derive the following statement by (Statement 18), (Statement 19), and the nonce verification rule:
$HB|\equiv P|\equiv (<I{D}_{PAT},R_{PAT},T_{PAT2}{>}_{P{K}_{HPB}},<H(SE{K}_{BP},T_{HPB}){>}_{CH{K}_{BP}})$	(Statement 20)
We derive the following statement by (Statement 20) and the belief rule:
$HB|\equiv P|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$	(Statement 21)
We derive the following statement by (Statement 21), A14, and the jurisdiction rule:
$HB|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$	(Statement 22)
We derive the following statement by (Statement 22) and the belief rule:
$HB|\equiv P|\equiv I{D}_{PAT}$	(Statement 23)
We derive the following statement by (Statement 23), A16, and the jurisdiction rule:
$HB|\equiv I{D}_{PAT}$	(Statement 24)

d.

The patient P authenticates hospital B HB.

We derive the following statement by M4 and the seeing rule:
$P⊲(<I{D}_{HPB},R_{HPB},T_{HPB}{>}_{P{K}_{PAT}},<H(SE{K}_{BP},T_{PAT2}){>}_{CH{K}_{PB}})$	(Statement 25)
We derive the following statement by A9 and the freshness rule:
$P|\equiv \#(<I{D}_{HPB},R_{HPB},T_{HPB}{>}_{P{K}_{PAT}},<H(SE{K}_{BP},T_{PAT2}){>}_{CH{K}_{PB}})$	(Statement 26)
We derive the following statement by (Statement 25), A11, and the message meaning rule:
$P|\equiv HB|~(<I{D}_{HPB},R_{HPB},T_{HPB}{>}_{P{K}_{PAT}},<H(SE{K}_{BP},T_{PAT2}){>}_{CH{K}_{PB}})$	(Statement 27)
We derive the following statement by (Statement 26), (Statement 27), and the nonce verification rule:
$P|\equiv HB|\equiv (<I{D}_{HPB},R_{HPB},T_{HPB}{>}_{P{K}_{PAT}},<H(SE{K}_{BP},T_{PAT2}){>}_{CH{K}_{PB}})$	(Statement 28)
We derive the following statement by (Statement 28) and the belief rule:
$P|\equiv HB|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$	(Statement 29)
We derive the following statement by (Statement 29), A13, and the jurisdiction rule:
$P|\equiv P\stackrel{SE{K}_{BP}}{\leftrightarrow }HB$	(Statement 30)
We derive the following statement by (Statement 30) and the belief rule:
$P|\equiv HB|\equiv I{D}_{HPB}$	(Statement 31)
We derive the following statement by (Statement 31), A15, and the jurisdiction rule:
$P|\equiv I{D}_{HPB}$	(Statement 32)

e.

The hospital A HA authenticates the hospital B HB.

We derive the following statement by M5 and the seeing rule:
$HA⊲(<I{D}_{HPB},R_{HPB},T_{HPB2}{>}_{P{K}_{HPA}},<H(SE{K}_{AB},T_{HPA2}){>}_{CH{K}_{AB}})$	(Statement 33)
We derive the following statement by A18 and the freshness rule:
$HA|\equiv \#(<I{D}_{HPB},R_{HPB},T_{HPB2}{>}_{P{K}_{HPA}},<H(SE{K}_{AB},T_{HPA2}){>}_{CH{K}_{AB}})$	(Statement 34)
We derive the following statement by (Statement 33), A20, and the message meaning rule:
$HA|\equiv HB|~(<I{D}_{HPB},R_{HPB},T_{HPB2}{>}_{P{K}_{HPA}},<H(SE{K}_{AB},T_{HPA2}){>}_{CH{K}_{AB}})$	(Statement 35)
We derive the following statement by (Statement 34), (Statement 35), and the nonce verification rule:
$HA|\equiv HB|\equiv (<I{D}_{HPB},R_{HPB},T_{HPB2}{>}_{P{K}_{HPA}},<H(SE{K}_{AB},T_{HPA2}){>}_{CH{K}_{AB}})$	(Statement 36)
We derive the following statement by (Statement 36) and the belief rule:
$HA|\equiv HB|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$	(Statement 37)
We derive the following statement by (Statement 37), A22, and the jurisdiction rule:
$HA|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$	(Statement 38)
We derive the following statement by (Statement 38) and the belief rule:
$HA|\equiv HB|\equiv I{D}_{HPB}$	(Statement 39)
We derive the following statement by (Statement 39), A24, and the jurisdiction rule:
$HA|\equiv I{D}_{HPB}$	(Statement 40)

f.

The hospital B HB authenticates the hospital A HA.

We derive the following statement by M6 and the seeing rule:
$HB⊲(<I{D}_{HPA},R_{HPA},T_{HPA2}{>}_{P{K}_{HPB}},<H(SE{K}_{AB},T_{HPB2}){>}_{CH{K}_{BA}})$	(Statement 41)
We derive the following statement by A17 and the freshness rule:
$HB|\equiv \#(<I{D}_{HPA},R_{HPA},T_{HPA2}{>}_{P{K}_{HPB}},<H(SE{K}_{AB},T_{HPB2}){>}_{CH{K}_{BA}})$	(Statement 42)
We derive the following statement by (Statement 41), A19, and the message meaning rule:
$HB|\equiv HA|~(<I{D}_{HPA},R_{HPA},T_{HPA2}{>}_{P{K}_{HPB}},<H(SE{K}_{AB},T_{HPB2}){>}_{CH{K}_{BA}})$	(Statement 43)
We derive the following statement by (Statement 42), (Statement 43), and the nonce verification rule:
$HB|\equiv HA|\equiv (<I{D}_{HPA},R_{HPA},T_{HPA2}{>}_{P{K}_{HPB}},<H(SE{K}_{AB},T_{HPB2}){>}_{CH{K}_{BA}})$	(Statement 44)
We derive the following statement by (Statement 44) and the belief rule:
$HB|\equiv HA|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$	(Statement 45)
We derive the following statement by (Statement 45), A21, and the jurisdiction rule:
$HB|\equiv HB\stackrel{SE{K}_{AB}}{\leftrightarrow }HA$	(Statement 46)
We derive the following statement by (Statement 46) and the belief rule:
$HB|\equiv HA|\equiv I{D}_{HPA}$	(Statement 47)
We derive the following statement by (Statement 47), A23, and the jurisdiction rule:
$HB|\equiv I{D}_{HPA}$	(Statement 48)

By (Statement 22), (Statement 24), (Statement 30), and (Statement 32), it can be proven that, in the proposed scheme, the patient P and hospital B HB authenticate each other. Moreover, it can also be proven that the proposed scheme can establish a session key between the patient P and hospital B HB.

In the proposed scheme, hospital B authenticates the patient by

$$CH{K}_{BP}\stackrel{?}{=}{H}_3(SE{K}_{BP},T_{HPB}).$$

If it passes the verification, hospital B authenticates the legality of the patient. The patient authenticates hospital B by

$$CH{K}_{PB}\stackrel{?}{=}{H}_3(SE{K}_{BP},T_{PAT2}).$$

If it passes the verification, the patient authenticates the legality of hospital B. In the same phase, by (Statement 38), (Statement 40), (Statement 46), and (Statement 48), it can be proven that, in the proposed scheme, hospital B HB and hospital A HA authenticate each other. Moreover, it can also be proven that the proposed scheme can establish a session key between hospital B HB and hospital A HA.

In the proposed scheme, hospital A authenticates the hospital B by

$$CH{K}_{AB}\stackrel{?}{=}{H}_3(SE{K}_{AB},T_{HPA2}).$$

If it passes the verification, hospital A authenticates the legality of hospital B. Hospital B authenticates the hospital A by

$$CH{K}_{BA}\stackrel{?}{=}{H}_3(SE{K}_{AB},T_{HPB2}).$$

If it passes the verification, hospital B authenticates the legality of hospital A. The inter-hospital authentication and communication phase of the proposed scheme thus guarantees mutual authentication between the patient, P, and hospital B, HB, and also between hospital B, HB, and hospital A, HA.

Scenario:

A malicious attacker uses an illegal hospital medical device to obtain a patient’s medical record from a legal patient’s mobile device.

Analysis:

The attacker will not succeed because the illegal hospital medical device has not been registered to the blockchain server and thus cannot calculate the correct session key. Thus, the attack will fail when the legal patient mobile device attempts to authenticate the illegal hospital medical device. In the proposed scheme, the attacker cannot achieve its purpose using an illegal hospital medical device. In the same scenario, the proposed scheme can also defend against a malicious attack using an illegal patient mobile device to send fake information to a legal hospital medical device, because the illegal patient mobile device has not been registered to the blockchain server and thus cannot calculate the correct session key. Thus, the attack will fail when the legal hospital medical device attempts to authenticate the illegal patient mobile device.

4.2. Data Integrity

To ensure the integrity of the transaction data, this study uses elliptic curve cryptography to calculate the session key, $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$, and also to protect the data’s integrity. The malicious attacker cannot use the signatures $(K_{AP1},K_{AP2})$, $(K_{PA1},K_{PA2})$, $(K_{BP1},K_{BP2})$, $(K_{PB1},K_{PB2})$, $(K_{AB1},K_{AB2})$, and $(K_{BA1},K_{BA2})$ to calculate the correct session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$.

Only the legal patient or hospital A can calculate the correct session key $SE{K}_{AP}$. The legal hospital A calculates the session key as follows:

$$SE{K}_{AP}=H_2(K_{AP1},K_{AP2})$$

and the legal patient calculates the session key as follows:

$$SE{K}_{AP}=H_2(K_{PA1},K_{PA2}).$$

$$\begin{array}{ll}\hfill K_{PA1}& =S_{PAT}{T}_{HPA}+aP{K}_{HPA}\hfill \\ & =S_{PAT}bP+a{S}_{HPA}P\hfill \\ & =b{S}_{PAT}P+S_{HPA}aP\hfill \\ & =bP{K}_{PAT}+S_{HPA}{T}_{PAT}=K_{AP1}\hfill \\ \hfill K_{PA2}& =a{T}_{HPA}=abP=baP=b{T}_{PAT}=K_{AP2}\hfill \end{array}$$

Only the legal patient or hospital B can calculate the correct session key $SE{K}_{BP}$. The legal hospital B calculates the session key as follows:

$$SE{K}_{BP}=H_2(K_{BP1},K_{BP2})$$

and the legal patient calculates the session key as follows:

$$SE{K}_{BP}=H_2(K_{PB1},K_{PB2}).$$

$$\begin{array}{ll}\hfill K_{PB1}& =S_{PAT}{T}_{HPB}+cP{K}_{HPB}\hfill \\ & =S_{PAT}dP+c{S}_{HPB}P\hfill \\ & =d{S}_{PAT}P+S_{HPB}cP\hfill \\ & =dP{K}_{PAT}+S_{HPB}{T}_{PAT2}=K_{BP1}\hfill \\ \hfill K_{PB2}& =c{T}_{HPB}=cdP=dcP=d{T}_{PAT2}=K_{BP2}\hfill \end{array}$$

Only legal hospital B or hospital A can calculate the correct session key $SE{K}_{AB}$. The legal hospital A calculates the session key as follows:

$$SE{K}_{AB}=H_2(K_{AB1},K_{AB2})$$

and the legal hospital B calculates the session key as follows:

$$SE{K}_{AB}=H_2(K_{BA1},K_{BA2}).$$

$$\begin{array}{ll}\hfill K_{BA1}& =S_{HPB}{T}_{HPA2}+eP{K}_{HPA}\hfill \\ & =S_{HPB}fP+e{S}_{HPA}P\hfill \\ & =f{S}_{HPB}P+S_{HPA}eP\hfill \\ & =fP{K}_{HPB}+S_{HPA}{T}_{HPB2}=K_{AB1}\hfill \\ \hfill K_{BA2}& =e{T}_{HPA2}=efP=feP=f{T}_{HPB2}=K_{AB2}\hfill \end{array}$$

Only the correct session key will make a successful communication. Therefore, malicious attackers cannot modify the transmitted information. Thus, data integrity is achieved by the proposed scheme.

Scenario:

A malicious attacker intercepts the information transmitted from hospital A to the patient and sends a modified information to the patient.

Analysis:

The attacker will not succeed because the legal patient will use

$$CH{K}_{PA}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{PAT})$$

to check the data integrity of the transmitted information. The malicious attacker cannot calculate the correct session key $SE{K}_{AP}$. Therefore, the attack will fail when the legal patient authenticates the received information. The malicious attacker cannot achieve his/her purpose by sending modified information to the patient in the proposed scheme. For the same reason, the attack will fail when the legal hospital A uses

$$CH{K}_{AP}\stackrel{?}{=}{H}_3(SE{K}_{AP},T_{HPA})$$

to check data integrity. Thus, malicious attackers cannot achieve their purpose by sending a modified message to hospital A.

4.3. User Untraceability

Another frame of privacy attack relates to trying to obtain the physical location of a person by tracing his/her device (in this case, the personal mobile device carried by the patient). If the personal mobile device transmits the same information continuously, then its location can be traced by a malicious attacker. In the proposed system, the session key $SE{K}_{AP}$ and $SE{K}_{BP}$ is changed for every communication round in order to prevent location tracking. Therefore, the proposed system achieves user untraceability and protects location privacy.

4.4. Resisting Replay Attack

The information transmitted between the sender and the receiver may also be intercepted by a malicious attacker. He/she impersonates a legal sender and then sends the same information again to the predetermined receiver. However, as all information transmitted between the sender and the receiver is protected with the session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$, a malicious attacker cannot calculate the correct session key, thus this attack will fail in the proposed system. Due to the transmitted information being changed after every round, the same information cannot be sent twice. Therefore, the replay attack cannot succeed in the proposed scheme.

4.5. Forward and Backward Secrecy

If a malicious attacker compromises the session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$ which is established between the sender and the receiver, the proposed system still satisfies forward and backward secrecy. The malicious attacker may use the compromised session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$ for future malicious communication or use it to obtain previously transmitted messages. However, the session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$ is randomly chosen by the sender and the receiver, and the session key may only be used in the current round. The malicious attacker cannot use the same session key $SE{K}_{AP}$, $SE{K}_{BP}$ and $SE{K}_{AB}$ for future malicious communication or use it to obtain previously transmitted messages. Therefore, forward and backward secrecy is achieved in the proposed scheme.

4.6. Non-Repudiation

In the proposed scheme, a digital signature is used to achieve nonrepudiation for the EMR compiled by a doctor. In the initial treatment authentication and communication phase, hospital A uses the private key to sign the patient’s EMR, and then the signed message is transmitted to the patient. The patient uses the public key of hospital A to verify the signed message. In the inter-hospital authentication and communication phase, hospital A uses the private key to sign the patient’s EMR, and then the signed message is transmitted to hospital B. Hospital B uses the public key of hospital A to verify the signed message. Then, hospital B uses the private key to sign the patient’s EMR, and the signed message is transmitted to the patient. The patient uses the public key of hospital B to verify the signed message. Thus, the proposed scheme achieves nonrepudiation for EMR established by hospital A or hospital B.

Table 1. Non-repudiation of the proposed scheme.

	Item	Proof	Issuer	Holder	Verification
Phase
Initial Treatment Authentication and Communication Phase		$(c_{HPA},Si{g}_{HPA})$	Hospital A	Patient	$(EMR,Cer{t}_{HPA})\stackrel{?}{=}{V}_{P{K}_{HPA}}(Si{g}_{HPA})$
Inter-Hospital Authentication and Communication Phase		$(c_{HPA2},Si{g}_{HPA2})$	Hospital A	Hospital B	$EMR\stackrel{?}{=}{V}_{P{K}_{HPA}}(Si{g}_{HPA2})$
		$(c_{HPB2},Si{g}_{HPB})$	Hospital B	Patient	$(EMR,Cer{t}_{HPB})\stackrel{?}{=}{V}_{P{K}_{HPB}}(Si{g}_{HPB})$

shows the non-repudiation of the proposed scheme.

4.7. Computation Cost

Table 2. The computation costs of the proposed scheme.

	Party	Blockchain Center	Hospital A	Hospital B	Patient
Phase
Patient Registration Phase		$2T_{Mul}+1T_H$	N/A	N/A	$\begin{array}{l}2T_{Mul}+1T_H\\ +1T_{Cmp}\end{array}$
Hospital A Registration Phase		$2T_{Mul}+1T_H$	$\begin{array}{l}2T_{Mul}+1T_H\\ +1T_{Cmp}\end{array}$	N/A	N/A
Hospital B Registration Phase		$2T_{Mul}+1T_H$	N/A	$\begin{array}{l}2T_{Mul}+1T_H\\ +1T_{Cmp}\end{array}$	N/A
Initial Treatment Authentication and Communication Phase		N/A	$\begin{array}{l}5T_{Mul}+4T_H\\ +1T_{Cmp}+2T_{Enc}\\ +1T_{Sig}\end{array}$	N/A	$\begin{array}{l}5T_{Mul}+4T_H\\ +2T_{Cmp}+2T_{Enc}\\ +1T_{Sig}\end{array}$
Inter-Hospital Authentication and Communication Phase		N/A	$\begin{array}{l}5T_{Mul}+4T_H\\ +1T_{Cmp}+2T_{Enc}\\ +1T_{Sig}\end{array}$	$\begin{array}{l}10T_{Mul}+8T_H\\ +3T_{Cmp}+4T_{Enc}\\ +2T_{Sig}\end{array}$	$\begin{array}{l}5T_{Mul}+4T_H\\ +2T_{Cmp}+2T_{Enc}\\ +1T_{Sig}\end{array}$

$T_{Mul}$: Multiplication operation, $T_H$: hash function operation, $T_{Cmp}$: comparison of operation, $T_{Enc}$: symmetric encryption operation, $T_{Sig}$: signature operation.

shows the computation costs of the proposed scheme.

The computation costs of our proposed system for the blockchain center, hospital A, hospital B, and the patient in each phase are analyzed in Table 2. We found the highest computation cost in the inter-hospital authentication and communication phase; for example, hospital A needs five multiplication operations, one comparison operation, four hash function operations, two symmetric encryption operations, and one signature operation. Hospital B needs ten multiplication operations, three comparison operations, eight hash function operations, four symmetric encryption operations, and two signature operations. The patient needs five multiplication operations, two comparison operations, two symmetric encryption operations, four hash function operations, and one signature operation. Thus, the computation cost is acceptable in our proposed system.

4.8. Communication Cost

The following table,

Table 3. Communication cost of the proposed scheme.

	Item	Message Length	Round	3.5G (14 Mbps)	4G (100 Mbps)	5G (20 Gbps)
Phase
Patient Registration Phase		2528 bits	2	0.181 ms	0.025 ms	0.126 us
Hospital A Registration Phase		2528 bits	2	0.181 ms	0.025 ms	0.126 us
Hospital B Registration Phase		2528 bits	2	0.181 ms	0.025 ms	0.126 us
Initial Treatment Authentication and Communication Phase		2816 bits	4	0.201 ms	0.028 ms	0.141 us
Inter-Hospital Authentication and Communication Phase		5632 bits	8	0.402 ms	0.056 ms	0.282 us

, shows the communication cost of the proposed scheme.

The communication efficiency of our proposed system during the transaction process of each phase is also analyzed in Table 3. It is assumed that an elliptic curve modular operation requires 160 bits, an Advanced Encryption Standard (AES) operation requires 256 bits, a hash operation requires 160 bits, and a signature operation requires 1024 bits, while other messages, like id, pid, and a random number, require 80 bits. Taking the inter-hospital authentication and communication phase, for example, it requires eight elliptic curve modular messages, four AES messages, four hash messages, two signature operation messages, and eight other messages. Thus, it requires 160 × 8 + 160 × 4 + 256 × 4 + 1024 × 2 + 80 × 8 = 5632 bits in total. The maximum transmission speed is 14 Mbps in a 3.5 G environment. The inter-hospital authentication and communication phase is also considered in this study, which only takes 0.402 ms to transfer all messages. The maximum transmission speed is 100 Mbps in a 4G environment, and thus the transmission time is reduced to 0.056 ms to transfer all messages. In a 5G environment [52], with a maximum transmission speed of 20 Gbps, the transmission time is only 0.282 us.

4.9. Functionality Comparison

Table 4. Functionality comparison of previous schemes and the proposed scheme.

	Scheme	Liu et al. (2019) [43]	Xu et al. (2019) [44]	Our Scheme
Functionality
Blockchain Architecture		Yes	Yes	Yes
Mutual Authentication		Yes	Yes	Yes
Data Integrity		Yes	Yes	Yes
User Untraceability		Yes	Yes	Yes
Resistance to Replay Attack		Yes	Yes	Yes
Forward and Backward Secrecy		Yes	Yes	Yes
Nonrepudiation		No	Yes	Yes
BAN Logic Proof		No	No	Yes
Inter-Hospital Authentication		No	No	Yes

shows the functionality comparison of previous schemes and the proposed scheme.

5. Conclusions

With the growth of medical technology, medical information is becoming increasingly important in terms of patient identity background, medical payment records, and medical history. This can be the most private information about a person, but due to some issues, such as operation errors within the network or hacking attacks by a malicious person, there have formerly been major leaks of sensitive personal information. In any case, this has become an issue worth studying to ensure the privacy of patients and protect these medical materials.

On the other hand, under the current medical system, the patient’s medical record cannot be searched across different hospitals. When the patient visits another hospital for treatment, repeated examinations will occur, resulting in a waste of medical resources. Therefore, inter-hospital medical record access is also a very important goal. This study draws on blockchain technology to propose a secure inter-hospital EMR sharing system. Assuming that the hospitals and the patients are in the same medical alliance, the blockchain center will issue identity verification keys to these members. After this, the alliance members can conduct legal communication and data exchange in the future. Thus, the medical records of the patients will be accessible. This can prevent the waste of medical resources and achieve higher medical quality and efficiency. The proposed scheme meets a variety of security requirements, and the BAN logic proof model is applied to assess the correctness of the proposed scheme. The proposed scheme performs quite well in terms of computational and communication costs. In the future, the prospect of using blockchain-based technologies the medical field is becoming increasingly likely. While protecting personal privacy and sharing medical resources, how could the blockchain transaction become efficient? This is another research direction by which to compare blockchain-based platforms in a performance evaluation.