Authorized Shared Electronic Medical Record System with Proxy Re-Encryption and Blockchain Technology

With the popularity of the internet 5G network, the network constructions of hospitals have also rapidly developed. Operations management in the healthcare system is becoming paperless, for example, via a shared electronic medical record (EMR) system. A shared electronic medical record system plays an important role in reducing diagnosis costs and improving diagnostic accuracy. In the traditional electronic medical record system, centralized database storage is typically used. Once there is a problem with the data storage, it could cause data privacy disclosure and security risks. Blockchain is tamper-proof and data traceable. It can ensure the security and correctness of data. Proxy re-encryption technology can ensure the safe sharing and transmission of relatively sensitive data. Based on the above situation, we propose an electronic medical record system based on consortium blockchain and proxy re-encryption to solve the problem of EMR security sharing. Electronic equipment in this process is connected to the blockchain network, and the security of data access is ensured through the automatic execution of blockchain chaincodes; the attribute-based access control method ensures fine-grained access to the data and improves the system security. Compared with the existing electronic medical records based on cloud storage, the system not only realizes the sharing of electronic medical records, but it also has advantages in privacy protection, access control, data security, etc.


Background
E-health appeared in the early 21st century; it refers to the use of modern information and communication technology, to provide medical services in the health sector [1]. Electronic medical records (EMRs) is a hot topic in the field of e-health [2]. According to one survey [3], as of March 2017, 86% of provincial hospitals and 75.6% of municipal hospitals have established EMR databases; only 32% of provincial hospitals and 35.2% of municipal hospitals have established electronic medical record information platforms. Although the goal of establishing electronic medical record systems has been achieved throughout the world, there is not enough medical record data sharing.
Electronic medical records (EMRs) involve systematic collections of patient-and population-based health data, which are stored electronically in digital format [4,5]. Effective EMR implementation and networking can save more than USD 81 billion annually, by improving medical efficiency and security [6].
At present, there are problems with the use of EMRs [7,8]. Firstly, data stored in the centralized system databases face many risks, such as hacker intrusions, data stealing, and artificial tampering of data that will endanger data security. Secondly, thousands of medical record data are saved by each regional hospital, separately, and unsystematic 1. The electronic medical record sharing system integrates electronic medical record data between hospitals so that it can be used and browsed across different hospitals, ensuring the availability and accuracy of electronic medical record data.
2. The establishment of a reasonable and effective electronic medical record sharing system facilitates a doctor's access to a patient's medical history, significantly reducing the costs associated with a patient's repeat examinations, and improving the efficiency of treatment.
3. Patients benefit from the sharing of electronic medical records because they can directly query their medical records, examination reports, and drug use in the hospital on the relevant networks. 4. The sharing of electronic medical records contributes to public health safety. The sharing of electronic medical records aids in the monitoring of the epidemic situation, allowing for early prevention and treatment of the epidemic situation, preventing the spread of large-scale infection, and preventing the occurrence of public health emergencies.
However, we may come across some potential threats and attacks while using the system. To make the proposed scheme more effective and safe, we analyze potential threats and attacks. The threat models and knowing attacks are as follows: 1. Data integrity issue [19].
In an insecure network environment, any information transmitted is vulnerable to tampering attacks, so that the data received by the receiver is not the original data. Data integrity is threatened. Therefore, it is necessary to ensure the integrity of the transmission data and protect it from tampering during transportation.
2. Illegal access issue [20]. Unauthorized access refers to the unauthorized use of network resources or the use of network resources in an unauthorized way. In this scheme, users are not allowed to operate other people's data in an unauthorized way.
3. Forgery and tampering [21]. If an attacker forges or tampers with the data stored in the shared electronic medical record system, it will have a significant impact on the entire system, resulting in massive data loss and errors. As a result, leveraging the non-tampering ability of the blockchain could significantly improve data security.  4. Replay Attack [22]. Replay attack means that the same information or data are repeatedly sent twice or more. If the receiver does not take relevant measures and continuously receives information, it would not be able to effectively identify that the data were received, which would lead to replay vulnerabilities. 5. Collusion Attack [23].
In the proxy re-encryption scheme, if the proxy colludes with the authorized party, the data and encryption key of the authorizer may be decoded. Therefore, in a proxy re-encryption scheme, we must verify whether the scheme can resist collision attacks.
Based on the above situation, this study proposes an EMR data sharing mechanism based on the advantages of anti-tampering and traceability of the consortium blockchain and the security authorization characteristics of proxy re-encryption. The proposed scheme, such that hospitals join the medical consortium blockchain, store the EMR data generated by patients in the consortium blockchain service center, and protect the data security according to the relevant national laws and regulations. At the same time, the chaincode functions are used to realize the EMR, and the proxy re-encryption is used for sharing and authorization. Furthermore, we write the attributes of users and devices into the digital certificate to provide different data access functions for users and devices with different attributes.
The rest of this paper is organized as follows. In Section 2, we review some preliminaries. The system model and detailed design are introduced in Sections 3 and 4, respectively. The analysis of the system is given in Section 5. Finally, Section 6 concludes the paper.

