Heart disease severity level identification system on Hyperledger consortium network

Component’s roles and responsibilities of the proposed system

The proposed system network has been designed using multiple organizations as a consortium blockchain. Through peer-to-peer connections, the system enables collaboration between various organizations such as hospitals, clinical laboratories. The Raft consensus protocol is used to create this system, and it operates in a leader and follower pattern. The Raft consensus algorithm has been implemented to provide Crash Fault Tolerant (CFT) and enhanced understandability in a distributed network. This system has a special node called the Orderer node which is the central part of the fabric network. The Orderer node’s responsibility is to maintain a consistent database, distribute and ensure consistency among multiple peers in the participating organization. Three ordering nodes make up this system, where a leader node will be dynamically selected from among them. The reason for having more than one Orderer node is to achieve fault tolerance in this network. The role of the membership service provider (MSP) is to supervise and validate participants’ identities, provide crypto materials for network entities during transaction proposals and to revoke user identities with the help of Certificate Authorities (CA). The CA facilitates user enrollment and transaction invocation in blockchain networks by providing necessary certificates. The next key component is the channels or ledgers, and it is a subnetwork of a network that helps to participate in the form of proposing and receiving transactions from their own peers. The transaction details of any channel can be viewed only by members of a corresponding channel (Hang & Kim, 2021; Manevich, Barger & Tock, 2018).

A world state database, smart contracts, and a copy of the ledger are all present to each peer. The main role of the peer is controlling the ledger in the form of reading/writing by chaincode execution. The categories of peers and their roles are: (1) Endorsing peers—using its copy of the ledger, it executes the proper smart contract in response to the client’s request. (2) Committing peers—for future audit purposes, these peers analyze each transaction request and update its copy with either valid or invalid transactions. (3) Anchor peers—across the peers in the organization, anchor peers disseminate the block details from the ordering service. (4) Leader peers—these are like anchor peers in that they also disseminate block information, however this leader peer does it using the Gossip protocol.

Private data and endorsement policy

To ensure the organization-level privacy of patients’ medical records, in the proposed system, the private data collection concept has been utilized. These private data are accessed in a peer-to-peer manner between the authorized organizations using gossip protocol (Benhamouda, Halevi & Halevi, 2018). The patient’s medical records can be endorsed by an organization specified in the private collection. Other healthcare centers are not able to access the patients’ health information stored in a different hospital even though they are in the same communication channel. The definitions for the hospital’s private data collection are shown in Fig. 3. The consideration of policy in “Hospital1PrivateCollectionAssets” allows the members of Hospital-1 and Laboratory-1 to access and transact the data.

The ordering service transactions do not comprise private data. So, these private data are not distributed among all the peers in this network. To reflect the details of private patient data to the authorized organization and its peers, endorsing peers takes part in a major role. Figure 4 illustrates the endorsement policy for the private collection. It defines any transaction executed in the private data should be endorsed by Hospital-1 through endorsing peers.

User identity and enrolment process

This helps to ensure that only authorized people have access to sensitive patient information. The proposed system is specifically designed to provide secure and private access to patient records. It uses digital identity and attribute management to ensure that only authorized individuals can access sensitive information. These identities are signed by a trusted entity, usually a CA, and used to represent entities in the network. It enables organizations to assign specific permissions to entities on the network, and to define the conditions under which these permissions can be granted or revoked. It allows each organization to create roles and assign privileges according to healthcare professional needs. Each network organization has a registered administrator with responsibility of managing users and confirming the identification and attributes with CA. On the fabric network, the user identity registration process is split into two phases: the organization admin registration and the healthcare user (i.e., doctors, nurses, and lab technicians) registration.

Attribute based access control policy

Attribute-based access control (ABAC) is a powerful security mechanism for protecting the privacy of EHRs when sharing them between different healthcare organizations. It allows for the secure exchange of EHRs between different organizations by using attributes, such as an individual’s identity, role, and access rights, to determine who can access and view the EHR. The policies can also be set to dynamically adjust based on the attributes associated with the participating user and medical records. For example, an ABAC system may grant access to an EHR if the user is a doctor in the emergency department of a hospital but deny access if the user is a doctor in the primary care department. ABAC provides the flexibility to define policies that are tailored to the particular use case and can be modified as the security requirements change (Shammar, Zahary & Al-Shargabi, 2022). The core elements of attribute-based access control in EHRs are as follows:

