A lightweight blockchain-based framework for medical cyber-physical system

A medical cyber-physical system (MCPS) combines intelligent medical devices with a network. Nowadays, MCPS is extensively used in the healthcare system. While sharing patient data into MCPS, data security and privacy are significant challenges in healthcare as most of the devices suffer from data leaking, data manipulation, data forgery, denial of service attacks, etc. In this work, a reputation-based blockchain framework has been proposed to ensure patient data security while preserving privacy. A detailed security analysis discusses the possible attacks and the countermeasures of the attacks. The result and performance analysis of the proposed framework show low latency in data sharing and high throughput with an increasing number of users in the network. The calculated results established that the average latency time is reduced to (46–50%) while throughput is increased by (44–50%) as the number of users increases.


Introduction
The intelligent healthcare system is integrated with healthcare 4.0, which was introduced by industry 4.0. Industry 4.0 comprises key technologies like data mining, artificial intelligence, machine learning, blockchain technology, cloud computing, fog computing, cyber-physical system, etc. [1]. With the advancement of intelligent healthcare medical technology, wireless medical sensor, cloud computing, and 1 3 cyber-physical systems are added to healthcare applications for services like remote patient care, remote diagnosis, and medical emergency services. A medical cyberphysical system(MCPS) is the integration of a network of medical devices and a cyber-physical system. In MCPS, medical sensors, implantable body devices, and wearable devices are responsible for sensing the patient's body parameters and sharing those data with the medical organization for patient treatment efficiently [2]. The medical data which are collected by the medical sensors shared via network connection like Bluetooth, ZigBee, or Wi-Fi face security risks of data leakage, data theft, data manipulation, and also vulnerable to many security attacks like man-inthe-middle attacks, data falsification, and SQL injection [3]. Also, MCPS generates a large amount of medical data in a short time which is stored on a cloud server so that medical practitioners can easily monitor the health data [4][5][6].
Medical data involve a huge amount of data related to diagnosis, treatment, insurance, personal information, etc. It also includes CT scan images, X-ray images, MRI scans, etc. There are huge chances of data tampering if the data are stored in cloudbased system or any central storage where different entities are accessing these data for different purposes. Some solutions to this problem [7,8], fog computing [9,10], mobile edge computing [11,12], are discussed. Storing and managing the large volume of data collected through medical sensors [13] are another challenge. Some solutions are proposed for the security issues like the cryptographic algorithm [14], Kalman filter, and chaotic cryptosystem [15]. Some solutions are proposed for data storage and management [16,17]. In such cases, cryptographic techniques, such as encryption can maintain confidentiality, but the chances of data leaking are always there.
Moreover, health records together with other information can help to identify or locate a person (e.g., PIN, aadhar no., credit card no., etc.) for some specific purpose. Hence, an individual's privacy may be jeopardized since once this information is available [18]. In such cases, there is no longer control over how and by whom data are utilized which means the privacy of a user is not preserved [19].
Blockchain-based solutions are suitable in such scenario. The permissioned blockchain which is available only to authorized users rather than the general public to manage authentication and data exchange with other characteristics can be used in the medical sector [20]. Blockchain network uses IPFS which mainly stores files in an encrypted format and stores the hash on the ledger. The medical data which are stored on the cloud using these techniques can be accessed through the internet [21]. While accessing these data from the cloud, there increases the overhead in terms of latency and network bandwidth and also found some difficulties in scalability, throughput, the volume of the data, and the privacy of the medical data [22].

Motivation
In Cancer care, data sharing is essential where boards are formed by a group of doctors from different specializations to detect and classify the tumors. These boards meet on a regular basis to examine cancer cases, share expertise, and work together for appropriate treatment. In such a collaborative environment, trust relations between entities must be formed. Also, sometimes not only the medical people, the pharmaceutical agencies and R & D agencies become a part of such an environment. This may raise the danger of clinical data breaches like data leakage, tampering, and data falsification which can result in serious financial and legal implications. On the other hand, the direct storage of sensitive health data, such as data aggregated from body sensors, is prone to advanced attacks like ransomware attacks and DoS attacks. This motivates to develop of a framework that can integrate privacy and confidentiality of healthcare data in an intelligent healthcare system.