Blockchain and Smart Contract (Chaincode)
Blockchain is a kind of chain data structure that combines data blocks with time sequences [24]. A smart contract was a concept proposed by Nick Szabo in the 1990s [25], which is almost the same age as the internet. He defines a smart contract as a set of commitments defined in digital form, including agreements in which contract participants can execute these commitments automatically [26]. In this article, we refer to smart contracts as chaincodes, which are programs that are deployed and run on the blockchain network. The chaincode presets some conditions and rules to trigger the execution of the chaincode under certain events and conditions. The goal of the chaincode is to generate ledger data on the blockchain, which means that all operations on the blockchain data are completed by the chaincode. Moreover, security policies (including data encryption and decryption, data signature and signature verification, access control) will be automatically invoked through chaincodes.

Blockchain of Things
In ordinary internet of things devices [27], there are problems, such as poor data privacy and difficulty accessing data safely. The blockchain will have a significant impact on the internet of things due to its peer-to-peer, open and transparent communication, secure communication, difficulty to tamper with, and multi-party consensus. The encryption mechanism and data storage characteristics of blockchain just meet the security requirements of the internet of things. The integration of blockchain and the internet of things is called the blockchain of things (BCoT) in academia.

QR Code
A QR code [28], a kind of readable bar code, can identify the binary data recorded in it and obtain the information contained in it by scanning the QR code. A QR code's characteristics includes the following: it has large information capacity, high decoding reliability, and adopts certain security encryption measures. A QR code is widely used in near-field secure data exchange.

Elliptic Curve Digital Signature Algorithm (ECDSA)
In an elliptic curve system, we need to use a much shorter key than RSA to achieve the same security strength [29]. The elliptic curve digital signature algorithm (ECDSA) is the elliptic curve analog of the digital signature algorithm [30].
We assume that the sender sends M and signs M to a receiver, and the receiver needs to verify the signature to ensure the correctness of M. We assume that the sender has already generated their own key-pairs, G(x, y) is the base point on the elliptic curve E/F n (based on P256 curve), and satisfies nG = 0, n is a big prime number and is also the order of G.
Select a random number Sk A ∈ [1, n − 1] as a private key, and a public key is Pk A = Sk A G. Suppose the sender's key pair is (Sk A , Pk A ).
(3) Calculate S = (SHA(M) + Sk A x 1 )·r −1 according to random number r, private key Sk A , and SH A(M), which is the secure hash value of message M. (4) Send message M, and signature (R, S) to the receiver.
(2) Hash SH A(M) according to message M.
(3) Use the sender's public key Pk A to calculate SH A(M)G/S + x 1 Pk A /S and compare it, if it is equal to R: If it is equal, the signature verification is successful. For reading convenience, in the following sections, we use Sig SkX (·) to represent the signature generation and Sign X to represent the signature (R, S); we use Ver PkX (·) to represent the signature verification.

