# A Secure and Privacy-Preserving Medical Data Sharing via Consortium Blockchain

Authors: Duo Zhang; Shangping Wang; Yinglong Zhang; Qian Zhang; Yaling Zhang
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Medical data sharing is of great significance in promoting smart medicine. However, the heterogeneity of information systems used by various medical institutions makes sharing difficult. In addition, since medical data involves a great deal of sensitive information, sharing it could easily lead to the leakage of personal privacy. Blockchain, gained popularity as a distributed ledger technology, has great potential to connect heterogeneous systems and provides authenticity and integrity guarantees for medical data sharing. Focusing on the issues of medical data sharing and privacy protection, we propose a medical data sharing scheme based on consortium blockchain. To achieve access control, attribute-based access control technique is implemented, where patients preset attribute-specific access policies for their medical records, and record requesters are described by a set of attributes. For patients, we devise a hybrid storage mode to write access policies of medical records on the consortium blockchain network and store encrypted medical records off-chain. Leveraging blockchain and smart contracts, access privilege control and access history tracking can be realized. To enhance the key management, a tree of medical records is constructed for each patient, and by simply keeping the medical record trees, patients can recover their encryption keys at any time. Furthermore, we carry out an extensive analysis to show the high security and efficiency of our proposed scheme. Finally, we build a Quorum consortium blockchain on the Tencent Cloud and deploy smart contracts on the chain to simulate transactions in our scheme. The experiment results indicate the proposed scheme achieves good feasibility.


---

## Body

## 1. Introduction

With the continuous improvement in the informatization degree of medical institutions, the scale of medical data is also increasing [1]. In order to realize the efficient integration of medical resources and improve the efficiency of doctors’ diagnosis and treatment, it is essential to promote the sharing of electronic medical data. Patients’ medical data, on the other hand, is a valuable personal asset containing a great deal of sensitive information. In medical data sharing, there are significant risks of data privacy leakage and abuse, posing a major threat to the lives and property of patients. Therefore, the problem of data security and privacy in the process of data sharing arouses high concern. In addition, medical records are scattered among various medical institutions, and different data storage formats make it difficult to realize data exchange, resulting in information islands [2]. This is incompatible with the needs of patients for rapid, convenient, and accurate diagnosis and treatment, as well as the advancement of medical science. As a result, figuring out how to achieve data sharing and break down information barriers between various medical information systems while ensuring the security and privacy of medical data has become a pressing issue that must be addressed.At present, mainstream solutions [3] to this problem include identity authentication, access control, cryptography and log analysis, etc. These methods focus on how to ensure the privacy and security of patient data but lack the transparency guarantee of data access. Patients can only believe that medical data maintenance organizations will not abuse data for profit and other factors. However, as the owner of data, patients should control the access rights of their own medical data and have the right to know who, when, and for what purpose they access their data.The introduction of bitcoin [4] in 2009 presented a new direction for overcoming the challenges mentioned above. It has been discovered that the underlying technology of bitcoin, blockchain, could not only serve as a decentralized payment system, but also play an important role in many industries [5], such as finance, healthcare, utilities, identity management, asset registration, government agencies, etc. Subsequently, a lot of research on blockchain has been carried out, including the application of blockchain in medical treatment. With the characteristics of decentralized, unforgeable and tamper resistant, openness, anonymity, transparency, and autonomy, blockchain realizes the value transfer between peer nodes without trust and solves the problems of low security, high cost, low efficiency, and poor reliability in the current centralized mode. Attempting to apply blockchain technology [6, 7] to the medical industry is conducive to finding timely and effective medical data sharing solutions among different institutions, improving the accuracy and efficiency of diagnosis in the medical industry, and promoting the construction of smart medical systems. This study aims to contribute to this growing area of research by exploring how to harness the advantages of blockchain to facilitate privacy-preserving and access-controlled medical data sharing.The main contributions of this article are as follows:(1)
We adopt a hybrid data storage pattern of off-chain and on-chain to reduce storage load of blockchain. The medical data is encrypted and off-chain stored on a cloud server or decentralized storage system, while the relevant metadata of the medical data is recorded on blockchain.(2)
Patients can specify access policies for their own data, which are recorded in a smart contract by initiating a transaction. Each requester is described by a set of attributes, which are also recorded in a smart contract. Thus, access control can be performed automatically by smart contracts. A medical record can be accessed only if the requester’s attributes satisfy the access policy specified for the record.(3)
Due to the transparency and immutability of the blockchain, all the user’s actions are actually recorded on the blockchain, allowing patients to track the access history of their medical data.(4)
To facilitate key management, the scheme enables patients to generate subkeys based on a built medical record tree. A patient just needs to preserve the medical record tree, regardless of how many records he has. The patient can also backup the medical record tree with family or friends for unexpected situations.(5)
We deploy a consortium blockchain on Quorum project on Tencent Cloud Host and deploy smart contracts on the consortium blockchain to simulate transactions in the scheme. The experiment shows that the scheme is feasible, and the analysis carried out shows that the scheme is both secure and efficient.


## 2. Related Work

Blockchain technology has already shown its application potential in many fields, such as e-health [8,9], decentralized storage and data retrieval [10–12], crowdsourcing collaboration [13, 14], etc. In this section, we will introduce some previous works related to the application of blockchain technology in the medical record sharing in terms of privacy protection and access control, respectively.


### 2.1. Blockchain-Based Electronic Medical Record Sharing with Privacy Protection

Previous studies [15] have explored the efficacy of blockchain to achieve electronic medical record sharing with security and privacy preservation. Azaria et al. [16] proposed MedRec, an innovative decentralized medical record management system with capabilities for certifiability, privacy, auditability, and data sharing. It also provides tamper-proof logging records that can be accessed by patients across organizational structures. Xia et al. [17] presented a blockchain-based data sharing framework for electronic medical records. Leveraging cryptographic techniques, access to sensitive data from a shared repository is only permitted by authenticated users. The accountability is guaranteed by the properties of permissioned blockchain. Xia et al. [18] designed an effective medical record management system: MedShare, which allows data entities to share medical records in a trustless setting. Based on blockchain, data access control, tracing, and auditing are provided in MedShare. Jayabalan and Thiruchelvam [19] proposed a general patient data transparent framework based on blockchain and cloud storage, which implements electronic medical record authorization management by analyzing the generated log events. For the problem of patients being unable to manage questionnaire data in the medical industry, Kim et al. [20] presented a blockchain-based medical questionnaire data sharing management system which can interoperate with other systems. Based on the characteristics of the blockchain, the solution not only ensures the integrity of the questionnaire data, but also improves the security of the patient’s personal medical data. Zhao et al. [21] designed a lightweight backup and efficient recovery scheme for the medical blockchain key through the sensor network, which can help the medical blockchain effectively protect privacy information and promote the development of medical blockchain. Because data storage and synchronization have not been effectively implemented, it is difficult to share data between medical institutions. Abdellatif et al. [22] designed a medical-edge-blockchain, MEdge-Chain, that leverages blockchain and edge computing technology to provide optimized and intelligent medical data exchange among various entities. To enable medical data exchange and speedy data retrieval, Zou et al. [23] designed a new block and chain structure and proposed a privacy-preserving e-health system. Also, a reputation-based mechanism system is being constructed to motivate miners.


### 2.2. Blockchain-Based Electronic Medical Record Sharing with Access Control

In the management of medical data, only the traditional data protection methods are applied, the patient’s privacy information is not effectively guaranteed. Patients cannot control their medical image data while receiving treatment. Tang et al. [24] suggested a medical image security sharing system based on blockchain and smart contract technology. The system realizes medical image data sharing across systems and regions and provides a novel idea to making medical image sharing more secure and dependable. With the development of mobile networks and wearable electronic devices, the collection and sharing of personal health data is becoming more and more valuable. To address the privacy problem during the process and the vulnerability of the data storage system, Liang et al. [25] proposed a user-centric medical record sharing solution using the permissioned blockchain technology and using Hyperledger Fabric [26] blockchain to simulate the implementation of the scheme. Zhang and Poslad [27] introduced an electronic medical record architecture that differs from existing blockchain methods. The architecture’s access model enables fine-grained access authorization while maintaining compatibility with blockchain. Zhang and Lin [28] proposed a personal health information sharing scheme based on blockchain, which realizes data security, access control, privacy protection, and secure search. This article constructs two kinds of blockchains, private blockchain and consortium blockchain, to store personal health data and its security index records, respectively. Using immutable and verifiable features of transaction records in blockchain technology, Chen et al. [29] proposed a new medical data processing architecture. Under this architecture, medical data can be safely shared without intermediaries, avoiding data leakage risks caused by improper operation during processing. Wang et al. [30] proposed a blockchain-based framework that combines decentralized storage system, Ethereum blockchain, smart contract, and attribute-based encryption (ABE) technology to achieve fine-grained access control and keyword search in the decentralized storage systems. Rajput et al. [31] designed an access control management system for emergency situations based on Hyperledger Fabric blockchain. The system realizes smart contract based on emergencies and specific time-limited rules, enabling access to patient data via smart contract in an emergency. Tanwar et al. [32] proposed an architecture for an electronic medical record sharing system based on the Hyperledger and designed an access control algorithm based on symmetric key cryptography to improve data accessibility between healthcare providers. Utilizing the blockchain technique and smart contract, Wang et al. [9] established a decentralized and trusted framework, MedShare, for healthcare centers to securely share their encrypted EHR. In their article, fine-grained access control can be realized by devising a lightweight ABE. Besides, multi-keyword Boolean search operations on encrypted EHR is also allowed for authorized users.


## 2.1. Blockchain-Based Electronic Medical Record Sharing with Privacy Protection

Previous studies [15] have explored the efficacy of blockchain to achieve electronic medical record sharing with security and privacy preservation. Azaria et al. [16] proposed MedRec, an innovative decentralized medical record management system with capabilities for certifiability, privacy, auditability, and data sharing. It also provides tamper-proof logging records that can be accessed by patients across organizational structures. Xia et al. [17] presented a blockchain-based data sharing framework for electronic medical records. Leveraging cryptographic techniques, access to sensitive data from a shared repository is only permitted by authenticated users. The accountability is guaranteed by the properties of permissioned blockchain. Xia et al. [18] designed an effective medical record management system: MedShare, which allows data entities to share medical records in a trustless setting. Based on blockchain, data access control, tracing, and auditing are provided in MedShare. Jayabalan and Thiruchelvam [19] proposed a general patient data transparent framework based on blockchain and cloud storage, which implements electronic medical record authorization management by analyzing the generated log events. For the problem of patients being unable to manage questionnaire data in the medical industry, Kim et al. [20] presented a blockchain-based medical questionnaire data sharing management system which can interoperate with other systems. Based on the characteristics of the blockchain, the solution not only ensures the integrity of the questionnaire data, but also improves the security of the patient’s personal medical data. Zhao et al. [21] designed a lightweight backup and efficient recovery scheme for the medical blockchain key through the sensor network, which can help the medical blockchain effectively protect privacy information and promote the development of medical blockchain. Because data storage and synchronization have not been effectively implemented, it is difficult to share data between medical institutions. Abdellatif et al. [22] designed a medical-edge-blockchain, MEdge-Chain, that leverages blockchain and edge computing technology to provide optimized and intelligent medical data exchange among various entities. To enable medical data exchange and speedy data retrieval, Zou et al. [23] designed a new block and chain structure and proposed a privacy-preserving e-health system. Also, a reputation-based mechanism system is being constructed to motivate miners.


## 2.2. Blockchain-Based Electronic Medical Record Sharing with Access Control