Research problem and contribution
While working in the collaborative model, data security and privacy are vital concerns as medical data are too confidential from ethical and legal perspectives. Most of cryptographic solutions mainly focus on the confidentiality of medical data but overlook data leaking (privacy concern) and data traceability problems. The privacy problem arises if the health data storage leak data about a particular user due to the user's multiple queries. For instance, a patient shares medical data with the caregivers. Somehow, attackers may be able to gain knowledge about the patient's name, location, and disease which hampers identity privacy. The above-mentioned problem can be solved by using blockchain that can handle data tampering, data traceability, and data privacy with low delay and low processing time. Hence, this paper identified two significant objectives in the MCPS. The first objective is to eliminate data tampering which results in data forgery and also maintain data traceability. The second objective is to preserve data privacy to prevent information leaking in the healthcare system. To fulfill these two objectives, we have designed a blockchain-based framework that will build a trusted network for sharing information using insecure channels.
The key contributions of this research work are as follows: • A lightweight blockchain-based framework for electronic healthcare system (LB-EHS) has been proposed, which integrates blockchain with MCPS that enhances the security and reduces the latency. • The proposed framework ensures privacy where the cluster head will authenticate and pass every request of data retrieval to the access control module. The trust of the cluster head depends upon the reputation based scheme. • The proposed framework is experimented, and results are analyzed in terms of performance metrics like throughput, transaction time, and latency. The calculated results established that the average latency time is reduced while throughput is increased as the number of users increases.
The rest of the paper is organized as follows: Sect. 2 presents background studies including some of the related works; Sect. 3 describes the proposed framework; Sect. 4 presents the experimental setup and results; Sect. 5 presents the Performance and analysis of the proposed scheme; finally, it is concluded in Sect. 6.

Background
With the advancement in technology, the healthcare sector is also developed with new technology like cloud computing, machine learning, MCPS, blockchain, etc. The distributed systems simultaneously monitor and control various parts of the patient's physiology in place of standalone devices that can be created, approved, and utilized independently of one another to treat patients. Modern medical device systems are a unique class of cyber-physical systems due to the device's embedded software, networking capabilities, and complex physical dynamics displayed by patient bodies (CPS). These are referred as MCPS.

Medical cyber-physical system
Medical cyber-physical system consists of the medical device with the network system that will connect the medical devices and the cyber-things, an intelligent control system that will take action based on the signal generated through actuator [2]. The monitoring equipment in MCPS can transmit the data, it accumulates to decision support entities, each of which serves a different but complementary objective [23]. Decision support entities can process the collected data and use a smart controller to assess the information gathered from the monitoring devices, determine the patient's state of health, and automatically begin therapy (such as a medicine infusion) by sending commands to delivery devices [24]. The basic architecture of the MCPS is shown in Fig. 1.
• Data acquisition layer: This layer senses the data of the human body with the help of wearable smart devices and body implantable devices and sends it to the mobile or any connected device for further processing of data. • Pre-processing layer: After sensing the data from the smart device, data are sent to any smartphone or system so that it can be shared to medical organizations and caregivers. • Cloud layer: This layer stores all the medical data from the blockchain, processes the data, and transfers the data to caregivers for taking action. • Action layer: Based on the medical data received, the action will be taken by the caregivers or automatically by the smart devices.