The Algorithm Elliptic Curve Based Proxy Re-Encryption
In elliptic curve based proxy re-encryption [31], let E be an elliptic curve over a limited field F q , where q is a large prime number, and G is a point on the elliptic curve E of order n. Let G 1 , G 2 be two multiplicative cyclic groups of prime modulo n. Let e : G 1 × G 1 → G 2 be a bilinear map [32], z = e(G 1 , Key-Generation: let private key a ∈ Z * n and a public key Pk a = aG ∈ point on E. Encryption: generate an arbitrary number r ∈ Z * n , and output C a = (A, B)= (r·Pk a , z r G + P m ), where P m = f (m) [33].
Re-Key-Generation: the re-encryption key rk a→b = a −1 bG is generated by private key a and public key bG.
Re-Encryption: given rk a→b and message C a computes C b = (A , B ) =(e(raG, a −1 bG), z r G + P m ) = (z rb , z r G + P m ).
Decryption: (1) given ciphertext C a and private key a, output P m =B − (e(A, Sk −1 a G))G; (2) given C b and private key Sk b , compute For reading convenience, in the next section, we use Enc PkX (·) for Encryption, reKeyGen(·) for Re-Key-Generation, reEnc A→B (·) for Re-Encryption, and Dec SkX (·) for Decryption. 1. User registration phase: all users (including patients and doctors) must register in the CBSC and obtain the private key and the corresponding X.509 digital certificate. The digital certificate contains the user's role attribute information (doctors, patients) and the user's public key. 2. Device registration phase: the scanner has to register in CBS to obtain the private key and the corresponding X.509 digital certificate. The digital certificate contains the hospital information and public key of the equipment. 3. Appointment and EMR generation phase: the patient makes an appointment to see doctor A and chains up the appointment information to CBSC. Then doctor A obtains the appointment information from CBSC and makes a diagnosis. After the diagnosis, doctor A generates and chains up the encrypted EMR to CBSC. 4. The generation of re-encryption key and access voucher phase: the patient authorizes doctor B to view his/her historical EMR through proxy re-encryption and blockchain-network scanners. Firstly, the patient calculates the re-encryption key through his/her private key and doctor B's public key and submits it to CBSC. CBSC returns an authorization voucher to the patient. Then, the patient displays the voucher to doctor B in the form of a QR code. 5. Scanning of access voucher and acquisition of re-encrypted EMR phase: the scanner scans the QR code to obtain the voucher, and requests the re-encrypted EMR through the voucher from CBSC, which uses the re-encryption key to convert the historical EMR into the re-encrypted EMR. Finally, doctor B obtains the re-encrypted EMR through the scanner and decrypts it through the private key.

The Consortium Blockchain Service Center Architecture
CBSC refers to embedding the blockchain framework into the cloud-computing platform, making use of the deployment and management advantages of cloud service infrastructure to provide users with a convenient and high-performance blockchain ecological environment and ecological supporting services. In this paper, our CBSC architecture is shown in Figure 2, which is divided into the application layer, service layer, and consortium blockchain layer. In the proposed framework, there are four roles in the scheme.
(1) Consortium blockchain service center (CBSC): the distributed cloud storage and the peer-to-peer network of each hospital organization node constitute the consortium blockchain service center. In fact, the consortium blockchain service center is a decentralized network service. For the convenience of understanding, we call it CBSC. The consortium blockchain service center implements identity management and digital certificate issuance, and chaincode operation, data storage, and data legitimacy verification. (2) Patient (P): the patient can make an appointment with a doctor. The patient uses the voucher and the scanner to authorize the doctor to view the patient's historical medical records. The patient authorizes the doctor to view his/her historical medical record through the combination of vouchers generated by proxy re-encryption and scanner. (3) Doctor (D): the doctor obtains the patient's appointment information through the CBSC and generates the EMR with the encrypted fields by the patient's public key after diagnosis and stores it in CBSC. (4) Scanner (SC): the scanner is used to scan the voucher code presented by the patient and request CBSC to obtain the re-encrypted ciphertext data through the voucher, which CBSC will convert the ciphertext through the re-encryption key.

1.
User registration phase: all users (including patients and doctors) must register in the CBSC and obtain the private key and the corresponding X.509 digital certificate. The digital certificate contains the user's role attribute information (doctors, patients) and the user's public key.

2.
Device registration phase: the scanner has to register in CBS to obtain the private key and the corresponding X.509 digital certificate. The digital certificate contains the hospital information and public key of the equipment.

3.
Appointment and EMR generation phase: the patient makes an appointment to see doctor A and chains up the appointment information to CBSC. Then doctor A obtains the appointment information from CBSC and makes a diagnosis. After the diagnosis, doctor A generates and chains up the encrypted EMR to CBSC.

4.
The generation of re-encryption key and access voucher phase: the patient authorizes doctor B to view his/her historical EMR through proxy re-encryption and blockchain-network scanners. Firstly, the patient calculates the re-encryption key through his/her private key and doctor B's public key and submits it to CBSC. CBSC returns an authorization voucher to the patient. Then, the patient displays the voucher to doctor B in the form of a QR code.

5.
Scanning of access voucher and acquisition of re-encrypted EMR phase: the scanner scans the QR code to obtain the voucher, and requests the re-encrypted EMR through the voucher from CBSC, which uses the re-encryption key to convert the historical EMR into the re-encrypted EMR. Finally, doctor B obtains the re-encrypted EMR through the scanner and decrypts it through the private key.

The Consortium Blockchain Service Center Architecture
CBSC refers to embedding the blockchain framework into the cloud-computing platform, making use of the deployment and management advantages of cloud service infrastructure to provide users with a convenient and high-performance blockchain ecological environment and ecological supporting services. In this paper, our CBSC architecture is shown in Figure 2, which is divided into the application layer, service layer, and consortium blockchain layer. Application layer and service layer: the application layer provides the EMR function service for patients, doctors, and scanners. It can interact with the background blockchain network via the API provided by the HTTPS server from the service layer. The service layer plays the role of middleware. Besides receiving and processing HTTPS requests from applications, the service layer must interact with the consortium blockchain layer directly to achieve the business logic by invoking a specific chaincode. In this way, the service layer can decouple applications and the data layer.
Consortium blockchain Layer: the consortium blockchain layer takes the Hyperledger Fabric technology as the core to provide blockchain services to users. Hyperledger Fabric technology is a new distributed infrastructure and computing mode, which uses chained data structure to verify and store data, uses distributed node consensus algorithm to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses chaincode composed of automatic script code to program and operate data. In fabric, the order nodes use the consensus algorithm to sort the data and packages into blocks. Organizations that join the alliance chain verify and store data through peers.

X.509 Digital Certificate
CBSC uses X.509 digital certificate to identify the identity of users and devices in Application layer and service layer: the application layer provides the EMR function service for patients, doctors, and scanners. It can interact with the background blockchain network via the API provided by the HTTPS server from the service layer. The service layer plays the role of middleware. Besides receiving and processing HTTPS requests from applications, the service layer must interact with the consortium blockchain layer directly to achieve the business logic by invoking a specific chaincode. In this way, the service layer can decouple applications and the data layer.
Consortium blockchain Layer: the consortium blockchain layer takes the Hyperledger Fabric technology as the core to provide blockchain services to users. Hyperledger Fabric technology is a new distributed infrastructure and computing mode, which uses chained data structure to verify and store data, uses distributed node consensus algorithm to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses chaincode composed of automatic script code to program and operate data. In fabric, the order nodes use the consensus algorithm to sort the data and packages into blocks. Organizations that join the alliance chain verify and store data through peers. CBSC uses X.509 digital certificate to identify the identity of users and devices in CBSC. The most basic information of the X.509 digital certificate includes the public key, the owner information of the public key, and the digital signature of CBSC. The "role" attributes in the digital certificate indicates the registered user or device attribute. If the value of "role" is "D", it is the doctor user certificate; if the value of "role" is "P", it is the patient certificate; if the "role" value is "S", it is the scanner device certificate. The scanner certificate is uniquely identified by the "Sid" attribute of the scanner; in the user certificate, the "Uid" attribute is the user's identification number and is used as the unique identifier of the use. For the patient, "Uid" means "Pid"; for the doctor, "Uid" means "Did". Patients can use the public key in the doctor's certificate combined with their own private key to realize the proxy re-encryption of data and then realize the access control of data. The examples of the digital certificate are as Figures 3 and 4 shown below.

Deployment and Initialization of the Chaincode
The chaincode is event-driven, with state storage and programs running on the

Deployment and Initialization of the Chaincode
The chaincode is event-driven, with state storage and programs running on the blockchain. The user realizes data access on CBSC through the chaincode. In this scheme,

Deployment and Initialization of the Chaincode
The chaincode is event-driven, with state storage and programs running on the blockchain. The user realizes data access on CBSC through the chaincode. In this scheme, the chaincode data structure and function of the key information for the proposed architecture we define as Figure 5 follows, and Table 1 shows the detailed introduction of chaincode data structure. In particular, the field "state" of the appointment is divided into two states, namely "CREATE" and "FINISH". When an appointment is created, the patient needs to sign it and set the state to "CREATE". After the doctor's diagnosis, he/she needs to sign and set the state to "FINISH". In EMR, "EncryptedSickDetail" and "EncryptedDrugDetail" are encrypted fields. When authorizing EMR by using proxy re-encryption, these two fields are re-encrypted. We define the access data structure for access control, in which the "ReEncryptionkey" field is used to re-encrypt the EMR. Similarly, the "state" of access has three states. When the patient creates an access, the state is "CREATE". When the scanner scans the voucher and obtains the re-encrypted EMR, the state is "SCAN". When the doctor obtains the EMR, the state is "FINISH".

Doctor
The doctor data structure represents the role of the doctor user, where Did is the doctor's ID, the field DName is the doctor's name, the Phone field refers to the doctor's mobile phone number, the field HospitalName refers to the name of the doctor's Hospital, and the Hospital Id field refers to the code of the doctor's hospital. These fields form the basic information of the doctor.

Patient
Patient data structure represents the role of the patient-user, where Pid is the patient's ID, the field PName is the patient's name, the field Phone refers to the patient's mobile phone number, the field Address refers to the name of the patient's home address.

Scanner
Scanner data structure refers to the basic information of the scanner equipment connected to the network, the Sid field refers to the equipment code, the belongto field refers to the organization, the Sname field refers to the equipment model name, and the field activationTime refers to the activation time of the scanner equipment.

Appointment
Appointment data structure stores the information of the patient's appointment with the doctor. The BeginTime field refers to the creation time of the appointment, EndTime refers to the end time of the appointment, the Pid field refers to the patient's ID, Did is the doctor's ID, PatientSignature refers to the patient's signature, DoctorSignature refers to the doctor's signature, the state field refers to the current state of the appointment EMR EMR data structure refers to the electronic medical record, which Pid refers to the patient's ID, Did refers to the doctor's ID, createTime refers to the creation time of the EMR, the EncryptedSickDetail field refers to the encrypted sick detail, the EncryptedDrugDetail field refers to the encrypted drug detail, and doctorSignature refers to the signature of the diagnostic doctor

Access
Access data structure records the information that the patient authorizes the doctor to view the historical EMR. Pid refers to the patient's ID, Did refers to the doctor's ID, BeginTime refers to the authorization start time, EndTime refers to the authorization end time, reEncryptionKey refers to the re-encryption key, PatientSignature refers to the patient's signature, scannerSignature refers to the scanner's device signature, DoctorSignature refers to the doctor's signature, and state refers to the current status of access.
tion, these two fields are re-encrypted. We define the access data structure for access control, in which the "ReEncryptionkey" field is used to re-encrypt the EMR. Similarly, the "state" of access has three states. When the patient creates an access, the state is "CRE-ATE". When the scanner scans the voucher and obtains the re-encrypted EMR, the state is "SCAN". When the doctor obtains the EMR, the state is "FINISH".

Doctor
The doctor data structure represents the role of the doctor user, where Did is the doctor's ID, the field DName is the doctor's name, the Phone field refers to the doctor's mobile phone number, the field HospitalName refers to the name of the doctor's Hospital, and the HospitalId field refers to the code of the doctor's hospital. These fields form the basic information of the doctor.

Patient
Patient data structure represents the role of the patient-user, where Pid is the patient's ID, the field PName is the patient's name, the field Phone refers to the patient's mobile phone number, the field Address refers to the name of the patient's home address.

Scanner
Scanner data structure refers to the basic information of the scanner equipment connected to the network, the Sid field refers to the equipment code, the belongto field refers to the organization, the Sname field refers to the equipment model name, and the field activationTime refers to the activation time of the scanner equipment.

Appointment
Appointment data structure stores the information of the patient's ap-   Table 2 shows the notations and their meaning.  rk A→B Proxy re-encryption key generated by A and B Ver PkX (Sign X ) The verification function, use the X's public key Pk X to verify the correctness of the signature Sign X Enc PkX (·)

Notation
The function of encryption with Pk X reKeyGen(·) The generation of re-encryption keys from A to B reEnc A→B (·) The function of re-encrypting the ciphertext of A into the ciphertext that B can decrypt.

Dec SkX (·)
The function of decryption with the key Sk X

User Registration Phase
Users (including patients and doctors) should register with CBSC. CBSC will generate a private key and digital certificate (including public key) for users, sign the private key and digital certificate, and issue them to users. After the user obtains the private key and digital certificate, the user will verify the correctness of the signature. After the signature is verified successfully, the user will call the chaincode to store the user details in CBSC. The flow chart of the user registration phase is shown in Figure 6.

•
Step 1: the user chooses the attributes role and Uid to request for registration in CBSC.

•
Step 2: when the CBSC receives the request, it selects a random number as the private key Sk U and uses it with the generator for the elliptic group G to compute a public key Pk U = Sk U G.
Then the CBSC signs the signature Sign CBS as follows:

•
Step 3: CBSC generates digital certificates Cert U for users and sends Sk U and Cert U to users. • Step 4: after receiving the data, the user will verify the correctness of the signature. If it is correct, the certificate is legal.
and the user will store the private key Sk U and certificate Cert U . • Step 5: the user selects the user information In f o U . For a patient, In f o U means (PName||Phone||Pid||Address||Phone||CreateTime) , as shown in the above patient data structure; for doctors, In f o U = (DName||Phone ||DId||HospitalName||Hospital Id|| CreateTime) as shown in the above doctor data structure. Then the user signs (In f o U ||timestamp) and chain up (In f o U ||timestamp||Sign U1 ) to the CBSC.

•
Step 6: when the CBSC receives the data from the user, it will verify the signature Sign U1 If it holds, then the CBSC saves the data. The chaincode of the pseudo-code of user registration is shown in Algorithm 1.

Device Registration Phase
The scanner is registered in CBSC under the setting of person. Scanner devices are also registered in CBSC. CBSC will generate a private key and device digital certificate for the scanner, sign the private key and digital certificate, and issue them to devices. After the scanner obtains the private key and digital certificate, it will verify the correctness of the signature. After the signature is verified successfully, the scanner will call the chaincode automatically to store the device details in CBSC. The flow chart of the device registration phase is shown in Figure 7.

•
Step 1: the scanner sets the attributes role and Sid to request for registration in CBSC.

Device Registration Phase
The scanner is registered in CBSC under the setting of person. Scanner devices are also registered in CBSC. CBSC will generate a private key and device digital certificate for the scanner, sign the private key and digital certificate, and issue them to devices. After the scanner obtains the private key and digital certificate, it will verify the correctness of the signature. After the signature is verified successfully, the scanner will call the chaincode automatically to store the device details in CBSC. The flow chart of the device registration phase is shown in Figure 7.

•
Step 1: the scanner sets the attributes role and Sid to request for registration in CBSC.

•
Step 2: when the CBSC receives the request, it selects a random number as the private key Sk SC and uses it with the generator for the elliptic group G to compute a public key Pk SC = Sk SC G for the scanner. Then the CBSC signs the signature Sign CBSC2 as follows: • Step 3: CBSC generates device digital certificates Cert SC and sends Sk SC and Cert SC to users. Cert SC = (role||Sid||Pk SC ||timestamp||Sign CBSC2 ) • Step 4: after receiving the data, the scanner will verify the correctness of the signature. If it is correct, the certificate is legal.
(role Sid Pk SC timestamp) ? = Ver PkCBSC (Sign CBSC2 ) (8) and the scanner will store the private key Sk SC and certificate Cert SC . • Step 5: the scanner set up the basic information In f o SC and signs In f o SC with Sk SC , and chain up (In f o SC ||timestamp||Sign SC1 ) to the CBSC. • Step 6: when the CBSC receives the data from the scanner, it will verify the signature Sign SC1 (In f o SC timestamp) ?
If it holds, then the CBSC saves the data. The chaincode of the pseudo-code of device registration is shown in Algorithm 2.

•
Step 4: after receiving the data, the scanner will verify the correctness of the signature. If it is correct, the certificate is legal.

•
Step 6: when the CBSC receives the data from the scanner, it will verify the signature

Appointment and EMR Generation Phase
In this phase, the patient makes an appointment to see the doctor and chains up the appointment information to the CBSC. Then doctor A obtains the appointment information from CBSC and makes a diagnosis. After diagnosis, doctor A generates and stores an encrypted EMR in CBSC. The flow chart of appointment and EMR generation is shown in Figure 8.

Appointment and EMR Generation Phase
In this phase, the patient makes an appointment to see the doctor and chains up the appointment information to the CBSC. Then doctor A obtains the appointment information from CBSC and makes a diagnosis. After diagnosis, doctor A generates and stores an encrypted EMR in CBSC. The flow chart of appointment and EMR generation is shown in Figure 8.

•
Step 1: the patient sets the appointment data fields and sets the field "state" = "CRE-ATE", then signs them with the patient's private key Sk P , Then sends (appointment||Sign P1 ||timestamp) to CBSC.

•
Step 2: when CBSC receives the data, it will get the data fields from appointment and verify the data signature, (BeginTime EndTime Pid Did state timestamp) ?
If holds, CBSC will save the data.

•
Step 3: Doctor A requests the appointment form; the state field value is "CREATE" in CBSC, Then requests to CBSC with parameters (Sign D1 ||Did||state||timestamp) • Step 4: upon receiving the request, CBSC will verify the correctness of the signature, If it holds, then the appointment will be found according to (Did||state) , and the appointment will be signed.

•
Step 5: after receiving the data, doctor A will verify the correctness of the data, If it is held, the patient's certificate is requested according to the patient's Pid.

•
Step 6: when CBSC receives doctor A's request, it sends the patient's digital certificate Cert P to doctor A, and doctor A obtains the patient's public key Pk P from the patient's digital certificate.

•
Step 7: after the diagnosis, doctor A will generate the EMR for the patient and encrypt the EncryptedSickDetail (the encrypted sick detail filed) and EncryptedDrugDetail (the encrypted drug detail filed) fields in the EMR with the patient's public key.

•
Step 8: when CBSC receives doctor A's data, it will verify the correctness of the signature.
If the signature is correct, it will store the EMR and update the "state" of the appointment. Algorithms 3 and 4 show the appointment generation and EMR generation respectively.

The Generation of Re-Encryption Key and Access Voucher Phase
In this phase, the patient will combine his private key with the public key of doctor B to generate the re-encryption key and send it to CBSC. After verification, CBSC will return the access voucher to the patient. The patient displays the access voucher to doctor B in the form of a QR code. Figure 9 shows the data flow in this phase.
Step 1: The patient requests doctor B's certificate Cert D from CBSC through doctor B's ID Did.
Step 2: when CBSC receives the request, it will verify the signature Sign P3 , If it holds, then return doctor B's certificate Cert D .
Step 3: the patient gets doctor B's public key Pk D from Cert D , then generates the re-encryption key rk P→D . rk P→D = reKeyGen(Sk P, Pk D ) (25) Then the patient sets the "state" = "CREATE" in access, signs the fields of access, and forms access data.
Step 5: when the patient receives the data, the signature will be verified, If it holds, the voucher QR code will be generated and be shown to doctor B. Algorithm 5 shows the generation of the registration of the re-encryption key and access voucher.

Scanning of Access Voucher and Acquisition of Re-Encrypted EMR Phase
In this phase, the patient authorizes doctor B to view their historical EMR through proxy re-encryption and scanner.
Step 1: doctor B scans the QR code with the scanner and generates the signature The scanner requests the data in CBSC ( | | | | ) SC voucher timestamp Sign .
Step 2: after receiving the request, CBSC first verifies the correctness of the signature,

Scanning of Access Voucher and Acquisition of Re-Encrypted EMR Phase
In this phase, the patient authorizes doctor B to view their historical EMR through proxy re-encryption and scanner.
Step 1: doctor B scans the QR code with the scanner and generates the signature The scanner requests the data in CBSC (voucher||timestamp||Sign SC ) .
Step 2: after receiving the request, CBSC first verifies the correctness of the signature, If it holds, CBSC queries the access according to acid, hashes access, and compares it with the digest, digest ? = SH A(access). If it is correct, update the state field access to "SCAN" and add the scanner's signature to access.
Then CBSC re-encrypts the encrypted field in EMR and sends it to doctor B through the scanner.
Step 3: after receiving the data, doctor B will verify the signature.
If it is correct, decrypt the data, update the "state" file to "FINISH" in access and signs, Request to update "state" field and add doctor B's signature into access to CBSC.
Step 4: when CBSC receives the data, it will verify the signature Sign D4 , if holds, it will update the "state" field of access to "FINISH", and add doctor B's signature to access. access = (Acid||Pid||Did||BeginTime||EndTime||rk P→D ||state||Sign P3 ||Sign SC ||Sign D4 ) (45) Figure 10 shows the data flow; Algorithm 6 shows the chaincode in this phase.

Data Integrity Analysis
In order to protect the integrity and security of the data, this paper uses an elliptic curve encryption algorithm (ECDSA) to sign the data.
Taking the user registration phase's signature as an example, the verification process of the signature CBSC Sign is as follows: When E1 equals E2, the signature verification is correct, which can prove the integrity of the data. Once the data are tampered with, then E1 will not match E2. In this way, the integrity of the data are guaranteed.

Data Integrity Analysis
In order to protect the integrity and security of the data, this paper uses an elliptic curve encryption algorithm (ECDSA) to sign the data.
Taking the user registration phase's signature as an example, the verification process of the signature Sign CBSC is as follows: Because Sign CBSC = (R CBSC , S CBSC ) = (rG, r + hash(role||Uid||Pk U ||timestamp||R CBSC )Sk CBSC ) ; therefore, the verification is as follows: When E1 equals E2, the signature verification is correct, which can prove the integrity of the data. Once the data are tampered with, then E1 will not match E2. In this way, the integrity of the data are guaranteed.
Scene: the malicious attacker intercepts the information transmitted from CBSC to the user and sends the modified information to the user. Analysis: the attacker will not succeed. The user will verify the integrity of the data: (role Uid Pk U timestamp) ?
Because the attacker cannot obtain CBSC's private key, and if the data are modified, the signature verification will be incorrect, so the attacker will not be able to achieve the purpose of sending the modified data to the user.

Tamper-Resistant
Consortium blockchain technology can ensure that the chain-up information will not be tampered with. All of the chained data stored in a block will be constructed into a binary tree structure of the Merkle tree structure. As shown in Figure 11 below, the hash value between two data records in the Merkle tree will be directly concatenated as the input of the next binary tree. In this way, if an attacker attempts to change any of the data records, the root node of the Merkle tree will change greatly due to the characteristics of the SHA-256 encryption hash, so that other participants will find that the content has been changed when they verify the block information.
Scene: the malicious attacker intercepts the information transmitted from CB the user and sends the modified information to the user.
Analysis: the attacker will not succeed. The user will verify the integrity of the ( || || || )? ( )

U C B S C PkCBSC role Uid Pk timestamp Ver Sign
Because the attacker cannot obtain CBSC's private key, and if the data are mod the signature verification will be incorrect, so the attacker will not be able to achie purpose of sending the modified data to the user.

Tamper-Resistant
Consortium blockchain technology can ensure that the chain-up information w be tampered with. All of the chained data stored in a block will be constructed binary tree structure of the Merkle tree structure. As shown in Figure 11 below, the value between two data records in the Merkle tree will be directly concatenated input of the next binary tree. In this way, if an attacker attempts to change any of th records, the root node of the Merkle tree will change greatly due to the characteris the SHA-256 encryption hash, so that other participants will find that the content ha changed when they verify the block information.

Data Security Sharing and Access Control
In the process of authorizing the patient to share the historical EMR with the d the proxy re-encryption algorithm is used to convert the original ciphertext into a c text that can be decrypted by the doctor's private key. When the doctor wants to vie patient's historical medical record, the patient will generate the re-encryption key generated by the patient's private key P sk and the doctor's public key D Pk , and gen access data. Besides, when the users (including patients and doctors) and devices are regis we write the role attribute into the user or device's digital certificate (where the pa role data are "P", the doctor's role attribute is "D", and the scanner device's role att is "S"). When the user or scanner calls the chaincode to access data, the chaincod obtain the attribute value in the user or device's digital certificate firstly, Dif chaincode functions and data access are provided according to different attribute v Table 3 shows the attribute-based access control in this paper.

Data Security Sharing and Access Control
In the process of authorizing the patient to share the historical EMR with the doctor, the proxy re-encryption algorithm is used to convert the original ciphertext into a ciphertext that can be decrypted by the doctor's private key. When the doctor wants to view the patient's historical medical record, the patient will generate the re-encryption key rk P→D generated by the patient's private key sk P and the doctor's public key Pk D , and generate access data.
Access specifies the usage time (BeginTime and EndTime) of the re-encryption key rk P→D and uses signature and state to ensure the authenticity and usage record of the data.
Besides, when the users (including patients and doctors) and devices are registered, we write the role attribute into the user or device's digital certificate (where the patient's role data are "P", the doctor's role attribute is "D", and the scanner device's role attribute is "S"). When the user or scanner calls the chaincode to access data, the chaincode will obtain the attribute value in the user or device's digital certificate firstly, Different chaincode functions and data access are provided according to different attribute values. Table 3 shows the attribute-based access control in this paper.

