Volume 2024, Issue 1 5569121
Research Article
Open Access

Secure Sharing of Electronic Medical Records Based on Blockchain

Song Luo

Song Luo

College of Computer Science and Engineering, Chongqing University of Technology, Chongqing, China cqut.edu.cn

Search for more papers by this author
N. Han

Corresponding Author

N. Han

College of Computer Science and Engineering, Chongqing University of Technology, Chongqing, China cqut.edu.cn

Search for more papers by this author
Tan Hu

Tan Hu

College of Computer Science and Engineering, Chongqing University of Technology, Chongqing, China cqut.edu.cn

Search for more papers by this author
YuHua Qian

YuHua Qian

School of Artificial Intelligence, Chongqing University of Technology, Chongqing, China cqut.edu.cn

Search for more papers by this author
First published: 03 February 2024
Academic Editor: Ashish Bagwari

Abstract

As network technology advances and more people use devices, data storage has become a significant challenge due to the explosive growth of information and the threat of data leaks. In traditional medical institutions, most medical data is stored centrally through cloud computing technology in the institution’s data center. This centralized storage method has many security risks, and once the central server is attacked, it will lead to the loss of medical data, which will lead to the leakage of patients’ private data. At the same time, electronic medical records are the most critical data in the current medical field. In the traditional centralized healthcare service system (HSS), there are data leakage problems and tampering with electronic medical records due to human factors. At the same time, each hospital is built independently, resulting in the current centralized healthcare service system having a data silo problem, making it difficult to share medical data between institutions securely. With the increase in the number of users in the system, the electronic medical record data in the system also increases gradually, resulting in the increasing overhead of decryption calculation. Therefore, this paper proposes a blockchain-based access control scheme with multiparty authorization to ensure the security of electronic medical records. The scheme uses an SM encryption algorithm to encrypt the medical data in the system. It adds the patient’s signature to ensure the confidentiality and security of the data, and the encrypted electronic medical records (EMRs) are stored in the InterPlanetary File System (IPFS) to realize the distributed storage of EMR. In addition, role-based multiauthorization access control is implemented through smart contract-based to ensure the security of EMR. We have analyzed the security of this paper’s solution and compared its performance with the existing schemes based on other cryptographic algorithms. The experimental results show that the proposed solution significantly improves the secure sharing of EMR and provides system performance.

1. Introduction

The widespread adoption of Internet technology has led to significant advancements in healthcare information technology. Electronic medical records (EMRs) have been extensively used within hospitals’ healthcare service systems (HSS) to assist medical practitioners in diagnosing and treating patients. However, due to the substantial volume and sensitive nature of EMR, healthcare institutions are vulnerable to cybersecurity attacks. The COVID-19 pandemic has witnessed several incidents of sensitive data breaches in the healthcare industry, highlighting the importance of security technologies related to EMR [1].

With the rapid growth of EMR data, when a patient visits a hospital or healthcare facility, a corresponding EMR is generated between the hospital and the patient and stored in the system database. For patients, the previously developed EMRs are also needed when they visit other hospitals. The relevant EMR of the patient may be stored in different hospitals. The doctor needs the patient’s medical data for the next treatment step. In this case, the doctor is unaware of the patient’s previous medical history, which leads to easy misdiagnosis, and this is when the problem of data silos in hospitals becomes quite prominent [2]. For hospitals and medical institutions, hospitals or medical institutions need to have corresponding standards or regulations for exchanging and transferring data when exchanging and transferring medical data [3]. Currently, most EMRs are stored centrally; i.e., the medical data are stored on a centralized cloud server. However, this storage method can cause data loss or tampering and lead to a single-point failure of the entire system, such as a natural disaster or hacking of the cloud server. In addition, the cloud server is always a semitrusted entity. If it is attacked and returns incorrect or incomplete medical record data, it may lead to misjudgment by users (e.g., doctors and healthcare organizations), which may endanger patients’ lives. Finally, the need to protect healthcare data from security breaches and criminal activities has become increasingly urgent; if someone not authorized by the system obtains sensitive patient data, then this data can be sold or redistributed on the open market, resulting in the exposure of sensitive patient information to anyone, and when electronic healthcare data is distributed among different healthcare organizations in an available network, data tampering, and forgery, among other attacks can quickly occur [4]. Therefore, the problem of secure sharing of EMR increases the cost of healthcare services for patients and affects effective communication and cooperation among healthcare organizations. Thus, to address these problems, if we design a secure and reliable decentralized electronic medical data-sharing scheme that provides accurate, secure, and timely patient-sensitive data and enables secure sharing of EMR across institutions, it can accelerate the research on medicine and diseases.

With the development of blockchain technology in recent years, it has been widely used in various industries due to its characteristics of invariance, data integrity, and distributed storage, so many scholars have begun to put forward many solutions to the current problems of EMR [5]. Literature [68] uses blockchain architecture to implement electronic medical record storage solutions. Still, these solutions only store part of the data on the blockchain and do not solve the problem of centralized nodes in the current system. Literature [9], for the first time, combined blockchain and InterPlanetary File System (IPFS) to propose a new model of electronic medical record scheme. Still, this author did not consider the problem of access control centralization, which led to the increased computational overhead of the EMR stored in the system. Literature [10] and literature [11], based on literature [9], used attribute-based encryption (CP-ABE) to allow doctors and patients to formulate access policies for EMR, which realized fine-grained access control for data requesters. Still, this access control scheme increased the computational overhead of the system’s access control. In addition, some researchers have adopted a semidecentralized architecture to improve the response speed of the whole system; i.e., the system behavior of storing EMR data is outsourced to external trusted cloud storage servers, such as in literature [12] and literature [13]. Still, this approach does not avoid the attacks during the data transmission process or the attacks on the external cloud storage servers. Based on this problem, some researchers have proposed using fog computing to avoid attackers’ attacks during data transmission and on cloud servers, such as in literature [14]. Still, literature [14] does not achieve user and attribute revocation, which enables access control to the system.