In the management of medical data, only the traditional data protection methods are applied, the patient’s privacy information is not effectively guaranteed. Patients cannot control their medical image data while receiving treatment. Tang et al. [24] suggested a medical image security sharing system based on blockchain and smart contract technology. The system realizes medical image data sharing across systems and regions and provides a novel idea to making medical image sharing more secure and dependable. With the development of mobile networks and wearable electronic devices, the collection and sharing of personal health data is becoming more and more valuable. To address the privacy problem during the process and the vulnerability of the data storage system, Liang et al. [25] proposed a user-centric medical record sharing solution using the permissioned blockchain technology and using Hyperledger Fabric [26] blockchain to simulate the implementation of the scheme. Zhang and Poslad [27] introduced an electronic medical record architecture that differs from existing blockchain methods. The architecture’s access model enables fine-grained access authorization while maintaining compatibility with blockchain. Zhang and Lin [28] proposed a personal health information sharing scheme based on blockchain, which realizes data security, access control, privacy protection, and secure search. This article constructs two kinds of blockchains, private blockchain and consortium blockchain, to store personal health data and its security index records, respectively. Using immutable and verifiable features of transaction records in blockchain technology, Chen et al. [29] proposed a new medical data processing architecture. Under this architecture, medical data can be safely shared without intermediaries, avoiding data leakage risks caused by improper operation during processing. Wang et al. [30] proposed a blockchain-based framework that combines decentralized storage system, Ethereum blockchain, smart contract, and attribute-based encryption (ABE) technology to achieve fine-grained access control and keyword search in the decentralized storage systems. Rajput et al. [31] designed an access control management system for emergency situations based on Hyperledger Fabric blockchain. The system realizes smart contract based on emergencies and specific time-limited rules, enabling access to patient data via smart contract in an emergency. Tanwar et al. [32] proposed an architecture for an electronic medical record sharing system based on the Hyperledger and designed an access control algorithm based on symmetric key cryptography to improve data accessibility between healthcare providers. Utilizing the blockchain technique and smart contract, Wang et al. [9] established a decentralized and trusted framework, MedShare, for healthcare centers to securely share their encrypted EHR. In their article, fine-grained access control can be realized by devising a lightweight ABE. Besides, multi-keyword Boolean search operations on encrypted EHR is also allowed for authorized users.


## 3. Preliminaries

### 3.1. Blockchain and Smart Contract

#### 3.1.1. Blockchain

Blockchain can not only serve as a decentralized payment system, its enabler blockchain technology can also play an important role in many industries such as finance, public utilities, identity management, asset registration, government agencies, etc., especially in the medical industry. In the medical field, blockchain is mainly applied to the preservation of personal medical records. The main characteristics of blockchain technology, including decentralization, immutability, consensus mechanism, etc., can provide the security and privacy protection for medical information.Blockchain can be classified into three types based on the admission principle of blockchain nodes: public blockchain, consortium blockchain, and private blockchain. This article employs consortium blockchain to provide a technical support for personal medical record storage and sharing. In consortium blockchain, nodes need to be authorized to join the network, and the read-write rights and account rights are set according to the consortium rules.


#### 3.1.2. Smart Contract

Smart contract is a computer protocol that does not require human intervention once it is deployed. It can automatically execute contract-related operation under specified conditions and generate verifiable evidence after execution to illustrate the validity of the contract operation. Smart contracts were not used in the actual industry until the advent of blockchain due to lack of a trustworthy execution environment. Ethereum was the first platform to achieve the full integration of smart contracts and blockchain technology.


### 3.2. Quorum

Quorum [33, 34] is an open-source blockchain platform based on the Ethereum protocol developed by J.P. Morgan since 2016, which can be regarded as the enterprise version of Ethereum. Quorum is designed to provide a permissioned Ethereum solution for industries to support the privacy of transactions and contracts. Quorum code is a branch of go-ethereum, and it can quickly integrate and seamlessly connect with Ethereum updates. The main features of Quorum over public Ethereum are as follows:(i)
Transaction and contract privacy(ii)
Multiple consensus mechanisms based on votes(iii)
Authority management of network/peer nodes(iv)
More superior performanceThe main components of Quorum include the Quorum node and Constellation module. The Quorum node is intentionally designed as a lightweight Geth fork so that it can take advantage of the Ethereum’s node design. Therefore, Quorum will update and adjust accordingly with each release of Geth in the future.Quorum’s Constellation module consists of two submodules: Transaction Manager and Enclave. The Transaction Manager is responsible for transaction privacy. It stores the contents of the private transaction and interacts with other Transaction Managers concerned. It also uses the Enclave to encrypt or decrypt the private transactions it receives.In distributed ledger, cryptography is widely used in transaction authenticity verification, participants’ verification, historical information traceability, etc. In order to achieve state separation and improve performance through some parallelized encryption operations, Quorum delegates much of the encryption work to the Enclave, including symmetric key generation and data encryption/decryption. Enclave works with the Transaction Manager to enforce privacy, managing encryption/decryption in a segregated manner.


### 3.3. Istanbul BFT

The original PBFT consensus algorithm [35] requires quite a bit of adjustments to work with blockchain. The improved PBFT that implemented in the Quorum project is named Istanbul BFT (IBFT) [36]. IBFT inherits the three consensus phases of PBFT, namely pre-prepare, prepare, and commit, and combines them with block generation. In a consensus network with N validator nodes, up to F Byzantine nodes can be tolerated, where N=3F+1.IBFT is a state machine replication algorithm. Each validator maintains a state machine replica in order to reach block consensus. IBFT sets six consensus states: new round, pre-prepared, prepared, committed, final committed, and round change. Figure1 shows the state transition process in a round of consensus.(1)
New round: The validators pick one of them as a proposer. The proposer will propose a new block proposal and broadcast it along with the pre-prepare message (as step ① in Figure1). The other validators wait for the pre-prepare message (as step ② in Figure 1).(2)
Preprepared: After receiving the pre-prepare message from the proposer, a validator will enter the pre-prepared state and broadcast the prepare message (as step ③). It then waits for2F+1 prepare messages (as step ④).(3)
Prepared: A validator enters the prepared state after receiving2F+1 prepare messages and broadcasts a commit message (as step ⑤). It then waits for 2F+1 commit messages (as step ⑥).(4)
Committed: After receiving the2F+1 commit messages, a validator enters the committed state and attempts to add the block at the end of the local blockchain (as step ⑦).(5)
Final committed: After the block is inserted successfully (as step ⑧), a verifier enters the final committed state and is ready for the next round.(6)
Round change: The round change state would be triggered in three cases: round change time expiration, invalid pre-prepare message, and block insertion failure. When a verifier finds one of the three conditions, it broadcasts a round change message and waits for round change messages from the other verifiers. Upon receiving2F+1 round change messages for the same round, a validator enters new round state.Figure 1
The state transition of IBFT algorithm.The blockchain using IBFT consensus algorithm will not fork, and the valid blocks are bound to appear on the main chain. In order to prevent the Byzantine nodes from generating a different chain from the main chain, each validator will add at least2F+1 signatures of received confirm message to the extraData field of the block header, and then insert the block to the blockchain. Therefore, the light node can also verify the correctness of the block. However, the dynamic extraData field will cause the inconsistency of block hash calculation. Since for the same block, different validators may add different confirm signatures, resulting in inconsistent block hashes. To solve this problem, the extraData field will be removed when calculating the block hash.


### 3.4. Cryptographic Primitive

#### 3.4.1. Hash Function

In addition to the hash function used in the blockchain system, we also need to choose a cryptographic collision-resist hash functionH, which maps any strings to a fixed pth strings, that is H:0,1∗⟶0,1p.


#### 3.4.2. Encryption and Signature

We assume that a secure symmetric encryption algorithmEncsym,Decsym, a secure asymmetric encryption algorithm Encasym,Decasym, and an unforgeable digital signature algorithm Sig,Ver are available. We denote Encpkasymm, Encpksymm to be the ciphertext of the message m encrypted by the public key pk, and Sigskm to be the signature of the message m signed by the secret key sk.


### 3.5. Access Control

We use attribute-based access control model for more precise access control and considerd,n−threshold as access control policy. Let U be the universal set of possible attributes that are publicly known. Given an attribute set Att⊂U and an access policy Policy⊂U, where Policy=n, we say that Att satisfy Policy if Att∩Policy≥d.


## 3.1. Blockchain and Smart Contract

### 3.1.1. Blockchain

Blockchain can not only serve as a decentralized payment system, its enabler blockchain technology can also play an important role in many industries such as finance, public utilities, identity management, asset registration, government agencies, etc., especially in the medical industry. In the medical field, blockchain is mainly applied to the preservation of personal medical records. The main characteristics of blockchain technology, including decentralization, immutability, consensus mechanism, etc., can provide the security and privacy protection for medical information.Blockchain can be classified into three types based on the admission principle of blockchain nodes: public blockchain, consortium blockchain, and private blockchain. This article employs consortium blockchain to provide a technical support for personal medical record storage and sharing. In consortium blockchain, nodes need to be authorized to join the network, and the read-write rights and account rights are set according to the consortium rules.


### 3.1.2. Smart Contract

Smart contract is a computer protocol that does not require human intervention once it is deployed. It can automatically execute contract-related operation under specified conditions and generate verifiable evidence after execution to illustrate the validity of the contract operation. Smart contracts were not used in the actual industry until the advent of blockchain due to lack of a trustworthy execution environment. Ethereum was the first platform to achieve the full integration of smart contracts and blockchain technology.


## 3.1.1. Blockchain

Blockchain can not only serve as a decentralized payment system, its enabler blockchain technology can also play an important role in many industries such as finance, public utilities, identity management, asset registration, government agencies, etc., especially in the medical industry. In the medical field, blockchain is mainly applied to the preservation of personal medical records. The main characteristics of blockchain technology, including decentralization, immutability, consensus mechanism, etc., can provide the security and privacy protection for medical information.Blockchain can be classified into three types based on the admission principle of blockchain nodes: public blockchain, consortium blockchain, and private blockchain. This article employs consortium blockchain to provide a technical support for personal medical record storage and sharing. In consortium blockchain, nodes need to be authorized to join the network, and the read-write rights and account rights are set according to the consortium rules.


## 3.1.2. Smart Contract

Smart contract is a computer protocol that does not require human intervention once it is deployed. It can automatically execute contract-related operation under specified conditions and generate verifiable evidence after execution to illustrate the validity of the contract operation. Smart contracts were not used in the actual industry until the advent of blockchain due to lack of a trustworthy execution environment. Ethereum was the first platform to achieve the full integration of smart contracts and blockchain technology.


## 3.2. Quorum

Quorum [33, 34] is an open-source blockchain platform based on the Ethereum protocol developed by J.P. Morgan since 2016, which can be regarded as the enterprise version of Ethereum. Quorum is designed to provide a permissioned Ethereum solution for industries to support the privacy of transactions and contracts. Quorum code is a branch of go-ethereum, and it can quickly integrate and seamlessly connect with Ethereum updates. The main features of Quorum over public Ethereum are as follows:(i)
Transaction and contract privacy(ii)
Multiple consensus mechanisms based on votes(iii)
Authority management of network/peer nodes(iv)
More superior performanceThe main components of Quorum include the Quorum node and Constellation module. The Quorum node is intentionally designed as a lightweight Geth fork so that it can take advantage of the Ethereum’s node design. Therefore, Quorum will update and adjust accordingly with each release of Geth in the future.Quorum’s Constellation module consists of two submodules: Transaction Manager and Enclave. The Transaction Manager is responsible for transaction privacy. It stores the contents of the private transaction and interacts with other Transaction Managers concerned. It also uses the Enclave to encrypt or decrypt the private transactions it receives.In distributed ledger, cryptography is widely used in transaction authenticity verification, participants’ verification, historical information traceability, etc. In order to achieve state separation and improve performance through some parallelized encryption operations, Quorum delegates much of the encryption work to the Enclave, including symmetric key generation and data encryption/decryption. Enclave works with the Transaction Manager to enforce privacy, managing encryption/decryption in a segregated manner.


## 3.3. Istanbul BFT

The original PBFT consensus algorithm [35] requires quite a bit of adjustments to work with blockchain. The improved PBFT that implemented in the Quorum project is named Istanbul BFT (IBFT) [36]. IBFT inherits the three consensus phases of PBFT, namely pre-prepare, prepare, and commit, and combines them with block generation. In a consensus network with N validator nodes, up to F Byzantine nodes can be tolerated, where N=3F+1.IBFT is a state machine replication algorithm. Each validator maintains a state machine replica in order to reach block consensus. IBFT sets six consensus states: new round, pre-prepared, prepared, committed, final committed, and round change. Figure1 shows the state transition process in a round of consensus.(1)
New round: The validators pick one of them as a proposer. The proposer will propose a new block proposal and broadcast it along with the pre-prepare message (as step ① in Figure1). The other validators wait for the pre-prepare message (as step ② in Figure 1).(2)
Preprepared: After receiving the pre-prepare message from the proposer, a validator will enter the pre-prepared state and broadcast the prepare message (as step ③). It then waits for2F+1 prepare messages (as step ④).(3)
Prepared: A validator enters the prepared state after receiving2F+1 prepare messages and broadcasts a commit message (as step ⑤). It then waits for 2F+1 commit messages (as step ⑥).(4)
Committed: After receiving the2F+1 commit messages, a validator enters the committed state and attempts to add the block at the end of the local blockchain (as step ⑦).(5)
Final committed: After the block is inserted successfully (as step ⑧), a verifier enters the final committed state and is ready for the next round.(6)
Round change: The round change state would be triggered in three cases: round change time expiration, invalid pre-prepare message, and block insertion failure. When a verifier finds one of the three conditions, it broadcasts a round change message and waits for round change messages from the other verifiers. Upon receiving2F+1 round change messages for the same round, a validator enters new round state.Figure 1
The state transition of IBFT algorithm.The blockchain using IBFT consensus algorithm will not fork, and the valid blocks are bound to appear on the main chain. In order to prevent the Byzantine nodes from generating a different chain from the main chain, each validator will add at least2F+1 signatures of received confirm message to the extraData field of the block header, and then insert the block to the blockchain. Therefore, the light node can also verify the correctness of the block. However, the dynamic extraData field will cause the inconsistency of block hash calculation. Since for the same block, different validators may add different confirm signatures, resulting in inconsistent block hashes. To solve this problem, the extraData field will be removed when calculating the block hash.


