Hyperledger Healthchain: Patient-Centric IPFS-Based Storage of Health Records

: Blockchain-based electronic health system growth is hindered by privacy, conﬁdentiality, and security. By protecting against them, this research aims to develop cybersecurity measurement approaches to ensure the security and privacy of patient information using blockchain technology in healthcare. Blockchains need huge resources to store big data. This paper presents an innovative solution, namely patient-centric healthcare data management (PCHDM). It comprises the following: (i) in an on-chain health record database, hashes of health records are stored as health record chains in Hyperledger fabric, and (ii) off-chain solutions that encrypt actual health data and store it securely over the interplanetary ﬁle system (IPFS) which is the decentralized cloud storage system that ensures scalability, conﬁdentiality, and resolves the problem of blockchain data storage. A security smart contract hosted through container technology with Byzantine Fault Tolerance consensus ensures patient privacy by verifying patient preferences before sharing health records. The Distributed Ledger technology performance is tested under hyper ledger caliper benchmarks in terms of transaction latency, resource utilization, and transaction per second. The model provides stakeholders with increased conﬁdence in collaborating and sharing their health records. order to validate its functionality and evaluate its performance. An assessment of the health chain framework systems is realized through the application of four case studies that illustrate efﬁciency, scalability, storage, and security.


Introduction
Providing a secure and private access control model is one of the most critical aspects of healthcare. Big data are used to store and access a large amount of health information over the Internet in the big data age. Cloud networking plays an increasingly critical role in this process. Traditional electronic health record (EHR) systems present numerous privacy and security challenges despite their ease of use and reliability. [1] Health record (HR) contains a lot of sensitive information about patients and diagnoses; therefore, it is considered the most sensitive data collection method. HR data has, however, become more susceptible to breach due to the advancement of the internet and advancement in digital healthcare systems [2]. Therefore, the security and privacy of HR data need to be taken into account when assessing a decentralized and trust-based approach [3].

Motivation
The electronic medical records (EMRs), electronic health records (EHRs), and personal health records (PHRs), clinical images, and patient information such as doctor names, individual measurements, and home-checking gadget information are centralized in cloud names, individual measurements, and home-checking gadget information are centralized in cloud databases used by content organizations. A centralized database can expose us to cyber-attacks, which threaten the privacy and security of EHR. Health providers and other stakeholders have difficulty sharing health information due to varying standards and formats. The EHR can be permanently lost when it is deleted from the hospital's database. This is yet another issue to be addressed carefully. It is imperative that systems are tamper-proof so that only authorized individuals can gain access to them. A further problem is that current healthcare systems do not completely empower patients to manage their health records since they are managed by our service providers. As healthcare data continues to increase, medical records' security and scalability have become major concerns. The overview of the existing health record system architecture is shown in Figure  1.

Contribution
Technology that stores data effectively is therefore required. The paper contribution is shown in Figure 2. To achieve this, an effective patient-centric distributed architecture for storing patient-centric data is simultaneously concerned with privacy, security, integrity, interoperability, and scalability. This research identifies security and privacy issues and examines a blockchain-based approach to conquer them. Second, we have created a novel algorithm for storing and securely gaining access to records using blockchains.
In this research, we are developing a permissioned network in a hyper ledger fabricbased PCHDM framework that ensures health record integrity, security, scalability, and privacy while providing patients with complete control. Health information is mainly stored on the blockchain as hashes, whereas the original vast quantities of data are maintained off-chain in IPFS to ensure scalability and efficiency.
The smart contract chain code protocol in this research is named Patient-Centric Healthcare Data Management Access Control-Smart Contract, PCHDMAC-SC, where PCHDMAC-SC is the role-based access control chain code written using Access Control language for registered stakeholder groups and does not use any form of incentive mining beyond equitable access to the system. After the registration of stakeholders, the Fabric Certificate authority generates the role-based unique ID for the registered stakeholders. Each stakeholder is created with public and private key pairs for secure storage and sharing of the health records. A patient's health record can be created by a doctor. After crea-

