BIoMT: A Blockchain-Enabled Healthcare Architecture for Information Security in the Internet of Medical Things

1  Introduction

The Internet of Things (IoT) has revolutionized almost every aspect of human life. Among several IoT-based smart applications, healthcare has gained great attention from academia and industries worldwide [1,2]. The healthcare industry is progressing exponentially with rapid advancements in smart manufacturing, artificial intelligence (AI), fast communication protocols, and robust cybersecurity mechanisms. As a modern application, the Internet of Medical Things (IoMT) has set new trends in the healthcare sector, such as smart sensors, wearable devices, advanced diagnoses, and medical procedures [3,4]. These technologies are highly capable of improving the quality of healthcare with economical and time-saving responses. Modern healthcare systems enable patients to monitor their health conditions via smart apps, providing remote consultations with doctors for diagnosis. Doctors can also prescribe medicines and offer medical interventions.

The IoMT is a great combination of medical equipment and apps capable of connecting to healthcare information technology systems via networking technologies. Connecting patients to their physicians and permitting the transfer of medical data through a secure network can minimize the pressure on healthcare systems. Most IoMT systems are usually built on centralized frameworks that provide fast information processing and data analysis facilities [5,6]. Despite having strong computational and management capabilities, the growth of IoMT networks has also increased security and privacy issues. With the rapid growth of IoMT networks, the security and privacy of valuable healthcare data have become a critical challenge [6]. Therefore, IoMT systems demand economical, lightweight, immutable, and robust security solutions. Single-point failure is one of the biggest disadvantages of centralized architectures, as it can expose the entire IoMT network to cyber criminals [7,8]. Therefore, centralized frameworks are not recommended for sensitive healthcare record services. Furthermore, the expansion of the IoMT network significantly increases the amount of sensing data, which may burden the centralized system and can further lead to the instability of the network.

These issues can be addressed using blockchain technology. A blockchain is a distributed ledger that facilitates the secure and immutable recording of transactions. It has several key characteristics, including immutability, anonymity, persistency, decentralization, and security [9,10]. It also enables the underlying communication frameworks to provide secure and trustworthy transactions with cryptographic primitives [11,12]. Blockchain is initially introduced for secure digital currency transactions. It is a decentralized and distributed ledger that stores data throughout its peer-to-peer network and addresses blocks using asymmetric cryptography. This ensures the accessibility of data at the block level for all parties concerned. Consequently, blockchain reduces the hazards associated with data centralization, including data tampering.

In the past few years, blockchain has gained much attention from academia and industry for healthcare applications. Blockchain technology offers secure and robust storage solutions to maintain valuable healthcare records. Although several blockchain-based frameworks have been proposed for healthcare applications, most do not provide access control mechanisms. Furthermore, the IoMT network contains hundreds of smart IoT devices that cannot process complex cryptographic algorithms because of their resource-constrained nature. To overcome these challenges, this paper presents a private blockchain-enabled framework for the IoMT. The main contributions of this paper are as follows.

•   This work realizes the capabilities of emerging blockchain technologies for the next generation of healthcare applications.

•   A decentralized, flexible, and private blockchain framework based on ciphertext policy attribute-based encryption is proposed for the IoMT that can perform several healthcare-related operations in a secure and trustworthy manner.

•   To analyze the effectiveness of the suggested framework, extensive experiments are conducted, and performance is analyzed in terms of system throughput and latencies.

The remaining article is organized as follows. Section 2 presents some state-of-the-art research in the area of blockchain-based healthcare frameworks. Section 3 briefly discusses the mathematical model of the proposed architecture. Section 4 presents the operation of multiple medical services through the proposed framework. Section 5 presents simulations and a discussion of the results. Finally, a brief conclusion is presented in Section 6.

2  Literature Review