## 3.4. Cryptographic Primitive

### 3.4.1. Hash Function

In addition to the hash function used in the blockchain system, we also need to choose a cryptographic collision-resist hash functionH, which maps any strings to a fixed pth strings, that is H:0,1∗⟶0,1p.


### 3.4.2. Encryption and Signature

We assume that a secure symmetric encryption algorithmEncsym,Decsym, a secure asymmetric encryption algorithm Encasym,Decasym, and an unforgeable digital signature algorithm Sig,Ver are available. We denote Encpkasymm, Encpksymm to be the ciphertext of the message m encrypted by the public key pk, and Sigskm to be the signature of the message m signed by the secret key sk.


## 3.4.1. Hash Function

In addition to the hash function used in the blockchain system, we also need to choose a cryptographic collision-resist hash functionH, which maps any strings to a fixed pth strings, that is H:0,1∗⟶0,1p.


## 3.4.2. Encryption and Signature

We assume that a secure symmetric encryption algorithmEncsym,Decsym, a secure asymmetric encryption algorithm Encasym,Decasym, and an unforgeable digital signature algorithm Sig,Ver are available. We denote Encpkasymm, Encpksymm to be the ciphertext of the message m encrypted by the public key pk, and Sigskm to be the signature of the message m signed by the secret key sk.


## 3.5. Access Control

We use attribute-based access control model for more precise access control and considerd,n−threshold as access control policy. Let U be the universal set of possible attributes that are publicly known. Given an attribute set Att⊂U and an access policy Policy⊂U, where Policy=n, we say that Att satisfy Policy if Att∩Policy≥d.


## 4. The Proposed Scheme

### 4.1. System Model

#### 4.1.1. Entities

As illustrated in Figure2, the key entities of our scheme can be listed as: blockchain, supervision center, storage server, record owner, and record requester.Blockchain: We utilize consortium blockchain in this scheme, and choose IBFT, a PBFT variant algorithm, as the consensus algorithm. The identity of nodes in the consortium blockchain needs to be authenticated, so there is a certain trust foundation between members. The members in the blockchain network can be ordinary users such as doctors and patients, as well as large medical institutions, disease research institutions, etc. As medical institutions and research institutes often have certain authority and rich hardware resources, some of them will be selected by the supervision center as IBFT consensus nodes to maintain the blockchain. The consortium blockchain is defined to accept only four types of transactions:Tauthorize for identity authentication; Tupload for new record upload; Taccess for access control management; and Tupdate for access policy update.Supervision centerS: The supervision center S acts as an administrator of the data sharing system. The S is responsible for initializing the consortium blockchain network and deploying smart contracts on it. The S also needs to verify the identities of users who want to join the network.Storage server: The storage server is responsible for executing the instructions of storage and access issued by users. After users upload their data, the storage server will return location information from which the encrypted record can be accessed, such as the URL returned by dropbox or the hash returned by IPFS [37].Record ownerO: The record owner O is a patient who owns a number of medical records and intends to share his medical records. The Os define access policies for their medical records to enforce access control. The Os store their medical records in a hybrid mode, that is, the raw records are encrypted and stored on the storage server, while the access policy, storage location, and other information are uploaded to the blockchain.Record requesterℛ: A record requester ℛ can be a doctor who needs to view a case of a patient or an institution conducting a case study of an infectious disease. To join the consortium blockchain network, the ℛ needs to register with the S to obtain an attribute certificate. An ℛ can access the owners’ medical records if it has satisfiable authority.Figure 2
System framework of the proposed scheme.


#### 4.1.2. Workflow

As illustrated in Figure2, the workflow of this scheme can be summarized into five phases, namely system establishment, identity authentication, record generation and upload, record access, and access policy update.(1)
System establishment: In this phase, the supervision center initializes the consortium blockchain network and deploys smart contracts on it (as step ① in Figure2).(2)
Identity authentication: In this phase, each user who wants to join the network submits real-life identification materials to theS (as step ② in Figure 2). The S will issue a certificate to the user after verifying the authenticity and validity of identification materials (as step ③). The S also initiates an authorization transaction to record the attributes of the registrant on blockchain (as step ④).(3)
Record generation and upload: In this phase, theO encrypts his medical record and submits the encrypted medical record to the storage server (as step ⑤). The O also defines an access policy for medical record and anchors it to blockchain by initiating an upload transaction (as step ⑥).(4)
Record access: This phase allows theℛ to request access to the O’s medical record by initiating an access transaction (as step ⑦). If the ℛ’s attributes meet the access policy of record, the access request is accepted and the O will secretly transmit the decryption key to the ℛ (as step ⑧). The ℛ can download the encrypted record from the storage server and decrypt it (as step ⑨).(5)
Access policy update: This phase enables theO to make changes to the access policy of the uploaded records by initiating an access transaction (as step ⑩).


### 4.2. Threat Model

We assume that all the adversaries have bounded computational capability, so they cannot break the security properties of the blockchain and the cryptographic tools used in our scheme. The supervision center and record owners are assumed to be trusted and will exactly follow the protocol. We also consider the following threats:(i)
Semi-trusted storage server: We assumed that the storage server is semi-trusted, that is, honest but curious. It will honestly follow the protocol, but it is also curious about users’ private data and tries to learn any information from the data stored on the server.(ii)
Unauthorized access attack: We also consider the record requesters may be malicious that attempts to break data access control. Specifically, the adversary might collude with the storage server to gain some content of medical records out of its authority.(iii)
Standard Byzantine threat model: In our design, medical institutions work as consensus nodes to execute IBFT protocol to generate new blocks. We consider a Byzantine adversary who may cause faulty nodes to exhibit arbitrary behavior (drop, delay, reorder). However, we assume the assumptions hold: the number of Byzantine nodes in IBFT-based consensus does not exceed one-third of the total consensus members.


### 4.3. Design Goals

The design goals of our work are listed as follows:(i)
Access control: Medical records should be enforced by fine-grained access control so that only authorized users can access.(ii)
Integrity and confidentiality: Raw data are stored on a semi-honest storage server, so it is critical to keep information from being corrupted or modified and accessed without authorization during transmission and storage.(iii)
Auditability: Various operations on medical records such as uploading, updating, and accessing should be recorded in a tamper-resistant way, making them easy to be audited.(iv)
Key management: When a user has a large number of medical records, there is a corresponding need for multiple symmetric keys, so we believe that efficient key management is of necessity.


### 4.4. Key Management

To facilitate key management, a hierarchical tree structure is introduced in this article. Patients can classify the diseases they suffer from based on the types of diseases (refer to the departments’ setting structure of a hospital) and build their own medical record tree with a hierarchical classification of diseases.


#### 4.4.1. Medical Record Tree

We now describe how a patient creates his own medical record tree, taking Figure3 for example. The patient chooses a master key and takes it as the root node of a tree. Each leaf node of the tree is described by a medical record of the patient. Each interior node of the tree represents the hierarchical classification of a medical record. The hierarchical relationship of the interior node can refer to departments’ setting structure of a hospital.Figure 3
Example of medical record tree: the number of a node is highlighted in orange, for the leaf node associated with the medical recordEMR6 (marked by blue box), index=1223 (marked by red box).To facilitate working with the tree, an ordering is defined between the children of each non-leaf node. That is, the children of a non-leaf node are numbered in serial order starting from 1. Specifically, the number of the root node is set to 1. In Figure3, the number of a node is highlighted in orange. Besides, for each leaf node, let index denote the concatenation of numbers of all nodes on the shortest path from the root node to the leaf node. For example, in Figure 3, the index of leaf node associated with the medical record EMR6 (marked with blue boxes) is: 1223 (marked with red boxes).


#### 4.4.2. Generating Keys from the Medical Record Tree

With a medical record tree, the patient can generate keys for all medical record in the tree. For a leaf node, the key of its associated medical record can be calculated as follows:(1)Hmaster key‖index,where “ ∥” indicates concatenation.


### 4.5. Construction

In this section, we will describe the construction of the scheme in detail and show how to use the features of blockchain and smart contract to achieve the privacy protection and secure sharing of medical data.The cryptographic hash functionH used in our system is implemented by SHA256, the symmetric encryption algorithm Encsym,Decsym is implemented using AES, and the asymmetric encryption algorithm Encasym,Decasym and the signature algorithm Sig,Ver are implemented using ECC with secp256k1 curve.


#### 4.5.1. System Establishment

In the system establishment stage, theS first creates a blockchain account for itself, where the public-private key pair is denoted as pkS,skS, and the account address derive from the public key pkS is denoted as addrS. The S selects a number of hospitals and research institutes as consensus nodes, which are authoritative or have a high reputation score counted by a reputation management system. The S also deploys smart contracts on the consortium blockchain network—Authorize, MedicalRecord, and AccessControl—the details of which are described in Section 4.6.


#### 4.5.2. Identity Authentication

To join in the consortium blockchain network, each user (ℛ and O) needs to apply for identity registration with the supervision center S. Before that, each ℛ or O chooses a pair of public and private key, denoted as pkℛ,skℛ or pkO,skO. Then, an application for registration Register and a signature σ on Register can be submitted to the S,(2)Register=pkℛ/O,identification materials,σ=Sigskℛ/ORegister..A registration applicationRegister should include his public key pkℛ/O, identification materials that can prove the real-life role. The S will verify the registrant’s signature,(3)0,1=Verpkℛ/ORegister,σ,and the authenticity and validity of the identification materials. If the verification passes, the S formalize the registrant’s role as a set of descriptive attributes Att according to the provided identification materials,(4)Att=att1,att2,att3⋯,where atti∈U. Also, the S derives a blockchain account address from the registrant’s public key pkℛ/O, denoted as addrO or addrℛ. Then, a certificate Cert along with the S’s signature σ on it will be issued to the registrant,(5)Cert=addrℛ/O,Att,σ′=SigskSCert.TheS also initiates an authorization transaction Tauthorize to the consortium blockchain network. The transaction structure is shown as Table 1.Table 1
The authorization transactionTauthorize.
Tauthorizefrom:addrSto:Authorizedata:addrℛ/O,Attsig:SigskSTauthorizeThis transaction will trigger the interface setAuthorization() of the smart contract Authorize, by which registrant’s attribute authorization information will automatically be stored in smart contract.Upon receipt of the certificate, the registrant will verify the signature of theS to confirm the integrity of the certificate and the authenticity of its source,(6)0,1=VerpkSCert,σ′.


#### 4.5.3. Record Generation and Upload

When the patient goes to the hospital for medical treatment or examination, a medical recordM will be generated and given to the patient. Patients can share their historical medical data with doctors for more accurate treatment or research institutions for case studies. To protect the privacy of medical data when sharing, it is often necessary to encrypt it.The key management method is described in Section4.4; the patient, that is the record owner O, first creates a medical record tree with his master key MK and all historical medical records as Figure 3. For a medical record M with index index in the tree, generates the subkey(7)K=HMK‖index.To share the medical recordM, the O takes K as the symmetric key and calculates(8)CTM=EncKsymM,h=HCTM.TheO uploads CTM to the storage server, which will return the storage location location. The O records the ciphertext hash h and the storage location location.In order to control the access privilege of medical record, theO specifies an attribute-based d,n−threshold access policy for his record,(9)Policy=att1,att2,att3⋯,threshold=d,where Policy=n, atti∈U, U is the universe of possible attributes. The medical record can only be accessed if the number of identical attributes in requester’s attributes set and access policy is equal to or greater than the threshold.(10)Policy∩Att≥d.TheO assembles policy, threshold, index,h, location,metadata as an upload transaction Tupload, where metadata can be a few keywords for the record or a simple description of the condition, Then Tupload is broadcast to the consortium blockchain network. The structure of Tupload is shown as Table 2.Table 2
The upload transactionTupload.
Tuploadfrom:addrOto:MedicalRecorddata:policy,threshold,index, h,location,metadatasig:SigskOTuploadThis transaction will trigger the interface uploadRecord() of the smart contract MedicalRecord, by which transaction data related to the medical record will be automatically stored in the smart contact.


