Generic Patient-Centered Blockchain-Based EHR Management System

Abstract

Accessing healthcare services by several stakeholders for diagnosis and treatment has become quite prevalent owing to the improvement in the industry and high levels of patient mobility. Due to the confidentiality and high sensitivity of electronic healthcare records (EHR), the majority of EHR data sharing is still conducted via fax or mail because of the lack of systematic infrastructure support for secure and reliable health data transfer, delaying the process of patient care. As a result, it is critically essential to provide a framework that allows for the efficient exchange and storage of large amounts of medical data in a secure setting. The objective of this research is to develop a Patient-Centered Blockchain-Based EHR Management (PCEHRM) system that allows patients to manage their healthcare records across multiple stakeholders and to facilitate patient privacy and control without the need for a centralized infrastructure by means of granting or revoking access or viewing one’s records. We used an Ethereum blockchain and IPFS (inter-planetary file system) to store records because of its advantage of being distributed and ensuring the immutability of records and allowing for the decentralized storage of medical metadata, such as medical reports. To achieve secure a distributed, and trustworthy access control policy, we proposed an Ethereum smart contract termed the patient-centric access control protocol. We demonstrate how the PCEHRM system design enables stakeholders such as patients, labs, researchers, etc., to obtain patient-centric data in a distributed and secure manner and integrate utilizing a web-based interface for the patient and all users to initiate the EHR sharing transactions. Finally, we tested the proposed framework in the Windows environment by compiling a smart contract prototype using Truffle and deploy on Ethereum using Web3. The proposed system was evaluated in terms of the projected medical data storage costs for the IPFS on blockchain, and the execution time for a different number of peers and document sizes. The findings of the study indicate that the proposed strategy is both efficient and practicable.

1. Introduction

One of the most important components of healthcare is providing a secure and discreet access control approach. In this age, big data is utilized to maintain and retrieve a significant amount of healthcare records over the Internet. For that purpose, cloud networking is becoming increasingly crucial in this process. Despite their simplicity and efficiency, conventional EHR systems pose a slew of privacy and security issues [1]. This is because HR are considered the most sensitive data being collected owing to the sensitive information about patients and diagnoses. HR data has, however, become more susceptible to breach due to the advancement of the internet and digital healthcare systems in current times [2]. As a result, while evaluating a decentralized and trust-based mechanism, the issues of security and privacy must be considered [3].

Table 1. List of abbreviations and acronyms used in the article.

Abbreviations	Meaning
EHR	Electronic healthcare record
HR	Health records
EMR	Electronic medical records
PHRs	Personal health records
P2P	Peer-to-peer
SC	Smart contract
CSS	Cascading Style Sheets
HTML	Hypertext Markup Language

shows the list of abbreviations and acronyms used in the article.

1.1. Motivation

In the conventional approach, cloud databases are used by content organizations to amalgamate EHRs, EMRs, clinical images, PHRs, and patient information; for example, doctor name, body measurements, and home-checking gadget information. It is worth noting that a centralized database is vulnerable to cyberattacks, jeopardizing the security and privacy of EHR [1]. Meanwhile, stakeholders and health providers face difficulty in sharing health information attributable to the discordant standards and formats.

The problem is further exacerbated if the EHR of a patient is erased from the hospital’s database, resulting in a permanent loss of the record. Thus, it is imperative for the proposed system to be tamper-proof by unauthorized parties to avoid that issue occurring [4]. Another challenge posed by the current healthcare systems is patients do not have total control over their health records since they are maintained by the service providers [5]. As the healthcare data amount continues to multiply, the security and scalability features have become major concerns. Figure 1 shows the overview of the current system architecture for existing health records.

1.2. Contribution

Considering the problems mentioned above, the healthcare industry would require a technology that is able to store data securely and efficiently. The contributions of this article are as follows:

-

A proposed PCEHRM system’s structure is introduced, and the different system’s components interactions are demonstrated.

-

The proposal of a patient-centric access control framework is based on a smart contract protocol to grant stakeholders access to the health records. It determines specific functions to be used to send information in and out of the Ethereum blockchain and to provide access privileges between stakeholders.

-