Contribution
Technology that stores data effectively is therefore required. The paper contribution is shown in Figure 2. To achieve this, an effective patient-centric distributed architecture for storing patient-centric data is simultaneously concerned with privacy, security, integrity, interoperability, and scalability. This research identifies security and privacy issues and examines a blockchain-based approach to conquer them. Second, we have created a novel algorithm for storing and securely gaining access to records using blockchains.
In this research, we are developing a permissioned network in a hyper ledger fabricbased PCHDM framework that ensures health record integrity, security, scalability, and privacy while providing patients with complete control. Health information is mainly stored on the blockchain as hashes, whereas the original vast quantities of data are maintained off-chain in IPFS to ensure scalability and efficiency.
Electronics 2021, 10, x FOR PEER REVIEW 3 of 24 tion, the patient commits the encrypted health record, which will be stored in IPFS permanently. The generated health record hash from IPFS is preserved via the Hyperledger blockchain. The patient wants the doctor to be able to update his or her health record by granting access. The temporary view, called the patient-centric view of the health record, is generated from IPFS. The doctor can update the patient record using the patient-centric view, and then the patient commits to the update using their key pairs to store the updated health record again in IPFS. Hence, interoperability is achieved by developing this framework. A doctor session will expire before the hash value is committed to the ledger of the Hyperledger fabric using Couch DB. Therefore, no doctor has access to a patient's record without the patient's permission, which implies that the patient's privacy in the system has been protected.
To share the records with stakeholders, the patient wants to grant access that retrieves a patient-centric view of the record, i.e., partial information about the patient retrieved from the IPFS system. That means the privacy of patient health information is preserved.
Smart contracts PCHDMAC-SC are created at the back end for multiple healthcare processes, and then each patient manages the permissions to access data within the healthcare ecosystem. Hence, this system protects the privacy of the patient using role-based access control, and its scalability is tested and evaluated under hyper ledger caliper benchmarks. The performance evaluation results show our proposed system has improved scalability and interoperability compared with the existing system. The smart contract chain code protocol in this research is named Patient-Centric Healthcare Data Management Access Control-Smart Contract, PCHDMAC-SC, where PCHDMAC-SC is the role-based access control chain code written using Access Control language for registered stakeholder groups and does not use any form of incentive mining beyond equitable access to the system. After the registration of stakeholders, the Fabric Certificate authority generates the role-based unique ID for the registered stakeholders. Each stakeholder is created with public and private key pairs for secure storage and sharing of the health records. A patient's health record can be created by a doctor. After creation, the patient commits the encrypted health record, which will be stored in IPFS permanently. The generated health record hash from IPFS is preserved via the Hyperledger blockchain.
The patient wants the doctor to be able to update his or her health record by granting access. The temporary view, called the patient-centric view of the health record, is generated from IPFS. The doctor can update the patient record using the patient-centric view, and then the patient commits to the update using their key pairs to store the updated health record again in IPFS. Hence, interoperability is achieved by developing this framework. A doctor session will expire before the hash value is committed to the ledger of the Hyperledger fabric using Couch DB. Therefore, no doctor has access to a patient's record without the patient's permission, which implies that the patient's privacy in the system has been protected.
To share the records with stakeholders, the patient wants to grant access that retrieves a patient-centric view of the record, i.e., partial information about the patient retrieved from the IPFS system. That means the privacy of patient health information is preserved.
Smart contracts PCHDMAC-SC are created at the back end for multiple healthcare processes, and then each patient manages the permissions to access data within the healthcare ecosystem. Hence, this system protects the privacy of the patient using role-based access control, and its scalability is tested and evaluated under hyper ledger caliper benchmarks. The performance evaluation results show our proposed system has improved scalability and interoperability compared with the existing system.

Organization
The remainder of the paper is structured as follows: Section 2 addresses the related work. Section 3 presents the framework of the proposed PCHDM. Section 4 presents the implementation of the proposed PCHDM. Section 5 discusses the results and performance evaluation. Section 6 concludes the paper and discusses future work.

Related Works
In this section, we discuss research related to the use of blockchain technology in e-healthcare to ensure secure data storage and efficient access control. The growth of electronic health systems is hindered by security issues. Blockchain technology has arrived and provides a cryptographic solution to the problem of security, but it has challenges, such as privacy, scalability, and interoperability. Throughout the past two decades, medical companies have experienced additional challenges caused by record breach episodes within large medical data centers [4]. In the early days of blockchain technology, MedRec [5] became the first suggestion for an electronic patient record management system that was implemented by blockchain technology. Ethereum blockchain and smart contracts store detailed accessibility data. The blockchain does not store medical records, but rather the third-party database operated by healthcare providers. Infringement or misuse of these records is therefore still possible. By recording data on the blockchain, healthcare management systems [6] encrypt patient keys. To decrypt data, hospitals and researchers obtain consent from a patient's public key to decode the data. This contrasts dramatically with our approach, in which patients are the only ones who have access control to their data. On the public blockchain, any node can join the network and their transactions are transparent [7]. The Medchain is a blockchain based application that permits hospitals, pharmacies, and patients to share healthcare data [8]. Data is stored on-chain, but they suffer from scalability and privacy problems. With blockchain-based smart contracts [9], the health of patients could be tracked using a blockchain-based IoT platform. A blockchain-driven system for tracking electronic healthcare records was proposed by the author in [10]. The author of [11] presented a blockchain-based architecture that integrates distributed health records across node models to maximize replication of health data. The author of [12] used smart technology called blockchain, which is a decentralized network with smart contracts, to store and share data with security. In [13], a privacy-preserving system was modeled for remote patient monitoring. The author [14] has proposed a permissioned blockchain with an access control audit log for storing the health record but it suffers from privacy issues due to the sharing of audit log information to all stakeholders. The author of [15] discusses the security of medical data using blockchain technology but faces privacy and scalability concerns. The author in [16] has proposed a ring structure-based access control that ensures privacy and the system is not stable due to scalability issues as the data is stored as an on-chain database. An intelligent data management framework was proposed for the cyber system in [17]. As described in [18], the decentralized storage and access of records effectively utilizes the network's power and resources. As in [19], the author used high-end privacy-enhancing technologies, such as homomorphic encryption, that allow data to be processed while remaining completely encrypted so that vulnerabilities can be prevented. As a privacy enhancement technique, the author [20] used zero-knowledge proofs along with proof authority consensus for mutual authentication to ensure nodes were not engaging in malicious behavior. A number of cryptographic mechanisms using blockchain technology are shown in Table 1, which can be used to prevent tampering, efficiently store and share data.