This section presents some latest studies related to blockchain technology for healthcare applications. Recent advancements in blockchain technologies have enabled modern healthcare systems to provide authenticity, security, privacy, and trustworthiness in data sharing at multiple levels. Wang et al. [13] presented a hybrid blockchain framework to enhance the accuracy of diagnosis and medical treatment. The authors constructed a consortium blockchain to link patients, doctors, and hospitals for comprehensive healthcare data sharing. Wong et al. [14] developed a blockchain-enabled system for clinical trial processes. The authors utilized real data from clinical trials and conducted extensive experimentation on web portal applications. The experimental findings proved the effectiveness of the proposed system for efficient management and security of clinical trial data. Vazirani et al. [15] introduced a secure and interoperable blockchain infrastructure to maintain medical history. The proposed system maintains the ownership of patients without compromising the security and privacy of sensitive healthcare data. Access to a patient’s medical record is important in medicine prescription. Tanwar et al. [16] presented an access control privacy scheme with blockchain to enhance data accessibility among healthcare system participants. The authors implemented a Hyperledger-based framework for healthcare record sharing. Garg et al. [17] developed an advanced blockchain-based authentication protocol for the healthcare environment to address this issue. The proposed technique ensures secure key management between personal servers and medical devices. It facilitates authorized users to access medical data from the blockchain network in a secure manner. Experimental outcomes confirmed the higher performance of the suggested technique over several state-of-the-art studies.

Alqaralleh et al. [18] presented a hybrid image transmission approach for the IoMT using deep learning with a blockchain-based infrastructure. The suggested technique contains multiple processes, including data collection, hashing, secure transactions, and classification. First, researchers utilized elliptic curve cryptography and calculated its keys using the fruit fly optimization algorithm. After that, the hash values are encrypted using the neighborhood indexing sequence with burrow wheeler transform. In the final stage, a deep belief network is employed to diagnose the disease. Extensive experiments are conducted to identify the appropriate analysis of the supplied model’s outcomes, and the results are analyzed from several perspectives. Recent advances in IoMT have made it possible for smart devices to produce and send voluminous Electronic Medical Records (EMRs). However, an EMR has several sensitive properties that some unauthorized users might access for malevolent reasons. Wang et al. [19] presented an access control technique compatible with a blockchain-based transaction system. Moreover, they designed a privacy-preserving framework for access control. Researchers assessed their methodology using EMRs of 100,000 patients in real time. The experimental outcomes demonstrate that the proposed framework protects patient privacy more effectively than conventional access control mechanisms in smart healthcare environments. Egala et al. [20] introduced a novel blockchain-enabled distributed data storage system for the IoMT. The authors addressed the multiple issues of cloud-centric healthcare systems, including high storage costs, high latency, and single-point failure. Jin et al. [21] proposed an integrated cross-cluster federated learning and blockchain-based system for IoMT. The authors conducted extensive experiments to analyze the feasibility and efficiency of the suggested scheme. The proposed framework efficiently addressed the issue of high latency in the IoMT network. In another recent study, Akkaoui [22] developed a smart contract-based authentication framework for healthcare devices using blockchain technology. The proposed scheme addresses several security issues in traditional healthcare systems due to their centralized architecture. Singh et al. [23] designed a patient-centric blockchain system for healthcare record management. The authors conducted extensive experiments using the Hyperledger caliper benchmarking tool. The experimental outcomes confirm the effectiveness of the proposed architecture in terms of resource utilization, throughput, latency, etc.

In smart healthcare systems, security and privacy are the major issues in the IoMT paradigm. Blockchain can overcome a wide range of these issues in IoMT. Several research efforts have been made regarding blockchain deployments in healthcare applications. However, the aforementioned studies have a few limitations. First, most of the existing model’s utilized open-source frameworks for blockchain deployments. Using third-party services can occasionally create severe privacy issues in healthcare-based applications. Secondly, the breadth of the existing studies on healthcare operations is limited. Most of the studies focus only on the efficient recording of healthcare data; the feasibility of blockchain for other necessary medical operations is not deeply considered. Third, the evaluation of the proposed architecture in the context of IoMT is not discussed. To overcome the aforementioned issues, this paper presents a private, flexible, and lightweight blockchain-based framework for IoMT.

3  Design of the Proposed Architecture

Integrating blockchain technology with IoMT enhances the security of the overall healthcare architecture. The blockchain contains all the key essential features for a secure IoMT network. This article proposed a blockchain-based scheme for security, privacy, and trustworthiness in the IoMT systems.

3.1 Main Participants

The proposed scheme contains five main participants: private blockchain, hospital management services, cloud service providers, doctors, and patients. These modules are shortly described in the following.

1.    Private Blockchain: The proposed framework is based on a private network that only authorizes registered users to access the services. The distributed ledger is made up of a chain of cryptographically linked blocks. Each block contains a timestamp, hash value, hash value of the previous block, and Merkle roots. The authorized users can access and modify the ledger through smart contracts. These contracts consist of mathematical and logical function-based code that enables the users to access the blockchain without any third-party involvement. The consensus mechanism allows the new transaction to be added to the blockchain network. The proposed framework uses a proof of authentication (PoAh) consensus algorithm. The PoAh technique follows a conventional blockchain working mechanism with lightweight block verification [24]. Therefore, it is considered a lightweight and IoT-friendly consensus algorithm suitable for resource-constrained IoMT networks.