The proposed patient-centric distributed architecture focuses on confidentiality, reliability, integrity, portability, and scalability through a blockchain-based approach.

-

A novel algorithm is introduced for preserving and securely retrieving healthcare records using blockchains.

-

The viability and coherence of the access process and system interaction amongst network participants was tested by putting the suggested framework into practice.

-

The average time taken to download and upload health data, the cost of under-taking PCEHRM functions, as well as the efficiency of the transaction were examined and evaluated. Consequently, examining the test network permits us to validate and optimize the prototype prior to publishing it on a public blockchain.

2. Related Work

This section covers the study related to using blockchain technology in the e-healthcare industry to guarantee safe data storage and effective access management. Blockchain technology offers a cryptographic fix to the security issues that are hindering the growth of electronic health systems. Medical enterprises have encountered taxing challenges over the past 20 years as a result of incidents involving record breaches in major medical data centers [6]. MedRec became the first organization to suggest a blockchain-based electronic patient record management system in the early days of blockchain technology [7]. At that time, the Ethereum blockchain and smart contracts preserve detailed accessible healthcare records. However, the medical records are stored in third-party databases operated by healthcare providers, instead on the blockchain network. As a result, the violation or misuse of these records is still a possibility. Healthcare management framework encrypts patient keys during the process of creating or updating data on the blockchain [8]. To decrypt the record, healthcare personnel and lab technician would have to request authorization from a patient’s public key. This is starkly in contrast to our approach, as patients are the sole party with access to and control over their data. Any node can connect to the network and conduct transactions on the public blockchain [9]. A blockchain-based application called Medchain allows patients, pharmacists, and hospitals to exchange healthcare data [10]. This architecture stores data on-chain, and thus, presents scalability and privacy issues. A blockchain-based IoT solution may utilize smart contracts to track patients’ health [11]. The authors in [12] proposed a blockchain-driven system for maintaining electronic medical records, while [13] presented a blockchain-based architecture that incorporates distributed health records with node models to optimize the replication of healthcare records. The researchers in [14] used blockchain smart technology, a decentralized network with smart contracts, to save and transfer data in a secure manner. In a study by [15], a privacy-preserving system was developed for remote patient surveillance. A permissioned blockchain with an access control audit log was also developed to store health records, but it raises privacy concerns owing to the distribution of the audit log with all interested parties [16]. The authors of [17] argued about the robustness of blockchain technology in storing medical records and raised concerns about the scalability and privacy issues concerning the framework. In another study by [18], they proposed a ring structure-based access control that ensures privacy, but inadvertently leads to an unstable system as the data is maintained in an on-chain database. Ref. [19] also proposed an intelligent data management framework for the cyber system. The decentralized storage and access of records, as described in [20], effectively utilize the network’s power and resources. In another study by [21], they employed high-end privacy-enhancing technologies such as homomorphic encryption, which permits data processing while maintaining complete encryption to avoid vulnerability problems. Meanwhile, the researchers in [22] adopted the zero-knowledge proofs approach, along with proof authority consensus for mutual authentication to enhance privacy by ensuring that nodes were not engaging in a malicious manner. Using blockchain technology, several cryptographic mechanisms for preventing tampering and becoming an effective data storage and sharing solution are shown in

Table 2. Several solutions of the existing techniques EHR systems currently lack adequate interoperability to provide private, effective, and secure access control.

Ref	Implemented Problems	Problem to Be Solved
[7]	Data Integrity and Interoperability	Privacy and scalability
[10]	Sharing if Data and Integrity of Data	Privacy and scalability
[11]	Public data access and Integrity of data	Interoperability and authentication
[13]	Interoperability	Secure, Privacy, and Scalability
[15]	Privacy and Security	Scalability and Interoperability
[16]	Scalability and interoperability	Privacy
[17]	Security	Scalability and Privacy
[18]	Security and Privacy	Scalability

.

3. Framework Components

In this study, as shown in Figure 2, we established a permissioned infrastructure in an Ethereum Blockchain framework that allows complete control of records by patients while ensuring privacy, durability, and security. This is carried out by maintaining health information primarily on the blockchain as hashes, whereas the original bulk quantities of data are stored off-chain in IPFS to guarantee effectiveness and scalability.

