Blockchain Paradigm for Healthcare: Performance Evaluation

Abstract

Electronic health records (EHRs) have become a popular method to store and manage patients’ data in hospitals. Sharing these records makes the current healthcare data management system more accurate and cost-efficient. Currently, EHRs are stored using the client/server architecture by which each hospital retains the stewardship of the patients’ data. The records of a patient are scattered among different hospitals using heterogeneous database servers. These limitations constitute a burden towards a personalized healthcare, when it comes to offering a cohesive view and a shared, secure and private access to patients’ health history for multiple allied professionals and the patients. The data availability, privacy and security characteristics of the blockchain have a propitious future in the healthcare presenting solutions to the complexity, confidentiality, integrity, interoperability and privacy issues of the current client/server architecture-based EHR management system. This paper analyzes and compares the performance of the blockchain and the client/server paradigms. The results reveal that notable performance can be achieved using blockchain in a patient-centric approach. In addition, the immutable and valid patients’ data in the blockchain can aid allied health professionals in better prognosis and diagnosis support through machine learning and artificial intelligence.

1. Introduction

Healthcare data management is the process of storing and analyzing patients’ health records to improve patient treatment, track the causes of diseases efficiently, manufacture effective medicines and establish an accurate prevention agenda. The early form of data management includes documenting patient’s complaints, diagnosis and the corresponding treatment manually introduced in a health record. Later, with the development of digital data, electronic health records (EHRs) came into existence [1]. For accurate health care, EHRs are often required to be shared among different healthcare organizations, medical drug manufacturers, pharmacists, medical insurance providers, researchers and patients. This poses a serious challenge in keeping the patients’ sensitive data secure and up to date. A patient may visit/get transferred to different hospitals during the treatment lifecycle. A patient in such a situation owns the right over their own medical data and may require defining access control limits, says the U.S Department of Health and Human Services [2] and the European Parliament and the Council of the European Union [3]. The patient needs to sign a consent form stating what data will be shared and with whom and for how long. The consent form and the data are then posted to the recipient instead of sending them over the Internet due to security concerns [2]. Consequently, the process of sharing a patient’s data between multiple hospitals becomes complex, time-consuming and difficult to coordinate. With the trend toward a personalized healthcare for better diagnosis and prognosis, current EHR systems using the client/server approach are limited when it comes to providing a cohesive view and secure shared-access to patients’ health history to multiple stakeholders, including the patients. In a centralized client/server approach, electronic health records are vulnerable to mistakes that can lead to life-threatening situations. Moreover, the patients need to trust the service provider and their exists privacy and security concerns.

Blockchain [4,5] is a very promising technology that enables a secure, private and distributed environment among peers without any trusted third-party using consensus. It is based on a shared, distributed and immutable ledger. Each transaction in the blockchain network is processed and validated by the majority of the network participants that eliminates the need of a trusted third-party. The validated transactions after verification are packed in blocks. Each block is linked to the preceding block by hashing the block’s data along with the previous block’s hash, providing immutability. The blocks in the network are considered valid when more than 50% of the participants reach an agreement using a consensus algorithm [6]. The immutable and replicated blockchain ledger is capable of solving the issues of scattered data, delayed sharing, lack of audit trail, privacy and security that prevail in the client/server model [7]. In addition, blockchain has an important characteristic of enforcing smart contracts—pieces of codes that are executed automatically once certain conditions are met. Blockchain-based EHRs have a tremendous potential in healthcare to enable allied health professionals to manage and share, not only clinical data, but also important patient-reported social and contextual data. Moreover, implementing artificial intelligence approaches on the ledger data that includes patients’ health data from all the hospital in the network can aid allied health professionals in better prognosis and diagnosis support. While many researchers investigated the development blockchain-based system for healthcare data management, most of the works focus on the comparison of different blockchain development platforms [8,9,10]. As far as we know, this is the first work to evaluate and compare the blockchain technology with the current client/server model.

The major contributions of the paper are as follows:

• While the blockchain characteristics are suitable for implementing a healthcare system, these mechanisms are still costly considering execution time and amount of data transferred for ledger update.
• In spite of these costly mechanisms, notable performance can be achieved thanks to the blockchain model, especially in a patient-centric approach. In this approach, the patients and/or the physicians are constantly visiting the health records to construct a cohesive view from different hospitals for a better diagnosis or prognosis of diseases using artificial intelligence.