#### 4.5.4. Record Access

The data on blockchain is available to members of the consortium, and the requesters can monitor the blockchain to find medical resources of interest. When a requesterℛ would like to access a medical record written in an upload transaction Tupload with transaction ID txid, he can determine for himself whether his attributes set satisfy the access policy recorded in the transaction. If yes, he assembles an access request transaction Taccess as Table 3 and broadcasts it on the consortium blockchain network.Table 3
The access transactionTaccess.
Taccessfrom:addrℛto:AccessControldata:addrO,txidsig:SigskℛTaccessThis transaction will trigger the interface requestAccess() of the smart contract AccessControl, which automatically check whether the attributes of the requesterℛ satisfy the access policy in the transaction txid, that is, if the following condition holds:(11)Policy∩Att≥d.If not, the access request will be denied; otherwise, the request will be accepted and the result will be recorded in the event log.Once theO of the medical record listens for an authorized access request event, he uses the ℛ’s public key pkℛ to encrypt the symmetric key K of the medical record,(12)CTK=EncpkℛasymK,then sends CTK to the ℛ by an off-chain communication channel.After receivingCTK, the ℛ decrypts CTK with his private key skℛ,(13)K=DecskℛasymCTK.Further, theℛ downloads the encrypted record CTM according to the location information in transaction Tupload and calculates(14)h′=HCTM,to check if h=h′ holds. If it does, make the final decryption(15)M=DecKsymCTM,to get the raw medical record M.


#### 4.5.5. Access Policy Update

Although the data on the blockchain are tamper resistant, theO can broadcast a new transaction to update the access policy. The consensus nodes always verify the permissions based on the latest transactions, thereby enabling the O to update the access policy for the records on the blockchain. To update the access policy, the O assembles txid,policy′ as a policy update transaction Tupdate, where txid is the upload transaction ID where the medical record needs to be updated, policy′ is the new access policy, and broadcasts Tupdate to the blockchain network. The transaction structure is shown as Table 4.Table 4
The policy update transactionTupdate.
Tupdatefrom:addrOto:MedicalRecorddata:txid,policy′sig:SigskOTupdateThis transaction will trigger the interface updateRecord() of the smart contract MedicalRecord, which automatically performs policy updates.


### 4.6. Smart Contract Design

In this section, we mainly introduce the smart contract-related interface and algorithm logic used in this article. Smart contracts are coded in the programming language Solidity [38]. The smart contracts we designed include Authorize contract, MedicalRecord contract, and AccessControl contract.


#### 4.6.1. Authorize Contract

The Authorize contract is deployed by theS, and the contract design can be seen in Figure 4. Through the contract, tamper-resistant information is written on the blockchain to enable authorization for organizations and users.(1)
Authorize contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The authorizedUsers variable of mapping types, which defines a mapping collection from authorized user addresses to the string of attribute set. TheS can add, modify, and delete the collection through the relevant function interfaces of the contract.(2)
Authorize contract interfaces. The following two function interfaces are provided in the Authorize contract:(a)
setAuthorization (address, attributeSet): This function can only be executed by the S. When the S authorizes organizations and users, the authorized account address will be added to the authorizedUsers variable. This function can be used to add, modify, or delete authorizations for organizations and users. The attribute set string is set to the corresponding attribute values.(b)
getAuthorization (address): This function can be executed by anyone. We can use the function to query the attribute set of a specific account address. The type of the function is constant, meaning it does not modify the state of the blockchain.Figure 4
Pseudocode for Authorize contract.


#### 4.6.2. MedicalRecord Contract

The MedicalRecord contract is deployed by theS, and the contract design can be seen in Figure 5. Through the contract, we can upload medical records, update access policy, or obtain the metadata information of medical records.(1)
MedicalRecord contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The MedRec variable of custom data struct types, which defines the structure of a medical record, containing variables like policy, threshold, index, hash, location, and metadata.(c)
The MedRec variable of mapping types, which a mapping collection from user address to the array of struct MedRec.(2)
MedicalRecord contract interfaces: The following four function interfaces are provided in the MedicalRecord contract.(a)
uploadRecord(policy, threshold, index, hash, location, metadata): The function can be executed by anyone. It is used to upload the metadata information of medical records. A serious limitation of this is that one can only add the medical record collection corresponding to one’s own address.(b)
updateRecord(location, newPolicy): The function can be executed by anyone. It is used to update the access policies of medical records. A serious limitation of this is that one can only update the access policies of medical record collection corresponding to one’s own address.(c)
getRecord(): This function is used to obtain the metadata information of medical records already uploaded. The type of the function is constant, meaning it does not modify the state of the blockchain.(d)
getAccessPolicy(address, location): This function is used to obtain the access policy of medical record that the account address and location are specified.Figure 5
Pseudocode for MedicalRecord contract.


#### 4.6.3. AccessControl Contract

The AccessControl contract is deployed byS, and the contract design can be seen in Figure 6. Through the contract, one can issue access request or obtain the access history of medical record.(1)
AccessControl contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The AccessStruct variable of custom data struct types, which defines the structure of an access, containing variables like txid, time, and requester.(c)
The access variable of mapping types, which defines a mapping collection from authorized user address to the array of struct AccessStruct.(d)
The object instance medicalRecord of MedicalRecord contract. In the AccessControl contract, the getAccessPolicy function of the MedicalRecord contract needs to be invoked. Therefore, a MedicalRecord contract object instance needs to be initialized.(e)
The object instance authorize of Authorize contract. In the AccessControl contract, the getAuthorization function of the Authorize contract needs to be invoked. Therefore, a Authorize contract object instance needs to be initialized.(2)
AccessControl contract interfaces: The following function interfaces are provided in the AccessControl contract.(a)
setContract(address of MedicalRecord contract, address of Authorize contract): The function is used to set the address of the Authorize instance and the address of the MedicalRecord instance.(b)
requestAccess(address, txid, location): The function is used to issue an access request for a medical record. The access history will be recorded on the blockchain.(c)
getAccessRequest(): The function is used to obtain the access history of medical records.Figure 6
Pseudocode for AccessControl contract.


## 4.1. System Model

### 4.1.1. Entities

As illustrated in Figure2, the key entities of our scheme can be listed as: blockchain, supervision center, storage server, record owner, and record requester.Blockchain: We utilize consortium blockchain in this scheme, and choose IBFT, a PBFT variant algorithm, as the consensus algorithm. The identity of nodes in the consortium blockchain needs to be authenticated, so there is a certain trust foundation between members. The members in the blockchain network can be ordinary users such as doctors and patients, as well as large medical institutions, disease research institutions, etc. As medical institutions and research institutes often have certain authority and rich hardware resources, some of them will be selected by the supervision center as IBFT consensus nodes to maintain the blockchain. The consortium blockchain is defined to accept only four types of transactions:Tauthorize for identity authentication; Tupload for new record upload; Taccess for access control management; and Tupdate for access policy update.Supervision centerS: The supervision center S acts as an administrator of the data sharing system. The S is responsible for initializing the consortium blockchain network and deploying smart contracts on it. The S also needs to verify the identities of users who want to join the network.Storage server: The storage server is responsible for executing the instructions of storage and access issued by users. After users upload their data, the storage server will return location information from which the encrypted record can be accessed, such as the URL returned by dropbox or the hash returned by IPFS [37].Record ownerO: The record owner O is a patient who owns a number of medical records and intends to share his medical records. The Os define access policies for their medical records to enforce access control. The Os store their medical records in a hybrid mode, that is, the raw records are encrypted and stored on the storage server, while the access policy, storage location, and other information are uploaded to the blockchain.Record requesterℛ: A record requester ℛ can be a doctor who needs to view a case of a patient or an institution conducting a case study of an infectious disease. To join the consortium blockchain network, the ℛ needs to register with the S to obtain an attribute certificate. An ℛ can access the owners’ medical records if it has satisfiable authority.Figure 2
System framework of the proposed scheme.


### 4.1.2. Workflow

As illustrated in Figure2, the workflow of this scheme can be summarized into five phases, namely system establishment, identity authentication, record generation and upload, record access, and access policy update.(1)
System establishment: In this phase, the supervision center initializes the consortium blockchain network and deploys smart contracts on it (as step ① in Figure2).(2)
Identity authentication: In this phase, each user who wants to join the network submits real-life identification materials to theS (as step ② in Figure 2). The S will issue a certificate to the user after verifying the authenticity and validity of identification materials (as step ③). The S also initiates an authorization transaction to record the attributes of the registrant on blockchain (as step ④).(3)
Record generation and upload: In this phase, theO encrypts his medical record and submits the encrypted medical record to the storage server (as step ⑤). The O also defines an access policy for medical record and anchors it to blockchain by initiating an upload transaction (as step ⑥).(4)
Record access: This phase allows theℛ to request access to the O’s medical record by initiating an access transaction (as step ⑦). If the ℛ’s attributes meet the access policy of record, the access request is accepted and the O will secretly transmit the decryption key to the ℛ (as step ⑧). The ℛ can download the encrypted record from the storage server and decrypt it (as step ⑨).(5)
Access policy update: This phase enables theO to make changes to the access policy of the uploaded records by initiating an access transaction (as step ⑩).


## 4.1.1. Entities

As illustrated in Figure2, the key entities of our scheme can be listed as: blockchain, supervision center, storage server, record owner, and record requester.Blockchain: We utilize consortium blockchain in this scheme, and choose IBFT, a PBFT variant algorithm, as the consensus algorithm. The identity of nodes in the consortium blockchain needs to be authenticated, so there is a certain trust foundation between members. The members in the blockchain network can be ordinary users such as doctors and patients, as well as large medical institutions, disease research institutions, etc. As medical institutions and research institutes often have certain authority and rich hardware resources, some of them will be selected by the supervision center as IBFT consensus nodes to maintain the blockchain. The consortium blockchain is defined to accept only four types of transactions:Tauthorize for identity authentication; Tupload for new record upload; Taccess for access control management; and Tupdate for access policy update.Supervision centerS: The supervision center S acts as an administrator of the data sharing system. The S is responsible for initializing the consortium blockchain network and deploying smart contracts on it. The S also needs to verify the identities of users who want to join the network.Storage server: The storage server is responsible for executing the instructions of storage and access issued by users. After users upload their data, the storage server will return location information from which the encrypted record can be accessed, such as the URL returned by dropbox or the hash returned by IPFS [37].Record ownerO: The record owner O is a patient who owns a number of medical records and intends to share his medical records. The Os define access policies for their medical records to enforce access control. The Os store their medical records in a hybrid mode, that is, the raw records are encrypted and stored on the storage server, while the access policy, storage location, and other information are uploaded to the blockchain.Record requesterℛ: A record requester ℛ can be a doctor who needs to view a case of a patient or an institution conducting a case study of an infectious disease. To join the consortium blockchain network, the ℛ needs to register with the S to obtain an attribute certificate. An ℛ can access the owners’ medical records if it has satisfiable authority.Figure 2
System framework of the proposed scheme.


## 4.1.2. Workflow

As illustrated in Figure2, the workflow of this scheme can be summarized into five phases, namely system establishment, identity authentication, record generation and upload, record access, and access policy update.(1)
System establishment: In this phase, the supervision center initializes the consortium blockchain network and deploys smart contracts on it (as step ① in Figure2).(2)
Identity authentication: In this phase, each user who wants to join the network submits real-life identification materials to theS (as step ② in Figure 2). The S will issue a certificate to the user after verifying the authenticity and validity of identification materials (as step ③). The S also initiates an authorization transaction to record the attributes of the registrant on blockchain (as step ④).(3)
Record generation and upload: In this phase, theO encrypts his medical record and submits the encrypted medical record to the storage server (as step ⑤). The O also defines an access policy for medical record and anchors it to blockchain by initiating an upload transaction (as step ⑥).(4)
Record access: This phase allows theℛ to request access to the O’s medical record by initiating an access transaction (as step ⑦). If the ℛ’s attributes meet the access policy of record, the access request is accepted and the O will secretly transmit the decryption key to the ℛ (as step ⑧). The ℛ can download the encrypted record from the storage server and decrypt it (as step ⑨).(5)
Access policy update: This phase enables theO to make changes to the access policy of the uploaded records by initiating an access transaction (as step ⑩).


## 4.2. Threat Model