• Attributes (or) subjects: These are the characteristics used to define user access. Subjects can include things like organizations participating member’s role (like doctors, nurse), department, and other user information.

• Objects: It represents various resources, like patient’s demographic information, medical history, medications, vital signs, laboratory tests, clinical notes, and insurance information.

• Operations: It includes assigning roles to each user, determining user access levels (like view, edit, or delete), set up notification systems and assign privileges to each user (such as creating a new patient record or scheduling an appointment).

• Policies: Policies are used to define which users can access which resources. Policies can be based on user attributes, or they can be based on context, such as the time of day or the type of device being used.

• Environments: All access to EHRs must be logged, and the log should be reviewed on a regular basis and Patients should be able to specify which locations, if any, EHRs can be accessed from.

When considering shared EHR data, attribute-based access control systems offer the following advantages:

• Fine grained authorization: It uses user attributes, such as user roles and group membership, to define access rights to EHR data. This type of access control allows for very specific authorization decisions to be made, based on the user’s specific attributes. For example, a doctor may have access to a patient’s medical record, while a nurse may only be able to view the patient’s list of medications.

• Independent authorization: Attributes can include the patient’s identity, the owners of the data and the receiver of the data, the type of data being shared, and the purpose of the data sharing. With ABAC, each data sharing transaction can be independently authorized, ensuring that only the necessary and appropriate data is shared.

• Attribute management: ABAC enables healthcare organizations to manage access to medical records based on the attributes of the user, such as their role in the healthcare organization, their location, or even the type of data they are trying to access. This makes it possible to create complex and nuanced access policies that are tailored to the needs of the healthcare organization and its users.

Smart contract for heart disease prediction and weight computation

This section describes the datasets information, feature selection, the methodology used to diagnose heart disease, and feature weight calculation for ranking the patient. In this phase, the entire work is broken down into four stages. At stage 1, attributes from EHR records are chosen for prediction of heart disease. Stage 2 uses the Gaussian naive Bayes technique to predict the disease. The severity level of cardiovascular disease was determined in stage 3 using a feature weight computation approach. Finally, the Emergency Attribute Based Access Control (E-ABAC) model has been applied for emergency care.

Evaluation metrics

The metrics used to evaluate the efficiency of the proposed blockchain system and smart contracts are carried out in this section. The following essential parameters are considered in measuring the performance of the proposed system: success rate, average throughput, average latency and resource consumption. Five trials have been used to assess each metric. The following gives a quick explanation of each metric:

• Success rate: It is measured using the number of transactions executed successfully against the submitted transaction count.

• System throughput: The number of valid transactions that were committed to the blockchain system over a stipulated period is used to compute the success rate.

• System delay/latency: It is measured by how long it takes for the result to reflect in the blockchain system after a transaction has been submitted to the system.

• Resource utilization: It is determined from system’s average CPU consumption percentage and memory used by the blockchain system.

Security evaluations

The sharing of highly confidential communications puts patients and healthcare providers’ privacy and security at severe risk, according to a review of the literature. Security and privacy fundamentals like confidentiality, integrity, and availability must be guaranteed by the system. Transaction layer security (TLS) is used by the Hyperledger Fabric to secure communication between network elements. The fabric system can function effectively without TLS, but it is not recommended in a production environment. In this system, TLS was implemented only in accordance with the system’s security policy. Security, trust, and privacy needs are the ones that are the most unfulfilled. Privacy deals with the appropriate handling of sensitive data, particularly personal data. Security of the blockchain’s records is mostly achieved through cryptography. Participants in a network also carry their private keys, which serve as personal digital signatures. Integrity and authentication are ensured by this digital signature. The TLS Protocol’s main objective is to ensure data integrity and privacy. Showing how the proposed system ensures security is explained in further detail in the subsequent paragraph:

• Confidentiality—Confidentiality is possible by ensuring that the implementation uses a private blockchain and has constrained user access. Participants in this healthcare system will have various responsibilities and privileges. Reports kept in a private collection should be accessible only to the patient who authorized the diagnostic report and the concerned healthcare member. The authorized individual uses the certificate provided by the Fabric CA with a role attribute to identify themselves. Additionally, the TLS mechanism is enabled to guarantee the integrity and confidentiality of data sent between client application and network components.

• Integrity & consistency—Integrity refers to safeguarding private data against unauthorized modifications that may be intentional or accidental. This system makes use of blockchain technology, which ensures data integrity through an endorsement policy. Consistency is ensured with the ordering services. The transaction ordering is carried out by the ordering node of the Hyperledger Fabric network. Because the methods used in these systems, which depend on probabilistic consensus, ensure ledger consistency.

• Availability—A system’s availability helps to ensure that it can be accessed and is fully functional whenever an authorized user needs to use it. Reduced failed connections to data in the blockchain are achieved by making the blockchain network fault tolerant. Multiple peers and three Orderer nodes are used in this system to achieve high availability.

Also, our access control system can withstand common network vulnerabilities, including the Sybil attack, Man-in-the-Middle attack, Race Condition attack, and Collusion attack.

• Sybil attack: This attack involves creating multiple fake identities to overwhelm a network. This system uses digital identities and authentication mechanisms to verify the identity of all participants. Additionally, the Fabric consortium blockchain uses consensus algorithms, the identities of the nodes are verified by the consensus protocol and the network is protected from such attacks.

• Man-in-the-Middle attack: This attack involves a malicious actor intercepting messages between two nodes. Hyperledger consortium blockchain verifies the identity of each node and encrypts the communication between them, making it impossible for a malicious actor to intercept messages. By verifying the identity of the user or entity, access is only granted to the user with the correct combination of attributes, thus enabling secure communication between parties.

• Race Condition attack: This attack involves two or more transactions being processed simultaneously to gain an advantage over other transactions. Hyperledger consortium blockchain uses Fabric CA and consensus protocols to ensure that transactions are processed in a secure and reliable manner. These protocols ensure that all nodes in the network process transactions in the same order and prevent any malicious node from taking control of the transaction process. Additionally, Hyperledger consortium blockchain implements a smart contract feature which allows all participating nodes to validate the transactions and ensure that the data is secure.

• Collusion attack: Attribute based access control by ensuring that all attributes used in the access control decisions are unique. This can be done by assigning a unique identifier to each attribute. Additionally, all attributes should be cryptographically signed to ensure that they are not tampered with during the access control decision process. Finally, the system should be configured to reject any access control decision that results in a collision, i.e., when two attributes of different owners have the same value.

Performance assessment

To evaluate the performance of the proposed systems, the benchmark and network configuration files of Hyperledger Caliper were updated. With reference to block sizes 10, 30, and 50 and varied transaction send rates ranging from 25 to 250 tps, we analyzed the throughput and latency performance. We used a total of 10 different send rates to test the performance of the proposed system and conducted 20 attempts for each send rate. To evaluate throughput, we have conducted a total of 200 trails (10 × 20). Here, 10 represents the overall send rate used, and 20 represents the number of trails for each send rate. When the experiment was being evaluated, we discovered a few outliers in the results. The box plot is used to determine the mean value after the outliers have been removed. A box plot is shown in Fig. 5A to show the range of throughput in relation to block size 10. Using the same procedure as before, we performed 200 trials with block sizes of 30 and 50. Figures 5B and 5C illustrate the throughput evaluation for blocks of 30 and 50, and Table 6 displays the summary of the obtained values.

Figure 6 shows the average transaction throughput statistics from the past investigation. The statistics revealed that for blocks having 10 and 30 transactions, the transaction throughput improved significantly with an increase in send rate. When the block size is increased to 50, the transaction throughput increases until the sending rate reaches 150 tps. As soon as the send rate exceeded 150 tps, the throughput rate declined.

Like the throughput evaluation, 200 trials have been completed for the latency investigation. The latency evaluation for blocks of 10, 30, and 50 is shown in Figs. 7A–7C, and Table 7 displays the summary of the obtained values.