Ref.
Implemented Challenge Problem to Be Addressed [5] Data Integrity and Interoperability Privacy and Scalability [8] Sharing of Data and Integrity of data Privacy and Scalability [9] Public Data Access and Integrity of Data Interoperability and authentication [11] Interoperability Security, Privacy and Scalability [13] Privacy and Security Scalability and Interoperability [14] Scalability and Interoperability Privacy [15] Security Scalability and Privacy [16] Security and Privacy Scalability EHR systems are still not sufficiently interoperable for ensuring privacy, security, and effective access control. With the implementation of a permissioned blockchain framework and Practical Byzantine Fault Tolerance as the consensus algorithm, we are able to resolve most of the existing challenges in the eHealth environment to enable decentralized storing and sharing of health information while ensuring patient confidentiality, privacy, and scalability.

Hyperledger Fabric Blockchain
The Hyperledger blockchain network is permission-based and requires users to sign up to use it. Permission on the network is controlled using Hyperledger modeling and access control languages. Hyperledger Fabric is a platform for distributed ledger solutions underpinned by a modular architecture delivering high degrees of confidentiality, resilience, flexibility, and scalability. Medical information is often highly sensitive, in both a social and legal sense, so a closed blockchain such as Hyperledger Fabric helps to retain the necessary privacy required for such an application. Hyperledger Fabric is a better solution for managing access to health records, as it accommodates for multiple layers of permission, meaning the owner of a set of data can control which parts of their data are accessed. Smart contract SC stores rules relating to contract negotiations. The framework designed for role-based access control chain code is named as PCHDMAC-SC.
For medical information sharing efficiently and reliably without having to rely on a single authority, we are employing Hyperledger Fabric, a permissioned blockchain based on pre-specified parties. Hyperledger Fabric offers the advantage of employing the Byzantine fault tolerance consensus protocol without requiring mining or an associated currency as a means of achieving consensus. Hyperledger blockchain uses a Merkle Directed Acyclic Graph tree structure as its state database, which can be replicated using IPFS objects. Therefore, IPFS can be used to model an off-chain and on-chain blockchain for health record storage. By implementing the PCHDMAC-SC protocol, we created a transparent, fine-grained access control system that prevented hacking without patient consent using a Hyperledger blockchain.

Distributed File System-IPFS
A cryptographic hash represents a unique fingerprint for each file within IPFS, a peerto-peer (P2P) protocol. To make the contents immutable, the hash address is applied [21]. Merkle DAGs combine Merkle trees with DAGs in IPFS file storage. Rather than relying on location-based addressing, IPFS's key feature is that access to health record can be accomplished through content-based addressing. Due to IPFS, bandwidth costs can be reduced, record download speeds can be enhanced, and a large volume of data can be distributed without duplication, which can save storage space. The hash value of an IPFS file cannot be changed so IPFS is an immutable storage mechanism.

Services Provided to Members
A cryptographic procedure that validates identity, generates and verifies signatures, and generates and verifies certificates, as well as verifying the identity of the user is described in [22]. In this Hyperledger framework, Fabric-Certificate Authority (CA) of [23] acts as the interface for providing Services to Members who have registered on the network as shown in Figure 3.

Services Provided to Members
A cryptographic procedure that validates identity, generates and verifies signatures, and generates and verifies certificates, as well as verifying the identity of the user is described in [22]. In this Hyperledger framework, Fabric-Certificate Authority (CA) of [23] acts as the interface for providing Services to Members who have registered on the network as shown in Figure 3.

A Background of the PCHDM System
An illustration of health chain's proposed framework can be seen in Figure 4. User requests are sent to the fabric network by the Dapp through an API called the composer, which is interactively handled by the Dapp admin. Through GET calls to the composer, the Angular framework can access the on-chain database and retrieve data based on the current state as returned by the API. Smart contract composer creates decentralized applications based on blockchain business networks. With Hyperledger Fabric [24] network stakeholder can validate medical data entries via smart contracts named chain codes. This technology was developed for distributed ledger solutions. Bitcoin [25] was created specifically for financial transactions, and Hyperledger is for storing health records.

