A Blockchain-Based Secure Inter-Hospital EMR Sharing System

: 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 ﬁelds. 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.


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].
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.

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.

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.

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.

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.

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.

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.

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.

1.
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.

2.
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.

3.
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. (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.

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 as a public key.

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. 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.

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, PAT ID , and sends it to the blockchain center. 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.

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, ID PAT , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, r PAT , and calculates If the identity ID PAT is valid, the blockchain center calls the smart contract ptins as follows: Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 29 If the identity PAT ID is valid, the blockchain center calls the smart contract ptins as follows: and it then sends ( , ,

, )
PAT PAT PAT PAT R S PK SK to the patient.
Step 3: The patient verifies If the verification is passed, then the patient stores ( , , and it then sends (R PAT , S PAT , PK PAT , SK PAT ) to the patient.
Step 3: The patient verifies Appl. Sci. 2020, 10, 4958 If the verification is passed, then the patient stores (R PAT , S PAT , PK PAT , SK PAT ) in his/her mobile device.
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.

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, PAT ID , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, PAT r , and calculates

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 Figures 3 and 4.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 29 If the identity PAT ID is valid, the blockchain center calls the smart contract ptins as follows: and it then sends ( , ,

, )
PAT PAT PAT PAT R S PK SK to the patient.
Step 3: The patient verifies If the verification is passed, then the patient stores ( , ,

, )
PAT PAT PAT PAT R S PK SK in his/her mobile device.

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 Figures 3 and 4. Step 1: Hospital A chooses a unique identity, HPA ID , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, HPA r , and calculates  Step 1: Hospital A chooses a unique identity, ID HPA , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, r HPA , and calculates S HPA = r HPA + h HPA s, If the identity ID HPA is valid, the blockchain center calls the smart contract hains as follows: to hospital A.
Step 3: Hospital A verifies  Step 1: Hospital B chooses a unique identity, HPB ID , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, HPB r , and calculates HPB HPB If the verification passes, then hospital A stores (R HPA , S HPA , PK HPA , SK HPA ) in the medical device. to hospital A.
Step 3: Hospital A verifies  Step 1: Hospital B chooses a unique identity, HPB ID , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, HPB r , and calculates  Step 1: Hospital B chooses a unique identity, ID HPB , and sends it to the blockchain center.
Step 2: The blockchain center chooses a random number, r HPB , and calculates If the identity ID HPB is valid, the blockchain center calls the smart contract hbins as follows: and it then sends (R HPB , S HPB , PK HPB , SK HPB ) to hospital B.
Step 3: Hospital B verifies If the verification passes, then hospital B stores (R HPB , S HPB , PK HPB , SK HPB ) in the medical device.

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 and then sends (ID PAT , R PAT , T PAT ) to hospital A.
Step 2: Hospital A chooses a random number, b, calculated by and the session key Hospital A then calculates and sends (ID HPA , R HPA , T HPA , CHK PA ) to the patient.
Step 3: The patient calculates PK HPA = R HPA + H 1 (ID HPA , R HPA )PK, and the session key The patient then verifies to check the legality of hospital A. If the verification passes, the patient calls the smart contract hachk as follows: and the session key The patient then verifies and sends (ID PAT , c PAT , CHK AP ) to hospital A.
Step 4: Hospital A verifies to check the legality of the patient. If the verification passes, the session key SEK AP between the patient and hospital A is established successfully. Hospital A calls the smart contract ptchk as follows: Appl. Sci. 2020, 10, x FOR PEER REVIEW 12 of 29 Hospital A then decrypts the received message 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 to the patient.
Step 5: The patient decrypts the received message, 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 Cert HPA If the identity ID PAT is valid, the hospital A calls the smart contract mrins and ptins as follows: Appl. Sci. 2020, 10, x FOR PEER REVIEW 12 of 29 Hospital A then decrypts the received message 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 to the patient.
Step 5: The patient decrypts the received message, and sends (ID HPA , c HPA , Sig HPA ) to the patient.

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

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. Appl. Sci. 2020, 10, x FOR PEER REVIEW 13 of 29 Figure 6. The inter-hospital authentication and communication phase of the proposed scheme.
Step 1: The patient chooses a random number, c , calculated by     Step 1: The patient chooses a random number, c, calculated by and then sends (ID PAT , R PAT , T PAT2 ) to hospital B.
Step 2: Hospital B chooses a random number, d, calculated by and the session key, Hospital B then calculates and sends (ID HPB , R HPB , T HPB , CHK PB ) to the patient.
Step 3: The patient calculates PK HPB = R HPB + H 1 (ID HPB , R HPB )PK, and the session key, The patient then verifies to check the legality of hospital B. If the verification passes, the patient calls the smart contract hbchk as follows: Step 2: Hospital B chooses a random number, d , calculated by and the session key, and the session key, ( The patient then verifies Step 4: Hospital B verifies and sends (ID PAT , c PAT2 , CHK BP ) to hospital B.
Step 4: Hospital B verifies to check the legality of the patient. If the verification is passed, the session key SEK BP between the patient and hospital B is established successfully. The hospital B calls the smart contract ptchk as follows: 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 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 and then sends (ID HPB , R HPB , T HPB2 ) to hospital A.
Step 6: Hospital A chooses a random number, f , calculated by PK HPB = R HPB + H 1 (ID HPB , R HPB )PK, K AB1 = S HPA T HPB2 + f PK HPB , (53) and the session key, Hospital A then calculates and sends (ID HPA , R HPA , T HPA2 , CHK BA ) to hospital B.
Step 7: Hospital B calculates PK HPA = R HPA + H 1 (ID HPA , R HPA )PK (57) and the session key, Hospital B then verifies to check the legality of hospital A. If the verification passes, hospital B calculates and sends (ID HPB , c HPB , CHK AB ) to hospital A.
Step 8: Hospital A verifies to check the legality of hospital B. If the verification is passed, the session key SEK AB between hospital B and hospital A is established successfully. Hospital A then decrypts the received message and receives the medical record request from the patient. Hospital A then generates the encrypted medical records of the patient and sends (ID HPA , c HPA2 , Sig HPA2 ) to hospital B.
Step 9: Hospital B decrypts the received message verifies the signature, If the verification passes, and hospital B calls the smart contract mrchk as follows: to hospital B.
Step 9: Hospital B decrypts the received message (69) If the verification passes, and hospital B calls the smart contract mrchk as follows: 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 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 If the identity ID PAT is valid, hospital B calls the smart contract mrins and ptins as follows: server and generates the encrypted basic inspection report verifies the signature, and receives the encrypted basic inspection report from hospital B.

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. To analyze the proposed scheme, the following assumptions are made: P|≡ HA|⇒ ID HPA A8: HA|≡ P|⇒ ID 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: a.
Hospital A, HA, authenticates the patient, P.
We derive the following statement by M1 and the seeing rule: HA (< ID PAT , R PAT , T PAT > PK HPA , < H(SEK AP , T HPA ) > CHK AP ) (Statement 1) We derive the following statement by A2 and the freshness rule: HA ≡ #(< ID PAT , R PAT , T PAT > PK HPA , < H(SEK AP , T HPA ) > CHK AP ) (Statement 2) We derive the following statement by (Statement 1), A4, and the message meaning rule: HA|≡ P| ∼ (< ID PAT , R PAT , T PAT > PK HPA , < H(SEK AP , T HPA ) > CHK AP ) (Statement 3) We derive the following statement by (Statement 2), (Statement 3), and the nonce verification rule: HA ≡ P ≡ (< ID PAT , R PAT , T PAT > PK HPA , < H(SEK AP , T HPA ) > CHK AP ) (Statement 4) We derive the following statement by (Statement 4) and the belief rule: We derive the following statement by (Statement 5), A6, and the jurisdiction rule: We derive the following statement by (Statement 6) and the belief rule: HA|≡ P|≡ ID PAT (Statement 7) We derive the following statement by (Statement 7), A8, and the jurisdiction rule: The patient P authenticates the hospital A HA.
We derive the following statement by M2 and the seeing rule: P (< ID HPA , R HPA , T HPA > PK PAT , < H(SEK AP , T PAT ) > CHK PA ) (Statement 9) We derive the following statement by A1 and the freshness rule: P ≡ #(< ID HPA , R HPA , T HPA > PK PAT , < H(SEK AP , T PAT ) > CHK PA ) (Statement 10) We derive the following statement by (Statement 9), A3, and the message meaning rule: P|≡ HA| ∼ (< ID HPA , R HPA , T HPA > PK PAT , < H(SEK AP , T PAT ) > CHK PA ) (Statement 11) We derive the following statement by (Statement 10), (Statement 11), and the nonce verification rule: P ≡ HA ≡ (< ID HPA , R HPA , T HPA > PK PAT , < H(SEK AP , T PAT ) > CHK PA ) (Statement 12) We derive the following statement by (Statement 12) and the belief rule: We derive the following statement by (Statement 13), A5, and the jurisdiction rule: We derive the following statement by (Statement 14) and the belief rule: P|≡ HA|≡ ID HPA (Statement 15) We derive the following statement by (Statement 15), A7, and the jurisdiction rule: P|≡ ID 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 If it passes the verification, hospital A authenticates the legality of the patient. The patient authenticates hospital A by 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. Hospital B, HB, authenticates the patient, P.
We derive the following statement by M3 and the seeing rule: We derive the following statement by (Statement 21), A14, and the jurisdiction rule: We derive the following statement by (Statement 22) and the belief rule: HB|≡ P|≡ ID PAT (Statement 23) We derive the following statement by (Statement 23), A16, and the jurisdiction rule: HB|≡ ID PAT (Statement 24) d. The patient P authenticates hospital B HB.
We derive the following statement by M4 and the seeing rule: P (< ID HPB , R HPB , T HPB > PK PAT , < H(SEK BP , T PAT2 ) > CHK PB ) (Statement 25) We derive the following statement by A9 and the freshness rule: P ≡ #(< ID HPB , R HPB , T HPB > PK PAT , < H(SEK BP , T PAT2 ) > CHK PB ) (Statement 26) We derive the following statement by (Statement 25), A11, and the message meaning rule: P|≡ HB| ∼ (< ID HPB , R HPB , T HPB > PK PAT , < H(SEK BP , T PAT2 ) > CHK PB ) (Statement 27) We derive the following statement by (Statement 26), (Statement 27), and the nonce verification rule: P ≡ HB ≡ (< ID HPB , R HPB , T HPB > PK PAT , < H(SEK BP , T PAT2 ) > CHK PB ) (Statement 28) We derive the following statement by (Statement 28) and the belief rule: We derive the following statement by (Statement 29), A13, and the jurisdiction rule: We derive the following statement by (Statement 30) and the belief rule: P|≡ HB|≡ ID HPB (Statement 31) We derive the following statement by (Statement 31), A15, and the jurisdiction rule: P|≡ ID 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 (< ID HPB , R HPB , T HPB2 > PK HPA , < H(SEK AB , T HPA2 ) > CHK AB ) (Statement 33) We derive the following statement by A18 and the freshness rule: HA ≡ #(< ID HPB , R HPB , T HPB2 > PK HPA , < H(SEK AB , T HPA2 ) > CHK AB ) (Statement 34) We derive the following statement by (Statement 33), A20, and the message meaning rule: HA|≡ HB| ∼ (< ID HPB , R HPB , T HPB2 > PK HPA , < H(SEK AB , T HPA2 ) > CHK AB ) (Statement 35) We derive the following statement by (Statement 34), (Statement 35), and the nonce verification rule: HA ≡ HB ≡ (< ID HPB , R HPB , T HPB2 > PK HPA , < H(SEK AB , T HPA2 ) > CHK AB ) (Statement 36) We derive the following statement by (Statement 36) and the belief rule: We derive the following statement by (Statement 37), A22, and the jurisdiction rule: , 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 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.

Data Integrity
To ensure the integrity of the transaction data, this study uses elliptic curve cryptography to calculate the session key, SEK AP , SEK BP and SEK 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 SEK AP , SEK BP and SEK AB .
Only the legal patient or hospital A can calculate the correct session key SEK AP . The legal hospital A calculates the session key as follows: and the legal patient calculates the session key as follows: K PA1 = S PAT T HPA + aPK HPA = S PAT bP + aS HPA P = bS PAT P + S HPA aP = bPK PAT + S HPA T PAT = K AP1 K PA2 = aT HPA = abP = baP = bT PAT = K AP2 Only the legal patient or hospital B can calculate the correct session key SEK BP . The legal hospital B calculates the session key as follows: and the legal patient calculates the session key as follows: K PB1 = S PAT T HPB + cPK HPB = S PAT dP + cS HPB P = dS PAT P + S HPB cP = dPK PAT + S HPB T PAT2 = K BP1 K PB2 = cT HPB = cdP = dcP = dT PAT2 = K BP2 Only legal hospital B or hospital A can calculate the correct session key SEK AB . The legal hospital A calculates the session key as follows: and the legal hospital B calculates the session key as follows: K BA1 = S HPB T HPA2 + ePK HPA = S HPB f P + eS HPA P = f S HPB P + S HPA eP = f PK HPB + S HPA T HPB2 = K AB1 K BA2 = eT HPA2 = e f P = f eP = f T HPB2 = K AB2 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 to check the data integrity of the transmitted information. The malicious attacker cannot calculate the correct session key SEK 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 to check data integrity. Thus, malicious attackers cannot achieve their purpose by sending a modified message to hospital A.

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 SEK AP and SEK BP is changed for every communication round in order to prevent location tracking. Therefore, the proposed system achieves user untraceability and protects location privacy.

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 SEK AP , SEK BP and SEK 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.

Forward and Backward Secrecy
If a malicious attacker compromises the session key SEK AP , SEK BP and SEK 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 SEK AP , SEK BP and SEK AB for future malicious communication or use it to obtain previously transmitted messages. However, the session key SEK AP , SEK BP and SEK 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 SEK AP , SEK BP and SEK AB for future malicious communication or use it to obtain previously transmitted messages. Therefore, forward and backward secrecy is achieved in the proposed scheme.

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 shows the non-repudiation of the proposed scheme.  Table 2 shows the computation costs of the proposed scheme.

Computation Cost
Inter-Hospital Authentication and Communication Phase 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.

Communication Cost
The following table, Table 3, 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. Table 4 shows the functionality comparison of previous schemes and the proposed scheme.

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.
Author Contributions: The authors' contributions are summarized below. C.-L.C. and Y.-Y.D. made substantial contributions to the conception and design and were involved in drafting the manuscript. W.W. and H.S. acquired data and analysis and conducted the interpretation of the data. The critically important intellectual contents of this manuscript were revised by M.Z. All authors read and approved the final manuscript.
Funding: This study is supported by the Ministry of Science and Technology (MOST), Taiwan, Republic of China, under the grant MOST 108-2221-E-324-013.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations q
A k-bit prime F q A prime finite field E/F q An elliptic curve E over F q G A cyclic additive group of composite order q P A generator for the group G s A secret key of the system PK A public key of the system, PK = sP PK x , SK x x's public key and private key, issued by the blockchain center H i ( ) i th one-way hash function ID x x's identity, like a universally unique ID code r x , a, b, c, d, e, f Random numbers of the elliptic curve group S x x's elliptic curve group signature SEK xy A session key established by x and y E x (m) Use a session key x to encrypt the message m D x (m) Use a session key x to decrypt the message m S SK x (m) Use x's private key SK x to sign the message m V PK x (m) Use x's public key PK x to verify the message m c i The ith cyphertext Sig xy The signed message for parties x and y CHK x x's verified message The information between the patient and the hospital EMR The medical record established by a doctor