2.    Hospital Management Service (HMS): The main function of HMS is to provide hospital-related services to patients. HMS generates the master and public keys for the healthcare management system and private keys for the users and patients.

3.    Cloud Service Provider (CSP): CSP facilitates the storage of encrypted medical data by doctors, helps implement policy matching, and provides data storage services to users and patients. CSP also generates and publishes the decryption parameters to only access the stored data by authorized users.

4.    Doctors: The medical practitioners diagnose the patients, suggest suitable treatments for the diagnosed diseases, and generate an encrypted electronic medical record for all the patients.

5.    Users: Patients are the most important participants of the proposed framework. Users can register themself in a blockchain network through an authorization process, get doctor’s appointments, lab facilities, information about prescribed medicines, and can get access to their medical history.

Table 1 shows notations and descriptions of all parameters used in this paper.

3.2 Mathematical Model of the Proposed Security Scheme

Let’s initiate a security challenge between an opponent ϕ and an attacker η. The security challenge is described in the following.

1.    The opponent ϕ chooses the access structure T∗ and the user’s list C∗, and submits T∗ and C∗ to the attacker η.

2.    The B generates the master key δ and public key φ, sends φ to ϕ, and keeps δ secrete by using an initialization algorithm.

3.    Based on attribute sets At, ϕ continuously requests the private keys ψu from η. Meanwhile, B uses the key generation algorithm to return the private keys ψu.

4.    A sends two messages, χ1 and χ2, to η, where |χ1|==|χ2|. η chooses a user set u∈{0,1} at random and uses the encryption technique to encrypt χ using T∗ and C∗. ϕ is given the result ξp.

5.    ϕ requests the private keys as in step 3.

6.    ϕ estimates u′∈{0,1}. If u′==u, ϕ wins the challenge, and can be described as:

Adv(ϕ)=|pr[u′==u]−12|.

We can consider the suggested technique secure if all polynomial-time competitor has a trifling advantage in the given challenge. To put it another way, it can withstand plaintext attacks.

3.3 Mathematical Model of the Suggested Protocol

3.3.1 Overview

Some functions are defined to enable secure and traceable medical data exchange in IoMT.

1.    IDGen(passwrd)→addr ℏ: This function facilitates the users to generate an account address addrID through blockchain-enabled service.

2.    Setup(μ)→(φ,δ): This function aids in obtaining the φ and δ of the system by providing the security parameter μ.

3.    KeyGen(δ,Atui,addr ℏui)→(ϑui,ψui): This function accepts inputs such as δ, the attributes set Atui, and the user identity addr ℏui and produces a private key ψui as well as an intermediate parameter ϑui for user ui.

4.    Encrypt(φ,Δi,χi,C)→ξpi: This function accepts the φ, Δi, Mi, C, as inputs and returns a ciphertext ξpi associated with Δi.

5.    Delegate(φ,Atui,ϑui,ξpi)→(εui,ξi′): This function receives the inputs φ, Atui, ϑui, and ξpi, and returns εui and ξT′.

6.    Decrypt(ξpi′,εui,ψui)→χi: This function takes the inputs εui, ξT′and ψui, and returns the plaintext χi′.

7.    Trace(φ,Atui,ϑui)→(addr ℏui/⊥): This function accepts the inputs φ, Atui, and ψui, and returns the user’s address addr ℏui or ⊥.

8.    Re−Encrypt(φ,Δi,χi,C′)→ξi′: This function receives the φ, Δi, χi, C″ as inputs, and returns a ciphertext ξi′ associated with Δi.

9.    Tran_save(ψ,addr ℏ,content,timeStamp−amp): This function facilitates the users to store their valuable data in the blockchain network. It accepts a private key ψ for data signing, the transaction address of the sender addr ℏ, the real information to be stored, and the timeStamp.

The detailed operation is depicted in Fig. 1 and the process is elaborated in the following.

1.    The users that want to register them in the blockchain generate the account address as addr ℏui.

2.    The HMS generates the master keys δ and public keys φ by using the security parameter μ.