A Background of the PCHDM System
An illustration of health chain's proposed framework can be seen in Figure 4. User requests are sent to the fabric network by the Dapp through an API called the composer, which is interactively handled by the Dapp admin. Through GET calls to the composer, the Angular framework can access the on-chain database and retrieve data based on the current state as returned by the API. Smart contract composer creates decentralized applications based on blockchain business networks. With Hyperledger Fabric [24] network stakeholder can validate medical data entries via smart contracts named chain codes. This technology was developed for distributed ledger solutions. Bitcoin [25] was created specifically for financial transactions, and Hyperledger is for storing health records.
The proposed system architecture as shown in Figure 5 has a Hyperledger Composer users permissioned blockchain based on Hyperledger Fabric to develop web applications for single organizations using three peer nodes. Three peer nodes are used by the organization, one serving as a validating peer node, while another serves as an ordering node that is used to register stakeholders. In this system, multiple peers access the corresponding database, IPFS for distributed storage of data, a Solo Order Node, a Data Certificate Authority, a Membership Service Provider, and smart contracts for blockchain connectivity. In order to verify the system's scalability, multiple peers can be added to multiple locations on different machines. Smart contractors have access to ledgers and have ledger access through this framework. Peer nodes are connected to the application, which then updates the ledger via smart. The three peer nodes in the organization are peernode0 (PE0), peernode1 (PE1), and peernode2 (PE2) each of which contains its own ledger and smart contract copies. which is interactively handled by the Dapp admin. Through GET calls to the composer, the Angular framework can access the on-chain database and retrieve data based on the current state as returned by the API. Smart contract composer creates decentralized applications based on blockchain business networks. With Hyperledger Fabric [24] network stakeholder can validate medical data entries via smart contracts named chain codes. This technology was developed for distributed ledger solutions. Bitcoin [25] was created specifically for financial transactions, and Hyperledger is for storing health records.  The proposed system architecture as shown in Figure 5 has a Hyperledger Composer users permissioned blockchain based on Hyperledger Fabric to develop web applications for single organizations using three peer nodes. Three peer nodes are used by the organization, one serving as a validating peer node, while another serves as an ordering node that is used to register stakeholders. In this system, multiple peers access the corresponding database, IPFS for distributed storage of data, a Solo Order Node, a Data Certificate Authority, a Membership Service Provider, and smart contracts for blockchain connectivity. In order to verify the system's scalability, multiple peers can be added to multiple locations on different machines. Smart contractors have access to ledgers and have ledger access through this framework. Peer nodes are connected to the application, which then updates the ledger via smart. The three peer nodes in the organization are peernode0 (PE0), peernode1 (PE1), and peernode2 (PE2) each of which contains its own ledger and smart contract copies.
In Hyperledger Composer, a single channel (CH) facilitates communication with peers. This network generates a transaction T for our application and sends it to peer-node0, peernode1, and peernode2. The chain codes are installed by the peers based on the execution of a transaction. When querying or altering the ledger, the application uses chain codes to interact with peers. The Health record chain network framework allows the histories of the changes that contributed to the framework to be viewed in the blocks as hash values in the blockchain. In a ledger record, a block relating to the health record of a patient n is mainly comprised of that transaction's workload WLtr(n), hash of preceding transactions WLph(n), and the current transaction hash WLh(n). The block workload can be calculated using WLTot(n) WLTot(n) = WLtr(n)+ WLph(n) + WLh(n) (1) In Hyperledger Composer, a single channel (CH) facilitates communication with peers. This network generates a transaction T for our application and sends it to peernode0, peernode1, and peernode2. The chain codes are installed by the peers based on the execution of a transaction. When querying or altering the ledger, the application uses chain codes to interact with peers. The Health record chain network framework allows the histories of the changes that contributed to the framework to be viewed in the blocks as hash values in the blockchain. In a ledger record, a block relating to the health record of a patient n is mainly comprised of that transaction's workload WL tr(n) , hash of preceding transactions WL ph(n), and the current transaction hash WL h(n) . The block workload can be calculated using WL Tot(n) WL Tot(n) = WL tr(n) + WL ph(n) + WL h(n) The health record consists of patient's profile, Diseases Diagnosed, Address Location, Medicine, Doctor Suggestion, next Review Notes, doctors Name, Hospital ID, Scan and Test image reports.
PCHDM consists of the following stakeholders: 1. Owner of Record Patients own their medical records. A patient will need to sign an agreement on PCHDMAC-SC in the Hyperledger blockchain and store it there. Health record chain networks allow patients to define access rights to their health data. Each PCHDMAC-SC defines this within its own context. Patient role is described in detail in Table 2.

Data Uploader
Doctor may upload their medical data to Data Uploaders. Adding encrypted clinical data of the affected person to the IPFS community and confirming the preliminary transaction at the blockchain are the high responsibilities of the data uploaders. The Doctor/Lab technician role is described in Table 3. Table 3. Role of Doctor/Lab Technician in this proposed system.

Doctor
Create/Read/Write on permissioned Healthcare system Able to search available doctor in network.
Lab Technician Read/Write on permissioned Healthcare system Able to search available Labs in network.

Data Users
All those interested in obtaining clinical or medical data about patients, whether they are doctors, hospitals, insurance companies, or researchers, are considered Data Customers. PCHDMAC-SC contains role-based access control mechanisms that defines how patients can grant access privileges to data users.

Data Encryption
The integrity and confidentiality of blockchain data are ensured by cryptographic techniques. Figure 6 shows how patients and doctors interact with each other when accessing their health records. Bringing up the health records stored in the IPFS, the doctor requests permission to access them. Rather than sharing all the information about the patient, it creates a patient-centric view of the records based on the request. S k is the Session key used to access records in a definite session, and the patient-centric view is encrypted and stored in IPFS with the session key. Doctors and patients receive encrypted patientcentric views and encryption session key S k . Doctors can decrypt S k and patient-centric views for an update on the health record.

PCHDMAC-SC
In order to obtain access to the IPFS health record of the patient, the doctor requests permission from the patients. Role-based access control permissions enable the patient to grant or deny requests for authorized users as shown in Table 4. After the approval of the patient, the doctor can create, write, and read patient records. After the write operation the patient wants to commit his record to permanent storage. In this health chain framework, other stakeholders such as researchers, pharmacists, and insurance agents can only access the patient-centric view of the health records for a specific session if their object ID matches the ownership ID and also the patient. After the approval of the patient and the doctor, the laboratory technician can update the health record. Certificate authority provides the privacy agreement, access control, and policies as a smart contract, and it is managed by the Hyperledger fabric blockchain. This approach has follows certain conditions such as 1. An access control policy defines the unique identity of the stakeholder who is allowed access.
2. The system assigns the authorized value to stakeholders, action types, resources, and environment attributes after the patient has granted access.
This system divides privacy into three levels: Level 1: Health record is visible only to the patient. Level 2: Health record is available to authorized stakeholders. Level 3: During an emergency, the health record is accessible to an authorized patient caretaker.
A patient can control the privacy of his or her personal data by setting their own privacy level. In our model, the levels are configured to modify conditions during the transfer of authorizations to another authorized user prior to submission to the health record chain network.  Following the update of his record in IPFS, the patient has been notified. When a patient commits to his health record, the S k and patient-centric view will be deleted automatically. This framework ensures the privacy of patients by preventing stakeholder access to health records without the permission of the patient. Then the hash value of the data is stored securely in Hyperledger blockchain using smart chain code running on the back end of the system. Hence, the ledger will intimate the patient about the successful addition or updating of the records.