Blockchain of Things (BCoT)
In this paper, the voucher scanner will be connected to the blockchain. The blockchainnetworking scanner will realize the data interaction with the blockchain network through the chaincode (smart contract). Once the chaincode reaches the trigger condition, it will be automatically executed and cannot be tampered with; and the attribute access control is used to specify the chaincode functions that can be accessed by the blockchain-networking scanner. It ensures the device's secure access to blockchain data.

Resisting Replay Attack
Scene: the information transmitted between sender and receiver might be intercepted by malicious attackers. The attacker mimics the legitimate sender and then sends the same message to the target receiver again.
Analysis: because all information transmitted between sender and receiver is protected by ECDSA, and timestamp verification is added, the attacker cannot accurately timestamp parameters, so the attack will fail because the signature verification will fail. Since the information sent after each round will be changed, the same information cannot be sent twice. Therefore, a replay attack cannot succeed in this scheme.

Resisting Collusion Attack
Scene: suppose the doctor and the blockchain center (proxy) conspire to obtain the patient's private key.
Analysis: in this scheme, we use the proxy re-encryption scheme, which is collusion resistant. In the phase when the patient authorizes the doctor to view the patient's historical medical record, doctor B's public key Pk D is used to calculate the re-encryption key rk P→D through Pk D and the patient's private key Sk P .
CBS will convert the encrypted fields in EMR into data that can be decrypted by Sk D through rk P→D . In the whole process, unless the patient exposes his private key, the doctor and the blockchain center (proxy) will not be able to obtain the patient's private key in collusion.