3.    The HMS transmits its attribute set Atui and addr ℏui to the HMS to generate (ϑui,ψui) by using the function KeyGen().

4.    The doctor creates a matching access policy Δi based on the requirements of the patients for medical data protection, then uses Encrypt() to build the ciphertext ξpi, which is subsequently sent to the cloud service provider.

5.    The user enquires about medical information by sending ϑui and the attributes set to CSP.

6.    CSP uses Delegate() to match policies. On success, it delivers the parameters for decryption and the ciphertext. After that, the ciphertext can be decoded using Decrypt().

7.    The HMS can track the decoding process by using the intermediate parameters retrieved through CSP.

8.    If the user is anomalous and involved in data leaks, then its address addr ℏ will be put on the cancellation list and forwarded to the doctor. The doctor encrypts the data again using ReEncrypt().

Figure 1: Flow of the proposed security protocol

3.3.2 Description of Protocol

The system protocol contains several stages that are described in the following.

a) System Setup: The setup (μ) function is used to generate φ and δ. First, two groups (G,GT) are selected on the order P. Then the function e:G×G→GT is defined, based on two generators g and ω. Define U={addr ℏui|1≤i≤n} as the group users and define attr={aj|1≤i≤m} as the global characteristic set. After that, the query list ω with the ϕ is generated with a random parameter and a addr ℏ. Finally, selecting H:{0,1}→G, a hash function, and selecting q1 and q2 randomly, where q1,q2∈ZΔ. After completion, the φand δ are returned.

v={q1,q2}(1)

φ={g,ω,h=ωq2,h=gq2,y=e(g,ω)q1,H()}(2)

b) Key Generation: When a patient ui interact with the hospital, the HMS selects the Atui and addr ℏui as inputs. HMS chooses the random parameter τ∈ZΔ according to the addr ℏui, and then computes ℏui(1)=gq1+τq2+q2τ,ℏui(2)={gτH(aj)}aj∈Lui,ℏui(3)=gaddrℏuiq2τ and ℏui(4)=hτ. For the moment, it writes the parameters addr ℏui, and τ into W. Then, it transmits ψui=(vui(3),ℏui(4)) and ϑui=(τ,ℏui(1),ℏui(2)) to user ui via a secure channel.

c) Data Encryption: The doctor generates medical data after interaction with the patient. Let χi represent the medical data generated by the doctor for patient ui. C represents the cancellation user list, where C=addr ℏj|1≤j≤n,|C|=r,rn, and S represent the authorized user list. The doctor encrypts χi through the φ and the system’s access policy Δi by performing the following procedures. Create Ti based on the Δi.

1.    Choose γ∈ZΔ, and computes ξ(1)Δ=χiyγ=χie(g,ω)aγ and ξΔ(2)=hγ.

2.    Let γ represent the root node’s value for the tree Ti. Allocate the root nodes and unallocated all its sub-nodes.

3.    For all leaf nodes aj∈T, the system computes ξaj,k(3)=ωγkH(aj)−1.

4.    Select a random entity for each participant belonging to the cancellation list. Since |C|=r, the system selects r numbers that represent {tj∈ZΔ}1≤j≤r and satisfy γ=∑j=1rtj.

Then, the ciphertext is defined as

ξΔi=(ξΔ(1),ξΔ(2),{ξaj,k(3)}aj∈Ti,{ξuj(4)}uj∈C,{ξuj(5)}uj∈C)(3)

d) Decryption Delegation: When a patient sends a request to access healthcare services, he/she will send Lui and ϑui to the CSP. The CSP provides the decryption parameters and cipher text to the user through the decryption delegation function. The CSP chooses the minimum set L′ that fulfill the Ti. For each attribute aj∈At′, it calculates.

ϑui=e(ℏui(i),ξΔ(2))∏aj∈At,i=indexe(ℏi(2),ξaji(3))li(0)(4)

Each attribute in the policy corresponds to a sub-secret sharing value, parameter γ can be computed according to ∑i=0t−1γili(0). In other words, it can obtain εui by computing e(ℏi(2),ξaji(3))li(0). For the moment, the CSP integrates the ξΔi with r τ to generate the new ciphertext

ξTi′={τ,ξΔi}(5)

and sends εui and ξTi′ to the user.

e) Decryption: The user executes the decryption process after receiving (εui,ξTi′). If addr ℏui∈ C, the algorithm is terminated. The plaintext can be obtained if addr ℏui∈S. For each aj∈At′, the system calculates