PCHDMAC-SC
In order to obtain access to the IPFS health record of the patient, the doctor requests permission from the patients. Role-based access control permissions enable the patient to grant or deny requests for authorized users as shown in Table 4. After the approval of the patient, the doctor can create, write, and read patient records. After the write operation the patient wants to commit his record to permanent storage. In this health chain framework, other stakeholders such as researchers, pharmacists, and insurance agents can only access the patient-centric view of the health records for a specific session if their object ID matches the ownership ID and also the patient. After the approval of the patient and the doctor, the laboratory technician can update the health record. Certificate authority provides the privacy agreement, access control, and policies as a smart contract, and it is managed by the Hyperledger fabric blockchain. This approach has follows certain conditions such as 1. An access control policy defines the unique identity of the stakeholder who is allowed access. 2. The system assigns the authorized value to stakeholders, action types, resources, and environment attributes after the patient has granted access.
This system divides privacy into three levels: Level 1: Health record is visible only to the patient. Level 2: Health record is available to authorized stakeholders. Level 3: During an emergency, the health record is accessible to an authorized patient caretaker.
A patient can control the privacy of his or her personal data by setting their own privacy level. In our model, the levels are configured to modify conditions during the transfer of authorizations to another authorized user prior to submission to the health record chain network.

PCHDM Algorithm
The four stakeholders in our framework are Pa, D, Ph, and LT, where P is the patient, D is the Doctor, Ph Pharmacist, and LT is the lab technician. Notations used in algorithms are shown in Table 5. The n is the number of patients, doctor, pharmacist, health record, and lab technician where n = 1,2 . . . N. Hyperledger-CA issues public key certificates to n stakeholders including patients, doctors, lab technicians, and pharmacists. A key pair will be generated for all the stakeholders. The public and private key of patient and doctor are Papk n, Paprk n , Dpk n , Dprk n . As shown in Algorithm 1, the patient Pa n grants access to their health record HR n to the doctor, D n , based on PCHDMAC-SC. Hence the system generates a patient centric view Pa cvn of the health record HR n . Based on the Doctor D n request, the attribute-based data is retrieved from the Pa cvn instead of sharing whole patient health records. A patient-centric view Pa cvn of a specific health record allows users to see and modify only the data they need. In other words, the patient-centric view is a subset of the health record. In addition to this, the system generates a session key S k shared by both doctor and patient within a particular session. An encrypted session key such as Encrypted (Papk n (S k )), Encrypted (Dpk n (S k )) is generated for the patient and doctor using their public key. The session key S k is also encrypted with Pa cvn which can be sent to doctors. To update the health record HR n , Algorithm 1 calls the Create_Update () function of Algorithm 2. The updates are uploaded into the update patient-centric view UPa cvn after decryption of doctor session key and patient-centric view session key. As soon as the patient system updates, the encrypted health record HR n is decrypted by using the patient private key retrieved by decrypting the encrypted private key using the password of the patient and adds the Encrypted UPa cvn. Lastly, the patient commits the updates to the health record HR n and stores in IPFS. The session key and Pa cvn will becomes expired once the patient commits the health record HR n. The IPFS generates health record hash value HR n _hash which is stored in blocks of Hyperledger blockchain.

Creating and updating health record in Hyperledger blockchain
Input: A Doctor D n with their Dpk n and Dprk n with session key S k of Health Record HR n , A Patient Pa n with their Papk n and Paprk n with session key S k of Health Record HR n Output: Boolean (Success or Failure)

1.
Procedure of storing and updating health records 2.
For each user u having access permission to Health Record 3.
Create patient centric view Pa cvn of HR n in IPFS 6.
Create S k 8.
send Encrypted (Papk n (S k ), Dpk n (S k ), Pa cvn (S k )) to Pa n , D n and Pa cvn 9.
Return For each Doctor having Dpk n with session key S k 3. D n ← Decrypt (Dpk n (S k )) 4. D n ← Decrypt (Pa cvn (S k )) 5.
End For 8.
End procedure

Implementation of PCHDM Protocol
The proposed framework has two parts in terms of the development environment. This framework is built with network entities and smart contracts, IPFS storage is used, and smart contracts govern every transaction. This system consists of separate back-end and front-end development environments. Implementations and experiments were carried out on a Core i7-8765u processor and 8 GB of memory. We used a Linux Foundation project, Hyperledger Fabric 1.4v, for our research. The Fabric SDK requires Java and Node as prerequisites for client development. REST APIs made it possible to visualize back-end business logic, such as user requests, assets, searches, and transaction APIs. Front-end development was carried out using HTML5, CSS3 and JavaScript. To make our web application more efficient and user-friendly, we incorporate third-party frameworks such as jQuery and Bootstrap. Front-end programming is performed with a database, and backend programming is performed with REST API servers. Clients use web applications to perform actions that trigger HTTP methods such as POST, GET, PUT, and DELETE. These methods cause the web service to respond with HTTP responses according to the requests made by the client. Table 6 shows the machine configurations and main components used for the simulation environment. Node.js, Java The protocol has been implemented in four steps.