We assume that all the adversaries have bounded computational capability, so they cannot break the security properties of the blockchain and the cryptographic tools used in our scheme. The supervision center and record owners are assumed to be trusted and will exactly follow the protocol. We also consider the following threats:(i)
Semi-trusted storage server: We assumed that the storage server is semi-trusted, that is, honest but curious. It will honestly follow the protocol, but it is also curious about users’ private data and tries to learn any information from the data stored on the server.(ii)
Unauthorized access attack: We also consider the record requesters may be malicious that attempts to break data access control. Specifically, the adversary might collude with the storage server to gain some content of medical records out of its authority.(iii)
Standard Byzantine threat model: In our design, medical institutions work as consensus nodes to execute IBFT protocol to generate new blocks. We consider a Byzantine adversary who may cause faulty nodes to exhibit arbitrary behavior (drop, delay, reorder). However, we assume the assumptions hold: the number of Byzantine nodes in IBFT-based consensus does not exceed one-third of the total consensus members.


## 4.3. Design Goals

The design goals of our work are listed as follows:(i)
Access control: Medical records should be enforced by fine-grained access control so that only authorized users can access.(ii)
Integrity and confidentiality: Raw data are stored on a semi-honest storage server, so it is critical to keep information from being corrupted or modified and accessed without authorization during transmission and storage.(iii)
Auditability: Various operations on medical records such as uploading, updating, and accessing should be recorded in a tamper-resistant way, making them easy to be audited.(iv)
Key management: When a user has a large number of medical records, there is a corresponding need for multiple symmetric keys, so we believe that efficient key management is of necessity.


## 4.4. Key Management

To facilitate key management, a hierarchical tree structure is introduced in this article. Patients can classify the diseases they suffer from based on the types of diseases (refer to the departments’ setting structure of a hospital) and build their own medical record tree with a hierarchical classification of diseases.


### 4.4.1. Medical Record Tree

We now describe how a patient creates his own medical record tree, taking Figure3 for example. The patient chooses a master key and takes it as the root node of a tree. Each leaf node of the tree is described by a medical record of the patient. Each interior node of the tree represents the hierarchical classification of a medical record. The hierarchical relationship of the interior node can refer to departments’ setting structure of a hospital.Figure 3
Example of medical record tree: the number of a node is highlighted in orange, for the leaf node associated with the medical recordEMR6 (marked by blue box), index=1223 (marked by red box).To facilitate working with the tree, an ordering is defined between the children of each non-leaf node. That is, the children of a non-leaf node are numbered in serial order starting from 1. Specifically, the number of the root node is set to 1. In Figure3, the number of a node is highlighted in orange. Besides, for each leaf node, let index denote the concatenation of numbers of all nodes on the shortest path from the root node to the leaf node. For example, in Figure 3, the index of leaf node associated with the medical record EMR6 (marked with blue boxes) is: 1223 (marked with red boxes).


### 4.4.2. Generating Keys from the Medical Record Tree

With a medical record tree, the patient can generate keys for all medical record in the tree. For a leaf node, the key of its associated medical record can be calculated as follows:(1)Hmaster key‖index,where “ ∥” indicates concatenation.


## 4.4.1. Medical Record Tree

We now describe how a patient creates his own medical record tree, taking Figure3 for example. The patient chooses a master key and takes it as the root node of a tree. Each leaf node of the tree is described by a medical record of the patient. Each interior node of the tree represents the hierarchical classification of a medical record. The hierarchical relationship of the interior node can refer to departments’ setting structure of a hospital.Figure 3
Example of medical record tree: the number of a node is highlighted in orange, for the leaf node associated with the medical recordEMR6 (marked by blue box), index=1223 (marked by red box).To facilitate working with the tree, an ordering is defined between the children of each non-leaf node. That is, the children of a non-leaf node are numbered in serial order starting from 1. Specifically, the number of the root node is set to 1. In Figure3, the number of a node is highlighted in orange. Besides, for each leaf node, let index denote the concatenation of numbers of all nodes on the shortest path from the root node to the leaf node. For example, in Figure 3, the index of leaf node associated with the medical record EMR6 (marked with blue boxes) is: 1223 (marked with red boxes).


## 4.4.2. Generating Keys from the Medical Record Tree

With a medical record tree, the patient can generate keys for all medical record in the tree. For a leaf node, the key of its associated medical record can be calculated as follows:(1)Hmaster key‖index,where “ ∥” indicates concatenation.


## 4.5. Construction

In this section, we will describe the construction of the scheme in detail and show how to use the features of blockchain and smart contract to achieve the privacy protection and secure sharing of medical data.The cryptographic hash functionH used in our system is implemented by SHA256, the symmetric encryption algorithm Encsym,Decsym is implemented using AES, and the asymmetric encryption algorithm Encasym,Decasym and the signature algorithm Sig,Ver are implemented using ECC with secp256k1 curve.


### 4.5.1. System Establishment

In the system establishment stage, theS first creates a blockchain account for itself, where the public-private key pair is denoted as pkS,skS, and the account address derive from the public key pkS is denoted as addrS. The S selects a number of hospitals and research institutes as consensus nodes, which are authoritative or have a high reputation score counted by a reputation management system. The S also deploys smart contracts on the consortium blockchain network—Authorize, MedicalRecord, and AccessControl—the details of which are described in Section 4.6.


### 4.5.2. Identity Authentication

To join in the consortium blockchain network, each user (ℛ and O) needs to apply for identity registration with the supervision center S. Before that, each ℛ or O chooses a pair of public and private key, denoted as pkℛ,skℛ or pkO,skO. Then, an application for registration Register and a signature σ on Register can be submitted to the S,(2)Register=pkℛ/O,identification materials,σ=Sigskℛ/ORegister..A registration applicationRegister should include his public key pkℛ/O, identification materials that can prove the real-life role. The S will verify the registrant’s signature,(3)0,1=Verpkℛ/ORegister,σ,and the authenticity and validity of the identification materials. If the verification passes, the S formalize the registrant’s role as a set of descriptive attributes Att according to the provided identification materials,(4)Att=att1,att2,att3⋯,where atti∈U. Also, the S derives a blockchain account address from the registrant’s public key pkℛ/O, denoted as addrO or addrℛ. Then, a certificate Cert along with the S’s signature σ on it will be issued to the registrant,(5)Cert=addrℛ/O,Att,σ′=SigskSCert.TheS also initiates an authorization transaction Tauthorize to the consortium blockchain network. The transaction structure is shown as Table 1.Table 1
The authorization transactionTauthorize.
Tauthorizefrom:addrSto:Authorizedata:addrℛ/O,Attsig:SigskSTauthorizeThis transaction will trigger the interface setAuthorization() of the smart contract Authorize, by which registrant’s attribute authorization information will automatically be stored in smart contract.Upon receipt of the certificate, the registrant will verify the signature of theS to confirm the integrity of the certificate and the authenticity of its source,(6)0,1=VerpkSCert,σ′.


### 4.5.3. Record Generation and Upload

When the patient goes to the hospital for medical treatment or examination, a medical recordM will be generated and given to the patient. Patients can share their historical medical data with doctors for more accurate treatment or research institutions for case studies. To protect the privacy of medical data when sharing, it is often necessary to encrypt it.The key management method is described in Section4.4; the patient, that is the record owner O, first creates a medical record tree with his master key MK and all historical medical records as Figure 3. For a medical record M with index index in the tree, generates the subkey(7)K=HMK‖index.To share the medical recordM, the O takes K as the symmetric key and calculates(8)CTM=EncKsymM,h=HCTM.TheO uploads CTM to the storage server, which will return the storage location location. The O records the ciphertext hash h and the storage location location.In order to control the access privilege of medical record, theO specifies an attribute-based d,n−threshold access policy for his record,(9)Policy=att1,att2,att3⋯,threshold=d,where Policy=n, atti∈U, U is the universe of possible attributes. The medical record can only be accessed if the number of identical attributes in requester’s attributes set and access policy is equal to or greater than the threshold.(10)Policy∩Att≥d.TheO assembles policy, threshold, index,h, location,metadata as an upload transaction Tupload, where metadata can be a few keywords for the record or a simple description of the condition, Then Tupload is broadcast to the consortium blockchain network. The structure of Tupload is shown as Table 2.Table 2
The upload transactionTupload.
Tuploadfrom:addrOto:MedicalRecorddata:policy,threshold,index, h,location,metadatasig:SigskOTuploadThis transaction will trigger the interface uploadRecord() of the smart contract MedicalRecord, by which transaction data related to the medical record will be automatically stored in the smart contact.


### 4.5.4. Record Access

The data on blockchain is available to members of the consortium, and the requesters can monitor the blockchain to find medical resources of interest. When a requesterℛ would like to access a medical record written in an upload transaction Tupload with transaction ID txid, he can determine for himself whether his attributes set satisfy the access policy recorded in the transaction. If yes, he assembles an access request transaction Taccess as Table 3 and broadcasts it on the consortium blockchain network.Table 3
The access transactionTaccess.
Taccessfrom:addrℛto:AccessControldata:addrO,txidsig:SigskℛTaccessThis transaction will trigger the interface requestAccess() of the smart contract AccessControl, which automatically check whether the attributes of the requesterℛ satisfy the access policy in the transaction txid, that is, if the following condition holds:(11)Policy∩Att≥d.If not, the access request will be denied; otherwise, the request will be accepted and the result will be recorded in the event log.Once theO of the medical record listens for an authorized access request event, he uses the ℛ’s public key pkℛ to encrypt the symmetric key K of the medical record,(12)CTK=EncpkℛasymK,then sends CTK to the ℛ by an off-chain communication channel.After receivingCTK, the ℛ decrypts CTK with his private key skℛ,(13)K=DecskℛasymCTK.Further, theℛ downloads the encrypted record CTM according to the location information in transaction Tupload and calculates(14)h′=HCTM,to check if h=h′ holds. If it does, make the final decryption(15)M=DecKsymCTM,to get the raw medical record M.


### 4.5.5. Access Policy Update

Although the data on the blockchain are tamper resistant, theO can broadcast a new transaction to update the access policy. The consensus nodes always verify the permissions based on the latest transactions, thereby enabling the O to update the access policy for the records on the blockchain. To update the access policy, the O assembles txid,policy′ as a policy update transaction Tupdate, where txid is the upload transaction ID where the medical record needs to be updated, policy′ is the new access policy, and broadcasts Tupdate to the blockchain network. The transaction structure is shown as Table 4.Table 4
The policy update transactionTupdate.
Tupdatefrom:addrOto:MedicalRecorddata:txid,policy′sig:SigskOTupdateThis transaction will trigger the interface updateRecord() of the smart contract MedicalRecord, which automatically performs policy updates.


## 4.5.1. System Establishment

In the system establishment stage, theS first creates a blockchain account for itself, where the public-private key pair is denoted as pkS,skS, and the account address derive from the public key pkS is denoted as addrS. The S selects a number of hospitals and research institutes as consensus nodes, which are authoritative or have a high reputation score counted by a reputation management system. The S also deploys smart contracts on the consortium blockchain network—Authorize, MedicalRecord, and AccessControl—the details of which are described in Section 4.6.


## 4.5.2. Identity Authentication

To join in the consortium blockchain network, each user (ℛ and O) needs to apply for identity registration with the supervision center S. Before that, each ℛ or O chooses a pair of public and private key, denoted as pkℛ,skℛ or pkO,skO. Then, an application for registration Register and a signature σ on Register can be submitted to the S,(2)Register=pkℛ/O,identification materials,σ=Sigskℛ/ORegister..A registration applicationRegister should include his public key pkℛ/O, identification materials that can prove the real-life role. The S will verify the registrant’s signature,(3)0,1=Verpkℛ/ORegister,σ,and the authenticity and validity of the identification materials. If the verification passes, the S formalize the registrant’s role as a set of descriptive attributes Att according to the provided identification materials,(4)Att=att1,att2,att3⋯,where atti∈U. Also, the S derives a blockchain account address from the registrant’s public key pkℛ/O, denoted as addrO or addrℛ. Then, a certificate Cert along with the S’s signature σ on it will be issued to the registrant,(5)Cert=addrℛ/O,Att,σ′=SigskSCert.TheS also initiates an authorization transaction Tauthorize to the consortium blockchain network. The transaction structure is shown as Table 1.Table 1
The authorization transactionTauthorize.
Tauthorizefrom:addrSto:Authorizedata:addrℛ/O,Attsig:SigskSTauthorizeThis transaction will trigger the interface setAuthorization() of the smart contract Authorize, by which registrant’s attribute authorization information will automatically be stored in smart contract.Upon receipt of the certificate, the registrant will verify the signature of theS to confirm the integrity of the certificate and the authenticity of its source,(6)0,1=VerpkSCert,σ′.


## 4.5.3. Record Generation and Upload