The smart contract chain code protocol in this paper is termed a Patient-Centric Healthcare Data Management Access Control-Smart Contract, in which this SC is used to write the role-based access control chain code for recognized stakeholders involved and does not employ any incentive mining beyond ensuring that every party has equal access to the system. The role-based unique ID is initiated after the registration of stakeholders. Following this process, public and private key pairs are provided to each stakeholder for the storage and transfer of health information. In this architecture, a patient’s health record is created by doctors. Subsequently, the patient would commit the encrypted health record to be stored in IPFS indelibly while the record hash from IPFS is conserved via the Ethereum blockchain.

In the event that the doctors need to update the patient’s health record, one can allow or block the process by granting or revoking access, respectively. The temporary view, or patient-centric view, of the health record, is constructed from IPFS. In this view, the doctor is allowed to update the documentation before the patient commits to the update using their key pairs to save the updated files in IPFS. In this way, this framework would ensure the interoperability of the mechanism.

Additionally, patients have the right to grant access to share the records with only the relevant stakeholders in a patient-centric view of the record from the IPFS system. A doctor’s session also would expire before the hash value is committed to the ledger so that non-concerned personnel would have gained access to a record without the patient’s permission, hence, safeguarding the data privacy in the system. At the back end, smart contracts are generated for several healthcare procedures.

Hence, role-based access control employed in this framework protects the privacy of the patient. Moreover, our proposed system also has improved scalability and interoperability features as compared to the current system.

3.1. Ethereum Blockchain

Ethereum is designed based on the Bitcoin architecture and features a framework for programmable smart contracts (SC) [23,24]. Simply put, SC is a software program that holds guidelines for negotiating contract conditions. The cost of building and maintaining a centralized database can be minimized by allowing programs to autonomously validate and implement contract-related agreements. SC utilizes the Ethereum virtual machine to enable users to operate SC well within the blockchain network. The value of gas generally determines how the Ethereum system calculates fees [5,23]. A certain amount of gas, which in turn is purchased using digital currency, is required to perform SC and handles a transaction. Hence, the actual transaction cost can be defined as in the equation below:

Ether = gas price × gas used

The Ethereum platform predominantly consists of two types of accounts: contract accounts commanded by the contract code, and externally owned accounts (EOAs) controlled by private keys. EOAs are used to undertake ether-sending transactions or to initiate SC execution. Account nonce, sender signature, recipient address, gas limit, ether values, gas price, and the endpoint of the medical data are just a few of the factors that are included in an Ethereum transaction. An affiliated state database for the Ethereum blockchain is built on an IPFS-like Merkle-Patricia tree structure [25]. Essentially, we can design a blockchain framework using IPFS for a more robust and secure off-chain and on-chain storage of medical records. We implemented the proposed system using the Ethereum blockchain’s smart contract architecture, resulting in an unambiguous, fine-grained access control mechanism that prohibits hacking and unauthorized access without the patient’s consent.

3.2. Distributed InterPlanFile System (IPFS)

Within the P2P IPFS system, a cryptographic hash serves as a distinct fingerprint for each file. In this regard, the hash address is employed to make the contents immutable [11,26]. In the IPFS file storage structure, Merkle DAGs combined Merkle trees with DAGs. The fundamental functionality of IPFS to access health information may be achieved by content-based addressing rather than location-based addressing. By harnessing the IPFS structure, lowered bandwidth costs can be achieved, file download speeds can be improved, and a substantial amount of data may be transmitted without duplication, which can free up storage space. Additionally, IPFS is an immutable storage solution since the hash value of an IPFS file cannot be modified.

3.3. A Background of the Proposed System

Our system structure, as displayed in Figure 3, has the organization use three peer nodes, with one acting as a validating peer node and the others as an ordering node for registering stakeholders. Multiple peers can access the same database in this system, which also uses IPFS for distributed data storage [27]. Multiple peers can be added to various locations on different machines to test the system’s scalability. This framework, which contains its own ledger and smart contract copies, provides access to ledgers for smart contracts.