Related works
The present healthcare system has problems with security, privacy, inconsistent data, and easy access to health records.
Huang et al. [38] presented an e-Health system built on Blockchain that would enable consumers to audit health data and spot data manipulation. They have used attribute-based proxy re-encryption to provide precise access control of medical data.
A blockchain-based health system that employs smart contracts to handle data storage and access management was created by Zhuang et al. [39]. This approach uses patient-centric HIE by personalizing data segmentation and creating an authorized list" for doctors to access their data.
"PrivySharing" was the solution provided by Makhdoom et al. [40] for protecting the privacy of health data segments and various channels. Additionally, a system of rewards was created for disclosing user data to stakeholders and other parties.
In [15], the authors described an EHR encryption system, "Healthcahin" built on the blockchain that makes use of intricate logic expressions to enable users to search the data using a specific set of indexes kept on the Blockchain. This procedure guarantees the integrity, anti-tampering, and traceability of the index ( Table 1).
The highlights of the study are to identify the research challenges that exist in the area which is described below. • Present healthcare system suffers problems for a large number of users when accessing health data. While increasing the number of users, data storing and data accessing time are increasing, and throughput is decreasing. Also, block  Ismail et al. [32] To propose a more efficient blockchain architecture than the Bitcoin network for managing healthcare data that has lower computational and transmission costs Access control Yes Scalability and energy issue is not discussed. The performance of the proposed architecture can be improved Ayesha et al. [33] To propose a framework that aims to safeguard the preservation of electronic records by creating granular access controls for users in addition to first using blockchain technology for EHR.

Access Control
Yes Throughput is decreasing when users are increasing Tanwar et al. [34] An access control policy using symmetric key cryptography should be provided to a separate healthcare practitioner using a patient-centered method.
Access control

Yes
In the suggested method, the design and integration of smart contracts are not formally defined Nagori et al. [35] To propose an electronic health record storage system for medical institutions that has a multichain connection for security, decentralization, and transparent visibility Access control

Yes
There is no data validation mechanism in implementation and simulation Yang et al. [36] To propose a novel multi-user electronic health record sharing protocol that uses public key encryption and keyword search that is verified

Confidentiality and integrity No
Computational cost is high Lai et al. [37] In order to share medical data effectively and securely, a blockchain-based and traceable ring signature-based system has been developed Authentication

No
Higher transaction rate for larger blocks creation and validation take a lot of time which degrades the system performance. • Spam transactions and blockchain forks are considered to be crucial issues for the blockchain system. However, the mechanism for detecting spam transactions and blockchain forks is less secure. • Moreover, during data accessing, personal information (PIN, aadhar card no., credit card no., etc.) may help to identify or locate a person, so it hampers personal identity privacy.

Proposed model
Based on the research problem discussed above, a lightweight blockchain-based framework (LB-EHS) is designed for the electronic healthcare system. The proposed system architecture contains three components which are shown in Fig. 2.
The first component is built with MCPS. The MCPS contains a medical sensor, an IoT gateway, a decision support system, and an actuator. The second component is the blockchain module which consists of smart contracts, and IPFS implementation with the blockchain entities. The third component is the privacy preservation mechanism which describes how privacy will be maintained during the data access. In this framework, the medical data collected by the MCPS are uploaded to the cloud through a permissioned blockchain. The selection of the permissioned blockchain over the permission-less blockchain is on the basis of the following issues.
1. Open Network: Permissionless blockchain is used in an open network where anyone can join the network which causes vulnerability of the network. 2. Weak information privacy: As permission-less blockchain is transparent to every entity, each piece of information has to be shared with every entity. So there is less privacy related to the shared information. 3. Slow network: Permission-less blockchain is slow as there are more nodes to manage the transaction. However, a faster network is a vital component of healthcare.
The detailed proposed architecture is discussed in the subsequent subsections.