When the patient goes to the hospital for medical treatment or examination, a medical recordM will be generated and given to the patient. Patients can share their historical medical data with doctors for more accurate treatment or research institutions for case studies. To protect the privacy of medical data when sharing, it is often necessary to encrypt it.The key management method is described in Section4.4; the patient, that is the record owner O, first creates a medical record tree with his master key MK and all historical medical records as Figure 3. For a medical record M with index index in the tree, generates the subkey(7)K=HMK‖index.To share the medical recordM, the O takes K as the symmetric key and calculates(8)CTM=EncKsymM,h=HCTM.TheO uploads CTM to the storage server, which will return the storage location location. The O records the ciphertext hash h and the storage location location.In order to control the access privilege of medical record, theO specifies an attribute-based d,n−threshold access policy for his record,(9)Policy=att1,att2,att3⋯,threshold=d,where Policy=n, atti∈U, U is the universe of possible attributes. The medical record can only be accessed if the number of identical attributes in requester’s attributes set and access policy is equal to or greater than the threshold.(10)Policy∩Att≥d.TheO assembles policy, threshold, index,h, location,metadata as an upload transaction Tupload, where metadata can be a few keywords for the record or a simple description of the condition, Then Tupload is broadcast to the consortium blockchain network. The structure of Tupload is shown as Table 2.Table 2
The upload transactionTupload.
Tuploadfrom:addrOto:MedicalRecorddata:policy,threshold,index, h,location,metadatasig:SigskOTuploadThis transaction will trigger the interface uploadRecord() of the smart contract MedicalRecord, by which transaction data related to the medical record will be automatically stored in the smart contact.


## 4.5.4. Record Access

The data on blockchain is available to members of the consortium, and the requesters can monitor the blockchain to find medical resources of interest. When a requesterℛ would like to access a medical record written in an upload transaction Tupload with transaction ID txid, he can determine for himself whether his attributes set satisfy the access policy recorded in the transaction. If yes, he assembles an access request transaction Taccess as Table 3 and broadcasts it on the consortium blockchain network.Table 3
The access transactionTaccess.
Taccessfrom:addrℛto:AccessControldata:addrO,txidsig:SigskℛTaccessThis transaction will trigger the interface requestAccess() of the smart contract AccessControl, which automatically check whether the attributes of the requesterℛ satisfy the access policy in the transaction txid, that is, if the following condition holds:(11)Policy∩Att≥d.If not, the access request will be denied; otherwise, the request will be accepted and the result will be recorded in the event log.Once theO of the medical record listens for an authorized access request event, he uses the ℛ’s public key pkℛ to encrypt the symmetric key K of the medical record,(12)CTK=EncpkℛasymK,then sends CTK to the ℛ by an off-chain communication channel.After receivingCTK, the ℛ decrypts CTK with his private key skℛ,(13)K=DecskℛasymCTK.Further, theℛ downloads the encrypted record CTM according to the location information in transaction Tupload and calculates(14)h′=HCTM,to check if h=h′ holds. If it does, make the final decryption(15)M=DecKsymCTM,to get the raw medical record M.


## 4.5.5. Access Policy Update

Although the data on the blockchain are tamper resistant, theO can broadcast a new transaction to update the access policy. The consensus nodes always verify the permissions based on the latest transactions, thereby enabling the O to update the access policy for the records on the blockchain. To update the access policy, the O assembles txid,policy′ as a policy update transaction Tupdate, where txid is the upload transaction ID where the medical record needs to be updated, policy′ is the new access policy, and broadcasts Tupdate to the blockchain network. The transaction structure is shown as Table 4.Table 4
The policy update transactionTupdate.
Tupdatefrom:addrOto:MedicalRecorddata:txid,policy′sig:SigskOTupdateThis transaction will trigger the interface updateRecord() of the smart contract MedicalRecord, which automatically performs policy updates.


## 4.6. Smart Contract Design

In this section, we mainly introduce the smart contract-related interface and algorithm logic used in this article. Smart contracts are coded in the programming language Solidity [38]. The smart contracts we designed include Authorize contract, MedicalRecord contract, and AccessControl contract.


### 4.6.1. Authorize Contract

The Authorize contract is deployed by theS, and the contract design can be seen in Figure 4. Through the contract, tamper-resistant information is written on the blockchain to enable authorization for organizations and users.(1)
Authorize contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The authorizedUsers variable of mapping types, which defines a mapping collection from authorized user addresses to the string of attribute set. TheS can add, modify, and delete the collection through the relevant function interfaces of the contract.(2)
Authorize contract interfaces. The following two function interfaces are provided in the Authorize contract:(a)
setAuthorization (address, attributeSet): This function can only be executed by the S. When the S authorizes organizations and users, the authorized account address will be added to the authorizedUsers variable. This function can be used to add, modify, or delete authorizations for organizations and users. The attribute set string is set to the corresponding attribute values.(b)
getAuthorization (address): This function can be executed by anyone. We can use the function to query the attribute set of a specific account address. The type of the function is constant, meaning it does not modify the state of the blockchain.Figure 4
Pseudocode for Authorize contract.


### 4.6.2. MedicalRecord Contract

The MedicalRecord contract is deployed by theS, and the contract design can be seen in Figure 5. Through the contract, we can upload medical records, update access policy, or obtain the metadata information of medical records.(1)
MedicalRecord contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The MedRec variable of custom data struct types, which defines the structure of a medical record, containing variables like policy, threshold, index, hash, location, and metadata.(c)
The MedRec variable of mapping types, which a mapping collection from user address to the array of struct MedRec.(2)
MedicalRecord contract interfaces: The following four function interfaces are provided in the MedicalRecord contract.(a)
uploadRecord(policy, threshold, index, hash, location, metadata): The function can be executed by anyone. It is used to upload the metadata information of medical records. A serious limitation of this is that one can only add the medical record collection corresponding to one’s own address.(b)
updateRecord(location, newPolicy): The function can be executed by anyone. It is used to update the access policies of medical records. A serious limitation of this is that one can only update the access policies of medical record collection corresponding to one’s own address.(c)
getRecord(): This function is used to obtain the metadata information of medical records already uploaded. The type of the function is constant, meaning it does not modify the state of the blockchain.(d)
getAccessPolicy(address, location): This function is used to obtain the access policy of medical record that the account address and location are specified.Figure 5
Pseudocode for MedicalRecord contract.


### 4.6.3. AccessControl Contract

The AccessControl contract is deployed byS, and the contract design can be seen in Figure 6. Through the contract, one can issue access request or obtain the access history of medical record.(1)
AccessControl contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The AccessStruct variable of custom data struct types, which defines the structure of an access, containing variables like txid, time, and requester.(c)
The access variable of mapping types, which defines a mapping collection from authorized user address to the array of struct AccessStruct.(d)
The object instance medicalRecord of MedicalRecord contract. In the AccessControl contract, the getAccessPolicy function of the MedicalRecord contract needs to be invoked. Therefore, a MedicalRecord contract object instance needs to be initialized.(e)
The object instance authorize of Authorize contract. In the AccessControl contract, the getAuthorization function of the Authorize contract needs to be invoked. Therefore, a Authorize contract object instance needs to be initialized.(2)
AccessControl contract interfaces: The following function interfaces are provided in the AccessControl contract.(a)
setContract(address of MedicalRecord contract, address of Authorize contract): The function is used to set the address of the Authorize instance and the address of the MedicalRecord instance.(b)
requestAccess(address, txid, location): The function is used to issue an access request for a medical record. The access history will be recorded on the blockchain.(c)
getAccessRequest(): The function is used to obtain the access history of medical records.Figure 6
Pseudocode for AccessControl contract.


## 4.6.1. Authorize Contract

The Authorize contract is deployed by theS, and the contract design can be seen in Figure 4. Through the contract, tamper-resistant information is written on the blockchain to enable authorization for organizations and users.(1)
Authorize contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The authorizedUsers variable of mapping types, which defines a mapping collection from authorized user addresses to the string of attribute set. TheS can add, modify, and delete the collection through the relevant function interfaces of the contract.(2)
Authorize contract interfaces. The following two function interfaces are provided in the Authorize contract:(a)
setAuthorization (address, attributeSet): This function can only be executed by the S. When the S authorizes organizations and users, the authorized account address will be added to the authorizedUsers variable. This function can be used to add, modify, or delete authorizations for organizations and users. The attribute set string is set to the corresponding attribute values.(b)
getAuthorization (address): This function can be executed by anyone. We can use the function to query the attribute set of a specific account address. The type of the function is constant, meaning it does not modify the state of the blockchain.Figure 4
Pseudocode for Authorize contract.


## 4.6.2. MedicalRecord Contract

The MedicalRecord contract is deployed by theS, and the contract design can be seen in Figure 5. Through the contract, we can upload medical records, update access policy, or obtain the metadata information of medical records.(1)
MedicalRecord contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The MedRec variable of custom data struct types, which defines the structure of a medical record, containing variables like policy, threshold, index, hash, location, and metadata.(c)
The MedRec variable of mapping types, which a mapping collection from user address to the array of struct MedRec.(2)
MedicalRecord contract interfaces: The following four function interfaces are provided in the MedicalRecord contract.(a)
uploadRecord(policy, threshold, index, hash, location, metadata): The function can be executed by anyone. It is used to upload the metadata information of medical records. A serious limitation of this is that one can only add the medical record collection corresponding to one’s own address.(b)
updateRecord(location, newPolicy): The function can be executed by anyone. It is used to update the access policies of medical records. A serious limitation of this is that one can only update the access policies of medical record collection corresponding to one’s own address.(c)
getRecord(): This function is used to obtain the metadata information of medical records already uploaded. The type of the function is constant, meaning it does not modify the state of the blockchain.(d)
getAccessPolicy(address, location): This function is used to obtain the access policy of medical record that the account address and location are specified.Figure 5
Pseudocode for MedicalRecord contract.


## 4.6.3. AccessControl Contract

The AccessControl contract is deployed byS, and the contract design can be seen in Figure 6. Through the contract, one can issue access request or obtain the access history of medical record.(1)
AccessControl contract initialization: This process defines some variables of the contract when the contract is created.(a)
The supervisionCenter variable of address types, which defines the address of theS. This variable defines the address of the S and is initialized when the contract is created.(b)
The AccessStruct variable of custom data struct types, which defines the structure of an access, containing variables like txid, time, and requester.(c)
The access variable of mapping types, which defines a mapping collection from authorized user address to the array of struct AccessStruct.(d)
The object instance medicalRecord of MedicalRecord contract. In the AccessControl contract, the getAccessPolicy function of the MedicalRecord contract needs to be invoked. Therefore, a MedicalRecord contract object instance needs to be initialized.(e)
The object instance authorize of Authorize contract. In the AccessControl contract, the getAuthorization function of the Authorize contract needs to be invoked. Therefore, a Authorize contract object instance needs to be initialized.(2)
AccessControl contract interfaces: The following function interfaces are provided in the AccessControl contract.(a)
setContract(address of MedicalRecord contract, address of Authorize contract): The function is used to set the address of the Authorize instance and the address of the MedicalRecord instance.(b)
requestAccess(address, txid, location): The function is used to issue an access request for a medical record. The access history will be recorded on the blockchain.(c)
getAccessRequest(): The function is used to obtain the access history of medical records.Figure 6
Pseudocode for AccessControl contract.


## 5. Performance Analysis

### 5.1. Security Analysis

In this section, we present our analysis of the security. The proposed scheme can satisfy all the security requirements described in Section3.3, based on the designed transactions, smart contacts, blockchain, and the exploited cryptographic schemes.


#### 5.1.1. Access Control

In the proposed scheme, we adopt ad,n-threshold access control structure and employ smart contract to automate the matching of access policies and attribute sets. A record owner can preset the access policy for his medical record as Policy=att1,att2,att3⋯, threshold=d. Each record requester is also assigned a set of attributes Att=att1,att2,att3⋯, based on his identity and role in reality. The attribute set of a requester is considered to satisfy an access policy only when Policy∩Att≥d. It should be noted that we stored the access policies and attribute sets on smart contract. Thus, access control can be automatically executed by smart contract, ensuring that only requesters whose attribute sets satisfy the access policy of a record can obtain access permissions. The fine-grained access control is thus realized.


#### 5.1.2. Key Management

In our proposal, a tree storage structure named medical record tree is devised to provide owners with efficient key management. An owner can construct his own medical record tree according to the hierarchical structure of his medical records. The tree takes master key as root and medical records as its leaf nodes. And for a medical record, index is denoted as a cascade of node numbers on the shortest path to the root. With the medical record tree, the owner can further generate a subkey for a record:Hmaster key‖index. Instead of recording each subkey, he only needs to keep his medical record tree, and then he can deduce the corresponding subkey of each record. In this way, the efficient management of symmetric key can be realized.


#### 5.1.3. Confidentiality