Peer nodes are linked to the application, which then uses smart to update the ledger. Figure 4 shows the data structure of the blockchain ledger after the integration of PCEHRM data fields, as it is intended to record only the information that patients wish to provide in a transaction. Peernode1, Peernode2, and Peernode3 are the three peer nodes in the organization, and each one has a copy of the ledger and a smart contract.

In this sense, the patient’s profile, address and location, diagnoses, doctor recommendations, next review notes, physician’s names, medication, scan and test reports, and hospital ID are all included in the healthcare records.

The following stakeholders make up the PCEHRM:

4. Record Owner

Patients retain their medical data, making them the owner of the record. To store the data, patients are required to acknowledge and sign an agreement on PCEHRM-SC in the Ethereum blockchain. The chain networks permit patients to specify access rights to their healthcare information, defined by each PCEHRM-SC within its context.

Table 3. Patient roles.

Patient	Grant-Revoke-Commit, Read Record
	Revoke permission from Doctor/Service Providers.
	Permission to Doctor to Read/write of their her.
	Able to search for Doctor/Labs.

further describes the patient roles in detail.

5. Data Uploader

The doctors/lab technicians may upload their patients’ medical data to Data Uploaders. The primary responsibilities of the data uploaders include submitting the concerned individual’s encrypted clinical data to the IPFS community and validating the preliminary transaction at the blockchain. This is further illustrated in

Table 4. Doctors/lab roles.

Doctor/Labs	-Create/Read/Write on Permission for EHR -Search for Doctor in the network
	-Read/Write on Permission for EHR. -Search for Labs the network.

.

6. Data Users

Data users are defined as the parties that require patients’ medical or clinical records for further action, namely, hospitals, researchers, insurance companies, and doctors. In this context, the role-based access control approach in PCEHRM-SC specifies the mechanism for patients to grant access rights to data users.

6.1. Data Encryption

Cryptographic methods guarantee the privacy and integrity of blockchain data. Figure 5 depicts the interaction between patients and their doctors while examining health records. The doctor initiates the process by requesting access permission to retrieve the information stored in the IPFS. Depending on the data fields requested, this generates a patient-centric view of the records rather than disclosing all the patient’s information. The session key, Sk, is used to store the encrypted patient-centric view in IPFS and to retrieve records in a finite period. After doctors and patients have received encrypted patient-centric views and Sk, doctors may decrypt the Sk and patient-centric views for the process of updating the record.

The patient would be notified after the revision of the record in IPFS. The Sk and patient-centric view are automatically erased when a patient commits to his health record. By prohibiting complete access to health records without the patient’s consent, this framework is advantageous in terms of protecting patients’ privacy. Then, utilizing smart chain code operating on the system’s back end, the hash value of the data is safely preserved on the Ethereum blockchain. The ledger will then notify the patient after the records were successfully created or updated.

6.2. PCEHRM-SC

The process of role-based access is initiated once doctors request permission to the IPFS health record of patients, in which patients are in control to allow or revoke access for authorized users as shown in Figure 6. With the patient’s consent, the doctor may create, view, and modify medical records before the patient commits the update to permanent storage. The patient-centric view of the health information can only be accessed by other participants in this health chain architecture for a given session, provided their ownership and object ID match the patients’ [27]. These stakeholders include insurance agents, pharmacists, and researchers. As for laboratory technicians, they can only modify or update patients’ medical records after the approval of the patient and the doctor. The regulations, access control, and privacy agreement are provided by authorization of smart contracts and are governed by the Ethereum blockchain. This methodology adheres to certain situations:

• An access control regulation specifies the stakeholders’ distinct profiles and defines their access rights.
• After the patient allows access, the system defines the approved value to stakeholders, resources, action types, and environmental attributes.

In addition, the proposed solution segregates privacy attributes into three levels below:

Level 1:

Patients are the sole party to access the health record.

Level 2:

Approved stakeholders may be made available to the medical record.

Level 3:

The permitted patient’s caregiver has access to the health record in an emergency.

By setting their privacy level, patients may manage the confidentiality of their data. Prior to submitting a modified medical record to the chain network, the levels in our model are calibrated to alter the terms during the transfer of authorizations to other authorized participants.