Figure 8 shows the average transaction delay obtained in the experiment. Transaction latency decreases as the send rate rises from 25 tps to 250 tps for blocks with a size of 10 and 30. For blocks of size 50, the latency is initially reduced, and thereafter, consistency is preserved.

TLS’s influence is considered while evaluating the proposed system’s throughput and latency. Figures 9A–9C illustrates the comparison of throughput with and without TLS for blocks of 10, 30, and 50. When TLS was used, the transaction throughput improved exponentially as the send rate increased. On the other hand, the bar chart clearly indicates that throughput performance has dropped significantly in comparison to the non-TLS method. Figures 10A–10C illustrate a comparison of transaction latency with and without TLS. Like transaction throughput, implementing TLS also had an impact on transaction latency performance. The outcomes of this experiment show that the use of TLS significantly affects performance. Even though it has a slight effect on system performance, TLS is required for private and sensitive data.

Based on the experimental analysis discussed above, we implemented this system in place with a block size of 30. In this system, a block can have a maximum of 30 transactions. Since the block size is 30 the system performs well in terms of throughput and latency in all the categories. Although there is a small difference in latency between networks with and without TLS. The results of the above experiment led us to the conclusion that TLS has little impact on system performance. As a result, we utilized TLS to ensure secure communication.

In Table 8, the proposed system’s default configuration is provided. The specifics of this configuration are chosen in accordance with the results of earlier experiments. With the help of the above-mentioned configuration, multiple parallel transactions are submitted to determine the system performance in terms of throughput, latency, and resource consumption. There are various types of rate control mechanisms offered by the Hyperledger Caliper framework (Caliper, 2004). Here, we utilized two different rate control mechanisms to assess the efficacy of the proposed systems. First, the Fixed Load rate controller’s aim is to maintain a defined number of transactions within the system. Second, the Linear Rate controller can gradually change the number of transactions in the system.

Throughput: Figure 11 demonstrates the throughput for 100 to 1,000 simultaneous transactions. The blue bar graph shows the throughput with a fixed load, and the brown bar graph shows the throughput using a Linear Rate. The system’s throughput is significantly higher than fixed load when it implements a linear rate control method. It has been shown that as the volume of transactions increases, both rate control strategies maximize the system throughput.

Throughput and response time of transactions are significantly associated. As the system increases overall throughput, the average transaction’s response time tends to get faster. In comparison to the existing system, which requires a minimum of 2.5 s for a transaction to be completed. The proposed system completes over 81 transactions per second when we implement it using the linear approach. Then, one transaction can be completed by the present system in less than a second. According to the abovementioned observation, the proposed blockchain system has a higher throughput than the existing system.

Latency: Figure 12 demonstrates the average latency for 100 to 1,000 simultaneous transactions. The average latency using a fixed load is depicted in the blue bar graph, and the average latency using a linear rate is depicted in the brown bar graph. When the system uses a linear rate control strategy, its latency is increased compared with a fixed load approach. However, when the number of simultaneous transactions increased, the average latency also increased.

The overall amount of time needed for a transaction to take effect across the peers is known as the transaction delay. Comparing the proposed system to the existing one, the transaction delay is significantly increased. The average transaction time for 100 health records would take more time than it does under the existing system. The proposed system has a larger latency because there are more organizations and peers in each organization.

Resource utilization: The CPU and Memory usages of the system are analyzed in connection with 100 to 1,000 patient records that have been submitted to the blockchain system.

Figures 13 and 14 evaluate the proposed system to an existing blockchain system in terms of CPU and memory consumption. We evaluated two distinct rate controller mechanisms offered by Hyperledger Caliper in this instance to assess how well the suggested system performed. From the above evaluation, this system requires, on average, 63 MB of storage for 100 transactions of health records, compared to 75 MB for the existing system. In terms of CPU utilization, this system uses a maximum of 18% for 100 health records transactions, whereas the existing system uses 63% for 100 health records transactions. It is clear from both instances that the proposed system uses less CPU and memory than the existing blockchain system for all categories of transactions. As a result, the fabric based EHR blockchain system uses very less CPU than the existing blockchain system while maintaining storage consistency between the systems. Along with the benefits, TLS also contributes to a significant improvement in privacy and security.