The symmetric encryption algorithm AES utilized in our proposal can prevent medical records from being accessed without owners’ permission. Note that the raw medical recordM is encrypted with symmetric key K by the symmetric encryption algorithm, CTM=EncKsymM, and encrypted medical record CTM is uploaded to the storage sever. Even if the storage server is compromised and CTM stored on the server is obtained illegally, no meaningful information can be revealed without the corresponding symmetric key K. The symmetric key is kept secretly by the owner. When someone requests to access the medical record, the owner will send the requester the decryption key only if he has access authorization, which ensures that the owners’ medical records are not exposed to the unauthorized users. Thus, the confidentiality of owners’ medical records can be guaranteed.


#### 5.1.4. Integrity

The immutability and transparency of blockchain and the hash algorithm used ensure the integrity of medical records. The hash values of encrypted medical records,h=HCTM, are published on the blockchain, and it cannot be modified once the block is chained. Any user in the blockchain network can confirm the integrity of medical records stored on storage server by comparing their hash value h’ with h on the blockchain. In other words, once owners’ records are tampered with or corrupted, it can be detected immediately. That ensures data integrity.


#### 5.1.5. Auditability

In our design, there are four types of transactions in blockchain, namely,Tauthorize, Tupload, Taccess, and Tupdate. Before a transaction can be packaged, it must be signed by the transaction initiator. Through the transaction logs of the blockchain, any behaviors of users can be audited. Specifically, the auditability for access history of medical records is also provided leveraging smart contact. So that owners can check who and when they have accessed their medical records.


### 5.2. Compared with the Similar Schemes

We compare the characteristics of our scheme with several state-of-the-art blockchain-based works for secure data sharing. The results are given in Table5.Table 5
Comparison of the functions of similar schemes.
SchemeConsensus mechanismAccess controlKey managementData confidentialityData integrityData auditabilitySimulation experimentAzaria’s [16]PowCoarse grained, through time×××✓×Liang’s [25]PBFTCoarse grained, through channels×××✓✓Wang’s [30]PoSFine grained, through attribute×✓✓×✓OursIBFTFine grained, through attribute✓✓✓✓✓From the perspective of consensus mechanism, the proposed scheme uses IBFT, an improved algorithm of PBFT. IBFT and PBFT have significantly better block output speed than PoW and PoS. In addition, in contrast to PBFT, IBFT does not need a specified client to send requests and wait for responses, and each verifier can be considered a client. Therefore, the adoption of IBFT mechanism can greatly increase the throughput of the consortium blockchain.In terms of access control, the scheme [16] achieves access restrictions from the time dimension, the scheme [25] realizes access control through the channel in the fabric. The scheme [30] and our scheme supports fine-grained access policy-based attributes. In particular, our scheme supports the update of access policy. In our scheme and scheme [30], the data owners have full control over their data. While in other schemes, the access permission is authorized by a central authority, which can decrypt all the data when they compromise.It can be seen that none of the other solutions can realize efficient key management except for ours. Furthermore, our scheme achieves data confidentiality, data integrity, data auditability, and detailed simulation experiments.


### 5.3. Efficiency Evaluation

In this section, we will evaluate the performance of off-chain operation, which mainly involves cryptography algorithms. Here, we conduct our implementation for hash function, symmetric encryption, asymmetric encryption, and signature using SHA256, AES, ECELG, and ECDSA, respectively. In particular, the standardized elliptic curve secp256k1 is selected for ECC algorithm. Performance evaluation will be carried out in terms of computing cost and communication cost, respectively.


#### 5.3.1. Computational Cost

Execution time is the most intuitive measure of computational complexity. First, we usePython to implement cryptography algorithms used in our scheme and estimate the time cost. Table 6 presents the run-time cost of our used cryptographic algorithm, which is metric on a 100-run basis.Table 6
Time cost of cryptographic algorithms.
AlgorithmSHA256AES.EncAES.DecECELG.EncECELG.DecECDSA.SigECDSA.VerMax time (s)0.0000260.0001600.0000830.0026870.0484120.0012800.003902Min time (s)0.0000190.0001460.0000630.0017020.0410220.0010110.003526Average time (s)0.0000220.0001580.0000770.0020560.0455290.0010700.003669Then, we summarize the cryptographic operations involved in each phase of the whole process. According to the corresponding running time costs in Table6, we estimate the time costs of each entity in each phase of the scheme, and the results are shown in Table 7. It can be observed that the execution time of the off-chain operation for each entity is less than 1 second, which is within the acceptable overhead range.Table 7
Time cost of each entity at each phase 0.76.
PhaseInvolved entityOperationTime cost (s)Identity authenticationOwner/requesterECDSA.Sig + ECDSA.Ver0.004739Supervise centerECDSA.Sig + ECDSA.Ver0.004739Record generation and uploadOwner2∗ SHA256 + AES.Enc0.000202Record accessOwnerECELG.Enc0.002056RequesterECELG.Dec + SHA256 + AES.Dec0.455389


#### 5.3.2. Communication Cost

In addition, we list the major communication costs between the entities, as shown in Table8. Here, bc and bs denote the bit size of ciphertext and signature data, respectively.Table 8
Communication cost between the entities.
EntitiesS&R/OO& serverR& serverR&OCommunication cost2∗bs.ECDSAbc.AESbc.AESbc.ECELGAs we can see, communication costs are directly affected bybc and bs. Since the signature size of ECDSA and ciphertext size of ECEGL are fixed when the elliptic curve is selected, communication cost between supervision center S and ℛ/O and between ℛ and O is close to constant. While the ciphertext size of AES is linearly and positively related to the plaintext size, communication costs between O and storage server and between ℛ and storage server are also positively related to the size of the plaintext. Combined with the real medical application scenarios, we believe that the size of plaintext, that is medical records, should not be overwhelming. In general, communication costs are also within acceptable loads.


### 5.4. Experimental Simulation

To show the feasibility of the scheme, we simulated the transactions of the proposed scheme through the smart contracts under the Quorum blockchain platform. Because the contracts are deployed on the consortium blockchain, we do not have to pay as much attention to the spending of gas that was consumed in the stage of transaction operations and contract deployment as in the Ethereum blockchain.Following the official 7-node example of Quorum [39], we setup a 7-nodes Quorum blockchain network with IBFT consensus on the Tencent cloud host, CentOS 7.6 system. Then we connected MetaMask-Chrome to the deployed Quorum blockchain network in the custom RPC mode with port 22000 and chainId 10. Next, we deployed smart contracts on Quorum blockchain network using Remix [40], that is, the Solidity online compiler, via the Injected Web3 connection.We regard a node with the address 0x951190d1fa0efcd6de9d1657d5c65caeaf421786 as the supervision centerS and use this node to compile and deploy three smart contracts of Authorize, MedicalRecord, and AccessControl in turn. After successfully deployed, the Authorize contract will provide the following two interfaces: setAuthorization() and getAuthorization(). The MedicalRecord contract will provide the following four interfaces: uploadRecord(), updateRecord(), getRecord(), and getAccessPolicy(). The AccessControl contract will provide the following three interfaces: setContract(), requestAccess(), and getAccessRequest().Using the contract’s address and ABI, we can interact with smart contracts deployed to the Quorum network. To perform a write operation, we need to send a transaction to trigger smart contract to update the stored value. To perform a read operation, the “get” function is called from the contracts’ list of methods. Next, we will test some of these interfaces and demonstrate the interaction with the contracts.A requesterℛ with account address 0xdd8af2f297143ae142e85ed40d1a17311031a5a2 is set to be a message sender. When the getAuthorization function is called, an empty string is obtained, as shown in Figure 7(a). It indicates that there is no permission for the requester.Figure 7
Get authorization information when (a) unauthorized and (b) authorized.
(a)(b)As shown in Figure7(b) , the requester first calls setAuthorize function with the inputs “0xdd8af2f297143ae142e85ed40d1a17311031a5a2”, and “Xi’an University of Technology ∣ School of Automation ∣ Lecturer”, and then calls getAuthorization function, and he will get the authorization information “Xi’an University of Technology ∣ School of Automation ∣ Lecturer”. Here we use the symbol “∣” to connect the attribute.In MedicalRecord contract, as shown in Figure8(a), the patient can upload the related information of medical record through the uploadRecord function, including policy, index, provider, hash, location, and metadata. After the medical record is uploaded, one can view the corresponding access policy by calling the getAccessPolicy function, as shown in Figure 8(b). Through the updateRecord function, the patient can update the corresponding access policy of the medical record uploaded by himself, as shown in Figure 9(a). Figure 9(b) shows the updated access policy by calling getAccessPolicy.Figure 8
Upload records. (a) Upload. (b) Get access policy.
(a)(b)Figure 9
Update access policy. (a) Update. (b) Get access policy.
(a)(b)As shown in Figure10(a), after a patient uploads his medical record, the patient can obtain the medical record uploaded by calling the getRecord function. The symbol “ ∥” is used as the segmentation symbol of the record. As shown in Figure 10(b), the patient can view the access history of their medical records by calling the getAccessRequest function.Figure 10
Get medical records and access history. (a) Get medical record. (b) Get access history.
(a)(b)


## 5.1. Security Analysis

In this section, we present our analysis of the security. The proposed scheme can satisfy all the security requirements described in Section3.3, based on the designed transactions, smart contacts, blockchain, and the exploited cryptographic schemes.


### 5.1.1. Access Control

In the proposed scheme, we adopt ad,n-threshold access control structure and employ smart contract to automate the matching of access policies and attribute sets. A record owner can preset the access policy for his medical record as Policy=att1,att2,att3⋯, threshold=d. Each record requester is also assigned a set of attributes Att=att1,att2,att3⋯, based on his identity and role in reality. The attribute set of a requester is considered to satisfy an access policy only when Policy∩Att≥d. It should be noted that we stored the access policies and attribute sets on smart contract. Thus, access control can be automatically executed by smart contract, ensuring that only requesters whose attribute sets satisfy the access policy of a record can obtain access permissions. The fine-grained access control is thus realized.


### 5.1.2. Key Management

In our proposal, a tree storage structure named medical record tree is devised to provide owners with efficient key management. An owner can construct his own medical record tree according to the hierarchical structure of his medical records. The tree takes master key as root and medical records as its leaf nodes. And for a medical record, index is denoted as a cascade of node numbers on the shortest path to the root. With the medical record tree, the owner can further generate a subkey for a record:Hmaster key‖index. Instead of recording each subkey, he only needs to keep his medical record tree, and then he can deduce the corresponding subkey of each record. In this way, the efficient management of symmetric key can be realized.


### 5.1.3. Confidentiality

The symmetric encryption algorithm AES utilized in our proposal can prevent medical records from being accessed without owners’ permission. Note that the raw medical recordM is encrypted with symmetric key K by the symmetric encryption algorithm, CTM=EncKsymM, and encrypted medical record CTM is uploaded to the storage sever. Even if the storage server is compromised and CTM stored on the server is obtained illegally, no meaningful information can be revealed without the corresponding symmetric key K. The symmetric key is kept secretly by the owner. When someone requests to access the medical record, the owner will send the requester the decryption key only if he has access authorization, which ensures that the owners’ medical records are not exposed to the unauthorized users. Thus, the confidentiality of owners’ medical records can be guaranteed.


### 5.1.4. Integrity

The immutability and transparency of blockchain and the hash algorithm used ensure the integrity of medical records. The hash values of encrypted medical records,h=HCTM, are published on the blockchain, and it cannot be modified once the block is chained. Any user in the blockchain network can confirm the integrity of medical records stored on storage server by comparing their hash value h’ with h on the blockchain. In other words, once owners’ records are tampered with or corrupted, it can be detected immediately. That ensures data integrity.


### 5.1.5. Auditability

In our design, there are four types of transactions in blockchain, namely,Tauthorize, Tupload, Taccess, and Tupdate. Before a transaction can be packaged, it must be signed by the transaction initiator. Through the transaction logs of the blockchain, any behaviors of users can be audited. Specifically, the auditability for access history of medical records is also provided leveraging smart contact. So that owners can check who and when they have accessed their medical records.


## 5.1.1. Access Control

In the proposed scheme, we adopt ad,n-threshold access control structure and employ smart contract to automate the matching of access policies and attribute sets. A record owner can preset the access policy for his medical record as Policy=att1,att2,att3⋯, threshold=d. Each record requester is also assigned a set of attributes Att=att1,att2,att3⋯, based on his identity and role in reality. The attribute set of a requester is considered to satisfy an access policy only when Policy∩Att≥d. It should be noted that we stored the access policies and attribute sets on smart contract. Thus, access control can be automatically executed by smart contract, ensuring that only requesters whose attribute sets satisfy the access policy of a record can obtain access permissions. The fine-grained access control is thus realized.