This paper proposes a new electronic medical record scheme that uses blockchain and IPFS technology to address the existing problems. In this scheme, the hash address of EMR data stored in IPFS is uploaded to the blockchain after encryption, ensuring the security of the EMR data stored in IPFS. The decentralized feature of IPFS avoids the single point of failure problem of the entire system. Meanwhile, we also introduce the SM2 signature algorithm to support the authentication of EMR data, which avoids the data leakage problem during data transmission. In addition, this paper designs an EMR data-sharing strategy through which it can balance the data transactions of EMR in the whole system and indirectly promote the EMR data transactions in the system. Finally, this scheme proposes a multiauthorization role control scheme based on smart contracts, which achieves lightweight access control and dramatically reduces the overall access control overhead in the system compared to the traditional role control scheme. The following are the main contributions of this paper:
  • (1)

    We propose integrating blockchain technology and IPFS technology to create a decentralized solution for electronic medical records. This solution ensures distributed data privacy protection for users within the system. By leveraging IPFS technology, encrypted medical data can be securely submitted, thereby reducing the overall storage overhead of the system. Furthermore, the solution records the corresponding storage address and medical-related information on the blockchain, guaranteeing effective data storage and preventing any tampering with the data

  • (2)

    We suggest using a hybrid encryption method of SM2 signature algorithm and SM4 encryption algorithm to ensure secure EMR data transmission

  • (3)

    We have developed an EMR data pricing strategy that calculates the potential value of EMR data. This strategy facilitates the sharing of EMR data across different agencies and ensures a balanced exchange of EMR data between data providers and consumers within the system

  • (4)

    We propose using smart contract technology to implement a smart contract-based multiauthorization role access control system. This approach is aimed at streamlining access control within the system, reducing the overall access control overhead

2. Related Work

2.1. Blockchain-Based Electronic Medical Record Model

In recent years, blockchain technology has experienced rapid development and is characterized by its decentralized nature, data immutability, and transparency. It was first proposed by Nakamoto [15] in 2008 and initially applied in the context of Bitcoin. Blockchain technology can be seen as a distributed database that enables reliable and secure data storage within the system, eliminating the need for third-party cloud storage and addressing potential data security issues associated with cloud storage. Building upon these distinctive features, researchers have begun exploring the application of blockchain technology in the medical field. Azaria et al. [6] introduced MedRec, an electronic medical record model based on blockchain technology, which enhances the security of data transmission. However, this model still relies on centralized cloud servers, making it susceptible to data leakage and malicious tampering. Liang et al. [7] proposed a secure data transfer scheme using Fabric blockchain, which improves data transfer security and reduces communication overhead. Zhang and Poslad [8] put forth a fine-grained access control-based secure storage model for electronic medical records, enabling granular access control by authorizing different queries. This blockchain-based approach effectively addresses data requests without revealing unauthorized personal information. However, it increases the computational consumption of querying electronic medical records, resulting in inefficiencies for the entire system. Nevertheless, the calculation of tokens is susceptible to attacks or tampering. Sun et al. [9] ensured the security of the storage platform by suggesting decentralized storage of encrypted electronic medical data in IPFS. Only the hash address returned from IPFS is uploaded to the blockchain. Li et al. [16] proposed a transaction record-centric system and utilized game theory to introduce a new token economic system, aiming to optimize the process of sharing electronic medical records and achieve a Nash equilibrium point [17]. Liu et al. [18] combined searchable encryption with federated blockchain to achieve efficient and reliable multikeyword searches. However, there is still a presence of cloud servers in the system architecture. However, the transaction record-centric approach makes the system inefficient and prone to congestion. Jayabalan and Jeyanthi [19] addressed the system overhead by adopting a patient-centric model and utilizing IPFS. However, handing over the entire system network maintenance to the patient is challenging to implement in reality, and centralized access control remains an issue. Kaur et al. [11] proposed a blockchain-based approach for EMR storage and sharing by utilizing IPFS as an off-chain storage and encrypting the patient-related records while encrypting and decrypting them using the CP-ABE algorithm. However, it still suffers from a high system overhead and centralization of the access control. Alrebdi et al. [20] proposed a blockchain-based scheme for secure storage and access to EMRs through a combination of IPFS and cloud storage to achieve search and verification of encrypted files. Still, the scheme does not achieve better access control, while the existence of cloud storage leads to system vulnerability to attacks. Ramesh et al. [21] proposed blockchain-based tamper-proof EMR storage access in cloud environment. Still, the third-party reviewer in the scheme is susceptible to attacks due to the lack of a distributed architecture, which leads to the review process of a single point of failure. Mohammed et al. [22] proposed a blockchain-based distributed EMR system, which achieves secure storage of EMR data through biological signaling and light-weighted encryption, but did not design a corresponding access control policy. Table 1 demonstrates a comparative analysis of existing EMR models and proposals.

Table 1. Comparison of existing blockchain-based EMR schemes with the proposed schemes.
Schemes Privacy protection Access control Blockchain IPFS Incentives
Azaria et al. [6] x x x
Liang et al. [7] x x x
Zhang and Poslad [8] x x
Sun et al. [9] x x
Li et al. [16] x
Sun et al. [10] x
Liu et al. [18] x x
Jayabalan and Jeyanthi [19] x x
Kaur et al. [11] x
Alrebdi et al. [20] x
Ramesh et al. [21] x
Mohammed et al. [22] x x
Ours

2.2. Smart Contract-Based Access Control Technology