Man-in-the-Middle Attack
Scene: the attacker intercepts the transmitted data and then modifies the intercepted message and sends the modified message to the destination.
Analysis: all signatures in the proposed scheme contain a timestamp, and the scheme uses public-key cryptography as well as public and private keys. Therefore, the public key is used to encrypt the data, and the private key is used to sign the data. When the signature involves the private key, the attacker cannot modify the signature or the timestamp. Therefore, they cannot proceed with a man-in-the-middle attack because it is impossible to successfully modify the message.

Discussion
We test the performance of the blockchain service through the experimental simulation of the mentioned scheme in the following cluster host, as shown in Table 4: The consortium blockchain service configuration is shown in Figure 12: Sensors 2021, 21, x FOR PEER REVIEW 23 of 27

Discussion
We test the performance of the blockchain service through the experimental simulation of the mentioned scheme in the following cluster host, as shown in Table 4: Table 4. Experimental environment configuration.

Configuration
Detail CPU 4-core CPU Intel ® Xeon ® Skylake 6133 Memory 8G Network 4 Gbit/s SSD 60 GB The consortium blockchain service configuration is shown in Figure 12:

Send Rate
Caliper is a blockchain performance-testing framework that allows users to test different blockchain solutions using custom use cases, obtaining a set of performance test results. In this scheme, we use the caliper to test the performance of chaincode in five phases, and the results are shown in the figure below. We use 5665 transactions to test, and the sending rate is shown in Figure 13.