## 5.1.2. Key Management

In our proposal, a tree storage structure named medical record tree is devised to provide owners with efficient key management. An owner can construct his own medical record tree according to the hierarchical structure of his medical records. The tree takes master key as root and medical records as its leaf nodes. And for a medical record, index is denoted as a cascade of node numbers on the shortest path to the root. With the medical record tree, the owner can further generate a subkey for a record:Hmaster key‖index. Instead of recording each subkey, he only needs to keep his medical record tree, and then he can deduce the corresponding subkey of each record. In this way, the efficient management of symmetric key can be realized.


## 5.1.3. Confidentiality

The symmetric encryption algorithm AES utilized in our proposal can prevent medical records from being accessed without owners’ permission. Note that the raw medical recordM is encrypted with symmetric key K by the symmetric encryption algorithm, CTM=EncKsymM, and encrypted medical record CTM is uploaded to the storage sever. Even if the storage server is compromised and CTM stored on the server is obtained illegally, no meaningful information can be revealed without the corresponding symmetric key K. The symmetric key is kept secretly by the owner. When someone requests to access the medical record, the owner will send the requester the decryption key only if he has access authorization, which ensures that the owners’ medical records are not exposed to the unauthorized users. Thus, the confidentiality of owners’ medical records can be guaranteed.


## 5.1.4. Integrity

The immutability and transparency of blockchain and the hash algorithm used ensure the integrity of medical records. The hash values of encrypted medical records,h=HCTM, are published on the blockchain, and it cannot be modified once the block is chained. Any user in the blockchain network can confirm the integrity of medical records stored on storage server by comparing their hash value h’ with h on the blockchain. In other words, once owners’ records are tampered with or corrupted, it can be detected immediately. That ensures data integrity.


## 5.1.5. Auditability

In our design, there are four types of transactions in blockchain, namely,Tauthorize, Tupload, Taccess, and Tupdate. Before a transaction can be packaged, it must be signed by the transaction initiator. Through the transaction logs of the blockchain, any behaviors of users can be audited. Specifically, the auditability for access history of medical records is also provided leveraging smart contact. So that owners can check who and when they have accessed their medical records.


## 5.2. Compared with the Similar Schemes

We compare the characteristics of our scheme with several state-of-the-art blockchain-based works for secure data sharing. The results are given in Table5.Table 5
Comparison of the functions of similar schemes.
SchemeConsensus mechanismAccess controlKey managementData confidentialityData integrityData auditabilitySimulation experimentAzaria’s [16]PowCoarse grained, through time×××✓×Liang’s [25]PBFTCoarse grained, through channels×××✓✓Wang’s [30]PoSFine grained, through attribute×✓✓×✓OursIBFTFine grained, through attribute✓✓✓✓✓From the perspective of consensus mechanism, the proposed scheme uses IBFT, an improved algorithm of PBFT. IBFT and PBFT have significantly better block output speed than PoW and PoS. In addition, in contrast to PBFT, IBFT does not need a specified client to send requests and wait for responses, and each verifier can be considered a client. Therefore, the adoption of IBFT mechanism can greatly increase the throughput of the consortium blockchain.In terms of access control, the scheme [16] achieves access restrictions from the time dimension, the scheme [25] realizes access control through the channel in the fabric. The scheme [30] and our scheme supports fine-grained access policy-based attributes. In particular, our scheme supports the update of access policy. In our scheme and scheme [30], the data owners have full control over their data. While in other schemes, the access permission is authorized by a central authority, which can decrypt all the data when they compromise.It can be seen that none of the other solutions can realize efficient key management except for ours. Furthermore, our scheme achieves data confidentiality, data integrity, data auditability, and detailed simulation experiments.


## 5.3. Efficiency Evaluation

In this section, we will evaluate the performance of off-chain operation, which mainly involves cryptography algorithms. Here, we conduct our implementation for hash function, symmetric encryption, asymmetric encryption, and signature using SHA256, AES, ECELG, and ECDSA, respectively. In particular, the standardized elliptic curve secp256k1 is selected for ECC algorithm. Performance evaluation will be carried out in terms of computing cost and communication cost, respectively.


### 5.3.1. Computational Cost

Execution time is the most intuitive measure of computational complexity. First, we usePython to implement cryptography algorithms used in our scheme and estimate the time cost. Table 6 presents the run-time cost of our used cryptographic algorithm, which is metric on a 100-run basis.Table 6
Time cost of cryptographic algorithms.
AlgorithmSHA256AES.EncAES.DecECELG.EncECELG.DecECDSA.SigECDSA.VerMax time (s)0.0000260.0001600.0000830.0026870.0484120.0012800.003902Min time (s)0.0000190.0001460.0000630.0017020.0410220.0010110.003526Average time (s)0.0000220.0001580.0000770.0020560.0455290.0010700.003669Then, we summarize the cryptographic operations involved in each phase of the whole process. According to the corresponding running time costs in Table6, we estimate the time costs of each entity in each phase of the scheme, and the results are shown in Table 7. It can be observed that the execution time of the off-chain operation for each entity is less than 1 second, which is within the acceptable overhead range.Table 7
Time cost of each entity at each phase 0.76.
PhaseInvolved entityOperationTime cost (s)Identity authenticationOwner/requesterECDSA.Sig + ECDSA.Ver0.004739Supervise centerECDSA.Sig + ECDSA.Ver0.004739Record generation and uploadOwner2∗ SHA256 + AES.Enc0.000202Record accessOwnerECELG.Enc0.002056RequesterECELG.Dec + SHA256 + AES.Dec0.455389


### 5.3.2. Communication Cost

In addition, we list the major communication costs between the entities, as shown in Table8. Here, bc and bs denote the bit size of ciphertext and signature data, respectively.Table 8
Communication cost between the entities.
EntitiesS&R/OO& serverR& serverR&OCommunication cost2∗bs.ECDSAbc.AESbc.AESbc.ECELGAs we can see, communication costs are directly affected bybc and bs. Since the signature size of ECDSA and ciphertext size of ECEGL are fixed when the elliptic curve is selected, communication cost between supervision center S and ℛ/O and between ℛ and O is close to constant. While the ciphertext size of AES is linearly and positively related to the plaintext size, communication costs between O and storage server and between ℛ and storage server are also positively related to the size of the plaintext. Combined with the real medical application scenarios, we believe that the size of plaintext, that is medical records, should not be overwhelming. In general, communication costs are also within acceptable loads.


## 5.3.1. Computational Cost

Execution time is the most intuitive measure of computational complexity. First, we usePython to implement cryptography algorithms used in our scheme and estimate the time cost. Table 6 presents the run-time cost of our used cryptographic algorithm, which is metric on a 100-run basis.Table 6
Time cost of cryptographic algorithms.
AlgorithmSHA256AES.EncAES.DecECELG.EncECELG.DecECDSA.SigECDSA.VerMax time (s)0.0000260.0001600.0000830.0026870.0484120.0012800.003902Min time (s)0.0000190.0001460.0000630.0017020.0410220.0010110.003526Average time (s)0.0000220.0001580.0000770.0020560.0455290.0010700.003669Then, we summarize the cryptographic operations involved in each phase of the whole process. According to the corresponding running time costs in Table6, we estimate the time costs of each entity in each phase of the scheme, and the results are shown in Table 7. It can be observed that the execution time of the off-chain operation for each entity is less than 1 second, which is within the acceptable overhead range.Table 7
Time cost of each entity at each phase 0.76.
PhaseInvolved entityOperationTime cost (s)Identity authenticationOwner/requesterECDSA.Sig + ECDSA.Ver0.004739Supervise centerECDSA.Sig + ECDSA.Ver0.004739Record generation and uploadOwner2∗ SHA256 + AES.Enc0.000202Record accessOwnerECELG.Enc0.002056RequesterECELG.Dec + SHA256 + AES.Dec0.455389


## 5.3.2. Communication Cost

In addition, we list the major communication costs between the entities, as shown in Table8. Here, bc and bs denote the bit size of ciphertext and signature data, respectively.Table 8
Communication cost between the entities.
EntitiesS&R/OO& serverR& serverR&OCommunication cost2∗bs.ECDSAbc.AESbc.AESbc.ECELGAs we can see, communication costs are directly affected bybc and bs. Since the signature size of ECDSA and ciphertext size of ECEGL are fixed when the elliptic curve is selected, communication cost between supervision center S and ℛ/O and between ℛ and O is close to constant. While the ciphertext size of AES is linearly and positively related to the plaintext size, communication costs between O and storage server and between ℛ and storage server are also positively related to the size of the plaintext. Combined with the real medical application scenarios, we believe that the size of plaintext, that is medical records, should not be overwhelming. In general, communication costs are also within acceptable loads.


## 5.4. Experimental Simulation

To show the feasibility of the scheme, we simulated the transactions of the proposed scheme through the smart contracts under the Quorum blockchain platform. Because the contracts are deployed on the consortium blockchain, we do not have to pay as much attention to the spending of gas that was consumed in the stage of transaction operations and contract deployment as in the Ethereum blockchain.Following the official 7-node example of Quorum [39], we setup a 7-nodes Quorum blockchain network with IBFT consensus on the Tencent cloud host, CentOS 7.6 system. Then we connected MetaMask-Chrome to the deployed Quorum blockchain network in the custom RPC mode with port 22000 and chainId 10. Next, we deployed smart contracts on Quorum blockchain network using Remix [40], that is, the Solidity online compiler, via the Injected Web3 connection.We regard a node with the address 0x951190d1fa0efcd6de9d1657d5c65caeaf421786 as the supervision centerS and use this node to compile and deploy three smart contracts of Authorize, MedicalRecord, and AccessControl in turn. After successfully deployed, the Authorize contract will provide the following two interfaces: setAuthorization() and getAuthorization(). The MedicalRecord contract will provide the following four interfaces: uploadRecord(), updateRecord(), getRecord(), and getAccessPolicy(). The AccessControl contract will provide the following three interfaces: setContract(), requestAccess(), and getAccessRequest().Using the contract’s address and ABI, we can interact with smart contracts deployed to the Quorum network. To perform a write operation, we need to send a transaction to trigger smart contract to update the stored value. To perform a read operation, the “get” function is called from the contracts’ list of methods. Next, we will test some of these interfaces and demonstrate the interaction with the contracts.A requesterℛ with account address 0xdd8af2f297143ae142e85ed40d1a17311031a5a2 is set to be a message sender. When the getAuthorization function is called, an empty string is obtained, as shown in Figure 7(a). It indicates that there is no permission for the requester.Figure 7
Get authorization information when (a) unauthorized and (b) authorized.
(a)(b)As shown in Figure7(b) , the requester first calls setAuthorize function with the inputs “0xdd8af2f297143ae142e85ed40d1a17311031a5a2”, and “Xi’an University of Technology ∣ School of Automation ∣ Lecturer”, and then calls getAuthorization function, and he will get the authorization information “Xi’an University of Technology ∣ School of Automation ∣ Lecturer”. Here we use the symbol “∣” to connect the attribute.In MedicalRecord contract, as shown in Figure8(a), the patient can upload the related information of medical record through the uploadRecord function, including policy, index, provider, hash, location, and metadata. After the medical record is uploaded, one can view the corresponding access policy by calling the getAccessPolicy function, as shown in Figure 8(b). Through the updateRecord function, the patient can update the corresponding access policy of the medical record uploaded by himself, as shown in Figure 9(a). Figure 9(b) shows the updated access policy by calling getAccessPolicy.Figure 8
Upload records. (a) Upload. (b) Get access policy.
(a)(b)Figure 9
Update access policy. (a) Update. (b) Get access policy.
(a)(b)As shown in Figure10(a), after a patient uploads his medical record, the patient can obtain the medical record uploaded by calling the getRecord function. The symbol “ ∥” is used as the segmentation symbol of the record. As shown in Figure 10(b), the patient can view the access history of their medical records by calling the getAccessRequest function.Figure 10
Get medical records and access history. (a) Get medical record. (b) Get access history.
(a)(b)


## 6. Conclusion

In the medical industry, with the rapid development of electronic medical records, how to store and share patients’ medical data among authorized participants in a privacy-preserving way is a thorny and urgent problem to be solved. In this article, we propose a blockchain-based medical data secure storage and sharing scheme to provide privacy and security guarantees such as confidentiality, integrity, and auditability. In addition, the functions of fine-grained access control and key management are supported. The scheme can open a medical data sharing channel to solve the current information island problem. Compared with the existing scheme, this scheme has a greater advantage in functionality, security, and efficiency. In the future, the security sharing of medical data in the human domain network can be further studied in the context of the rapid development of wearable devices and the Internet of Things.



---

*Source: 2759787-2022-05-18.xml*