A Patient-Centric Healthcare Framework Reference Architecture for Better Semantic Interoperability Based on Blockchain, Cloud, and IoT

Due to the distributed and non-integrated nature of the healthcare systems which results from the application-centric view it leads to a challenging task to manage healthcare data exchange (heterogeneity problem). On the other hand, Blockchain technologies are emerging as promising and cost-effective means to meet some of these requirements due to their inherent design properties, such as secure cryptography and a resilient peer-to-peer network. Likewise, Blockchain-based applications can benefit the healthcare domain via their properties of asset sharing, and audit trails of data access. Existing work mainly pays attention to centralized and blockchain-based mechanisms. But it doesn’t realize the increase need for better data interoperability amount multiple healthcare systems and services. This requires shifting from the application-centric solutions toward the patient-centric solutions. This paper presents A secure and efficient framework based on Blockchain, Cloud, and IoT named Patient-Centric Healthcare Framework (PCH) for better healthcare systems interoperability. A tiered-based architecture (5 tiers) with collaboration is designed for the feasible realization of PCH. Also, the design and implementation aspects start from the layering diagram, system context, and detailed reference architecture that emphasizes the detailed component topology and interactions within the framework. An electronic medical record is used to show how healthcare data is processed with the required security considerations. Then, an evaluation of PCH against the existing Blockchain-based healthcare frameworks is conducted. The results analysis demonstrates that PCH offers practical solutions to protect healthcare data and support efficient data sharing with better interoperability.