The concept of smart contracts traces its origins back to the paper by Szabo, which introduced the idea of using computer code and cryptographic techniques to automate contract execution and ensure the immutability and nonrepudiation of their execution [27]. With the advancement of blockchain technology, smart contracts have gained widespread adoption and implementation. They are designed as code or programs embedded within the blockchain that can autonomously execute and update its state. The emergence of smart contract platforms like Ethereum has propelled the development of smart contract technology. Ethereum introduced Solidity, a Turing-complete language for smart contracts, and provided developers with tools and environments to create and deploy smart contracts [28]. Building upon these features, researchers have explored the use of smart contracts for access control. For instance, Cruz et al. [23] implemented a role-based access control mechanism using smart contract technology, enabling cross-organizational role usage. Zhang et al. [24] proposed a framework for IoT environments by introducing multiple access control contracts to achieve enhanced access control. In access control, Wang et al. [25] utilized smart contract technology to implement access control and revocation within the Internet of Things (IoT) environment using a single contract. However, they did not tackle the security vulnerabilities of a lone access control node. Maesa et al. [26] introduced a decentralized and dynamic access control approach based on policies, allowing for complex access control policies based on user or environmental properties. These studies highlight the potential of smart contract technology in implementing robust and flexible access control mechanisms within various domains. Table 2 demonstrates the comparative analysis of existing blockchain-based access control techniques with the proposal.

Table 2. Comparison of existing smart contract-based access control schemes with the proposed scheme.
Schemes Smart contract Multiauthorization Access revoked
Cruz et al. [23] x x
Zhang et al. [24] x
Wang et al. [25] x
Maesa et al. [26] x
Ours

3. Preliminaries

3.1. Blockchain

In recent years, blockchain technology has become prevalent in developing distributed systems. Blockchain is a data structure that connects each block through hash pointers in chronological order, resulting in an immutable distributed ledger combined with cryptographic techniques [29]. Each block within the blockchain comprises at least five essential parameters: timestamp, the hash of the previous block, nonce, target hash, and the Merkle root of all transaction records. The block body encompasses all the transaction records.

Blockchain can be classified into three main types: public chains, consortium chains, and private chains [30]. Public chains are open and accessible to anyone without any access restrictions, enabling participation in transactions on the chain by any individual. Consortium chains are blockchain networks maintained collectively by institutions or organizations. Participants in the consortium chain possess management permissions and decision-making authority over the chain. To join the consortium chain, individuals must undergo a qualification review. Once their qualifications are approved, they are granted access to the chain. Private chains, on the other hand, are maintained and managed by a single organization or individual, offering complete control over the entire blockchain to the owner.

3.2. Ethereum (ETH)

In 2013, Buterin [31] drew inspiration from Bitcoin and introduced Ethereum (ETH). Ethereum is a blockchain platform that enables individuals to construct and utilize decentralized applications. The Ethereum platform offers an Ethereum virtual machine (EVM), a “Turing-complete” virtual machine. Users can leverage the EVM to develop and execute smart contracts.

Smart contracts are software programs that operate on the Ethereum virtual machine (EVM) and possess their own Ethereum accounts. Upon receiving transaction data, they autonomously execute predetermined code logic. Smart contracts are capable of invoking other smart contracts as well. They facilitate the automated execution of contracts between parties, with the entire process being recorded on the trusted public ledger without individual interference. Additionally, smart contracts can store data and trigger events based on predefined conditions.

3.3. InterPlanetary File System (IPFS)

The InterPlanetary File System (IPFS) is a decentralized file system and peer-to-peer hypermedia protocol. Benet [32] recognized the limitations of data distribution in traditional HTTP protocols and proposed the InterPlanetary File System (IPFS) by incorporating some aspects from the BitTorrent content distribution protocol. In IPFS, storage is distributed among nodes within the IPFS network, ensuring scalability. Each node is assigned a unique node ID, which corresponds to the hash value of its public key. Every node maintains a distributed hash table (DHT) to retrieve network addresses of other nodes. The DHT fulfills specific functions and facilitates node discovery within the network. When a file is uploaded to IPFS, the system generates a unique hash value, allowing a single instance of the file to be stored in IPFS.

3.4. SM2 Signature Algorithm

The SM2 algorithm is an asymmetric encryption algorithm introduced by the China National Cryptography Administration in 2010 [33]. It is aimed at replacing the widely employed 1024-bit RSA algorithm. In comparison to RSA, the SM2 algorithm exhibits increased computational complexity but faster encryption and decryption speeds, leading to reduced resource consumption on devices.

The process description of the SM2 signature algorithm is as follows:
  • (1)

    M = ZAM, where M represents the data to be signed and ZA denotes the identifiable information of A, partial elliptic curve system parameters, and the hash value of user A public key

  • (2)

    Compute e = Hash(M) and convert it to an integer

  • (3)

    Generate a random number k ∈ [1, n − 1] using a random number generator

  • (4)

    Compute the elliptic curve point (x1, y2) = [k]G, and convert it to an integer. Here, G represents a point on the elliptic curve, and [k]G denotes the multiplication of the point by a scalar

  • (5)

    Compute r = (e + x1)modn. If r = 0 or r + k = n, return to (3).

  • (6)

    Compute . If s = 0, return to (3) to regenerate a random number

  • (7)

    Convert r and s to strings to obtain the signature value (r, s) for the message

3.5. SM4 Encryption Algorithm

The SM4 algorithm operates on 128-bit plaintext and ciphertext using a 128-bit key. Both encryption and decryption employ the same key [34]. The encryption algorithm, including key expansion, is based on a 32-round nonlinear iterative function. The core of the data encryption process involves a round function that combines linear and nonlinear operations. Initially, the key is divided into four groups of 32 bits each, and the key expansion algorithm generates 32 groups of 32-bit keys. The 128-bit input data is processed iteratively, with each round handling four groups of 32 bits. The overall structure of the SM4 symmetric encryption algorithm is illustrated in Figure 1.

Details are in the caption following the image
Overall architecture of SM4.

3.6. Role-Based Access Control

The role-based access control (RBAC) model is a contemporary model introduced in the late 20th century [35]. In RBAC, access permissions are represented by three key components (who, what, and how). These components define the following: who can perform how on what, and the evaluation process determines the truth value of the logical expression. Who represents the owner or subject of the permission, such as users and roles. What refers to a resource or object, while how means an operation or activity. RBAC decomposes all permissions into subsets and defines them as corresponding roles, which are then assigned to respective subjects. The fundamental elements of the issue include users, roles, sessions, and permissions. Various forms of RBAC models can be constructed, including RBAC0 (core RBAC), RBAC1 (hierarchical RBAC), RBAC2 (constraint RBAC), and RBAC3 (combined RBAC) [36].