MCPS-based intelligent module of LB-EHS
The description of each entity in MCPS is shown in Fig. 4. All entities used in Fig. 4 are explained below: • Patient: The medical data will be collected from the patient's body with the help of medical sensors like pressure sensors and oxygen sensors. • Medical sensor: Medical sensors or monitoring devices like BP monitoring, body temperature sensors, airflow sensor, thermistor, etc. are deployed in the patient body. • IoT gateway: IoT gateway is responsible for data collection from the medical sensor. It receives and transfers the sensed data, pre-process the data. It filters and cleans the unfiltered data to the decision support system and to the cloud also. • Decision support system: DSS will be responsible for analyzing the captured data. Based on the analysis, it will generate an alarm for medical emergencies and send instructions to the actuator. • Transporting device or actuator: The actuator is responsible for accomplishing the instruction given by the decision support system on the smart medical device.

Act(C)
This intelligent module is mainly working for patient data gathering and analysis purposes which will result in quick decision-making. These data contain medical images (MRI scan, CT scan) and vital body parameters (oxygen level, BP level, blood sugar level, etc.) which will generate the patient's electronic healthcare report (EHR). This EHR will be used for quick data analysis so that the treatment is performed and also stored in the cloud for data accessors (doctors, patients, and hospitals). Now, in this proposed intelligent system, the medical image file will be stored in InterPlanetary File System (IPFS) in an encrypted format. The public key encryption technique (e.g., RSA) uses for encryption of his/her report to prevent others from misusing the data. After uploading the data to IPFS, the IPFS hash will store in the ledger. This process is shown in Fig. 3, where the blockchain network first registers the user (patient and doctor) and the intelligent MCPS and generates their public key. These public key pairs are shared among the users using D-app. When a user wants to access an EHR, he/she will get the public key pair after authentication in the blockchain network. Then, for login, the cluster head will verify the details provided by the user and MCPS. MCPS sends the updated data to D-apps and uploads it to IPFS. IPFS will return the hash to the blockchain network. The hash will be verified and uploaded to the IPFS.
The description of each transition is discussed below:

Blockchain module of LB-EHS
The permissioned blockchain module ensures the tamper-proof, secure, and traceable transaction in the network. In the permissioned blockchain, data will be shared after the authentication process. In the permissioned blockchain, there are two entities: cluster head and data accessor. The functional model depends upon two operational blocks: the EHR generation and storing block and the EHR accessing block. Figure 4 shows the workflow of LB-EHS.

EHR generation and storing block
In this operational block, EHR is generated through the collection of the patient's data, and also storing those data in the blockchain for storing the data, the selection of cluster head will be taken place.
The security problem rises in the framework if all nodes transfer transactions without verification which can cause a storage shortage as well as high consumption of network bandwidth. This can lead to more spam transactions as a result of a denial of service attack. Thus, a cluster head node should be selected for the verification of all transactions. Also if the cluster head starts to verify and complete all transactions before generating the block, it will slow down the block creation process. Therefore, a mechanism is required to ensure the validity of each transaction as well as the node. The idea of the reputation-based mechanism is developed to reduce spam transactions. It also increases blockchain efficiency and trustworthiness. The description of the cluster head is discussed below: (a) Cluster head selection The cluster head is the supervisor of this permissioned blockchain. It is responsible for the execution of all the transactions. There will be two types of ledger: one is for successful transactions and another is for unsuccessful transactions. Here, a successful transaction means an authentic transaction between the authentic entities. There is a reward for each successful transaction and a penalty for the unsuccessful transaction. The selection of the cluster head is based on the reputationbased mechanism which is discussed in the next subsection. In this way, the authenticity and utility of the permissioned blockchain remain reliable. The difference between cluster head and smart contract is cluster head is responsible for inner transactions like adding any entity, adding transactions, etc., in the blockchain network while to be a part of this blockchain network, every entity(patient, doctors and hospitals) must execute the smart contracts.
The role of the cluster head is: • Adding or removing the entity from the blockchain. • Adding, verifying, or removing the transaction. • Authentic the participated user or unauthorized user. • Update the database locally as well.
(b) Block creation and block validation The steps for block creation and block validation in the proposed framework are explained below: • Step 1: Create the block header by generating hash of the hash of previous block, and gas limit, gas used, timestamp, and the transaction list. • Step 2: Add all the data into block along with calculated header, and calculate the hash for all data again. • Step 3: Compare with the set hash value; if the calculated hash and set hash are equal, then, the block is created otherwise calculate the hash again. • Step 4: Then, data will be added to the blockchain by the cluster head.
The algorithm for the creation of blocks in the proposed framework is explained below: The Algorithm 3 for the validation of blocks in the proposed framework is explained below: The steps for the validation of blocks in the proposed framework are explained below: • Step1: Calculate the hash of the previous block by calculatehash(). • Step2: Compare the previous hash value of the block to parent's hash value, gas limit of the current block to the gas limit of the parent's block. • Step 3: Verify the amount of total gas used in the current block is less than the block's gas limit. • Step 3:Verify the timestamp (T) of a current block is more than the parent's block and not more than 15 milliseconds. • Step 4: Validate the block and add the block to the blockchain. 15 milliseconds is the upper limit of the time for adding all the pending transactions, verifying the transactions, and mining the next block. So that this framework will give a response within 15 milliseconds which is very crucial in the healthcare sector.
Functions associated with the proposed framework are discussed below:

3
A lightweight blockchain-based framework for medical… The steps for registration of hospitals, doctors, and patients are discussed below: • Step 1: Entities like hospitals, doctors, and patients, request for the registration. • Step 2: The cluster head will ask for the data to be added to the blockchain. • Step 3: The cluster head will verify the data and register them with the blockchain network using verify(). • Step 4: The cluster head will provide the registration id and password to entities using Provide(registration_id, pw) function.

Data accessing block
In this block, EHR is accessed by the data accessor(patient, doctors and hospitals). The data accessor will send the request for data access.
The cluster head will authenticate the data accessor on the basis of id and password. After that, the requester has to go through the access control module. If the requester passes the access control module, access to the data will be provided to the data accessor. The description of this block is discussed below in detail: • accessData(): The block A5 of Fig. 6 shows the code of for accessing data. Before providing data to the data accessor, the cluster head will verify and allow the data accessor to retrieve the data. • getPatientDetails(): This function will provide the data to the data accessor.
The function will ask for the hospital's details, patient id, age, pincode, etc. The parameter is checked, and if passed, then, data are provided to the data accessor. The code is shown in block A6 of Fig. 6. • updatePatientDetails(): This function will update the patient details with the updated data to the blockchain network.

Privacy module of the LB-EHS
To solve the privacy issue in the healthcare system, a privacy preservation mechanism has been developed. Privacy breaches are possible during data transactions. Hence, transactions are categorized into three types, such as valid complete transaction (V 1 ) , valid incomplete transaction (V 2 ) , and invalid transaction(V 3 ) . Nodes are of three types, such as honest nodes, semi-honest nodes, and dishonest nodes. This honest node first verifies all complete transaction and sends a reminder to all incomplete valid transactions. After all verification, it forwards transaction cluster heads. The semi-honest node does not verify all transactions but forwards all transactions to the cluster head which are only valid complete transactions. But never generate an alert to incomplete transactions or details of such transactions to the cluster head. However, the dishonest nodes never check any transactions. They only forward all types of transactions. The proposed reputation-based system is to maintain node privacy. Each node i will maintain a reputation R i for every successful valid transaction. At the same time, the cluster head will make a reputation table of all the nodes ( Rep c ), where all node's scores on the basis of penalty(P) and rewards(R) are calculated. After the score calculation, the cluster head will send the updated score table to all nodes so that they will update their own table. Once the reputation R ij of any node reaches the highest value, that node becomes the next cluster head. The reputation R ij is calculated by the equation: Normally, in a healthcare scenario, the value of = 1 , = 0.5 , and = −1 for each transaction. In this way, the final reputation score will be determined, and the highest scorer will be selected as cluster head. The cluster head will maintain the privacy of (PHI) by using a rule set. This rule set is actually for privacy preservation. The query set is resolved by the rule set manager. This will work with the Result Set Overlap Restriction of our previous work [41]. This restriction algorithm utilizes the notion of the query set size restriction. All the statistical queries, such as count, sum, etc., under this method, will be cross-checked with all prior query results. For example, let N be the total no. of records in the current result set, and the subsequent query results set will not send to the user. The rule set manager sets a time window for all saved query results.
The rule used for the above problem is: This rule says if the user after authentication passes a query to read the total number of patients suffering from a disease (e.g., Tuberculosis) in a particular location (pin code). This will allow viewing the anonymous data only if the query result is not equal to 1. Similarly, other rules have been developed under the privacy preservation policy.