The rest of the paper is organized as follows. We overview the related work in Section 2. In Section 3, we introduce the principles of blockchain and its benefits to healthcare. We discuss the system model for the developed blockchain-based healthcare platform in Section 4. We present the experiments, and comparative analysis of client/server model versus blockchain using several application scenarios in Section 5. Section 6 concludes this paper.

2. Related Work

Traditionally, EHRs are employed by the healthcare organizations using a client/server architecture where the hospitals retain primary stewardship [11]. The medical data of a patient receiving treatment from multiple hospitals are scattered among different databases. To address this issue, several cloud-based eHealth applications are proposed [12,13,14,15,16,17]. However, privacy and security are the major concerns in the client/server and cloud-based models. Several research efforts address the privacy concern by managing the health data in cloud storage and recording the hash of the data in a special blockchain network [18,19,20,21,22,23,24,25]. Wang et al. [26,27,28,29,30,31,32,33] propose mechanisms for data integrity and authenticity of health records in a blockchain.

Several works [8,9,10,34,35,36,37,38,39,40,41,42,43] propose a blockchain-based healthcare data management system involving multiple hospitals. Azaria et al. [35] propose an interoperable blockchain-based application that enables allied health professionals to share patients’ health records. Dagher et al. [8] and Li et al. [36] propose an Ethereum-based blockchain framework for smart contract enabled medical data access. However, the blockchain networks in [8,35,36] use the energy-hungry and non-scalable Proof of Work (PoW) consensus mechanism [44,45,46]. Fan et al. [9] and Zghaibeh et al. [34] develop an EHR blockchain-based framework using Practical Byzantine Fault Tolerance (PBFT) consensus which is more energy-efficient and has better performance than PoW [47]. The healthcare data management systems proposed by [37,38,42,43] allow patients to retain the primary stewardship of the medical data because only the patients have the right to upload their data to the network. In these systems, the allied health professionals can only access the patients’ health record. Uddin et al. [10,39,40,41] propose a blockchain-based healthcare system with both allied health professionals and patients having data update authority. As far as we know, there is no work that compares the client/server and blockchain-based healthcare data management systems. In this paper, we implement a minimal blockchain-based healthcare platform and compare its execution time and amount of data transferred with the client/server system model for health records update and query. This is with increasing number of records and hospitals.

3. Blockchain Paradigm

Figure 1 shows the blockchain architecture. The architecture consists of the following layers [6]:

• Infrastructure layer: It includes the network nodes (known as participants), network modules and storage provisions. There are three types of participants: (1) simple which only performs the transactions, (2) validating which performs and validates transactions, and has a copy of the ledger and (3) mining which generates a new block and has a copy of the ledger.
• Platform layer: It includes modules for communication between the blockchain participants.
• Computing layer: It includes the underlying blockchain mechanisms for immutability, availability, finality, provenance, privacy and security.
• Application layer: It enables the blockchain participants to communicate with the application.

A blockchain network can be classified as either permission-less or permissioned [48]. The permission-less network (also called public) is open for anyone to join using a pseudo-name [49]. The users are encouraged to join the network for enhanced security by offering incentives. The ledger data in this network are visible to everyone. The permissioned network (also known as private) is an invitation-based network that allows only authorized participation. The visibility of the data is subject to access control rights as defined by the certificate authority. Considering the restricted network participation, the permissioned blockchain is more scalable and has a higher throughput compared to the permission-less.

3.1. Features of Blockchain

Blockchain is a peer-to-peer network that enables the stakeholders to share transactions with each other ensuring decentralization. It has the following features:

• Decentralization: A centralized third-party is not required as the ledger is updated after the majority of the participants in the network reaches a consensus.
• Immutability: A block in the ledger is hashed using its contents and the hash of the previous block. Consequently, any modification in a block will modify all the following blocks in the ledger. This makes the modification of a block in blockchain computationally difficult because the ledger is replicated among peers. In case data are entered by error, these data are corrected by issuing a new transaction.
• Transparency: Any change in the network is recorded as a transaction and can be viewed by all the participants maintaining a copy of the ledger.
• Traceability: The replication of any event in the network enables convenient tracing and audit trail.
• Trustless: Participants unknown to each other can perform transactions among each other as the consensus mechanism maintains the trust in the network.

3.2. Transaction Execution Mechanism

A transaction is an action that alters the blockchain ledger. It is application dependent and can be the transfer of monetary assets or execution of a smart contract. The transaction execution flow in blockchain is as follows:

• Transaction proposal: The user hashes the transaction using a hashing algorithm. The user’s private key is then used to encrypt this hashed value. The result is known as the digital signature. The digital signature along with the data is broadcasted to the network.
• Transaction validation: The transaction is validated by each validating node. This is by authenticating the user identity and ensuring the data integrity. The identity is authenticated by decrypting the signature and the integrity is ensured by hashing the transaction and comparing it with the decrypted result. The valid transaction is sent to the mining node.
• Block generation: The mining node (selected based on the consensus protocol used) verifies the valid transactions and groups them in a block in a way that the block size does not exceed a predetermined threshold. It hashes the transactions data, block version, timestamp and previous block’s hash value, and then hashes this hash value to obtain the hash of the block. The miner broadcasts the block to the network.
• Replication: The validating and mining nodes verify the validity of the block as part of the consensus protocol. Once valid, each node updates its copy of the ledger by appending the block.

3.3. Benefits to Healthcare

A blockchain-based healthcare platform provides the following benefits compared to the client/server approach:

• Fault tolerance: In a client/server-based system the patients’ health data are managed in a centralized database. Once the data are lost, they cannot be recovered. The replication characteristic of blockchain aids in fault tolerance.
• Data sharing: In the current client/server systems, a patient’s data are scattered over multiple hospitals’ databases. The sharing of data among different hospitals and medical organizations is a complex process. However, in a blockchain-based platform, the patients’ data recorded in the ledger is replicated among all the hospitals in the network.
• Interoperability: In a client/server-based system, each hospital stores the patients’ data in a different database using heterogeneous data formats and structures resulting in interoperability challenges. The synchronized and replicated ledger in the blockchain solves this issue.
• Avoidance of tests repetition: Currently the patients’ data are scattered across different healthcare providers, a patient often needs to repeat various laboratory and pathological tests. This not only incurs huge medical bills but also has adverse effects on the human body. The replicated blockchain ledger aids in avoiding medical tests.
• Security: The existing client/server-based system is prone to different cyber-attacks such as phishing and hacking. The stolen health records can be used to buy medical equipment by creating a fake ID or combining a patient number with a false provider to claim medical insurance.

  Table 1. Number of health record breaches and cost per breached health record between 2009–2019.

  Year	Number of Health Records Breached	Cost per Breached Record (USD)
  2009	0	204
  2010	6,006,063	214
  2011	13,407,992	194
  2012	2,808,042	233
  2013	7,401,928	255
  2014	12,946,972	308
  2015	113,270,000	363
  2016	27,300,000	355
  2017	5,138,179	380
  2018	13,947,909	408
  2019	41,335,889	429

  shows the number of health data records breached in America based on a report by the Health Insurance Portability and Accountability Act (HIPAA) [50], and the cost per breached health record based on a report by the Federal Bureau [51] between 2009–2019. This cost of health record breach includes the expenses for forensic experts, outsourcing hotline support, the value of customer loss and free subscriptions and discounts for future services [52]. The table shows a spike in the number of health records breached in 2015. This is due to the largest health records breach encountered so far by the health insurance company, Anthem, with almost 78.8 million individuals affected as the patients’ records were not encrypted [53]. The immutability feature of blockchain ensures data security.

4. A Blockchain-Based Healthcare System Model

We develop a basic blockchain platform for healthcare which provides minimal functionality to program healthcare transactions. This is using a permissioned blockchain network due to its advantages over the permission-less. The blockchain-based healthcare system model consists of participants such as patients, allied health professionals (doctors, nurses and pharmacists) and administrators; assets such as medical test data; and transactions such as health record update and query. Figure 2 shows the developed blockchain-based healthcare platform overview. It shows that the platform involves several hospitals and participants, including patients, connected to the blockchain network. A hospital includes different departments such as radiology and pathology laboratories as well as doctors, nurses, pharmacists and administrators. Let N represent total hospitals, K total participants and M total patients ($M<K$) in the network. Each hospital i, i ∈ {1, …, N}, maintains a copy of the ledger. A participant k, k ∈ {1, …, K} updates/queries the health record of a patient j, j ∈ {1, …, M}. For every healthcare transaction, the doctors and pharmacists act as full nodes and the administrator acts as a mining node. The developed minimal blockchain-based healthcare platform supports two types of transactions: (1) data update and (2) data query.