4. Proposed Model

This section provides a detailed description of the system design. Patients, as creators of EMR data, upload their encrypted data to the system. Medical institutions act as IPFS nodes, responsible for storing the encrypted EMR data and recording its hash address on the blockchain. This section presents the system model, outlining the secure transmission of data and access control mechanisms. Finally, the chapter discusses the pricing strategy for EMR data.

4.1. System Framework

As shown in Figure 2, traditional healthcare systems are centralized, and as the number of users increases, so do the system costs. They are susceptible to single points of failure and data breaches. In contrast, this paper presents a blockchain-based system where medical institutions are network nodes to maintain the system. EMR data generated by patients is uploaded to the IPFS network for storage, and with patient authorization, it can be shared among medical institutions. This distributed system enhances security and reliability, mitigating the risk of single points of failure.

Details are in the caption following the image
Centralized traditional healthcare system.

As shown in Figure 3, the system consists of entities such as patients, doctors, IPFS, and the institution-maintained blockchain. The MedCoin token system, in conjunction with incentive mechanisms, regulates the sharing process of EMR (electronic medical record) data within the system and rewards users for sharing their EMR data. The entities involved in the system are listed in Table 3, with the primary commodities being EMR, patients, doctors, IPFS, and the healthcare institution-maintained blockchain.

Details are in the caption following the image
Proposed system framework.
Table 3. Entities in the system.
System entity Description
Patients Creators and owners of EMR data
Doctors Secondary creators of EMR
MedCoin token wallet Deposit of MedCoin tokens awarded by the system
IPFS Distributed storage system to store encrypted EMR
Medical institutions Maintainer of the system blockchain network
EMR Electronic medical records

4.2. System Entities

The primary system entities include EMR, patients, doctors, IPFS, and the blockchain, which healthcare institutions maintain. These entities are depicted in Table 3.

4.2.1. EMR

When a patient receives medical treatment, the system records the entire process. Initially, the patient enters the system to initialize their EMR. Subsequently, the doctor completes the medical history and prescription within the EMR. Once the entries are finalized, the EMR is encrypted and transmitted to the IPFS node network, maintained by healthcare institutions to ensure data confidentiality and prevent third-party access. The IPFS node returns a hash address, which the system encrypts and uploads onto the healthcare institution’s blockchain. This information is encapsulated into a block and added to the blockchain following a consensus process.

4.2.2. Patients

Patients play a vital role in the system as they are the primary creators of EMRs and have complete control over them. By creating EMRs, patients can receive medical treatment across different healthcare institutions, greatly enhancing their accessibility to care.

4.2.3. Doctors

Doctors serve as secondary creators of EMR data and have the authority to access EMR records authorized by patients. After patients initialize their EMR, doctors record medical visit data, enabling it to become a complete EMR and circulate within the system.

4.2.4. Medical Institution

The healthcare institution is the creator and maintainer of the system and is responsible for user privacy and EMR data security. It constitutes the distributed storage network IPFS, which stores EMR data. In the incentive mechanism, the healthcare organization acts as an intermediary that responds to data consumption requests, obtains MedCoin tokens, and transfers them to the EMR data creator.

4.2.5. MedCoin

MedCoin tokens were introduced to encourage the sharing of EMR data. When EMR data is shared, the system responds to the consumer’s request, transmits the data to them, and receives MedCoin as payment, which is transferred to the data creator to reward the data-sharing behavior. In this way, complete EMR data sharing is realized through the amount of MedCoin. The specific structure of MedCoin is shown in Figure 4.

Details are in the caption following the image
MedCoin storage structure.

4.3. Secure Storage and Sharing of EMR Data

EMR data comprises sensitive information, including patient personal details and doctor diagnostic records. The system must ensure secure storage and sharing of EMR data while protecting patient privacy. In some existing solutions, such as those described in literature [10, 11], CP-ABE is employed to address the secure storage of EMR data. However, this paper utilizes a more lightweight SM encryption algorithm to encrypt EMR data, aiming to resolve the security concerns associated with storing and sharing EMR data within the system.

4.3.1. Secure Storage of EMR Data

With distributed storage technology, this paper realizes the secure sharing of EMR data among various medical institutions through blockchain technology. The fundamental operations of the storage of EMR data within the system are outlined as follows:

Initialization: when patients access the system, they undergo an EMR initialization process. Here, patients supply their essential personal information and complete relevant EMR fields.

Generate patient’s public-private key pair: the system generates a patient’s key pair using their ID, creating a private-public key pair based on the provided initial parameters γ and patient ID:
(1)

Encryption and generation of signature: the system conducts a hash operation on unencrypted EMR data, computing its digest value. Using the patient’s private key private_key and the computed digest value, the system employs the SM2 signature algorithm to generate the EMR data’s signature. Furthermore, the system utilizes the SM4 encryption algorithm to calculate CTemr, concatenated with Sign to produce the patient’s EMR data ciphertext CT, as shown in Algorithm 1.

    Algorithm 1: EMR data signature and encryption algorithm based on SM2 algorithm.
  • Input: Medical record data Memr, Patient ID

  • Output:CT = CTemrSign

  •  1: KeyGen: patient’s private_key and public_key

  •  2: Extract:H1 = SM3(IDpublic_keyabxGyg)

  •  3: Calculating hashes:H = SM3(H1Memr)

  •  4: Generate signature: Sign = SM2(Hprivatekey)

  •  5: Encrypt: CTemr = SM4(Memr)

Upload IPFS network: upon receiving the encrypted EMR data, the system follows a secure storage process. Initially, the encrypted patient EMR is uploaded to the IPFS network. The hash address provided by the IPFS network, along with the patient’s ID and relevant data, is subsequently uploaded to the system’s blockchain as a package. The system awaits authentication by the chain’s nodes. Upon successful mutual authentication, the package is compiled into a block and added to the system’s blockchain. Additionally, the system compiles the patient’s ID, public_key, and signature Sign into a list and uploads it to the IPFS network, obtaining a corresponding hash address. After confirmation by the chain’s nodes using the blockchain’s broadcast mechanism, this value is packaged and uploaded to the chain. Simultaneously, the signature Sign generated by the patient during the encryption phase is automatically packaged and uploaded to the blockchain by the system for patient EMR data verification.