Experimental setup and results
The experimental setup and the result are discussed in this section. The experiment is performed on Google Cloud Platform which uses E2 machines for virtual machines. These machines have 128 GB of RAM and a maximum of 8 GB per vCPU. It supports 32 vCPUs in total. E2 computers have a 64-bit Linux operating system with a dual-core Intel i7-2500 CPU running at 2.8 GHz with 8GB of RAM.
A. Implementation of smart contracts A D-app prototype is developed for the implementation of LB-EHS. While implementation of the smart contracts we have set up an experimental environment which is shown in Fig. 7. In Fig. 7, how the D-app is working for the proposed framework is shown step-wise. There are twelve components of this setup whose working is discussed below: -Step 1: The front end is developed by the react.js, google chrome browser, and Meta-mask. Meta-Mask and react.js use the IPFS for data sharing and to keep record of transactions, respectively. Etherscan keep the information about all the transactions such as, timestamp, and hash. -Step 2: Smart contracts are deployed on Remix IDE, which will run on google chrome browser. -Step 3: Back end is developed by node.js, Truffle, Ganache, Meta-mask, and smart contracts.
-Step 4: Now, the patient's data are collected through the sensor which is attached to Arduino UNO. Arduino UNO is connected to system through the USB.
For software communication between Arduino UNO and PCs, the Firmata protocol is employed. Google chrome on the gateway device is used to connect the device to the blockchain. In this application, the johnny-five library analyzes the pin output received through the Firmata connection from the Arduino board. The socket.io and dweet.io tools establish a socket connection with Firmata and then transfer the received data in real time. The React.js library connects to the private Ethereum blockchain where the smart contract resides and talks with it via the JSON-RPC protocol.

B. Result of blockchain network
The blockchain network is evaluated with the computation time and gas consumption for the functions as shown in Table 2. The functions are used addPatient(), addclusterHead(), addHospital(), adddoctors(), etc. The gas cost is calculated by the cluster head, who executed the consensus. The gas price, or the amount of ether, a user is prepared to spend per unit of gas, is used by the cluster head to choose which transactions to include in the next block. addpatient() function has a gas allowance of 21,000 units and a starting price of 99.15 gwei. So the gas cost will be = 21000 × 99.15 =2082158. Figure 8 shows the details about the addpatient().
The gas limit is dependent on the user's acceptance of paying for a transaction, with a minimum limit of 21000. The gas cost is decided by the user's capacity to pay for each unit of Gas and is represented as 'Gwei.' The consensus PBFT will take approx fifteen milliseconds to execute in the proposed scheme. Another result shows the transaction time which is low as compared with the previous scheme [37]. The transaction time is linearly increased with the number of users and is lowest from the existing scheme [37]. We have used the number of users from 200 to 2000 for measuring the throughput, and the result shows that the throughput increases as the number of users increases.

Performance analysis
After the experimental setup, the performance of the proposed scheme LB-EHS is discussed in this section. The security analysis and comparison are also done to show the security strength of the framework.