Add Users
A step-by-step implementation of adding users to the network is shown in Figure 7. After the registration of stakeholders, the Fabric Certificate authority generates the rolebased unique ID for the registered stakeholders.
Electronics 2021, 10, x FOR PEER REVIEW 12 of 24 jQuery and Bootstrap. Front-end programming is performed with a database, and backend programming is performed with REST API servers. Clients use web applications to perform actions that trigger HTTP methods such as POST, GET, PUT, and DELETE. These methods cause the web service to respond with HTTP responses according to the requests made by the client. Table 6 shows the machine configurations and main components used for the simulation environment. Node.js,Java The protocol has been implemented in four steps.

Add Users
A step-by-step implementation of adding users to the network is shown in Figure 7. After the registration of stakeholders, the Fabric Certificate authority generates the rolebased unique ID for the registered stakeholders.

Add Records and Update Records
Health records can be created by the doctor after the patient grants permission and stored in IPFS with encryption. The hash value is preserved via Hyperledger blockchain. The patient wants to grant access to the doctor's records in order to revise them. A temporary view called the patient-centric view of the health record is generated. The doctor may update the patient-centric view of the health record and, after the patient agrees, update the existing record permanently in both the IPFS and the Health record chain. The session key will expire after that, which means that doctors will no longer have access to patient records that contain confidential information. The step-by-step implementation of adding health records and updating records in the network is shown in Figure 8.

Add Records and Update Records
Health records can be created by the doctor after the patient grants permission and stored in IPFS with encryption. The hash value is preserved via Hyperledger blockchain. The patient wants to grant access to the doctor's records in order to revise them. A temporary view called the patient-centric view of the health record is generated. The doctor may update the patient-centric view of the health record and, after the patient agrees, update the existing record permanently in both the IPFS and the Health record chain. The session key will expire after that, which means that doctors will no longer have access to patient records that contain confidential information. The step-by-step implementation of adding health records and updating records in the network is shown in Figure 8.

Assuring Authorized Users Have Access
Access permissions on the medical record are granted by the patient to stakeholders within a restricted setting, allowing them to read, write, and deny access as needed. The patient has complete control and ownership to grant read, write, and deny access permissions to stakeholders on the medical record, thereby maintaining restrictive access control. In addition, patients can authorize access to health records according to the role type and permission type of authenticated users approved by consensus. The patient can also deny specific doctors access to their medical records, and in that case, the records cannot be released to other doctors. When users interact with the system, smart contracts will identify requests, validate requests, update records, and grant access permissions. The step-by-step implementation of role-based access control and permission is shown in Figure 9.

Assuring Authorized Users Have Access
Access permissions on the medical record are granted by the patient to stakeholders within a restricted setting, allowing them to read, write, and deny access as needed. The patient has complete control and ownership to grant read, write, and deny access permissions to stakeholders on the medical record, thereby maintaining restrictive access control. In addition, patients can authorize access to health records according to the role type and permission type of authenticated users approved by consensus. The patient can also deny specific doctors access to their medical records, and in that case, the records cannot be released to other doctors. When users interact with the system, smart contracts will identify requests, validate requests, update records, and grant access permissions. The stepby-step implementation of role-based access control and permission is shown in Figure 9.

Records Retrieval
For all stakeholders to read a patient's record, the patient wants to grant access that retrieves partial attribute-based information about the patient, retrieved from IPFS using the hash value in the Health record chain network. The step-by-step implementation of the view record is shown in Figure 10.

Assuring Authorized Users Have Access
Access permissions on the medical record are granted by the patient to stakeholders within a restricted setting, allowing them to read, write, and deny access as needed. The patient has complete control and ownership to grant read, write, and deny access permissions to stakeholders on the medical record, thereby maintaining restrictive access control. In addition, patients can authorize access to health records according to the role type and permission type of authenticated users approved by consensus. The patient can also deny specific doctors access to their medical records, and in that case, the records cannot be released to other doctors. When users interact with the system, smart contracts will identify requests, validate requests, update records, and grant access permissions. The stepby-step implementation of role-based access control and permission is shown in Figure 9.

Records Retrieval
For all stakeholders to read a patient's record, the patient wants to grant access that retrieves partial attribute-based information about the patient, retrieved from IPFS using the hash value in the Health record chain network. The step-by-step implementation of the view record is shown in Figure 10.

Records Retrieval
For all stakeholders to read a patient's record, the patient wants to grant access that retrieves partial attribute-based information about the patient, retrieved from IPFS using the hash value in the Health record chain network. The step-by-step implementation of the view record is shown in Figure 10.

Framework Implementation
The Health Chain Network Transaction Framework consists of smart contracts, chain code [26], IPFS storage, and network entities. In the Health Chain network user sign up system, doctors, pharmacists, receptionists, and other health care providers can register using their respective roles. Upon registration, the fabric certificate authority is generated. The certificate authority contains encrypted privacy policies as shown in Figure 11. Using their email address and password, the user can use their user type to sign in after registration. Receptionists can accept or reject appointments booked by the stakeholder using patient IDs and update the stakeholders based on the patient's information. The patient consults the doctor after the appointment has been approved by the receptionist, and the doctor creates the patient's medical record. IPFS allows doctors to upload medical notes or diagnosis results. Electronics 2021, 10, x FOR PEER REVIEW 14 of 24 Figure 10. Record retrieval.