4.3.2. Secure Sharing of EMR Data

Once the patient’s EMR data has undergone the steps illustrated in Figure 5, which include steps ① and ②, the data is securely stored on the IPFS within the system. Subsequently, through the steps depicted as ③, ④, and ⑤ in Figure 5, the hash address and the patient’s ID returned by the IPFS are bundled and uploaded to the blockchain. When a physician or institution initiates a request to access a patient’s EMR, the following detailed description explains how the data is securely shared within the system.

Details are in the caption following the image
Data flow diagram of system entities.

Initiating a request: a third-party user, such as a physician or institution, initiates an EMR data access request within the system. Upon receiving this request, the system seeks authorization from the patient who owns the EMR data. The system waits for the patient’s approval, as shown in Figure 5, during steps ⑦ and ⑧.

Data lookup: upon receiving remote patient authorization for a data request initiated by a third-party organization or doctor, the organization’s node will execute the deployed smart contract on the blockchain. This contract will conduct a lookup using the patient’s ID and relevant keywords, retrieving the hash value from the packaged IPFS and the patient’s blockchain signature. This process is depicted in Figure 5, particularly in steps ⑧-⑪.

Signature verification: when a patient remotely authorizes a data request from a third-party organization or doctor, the system looks up the hash value in the blockchain using the patient’s ID and keywords. It then retrieves the patient’s public_key and signature Sign from IPFS based on the obtained hash value. Subsequently, the system compares the signature found by the third-party organization with the system’s Sign2 to determine if they match. If they match, the process proceeds; if they differ, the system denies further access to the third-party organization, as in steps ⑫-⑭ in Figure 5.
(2)

Data decryption and signature verification: if the signature comparison succeeds, the system decrypts and verifies the data. It retrieves the EMR data cipher stored in IPFS based on the hash value provided by the third-party organization or doctor. The system then decrypts and verifies the signature. It calculates the digest value of the current data. It uses the SM2 signature verification algorithm, taking into account the signature Sign obtained from the third-party organization or doctor, the patient’s public_key, and the digest value H1 of the data. If the verification fails, the system rejects the operation. If the verification is successful, the system decrypts the EMR data and provides the plaintext Memr to the third-party institution or physician, as shown in Figure 5, step ⑮. During the EMR data decryption stage, the third-party organization cannot access the patient’s public-private key pair and can only retrieve the patient’s signature stored in the blockchain. This approach ensures the security of patient data by conducting encryption, decryption, and verification operations through a system trusted by the patient, as shown in Algorithm 2.

    Algorithm 2: EMR data decryption and signature verification algorithm based on SM2 algorithm.
  • Input: Encrypted ciphertext CTemr

  • Output: Medical Record Data Memr

  •  1: if Sign verification succussed then

  •  2: H1Extract(ID, public_key, a, b, xG, yG)

  •  3: BoolSM2VerifySign(H1, Sign, public_key)

  •  4: if Bool == Truethen

  •  5:  Verification Success

  •  6:  return MemrSM4(CTemr)

  •  7: else

  •  8:  System Refused

  •  9:  return False

  •  10: end if

  •  11: else

  •  12: return False

  •  13: end if

4.4. A Sharing Strategy Based on Assessing the Value of EMR Data

Existing healthcare data security storage solutions face challenges because patients, physicians, and healthcare organizations operate independently in the system, often lacking motivation for active EMR data sharing [37]. To tackle this problem, this paper introduces an analytical strategy to assess the value of EMR data, aiming to overcome obstacles in sharing EMR data among diverse entities.

4.4.1. Entities in the Sharing Strategy

(1) Data Provider. In the proposed sharing strategy, the data provider is the patient who created the EMR data within the system. The patient maintains full control over their EMR and acts as the data provider, enabling them to grant licenses for sharing their self-generated EMR data with others.

(2) Data Consumer. In sharing strategies, data consumers are typically doctors or institutions seeking access to EMR data shared by data providers in the system. Data consumers are not the original creators of the EMR data. When they receive EMR data from a specific data provider within the system, the system rewards the data provider with MedCoin tokens as an incentive for sharing their EMR data.

(3) Leader. In the sharing strategy, the leader, usually a medical institution, takes a proactive role. It evaluates the value of EMR data and sets the reference price, initiating the bidding process with the first bid. Data consumers can assess the data’s value based on the leader’s bid and place their bids accordingly.

4.4.2. Security Price Algorithm Based on Evaluating the Value of EMR

In this paper, we enhance the optimal EMR price algorithm proposed by Li et al. [16] by incorporating the calculation of potential weight values for each EMR transaction. This is achieved by evaluating the potential value of the EMR. The security price algorithm, which evaluates the value of the EMR, is described as follows:

Initialize algorithm parameters, including the initial evaluation price p of EMR, data consumer bid price d, system maintenance consumption c, and other relevant parameters.

Assess the EMR’s potential value through an evaluation algorithm that analyzes requested EMR data and calculates its anticipated value based on the patient’s EMR data when a data consumer sends a request.
(3)
where Di represents the weight of each EMR calculated, j represents the disease weight, n represents the number of diseases, and k represents the nonzero coefficient.
(4)
where Pv represents the calculated minimum prognosis for each EMR, Di represents the weight of the i-th EMR, and c represents the consumption of the maintenance system.
The leader sets the EMR price bidding strategy. The leader in the system is the system itself, and the system sets the EMR price bidding strategy based on the expected estimate of EMR calculated in the previous step as
(5)
Data consumers calculate the optimal price for current EMR data:
(6)
where αi is the predefined nonzero positive factor and di represents the best price of the i-th EMR.
The data provider calculates the optimal return. The data provider calculates the return on its own EMR as
(7)
where γ is the predefined nonzero positive factor and Rw represents the optimal return price of the owner EMR data.