Send Rate
Caliper is a blockchain performance-testing framework that allows users to test different blockchain solutions using custom use cases, obtaining a set of performance test results. In this scheme, we use the caliper to test the performance of chaincode in five phases, and the results are shown in the figure below. We use 5665 transactions to test, and the sending rate is shown in Figure 13.

Discussion
We test the performance of the blockchain service through the experimental simulation of the mentioned scheme in the following cluster host, as shown in Table 4: Table 4. Experimental environment configuration.

Configuration
Detail CPU 4-core CPU Intel ® Xeon ® Skylake 6133 Memory 8G Network 4 Gbit/s SSD 60 GB The consortium blockchain service configuration is shown in Figure 12:

Send Rate
Caliper is a blockchain performance-testing framework that allows users to test different blockchain solutions using custom use cases, obtaining a set of performance test results. In this scheme, we use the caliper to test the performance of chaincode in five phases, and the results are shown in the figure below. We use 5665 transactions to test, and the sending rate is shown in Figure 13.

System Resource Consumption
The consumption of system resources is as follows. In the simulation experiment of this scheme, we set up two organization nodes, and each organization node consists of a peer node. At the same time, we set the order node, and its system resource consumption is shown in Table 5 below.

The Function Comparison with Other Works
On the subject of patient data confidentiality, Yup et al. [34] investigated the use of blockchain technology in healthcare intelligence. The healthcare data gateway was created to ensure privacy and data access controls were proposed. Liang et al. [35] used blockchain technology to develop a mobile-based healthcare record sharing system, proposing a secure user-centric approach for access control and privacy via a channel formation scheme. Using blockchain, Sun et al. [36] proposed a distributed attribute-based signature scheme for medical systems and a record sharing protocol based on blockchain with supporting algorithms. Using distributed ledger technology, Yang and Li [37] developed an electronic medical record security architecture that improved interoperability between different organizations. The proposed scheme aims to establish a secure electronic medical record sharing system using blockchain smart contracts and cryptography algorithms. Table 6 below compares this work to other related works. The computation cost of the proposed scheme is shown in Table 7.