Framework Implementation
The Health Chain Network Transaction Framework consists of smart contracts, chain code [26], IPFS storage, and network entities. In the Health Chain network user sign up system, doctors, pharmacists, receptionists, and other health care providers can register using their respective roles. Upon registration, the fabric certificate authority is generated. The certificate authority contains encrypted privacy policies as shown in Figure 11. Using their email address and password, the user can use their user type to sign in after registration. Receptionists can accept or reject appointments booked by the stakeholder using patient IDs and update the stakeholders based on the patient's information. The patient consults the doctor after the appointment has been approved by the receptionist, and the doctor creates the patient's medical record. IPFS allows doctors to upload medical notes or diagnosis results.

Framework Implementation
The Health Chain Network Transaction Framework consists of smart contracts, chain code [26], IPFS storage, and network entities. In the Health Chain network user sign up system, doctors, pharmacists, receptionists, and other health care providers can register using their respective roles. Upon registration, the fabric certificate authority is generated. The certificate authority contains encrypted privacy policies as shown in Figure 11. Using their email address and password, the user can use their user type to sign in after registration. Receptionists can accept or reject appointments booked by the stakeholder using patient IDs and update the stakeholders based on the patient's information. The patient consults the doctor after the appointment has been approved by the receptionist, and the doctor creates the patient's medical record. IPFS allows doctors to upload medical notes or diagnosis results.  Our proposed business network consists of stakeholders, Assets and Transaction as shown in Figure 12.
The prototype has undergone a number of tests in order to validate its functionality and evaluate its performance. An assessment of the health chain framework systems is realized through the application of four case studies that illustrate efficiency, scalability, storage, and security.
2. Role-based access control. 3. Health records are read with an assigned session key. Therefore, the system is capable of allocating access rights according to their levels and roles. Example code snippets for access control transactions are shown in Figures 13  and 14.

Data Scalability
The scalability of the proposed system is tested with a few test cases, such as: 2. Role-based access control. 3. Health records are read with an assigned session key. Therefore, the system is capable of allocating access rights according to their levels and roles. Example code snippets for access control transactions are shown in Figures 13  and 14.

Data Scalability
The scalability of the proposed system is tested with a few test cases, such as:

Data Scalability
The scalability of the proposed system is tested with a few test cases, such as: 1. Storing of large and small file size health records. 2. Computation of throughput and latency using Hyperledger caliper benchmarks. We have verified that our proposed system is capable of handling large data sets and low latency through the above test cases using the Hyperledger caliper benchmarks.

The Comparative Analysis of Existing and Proposed PCHDM Model
In Table 7, we compare existing and proposed patient-centric health storage models with an emphasis on scalability, privacy, confidentiality, integrity, and security. Using blockchain technology, the author has explained recent healthcare management practices and their consequences in [27,28]. The existing frameworks considered are [8,[13][14][15][16]29]. Each block contains a hash of a health record which will change if any changes are made to the record. As a result, tampering with the ledger is computationally difficult, ensuring that the medical record cannot be altered. The access control rules and levels prevent stakeholders from accessing health records without the patient's knowledge. Table 7. Comparison of proposed and existing model.

Results and Performance Evaluation
A dataset was gathered from US health records on a website called Kaggle. The dataset consisted of images and text of variable sizes. It was used to test the existing health records. Hyperledger Caliper was used to benchmark a blockchain-based application [30]. Caliper is designed to benchmark the performance of Hyperledger using many different metrics such as throughput, latency, and success rate (average, minimum, maximum, and percentile). Furthermore, it indicates how resources such as CPU memory will be allocated to the system. The result is calculated and generated from Hyperledger caliper reports benchmarks with the following metrics: 1. Success and fail rate. 2. Transaction/read throughput. 3. Transaction/read latency (minimum, maximum, average, percentile). 4. Resource utilization (CPU, memory, network (traffic in and traffic out)). The scalability of the proposed application is extremely important. The proposed framework was therefore tested against ordering services against varying numbers of peers. Initially the performance evaluation of this network was carried out under one organization and three peer nodes. The benchmark report helped to make a comparison of peer among nodes and finally the system efficiency was determined.
This first experiment employed a Hyperledger fabric blockchain framework to calculate transaction latency. The latency of a transaction reflects how long it takes to commit. It is a distributed parameter across nodes in the network. If there are p number of nodes in the health chain network, TR Lap is the transaction latency, TR Ctp is the confirmation time in the network nodes, and TR Stp is the transaction submit time in seconds then transaction latency is given as The network ledger has been updated through the use of eight groups of transactions in organization 1 peernode1 ranging from 5, 15,25,30,35,45,50 and 55 as shown in Figure 15. In this configuration, the first five transactions across the network were committed in 104 s, and the final 55 transactions took 161 s on average. A range of 55 to 400 transactions were then added to the experimental result to determine transaction time. Figure 16 shows that when 400 transactions were committed on three peer nodes of an organization, the average time was 420 s. As a result, the transaction latency remained average when the number of transactions increased. The comparison of commit transaction latency with three stage peernodes such as 1 Organization 1 peernode, 1 Organization 2 peernode, 1 organization 3 peernode. From Figure 17, it shows a slight increase in latency with an increase in the number of peer nodes. The next set of experiments was conducted for evaluating throughput. Transaction throughput is the number of transactions which were valid and committed from the total executed transactions as TR tpp = TR vcp /TR totalp (3) tion of eight sets of transactions. In this, the first five transactions have taken 79 s to commit into the network. Hence the valid transaction in system under test is three in the network. Likewise, the last transaction 55 takes 110 s to commit in the network with 28 valid transaction per minute. This same experiment is repeated for 1 organization 1 peernode, 1 organization 2 peernodes, 1 organization 3 peernodes. From the Figure 19 the successful transaction of all nodes in which 1 organization 1 peernode throughput is slightly higher than organization 2 peernodes and 1 organization 3 peernodes. When assets are successfully loaded and written to a database, the asset latency is measured. In a blockchain network with P nodes, AS_Lp represents the Asset Latency. The response time TR_Resp is measured in milliseconds and the asset submit time TR_AS_Subp is measured in milliseconds.