The system will pay the corresponding MedCoin tokens to the data provider according to the calculated price; MedCoin will record the corresponding data consumption records, the best price of the data consumer, and the best revenue of the data provider; and the MedCoin payment records will be encrypted by the system and then packaged and uploaded to the chain by the system, as shown in Algorithm 3.

    Algorithm 3: Price algorithm based on evaluating the value of EMR.
  • Input: Initial Parameters p, d, c, j, n, γ

  • Output: the unit value and reward

  •  1: if Data Provider passed request then

  •  2: for each EMR do

  •  3:  jSum_Num( )

  •  4:  DicomputeEMRWeight(n, j)

  •  5:  PvcomputeEMRValue(Di, c)

  •  6: end for

  •  7: for each Data Consumer ido

  •  8:  for the unit price P set value from Pv to Pmax by leader do

  •  9:   if di<cthen

  •  10:    break

  •  11:   end if

  •  12:   data consumer i computing value depend on:

  •  13:   di = (αi/Pi) + Pvc

  •  14:   data provider computing value depends on:

  •  15:   the unit value and reward

  •  16:  end for

  •  17: end for

  •  18: else

  •  19: return

  •  20: end if

4.5. Role-Based Access Control Based on Smart Contracts and Multiple Authorized Organizations

Literature [69, 18] centralized system access control, posing security risks due to a central server storing extensive access information, making it an attractive target for potential attackers. Breaches could grant unauthorized access to all system resources, potentially resulting in data breaches or misuse. To address these challenges, this paper introduces an extended role-based access control scheme called multiauthority role-based access control for smart contracts (MARBAC-SC), which utilizes smart contracts and multiauthority mechanisms. MARBAC-SC enhances the traditional RBAC model and is depicted in Figure 6 for reference, and the main flow is shown in Figure 7.

Details are in the caption following the image
The architecture of MARBAC-SC.
Details are in the caption following the image
Main processes of MARBAC-SC.

Contract deployment: after the system is initialized, the organization node in the system executes the organization essential generation function, generates the organization’s corresponding public-private key pair O_public_key and O_private_key, and executes the deployment of the smart contract to the chain.

Add users and assign corresponding roles: after the contract is deployed and the user fills in the personal information, the system will automatically execute the AddUser function in the contract to add the user to the corresponding organization after the user clicks to create the EMR for the individual, as shown in Algorithm 4.

    Algorithm 4: Add users and assign corresponding roles.
  • Input:O_public_key,userAddress

  • Output: grantRole(Role, userAddress)

  •  1: if status = = Truethen

  •  2: if userAll[userAddress].userSince==0 then

  •  3:  userAll[userAddress] = User(O_PublicKey, block.timestamp)

  •  4:  userAccounts.push(userAddress)

  •  5:  indexUser++

  •  6:  grantRole(Role, userAddress)

  •  7: else

  •  8:  return

  •  9: end if

  •  10: else

  •  11: return

  •  12: end if

Remove authenticated users: if a user has not been active for a long time, an organization in the system can execute the removeUser function to remove the role assigned to the current user. After the function is completed, the role of the user recorded in the chain will be removed, as shown in Algorithm 5.

    Algorithm 5: Remove authenticated users.
  • Input:O_public_key,userAddress

  • Output: revokeRole(Role,userAddress)

  •  1: if userAll[userAddress].userSince != 0 then

  •  2: delete userAccouts[userAll[userAddress].userIndex]

  •  3: userAccouts.pop()

  •  4: delete userAll[userAddress]

  •  5: indexUser - -

  •  6: revokeRole(Role,userAddress)

  •  7: else

  •  8: return "User does not exist"

  •  9: end if

Role access policy determination: after the user’s role is assigned, if the user performs a function in the system that involves permission control, the system will execute an access policy judgment in advance to determine whether the current user has permission to call the method, as shown in Algorithm 6.

    Algorithm 6: Role access rights determination.
  • Input: Role, userAddress

  • Output: Bool

  •  1: if !hasRole(Role, userAddress) then

  •    revert string abi.encodePacked(userAddress,uint(Role), 32)

  •  2: else

  •  3: return false

  •  4: end if

5. Solution Analysis

Unlike traditional medical visit systems, this solution utilizes blockchain and the IPFS storage network to shift from a centralized to a decentralized system. This transformation allows patients to access their EMR data across different institutions. The blockchain and IPFS storage network, maintained by healthcare institutions, guarantee secure and efficient storage of patient EMR data, safeguarding sensitive patient information. In this section, our principal emphasis lies in the execution of experimental analyses and scenario comparisons, aimed at assessing the efficacy of the proposed scheme.

5.1. System Deployment

All simulations of this program are executed on an Intel Core i7 processor with 16 GB of RAM to validate our framework. Smart contracts in Ethereum are written by Solidity, a programming language through which one can make transactions on the chain. This solution utilizes the web3.js framework to access the change account via HTTP connection in JsonRPC, compiling the smart contract requires the use of Ganache, and the Truffle development environment must also be used.

5.2. Security Analysis

Ensuring the security of patient data, especially within EMR, is paramount. Preserving EMR confidentiality and integrity is vital for protecting sensitive patient information and preventing unauthorized access or data breaches. In this context, the security level offered by this solution is demonstrated through the following aspects:

Eliminating single points of failure: the proposed scheme in this paper employs decentralized blockchain technology to effectively reduce the risk of system-wide failure due to a single node’s downtime or malicious attacks. By establishing a distributed storage network, the system gains increased resilience and eliminates the susceptibility to a single point of failure. This approach not only disperses power within the system but also enhances data security, facilitating data sharing and improving overall system efficiency.