In the developed platform, in order to perform a healthcare transaction, the patient and/or allied health professionals send the transaction to the blockchain network. The doctors and pharmacists validate the transaction, and the validated transaction is sent to the administrator that acts as a miner. The administrator will generate the block for the transaction and broadcast it to all other hospitals’ administrators for replication. The execution flow for the healthcare transaction in the developed blockchain-based healthcare platform is shown in Figure 3. The selection of the miner and the ledger update is done using a consensus protocol.

The consensus protocol used in the developed blockchain-based healthcare platform is the PBFT [54]. The PBFT consensus protocol is selected over the mostly used Proof of Work (PoW) because the latter consumes more energy [44,45] and less throughput [46] than the former. In PBFT, the mining nodes are known as peer nodes. A leader node is selected from the peers in a round-robin manner. The leader receives all the transactions from the network participants. The transactions are validated and a block is generated. The block is then broadcasted to all the peers. Each peer node verifies the transactions in the block, recalculates the block’s hash and broadcasts the block’s hash to all other peer nodes in the network. Each peer node then updates its ledger with the block if it receives the same block’s hash value from 2/3 of the total peer nodes in the network.

A block in the ledger corresponding to a health record of a patient j primarily consists of the transaction with the workload $W_t\left(j\right)$ and the block’s hash with the workload $W_{bh}\left(j\right)$. The total workload of the block is represented by $W_b\left(j\right)$, which is the summation of $W_t\left(j\right)$ and $W_{bh}\left(j\right)$. When a participant k initiates an update/query transaction to a health record of patient j, the execution time ($E{T}_j$) is given by Equation (1).

$$E{T}_j=T{C}_j+T{P}_j$$

(1)

where $T{C}_j$ represents the communication time for transferring the total workload between the communicating nodes. It is calculated by dividing the total workload by the network bandwidth between the communicating nodes. $T{P}_j$ indicates the processing time which is calculated as the summation of the time taken to generate the digital signature of the transaction j, the time taken to generate the block by the leader node and the time taken to validate the hash of the block by the peer nodes. In this paper, we consider the communication time and neglect processing time. The communication time ($T{C}_j$) for the blockchain ledger update/query is calculated as stated in Equation (2).

$$T{C}_j=T{C}_{j(k,mine{r}_i)}+T{C}_{j(validato{r}_i,leade{r}_i)}+T{C}_{j(leade{r}_i,peer)}+T{C}_{j\left(peer\right)}+T{C}_{j(mine{r}_i,k)}$$

(2)

where $T{C}_{j(k,mine{r}_i)}$ represents the communication time for transferring the health record transaction of patient j between the participant k and the blockchain mining node i (hospital), $T{C}_{j(validato{r}_i,leade{r}_i)}$ indicates the transaction communication time between the validator and the miner of the mining node i, $T{C}_{j(leade{r}_i,peer)}$ denotes the block communication time between the leader of the node i and the peer nodes, $T{C}_{j\left(peer\right)}$ represents the block’s hash communication time between the peer nodes and $T{C}_{j(mine{r}_i,k)}$ denotes the communication time for the acknowledgement between the mining node i and the participant k. Equations (3)–(7) show the calculation of these terms.

$$T{C}_{j(k,mine{r}_i)}=\frac{W_t\left(j\right)}{C_{k,i}}$$

(3)

$$T{C}_{j(validato{r}_i,leade{r}_i)}=\frac{W_t\left(j\right)}{C_{validato{r}_i,leade{r}_i}}$$

(4)

$$T{C}_{j(leade{r}_i,peer)}=\sum _{i\in \left\{N\right\}-\left\{leader\right\}}\frac{W_b\left(j\right)}{C_{leader,i}}$$

(5)

$$T{C}_{j\left(peer\right)}=\sum _{h\in \left\{N\right\}-\left\{leader\right\}}\sum _{i\in \left\{N\right\}-\{leader,h\}}\frac{W_{bh}\left(j\right)}{C_{h,i}}$$

(6)

$$T{C}_{j(mine{r}_i,k)}=\frac{W_{ack}\left(j\right)}{C_{i,k}}$$

(7)

Similarly, the amount of data transferred ($W_{total}\left(j\right)$) to update/query the health record of a patient j can be calculated using Equation (8).

$$W_{total}\left(j\right)=2\ast W_t\left(j\right)+W_b^{\prime }\left(j\right)+W_{bh}^{\prime }\left(j\right)+W_{ack}\left(j\right)$$