ε′=∏j=1,addr ℏuj∈Cr[e(ℏuj(3),ξuj(4))e(ξuj(5),ℏuj(4))]1addr ℏui−addr ℏj(6)

The decryption key ε can be computed using εui and ε′. The ciphertext can be decrypted as:

ε=εuiε′(7)

χi′={τ||ξΔ1ε}={τ||χi}(8)

After receiving (εui,ξTi′), The only user ui who satisfies addr ℏui∈S can access the decryption key.

f) Anomalous User Tracking: The HMS validates ϑui by determining whether the relevant user’s address addr ℏ can be found in list W. It employs τ to analyze the decoding behavior and to give referential elements for tracing down the users who illegally disseminated decryption keys. As a result, an invalid ϑui indicates that this user is not required to be tracked. There are two parts to the tracking process: verify and query.

Verify_phase. The HMS accepts the input parameters that include the attributes set of users Atui, φ and ϑui to verify the validity of ϑui, and then calculates Cs1 and Cs2. It can be described as:

Cs1=e(ℏ,h),Cs2=y⋅e(ℏ(1),h2,ωH(ai)aiϵLui−1)(9)

If Cs1 = Cs2, then it indicates the successful process of verification and nominates the user as an authorized user.

Query_phase: The ϑui is considered valid after the completion of a successful verification process. It can obtain the user’s addr ℏ from the list W through τ and then generate the addr ℏ corresponding to τ. Otherwise, output ⊥.

g) Data Re-encryption: As the cancellation list C was modified, only the items of {ξuj4}uj∈C and {ξuj5}uj∈C′ are required to be updated according to the new C′ in ξΔi. After adding an anomalous user address addr ℏe to the cancellation list, it should add ξe(4)=hte and ξe(5)=h1addr ℏete to {ξuj4}uj∈C′ and {ξuj5}uj∈C′, respectively. The newly generated ciphertext ξTΔi″ is described as

ξΔi″=(ξΔ(1),ξΔ(2),{ξaj,k(3)}aj∈Ti,{ξuj4}uj∈C′,{ξuj5}uj∈C)(10)

3.4 Consensus Algorithm

A lightweight consensus algorithm (PoAh) incorporated into the blockchain to verify and add new transactions to the blockchain. This algorithm adheres to conventional communications, with updates occurring only during block validation [25]. The network’s precipitants, acting independently, create the initial transactions with the data and then combine them into a block. The public and private keys generated in the aforementioned steps are used here. Before the node broadcast, the source node signs the block with its private key ψ and makes its public key φ available to everyone. For block validation, there must be authorized nodes in the network. These nodes are put into service with just enough trust to qualify as authorized nodes, whereas all other nodes have no trust. After a block has been completely authenticated, the authorized nodes will receive a trust value.

Once the authorized node receives the block, it is analyzed to determine its validity by obtaining the originating node’s public key φ. Due to the asymmetric cryptography characteristic, the signature can only be verified using the public key. Furthermore, because of the discrete log problem properties, it is impossible to determine the value of ψ while other values are known. In the second evaluation phase, the authorized node checks the MAC value once the signature has been verified. After verification, the reliable nodes will send out the block and the PoAh identity to the rest of the network. After that, the PoAh data in the block is sought by specific network nodes so that they may be appended to the chain. At last, nodes compute a hash of the block and store it to create a link to the following block; the previous hash value is also stored in the current block. Algorithm 1 details the steps involved in the PoAh process.

4  Medical Services in the Proposed Architecture

This proposed architecture can perform several healthcare-related operations, including patient appointments, medical checkups, diagnostic services, and treatments. Furthermore, all these healthcare services are interconnected with each other. An overview of the blockchain-enabled healthcare system is presented in Fig. 2. This section briefly describes each module.

Figure 2: Overview of blockchain-enable services in IoMT

4.1 Patient Appointment

If a patient wants to make an appointment with a doctor, they would first submit a transaction proposal with their details such as name, gender, ID number, and age. The Blockchain API will execute this transaction and provide the user with a list of medical specialists. After selecting a medical specialist, the API forwards this request to the relevant doctor. If the doctor confirms their availability, the API informs the patient about the available date and time. After final confirmation from the patient, the blockchain submits a transaction proposal and executes a consensus algorithm. If the consensus is successful, a new block is generated and added to the blockchain. After a successful operation, the blockchain generates an appointment receipt and sends it back to the patient. The receipt is encrypted, and a patient can extract the information using their private key. The flow of the appointment process is summarized in Algorithm 2.