Communication Costs
The communication performance of the proposed scheme in the different networks is shown in Table 8.
L Cert is the length of the certificate (5312 bits), L In f oU is the length of In f o U (192 bits), L In f oSC is the length of In f o SC (128 bits), L Sign is the length of the signature (576 bits), L Sk is the length of the private key (125 bits), L Ap is the length of the appointment data structure (736 bits), L EMR is the length of the electronic medical record data (768 bits), L Ac is the length of access (800 bits), and L Other is the length of other message data (32 bits). Notes: T P : polynomial function operation; T Cmp : comparison operation; T Enc : symmetric encryption operation; T Dec : symmetric decryption operation; T Sig : signature operation; T RkGen : re-encrypt key operation; T RkEnc : re-encryption operation.

Conclusions
Blockchain has brought about new ideas to internet medicine. Based on the consortium blockchain technology, this paper implements a sharing EMR system, realizing the following advantages and contributions: 1. The ECDSA signature algorithm and proxy re-encryption algorithm based on ECC were analyzed. Combined with attribute access control, the overall hierarchical architecture of sharing an EMR system based on consortium blockchain with secure access was designed and implemented.
2. According to different role attributes, different chaincodes were designed, and the data access control at the chaincode level was realized through attribute access control.
3. Through the proxy re-encryption algorithm, the data security sharing was realized. The sharing of privacy fields of electronic medical records could be used only with the authorization of patients, which greatly improves the control of patients over their own data.
4. The scanner device was connected to the blockchain network, and the blockchainnetworking scanner interacted with the blockchain data through the chaincode, which was executed digitally and automatically. The blockchain-networking scanner used a specific chaincode according to its attributes to realize the device's secure access to blockchain data.
In future work, we will conduct additional research on the encryption and authorized access of electronic medical records, as well as investigate a more general solution in the form of a security pattern, particularly in fine-grained access to encrypted electronic medical records.