(8)

where, $W_t\left(j\right)$ represents the amount of data transferred while broadcasting the transaction from the participant to the mining node. It is similar to the amount of data transferred between the validating and the mining node. Consequently, the term $W_t\left(j\right)$ is multiplied by 2 in Equation (8). It can be calculated using the size of the transaction. The term $W_{ack}\left(j\right)$ denotes the amount of data transferred between the mining node and the participant for acknowledgment and it is same as the size of the acknowledgment signal. $W_b^{\prime }\left(j\right)$ and $W_{bh}^{\prime }\left(j\right)$ in Equation (8) are calculated using Equations (9) and (10), respectively.

$$W_b^{\prime }\left(j\right)=\sum _{i\in \left\{N\right\}-\left\{leader\right\}}{W}_b\left(j\right)$$

(9)

$$W_{bh}^{\prime }\left(j\right)=\sum _{h\in \left\{N\right\}-\left\{leader\right\}}\sum _{i\in \left\{N\right\}-\{leader,h\}}{W}_{bh}\left(j\right)$$

(10)

where $W_b^{\prime }\left(j\right)$ indicates the amount of data transferred while broadcasting the block having workload $W_b\left(j\right)$ from the leader node to the peer nodes and $W_{bh}^{\prime }\left(j\right)$ represents the amount of data transferred between the peer nodes for consensus.

The blockchain-based healthcare system model enables the sharing of health records to provide more accurate and timely patient care. However, protecting the privacy, confidentiality and security of the records is crucial to effective data sharing [55]. Privacy refers to the rights of a patient to control their own data. Confidentiality refers to the obligations of allied health professionals and administrators who use patient’s data to maintain the privacy of patient identity. According to the title 42 of the Code of the Federal Regulations part 2 in the USA, the healthcare providers are required to obtain the patient’s written consent in order to share the health records with other medical organizations, even for treatment [56]. The Data Protection Act 1998 [57] and the Human Rights Act 1998 [58] provide a framework that governs a confidential usage and sharing of patients’ health records. These privacy and confidentiality laws can be reinforced using smart contracts and access control mechanisms. Furthermore, according to the HIPAA security rule [59], the integrity of health records should be ensured by employing proper encryption and authentication methods. In blockchain, security is established by signing every health transaction digitally using encryption mechanisms [60] and hash-chaining of transactions to reinforce data integrity.

In order to maintain data privacy and security, various blockchain participants have different role-based access rights to patients’ health records. A primary care health provider should a have full access to all patient’s health history, including patient’s identification such as name, contact details, photographic image, biometric details and medical record number; biological data such as height, weight and waist circumference; medical data such as body temperature, blood pressure, sugar level, diagnosis, treatment and allergies; laboratory and pathological results such as x-rays, magnetic resonance imaging, electrocardiography and computed tomography scans; and social data such as smoking habits, sleeping patterns, physical activity and diet plans. This provides the primary care with a cohesive view of the patient’s health records for a personalized care and artificial intelligence-based prognosis/diagnosis. For biomedical research purposes, another level of accessibility to patients’ data is defined. Biomedical researchers have access to anonymous data. Anonymity is reinforced via consent rules executed by the blockchain smart contracts.

5. Performance Evaluation

In this section, we analyze in which conditions the blockchain platform outperforms the client/server model by using two application scenarios. We evaluate and compare the execution time and amount of data transferred of these models for health records update and query with increasing number of health records and hospitals in the network.

5.1. Methods

5.1.1. Application Scenarios

We perform two experimental application scenarios to evaluate the performance of client/server and blockchain models: (1) health records update and (2) health records query.

In the first scenario, an allied health professional updates patients’ health records. We develop this scenario using the client/server model where the allied health professional updates the hospital local database that acts as the server, as shown in Figure 4. After successful data update, the server sends an acknowledgement to the allied health professional. We then measure the total execution time and the amount of data transferred for this process. We also developed the application using our minimal blockchain platform, in which case the allied health professional sends a health record to the blockchain network (Figure 4). The administrator of the mining node elected as the leader creates a block for that record and sends it to the administrators of the peer nodes for verification. Each administrator will verify the block and send the block’s hash to all other administrators in the network. An administrator updates the hospital’s copy of the ledger once it receives the same hash value from the majority of the administrators. Once the block containing the health record is added to the chain, an acknowledgement is sent back to the allied health professional notifying successful data update. The execution time and the amount of data transferred for this process are then measured.