4.2 Medical Checkup

For a medical checkup, the patient is required to visit the hospital on a specific date and time. First, a receptionist verifies the appointment details from the blockchain API. This is followed by payment confirmation details from the patient’s bank account or insurance balance. Once everything is confirmed, the API will update the database, and the patient will move toward the OPD, where a medical specialist will perform the necessary checkup. The doctor can also acquire the patient’s medical history from the blockchain API. Based on the checkup, the doctor can prescribe medicine or suggest some laboratory tests for further diagnosis. Once a checkup is completed, the doctor will update the record by submitting a transaction proposal to the blockchain API. After the successful execution of the consensus algorithm, the blockchain updates the record and issues an acknowledgment receipt that can only be accessed by the doctor, patient, or another authorized party. The flow of the medical checkup process is summarized in Algorithm 3.

4.3 Diagnostic Services

The patient must visit the diagnostic center if the doctor recommends laboratory tests such as blood, urine, X-rays, CT scans, etc. First, the diagnostic center will acquire details of the recommended tests from the blockchain API by using the patient’s ID. Subsequently, the additional payment details for the specific test will be confirmed. Once the payment has been confirmed, the patient moves toward the laboratory. The laboratory staff will collect the required samples for the test. The time of each test result can vary according to the requirements. After completion of the process, the laboratory staff will update the blockchain API with the diagnosis results. All these results are in the form of encrypted reports. Only relevant doctors and patients can access these reports’ contents using their private keys. The flow of the medical checkup process is summarized in Algorithm 4.

4.4 Medical Treatment

The doctor will decide on the medical treatment based on the diagnosis reports. This treatment can take several forms, according to a patient’s health condition. First, a doctor can prescribe the medicine for a limited duration. In this case, the doctor will update the blockchain with their recommendation. Next, the patient must visit a pharmacy to collect the medicines. The pharmacy will have a detailed record of each medicine, including the type, company, manufacturer, expiry date, and prices. After a successful payment process, the pharmacy will issue the medicines and update the blockchain record that will be accessible to both the doctor and the patient. In the second case, the doctor can suggest admitting the patient to the medical ward for continuous care and treatment. The ward administration will allocate a specific room and bed to the patient and update the database. The record of daily checkups, medicine, and healthcare procedures will be continuously updated on the blockchain for the doctor’s access. In the third case, the doctor may suggest minor or major surgery for the patient. First, the patient will be allocated a specific surgery date. All the pre-surgical and post-surgical procedures will be updated in the blockchain database. After surgery, the patient’s health status and prescribed medicines will be updated in the blockchain for future diagnosis and treatment. The flow of the medical treatment process is summarized in Algorithm 5.

5  Experiments and Performance Analysis

All the experiments are conducted using a Dell Inspiron Compact Desktop computer system with Intel® Core™ i7-11700 processor, 16 GB RAM, and Windows 10 operating system. The proposed blockchain framework is constructed in Python, JavaScript, and HTML languages by using open-source libraries. The performance of the proposed architecture is analyzed in terms of transaction throughput and latency.

Throughput and latency have always been useful performance indicators for assessing blockchain-based systems. Transaction throughput indicates the number of successful transactions per second from the first transaction deployment time. Latency indicates the difference between each transaction’s completion time and deployment time. In our experiments, the average transaction throughput and latencies are computed for all operations with varying transactions. In the first phase of experiments, we analyze the blockchain’s read/write performance for the patient appointment process. The transactions are divided into five groups that contain 100, 250, 500, 750, and 1000 transactions. A comparative analysis of transaction throughput and latencies for the appointment process is presented in Fig. 3. In data reading, the throughput is almost linearly increased with the number of transactions. The maximum throughput was recorded as 96 TPS and 924 TPS for the smallest and largest groups of transactions. For middle groups, the throughputs were recorded as 232 TPS, 474 TPS, and 698 TPS, respectively. The read performance indicates that the latency is recorded between the interval of 19 ms to 45 ms. Results indicate that the overall latency is increased with the increase in the number of transactions. The data writing process decreases throughput compared to the reading process. The maximum throughput is recorded as 155 TPS for the largest group of transactions. The latency for the writing process is recorded between 3 ms to 13 ms. Experimental outcomes indicate that the proposed blockchain scheme achieved higher throughput for reading operation than for write operation. The suggested scheme indicates the lower latency for both read and writing operations suitable for resource-constrained IoMT networks.