Privacy protection: in the proposed scheme, all EMR operations conducted by patients and doctors are contained within the system, eliminating external system node involvement and safeguarding patients’ sensitive data from exposure. Additionally, the patient’s sensitive data is encrypted using the system’s SM4 symmetric encryption and SM2 signature algorithm. Adversaries cannot decrypt and access the EMR ciphertext without the corresponding symmetric key and owner’s signature. Furthermore, the EMR is stored within the IPFS storage network, and the IPFS network’s address value is securely uploaded to the blockchain using SM4 symmetric encryption. The entire system operates on a private chain, permitting blockchain access only to authorized users vetted by the system, ensuring the safety and security of patient-sensitive data within the system.

Data integrity: the system guarantees the tamper-resistant nature of EMR data and patient’s private information through a dual backup mechanism. Initially, the system generates two data copies: one is uploaded to the internal IPFS network and stored on the institution’s blockchain. Additionally, the patient’s private data is encrypted and securely stored to prevent unauthorized access or data leakage, enhancing the security of sensitive patient details. Furthermore, when medical institutions or doctors access the data, the system enforces a dual verification process to ensure data authenticity and integrity, effectively thwarting any malicious tampering.

Resistance to double-spend attacks: in our proposed scheme, all EMR data transactions involving MedCoin tokens are diligently recorded on the system’s blockchain, including details of the sender, recipient, and token quantity in each transaction. This robust tracking system guarantees the traceability of all MedCoin token transactions within the system, preventing users from engaging in double spending. The system can detect and block the reuse of tokens already expended in prior transactions, ensuring the security of MedCoin tokens.

Protection against DDoS attacks: DDoS attacks, which can disrupt system operations by inundating resources with a high volume of requests, are a significant concern. The proposed scheme in this paper tackles this problem by implementing a distributed system architecture. Distributing the workload across multiple nodes mitigates the risk of resource exhaustion in any one node, safeguarding the system against potential collapse due to resource depletion. This distributed approach effectively protects the system from DDoS attacks, ensuring uninterrupted operation.

Resistance to masquerade attacks: attackers discover system vulnerabilities by obtaining user credentials and user passwords and use masquerade attacks to gain unauthorized access control to the system. Since the privilege control of our scheme is based on RBAC, this system is resistant to masquerade attacks. Before connecting to the system network, all the entities in the system have to register in the RegisterUser( ) function and provide the necessary data, and then, the system authenticates them. In addition, the system encrypts the EMR, resulting in a ciphertext CT that cannot be decrypted without the user’s authorization. Finally, the hash value of the EHR is stored on the blockchain and only users who satisfy the set of policy attributes can decrypt the EMR, which is inaccessible to attackers.

Resistance to man-in-the-middle attacks: in the data-sharing process, the attacker somehow obtains the hash value of the data and tries to access the data in the IPFS but cannot access the data in the IPFS because the attacker must also obtain the relevant signatures for signature verification. The attacker is unable to obtain the signatures stored on the chain normally through the access control policy.

5.3. Performance Analysis

5.3.1. Gas Fee Consumption

This section primarily focuses on analyzing the gas fee consumption for deploying the paper’s scheme on the Ethereum network. Deploying a contract or executing transactions on Ethereum incurs transaction fees, which correspond to the cost of processing data on the blockchain. Table 4 presents the gas fee consumption for key functions during each major phase of the system and analyzes the cost of smart contract creation and execution for the main methods. As of December 2022, considering the current Ethereum conversion rate of 1 gas ≈0.000000001 eth, the primary source of gas fee consumption in the system stems from the initial deployment of smart contracts. On the other hand, the gas fee generated during the execution of smart contracts is comparatively lower for the system. Table 5 mainly shows a comparative comparison of the gas fee consumption of some of the functions with literature [20].

Table 4. Consumption of gas fee for the method in the scheme.
Function name Gas used Actual Tx cost
Create Contract 1419799 0.001419799
InitializeEMR 168010 0.00016801
AddEMR 133329 0.000133329
RequestEMR 142320 0.00014232
AddDoctor 44721 0.000044721
AddPatient 344709 0.000344709
AddUser 145590 0.00014559
RemoveUser 101819 0.000101819
VerifyRole 120910 0.00012091
Table 5. Comparison table of gas fee consumption of some functions in the scheme with literature [20].
Function name Proposed model gas used SVBE [20] gas used
AddPatient 344709 421901
AddFile 92858 93968

5.3.2. Trading Latency Analysis

Transaction latency analysis examines the time required to complete a specific function within the system, and this completion time is a crucial factor for evaluating system performance. Transaction latency encompasses the entire process, starting from initiating a transaction to its confirmation, which includes the time taken for transaction broadcasting and the execution time of the consensus algorithm [21].
(8)
where TLT, TCT, TNT, and TST are the transaction delay, transaction confirmation time, network threshold, and transaction submission time, respectively.

Hence, the performance evaluation of the proposed system can be demonstrated by conducting a latency analysis of its major functions. In this section, we provide a brief calculation of transaction latency for several key functions in the scheme.

Firstly, the processing time related to patients and medical records is illustrated in Figure 8. It can be observed that the transaction delay time for patient identity verification is the shortest. In contrast, the system delay time for filling out medical record information and searching medical records is longer. It can be influenced by the size of the electronic medical record file. Specifically, larger electronic medical record files result in longer system delay times for these two tasks. Compared to alternative solutions, this solution demonstrates faster performance in adding and verifying patients, as well as adding EMRs.

Details are in the caption following the image
Transaction latency of functions.

Secondly, the system processing time for IPFS file upload and validation in the statistical system is depicted in Figure 9. We conducted tests with different file sizes, including 100 MB, 300 MB, 500 MB, and 1000 MB. As the file size increases, the system processing time for IPFS file upload and validation also increases. The proposed system exhibits certain advantages over other systems regarding transaction latency.

Details are in the caption following the image
Transaction latency of adding and verifying files.

5.3.3. Computational Overhead