In the second scenario, a patient and/or an allied health professional queries a health record. We develop this scenario using the client/server system model where the patient and/or allied health professional sends a health record query request to the hospital that has that record as shown in Figure 5. In response to the request, the hospital sends back the health records. We measure the total execution time and the amount of data transferred for this process. We also developed the application scenario using the minimal blockchain-based healthcare platform in which the patient and/or allied health professional sends the query request to the blockchain network (Figure 5). The administrator of the mining node elected as the leader creates a block for the query transaction and sends it to the other hospitals’ administrators in the network. Each administrator will verify the block and send the block’s hash to all other administrators in the network. An administrator updates the hospital’s copy of the ledger once it receives the same hash value from the majority of the administrators. Upon ledger update, the health record is forwarded to the patient or allied health professional. The allied health professional will retrieve the health record from its local copy of the ledger whereas the patient will retrieve it from the nearest hospital having a copy of the ledger.

5.1.2. Experimental Environment

To evaluate the client/server model and the blockchain-based healthcare platform, we implemented both network models. In the blockchain system model, we consider a block consisting of a single health record. This is to avoid the delay in the processing of health records in a situation when several records are grouped into a block that is limited by the block size. We use a health record of the size of 25.86 MB in the experiments. This is by considering that a record consists of images and texts of standard sizes, such as intraoral photography (1.64 MB), dental panoramic X-ray (0.85 MB), orthodontic cephalogram (1.20 MB) and skin lesion photography (22.17 MB) [61]. For the query application scenario, we used the block size of 1MB that represents a health record query. A block in blockchain consists of header and body. The body includes a health record in our experiments and the header consists of metadata information such as previous block’s hash, timestamp, Merkle root hash value, block number and version [6]. In our experiments, we use the standard block header size of 80 Bytes. The hashing algorithm used in the experiments is SHA-256 that generates a unique 256-bit output for a given input [62]. The selection of SHA-256 is due to its popularity among the blockchain implementations. To evaluate the impact of a dynamic healthcare data management system, we perform all the experiments for the client/server and blockchain system models with increasing number of health records (4000, 5000, 6000, 7000, 8000 and 9000) and increasing number of hospitals (10, 20, 30, 40, 50 and 100). We increase the number of records while keeping the number of hospitals constant at 10, and we increase the number of hospitals while keeping the number of records constant at 4000. The selection of the minimum number of records, i.e., 4000 represents the average patients’ records, visiting 10 hospitals (minimum number of hospitals in the experiments) per day, based on the Center for Health Statistics report [63]. We use Network Simulator NS3 [64] to develop the experiments.

5.2. Results Analysis

Figure 6 shows the execution time for updating health records using client/server and the developed minimal blockchain-based healthcare models with increasing number of health records. It shows that the execution time for client/server and blockchain models increase linearly with increasing health records. However, the execution time for the client/server model is less than that of blockchain. This is because of the consensus mechanism used in the blockchain for data validation and replication. The health record that has to be updated to the ledger is transmitted to all the hospitals having the copy of the ledger for validation. In addition, each peer node will transmit the block’s hash to the other peers in the network for consensus before appending it to the ledger. On the other hand, in the client/server approach, the data update request is transmitted to the hospital where the patient data exists. Consequently, the execution time of the client/server is less compared to blockchain approach for health records update. On average, the client/server approach takes 8.5 times less time for updating health records compared to the blockchain platform. Figure 7 shows the performance of client/server and blockchain models in terms of the amount of data transferred to update health records versus increasing number of records. It shows that the amount of data transferred in the blockchain platform is more compared to the client/server network. This is because each health record update request is broadcasted to all the peer nodes in the network by the leader node generating more data transfer. In addition, each peer nodes broadcasts the block’s hash to all other peers in the network increasing the data transfer. On average, blockchain model transfers 10 times more data compared to the client/server approach.