AS_Lp = TR_Resp − TR_AS_Subp
(4) Figure 20 shows the asset time to commit in the blockchain form sample set of transactions. As a result, this system can process a large dataset with low latency. In order to examine asset latency variability, the experiment was extended to include user numbers between 20 and 120, and data sizes between 200 k bytes and 20,574 k bytes. According to Figure 21, the average latency for updating assets in the ledger was 2.9 s. Considering configuration of the system, even with a 20-user increase to 120 users, the efficiency would still be higher and asset size would increase in the system, but the process of updating assets across the network would take slightly more time. As a result, this method can process data sets of large sizes with low latency. Further analysis such as upload of 140 mb of data and downloading of data in IPFS by the five concurrent users that take 60 sec to commit this upload and download operation. The average upload and download time of the medical image data in IPFS for the sample 100 MB is 34 and 43 s, as depicted in Figure 22. Then the average upload and download time of the sample 100 mb health record document file is 39.3 and 53.5 s, respectively, as depicted in Figure 23. From Figures 22 and 23, the average upload and download latency is maintained for all the transaction sets without any interruption. This shows the scalability of the system has improved using this proposed framework. Table 8 shows the Hyperledger caliper report of resource utilization. Throughout the experiments, resource utilization remained steady. Hence it will not affect the system under test.      Figure 18 shows transaction throughput of the proposed system using experimentation of eight sets of transactions. In this, the first five transactions have taken 79 s to commit into the network. Hence the valid transaction in system under test is three in the network. Likewise, the last transaction 55 takes 110 s to commit in the network with 28 valid transaction per minute. This same experiment is repeated for 1 organization 1 peernode, 1 organization 2 peernodes, 1 organization 3 peernodes. From the Figure 19 the successful transaction of all nodes in which 1 organization 1 peernode throughput is slightly higher than organization 2 peernodes and 1 organization 3 peernodes.   When assets are successfully loaded and written to a database, the asset latency is measured. In a blockchain network with P nodes, AS_Lp represents the Asset Latency. The response time TR_Resp is measured in milliseconds and the asset submit time TR_AS_Subp is measured in milliseconds.  Figure 19. Throughput comparative analysis with 1 organization 3 peernodes. Figure 19. Throughput comparative analysis with 1 organization 3 peernodes. Figure 20 shows the asset time to commit in the blockchain form sample set of transactions. As a result, this system can process a large dataset with low latency. In order to examine asset latency variability, the experiment was extended to include user numbers between 20 and 120, and data sizes between 200 k bytes and 20,574 k bytes. According to Figure 21, the average latency for updating assets in the ledger was 2.9 s.   Considering configuration of the system, even with a 20-user increase to 120 users, the efficiency would still be higher and asset size would increase in the system, but the process of updating assets across the network would take slightly more time. As a result, this method can process data sets of large sizes with low latency. Further analysis such as upload of 140 mb of data and downloading of data in IPFS by the five concurrent users that take 60 sec to commit this upload and download operation. The average upload and download time of the medical image data in IPFS for the sample 100 MB is 34 and 43 s, as depicted in Figure 22. Then the average upload and download time of the sample 100 mb health record document file is 39.3 and 53.5 s, respectively, as depicted in Figure 23. From Figures 22 and 23, the average upload and download latency is maintained for all the transaction sets without any interruption. This shows the scalability of the system has improved using this proposed framework. Table 8 shows the Hyperledger caliper report of resource utilization. Throughout the experiments, resource utilization remained steady. Hence it will not affect the system under test.

Conclusions
In this paper, we describe the design, implementation, and evaluation of PCHDM, an end-to-end secure Health record chain network architecture based on PCHDMAC-Smart Contracts. By leveraging Health record chain networks, IPFS, and Smart contract, this framework ensures the safety of health records between stakeholders. In addition, it

Conclusions
In this paper, we describe the design, implementation, and evaluation of PCHDM, an end-to-end secure Health record chain network architecture based on PCHDMAC-Smart Contracts. By leveraging Health record chain networks, IPFS, and Smart contract, this framework ensures the safety of health records between stakeholders. In addition, it features an innovative access control scheme that adheres to compliance with privacy laws and patients' privacy levels. 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.
There are some limitations to this research that need to be addressed in future research. Multi-blockchain systems require a tremendous number of resources to be implemented. In the future, we will extend the framework integrated with Non-Fungible Tokens (NFT) to share audio and video as NFT data with the stakeholders. NFTs will allow patients to choose whose data they want to share and sell, as well as track how and by whom that data is being used. Patient data transactions and monitoring can be supported by trusted NFT management services.