Figure 3: Blockchain read/write performance for the patient appointment process

In the second phase of experiments, we analyze the blockchain’s read/write performance for the medical checkup process. Again, the transactions are divided into the same groups. A comparative analysis of transaction throughput and latencies for the medical checkup process is presented in Fig. 4. Data reading increases throughput with the number of transactions. The maximum throughput was recorded as 79 TPS and 910 TPS for the smallest and largest groups of transactions. For middle groups, the throughputs were recorded as 198 TPS, 395 TPS, and 710 TPS, respectively. The read performance indicates that the latency is recorded between the interval of 28 ms to 74 ms. Results indicate that the overall latency is increased with the increase in the number of transactions. The data writing process decreases throughput compared to the reading process. The maximum throughput is recorded as 132 TPS for the largest group of transactions. The latency for the writing process is recorded between 5 ms to 17 ms. Experimental outcomes indicate that the proposed blockchain scheme achieved higher throughput for reading operation than for write operation. The suggested scheme achieved a lower throughput and higher latency for the medical checkup process compared to the patient appointment process.

Figure 4: Blockchain read/write performance for medical checkup process

In the third phase of experiments, the blockchain’s read/write performance is analyzed for diagnostic services. The same groups of transactions are also maintained here. A comparative analysis of transaction throughput and latencies for diagnostic services is presented in Fig. 5. The results indicate that the diagnostic service is the heaviest operation as compared to other operations. In data reading, the throughput is increased with the number of transactions. The maximum throughput was recorded as 83 TPS and 723 TPS for the smallest and largest groups of transactions. For middle groups, the throughputs were recorded as 201 TPS, 474 TPS, and 705 TPS, respectively. The read performance indicates that the latency is recorded between the interval of 14 ms to 69 ms. Results indicate that the overall latency is increased with the increase in the number of transactions. The data writing process decreases throughput compared to the reading process. The maximum throughput is 167 TPS for the largest group of transactions. The latency for the writing process is recorded between 5 ms to 18 ms.

Figure 5: Blockchain read/write performance for diagnostic service process

In the final phase of experiments, the blockchain’s read/write performance is analyzed for medical treatment services. The same groups of transactions are also maintained here. A comparative analysis of transaction throughput and latencies for diagnostic services is presented in Fig. 6. The throughput is increased with the number of transactions in data reading. The maximum throughput was recorded as 63 TPS and 872 TPS for the smallest and largest groups of transactions. For middle groups, the throughputs were recorded as 231 TPS, 467 TPS, and 622 TPS, respectively. The read performance indicates that the latency is recorded between the interval of 16 ms to 56 ms. Results indicate that the overall latency is increased with the increase in the number of transactions. In the data writing process, throughput is decreased as compared to the reading process. The maximum throughput is 149 TPS for the largest group of transactions. The latency for the writing process is recorded between 2 ms to 16 ms. Experimental outcomes indicate that the proposed blockchain scheme achieved higher throughput for reading operation than for write operation.

Figure 6: Blockchain read/write performance for the medical treatment process

Experimental outcomes indicated that the overall performance of the proposed blockchain architecture is good. Furthermore, the suggested scheme attained a high throughput and lower latency for all the discussed healthcare services, making it the best suitable for large-scale deployment in the IoMT networks. To further analyze the effectiveness of the proposed scheme, a brief comparison with the state-of-the-art is presented in Table 2.

6  Conclusion

This paper presented a blockchain-based framework for secure and trustworthy services on the IoMT. The proposed framework is based on a private blockchain network that ensures the security and decentralization of IoMT using attribute-based cryptography and PoAH consensus algorithm. As a result, several healthcare operations, including patient appointments, medical checkups, diagnostic services, and treatments, can be performed securely and trusted. The proposed architecture is evaluated for all healthcare services throughput and latency. The experimental results proved the optimum performance of the proposed architecture. For future endeavors, the performance of the suggested scheme can be further enhanced by incorporating the hardware accelerators in the existing network.

Funding Statement: The Deanship of Scientific Research (DSR) at King Abdulaziz University (KAU), Jeddah, Saudi Arabia has funded this project, under grant no. (RG-91-611-42).

Conflicts of Interest: The authors declare they have no conflicts of interest to report regarding the present study.