Security analysis
This section describes how the framework protects patient data from available threats. Detail description is given below: Theorem 1 Denial of service attacks using spam transactions can cause a serious threat to the framework.
Proof Transaction spamming represents one of the recurrent security vulnerabilities that may devastate these high-performance blockchains over lengthy periods of time. These transactions can add unwanted additional stress to the network as a result of not following Bitcoin best practices, either purposefully or inadvertently. In the proposed framework for MCPS, the Ethereum network is deployed where each node has earned a reward point after every successful transaction, and transaction failure adds a penalty point that calculates a reputation value. As a result, we define several sorts of transactions (valid/invalid) and network nodes (honest, semi-honest, and malicious nodes). Based on the node's activities, a reputation system is presented, which primarily provides the two benefits listed below. A node can determine the likelihood of verifying a transaction based on the sender's reputation value. Furthermore, nodes can use the method to identify spam transaction producers. The reward-penalty scheme is used for cluster head selection and to reduce spam transactions. ◻

Theorem 2 If forgery is performed by a dishonest node, the framework is able to detect it.
Proof Blockchain is a database that stores data, transaction records, and assets in a corporate network. To put it another way, it's a large digital notepad. It is prevented in the framework by using smart contracts. Because it enhances the visibility and openness of transactions done across a supply chain and between members of a business network, using a shared digital ledger can help decrease fraud. Any forged data can be identified by hash value. Participants can monitor the history and transfer of assets; fraudulent transactions are more easily identified. Furthermore, in order to tamper with the transaction records on a blockchain, a person or group of individuals working together would need to control a majority of the system. ◻

Theorem 3
The reentrancy attack can be resisted by this framework using the vulnerability function of a smart contract.
Proof An attacker makes a significant amount of wealth in a reentrancy attack by iteratively attacking a smart contract's vulnerability function. This is a programming approach that occurs when an external function call terminates a function's execution. Conditions inside the external function call's logic allow it to call itself before the first function execution may finish recursively. Reentering a process on several occasions to execute external logic may be advantageous in some cases and is not necessarily a problem. The suggested system uses a solidity smart contract to control the attack in four ways. To fight it, it employs Check, Effects, Interactions (CEI), mutex, and gas limitations. ◻

Theorem 4 Information leaking and transaction tracking can be resisted by this framework
Proof Information leaking and tracking information can be possible by implanting Trojans in the system. Once a malicious application is installed in the exchange system, it is very possible that a considerable quantity of sensitive information, including key and wallet data, will be leaked. The key is everything, and losing control of all assets is typically the result of leaking critical information. In the proposed framework, one key manager is installed to generate keys for encryption purposes and also to manage the keys to build a high level of key security. In Phi, all sensitive data are protected with an encryption mechanism, and images are stored in an encrypted format in the IPFS. It is difficult to alter a smart contract once it has been implemented in a distributed, decentralized network. Also, based on the encryption technique, it prevents data modification and forms a trust mechanism. ◻ Theorem 5 Selfish mining attack using a dishonest node can cause a serious threat in the framework.
Proof A hostile mining pool decides not to release the block it discovers, resulting in a fork. The malicious mining pool issues the secret fork when it is longer than the public chain. Because the fork is the longest chain in the current network, honest miners will identify it as a lawful chain, and the original public chain and its honest data will be destroyed. However, such assaults often need massive hash power as a backup. In the proposed framework, this type of attack is tried to resist by reputation-based cluster head selection that will be responsible for the mining process. The node will gain mining permission when it achieves a certain level of reputation so that it will become an honest node. Hence, selfish mining strategy can be prevented. ◻