88
Depending on the centralized systems often suffers from the 89 fear of data crashes due to the presence of most of the data in 90 one place; thus, one node/server failure results in the downfall 91 of the system entirely [9]. 92 2) PRIVACY ISSUES 93 In the health sector privacy issues have led to decreased 94 patients' trust in the EHR. Thus, if the privacy of sensitive 95 health information is weak, then public confidence becomes 96 difficult to be maintained in the health care delivery system. 97 Despite the expanded convenience and feasibility offer by the 98 EHR, patients are in continuous fear regarding their health 99 information's integrity and privacy [10], [11]. EHRs are likely to be attacked by hackers with a compre-102 hensive awareness of network navigation, which remains 103 unprotected. As attackers can see all information within the 104 EHR files such as patients or doctors' names, addresses, pay-105 ment information, medications, and history records. Despite 106 EHR benefits the process of health care, but, it can also be 107 vulnerable to attacks if they were not adequately secured [12]. There are different types of data including structured, semi-111 structured, and unstructured. Statistically, 80% of medical 112 data are unstructured, which further complicates the manage-113 ment of these data. The major source for healthcare appli-114 cations is patient records. Data integration is the task of 115 combining different data sources and providing a unified view 116 of the data. Such integrated data are needed to be standardized 117 and kept in a repository. However, integrating data from a 118 variety of sources is not a trivial task, due to the large volumes 119 of heterogeneous data during mapping, ranking, and key 120 matching. Moreover, structural, and semantic heterogeneity 121 is another problem that faces data integration [13]. Robust EHR interoperability is vital for providing effective 124 patient-centered care that it is lacked in most EHR systems 125 as being shown in recent findings. When a patient visits 126 a specialist or an emergency and receives treatment, the 127 healthcare provider must access the patient's health history 128 patients involved in clinical trials has discoursed in the frames 173 of this work. is one of the Blockchain frameworks for business that uses the 181 Cloud environment. Still, it saved the critical data off-chain, 182 which empire the security, and generally, this is considered 183 a very shallow idea level that missed the implementation 184 aspect. 185 Liang et al. [17] designed and implemented a mobile-based 186 healthcare system for personal health data collection, sharing, 187 and collaboration between individuals, healthcare providers, 188 and insurance companies based on blockchain technology. 189 In addition, the system was extended to accommodate the 190 health data usage for research purposes. The algorithm used 191 to handle data records can simultaneously preserve integrity 192 and privacy. The main advantage of the framework is adopt-193 ing the channel concept that Hyperledger Fabric supports to 194 deal with the isolated communication required by specific 195 scenarios. Still, the main missed section is the implementa-196 tion details for reference. 197 Li et al. [18] introduce a decentralized medication man-198 agement system (DMMS) that uses a blockchain ledger to 199 manage medication histories. However, the Proof-of-concept 200 (POC) shows an integrated standard healthcare application 201 using a primitive definition for the healthcare entities. How-202 ever, using the Hyperledger Composer terminologies while 203 implementing Hyperledger Fabric requires a common health-204 care framework to integrate with. 205 Jamil et al. [19] proposed A Novel Medical Blockchain 206 Model for Drug Supply Chain Integrity Management in 207 a Smart Hospital based on Hyperledger Fabric describ-208 ing its design, implementation, and performance evaluation. 209 An intelligent contract developed in the solidity program-210 ming language in combination with permissioned blockchain 211 architecture that is used to achieve transparency, security, 212 and privacy of the proposed system, carrying out several 213 experiments to test the suggested system's performance in 214 terms of transaction response time, throughput, latency, and 215 resource utilization. 216 Yang et al.
[20] present a privacy-preserved blockchain 217 scheme for collaborative medical decision-making, including 218 the security of Blockchain and personal data privacy and 219 identifying the reasons for the lack of medical collaboration 220 and the associated risks. Concerning the proof of familiarity 221 (PoF), a consensus gathering algorithm is designed to assimi-222 late healthcare stakeholders' medical decisions (patient, doc-223 tor, insurance company, cured patient). The proposed PoF 224 consensus algorithm efficiency is confirmed with multichain 225 2.0(an open-source blockchain simulation platform). A two-226 layer security measure is followed while preserving the stake-227 holders' identity; the First layer is concerned with storing the 228 identities of patients, cured patients, doctors, and insurance 229 companies locally. The second layer is concerned with hash-230 ing those identities stored in a block. In addition, modified 231 blockchain architecture is used (off-the-chain) for securing 232 clinical data. Allowing the trusted participation of the medical 233 decision-giving entities to afford improved clinical decisions. 234 Sharma and Balamurugan [21] proposed a system to 235 deploy a Blockchain-based EHR network and implement 236 basic functionalities in the network with the primary objective 237 leverages cryptographic fundamentals underlying blockchain 277 technology to achieve tamper-proof logs of events within the 278 supply chain. It utilizes smart contracts within the Ethereum 279 blockchain to achieve automated recording of events acces-280 sible to all participating stakeholders. Additionally, the pro-281 posed solution is cost-efficient regarding the amount of gas 282 spent executing the different functions triggered within the 283 smart contract. 284 Rajput et al. [24] suggested a novel access control frame-285 work that preserves personal health record (PHR) data pri-286 vacy in patient's emergency conditions. It works grounded 287 on permissioned Blockchain Hyperledger Fabric and Hyper-288 ledger Composer playground for assessing the framework's 289 performance. The experimental results declared that this 290 framework guarantees the secret data sharing of the PHR 291 through considering the auditing, immutability, and emer-292 gency access control policies. Furthermore, as the PHRs are 293 exchanged/shared among different participants (agencies), 294 a standard like HL7 FHIR is required for assuring the security 295 of data sharing implementation. 296 Nguyen et al. [25] proposed a new cooperative architecture 297 of sharing and offloading data for healthcare by leveraging 298 Ethereum blockchain and edge-cloud computing. Also, a 299 privacy-aware data offloading scheme is offered where under 300 system constraints, the MDs can offload IoT health data to 301 the edge server. Then, a new data-sharing is presented by 302 using Blockchain and smart contracts enabling secure data 303 exchange between diverse healthcare users. A reliable access 304 control mechanism accompanying a decentralized InterPlan-305 etary File System (IFPS) storage design on the cloud were 306 developed. Additionally, the data-sharing scheme reaches 307 efficient user authentication and significantly increases data 308 retrieval speeds even though protecting the healthcare system 309 from malicious access. By evaluating the system, it was 310 proved that the smart contracts' operation cost is low, and 311 system security is guaranteed, showing the healthcare appli-312 cations' scheme feasibility. 313 The relative comparison of the state-of-the-art blockchain-314 based approaches to secure EHR systems is given in Table 1 [26]. Although Access Control is an important feature 320 however booth Musamih et al. [23] and Zhang et al. [26] 321 didn't address it in the framework. Also the Access Revo-322 cation as an advanced level is addressed by Jamil et al. [19], 323 Rajput et al. [24], and Chukwu and Garg [27].