In this section, we assess the computational overhead of the proposed model, with a specific focus on the decryption and encryption computational overhead on the user side. To alleviate the computational burden on users, the system employs a strategy that primarily performs decryption and encryption computations, and the results are transmitted to the user side. Compared with existing schemes such as [11], [38], and [39], the proposed scheme in this paper demonstrates certain advantages in terms of decryption and encryption time. Furthermore, the user side’s decryption and encryption computation overhead does not significantly increase, as depicted in Figures 10 and 11. It is worth noting that the system bears the main burden of decryption and encryption computation, effectively reducing the computational pressure on the user side.

Details are in the caption following the image
Decryption time on the user side.
Details are in the caption following the image
Encryption time on the user side.

Next, we examine the computational overhead of running the signature algorithm. For this experiment, we utilize data sizes ranging from 100 MB to 1000 MB, and the results are presented in Figure 12. The computational overhead of the signature algorithm employed in this paper exhibits a linear increase as the data size of the electronic medical record (EMR) grows. Notably, our proposed scheme demonstrates an advantage over the approaches described in literature [40], literature [41], literature [42], and literature [9] in terms of the computational overhead of the signature algorithm.

Details are in the caption following the image
Computational overhead of signature-value generation.

The last is an analysis of the algorithmic overhead of the whole scheme compared to other schemes, and the symbols used in this section are defined in Table 6.

Table 6. Algorithm overhead symbol definition table.
Notation Description
EG The exponential operations in group G
HashG Hash function in group G
MultG Point multiplication in group G
P The pairing operations
EP The exponential operations in ring

As shown in Table 7, the overall computation overhead in encryption and decryption operations is much lower than that of scheme [7], which is (4n + 5) · EG + (n + 2) · HashG + (4n + 2) · MultG + (2n + 1) · P. In the encryption phase, the computation overhead of this paper is (n + 1) · EG + n · HashG + (n + 1) · MultG + n · P, while the computational overhead of scheme [43] in the encryption phase is P + (n + 1) · EG + (n + 4) · HashG + (2n + 5) · MultG + EP, and it can be found that the computational overhead of this paper in the encryption phase is lower than that of scheme [42]. From the data provided in Table 7, it can be found that the overall computational overhead of this paper is also lower than that of schemes [20, 21, 44] and [45]. Therefore, the scheme designed in this paper has an advantage in overall computational overhead compared to other schemes.

Table 7. Comparison of computational overheads.
Schemes Overall computation over
[7] (4n + 5) · EG + (n + 2) · HashG + (4n + 2) · MultG + (2n + 1) · P
[20] (3n + 5) · EG + (3n + 2) · HashG + (n + 6) · MultG + (2n + 7) · P
[21] (n + 2) · EG + (3n + 2) · HashG + (4n + 4) · MultG + (2n + 4) · P
[42] (2n + 1) · EG + 7n · HashG + (4n + 5) · MultG + 4n · P
[44] P + (2n + 2) · EG + (2n + 5) · HashG + (2n + 5) · MultG + 2 · EP
[45] (3n + 3) · EG + (3n + 4) · HashG + 4n · MultG + (3n + 1) · P
Ours (2n + 1) · EG + (n + 1) · HashG + (3n + 2) · MultG + 2n · P

5.3.4. Transaction Throughput

Transaction throughput is the number of successful transactions completed on the blockchain in a specific period. When performing the statistics, invalid transactions among them should be excluded from the total number of transactions to obtain successful transactions. The transaction throughput can be expressed as the following equation [46]:
(9)
In blockchain, the transaction delivery rate is the number of transactions sent to the blockchain network per unit of time. A blockchain network is a peer-to-peer network of nodes distributed around the globe, where each node can receive, process, and broadcast transactions. When a user initiates a transaction on the blockchain network, that transaction is sent to a nearby node and progressively broadcast to other nodes throughout the network. Therefore, the transaction delivery rate is one of the important measures of the transaction traffic that a blockchain network can handle and can be expressed as the following equation:
(10)
where Transactions number refers to the total number of transactions submitted to the blockchain network in a certain time, Block time is the average time for the blockchain network to generate new blocks, and Average Transaction Size refers to the average number of bytes of transaction data.

In this paper, the size of the average transaction throughput of the model is calculated by setting a series of transaction sending rates. The average transaction throughput of the model in this paper increases as the transaction sending rate increases, and the average transaction throughput increases, as shown in Figure 13.

Details are in the caption following the image
Average transaction throughput of the proposed model.

5.4. Functional Analysis

In Table 8, the characteristics of some of the schemes are compared, and the scheme proposed in this paper has certain advantages compared to other schemes.

Table 8. Comparison of key functions of blockchain-based electronic medical data systems.
Schemes Privacy protection Access control Blockchain IPFS Incentives
[16] x
[17] x
[24] x x x x x
[25] x x x x
[26] x x x
[29] x x
[30] x x
[43] x x
[20] x
[21] x
[22] x x
Ours

6. Conclusion and Future Work

This paper introduces a novel sharing scheme that leverages blockchain and IPFS technologies to facilitate the secure and reliable sharing of electronic medical data among various entities. The scheme incorporates an incentive mechanism by evaluating the potential value of electronic medical records, encouraging patients to share their records, and enhancing the efficiency of data circulation within the electronic medical data system. Additionally, the proposal utilizes blockchain technology to ensure the integrity of electronic medical records, making them tamper-proof and enabling traceability of patient data. Future research will focus on enhancing the system’s access control to achieve a more granular level of control and security.

In reality, Ethereum-based electronic medical record solutions have inherent shortcomings, and the relatively low transaction speed of Ethernet may lead to performance bottlenecks in this system, resulting in the inability to cope with higher system throughput and leading to the exhaustion of system resources. Therefore, we will further explore an extensible coalition chain blockchain architecture that also supports the deletion of blocks. This extensible federated chain blockchain architecture can support efficient storage management on the blockchain with invariance and high extensibility. In terms of access control, this scheme relies on smart contracts to realize access control, but the finesse of access control is not enough, and the next step will be to investigate the finesse of access control.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Data Availability

The data that support the findings of this study are available from the corresponding author upon reasonable request.

    The full text of this article hosted at iucr.org is unavailable due to technical difficulties.