Comparison with the existing scheme
In the proposed scheme, PBFT is used as a consensus algorithm in our proposed architecture. The result is analyzed with the proposed blockchain framework in terms of latency in adding a record, fetching a record, and how large amount of gas is consumed in executing a function. In the proposed framework, the throughput and latency are simulated by using METER. And blockchain network is simulated by NS3 for the evaluation of the volume of data sent (in megabytes) via the network under two distinct conditions, when the block numbers are increasing and when the nodes are increasing. In the proposed architecture that was simulated, the network nodes are separated into clusters, and a cluster head is assigned to every cluster. The smart contract of the suggested framework's framework includes a number of functions that are explained by algorithms. With the aid of JMeter, simulation is done for the range of users-from 200 to 2000-using the system and carrying out its various activities. The throughput in Meter is expressed as Data/Time, i.e., units of KB/ sec. Simulation is done for the above-mentioned number of users during the experiments in order to assess the system's effectiveness. The proposed framework is used to conduct these simulations, and throughput is examined at the conclusion. The reason for selecting PBFT as the consensus algorithm is the low latency in executing the transactions in the blockchain network. Also, PBFT provides more throughput in the context of a user. Figure 9 shows a detailed comparison between different types of consensus protocols.
• Average execution time: Execution time will grow as the number of transactions rises. The smart contract's features are used to carry out the transaction. When there is only one user, all the functions will execute more quickly; for example, adding a user, selecting a cluster head, and adding records would take 0.0023, 0.0019, and 0.0021 s, respectively. • Average transaction time: With the increase in the users in the network, the transaction time is increasing linearly in PBFT as compared with the other consensus algorithm. With comparison to the other consensus, algorithm PoW takes a lot of time to execute one transaction [42]. While comparing with PoB, a very small difference is analyzed in the latency for low number of users [43]. A large difference in transaction time is analyzed with the increasing number of users. The main reason for the selection of PBFT is the high transaction rate with a large number of users. • Throughput: For calculating the throughput of the proposed framework, JMeter is used, simulating a user base of 200 to 2000 users operating the system and carrying out operations. The throughput is expressed in units of data/time or KB/ sec. The evaluation of the system's performance included a simulation of the user's numbers, as stated above. Throughput is analyzed by considering the number of transactions added and transactions verified, and also when the number of blocks and the number of nodes are increasing in the blockchain network. The detailed analysis of the throughput is displayed in Fig. 10. It is observed that throughput is increasing linearly as the number of users increases. In other existing scheme [37], throughput decreases when the number of users increases. • Average latency: Latency is defined as the time difference between the two actions. It is the time difference between the request of one component of the system and the response of that request. We have used the JMeter to calculate the latency between two actions. The latency is measured in milliseconds. The detailed analysis of the latency is displayed in Fig. 11. The latency is analyzed  between the throughput and the time in which the task is completed. For this result, 2000 records have been taken into consideration and compared with the existing scheme. The evaluation is done for adding data requests, updating data requests, and retrieving data requests. As a result shows, the average latency for 200 records is 6 milliseconds and 9 milliseconds for 2000 records. It is observed that there is very less latency for 2000 requests. For 200-1400 records, the graph comes out nearly the same, but as the number of users is increasing, latency decreases in the proposed scheme as compared with the existing scheme [37]. Table 3 shows the security and privacy comparison between the existing schemes.

Conclusion
In the healthcare system, privacy and security are the main concerning issue. Several solutions for security are discussed, but most of the solutions are not feasible for the healthcare system in relation to automation, transparency, latency, throughput, security, data tampering, and distributed. The first objective of the proposed model is to enhance security and reduce service time for the healthcare system. Also, throughput is increased in the proposed model as compared to the existing model. This is possible because of the lightweight architecture of the proposed model, where only the main server is not responsible for all the necessary actions. Also, a cluster head will manage all the actions. The experimental results and analysis have shown the identified research problem is solved, while maintaining privacy, latency, and transaction time are reduced, and throughput is increased. The major limitation of the work is the device authentication is not considered in MCPS module. Due to this, if one IoT node is compromised, then it is not identifiable in the further process. The future work can be done to authenticate the device before the participating in the proposed framework.
Author contributions AK took part in data curation, formal analysis, writing-original draft, writingreview and editing, validation. KC took part in conceptualization, writing-original draft, writingreview and editing, validation.