324
Blockchain platform used main two frameworks; 325 Musamih et al. [23], Zhang et al. [26], and Fusco et al. [  along with their related transactions; in other words, it can 370 be considered as the system's business logic. Thus, for an 371 application needs to interact with the ledger Chaincode is 372 invoked. Peer nodes are considered as a fundamental element 373 of the network because of their ledgers and smart contracts' 374 hosting. A peer executes chaincode, accesses ledger data, 375 endorses transactions, and interfaces with applications. Some 376 peers can be endorsing peers or endorsers. Channels are a log-377 ical structure designed by peers assembly, and this capability 378 allows them to create a separate transactions ledger [32].

380
In an ideal world, assets are digital or intangible, but you must 381 develop solutions for physical assets. In a typical business 382 scenario, participants are known and identifiable because of 383 existing relationships. Asset ownership is transferred through 384 transactions, which must follow a set of business terms [33]. 385

386
A ledger consists of two distinct however related parts: a 387 ''blockchain'' and the ''state database,'' also identified as 388 the ''world state''. Unlike other ledgers, blockchains are 389 immutable; after a block is added to the chain, it cannot be 390 changed. In contrast, ''world state'' is a database encompass-391 ing the current value for a set of key-value pairs whether 392 added, modified, or deleted transactions in the Blockchain 393 that has been validated and committed [34].

395
The Blockchain is composed of a chain of blocks, and a new 396 block is always appended to the end of the chain. A block 397 might consist of zero or several transactions, depending on 398 how the block configuration was defined either as Time-399 based, Transaction-based, Memory-based. 400 The crucial aspect that makes the Blockchain immutable is 401 a mathematical hash function. As shown in Fig. 3, each block 402 contains a previous block's hash, which is included in calcu-403 lating the next block's hash. This hash signifies whether any 404 block has been tampered with, and then the corresponding 405 hash value changes and the Blockchain is no longer linked 406 together, as shown in Fig 3. Because the genesis block is the 407 first block in the chain and does not contain any previous 408 blocks. It usually includes an arbitrary key-value to initialize 409 the hash function [35]. world state [36], [37]. instantiated to one or more channels [38].  and maintains the shared ledger, including the Blockchain 450 of transactions and the world state database. There are two 451 roles for a peer: endorser and committer. Every peer is 452 always a committer, but not necessarily always an endorser. 453 As mentioned earlier, transactions must be endorsed, and only 454 endorsed transactions may be committed and their output 455 stored in the world state database [39], [37].  Peers can assume the unique role of an endorsing peer, 466 that is, an endorser; Every smart contract may specify an 467 endorsement policy denoting to a set of endorsing peers. This 468 policy states the essential and adequate conditions for a valid 469 transaction endorsement. For a smart contract, the endorsing 470 peer endorses a transaction before it is committed. Endorsing 471 peers endorse the updated proposed ledger to the application 472 but do not spread over the proposed update to the ledger [37]. 473

474
Blockchain networks are composed of and administered 475 by multiple organizations instead of a single organization. 476 By these organizations, Blockchain network is established 477 and managed as they contribute their resources, like nodes, 478 certificate authorities, computing power, physical connec-479 tions, and others, as without these contributions, the net-480 work cannot exist. The network expands and diminishes (as 481 organizations join and leave the network), not dependent 482 on a single organization. Typically, an organization operates 483 multiple peer nodes for different reasons, such as redundancy 484 or performance reasons [40]. is installed on each peer to ensure that transaction requests 492 issued to the peer originate from an authenticated and autho-493 rized user identity [32].

494
Clients use these credentials to authenticate their 495 transactions, and peers use them to authenticate transaction 496 processing results (endorsements). Although connected to the 497 system's transaction processing components, this interface 498 aims to define membership services components so that alter-499 native implementations of this component can be smoothly 500 plugged in without modifying the core of the transaction 501 processing components of the system [22].

503
The orders from the ordering service, that is, a communica-504 tion fabric that ensures delivery. When the client application 505 needs the endorsed transactions committed to the shared 506 ledger, it sends the transactions to the ordering service. The 507 ordering service orders the transactions, groups them into a 508 block, and sends them to their peers. This action determines 509 how transactions are committed to the shared ledger [41]. 510 The order is essential to ensure that the world state database 511 updates are valid. Moreover, the ordering service can be 512 executed in multiple ways, ranging from a centralized service 513 that is used in development and testing to distributed proto-514 cols targeting other network as well as node fault models [32].

554
The amalgamation of the Blockchain, Cloud, Internet of 555 Things (IoT), and analytics for holding and validating the 556 health data of the patient and healthcare ecosystem in a uni-557 fied, integrated healthcare framework. The proposed method-558 ology uses the blockchain network to intercept and fetch 559 the data generated from different healthcare systems and 560 other wearable devices worn by the patient. Therefore, it is 561 preferably used to store and maintain the patients' data in 562 several transactions and provide access control support to 563 diverse stakeholders.

564
Moreover, Blockchain architecture also supports medical 565 research by maintaining the health status of the patient's 566 identification and providing authenticated and trusted data for 567 more accurate analysis. The Cloud model is used basically 568 for minimizing the costs and sustaining the utilized capacity 569 fluctuation of the system servers. The IoT is used mainly to 570 collect healthcare information from multiple medical devices 571 and smartphones. Analytics will visualize the outcomes from 572 the semantic interoperability of the collected healthcare data. 573 We have attempted to redefine the standard set of layering 574 the proposed framework from base layered architecture to 575 introduce the tier concept for better isolation and separation 576 of responsibilities. Measures that are used to evaluate the 577 layered architecture of the software. We have also defined 578 steps to verify the layers' logical separation to ensure the 579 layered structure's quality. 580 This section will tackle the proposed patient-centric health-581 care (PCH) framework from multiple viewpoints and details. 582 It starts with the tier/layer model to the high-level grouping of 583 the solution components. This is followed by more elabora-584 tion on the human and technical actors inside the proposed 585 system actor model. Finally, the system context shows the 586 boundaries of the proposed framework. The layered architecture pattern is the most common 589 architecture pattern, which is an elements' logical struc-590 turing mechanism that constitutes the software solution. 591 In contrast, the N-tier architecture pattern is considered as a 592 VOLUME 10, 2022 receives data from the system. The research used to propose 630 the following Healthcare actors can be categorized into (a) 631 Acceptors, (b) Providers, (c) Supporters, and (d) Controllers' 632 as shown in Fig. 6.      it. The external entities and their communications with the 660 proposed healthcare framework were based on the con-661 cerns of the stakeholders from the system's actor section. 662 Two external entities are considered obligatory: the public 663 healthcare network and the enterprise (internal) network. 664 The optional entity can be absent in simpler HISs such as 665 the security and governance tier. Besides, some categorized 666 actors may require specific entities.

667
Several entities execute two-way communication between 668 each other. But only one type of communication per interac-669 tion is described due to space limitations; but in practice there 670 are many more possibilities.

671
As shown before, the proposed framework interacts 672 with all 16 actors (human & system) elaborated before. 673 The communication media through the Channels will be 674 listed in the ongoing sections. All healthcare systems, sub-675 systems, and data where reside. All those communication 676 and transaction should be governed through the governance 677 and security components. The details of information flow 678 between the main components are shown in Table 3.

680
The scope of the reference architecture is on concepts, logical 681 elements, and associated models that can be used to apply 682 and implement in a healthcare organization. The ultimate aim 683 of this reference architecture is to help improve healthcare 684 data interoperability on the semantic level. Its focus is on 685    The breakdown illustrations how a system can be decom-691 posed into several (sub-)modules and how they relate to each 692 other. This view regularly can be considered as the basis 693 for system's design, development, and documentation. The 694 breakdown view supports checking the required modules' 695 presence for all stakeholders. Such a breakdown view decom-696 poses the system into five tiers with multiple layers, together 697 with sub-modules and components.

698
As shown in Fig. 9, the proposed framework comprises 699 tiered/layered subsystems; each subsystem is composed of 700 multiple specialized components. The external (public) net-701 work layer allows users to access the proposed framework 702 platform through the channels layer. The channel is formed 703 of the media in which the users can interact with the plat-704 form. Then the Core Network tier abstracts the communi-705 cation between the component mentioned in this section. 706 It may be client on-premises location, cloud environment, 707 and hybrid-cloud or multi-cloud topology. Those components 708 can't communicate without the action performed by the Net-709 work Communication Tier. Those communications should 710 be done between the Core Network environment and the 711 Blockchain network. Due to the personal information (PI) and 712 the sensitive personal information (SPI) transformed from the 713 Enterprise Network Tier stored in the platform, the need for 714 the Network Governance Tier appears.

715
They start with the most outer tier exposed to the public The first layer of the Core network tier is the Blockchain 769 application layer, which serves as the network's brain com-770 posed of multiple subsystems and components-starting with 771 the API Management platform, which addresses the spec-772 trum of API lifecycle, monetization, and policy enforcement 773 options. We leveraged the open-source API management to 774 unify the interactions.

775
The second layer of security is Identity & Access Manage-776 ment (IAM), a framework of business processes, policies, and 777 technologies that facilitates the management of electronic or 778 digital identities. With an IAM framework in place, frame-779 work auditors can control user access to critical information 780 within their platform. We used for IAM the single sign-on 781 (SSO) systems, two-factor authentication (TFA), and privi-782 leged access management. These technologies also provide 783 the ability to store identity securely and profile data and 784 data governance functions to ensure that only necessary and 785 relevant data is shared.

786
With the support of the Application Logic components, 787 the Event Listener component, and the Transaction Manager 788 components, the core network tier manages the framework's 789 transaction logic to ensure that the business processes are well 790 executed under the agreed contracts.

791
Data visualization is translating information into a visual 792 context, such as a map or graph, to make data easier for 793 pulling insights from the collected data. The main goal of data 794 visualization is to make it easier to identify patterns, trends, 795 and outliers in system large data sets. This dimension is 796 fulfilled from the Analytics components and the Visualization 797 components.

798
The interaction with the Blockchain network stabilized 799 through the Hyperledger Fabric Client SDK component that 800 is considered as a programming library from client-side com-801 posed of a set of APIs that appears in the form of ''methods'' 802 or ''calls,'' that can be used by client programs for accessing 803 blockchain network functionalities and capabilities. Client 804 programs can be written in Python, Node, Java, or any other 805 supported languages. Additionally, SDK may also comprise 806 development tools. The Actual Blockchain components reside in the Blockchain 809 network layer. At the same time, the modeling has to do 810 with workflows. Since healthcare repercussions to a poorly 811 defined or executed contract, great care must ensure that the 812 warrant is issued correctly and free of potential weaknesses. 813 The software also needs to be verifiable, secure, and reliable. 814 The contract must be executed accurately and be free of 815 possible faults. This layer comprises multiple Blockchain 816 components like Node(s), Ledger, Data Store, Smart Con-817 tract, Consensus, Membership, Event.  The semantic interoperability between health information 880 systems is a significant challenge to improving clinical prac-881 tice quality and patient safety. Thus, this layer comprises 882 two main components: Transformation Component and the 883 Rule-Based Engine Component. The transformations work to 884 map the healthcare unstructured data format into a standard 885 one using the power of the Rule-Based engine to manage and 886 govern the process of data transformation. To transform, the framework needs a specialized connectiv-889 ity facility that helps connect different systems to map the 890 connectivity protocols for the existing healthcare systems to 891 maintain a stable transformation process.

893
The Enterprise (Internal) Network Tier comprises multi-894 ple existing healthcare applications and enterprise systems, 895 including the Enterprise Application, the Enterprise Data, and 896 the Enterprise User Directory. Those applications and sys-897 tems store the operational information related to the health-898 care information for the citizen. The main issue of this tier 899 is that the modification of the existing systems will require 900 much more cost to invest and will result in the refusal to 901 proceed with the integration. So, this layer will remain intact, 902 and the only modification will be through providing APIs 903 from the proposed framework to integrate with.

904
An enterprise interacting with the blockchain network can 905 create or use enterprise applications that may possibly act 906 together with the smart contracts on top of the blockchain. 907 Willy smart contract can obtain data from, send data to or 908 request services from the enterprise application.

909
On the other hand, the enterprise user directory keeps user 910 information for either supporting authorization, authentica-911 tion, or profile data related to the enterprise applications 912 while the connectivity and transformation services are con-913 trolling access to the enterprise services, enterprise network, 914 or enterprise-specific cloud provider services.

915
Enterprise data comprises metadata in addition to record 916 systems for enterprise applications that may possibly flow 917 directly to data repositories or data integration which provide 918 feedback loop in the blockchain systems' analytical proce-919 dure. Enterprise data correlates to blockchain consist of: 920 1) Transactional Data -Business interactions data that 921 adhere to related processes whether healthcare or finan-922 cial. This data is derived from reference data, dis-923 tributed storage, and master data repositories. 924 2) Application Data -Enterprise applications functionally 925 or operationally used or produced data. Usually, the 926 data get enhanced or improved for adding value and 927 driving insight. The HL7 v3 messaging standard uses an information 1000 model called the Reference Information Model (RIM) and 1001 a formal methodology called the HL7 Development Frame-1002 work (HDF) to increase the detail, clarity and precision of the 1003 message specification. The HL7 v3 Reference Information 1004 Model (RIM) provides a conceptual shared generic model 1005 that facilitates interoperability by standardizing all data mod-1006 els to a norm. CDA is a suite of HL7 v3 standards for 1007 representing clinical documents such as a referral form or a 1008 discharge summary.

1010
As shown in the architecture section, an interoperability 1011 EHRs framework on mobile, IoT, and hybrid cloud is consid-1012 ered. A Hyperledger Fabric blockchain network is deployed 1013 on Amazon cloud computing and the on-premises servers. 1014 The Cloud infrastructure is composed of two layers of 1015 the Core Network Layer. The Blockchain Application layer 1016 includes two virtual machines, AWS EC2, built based on 1017 the two virtual machines. Ubuntu 20.04 LTS was used as 1018 the application layer component. Detailed system setting and 1019 topology and illustrated in Fig. 10 below and elaborated in 1020 the below section.

1021
Blockchain Network layer utilizes the Blockchain Appli-1022 cation layer using a Linux computer through accessing the 1023 VPC resources for serving as Hyperledger Fabric client, thus 1024 AWS CLI version 1.16.149 or later is installed on com-1025 puter. As AWS CLI prior versions do not have the managed-1026 blockchain command. Thus, the latest version of the available 1027 AWS CLI is recommended to be used.

1028
VPC must have an Ipv4 CIDR block, with enableDnsHost-1029 names and enableDnsSupport options set to true. In case of 1030 connecting to the Hyperledger Fabric client utilizing SSH, 1031 VOLUME 10, 2022 are up and running. Additionally, it manages certificates, 1063 easily allows creating proposals for voting among network 1064 members, and helps tracking operational metrics associated 1065 with requests, data storage, memory usage, and computa-1066 tional load.

1068
Fabric network involves various entities, ordering service 1069 nodes, peer nodes, and clients belong to other organizations. 1070 On the network, each one holds his own an identity, offered 1071 by a Membership Service Provider (MSP), that typically 1072 correlated with an organization. The whole network entities 1073 have visibility of all organizations' identities as well as the 1074 ability to verify them. The fabric consists of a variety of com-1075 ponents such as endorsers, ordering services, and committers, 1076 which constitutes different steps in transaction processing, for 1077 instance, an endorsement, ordering, validation, and commit. 1078 As a result of components and stages variety, Fabric offers 1079 several configurable parameters for instance endorsement 1080 policy, channels, block size, as well as state database. Thus, 1081 one of the major challenges faced during setting up an effec-1082 tive blockchain network is finding the correct set of values 1083 used for these parameters.

1085
This section describes the microservices-based system that 1086 we implemented with smart contracts. To validate our 1087 approach's feasibility and simplicity, the method of this case 1088 study is composed of only three microservices. The exact 1089 implementation approach could be extended to more com-1090 plex designs by adding more microservices. In this case 1091 study, we adopted a simple microservice-based application 1092 consisting of three microservices. The method comprises 1093 three microservices written in JavaScript: Doctor, Patient, 1094 and Diagnosis. The system's goal is to allow doctors to keep 1095 track of diagnoses for their patients' diseases. The microser-1096 vices are accessed from the web user interfaces through 1097 an API-Gateway that routes the requests and forward the 1098 messages. Besides its simplicity, the system implemented 1099 includes several characteristics of accurate and more exten-1100 sive procedures. It exposes APIs to connect to the graphical 1101 user interface, enables microservices to communicate, and 1102 stores the data in independent non-SQL databases.

1104
In this subsection, A smart contract is designed for formu-1105 lating an access control model. As well, an access protocol 1106 is created that presenting EHRs workflow sharing scheme. 1107 The smart contract was written in NodeJS programming 1108 language then deployed on AWS Lambda functions that work 1109 together with the cloud blockchain through the web3.js API. 1110 Interaction between users and smart contracts can be achieved 1111 through client that create an account to communicate with the 1112 blockchain network to gain access to data.      When an unauthorized request to the EHRs system 1146 isdetected, the EHRs manager inform the smart con-1147 tract for issuing a penalty to the requester. In this paper, 1148 a warning message is also given as a penalty. to peer nodes, requests to join channels, enrols an admin peer, 1168 and lists the chaincode instances on a peer node. Also, peer 1169 node logs include the chaincode installation outcomes with 1170 the facility of enabling and disabling logs on individual peer 1171 nodes.

1172
Chaincode logs support analysing and debugging the busi-1173 ness logic and execution of the chaincode on a peer node. 1174 They contain the results of chaincode instantiating, invoking, 1175 and querying. A peer can run many instances of chain-1176 code, thus when chaincode logging is enabled, individual log 1177 streams are created on the peer for each chaincode.

1178
CA logs support determining when an account member 1179 connects to the network or as new peers join with a member 1180 CA. It can be used for debugging problems concerned with 1181 certifications and enrolment. For each member CA logging 1182 can be enabled and disabled along with a separate log stream 1183 for each member. In Hyperledger Fabric, consensus involves the endorsement, 1187 Ordering, and Validation phases. The transaction flow is 1188 separated into three steps, which might be run on different 1189 system entities: As shown in Fig. 11, the first step is Endors-1190 ing a transaction: Run the transaction and check its correct-1191 ness. This step corresponds to ''transaction validation'' in 1192 other blockchains. The second step is Ordering transactions 1193 through a consensus protocol: The ordering is done with-1194 out regarding the transaction semantics. Finally, the third 1195 step is Validating transactions: Transactions are validated 1196 per application-specific trust assumptions. This step is also 1197 helpful in preventing race conditions due to concurrency.

1198
The architecture employs an endorse-order-validate 1199 paradigm to distribute the execution of untrusted code in 1200 an untrusted environment. This design is different from the 1201 order-execute paradigm because Hyperledger Fabric runs 1202 transactions before reaching the final agreement on their 1203 order. It combines the passive and active approaches to 1204 replication. This section goes through the process from submitting a 1208 transaction from a client app to creating a block on the chain 1209 and confirming consensus, as shown in Fig. 12. We see how 1210 privacy is achieved with only specific participants running 1211 VOLUME 10, 2022 peer can distribute this block to other peers of the channel in 1251 a hierarchical way.

1252
Finally, the transaction third (validate) phase that com-1253 posed of last two steps. The sixth step in the transaction 1254 flow is the validation step. Where the requestPatientSurgery 1255 transaction is inspected for validation. If the block has the 1256 right R/W sets and signatures according to the endorsement 1257 policy and the current state of the ledger (based on the R/W set 1258 key history). committers flagged the transaction as valid and 1259 updated their world state based on the write set and surgery 1260 request. The final and seventh step in the transaction flow 1261 is the notification step where if the client registered to be 1262 notified when transactions succeed or fail, it is notified of the 1263 event.

VII. RESULT
1265 Several research ideas have been suggested for applying 1266 blockchain to healthcare, as well as implementation are 1267 underway for attempt requests. Even now, few published 1268 studies have kept in consideration the needed software 1269 design for implementing healthcare applications based on 1270 blockchain effectively. This section evaluates the security 1271 dimensions of the system and the interoperability of the pro-1272 posed healthcare framework. First, the security of a system 1273 is analyzed by studying its related properties such as data 1274 integrity, and non-repudiation of unauthorized access, after 1275 that, healthcare data interoperability is examined via theoret-1276 ical analysis besides trials. Finally, Table 4 summarized the 1277 evaluation is presented through a comprehensive discussion. 1278

1279
Taking part in integrity analysis, data can be categorized into; 1280 on-chain data and off-chain data. The immutability of the 1281 blockchain ensures on-chain data integrity while the off-chain 1282 data can be split up into directory and healthcare information. 1283 On the blockchain, the healthcare data integrity is validated 1284 with the digested data stored in it. Thus, because the data 1285 storage on the blockchain is tamper-proof, so in case that they 1286 pass the integrity check, then the users can trust the healthcare 1287 data.

1288
Alternatively, the directory information could be tampered 1289 from malicious servers through an internal attack. But for two 1290 reasons it will not be a calamity. First, before storage all sensi-1291 tive data is encrypted. Thus, tampering directory information 1292 will not be leaked. Probably, as a result of ID corruption 1293 or decryption malfunction caused by content corruption will 1294 led to data not found, and later users will be informed of 1295 it. Second, once data corruption happens, the patient or the 1296 healthcare provider can recover the directory information 1297 quickly, where the patient can rebuild the corrupted session 1298 using the data on their device, while the healthcare provider 1299 can rebuild a data inventory on the local legacy system.    Generally, the not satisfied metric scored 1, partially satis-1336 fied metric scored 3, and finally fully Satisfied metric scored 1337 5. However, for the Interoperability metric the score will be 1338 as the following foundational interoperability will be rated 1339 as 1, structural interoperability will be rated as 3 and finally 1340 semantic interoperability will be rated as 5.

1341
In summary, Table 5 Table 5 summarizes healthcare data management mecha-1348 nisms in blockchain technology from 2018 till now. Much 1349 research work was developed to design blockchain technol-1350 ogy to secure, share, and store EHR data within and across 1351 institutions.

1352
Only two out of ten frameworks based on Ethereum 1353 based consortium Blockchain they were developed by 1354 Musamih et al. [ PCH offers the necessary security analysis to demonstrate 1372 that the proposed framework with adopted components and 1373 the fundamental protocols has excellent security and pri-1374 vacy protection advantages for users in decentralized and 1375 collaborative data management. According to the security 1376 standards, some important security and privacy requirements 1377 are satisfied in our proposed framework. We summarize the 1378 significant advantages of the proposed framework in the 1379 following aspects.     When a doctor wants to access a patient's healthcare data, 1416 the doctor should ask permission. Otherwise, the system will 1417 doctor hopes to acquire a regular access privilege from the patient, the doctor should also directly ask whether it can be granted. In short, for the patient, all the data access regarding his healthcare data should be firstly authorized by him. Moreover, the patient can independently permit temporary access sources, particularly by implementing a smart contract 1471 design on top of Hyperledger blockchain platform on 1472 Amazon cloud, aiming at exploiting the access control 1473 capability of smart contract and blockchain for man-1474 aging the required healthcare business and ensuring 1475 integrity of the system.

1476
3) Instead of theoretical analysis shown in contempo-1477 rary studies, this study focuses on detailed architec-1478 tural design and actual implementation of data sharing 1479 design using Blockchain, Cloud, as well as IoT in 1480 the healthcare systems. Thus based on implementation 1481 outcomes several useful technical blockchain features 1482 are identified for EHRs sharing, resulting in signifi-1483 cant contributions to blockchain research in multiple 1484 domains such as IoT applications, Cloud including 1485 healthcare.
1486 4) A comprehensive evaluation of the proposed frame-1487 work regarding various aspects is provided like 1488 security aspects (attack resistance, access control, 1489 access revocation, privacy-preserving, patients con-1490 trol EHR access, different user types), also data 1491 integrity aspects (Block Search, data format, Inter-1492 operability), and finally technical aspects (used 1493 Blockchain platform, detailed architecture, detailed 1494 implementation)

1495
The work results are significant as efficiency, and inter-1496 operability level is considered as one of the important issues 1497 faced during the adoption of healthcare blockchain. PCH pro-1498 vides the comprehensive platform from an enterprise archi-1499 tecture viewpoint that would be implemented as a government 1500 scope of at least a mega healthcare provider chain/group. 1501 The framework provides the integration fixability to integrate 1502 with the currently existing system, either its data stored in 1503 healthcare standard format like HL7 or customized non-1504 standard design. The transformation component plays an 1505 important role. Moreover, it provides a template for holding 1506 the healthcare information in a standard format that facil-1507 itates the interoperability between the data from different 1508 systems and the pluggable reporting engine and analytical 1509 services.

1510
As a result, once a provider has obtained access to patient 1511 data, that data is permanently in possession of the provider. 1512 When a patient visits different providers many times through-1513 out their lifetime, their health and other sensitive personal 1514 information are available at several sites based on the granted 1515 permission. Also, patients may wish to release their medical 1516 records to a new provider, which was not easily accomplished 1517 and became available today using PCH.