6.3. PCEHRM Algorithm

Our proposed framework consists of four stakeholders: Pa, D, Ph, and LT, which represent patients, doctors, pharmacists, and lab technicians, respectively.

Table 5. Symbols in the algorithm functions.

Symbols	Definition
${Pa}_n$	nth Patient
$D_n$	nth Doctor
${Ph}_n$	nth Pharma
${LT}_n$	nth Lab Technician
${HR}_n$	nth Health Record
${Papubk}_n$	nth Patient Public Key
${Paprk}_n$	nth Patient Private Key
${Dpubk}_n$	nth Doctor Public key
${Dprk}_n$	Doctor Private Key
$S_k$	nth Session Key
${Pacenv}_n$	nth Patient-Centric View
${UP\_Pacenv}_n$	nth Update Patient-Centric View
${HR}_n\_hsh$	nth Health Record Hash Value

shows these symbols in the algorithm functions. The n is the number of doctors, patients, health records, pharmacists, and lab technicians where n = 1, 2…N. Patients, medical professionals, and pharmacists are among the n stakeholders provides public key. All stakeholders will each receive a key pair consisting of public and private keys. On that note, ${Papubk}_n$, ${Paprk}_n$, ${Dpubk}_n$, and ${Dprk}_n$ are the public and private keys of the patient and doctor, respectively.

In Algorithm 1, the patient allows the doctor access to their health record based on PCEHRM-SC. Hence, a patient-centric view of the health record is generated by the system.

Based on the doctor request, the patient-centric is queried for attribute-based data instead of granting unrestricted access to the patient’s health record, as patient-centric can enable users to view and update only the specific fields of HR instead of sharing whole patient health records.

Essentially, the patient-centric view is a subset of the medical record. In accordance, the system creates a session key ($S_k$) used by both patients and physicians within a particular session. An encrypted session key for ${Papubk}_n$ and ${Dpubk}_n$ is derived using the public key for patients and doctors, respectively. The session key $S_k$ which can be sent to doctors is also encrypted with a patient-centric view.

Algorithm 1 calls the create_Update_HR() function of Algorithm 2 to start updating the ${HR}_n$. After the doctor’s and ${Pacenv}_n$ session key have been decrypted, the modifications are uploaded into the updated patient-centric view (${UP\_Pacenv}_n$).

The encrypted ${HR}_n$ is decoded once the system is updated, acquired by decryption of the encrypted private key using the patient’s password, and appended to the encrypted ${UP\_Pacenv}_n$. For the last step, the ${HR}_n$ is saved in IPFS after the patient commits to the updates. Then, once the health record ${HR}_n$ is committed, it immediately ceases the $S_k$ and ${Pacv}_n$. In the Ethereum blockchain, the health record hash value ${HR}_n\_hash$ is generated by the IPFS and saved in blocks.

Algorithm 1. System_Function()