Figure 8 shows the execution time of client/server and the developed minimal blockchain-based healthcare models for querying health records from the databases with an increasing number of health records. It shows the execution time of blockchain is significantly less than the client/server approach. This is because in client/server, the data are retrieved from the server where the record exists, while in blockchain the data are retrieved from the local copy of the ledger. The execution time in the blockchain is only due to transmission of data query request to all the nodes in the network and to add the request as a transaction in a block upon consensus. On average, blockchain is 11.7 times faster compared to the client/server approach for querying health records. Figure 9 shows the amount of data transferred by client/server and blockchain models for querying health records from the databases with an increasing number of health records. It shows the amount of data transferred by the blockchain platform is more compared to the client/server approach. This is because of the PBFT consensus protocol used by blockchain. On average, blockchain transfers 1.1 times more data compared to the client/server approach for querying health records. However, the amount of data transferred by blockchain for ledger query (Figure 9) is less compared to the one for ledger update (Figure 7). This is because, for ledger update, a block includes a single health record to be updated, whereas, for ledger query, it includes a query request which is comparatively small in size.

Figure 10 shows the execution time of client/server and blockchain models for updating health records with an increasing number of hospitals. The relative performance is similar to that with an increasing number of health records (Figure 6). It shows that the blockchain model has more execution time than the client/server. On average, the client/server approach takes 13 times less time for updating health records compared to blockchain. Figure 11 shows the amount of data transferred by client/server and blockchain approaches for updating health records with an increasing number of hospitals. It shows the execution time of blockchain is more than the client/server approach due to the consensus protocol used by the former. On average, the amount of data transferred by blockchain increases 10 times compared to the client/server approach with every 10 hospitals increased.

Figure 12 shows the execution time for querying health records from the databases with an increasing number of hospitals. The relative performance is same when we increase the number of health records (Figure 8). It shows the execution time of blockchain is significantly less compared to that of the client/server approach. On average, blockchain is 8 times faster compared to the client/server approach for health records query. Figure 13 shows the amount of data transferred by client/server and blockchain models for querying health records from the databases with an increasing number of hospitals. It shows that the amount of data transferred by the client/server model is constant. This is because the number of health records queried is constant irrespective of the number of hospitals. The query will be performed to the hospital having the required record. However, the amount of data transferred by the blockchain platform for querying health records increases with the number of hospitals. This is because of the exchange of messages between the hospitals due to PBFT consensus. On average, the amount of data transferred by blockchain is 1.1 times more compared to the client/server model for 10 hospitals.

Table 2. Execution time for client/server and blockchain with increasing health records and hospitals.

		Average Increase in Execution Time (Hours)
		Health Records Update		Health Records Query
Increasing variable	Variable increasing factor	Client/server	Blockchain	Client/server	Blockchain
Number of health records	+1000	2.03	14.36	2.03	0.14
Number of hospitals	+10	4.42	57.44	4.42	0.58

shows the performance of client/server and blockchain approaches in terms of execution time for ledger update and query with increasing number of health records and hospitals. It shows that blockchain outperforms client/server for ledger query with both increasing number of health records and hospitals.

Table 3. Amount of data transferred for client/server and blockchain with increasing health records and hospitals.

		Average Increase in Data Transfer (GB)
		Health Records Update		Health Records Query
Increasing variable	Variable increasing factor	Client/server	Blockchain	Client/server	Blockchain
Number of health records	+1000	25.86	258.61	25.86	28.18
Number of hospitals	+10	0	1034.98	0	10.34

shows the amount of data transferred of client/server and blockchain approaches for ledger update and query with increasing number of health records and hospitals. The client/server approach outperforms blockchain in all application scenarios.

6. Conclusions

While many researchers investigated the application of blockchain for healthcare data management, however to our knowledge there is no evaluation of this new paradigm with the traditional client/server model. The client/server model suffers from the issue of data stewardship, data fragmentation, vulnerability, security and privacy. Blockchain paradigm has a strong potential to enhance health records management due to its immutability, security, privacy and data replication features. In this paper, we presented a comparative analysis of the two models for healthcare data management.

To analyze the performance of the models under study for updating and querying health records, we developed a basic healthcare platform based on blockchain paradigm. The results of the experiments show that the blockchain paradigm can lead to significant improvements. This is in particular in a patient-centric approach where the patients and/or the physicians are constantly visiting the health records to construct a cohesive view from different hospitals for a better diagnosis or prognosis using machine learning and artificial intelligence algorithms. Our results show that the health records query for the blockchain platform is 11.7 times faster compared with the client/server model with increasing number of health records. However, the blockchain-based system model is more costly than the client/server system model considering the execution time and the amount of data transferred whenever the transaction involves an update of the health record. This is due to the consensus mechanism involved in the ledger update. One of the future research directions is to implement the developed platform to evaluate its privacy and security.