Input: Doctor $D_n$, with their Public key ${Dpubk}_n$, with their Private key ${Dprk}_n$, with session key $S_k$ of ${HR}_n$ Health_Record. Patient ${Pa}_n$ with their Public key ${Papubk}_n$, and Private key ${Paprk}_n$. Output: Boolean (True or False) Function for storing and updating health records. For user $U$ have Access permission to HR Check PCEHRM-SC If (permission==“Grant” && role==“Doctor”) then   Create ${Pacenv}_n$ for ${HR}_n$ in IPFS   ${Pacenv}_n$→ Decryption (Encryption (${HR}_n$))   Create $S_k$   send Encrypted (${Papubk}_n$ ($S_k$), ${Dpubk}_n$($S_k$), ${Pacenv}_n$($S_k$)) to ${Pa}_n$,   $D_n$ and ${Pacenv}_n$.  create_Update_HR()   ${HR}_n$ → [(Decryption ${Papubrk}_n$ (Encrypted ${Papubk}_n$ (${HR}_n$)) + Encryption (${UP\_Pacenv}_n$)]  ${Pa}_n$ → Commit (IPFS (${HR}_n$))  IPFS → ${HR}_n\_hsh$  $HRn\_hsh$→ Ethereum Blocks  Return True Else   Permission=Deny   Return False End if End For End Function

Algorithm 2. create_Update_HR ()

Input: $D_n$, ${Dpubk}_n$, ${Dprk}_n$, $S_k$  Output: Storage of HR Function Doctor ${Dpubk}_n$ For Doctor with ${Dpubk}_n$, $S_k$ $D_n$→ Decrypt(${Dpubk}_n$($S_k$)) $D_n$→ Decrypt(${Pacenv}_n$($S_k$)) ${Pacenv}_n$→ ${UP\_Pacenv}_n$ IPFS Encrypt(${UP\_Pacenv}_n{(S}_k$)) End For End Function

7. PCEHRM Protocol Operation

The proposed architecture consists of two parts of development environments, back-end and front-end. It is also developed upon network entities and smart contracts to handle each transaction by utilizing an IPFS storage solution. Performance evaluation was carried out on a intel^®Core™i7 @ 3.38 GHz processor and 16 GB of RAM. For the back-end development, we used the Ethereum Platform and a Windows Foundation project, while the front-end development was implemented using JavaScript, CSS3, HTML5, and ReactJS. We also integrated third-party frameworks such as jQuery and Bootstrap to construct the web application in a more user-friendly and effective fashion. REST API servers were used to execute back-end programming while a database was employed for Front-end programming. On top of that, Truffle Framework, Ganache (Ethereum Blockchain), NodeJS and its libraries, as well as Metamask Browser extension (to connect Browser to Blockchain) were also adopted for this experiment. Solidity programming language was adopted for the implementation of PCEHRM in the remix IDE [28]. Using Kubo (go-ipfs), we established IPFS and transmitted an encrypted medical record to the network, returning a distinct hash value associated with the uploaded record. Then, by specifying the IPFS hash, the essential medical record attributes, and the patient Ethereum public key, we modified transactions on the blockchain. HTTP methods, for instance, POST, GET, PUT, and DELETE are triggered once clients consume web applications to call out actions. These methods, in turn, invoke HTTP responses by the web service based on the request by the client. The full PCEHRM-SC prototype code is available in our GitHub repository.

7.1. Add Users

Figure 7 details the successive steps to add users to the network. The smart contract may now create a role-based unique ID for the enrolled stakeholders upon their registration.

7.2. Add Records and Update Records

After the patient has been allowed access, the doctor may create a record before it is encrypted and stored in IPFS using the hash value that is maintained via the Ethereum blockchain. A temporary, patient-centric view of the medical record is supplied so that the physician may update the view and subsequently, the existing record incessantly in both IPFS and health record chains following the patient’s authorization. Consecutively, the session key would lapse, denying doctors access to patient-sensitive information. Figure 8 specifies the step-by-step operation of appending and modifying health records in the network.

7.3. Assuring Authorized Users Have Access

Patients maintain restrictive access control to grant or deny access permissions to stakeholders within a restricted setting to allow them to view, modify, or create records, providing patients full authority and control over their health records. This is carried out by authorizing consent to medical records based on the role and permission type for authenticated users approved by consensus. In the event that healthcare personnel are denied access, the records would not be made available to them or other attending physicians. Upon interaction of users with the system, smart contracts identify and validate the requests, perform data updating, and provide access rights. Figure 9 describes the actions sequentially for the role-based access rights and permission.

7.4. Records Retrieval

Patients must allow access for the retrieval of partial attribute-based data from IPFS using the hash value in the chain network, so that all stakeholders may access their records. Figure 10 delineates the view record step-by-step implementation.

7.5. Framework Implementation

Chain codes, smart contracts, network entities, and IPFS storage are all components of the Health Chain Network Transaction Framework [26]. In the user sign-up module of the network, receptionists, pharmacists, physicians, and other medical personnel can enroll using their respective roles, upon which the certificate of authority is produced after the registration. Users can sign in using their email address credentials and password after enrolment. In this case, receptionists may approve or decline appointments made by the stakeholders using patient IDs and update them based on the patient’s data. If the appointment proceeds, doctors may create or update the patient’s medical record via notes or diagnosis results before being uploaded to IPFS.

Our recommended business ecosystem contains elements such as assets, stakeholders, and transactions, as depicted in Figure 11. Several tests were carried out for the health chain framework prototype to evaluate its performance and functionality through four case studies that describe its storage, scalability, efficiency, and security.

7.5.1. Storage Efficiency

To assess if the interplanetary database can sufficiently hold and retain health records, a few cases were performed in the following ways:

• Doctors were able to upload health records.
• With the patient’s permission, a doctor could view the medical records.
• Patients were capable to view their health data.
• Patients and doctors were permitted to retrieve health records based on their credentials.
• Encrypted health records were generated proficiently.

Subsequently, encryption and decryption of the modified records in IPFS could be accomplished by doctors and patients, respectively, using their corresponding session keys.

7.5.2. Security

Before the data is saved in IPFS, the following instances were verified to confirm security requirements for the effective implementation of encrypted health records:

• Encryption of the user’s password.
• Health records were saved in IPFS with encryption.
• Each record was assigned a distinct hash value.
• Public and private keys were assigned to all stakeholders.
• Session keys assignment and expiration.

7.5.3. Privacy

The objective of this test is to confirm whether or not stakeholders were granted or denied access to health records depending on their role. The access control was verified using test instances as listed below:

• Depending on their role, stakeholders were able to view their respective home pages.
• Access rights based on the stakeholders’ role.
• Session keys were allocated for viewing medical records.

This was performed to prove that the system is capable of assigning access permissions based on their levels and roles.

8. Evaluation

In this section, we tested the viability and coherence of the access process and system interaction amongst network participants by putting the suggested framework into practice. We investigated the average time taken to download and upload health data, the cost of undertaking PCEHRM functions, as well as the efficiency of the transaction. Consequently, examining the test network permits us to validate and optimize the prototype prior to publishing it on a public blockchain.

8.1. Verification of PCEHRM-SC

By testing two key functions for brevity givePermission(), removePermission(), we were able to confirm the access rights and interactions between entities. The results of these test are presented in Figure 12 and Figure 13, depicting the summary of the transaction event log maintained in the blockchain once the functions were successfully executed.

8.2. Practical Applications and Costs

In the proposed system, we define the cost for the actual transactions and time taken to execute for each transaction. The cost is calculated by ether = gas used × gas price; “gas used” means the constant computational cost. The network adjusts the price of gas to compensate for changes in the value of ether [8]. Thus, the total transaction costs (ether) for the accessibility of health data remain relatively constant. Regarding the paying segment, all participants must pay gas for performing an operation in SC. Therefore, the automated SC process would result in significant cost savings for the patient. In the implemented PCEHRM-SC prototype, we have set a gas limit of 30,000, with each gas unit fixed at 2 Gwei.

Table 6. PCEHRM time and cost analysis (database).

Function Name	User	Start Time	Time Taken	Gas Used	Total Cost
addDoctor()	0x0bCD3A9Fcc8EfC4B5B2c07BC1129454A9C1fc56D: (Admin)	10/27/22, 7:27 A.M.	10.316 s	44,721	0.00089442 ETH
addPatient()	0x770a246c2CF57D25661Ef48C8D01b14D89264169: (Patient)	11/30/22, 6:35 P.M.	13.669 s	148,329	0.00296658 ETH
addDoctor()	0x0bCD3A9Fcc8EfC4B5B2c07BC1129454A9C1fc56D: (Admin)	11/30/22, 6:37 P.M.	13,949 s	44,721	0.00089442 ETH
getpatientDetails()	0x770a246c2CF57D25661Ef48C8D01b14D89264169: (Doctor)	11/30/22, 6:38 P.M.	0.213 s	0	0 ETH
saveMedicalRecord()	0xa96C9CB8b1Ae46FEE4cC3d65877464dB72070e5e: (Doctor)	11/30/22, 6:38 P.M.	12.506 s	168,010	0.0033602 ETH

summarizes the time taken and cost of operations performed in SC. The addDoctor() function is implemented once at a cost of 0.00089442 eth with used time 10.316s. The addPatient() function costs around 0.093 eth, which is higher than other functions due to the additional input bytes that are included during function execution, such as the patient’s blockchain address and usage notes. However, the used time for execute this function is not high compared to executing the getpatientdetails() function was 0.213s which requires fetch the EHR’s data of the patient.

In general, the overall costs can be further reduced by keeping the size of the input data to a minimum. However, these costs are still lower than those associated with purchasing storage space from a third party or maintaining a database through a centralized system such as ISN [29], MedBlock [30], MeDShare [31], and MedChain [11].

8.3. Performance Evaluation

Storing large amounts of data on the blockchain is costly, so to minimize costs, IPFS hashes are stored on the blockchain. Figure 14 shows the predicted difference in cost events as the number of transactions on the blockchain increases. Primarily foresee the cost of writing data to the blockchain, as it is a more expensive transaction than reading data from the blockchain. As shown in Figure 14, storing his IPFS hash rather than the entire image significantly reduces storage costs.

Our proposed system stores the media in IPFS, and IPFS stores media with the help of peers. Figure 15 shows that as the number of peers accessing the transaction or contributing to image storage increases, the execution time, or the time required to retrieve the media, increases. Depending on the previous section, the larger the image or report size, the longer it takes to access the same.

9. Discussion

To ensure the best possible health care experience for the patient, the patient should be able to access or grant access to his or her medical information as needed. This is currently not possible when the data is stored in a hospital’s proprietary Electronic Health Record (EHR). As a result, there is a requirement for patient operated where the details of the patient’s treatment are with the patient. This paper proposes a secure, interoperable patient-centric data access management system based on blockchain. In our proposed system, the patient has complete control over his or her health record-related data, which is stored securely using IPFS. Using a token, patients can grant controlled access to their medical data to health care providers for a set period of time. In the following,

Table 7. Comparison between the existing and suggested patient-centric health storage models.

Ref	Ease of Scaling	Access Control	Confidential Information	Data Integrity	Data Security	Patient-Centric
[10]
[15]
[16]
[17]
[18]
[32]
PCEHRM

explains the summary of the comparison between the existing and suggested patient-centric health storage models focusing on privacy, scalability, security, and integrity. The authors in [16,17] reviewed current strategies for healthcare management using blockchain technology and its effects. The existing architectures in [10,15,18,32] were examined. Each block includes a health record hash value that would transform whenever the record is updated. This ensures the records are immutable as it is computationally expensive to manipulate the ledger. On top of that, stakeholder access to patients’ medical records is prohibited by access control rights and levels.

10. Conclusions

Medical records are the most precious commodity in the industry of healthcare intelligence. Often, this information is indeed dispersed across various platforms, posing a challenge in sharing them for an efficient and cohesive healthcare system. Meanwhile, a centralized hosting solution, for instance, a cloud-based platform, is vulnerable towards a single point of a cybersecurity attack. Decentralized designs and system interoperability have received more attention as the dispersed nature of healthcare services has come to light. In this study, we incorporated the PCEHRM system, a decentralized framework for sharing access and storing medical data that is built on the Ethereum blockchain and IPFS architecture. We also introduced a novel access control system termed PCEHRM-SC that provides authorized parties access to the pertinent blockchain data. By giving patients complete management over their healthcare records utilizing smart contract protocol, the PCEHRM system promotes a unique manner to enhance their rights. For example, patients have full control over their medical reports and possess the ability to allow or deny access to the records for use in clinical trials or research. We also analyzed and evaluated the feasibility, effectiveness, and rationality parameters of the proposed framework. As a result of the analysis, the implemented system appears to be efficient and satisfies many security requirements. A high level of privacy, security, confidentiality, and scalability can be achieved.

By offering higher productivity, data integrity, and efficient audit, while allowing for shared access to medical data, the suggested scheme makes it easier for patients to access an immutable medical database. Since the data storage and exchange model are also de-centralized, it is crucial to involve third-party intermediaries and eliminate administrative structures. Our long-term study objective is to implement the suggested system architecture on the public blockchain using real-world examples to establish a worldwide PCEHRM system and to assess associated laws and standards to integrate this cutting-edge technology within the healthcare system. Without a doubt, the artificial intelligence component would aid clinicians in the analysis of diagnostic medical data and communicate more effectively with patients.