Received: 25 June 2024 Revised: 9 September 2024 Accepted: 11 September 2024 IET Communications

DOI: 10.1049/cmu2.12839

ORIGINAL RESEARCH

HealthChain: A blockchain-based framework for secure and

interoperable electronic health records (EHRs)

Ghassan Husnain1 Zia Ullah2 Muhammad Ismail Mohmand3 Mansoor Qadir1

Khalid J. Alzahrani4 Yazeed Yasin Ghadi5 Hend Khalid Alkahtani6

1
Department of Computer Science, CECOS Abstract
University of IT and Emerging Sciences, Peshawar,
Currently, there is no unified Electronic Health Record (EHR) system connecting major
Pakistan
2
healthcare organizations such as hospitals, medical centers, and specialists. Blockchain
Department of Computer Software Engineering,
University of Engineering and Technology Mardan,
technology, with its unique features, provides an ideal platform for developing a large-scale
Mardan, Pakistan electronic health record system. In this article, the authors introduce HealthChain, a novel
3
Department of Computer Science, Sarhad blockchain-based secure EHR system that integrates advanced encryption techniques, a
University of Science and Information Technology, robust consent management system, cross-platform interoperability, and enhanced scala-
Peshawar, Pakistan bility. Unlike existing EHR systems, HealthChain allows patients to have comprehensive
4
Department of Clinical Laboratories Sciences, control over their health data, ensuring that access is strictly regulated according to
College of Applied Medical Sciences, Taif University,
their preferences. The experimental results demonstrate several significant improvements
Taif, Saudi Arabia
5
over traditional EHR systems. HealthChain reduces data access times by 30%, and its
Department of Computer Science and Software
Engineering, Al Ain University, Abu Dhabi, UAE
interoperability rate with various healthcare systems is 40% higher than that of other
6
blockchain-based EHR solutions. Security is greatly enhanced, with HealthChain experi-
Department of Information Systems, College of
Computer and Information Sciences, Princess encing 50% fewer data breaches due to its advanced encryption and smart contract-based
Nourah bint Abdulrahman University, Riyadh, Saudi access controls. Moreover, patient satisfaction has increased by 35% as a result of better
Arabia control and access to their health records. These findings highlight HealthChain as not
only a feasible and effective solution for managing health records but also a significant
Correspondence
Hend Khalid Alkahtani, Department of Information
advancement over existing systems.
Systems, College of Computer and Information
Sciences, Princess Nourah bint Abdulrahman
University, Riyadh 11671, Saudi Arabia.
Email: [email protected]

Funding information
Princess Nourah Bint Abdulrahman University,
Grant/Award Number: PNURSP2023R384

1 INTRODUCTION The existing health information technology landscape is

currently highly diverse and non-unified. Health boards use
The healthcare sector has been experiencing steady growth over different IT systems for processing, storing, and sharing elec-
the past decade, and it is expected to continue. According to tronic medical data, with varying levels of maturity [5, 6]. Patient
National Health Statistics, the number of discharges from pub- health records are fragmented due to poor interoperability and
lic hospitals will increase by an average of 5.80% annually from long response times for data access requests [6]. Consequently,
2018 to 2022 [1, 2]. With the expansion of the healthcare sec- patients need to provide their health information to new Gen-
tor, treatment costs and processing times increase, straining the eral Practitioners (GPs) or healthcare providers. Health data are
existing infrastructure. As healthcare demand rises, organiza- distributed across multiple storage systems, preventing health-
tions are seeking IT solutions that improve productivity, reduce care providers from accessing accurate health information [7].
treatment costs, and enhance the quality of care [3, 4]. Patient consent is required to transfer medical information from

This is an open access article under the terms of the Creative Commons Attribution-NonCommercial-NoDerivs License, which permits use and distribution in any medium, provided the
original work is properly cited, the use is non-commercial and no modifications or adaptations are made.
© 2024 The Author(s). IET Communications published by John Wiley & Sons Ltd on behalf of The Institution of Engineering and Technology.

IET Commun. 2024;1–23. wileyonlinelibrary.com/iet-com 1

 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
2 HUSNAIN ET AL.

one provider to another, but there is no centralized electronic and standards hinder the effective sharing of health data due
consent management platform [6]. to the lack of interoperability in existing systems. Especially in
To address these challenges, the Ministry of Health has pro- an emergency situation, this fragmentation makes it difficult to
posed a nationwide EHR sharing system [6, 8]. The term EHR aggregate and examine patient data [17]. Authorized personnel
refers to “an electronic record of patient health information attacking cloud servers pose the greatest security risks, surpass-
generated during patient encounters in any setting.” Many stud- ing external cyber attacks [1]. EHRs may be lost when deleted
ies have attempted to improve health records management from hospital databases, which underscores the importance of
and sharing but have encountered significant obstacles. Azaria a tamper-proof system that can only be accessed by authorized
et al. [9] developed MedRec, the first functional shared EHR individuals. It is necessary to explore alternative technologies to
based on blockchain. However, since the blockchain is pub- complement traditional database management systems, which
lic, MedRec raises privacy and confidentiality concerns. While meet some requirements but fall short of others [18].
FHIRChain uses cryptography to enhance data security, it faces According to [19] their system is similar to MedRec [9],
challenges regarding seamless interoperability [10]. Additionally, allowing patients to share their health records, but it lacks a
these systems struggle with scaling, as they must process more mechanism for revocation of consent. Meanwhile, MedShare
transactions at a slower speed and higher cost [11]. uses blockchain to control access and monitor cloud-stored
Our paper presents HealthChain, a secure EHR based on health data; however, it faces scalability issues.
blockchain technology. Health IT fragmentation can be resolved With HealthChain, we address these problems by stor-
by a distributed, interconnected data storage framework pro- ing healthcare records on the blockchain securely, ensuring
vided by blockchain technology. HealthChain offers several immutability, encryption, and restricting access only to patients
significant advantages over existing EHR systems, not merely and their doctors. In addition, HealthChain implements a con-
due to its use of blockchain. These benefits include advanced sent management system at the healthcare provider level, where
encryption techniques that ensure robust data security, a robust patients can dictate how and when their records can be accessed.
consent management system that provides patients with fine- In addition, HealthChain places a high priority on usabil-
grained control over who can access their records and how, ity. Our authentication server safeguards critical cryptographic
and cross-platform interoperability that facilitates seamless data materials, preventing unauthorized access to or loss of records.
sharing across diverse healthcare platforms.
However, implementing blockchain in healthcare is not
without its challenges. Scalability remains a critical issue, as 1.2 Contributions
blockchain networks must handle a high volume of transac-
tions without compromising performance [12]. Interoperability Our study proposes the use of Ethereum blockchain as a frame-
with existing healthcare systems is another significant challenge work for efficient data sharing, health records management, and
[13], requiring blockchain solutions to integrate seamlessly with access control. HealthChain eliminates bottlenecks in existing
legacy systems and adhere to industry standards such as HL7 systems and minimizes single points of failure by introducing a
FHIR. Additionally, maintaining the privacy of sensitive health distributed ledger platform. In HealthChain, records are syn-
data within a public or permissioned blockchain framework chronized in different formats and are self-governed. Health
presents complex technical hurdles [3]. records can be encrypted and access controlled by patients. In
In this paper, we introduce HealthChain, a blockchain-based this paper, we make the following contributions:
framework designed to overcome these challenges. HealthChain
integrates advanced encryption techniques, a robust consent ∙ Introduction of HealthChain, an innovative blockchain-
management system, and cross-platform interoperability, all based Electronic Health Record (EHR) system. With
within a scalable architecture. Our approach not only secures HealthChain, patients gain secure access to their medical data
EHRs but also ensures that they are easily accessible to autho- while seamless consent capturing is ensured.
rized users while maintaining the privacy and integrity of ∙ Implementation of cutting-edge data protection measures
patient data. within HealthChain, including advanced encryption schemes
and secure access protocols, guaranteeing the confidentiality
and integrity of medical data.
1.1 Motivation ∙ Proposal of a groundbreaking key storage framework
designed to revolutionize usability in HealthChain. A crypto-
Currently, healthcare is plagued by a number of critical graphic authentication server is used to store cryptographic
drawbacks, mainly stemming from centralized patient records material, enhancing user convenience and ensuring crypto-
storage. In a system similar to MedRec [9], Dubovitskaya et al. graphic assets are secure.
[14] suggested a mechanism for managing consent revocations,
but without allowing patients to share health records. MedShare
uses blockchain as a platform for controlling and monitoring 2 ORGANIZATION OF THE PAPER
cloud-based health data, despite scalability problems.
Moreover, electronic health record (EHR) [15, 16] are vulner- The rest of this paper is organized as follows. Section 3 provides
able to cyber threats, ranging from ransomware attacks to major an overview of related work in the field of blockchain-based
breaches like the Equifax incident. Additionally, varying formats EHR systems. In Section 4, we present various use case
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 3

scenarios that demonstrate the practical applications and

requirements of the proposed HealthChain system. Section 5
details the system architecture and model, outlining the key
components and interactions within HealthChain. Section 6
describes the methodology, including the blockchain imple-
mentation, security protocols, and HealthChain architecture. In
Section 9, we discuss the experimental setup and performance
analysis, highlighting the results of our simulations. Section 10
presents the security analysis of the proposed model, address-
ing potential threats and vulnerabilities. Finally, Section 11
concludes the paper with a summary of our findings and
suggestions for future work.

3 RELATED WORK

3.1 Blockchain technology overview

Blockchain [20] is a distributed, tamper-proof, and chronologi-

cally secure system that accumulates and keeps track of orders
of sequential transactions [21]. A distributed ledger is a list of
records that continuously add information to it. Distributed
FIGURE 1 Structure of blockchain network.
ledgers resist censorship or suppression because the ledgers are
controlled by no single entity but by all the peers participating in
the ledger. A blockchain is an immutable data chain where every Similarly, [23] discuss a privacy-preserving healthcare mon-
node has the same order. In distributed storage systems like itoring system using blockchain. The study emphasizes the
Blockchain, data consistency is guaranteed by a consensus algo- importance of secure data exchange in patient monitoring but
rithm. Cryptographic hashes connect records in a blockchain. does not fully address scalability challenges or the need for
A Blockchain-based technology encourages peer computations integration with various EHR systems, which could hinder the
towards consensus [6]. With its immutability and decentraliza- widespread adoption of such systems in large-scale healthcare
tion, Blockchain is an increasingly attractive technology for the environments. Another study by [24] explores a blockchain-
untrusted peer-to-peer network [21]. based privacy-preserving scheme for large-scale health data,
A digital signature chain is the essence of an electronic coin. focusing on secure data management. While effective in pri-
A hash of the previous transaction is digitally signed by each vacy protection, this work does not delve into cross-platform
member and the public key of the next member is added as interoperability or large-scale deployment scenarios. Moreover,
well. Verifying the chain of membership can be accomplished [19] developed a blockchain framework for patient-centered
by comparing signatures. Figure 1 illustrates the structure of health records, emphasizing evaluation and proof-of-concept
blockchain. Block headers, Merkle roots, block data, and the studies. However, this work remains largely conceptual, with
current block’s hash value are all transactions. limited discussion on real-world implementation challenges
and scalability.
MedRec, developed by MIT, is a pioneering project in this
3.2 Blockchain technology in healthcare field. Health records can be shared and maintained using
MedRec, a decentralized distributed ledger. Interoperability, lim-
In the past few years, blockchain technology has been exten- ited access to medical data, patient agency, and fragmentation
sively studied for its potential applications in healthcare [5], of data are among the key issues addressed. To ensure secure
which has been the subject of extensive study. Electronic health and accountable real-time data sharing, MedRec [9] uses smart
record (EHR) can be made more secure, private, and inter- contracts and proof-of-work as its consensus algorithm.
operable with blockchain. Recent research has explored the Blockchain applications in healthcare have been explored
integration of blockchain technology with advanced machine in recent studies, building on these foundational works. A
learning models and privacy-preserving techniques to enhance blockchain-based system similar to MedRec has been suggested
healthcare systems. For instance, [22] present a framework that in [9] but it does not provide a mechanism for managing revo-
combines blockchain with deep belief networks and ResNet cation of consent. Blockchain-based MedShare [25] focuses on
models to secure cyber-physical systems in healthcare. This securing cloud-based health data and monitoring access con-
approach shows significant promise in enhancing security trols, but it faces scalability issues. Several other frameworks
through AI integration, but it is primarily focused on spe- have also been proposed besides MedRec. The FHIRChain,
cific cyber-physical scenarios, limiting its applicability to broader developed by [26] aims to improve clinician interoperability. A
healthcare contexts. public key cryptographic framework manages user identities and
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
4 HUSNAIN ET AL.

stores data pointers on the blockchain. Public and private keys cia and Johnson [3] compared blockchain-based and traditional
are assigned to each user for digital signatures and encryption EHR systems, highlighting blockchain’s superior data integrity
of data. With FHIRChain [14], a token-based permission model and security, though technical deployment challenges were not
addresses the limitations of permissionless blockchain systems. fully addressed.
The contents of the data are encrypted using the user’s public Overall, these studies contribute to the growing body of
identity key, making it accessible only to those with the corre- knowledge on blockchain-based EHR systems, but they often
sponding private key. An encrypted token is created by signing lack comprehensive discussions on performance, scalability, and
the data pointer with the sender’s private key and encrypting integration with existing healthcare infrastructures. Our work
it with the receiver’s public identity key. This token can then be addresses these gaps by providing in-depth experimental results
decrypted by the receiver using their private key, and the sender’s and demonstrating how HealthChain improves both data access
public key can be used to verify the sender’s identity. times and system interoperability by 30% and 40%, respectively.
In addition, [19] introduced a privacy-preserving blockchain In [38], proposed a blockchain-based framework to address
framework for healthcare data, emphasizing the need for secure EHR interoperability issues. The study suggests that blockchain
and efficient data sharing among stakeholders. In [26] pro- enables seamless data exchange between disparate healthcare
posed Healthcare Data Gateway, a blockchain-based healthcare systems. However, it lacks an in-depth discussion of scala-
data management system that ensures data integrity and patient bility challenges, particularly in handling large-scale healthcare
privacy through advanced cryptographic techniques. Despite transactions, which are critical for real-world deployment.
these advancements, several critical issues remain unresolved In [39], a comprehensive review of blockchain’s security ben-
in existing systems. Centralized databases in current healthcare efits for EHR management is provided. The paper emphasizes
infrastructures are prone to security risks [27], as they present an the use of encryption algorithms like AES-256 and consensus
attractive target for attackers. The increasing incidence of cyber mechanisms to protect patient data. Despite addressing secu-
threats, such as ransomware and data breaches, underscores the rity thoroughly, the paper fails to analyze the cost implications
vulnerability of centralized health data repositories. Moreover, of blockchain integration in healthcare, leaving its feasibility in
the lack of interoperability among diverse health IT systems practical scenarios uncertain.
hampers the effective aggregation and sharing of patient data, In [40], presents a blockchain-based privacy-preserving EHR
particularly in emergency situations. system using zero-knowledge proofs, which helps in keep-
In [25] proposed a secure time protection scheme for IoT ing patient data confidential while allowing authorized access.
data credibility using blockchain, highlighting the importance of Although the system is effective for small to medium-sized
data integrity and security in healthcare applications. Reference networks, it struggles with computational overhead in large,
[10] integrated blockchain for data sharing and collaboration in national healthcare networks, limiting its scalability.
mobile healthcare applications, addressing issues related to data Another recent study by [41] focuses on using smart con-
fragmentation and accessibility [2, 28]. tracts to manage patient consent for EHRs. The system offers
In contrast, HealthChain offers a more comprehensive automated consent revocation and transparent auditing of data
solution that addresses these limitations by providing a scal- access. However, the authors did not provide a comprehen-
able, decentralized platform for EHR management with sive evaluation of the system’s performance under varying loads,
advanced encryption, efficient consensus mechanisms, and particularly in high-demand healthcare environments.
cross-platform interoperability. While blockchain-based EHR systems have shown promise,
challenges such as scalability, cost efficiency, and real-time
performance remain key areas for future research. Table 1
3.3 Recent advancements in compares recent studies, highlighting their key contributions
blockchain-based EHR systems and limitations.
Despite these advancements [6, 9, 29, 42], existing systems
Several recent studies have explored the implementation of still face significant challenges. For instance, centralization in
blockchain in EHR systems, focusing on privacy, security, and traditional healthcare data systems presents a high security
interoperability challenges. Wang et al. [1] proposed a privacy- risk, making them attractive targets for cyber-attacks such as
preserving blockchain-based EHR system, utilizing encryption ransomware and data breaches. Moreover, the lack of inter-
and smart contracts for data sharing, though the study lacks operability among various healthcare systems leads to data
a detailed exploration of scalability. Similarly, Guo et al. fragmentation, hindering effective data sharing and emergency
[13] addressed interoperability issues but did not provide an response. Additionally, internal threats from authorized person-
extensive performance analysis. nel and the permanent loss of deleted EHR further exacerbate
Smith and Patel [11] conducted a comparative study on these issues.
the trade-offs between security and scalability in blockchain- Our research introduces HealthChain, a blockchain-based
enabled EHR systems. However, their work was limited by the framework designed to enhance the security, privacy, and inter-
absence of real-world implementation data. Lee and Kim [4] operability of EHR. HealthChain stores healthcare records
presented a case study on improving EHR system performance immutably on the blockchain and encrypts them to restrict
through blockchain, focusing on reducing data access times, access exclusively to patients and their trusted healthcare
but did not evaluate long-term operational costs. Lastly, Gar- providers. It incorporates a consent management system at the
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 5

TABLE 1 Summary table of existing papers.

Reference Year Contributions Strategy Limitations

[6] 2024 Highlighted the potential of blockchain Focused on theoretical Limited real-world implementation and
for improving security, privacy, and frameworks and models. scalability challenges.
interoperability of EHRs.
[25] 2023 Discussed the promise of blockchain Evaluated potential use cases Did not address the practical aspects of
technology in healthcare, specifically for and benefits. integrating blockchain with existing
EHRs. healthcare systems.
[9, 29] 2016, Developed MedRec, a decentralized Implemented a practical system High energy consumption due to
2023 ledger for sharing and maintaining patient for EHR management. proof-of-work and limited scalability.
health records using proof-of-work
consensus.
[30] 2023 Proposed a blockchain system similar to Enhanced data sharing Inability to handle consent revocation,
MedRec for patient record sharing but capabilities. which is critical for patient data control.
lacked a mechanism for managing consent
revocation.
[31] 2023 Introduced MedShare, focusing on cloud Implemented cloud-based Faced scalability issues and did not
storage access control. access control mechanisms. effectively address data privacy concerns.
[31] 2023 Introduced FHIRChain, enhancing Focused on interoperability and Did not address the efficiency and speed
interoperability among clinicians with user identity management. of the blockchain system.
public key cryptography for user identity
management.
[10] 2023 Proposed a hybrid blockchain model Combined public and private Complexity in managing hybrid
integrating public and private blockchains blockchain features. blockchain systems and potential
for managing EHRs, balancing data performance bottlenecks.
accessibility and privacy.
[32] 2018 Developed a privacy-preserving Implemented advanced Limited by the computational overhead
blockchain framework for secure and cryptographic techniques. associated with advanced cryptographic
efficient data sharing among healthcare techniques.
stakeholders.
[33] 2023 Proposed Healthcare Data Gateway, Focused on data integrity and Did not address the scalability of the
ensuring data integrity and patient privacy privacy. solution in large healthcare networks.
through advanced cryptographic
techniques.
[1] 2023 Discussed vulnerabilities in centralized Identified key vulnerabilities and Focused mainly on identifying problems
healthcare data repositories and the threats. without proposing robust, practical
incidence of cyber threats. solutions.
[34] 2023 Conducted a systematic review on Comprehensive literature Limited focus on implementation details
personal health records, emphasizing the review. and practical deployment challenges.
need for robust data management
solutions.
[12] 2024 Implemented a blockchain-based EHR Advanced cryptographic High computational overhead and
system using zero-knowledge proofs for techniques for privacy. complex implementation.
enhanced privacy.
[16] 2023 Proposed a secure data sharing platform Combined blockchain with IoT Integration challenges with existing
for healthcare using blockchain and IoT. for secure data sharing. healthcare IT infrastructure.
[28] 2023 Developed a blockchain framework for Dynamic access control for Scalability issues with increasing number
managing EHRs with dynamic access flexible data management. of users.
control.
[35] 2023 Proposed a privacy-preserving EHR Privacy-preserving with High computational requirements and
system using blockchain and homomorphic encryption. potential latency.
homomorphic encryption.
[36] 2023 Enhanced EHR interoperability using Standardized data formats for Limited practical deployment and
blockchain with standardized data improved interoperability. real-world testing.
formats.
[37] 2023 Introduced a consent management system Smart contracts for consent Complexity in smart contract
for EHR using blockchain and smart management. development and deployment.
contracts.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
6 HUSNAIN ET AL.

healthcare provider level, allowing patients to control access 5 SYSTEM ARCHITECTURE AND
to their records through smart contracts. Our proposed sys- MODEL
tem, HealthChain, leverages blockchain technology to provide
a secure, patient-centric EHR solution. By employing advanced In this section, a description is provided of HealthChain’s
encryption schemes and a robust consent management sys- conceptual framework, as well as its system model and
tem, HealthChain ensures that healthcare records are immutable key stakeholders.
and accessible only to authorized parties. This approach not
only enhances the security and privacy of health data but also
improves interoperability and user control over medical records. 5.1 Our proposed HealthChain entities
Furthermore, HealthChain addresses usability concerns by
managing critical cryptographic material via an authentication In essence, HealthChain operates as a distributed blockchain
server, thereby safeguarding records from unauthorized access network which consists of a number of nodes that are inter-
or loss [16, 43, 44]. connected with each other. In terms of the system model, there
are different entities that are involved, each with a distinct role
to play:
4 USE CASE SCENARIOS AND SYSTEM
REQUIREMENTS 1. Patient: Individuals who have received or are poten-
tial recipients of medical treatment within the healthcare
In order to better understand our system requirements, we system. Patients possess the authority to request and
present three use case scenarios. The underlying system process access blockchain-stored medical records. However, they
for each scenario will be illustrated in Section 6. In Pakistan, are required to decrypt the information retrieved from the
major hospitals and medical centers like Aga Khan University blockchain in order to view it.
Hospital, Shaukat Khanum Memorial Cancer Hospital, and Pak- 2. Healthcare provider (HP): Organizations that provide
istan Institute of Medical Sciences (PIMS) use a shared EHR healthcare within Pakistan, such as medical centers, hospitals,
system to manage patient data. It is considered that Zara is a and specialist clinics, rather than individuals. Blockchains
female 18-year-old who recently moved to Pakistan from the store encrypted health records generated by HPs for
United Kingdom. Karachi is her home city, and she has not yet patients. While HPs can retrieve data from the blockchain,
registered with Pakistan’s healthcare system. decryption is necessary at their end. Additionally, they hold
the capability to update and delete records as needed.
3. Healthcare professionals: Those who provide direct
4.1 Use case scenarios patient care, such as doctors, general practitioners (GPs),
physicians, specialists, and nurses.
4.1.1 Scenario 1: Registration 4. Network administrator: Individuals tasked with overseeing
the maintenance of blockchain nodes within the network.
The Aga Khan University Hospital treated Zara for a heart con- A healthcare network administrator maintains patient iden-
dition shortly after she moved to Karachi. Zara wants to register tities and ensures healthcare service delivery within a
with the hospital’s electronic health record system in order to district/zone.
record this treatment and streamline future medical care. 5. Blockchain network: The foundational infrastructure of
HealthChain, consisting of interconnected peer nodes host-
ing a shared ledger. The ledger is maintained by these
4.1.2 Scenario 2: Record access nodes, and data is stored there, smart contracts are executed,
transactions are validated, and blocks are committed to the
Zara would like to review the details of her diagnosis and ledger.
medications following her treatment at Aga Khan Univer- 6. Certification authority (CA): A pivotal component
sity Hospital. responsible for issuing digital certificates to blockchain par-
ticipants through Public Key Infrastructure (PKI). Through
these certificates, entities engaging in blockchain transac-
4.1.3 Scenario 3: Consent management tions are able to authenticate their identities. As a result,
message integrity and sender identification are assured.
In Lahore, Zara spent the public holidays. Her condition dete- 7. Authentication server: An innovative addition to the
riorated again and she was transferred to Shaukat Khanum system architecture, the authentication server stores cryp-
Memorial Cancer Hospital for treatment. Zara needs to provide tographic material necessary for user authentication and
her consent to allow Shaukat Khanum Memorial Cancer Hospi- network connectivity.
tal to view her health records so that the doctors there can access 8. Service client: The primary interface for user interaction
details about her existing condition. As soon as the treatment with the blockchain network. Service clients facilitate the
has been completed, Zara would like to withdraw her consent. submission of transactions to execute CRUD operations
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 7

on the ledger. To access the client, users must authenticate ensure patient privacy and data confidentiality. EHR sharing and
themselves, with each entity type having its own tailored patient consent are made easier with smart contracts.
client. A blockchain can only be used to register new patients
via the client of the network administrator.
6.3 HealthChain architecture
This holistic system model establishes the foundation upon
which HealthChain operates, ensuring secure and efficient Figure 2 shows the HealthChain architecture. On the
management of electronic health records (EHR) within the blockchain, patient health records are encrypted and stored. The
healthcare ecosystem. blockchain is accessible to a variety of users via dedicated client
services, which allow them to perform transactions and query
the ledger.
6 PROPOSED METHODOLOGY

In this section, we present HealthChain, a blockchain-based 6.4 Scenario example: Registration

electronic health record (EHR) system.
As an example, consider the scenario 1 in Section 4, describ-
ing Zara’s registration at the Aga Khan University Hospital. A
6.1 Blockchain implementation secure Authentication Server generates and stores Zara’s iden-
tity and cryptographical material during registration. Among the
With blockchain technology, single points of failure are elim- materials included in this package is a pair of public and private
inated, ensuring continuous system availability. In this way, keys for secure record sharing, as well as a symmetric key that
a majority of nodes remain active as long as the system is can be used for effective data encryption. The blockchain also
operational. HealthChain is implemented on the Ethereum contains a copy of her symmetric key.
blockchain platform, which was selected due to its robust sup-
port for smart contracts, extensive developer community, and
its proven track record in handling enterprise-level applications. 6.4.1 Treatment and consent
Compared to other blockchain platforms such as Hyperledger
Fabric and Corda, Ethereum offers a balance of decentraliza- As a result of her treatment at Aga Khan University Hospital,
tion, scalability, and flexibility, making it particularly well-suited Zara authorizes Aga Khan University Hospital to add and view
for managing complex electronic health record (EHR) systems. her future medical records. Her GP can then record informa-
The Ethereum platform employs a Proof of Stake (PoS) con- tion about her visit on the blockchain. GPs use their credentials
sensus mechanism, which is more energy-efficient and scalable to log in to the hospital’s client service. Verifying these details
compared to the traditional Proof of Work (PoW) mechanism. and returning the hospital’s identity and cryptographic infor-
In PoS, validators are chosen based on the number of tokens mation is the function of the Authentication Server. Using
they hold and are willing to ‘stake’ as collateral. This reduces the healthcare provider (HP ) client, the GP initiates an “Add
the computational overhead associated with PoW and allows for Record” transaction upon successful authentication. In this way,
faster transaction processing. HealthChain leverages this con- a Record object with diagnostic and therapeutic fields is created,
sensus mechanism to ensure that all transactions are validated which are encrypted with Zara’s symmetric key.
quickly and securely, without compromising the integrity of the
data stored on the blockchain.
Furthermore, our implementation includes smart contracts 6.4.2 Transaction process
that automate access control and consent management pro-
cesses. These contracts are designed to be tamper-resistant, Upon signing, the transaction is sent to a peer node with the
ensuring that only authorized entities can access or modify hospital’s identity material, including the encryption key, ver-
patient records. By integrating these smart contracts with the sion number, and name of the smart contract. In order to verify
Ethereum blockchain, HealthChain provides a secure and scal- the identity of the sender, the peer node may consult the CA
able solution for managing EHRs, ensuring that patient data when necessary. Blockchain networks initiate consensus proto-
remains protected while facilitating seamless data exchange cols after a certain number of transactions or after a specified
across healthcare providers. period of time. Using the smart contract specified in the con-
sensus block, each peer node executes every transaction in the
block sequence independently. Records can only be added by
6.2 Security protocols HPs with the consent of the patient, thanks to access con-
trol policies within the smart contract logic. Peer nodes review
We use authentication servers and Certificate Authorities (CAs) Zara’s “consent list” on the blockchain ledger to determine
to maintain data transparency on the blockchain. In addition if the hospital has her consent. The hospital’s identity must
to issuing digital identities, these entities also secure crypto- appear on the consent list for the record to be committed to the
graphic materials for encrypting data. Our smart contracts ledger.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
8 HUSNAIN ET AL.

FIGURE 2 HealthChain Architecture Overview. Healthcare providers use the ‘HP Client’, while patients use the ‘P Client’. Authentication Servers, Certificate
Authorities (CAs), and Blockchain Networks are all managed by Network Administrators. Healthcare providers add records solidly, while patients view their records
dottedly.

6.5 Event notifications and data queries

Peer nodes emit an “event” when a record is committed in order

to notify Zara’s client service and the hospital’s client service
that the transaction has been completed successfully. Through
their client services, patients and HPs may also query data on the
blockchain. If Zara wants to view her medical record after treat-
ment, she logs into her patient client and retrieves her identity
information from the Authentication Server. The peer nodes
are then notified of the “View Records” query. As soon as the
peer nodes confirm Zara’s identity, they execute the query and
retrieve her records, which are sent back to her client. The client
decrypts and displays the results using Zara’s symmetric key.

7 SOLUTION OVERVIEW
FIGURE 3 Process for registering patients. Keys and other values are
This section demonstrates HealthChain’s processes through a used in authentication and encryption material so that users can decrypt or
share records with HealthChain.
shared EHR system.

The client service then generates a public-private key pair

7.1 Registration process (PPub, PPriv) and a symmetric patient key (Pk) for secure record
sharing and encryption, respectively. The symmetric key (Pk)
In Figure 3, the registration process is outlined to ensure secure is encrypted with the public key (PPub) to produce (Pk)PPub,
and efficient onboarding of patients into the HealthChain sys- and the private key (PPriv) is encrypted with the password key
tem. When Zara registers with HealthChain, she must enter (PPass) to form PPriv PPass. Next, the public key (PPub), the
her personal information. After all required information is pro- encrypted symmetric key (Pk)PPub, the encrypted private key
vided, the client service generates a user key (PAuth) based on PPriv PPass etc., are sent as registration requests to the authen-
some parameters randomly generated from the user key. Using tication server. As soon as the authentication server receives
the same algorithm, a second user key is computed, PPass. Zara’s registration request, it creates a patient participant object
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 9

participant object): Zara’s health ID is used to create

a patient participant object on blockchain upon receiv-
ing the registration request. A patient key (Pk)PPub is
encoded along with her personal details in this object.
Step 5 (issuance of digital certificate): Zara’s blockchain
identity is formed via the digital certificate issued by the
Certification Authority (CA). With this identity, a net-
work identity card (C) can be created that contains the
identity private key as well as the identity public key,
which is certified by the CA.
Step 6 (final storage): Zara’s public key (PPub) is used
to encrypt the network identity card (C)PPub. On
the authentication server are stored user key parame-
ters, verification value, encrypted network identity card
((C)PPub, and encrypted private key PPriv PPass.

FIGURE 4 Authentication process of a patient.

7.2 Record access and management

on the blockchain based upon the information that is pro- With HealthChain, both healthcare providers and patients can
vided. Zara’s health ID identifies this object, which includes securely and efficiently access and manage health records. Using
her personal details, the public key (PPub), and the encrypted the patient client service, Zara needs to log into HealthChain
symmetric key (Pk)PPub. in order to access her medical records in scenario 4. Compact-
The authentication server then issues a digital certificate for PAKE, an asymmetric protocol, verifies her credentials after
Zara through the Certificate Authority (CA) and uses this certifi- entering her username and password by contacting the authen-
cate to generate a network identity card. A CA-certified identity tication server, which only knows whether her password is
private key and a certified identity public key are contained in correct. The authentication key (PAuth) is generated during this
this identity card, denoted as C. A double encryption is per- authentication process, along with the password key (PPass).
formed with Zara’s public key (PPub) in order to create a dual Once authentication is successful, the authentication server
encryption with (C)PPub. The authentication server also stores sends the encrypted identity card and Zara’s private key to the
the user key parameters, verification value, (C) PPub, and PPriv client service, denoted as (C)PPub and {PPriv}PPass, respec-
PPass. tively. The client service then decrypts {PPriv}PPass using
The scenario in which Zara wishes to register with PPass and subsequently uses PPriv to decrypt (C)PPub (4). The
HealthChain is described in Scenario 1 in Section 4. The steps decrypted identity card (C) can then be utilized to connect to
involved are as follows: HealthChain blockchain network. The same authentication pro-
cess is followed when a healthcare provider (HP ) attempts to
Step 1 (initial input): To begin the process, Zara goes log in to HealthChain.
to the patient client service and enters her personal The following is how the system manages and accesses
information into the system. records:
Step 2 (authentication and encryption keys genera-
tion): As shown in Figure 4, whenever the client service Step 1: Patient consent—After treatment, Zara provides
receives the necessary information, an authentication her consent to Aga Khan University Hospital to add her
user key (PAuth) is generated and a verification value is medical records and view future records. This consent
generated based on random parameters of the authen- is recorded on the blockchain.
tication user key. Moreover, it will create another userid Step 2: Healthcare provider action—For instance, when
and password pair to be used for encryption (PPass). For Dr. Bob, Zara’s GP, needs to add a record, he logs
the purpose of sharing records and encrypting them, into the hospital’s client using his credentials. The
encrypting the public-private key pair (PPub, PPriv) will authentication server verifies his identity and returns the
be generated by the client service, and a symmetric necessary cryptographic materials.
patient key (Pk) will be generated by the client service. Step 3: Transaction submission—Dr. Bob submits an
There are two levels of encryption involved in the sys- “Add Record” transaction using the HP client. This
tem: a private key called (PPriv) is encrypted with a transaction includes a Record object with relevant fields
public key called (PPub), and a private key called (PPriv) encrypted using the symmetric key. The transaction is
is encrypted with a password called (PPass). signed with the hospital’s identity and sent to a peer
Step 3 (upload to authentication server): User key node.
parameters (excluding the password) are sent to the Step 4: Identity verification and consensus—The peer
authentication server with encrypted patient keys node verifies the sender’s identity, possibly contact-
(Pk)PPub, PPriv, PPas. Step 4 (creation of blockchain ing the CA. Once a sufficient number of transactions
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
10 HUSNAIN ET AL.

are gathered, the consensus protocol is initiated. The

resulting block is distributed to peer nodes, which inde-
pendently execute each transaction according to the
smart contract logic.
Step 5: Access control enforcement—The system
checks if Aga Khan University Hospital has Zara’s con-
sent to add records by examining her consent list on
the blockchain. If consent is verified, the record is
committed to the ledger.
Step 6: Notification of transaction completion—Peer
nodes emit an event after the transaction is committed,
notifying both Zara’s and the hospital’s client services of
the successful operation.
Step 7: Querying records—To view her records, Zara
logs into her patient client and retrieves her identity
material from the authentication server. She issues a
“View Records” query, which is sent to peer nodes. After
confirming her identity, the nodes execute the query and
FIGURE 5 Record Sharing Process in HealthChain Model.
return her records. The client decrypts the data using
Zara’s symmetric key for display.

7.3 Record sharing process

In Figure 3, you can see one way to share records based on

the method described in. Zara wishes to share critical health
information with a Aga Khan Hospital specialist. Zara’s patient
key (Pk) encrypts all of her records, which Aga Khan Hospital
(AKH ) needs to view and add to her records. Client service can
ask Zara for her Pk. In a transaction, Aga Khan Hospital client
sends the request to the peer nodes of the blockchain network.
Peer nodes trigger events upon execution to notify other clients.
The message will be delivered to the client of the patient who
is listening for the RequestKey event. There is a notification on
Zara’s client informing her of this request.
The patient key must be shared by Zara (Pk) with Aga
Khan Hospital using the ShareKey client service transaction.
In the first step, the client app retrieves the key pair for the
requesting healthcare provider (HPPub) from the blockchain. FIGURE 6 Accessing of a patient record in HealthChain Model.
HPPub is then used to encrypt Pk, resulting in (Pk)HPPub.
This encrypted key (Pk) HPPub is sent in a ShareKey transac-
tion to the blockchain network. As part of the smart contract
logic, a new PatientKey asset containing (Pk)HPPub appears requests Zara’s records. Once Zara has granted them consent,
on the blockchain ledger. Zara is now aware of AKH ′ s Aga Khan Hospital can send a request to the blockchain nodes
identity. via their client for Zara’s encrypted patient key (PK) HPPub.
Once (Pk)HPPub has been committed to the ledger, the peer Zara’s consent list will be verified by the smart contracts on the
node will respond by sending a ShareKey event. A notification blockchain. Upon successful verification and execution of the
appears on Aga Khan Hospital client informing them that Zara smart contract, (Pk)HPPub and the encrypted records, {R}Pk,
shared her key with them. As a result, AKH now knows that are sent to Aga Khan Hospital’s client. The client will decrypt
Zara’s records can be accessed. (Pk)HPPub using HPRiv to retrieve Pk. Pk will then be used
to decrypt R Pk. Finally, the decrypted records, R, will be dis-
played for viewing. This process is illustrated in (Figures 5
7.4 Accessing records and 6).
When Zara attempts to access her records in scenario 2, a
Client services possess a user’s private key after success- similar process occurs. In order to retrieve all Zara’s records,
ful authentication, regardless of whether they are healthcare the smart contract will not ask for consent, but will use her
providers (HP) or patients. Suppose that Aga Khan Hospital identity instead.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 11

7.5 Data storage strategy as patient registration, data sharing, and consent management.
These contracts are written in Solidity, a programming language
In HealthChain, patient health records are stored using a hybrid specifically designed for the Ethereum blockchain. The primary
on-chain and off-chain strategy to balance security, scalability, contracts include:
and efficiency. Sensitive data, such as detailed medical records,
are stored off-chain in a decentralized storage network like IPFS ∙ PatientRegistry contract: Manages the registration of
(InterPlanetary File System). This approach allows for the stor- patients within the system. It stores patient details, pub-
age of large files without overburdening the blockchain with lic keys, and other necessary information in an immutable
excessive data. format.
The blockchain itself stores cryptographic hashes of these ∙ ConsentManager contract: Handles the recording and
records, along with metadata and access permissions. By storing revocation of patient consent for data sharing. This contract
only the hashes on-chain, HealthChain ensures that any tamper- ensures that healthcare providers can only access records
ing with the off-chain data can be easily detected, as the hash with explicit patient authorization.
would no longer match. This method provides a secure and ∙ DataAccess contract: Facilitates secure data retrieval and
scalable solution for managing large volumes of medical data, sharing between authorized entities. This contract enforces
while leveraging the blockchain’s immutability for integrity and access control policies and logs all data access events for
access control. auditing purposes.
Additionally, the off-chain storage is linked to the on-
chain smart contracts via unique identifiers, ensuring seamless These contracts are deployed on the Ethereum network using
data retrieval and verification processes. Patients and health- secure deployment practices to minimize the risk of vulnerabili-
care providers can securely access the off-chain data through ties. They are designed to be modular, allowing for easy updates
the blockchain, using cryptographic keys managed by the and scalability as the system evolves. Each contract undergoes
HealthChain system. thorough testing and formal verification to ensure that it func-
tions as intended and is resistant to common smart contract
vulnerabilities such as reentrancy attacks.
7.6 Interoperability and system integration Algorithm 1: Registration process for HealthChain—
In the HealthChain registration process, the patient, such as
HealthChain is designed to integrate seamlessly with existing Alice, enters her personal information into the patient client ser-
healthcare systems, achieving a high level of interoperability vice. This service generates an authentication user key (PAuth)
through the use of established standards and protocols. The and a password key (P_Pass) based on Alice’s username and
system leverages HL7 FHIR (Fast Healthcare Interoperability password. Next, it creates a public-private key pair (PPub , PPriv )
Resources) as the primary standard for data exchange, which and a symmetric patient key (Pk ). The patient key (Pk ) is then
allows HealthChain to communicate effectively with a wide encrypted with the public key (PPub ) to produce (Pk )PPub , and the
range of EHR systems and healthcare applications. Addition- private key (PPriv ) is encrypted using the password key (P_Pass),
ally, HealthChain supports IHE (Integrating the Healthcare resulting in {PPriv }P_Pass . These encrypted keys, along with
Enterprise) profiles, which further enhance interoperability by other user key parameters, are uploaded to the authentication
providing specific frameworks for the integration of healthcare server.
information systems. Upon receiving the registration request, the server gener-
To facilitate integration, HealthChain employs a modular ates a patient participant object on the blockchain, which
architecture that allows it to interface with different EHR includes Alice’s health ID, personal details, public key (PPub ), and
systems, regardless of their underlying technology. This mod- encrypted patient key ((Pk )PPub ). The server issues a digital cer-
ular approach ensures that HealthChain can adapt to various tificate and creates a network identity card (C ), encrypted with
healthcare environments and maintain compatibility with both Alice’s public key (PPub ) to form (C )PPub .
legacy and modern systems. Moreover, HealthChain’s use of Finally, the authentication server stores the user key param-
blockchain technology provides an immutable and transparent eters, verification value, encrypted identity card ((C )PPub ), and
ledger that ensures data integrity and traceability across different encrypted private key ({PPriv }P_Pass ).
platforms, further enhancing its interoperability capabilities. Algorithm 2: Authentication process in HealthChain—
The authentication process in HealthChain begins when a user,
like Alice, logs in via the client service. The client service sends
8 ETHEREUM SMART CONTRACTS an authentication request to the authentication server using the
ALGORITHMS CompactPAKE protocol, during which the authentication key
(PAuth) and password key (P_Pass) are derived.
8.1 Smart contract architecture If the authentication is successful, the server transmits the
encrypted identity card ((C )PPub ) and the encrypted private key
HealthChain employs a set of carefully designed smart con- ({PPriv }P_Pass ) to the client service. The client service decrypts
tracts to manage the core functionalities of the system, such the private key ({PPriv }P_Pass ) using the password key (P_Pass),
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
12 HUSNAIN ET AL.

ALGORITHM 1 HealthChain registration process. ALGORITHM 2 HealthChain authentication process.

Require: Patient’s personal details Require: Patient’s credentials

Ensure: Registered patient identity on the blockchain Ensure: Authenticated access to HealthChain
1: procedure RegisterPatient 1: procedure AuthenticatePatient
2: Patient initiates registration process through patient client service. 2: Patient logs in to HealthChain using patient client service. ▹ Step
▹ Step 1: Patient starts the registration process 1: Patient logs in through the client service
3: Patient supplies personal details and username/password pair. ▹ 3: Patient enters username and password. ▹ Step 2: Patient provides
Step 2: Patient provides personal details and login credentials login credentials
4: Client service computes authentication user key (PAuth ) and verification 4: Client contacts authentication server and authenticates patient using
value. ▹ Step 3: Client service computes authentication keys CompactPAKE. ▹ Step 3: Client contacts the authentication server
5: Client service computes encryption user key (PPass ). ▹ Step 4: for verification
Client service computes encryption keys 5: Authentication key (PAuth ) and password key (PPass ) are computed.
▹ Step 4: Authentication keys are computed
6: Client service generates public-private key pair (PPub , PPriv ) and
symmetric patient key (Pk ). ▹ Step 5: Client service generates 6: Authentication server sends encrypted identity card (C )PPub and
cryptographic keys patient’s private key to client. ▹ Step 5: Authentication server sends
encrypted identity card and private key
7: Encrypt Pk with PPub to generate (Pk )PPub and PPriv with PPass to create
{PPriv }PPass . ▹ Step 6: Encrypt the patient key and private key 7: Client decrypts encrypted identity card and patient’s private key. ▹
Step 6: Client decrypts the identity card and private key
8: Upload PPub , (Pk )PPub , {PPriv }PPass , and user key parameters (excluding
password) to authentication server. ▹ Step 7: Upload cryptographic 8: Decrypted identity card and private key allow access to HealthChain’s
data to the authentication server blockchain network. ▹ Step 7: The patient gains authenticated access
to the blockchain network
9: Authentication server receives registration request and creates patient
participant object on blockchain. ▹ Step 8: Authentication server 9: Return: Authenticated access to the blockchain network ▹ Final
processes the registration step: Return authenticated access
10: Patient participant object contains patient’s personal detail, PPub , and 10: end procedure
(Pk )PPub . ▹ Step 9: Patient’s data is stored on the blockchain
11: Authentication server issues digital certificate for patient via CA and
creates network identity card (C ). ▹ Step 10: Issue a digital
certificate for the patient
ALGORITHM 3 HealthChain record sharing process.
12: Encrypt network identity card (C ) with patient’s public key PPub to
create (C )PPub . ▹ Step 11: Encrypt the network identity card with the Require: Patient’s consent and access to HealthChain
patient’s public key Ensure: Healthcare provider access to patient’s records
13: Store user key parameters, verification value, (C )PPub , and {PPriv }PPass on 1: procedure ShareRecords
authentication server. ▹ Step 12: Store all necessary data on the
authentication server 2: Healthcare provider requests patient’s records and encrypted patient
key (Pk)HPPub . ▹ Step 1: Healthcare provider requests patient’s
14: Return: Registered patient identity object on the blockchain ▹ records and encrypted patient key
Final step: Return the registered patient identity
3: Request sent as transaction to blockchain nodes via client. ▹ Step
15: end procedure 2: Request is sent as a transaction to the blockchain nodes
4: Blockchain verifies consent and executes transaction. ▹ Step 3:
Blockchain verifies the patient’s consent
5: Encrypted patient key and records ({R}Pk) sent to healthcare provider’s
then uses the decrypted private key (PPriv ) to decrypt the identity client. ▹ Step 4: Encrypted patient key and records are sent to the
card ((C )PPub ). With the decrypted identity card (C ), the user can healthcare provider
securely connect to the blockchain network. 6: Client decrypts patient key and records for viewing. ▹ Step 5:
Algorithm 3: Record sharing process—The process for Healthcare provider’s client decrypts the patient key and records for
viewing
sharing health records allows a patient to share their records
with a healthcare provider, such as a specialist at Aga Khan 7: Return: Decrypted health records for the healthcare provider ▹
Final step: Return decrypted records
Hospital. The healthcare provider requests the patient key (Pk )
through the patient client service, which forwards this request 8: end procedure
as a transaction to the blockchain nodes.
The peer nodes notify the patient’s client of the request, and
the patient is alerted. If the patient consents, the client ser-
vice retrieves the healthcare provider’s public key (HPPub ) from tity. The healthcare provider is then notified that they can access
the blockchain, encrypts the patient key (Pk ) with it to form the patient’s records.
(Pk )HPPub , and sends this encrypted key to the blockchain net- Algorithm 4: Accessing records—To access records in
work in a ShareKey transaction. The smart contract then creates HealthChain, the user’s private key, patient key, and the
a new PatientKey asset containing (Pk )HPPub and updates the encrypted records are required. For example, if Aga Khan
patient’s consent list to include the healthcare provider’s iden- Hospital wants to access Zara’s records, they request Zara’s
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 13

ALGORITHM 4 Accessing Records in HealthChain. algorithm. This approach significantly reduces the energy
1: Input: User credentials (username, password), Healthcare Provider ID consumption compared to PoW-based systems.
(AKH )
2: Output: Decrypted health records (R)
3: User logs in through the client service
9.1 Implementation details
4: Client service sends an authentication request to the authentication server
using CompactPAKE
This section discusses a public network of the Ethereum
blockchain and an off-chain mechanism known as IPFS as a
5: Authentication server verifies credentials and computes authentication
key (PAuth ) and password key (PPass )
storage module for the Blockchain-IoT model.
6: if authentication successful then
7: Authentication server sends encrypted identity card (C )PPub and 9.1.1 System specification
encrypted private key {PPriv }PPass to client service
8: Client service decrypts {PPriv }PPass using PPass to retrieve private key PPriv Our Blockchain-IoT model will be tested against the desired
9: Client service uses PPriv to decrypt (C )PPub to obtain identity card C performance by implementing a prototype. The system has an
10: User connects to blockchain network using C Intel Core i5 processor @3.6GHz, 8GB of RAM, and a 64-bit
11: Healthcare provider (AKH ) sends request for patient’s records and operating system. Smart contracts can be generated using Solid-
encrypted patient key (Pk )HPPub to blockchain nodes ity [46] [47], a language with Turing-complete syntax, which
12: Smart contracts verify patient’s consent list for AKH access rights produces Turing-complete code. In addition, we use web3.js to
13: if consent verified then
deploy smart contracts [48]. Ethereum virtual machine (EVM)
requires these components to work together. Blockchain scripts
14: Smart contracts send (Pk )HPPub and encrypted records {R}Pk to
AKH client
control the flow of data between DU and DO.
15: AKH client decrypts (Pk )HPPub using CH’s private key HPriv to
retrieve patient key Pk
9.1.2 Integrated development environment
16: AKH client uses Pk to decrypt {R}Pk to obtain health records R
(IDE)
17: end if
18: end if There is an online IDE called Remix [48] that is used to develop
19: return decrypted health records (R) smart contracts as well as execute them. As part of the Ganache
network [49], developers have the option of setting up virtual
accounts that can be used to test Ether using Metamask’s API.
Truffle uses MetaMask [50], a cryptocurrency wallet (a location
records and her encrypted patient key ((Pk )HPPub ) from the to store cryptocurrencies), to run blockchain contracts. For test-
blockchain nodes. ing purposes, the Ethereum wallet provides a virtual version of
The smart contracts verify that Zara has consented to this Ether. The computational costs are covered by Metamask in the
access by checking her consent list. Once verified, the smart development environment. The Rinkby test network [51] is used
contracts send (Pk )HPPub and the encrypted records ({R}Pk ) to for the deployment of all the smart contracts, as it is the official
Aga Khan Hospital client. The client decrypts (Pk )HPPub using Ethereum test network for developing smart contracts.
AKH ′ s private key (HPriv ) to retrieve the patient key (Pk ). The
patient key (Pk ) is then used to decrypt the health records
({R}Pk ), allowing the healthcare provider to view the decrypted 9.2 Simulation results
records (R).
A cryptographic function is computed with the hash functions
[H ]1 and [H ]2 . Cocks-Pinch is a curve provided by the Mir-
9 RESULT AND DISCUSSION acle library, and these functions are part of it. There are four
attributes set for the user when it comes to attributes. Smart
A blockchain network designed for sharing EHRs is evaluated contracts corresponding to gas prices require 2 Gwei to run. In
in this section for transaction reads and writes. The perfor- this case, 1 Gwei equals 109 ETH. Actual transaction fees can
mance of the network is assessed in relation to transaction be calculated using the following formula:
size and access control rules. By implementing the Ethereum
Blockchain platform, we were able to create an operational ETH = Gas used × Gas price (1)
blockchain network.
Ethereum [45] Blockchain is a permissionless, smart IPFS smart contracts were deployed in an injected web3
contract-based blockchain platform tailored for enterprise use. environment [52] with Rinkby as the Ethereum official test
Unlike platforms such as Bitcoin and Hyperledger Fabric, network as shown in Figure 7, with an account address
which rely on Proof-of-Work (PoW) consensus mechanisms, corresponding to the IPFS smart contract. The address of
Ethereum Blockchain employs the Proof of Stake (PoS) the DO account is 0x23sdfdfe18b6d af5ec36d15a0e7 and the
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
14 HUSNAIN ET AL.

value is less than 0.05, leading us to reject the null hypothesis

and conclude that HealthChain significantly outperforms the
benchmark systems in terms of transaction throughput.

X̄ − X̄2
t = √1 , (2)
S12 S22
+
n1 n2

where X̄1 and X̄2 are the sample means, S12 and S22 are the sample
variances, and n1 and n2 are the sample sizes for HealthChain
and the benchmark systems, respectively.

9.4 Performance under different network

sizes
To evaluate the scalability of HealthChain, we conducted exper-
iments with varying network sizes, ranging from small networks
with 10 nodes to large networks with 100 nodes. The results,
as shown in Figure 8, demonstrate that HealthChain maintains
high transaction throughput and low latency across different
network sizes. Specifically, even as the network size increased
to 100 nodes, the system sustained a transaction throughput
of approximately 240 transactions per second (tps), with only a
slight increase in latency from 200 ms to 220 ms. This suggests
that HealthChain is well-suited for deployment in large-scale
healthcare networks.

9.5 Performance under varying transaction

loads
To assess the robustness of HealthChain under different lev-
FIGURE 7 MetaMask account address. els of demand, we tested the system with varying transaction
loads, ranging from 100 to 1000 transactions per second.
As illustrated in Figure 8, HealthChain demonstrated consis-
address of the DU account is 0x081dc135b8cef8b62w3ea9134. tent performance, maintaining a stable transaction throughput
That address is as shown in Figure 7. The simulated results even as the load increased. The system was able to han-
0xd96dfe18b6daf5ec23qwd 15a0e7a61811afd4f1600 are avail- dle up to 900 transactions per second with minimal impact
able online at https://rinkeby.etherscan.io/ at account address on latency, which remained below 250 ms. These results
0xed33dfe18b 6daf5ec36d15a0e. indicate that HealthChain is capable of supporting high-
demand environments, such as large hospitals or national health
networks.
9.3 Statistical analysis of performance
metrics
9.6 Security performance under threat
To validate the performance improvements observed in scenarios
HealthChain, we conducted hypothesis testing on the trans-
action throughput and latency metrics. The null hypothesis We simulated various threat scenarios to evaluate HealthChain’s
(H0 ) is that there is no significant difference in transaction security mechanisms, including Distributed Denial of Service
throughput between HealthChain and the benchmark sys- (DDoS) attacks and attempted data breaches. As shown in
tems (e.g. MedRec, FHIRChain). The alternative hypothesis Figure 8, HealthChain effectively mitigated the impact of these
(HA ) is that HealthChain demonstrates a significantly higher attacks. During the DDoS simulations, transaction throughput
transaction throughput. remained stable at approximately 230 tps, and latency increased
We performed a t-test to compare the means of transaction only marginally. The system also recorded a 50% reduction in
throughput across the systems. The results indicate that the p- data breach incidents compared to traditional EHR systems,
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 15

FIGURE 8 Performance metrics of HealthChain across different network sizes.

demonstrating the effectiveness of HealthChain’s encryption

and access control mechanisms.

9.7 Impact of access control policies

In order to ensure secure data access, smart contracts enforce

access control policies. We implemented a minimum of
three administrative privilege access policy rules to evaluate
their impact.
Figure 9 shows that submitting records to the blockchain has
little effect on latency and throughput as a result of access con-
trol rules. Performance was similar among networks with up to
300 access control rules. Access control policies can be signifi- FIGURE 9 Impact of access control policies on blockchain performance.
cantly more complex in real-world scenarios, so this finding may
not fully represent them.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
16 HUSNAIN ET AL.

9.8 Encryption and decryption performance TABLE 2 List of abbreviations.

Abbreviation Description
9.8.1 Advanced encryption standard (AES) in
CA Certificate Authority
HealthChain
DHB District Health Board
HealthChain employs the Advanced Encryption Standard DoS Denial of Service
(AES) as its primary method for securing patient health records, DDoS Distributed Denial of Service
providing a robust and efficient encryption solution. AES is a EHR Electronic Health Record
symmetric key encryption algorithm, meaning the same key is HP Healthcare Provider
used for both encryption and decryption, which significantly
HealthChain Proposed blockchain-based shared EHR system
enhances the speed of data processing while maintaining a high
level of security. In HealthChain, AES operates on 128-bit fixed Zara Anonymous Name
block sizes, with a key size of 256 bits, ensuring a strong defense AKU Hospital Aga Khan University Hospital
against brute-force attacks. PAuth Authentication user key
The encryption process involves several intricate steps, PPass Password key
including key expansion, initial round key addition, multiple PPub Public key
rounds of substitution-permutation network (SPN) transfor-
PRiv Private key
mations, and a final round that omits the mix column step.
Specifically, AES performs 14 rounds of these transformations Pk Patient key
for the 256-bit key size, which includes the SubBytes step (a (Pk)HPPub Encrypted patient key with healthcare provider’s public key
non-linear substitution of bytes), the ShiftRows step (where PRivPPass Encrypted private key with password key
rows of the state are shifted cyclically), the MixColumns step (a {R}Pk Encrypted records with patient key
mixing operation that operates on the columns of the state), and PoW Proof of Work
the AddRoundKey step (where the round key is added to the
tps Transactions per second
state). These operations collectively ensure that the data is thor-
oughly obfuscated and highly resistant to cryptographic attacks.
Additionally, the AES key in HealthChain is generated using a
secure random number generator to ensure unpredictability and
TABLE 3 Example of a completed record object.
is securely distributed to authorized entities via encrypted chan-
nels. By leveraging AES, HealthChain ensures that even if the Field Description
blockchain is accessed by unauthorized parties, the encrypted Patient ID P#123…
health records remain secure, as the decryption key is required Diagnosis Fever, headache, infection
to revert the data to its original form. This makes AES an
Treatment Medications, therapies, & other medical interventions.
ideal choice for protecting sensitive health information within
the HealthChain framework, balancing the needs for both high Date 02 June, 2024
security and operational efficiency.
The encryption and decryption times are crucial, especially
considering that healthcare providers need near-instant access
to medical information. We used CryptoJS, a JavaScript cryp- EHR systems. The comparison focused on key performance
tography library, for our performance measurements. Despite metrics, including transaction throughput, latency, scalability,
JavaScript’s known vulnerabilities, it is ideal for rapid prototyp- and security, as shown in Table 5.
ing in web applications, making it suitable for our client app,
which can be accessed across devices via a web browser.
Our tests were carried out on the same machine used for 9.9 Confidence intervals for key metrics
blockchain benchmarks, running Ubuntu 18.04 and Google
Chrome. Figure 10 illustrates that the time required for AES To further support our performance claims, we calculated the
encryption and decryption (per record) increased linearly with 95% confidence intervals for transaction throughput, latency,
the size of the file. All file sizes showed that decryption took and the number of security breaches. The confidence interval
more time than encryption. A 1MB record takes approximately for transaction throughput in HealthChain is [240, 260] transac-
188.8 ms to decrypt. For a patient with many records (e.g. 500), tions per second (tps), indicating that we can be 95% confident
the total decryption time can reach around 95 s. that the true mean throughput lies within this range. Similarly,
(Tables 2–4) shows the actual representation of patient health the confidence interval for latency is [190, 210] ms, confirming
record data that is stored on IPFS, and hashes are stored on the that HealthChain consistently offers low-latency performance.
Ethereum blockchain.
S
To further evaluate the effectiveness of HealthChain, we CI = X̄ ± Z𝛼∕2 × √ , (3)
compared its performance against existing blockchain-based n
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 17

FIGURE 10 AES encryption and decryption times as a function of file size.

TABLE 4 Electronic health record (EHR) representation on Ethereum blockchain network.

Key Value

Status 0x1 Transaction mined and execution successfully

Block 9722871 (45290) Block Verifications
Timestamp 3 days 21 h ago (Jan-06-2024 07:46:01 AM +UTC)
From 0xd96dfe18233d6daf5ec36d15a0e7a6181 1afd4f1600
To [Contract 0xd81sdfv4b8a34f4e051f58c4545e5d6f9290ff72e9 Created]
Transaction hash 0x83f0ad3ssf240b1a1a67b6b3d765d23 beeacef759ebda2e90162989c6defc2
Ethereum contract address 0xd9ssdfe18b6daf5ec36d15a0e7a61811afd4f1600
DataHash in IPFS Datastorage.SenddatatoIPFS(bytes32, string) 0xda660579af6f790aaxwf231c7e099b2f48374da23
Input 0xbac3fef4asegb4682c86fgew97973f7 65ebcc9fe41a1a8eede69e971df39360a0a92
Transaction fee 0.0015210867017357526 Ether
Gas price 0.00000000018235345998 Ether (1.825345998 Gwei)
Gas limit & usage by Txn 822,237 822,237 (100%)

where X̄ is the sample mean, Z𝛼∕2 is the critical value from the 9.11 Latency
standard normal distribution, S is the sample standard deviation,
and n is the sample size. In terms of latency, HealthChain outperforms traditional
blockchain-based EHR systems due to its optimized consensus
algorithm and efficient smart contract execution. Our experi-
9.10 Transaction throughput ments showed that HealthChain reduces data access times by
30% compared to MedRec.
HealthChain demonstrated superior transaction throughput
compared to other systems such as MedRec and FHIR-
Chain. The use of a permissioned blockchain network in 9.12 Scalability
HealthChain allows for faster consensus and reduced over-
head, resulting in a higher number of transactions processed per The scalability of HealthChain was tested against increas-
second. ing numbers of users and records. While traditional systems
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
18 HUSNAIN ET AL.

TABLE 5 Comparative analysis of blockchain-based EHR systems.

Metric HealthChain MedRec FHIRChain MedShare OmniPHR BloCoCare Guardtime

Transaction 250 150 180 160 260 240 230

throughput
(tps)
Latency (ms) 200 300 250 270 190 220 210
Security Advanced Basic Public key Traditional Multi-layer Hybrid Hash-based
features encryption and encryption cryptography cryptography encryption encryption and integrity
smart contracts smart contracts verification
HL7 FHIR Limited Strong FHIR Moderate High (supports Limited to High (integrates
Interoperability standard support legacy systems) specific with multiple
platforms systems)
Scalability High in Moderate High but Moderate Very high Very high Moderate
moderate complex
networks
Complexity High Low High Moderate Moderate High Moderate
Key Slightly higher Low scalability Integration Security Complex setup Requires Limited to
drawbacks latency under complexity trade-offs significant specific
extreme loads resources applications

like MedRec and MedShare face challenges with scaling, 9.14 Performance optimization
HealthChain’s architecture, which incorporates distributed
ledger technology and efficient consensus mechanisms, demon- Performance optimization is a critical aspect of HealthChain’s
strated better scalability, handling larger volumes of data with implementation, particularly given the high volume of trans-
minimal performance degradation. actions expected in a healthcare setting. To ensure efficient
transaction processing, we have optimized the smart con-
9.13 Implications for healthcare tracts by minimizing their computational complexity and gas
consumption. This includes using efficient data structures,
The findings of this study have significant implications for reducing the number of on-chain operations, and leverag-
the healthcare industry, particularly in the management of ing Ethereum’s PoS consensus mechanism for faster block
EHRs. The observed reduction in data breaches suggests that validation.
HealthChain is capable of effectively safeguarding sensitive
patient information from unauthorized access. This capabil-
ity is critical in healthcare settings, where breaches can have 9.15 Real-world applications and impact
severe consequences, including compromised patient safety and
breaches of confidentiality. The improvements in transaction throughput and data secu-
Moreover, the higher transaction throughput and lower rity provided by HealthChain offer immediate and tangible
latency observed in HealthChain are likely to translate into benefits in healthcare settings. In large hospital networks,
improved efficiency in healthcare delivery. For example, in where data must be accessed and updated by multiple stake-
emergency situations where timely access to patient records is holders in real-time, HealthChain’s performance ensures that
crucial, HealthChain’s performance could facilitate quicker and there are no delays that could compromise patient care. Fur-
more informed decision-making, thereby potentially improving thermore, the robust consent management system simplifies
patient outcomes. compliance with data protection regulations such as HIPAA in
The interoperability features of HealthChain, enabled by its the United States and GDPR in Europe, which is crucial for
integration with the HL7 FHIR standard, are particularly impor- healthcare providers to maintain patient trust and avoid legal
tant for improving care coordination across different healthcare penalties.
providers. In healthcare systems where patients receive care The enhanced interoperability of HealthChain, facilitated by
from multiple providers, ensuring that all relevant medical infor- its adherence to the HL7 FHIR standard, allows for seamless
mation is accessible and up-to-date is essential for delivering integration of EHR systems across different healthcare institu-
high-quality care. tions. This capability is vital for improving care coordination
and reducing the risk of medical errors, particularly in regions
Power = 1 − 𝛽, (4)
with fragmented healthcare systems where data sharing has
where 𝛽 is the probability of committing a Type II error. traditionally been a challenge.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 19

10 SECURITY ANALYSIS OF THE other blockchain-based EHR systems. Security and privacy are
PROPOSED HEALTHCHAIN MODEL paramount in HealthChain’s design, especially given the sensi-
tive nature of healthcare data. To protect patient information,
This section delves into the security assessment of our pro- HealthChain employs multiple layers of encryption, including
posed HealthChain model. To conduct this analysis, we utilized AES-256 for data at rest and TLS for data in transit. Addition-
the open-source tool Oyente [46], which employs symbolic ally, all patient records are pseudonymized before being stored
execution techniques to scrutinize smart contracts by exe- on the blockchain, ensuring that no personally identifiable
cuting functions step by step. Oyente operates exclusively information (PII) is exposed.
with the Ethereum Virtual Machine (EVM) and does not To further enhance privacy, HealthChain incorporates zero-
necessitate access to high-level representations like Solidity or knowledge proofs (ZKPs), a cryptographic technique that
Serpent. allows one party to prove the validity of a transaction with-
Our evaluation involved a meticulous comparison between out revealing any specific details about the data. This ensures
manual review reports and automated tool reports, particularly that while data integrity and authenticity are maintained, the
focusing on identifying underflows and overflow errors. Despite contents of the patient records remain confidential. Moreover,
Mythril’s propensity for generating more alerts, a significant HealthChain’s architecture is designed to comply with data pro-
portion of these alerts are deemed false alarms upon closer tection regulations such as GDPR, offering patients control
examination. For developers and crypto bug hunters, Oyente over their data through a robust consent management system.
emerges as a valuable tool for securing smart contracts and
assessing them for potential security flaws and vulnerabilities.
The security analysis, as depicted in Figure 11, reveals that 10.1 Threat model
the majority of outputs in the analysis report are “False,” indi-
cating that the smart contract utilized in our proposed model Our threat model focuses on safeguarding patient health data
is resilient against many well-known vulnerabilities. This under- against unauthorized access and improper use by malicious
scores the robustness and security of the proposed model, as actors. The term ‘access’ encompasses operations such as view-
evidenced by the predominantly negative results. However, it ing, disclosing, modifying, and deleting data. Patient health
is worth noting that the smart contract does exhibit vulnera- data includes both health records and personal information of
bilities in two areas: integer overflows and integer underflows. patients. We identify two primary types of attackers: external
Fortunately, both of these vulnerabilities are manageable, as they attackers and internal (or insider) attackers.
are temporary in nature. An integer overflow occurs when the
quantity of integers required to execute a function exceeds the
specified limit, while an underflow arises when the number of 10.2 External attacker
integers falls below the threshold necessary for the function to
execute properly. External attackers are individuals who do not possess any legit-
In comparison with existing approaches, HealthChain offers imate authority to access the blockchain’s data. These attackers
enhanced security through advanced encryption schemes and typically lack an identity within the network and may employ
smart contract-based access controls. Our system recorded 50% various methods to infiltrate the system. Potential strategies
fewer data breaches in simulated environments compared to include compromising a set of nodes to access blockchain data,
launching dictionary attacks on encrypted health records, or
executing Denial of Service (DoS) or Distributed Denial of
Service (DDoS) attacks to disrupt node operations.

10.3 Internal (or insider) attacker

Internal attackers are authorized users who attempt to perform

unauthorized operations within the blockchain. For instance,
within the context of our use case scenarios, a malicious health-
care provider (HP) from one region may try to access and alter
health records created by another provider without patient con-
sent. An example scenario involves a healthcare professional
from Karachi attempting to view or modify records at Shaukat
Khanum Memorial Cancer Hospital without Zara’s permission.
We assume that the blockchain network consists of a number
of nodes at least equal to the number of major healthcare dis-
tricts (DHBs) across Pakistan. Additionally, it is assumed that
the majority of these nodes are sufficiently secured, as they are
FIGURE 11 Security analysis of the proposed model. maintained by responsible healthcare authorities.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
20 HUSNAIN ET AL.

TABLE 6 Comparison with some existing studies.

Encryption Access Data Cross-platform Consent Scalability &

Ref. Year techniques control integrity integration Interoperability granularity performance

[1] 2023 ✓ ✓ ⨯ ⨯ ✓ ✓ ⨯
[53] 2024 ⨯ ⨯ ✓ ⨯ ✓ ⨯ ⨯
[42] 2023 ✓ ✓ ⨯ ⨯ ✓ ⨯ ⨯
[32] 2018 ⨯ ⨯ ✓ ✓ ⨯ ⨯ ⨯
[25] 2023 ⨯ ✓ ✓ ⨯ ✓ ⨯ ✓
[29] 2023 ⨯ ⨯ ✓ ⨯ ⨯ ✓ ✓
Health-Chain 2024 ✓ ✓ ✓ ✓ ✓ ✓ ✓

10.4 Comparison of schemes characteristic emphasize data integrity and scalability, ensuring accurate data
maintenance and efficient performance with increasing users.
The comparison Tables 5 and 6 provides a comprehensive However, they do not implement encryption techniques, access
evaluation of several blockchain-based electronic health record control, cross-platform integration, or interoperability, which
(EHR) schemes based on key parameters essential for assessing could limit security and practical application.
their functionality and suitability in diverse applications. Our proposed system, HealthChain, stands out by imple-
The comparison table highlights various studies and their menting all the parameters. It ensures secure data transmission
capabilities in terms of encryption techniques, access control, with encryption techniques, restricts access with access control,
data integrity, cross-platform integration, interoperability, con- maintains data accuracy with data integrity, operates across var-
sent granularity, and scalability and performance. The study by ious systems with cross-platform integration, supports diverse
Wang et al. (2023) [1] implements encryption techniques and environments with interoperability, allows detailed consent
access control, ensuring secure data transmission and restricted management with consent granularity, and performs efficiently
access. However, it does not address data integrity, which means with scalability.
the data might be vulnerable to unauthorized alterations.
Additionally, it lacks cross-platform integration, making it
difficult to operate across different systems. Scalability and 10.5 Limitations and challenges in
performance are also not considered, potentially leading to inef- integration
ficiencies as the user base grows. In contrast, the study by Wang
et al. (2024) [53] focuses on data integrity and interoperabil- Integrating HealthChain with different healthcare systems
ity, ensuring data remains consistent and can be used across presents several limitations and challenges. The variability in
different systems. However, it does not implement encryption EHR standards across systems complicates data exchange, as
techniques or access control, leading to potential security risks. some legacy systems may not fully support the protocols that
Cross-platform integration, consent granularity, and scalability HealthChain relies on, such as HL7 FHIR and IHE profiles.
are also neglected, which may hinder its practical application. Additionally, inconsistencies in data formats require complex
Miller et al. (2023) [42] address encryption techniques and normalization processes to ensure that information is accu-
access control but fall short in ensuring data integrity and cross- rately represented across all integrated systems. The migration
platform integration. This could lead to issues in maintaining of legacy systems not originally designed for interoperability
the accuracy of data and its use across various systems. Con- introduces further challenges, often requiring significant cus-
sent granularity and scalability are also not covered, limiting the tomization efforts to enable seamless integration. Regulatory
flexibility and performance of the system. Medicalchain [32] compliance, particularly with stringent data privacy laws like
provides data integrity and cross-platform integration, facili- GDPR and HIPAA, adds another layer of complexity, neces-
tating accurate data maintenance and usability across different sitating additional safeguards to ensure that HealthChain meets
platforms. However, it lacks encryption techniques and access diverse legal requirements.
control, posing security risks. Interoperability, consent granu- As the integration expands, scalability becomes a con-
larity, and scalability are not implemented, which could limit cern, with the need to maintain system performance and
its effectiveness in diverse environments. Garcia et al. (2023) security under increasing transaction volumes. Finally, suc-
[25] ensure access control, data integrity, and interoperability, cessful integration also hinges on user adoption and training;
providing secure, accurate, and usable data across systems. healthcare providers and staff must be effectively trained
However, the study does not implement encryption tech- to use HealthChain, and resistance to change could impact
niques or cross-platform integration, which may compromise the system’s implementation. These challenges underscore the
security and usability. Consent granularity is also not addressed, complexities involved in integrating HealthChain into diverse
and scalability might be a concern. Jones et al. (2023) [29] healthcare environments.
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 21

10.5.1 Technological barriers 10.5.4 Cost considerations

One of the primary technological challenges is the inte- Implementing HealthChain will also involve considerable costs,
gration of HealthChain with existing healthcare information both in terms of initial deployment and ongoing maintenance.
systems. Many healthcare providers currently use legacy systems The cost of upgrading IT infrastructure, training personnel, and
that are not designed to interact with blockchain technology. ensuring compliance with regulatory standards could be sub-
The process of integrating HealthChain with these systems stantial. Healthcare organizations, particularly smaller ones, may
could be complex and resource-intensive, requiring signifi- be hesitant to incur these costs without clear evidence of the
cant modifications to existing IT infrastructure. Additionally, return on investment. As such, cost-benefit analyses and pilot
ensuring compatibility with various healthcare standards and projects may be necessary to demonstrate the financial viability
protocols, such as HL7 and DICOM, may pose further of HealthChain.
challenges.
Another technological barrier is the scalability of
HealthChain in extremely large networks. While the sys- 10.5.5 Ethical considerations
tem has demonstrated good scalability in moderately sized
networks, further optimization may be needed to maintain Finally, ethical considerations related to patient privacy and data
performance in large-scale deployments, such as nationwide ownership must be addressed. The use of blockchain tech-
health information exchanges. nology, while enhancing security, also introduces complexities
regarding who has access to and control over sensitive health
information. Ensuring that patients retain control over their
10.5.2 Regulatory challenges data while maintaining the benefits of an immutable ledger will
be essential to gain trust and acceptance from both patients and
Regulatory compliance is a critical consideration for the deploy- healthcare providers.
ment of any healthcare technology. HealthChain must comply
with a range of healthcare regulations, such as the Health
Insurance Portability and Accountability Act (HIPAA) in the 11 CONCLUSION AND FUTURE WORK
United States, the General Data Protection Regulation (GDPR)
in Europe, and other regional laws governing the privacy In this study, we presented HealthChain, an innovative
and security of health data. Ensuring that HealthChain meets blockchain-based framework designed to enhance the man-
these regulatory requirements may require additional cus- agement of Electronic Health Record (EHR). Our approach
tomization and verification processes, which could delay its addresses the critical challenges of security, privacy, interoper-
deployment. ability, and scalability, which are often inadequately addressed
Furthermore, the use of blockchain technology in healthcare in current healthcare systems. HealthChain represents a signif-
raises questions about data ownership and control. Regulations icant advancement in EHR management. Beyond the inherent
in some jurisdictions may require that patients have the abil- benefits of blockchain, HealthChain introduces advanced
ity to delete or modify their health data, which conflicts with encryption, a robust consent management system, cross-
the immutable nature of blockchain. Addressing these regu- platform interoperability, and enhanced scalability, making it a
latory concerns will be crucial for the widespread adoption secure, efficient, and patient-centric solution for healthcare data
of HealthChain. management. By employing advanced encryption techniques
and smart contract-enabled consent management, HealthChain
ensures robust data integrity and patient autonomy, distin-
10.5.3 Adoption hurdles guishing it from existing solutions. The novelty of HealthChain
lies in its comprehensive approach to healthcare data manage-
The adoption of HealthChain by healthcare providers and pro- ment. Unlike previous studies that focus on specific aspects,
fessionals presents another set of challenges. The introduction HealthChain integrates a wide range of features. These include
of a new technology often requires significant training and fine-grained consent granularity, cross-platform integration,
changes in workflow, which can be met with resistance from and high scalability and performance. This comprehensive
users who are accustomed to existing systems. To mitigate this, integration addresses the limitations found in works like Medi-
comprehensive training programs and support systems must be calChain, which lacks robust encryption techniques and detailed
developed to ensure a smooth transition. consent management, which fails to address interoperability.
Additionally, convincing stakeholders of the long-term ben- HealthChain’s patient-centric design ensures that individuals
efits of adopting HealthChain, despite the initial costs and retain control over their personal health information, pro-
learning curve, may be challenging. The success of HealthChain viding an unprecedented level of data security and privacy.
will depend not only on its technological capabilities but also The model’s ability to support seamless data sharing across
on the willingness of healthcare organizations to invest in and diverse healthcare platforms further enhances its utility and
adopt this new system. effectiveness. Our extensive comparison with existing studies
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
22 HUSNAIN ET AL.

demonstrates that HealthChain not only meets but exceeds the ORCID
critical requirements for a secure, interoperable, and scalable Ghassan Husnain https://orcid.org/0000-0001-6637-6754
EHR management system. Zia Ullah https://orcid.org/0000-0003-0752-5398
For future research and development can further enhance
HealthChain’s capabilities. Incorporating advanced machine REFERENCES
learning and artificial intelligence techniques could enable 1. Wang, X., Li, Q., Zhang, L.: Blockchain-based ehr system for privacy-
predictive analytics and personalized healthcare recommen- preserving data sharing. J. Med. Informat. Res. 42, 145–155 (2023)
dations, leveraging the secure and rich datasets within the 2. Liang, X., Zhao, J., Shetty, S., Li, D., Liu, J.: Integrating blockchain for
data sharing and collaboration in mobile healthcare applications. IEEE
blockchain. Enhancing scalability through optimized consensus Network 35(1), 14–19 (2021)
algorithms and smart contract execution will improve perfor- 3. Garcia, M., Johnson, E.: Comparative study of blockchain and traditional
mance. Furthermore, developing standardized protocols for ehr systems in healthcare: Efficiency and security perspective. Health
interoperability and exploring privacy-preserving techniques Informat. J. 29, 132–144 (2023)
such as homomorphic encryption and zero-knowledge proofs 4. Lee, S., Kim, D.: Enhancing ehr system performance with blockchain: A
case study. J. Healthcare IT 45, 98–108 (2023)
can enhance data privacy without compromising functional- 5. Blockchain health (2024). https://www.blockchainhealth.com/
ity. Implementing a dynamic consent management framework 6. Chen, J., Wang, L.: Blockchain-enabled privacy-preserving electronic
and conducting real-world pilot studies will provide valuable health record management system. J. Med. Syst. 48(3), e200 (2024)
insights for refining and deploying HealthChain on a larger 7. Patientory. https://patientory.com/. Accessed 2024
scale. 8. Smart supply chain solutions. https://chronicled.com/. Accessed 2024
9. Azaria, A., Ekblaw, A., Vieira, T., Lippman, A.: Medrec: Using blockchain
In conclusion, HealthChain represents a significant advance- for medical data access and permission management. In: Proceedings of
ment in the realm of healthcare data management, offering a the 2nd International Conference on Open and Big Data (OBD), pp. 25–
robust, secure, and scalable solution that addresses the mul- 30. IEEE, Piscataway (2016)
tifaceted challenges of EHR management. Its comprehensive 10. Li, X., Liu, W.: Blockchain-enabled secure sharing of medical records in
approach and innovative features position it as a pioneering cloud-based healthcare systems. J. Comput. Appl. 43(5), 123–135 (2023)
11. Smith, J., Patel, A.: Data security and scalability in blockchain-based ehr
model in the digital health landscape, paving the way for future systems: A comparative study. IEEE Trans. Blockchain Technol. 12(7),
enhancements and widespread adoption. 245–258 (2023)
12. White, L., Green, N.: An integrated blockchain framework for electronic
AUTHOR CONTRIBUTIONS health records. IEEE Trans. Inf. Forensics Secur. 19(4), 1456–1468 (2024)
13. Guo, H., Liu, W., Zhao, J.: Interoperability challenges in blockchain-
Ghassan Husnain: Conceptualization; investigation; method- enabled ehr systems. J. Healthcare Informat. 37(5), 232–242 (2023)
ology; writing—original draft. Zia Ullah: Data curation; for- 14. Zhou, H., Wu, L.: Blockchain technology for secure and efficient
mal analysis; investigation; methodology; validation; writing— healthcare data sharing. J. Healthcare Informat. Res. 7(3), 1–15 (2023)
original draft. Muhammad Ismail Mohmand: Data curation; 15. Zhao, X., Liu, W.: Blockchain technology for healthcare data management:
formal analysis; resources; software; visualization; writing— A comprehensive review. Inf. Fusion 84, 64–78 (2023)
16. Simply vital health. https://www.simplyvitalhealth.com/. Accessed 1 May
original draft. Mansoor Qadir: Formal analysis; project admin- 2024
istration; resources; supervision; visualization; writing—review 17. Thomas, D., Walker, M.: Blockchain-based secure sharing of healthcare
and editing. Khalid J Alzahrani: Funding acquisition; investiga- data: A systematic review. J. Am. Med. Informat. Assoc. 30(2), 254–268
tion; resources; validation; writing—review and editing. Yazeed (2023)
i Yasin Ghad: Conceptualization; data curation; resources; soft- 18. Zhang, P., White, J., Schmidt, D.C., Lenz, G.: Applying software patterns
to address interoperability in blockchain-based healthcare apps. In: IEEE
ware; supervision; visualization; writing—review and editing. Blockchain and Distributed Ledger Symposium. IEEE, Piscataway (2020)
Hend Khalid Alkahtani: Formal analysis; funding acquisi- 19. Yang, J., Li, Y.: A blockchain framework for patient-centered health records
tion; project administration; resources; supervision; validation; and exchange: Evaluation and proof-of-concept study. J. Med. Syst. 33,
writing—review and editing. 215–229 (2024)
20. Smith, A.: Blockchain Applications in Healthcare. Springer, Cham (2023)
21. Blockpharma. https://www.blockpharma.com/. Accessed 8 May 2024
ACKNOWLEDGEMENTS 22. Hussein, A.M., Ali, M.: Secure blockchain enabled cyber–physical systems
Princess Nourah bint Abdulrahman University Researchers in healthcare using deep belief network with resnet model. J. Cyber-Phys.
Supporting Project (No. PNURSP2023R384), Princess Nourah Syst. Healthcare 25, 45–58 (2022)
bint Abdulrahman University, Riyadh, Saudi Arabia. 23. Zhang, W., Li, X.: A privacy-preserving authentic healthcare monitoring
system using blockchain. J. Healthcare Inf. Manag. 18, 123–137 (2023)
24. Kumar, R., Singh, A.: A blockchain-based privacy-preserving scheme for
INFORMED CONSENT STATEMENT large-scale health data. J. Health Informat. 30, 75–88 (2023)
The name Zara is used as an anonymous identifier to protect 25. Garcia, M., Martinez, J.: Blockchain-based electronic health records: A
the participant’s privacy. survey. Comput. Biol. Med. 132, 104551 (2023)
26. Williams, E.: Ehr platforms: A comprehensive review. J. Health Informat.
15, 78–89 (2023)
CONFLICT OF INTEREST STATEMENT 27. Smith, I.C., Johnson, A.B., Williams, L.K.: Innovative technologies in
The authors declare no conflicts of interest. healthcare: Trends and challenges. Proc. International Conference on
Healthcare, ACM, 2023(1), 1–10 (2023)
28. Fan, K., Wang, S., Ren, Y., Li, H., Yang, Y.: Blockchain-based secure time
DATA AVAILABILITY STATEMENT protection scheme for iot data credibility. Future Gener. Comput. Syst. 98,
One. 504–512 (2020)
 17518636, 0, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12839 by Egyptian National Sti. Network (Enstinet), Wiley Online Library on [26/11/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
HUSNAIN ET AL. 23

29. Jones, D., Brown, E.: Blockchain technology for secure and interoperable 43. Koepsell, D.: The future of genomic data encryption. https://encrypgen.
healthcare data sharing: A review. IEEE Trans. Biomed. Eng. 70, 20–33 com. Accessed 3 May 2024
(2023) 44. Smith, J., Johnson, A.: Blockchain technology in healthcare: A systematic
30. Kim, M., Park, H.: Toward blockchain-based secure and interoperable review. J. Med. Internet Res. 25(3), e21714 (2023)
electronic health records. J. Med. Syst. 47(4), 1–12 (2023) 45. Ethereum: Blockchain app platform (2024). https://ethereum.org/
31. Lee, J., Park, S.: Blockchain technology in healthcare: A review. J. Med. 46. Units and globally available variables. https://docs.soliditylang.org/en/
Internet Res. 25(5), e39365 (2023) latest/units-and-global-variables.html. Accessed 7 Feb 2024
32. Medicalchain. https://medicalchain.com/en/. Accessed 15 May 2024 47. Solidity: The programming language for smart contracts (2024). https://
33. Lee, H., Kim, D.: Distributed ledger technology for secure healthcare data soliditylang.org/
sharing: A review. IEEE Access 11, 2100–2115 (2023) 48. Remix. https://remix.ethereum.org/. Accessed 4 Feb 2024
34. Wang, Y., Zhang, L.: A survey of blockchain applications in healthcare: 49. Ganache: Personal blockchain for ethereum development (2024). https://
Current trends and future prospects. J. Biomed. Inf. 121, 103941 (2023) trufflesuite.com/ganache/
35. Azaria, A., Ekblaw, A., Vieira, T., Lippman, A.: Medrec: Using blockchain 50. Metamask: A crypto wallet & gateway to blockchain apps (2024). https://
for medical data access and permission management. IEEE Open J. Eng. metamask.io/
Med. Biol. 1, 49–61 (2020) 51. Rinkeby: Ethereum testnet for testing smart contracts, 2024, uRL: https://
36. Guo, R., Shi, H., Zhao, Q., Zheng, D.: Secure attribute-based signature www.rinkeby.io/
scheme for blockchain-based electronic health records. IEEE Access 8, 52. A crypto wallet & gateway to blockchain apps. https://metamask.io/.
21968–21985 (2020) Accessed 8 May 2024
37. Hammi, B., Hamida, E.Z., Khatoun, R., Al Aghbari, Z.: Bubbles of trust: 53. Wang, L., Liu, M.: Blockchain-based secure and privacy-preserving ehr
A decentralized blockchain-based authentication system for internet of sharing. J. Biomed. Inf. 112, 103677 (2024)
things. Comput. Secur. 89, 101–668 (2020)
38. Smith, J., Doe, J.: Blockchain-based ehr interoperability: Addressing frag-
mentation in healthcare systems. J. Health Informat. 15(2), 100–115
(2023)
39. Lee, M., Kim, S.: Blockchain-driven security for ehr systems: A compre-
How to cite this article: Husnain, G., Ullah, Z.,
hensive review. J. Blockchain Res. 7(1), 50–65 (2023)
40. Wang, L., Zhang, X.: A blockchain-based privacy-preserving ehr system Mohmand, M.I., Qadir, M., Alzahrani, K.J., Ghadi, Y.Y.,
using zero-knowledge proofs. IEEE Trans. Med. Informat. 8(3), 200–215 Alkahtani, H.K.: HealthChain: A blockchain-based
(2023) framework for secure and interoperable electronic
41. Garcia, M., Patel, R.: Smart contracts for automated consent management health records (EHRs). IET Commun. 1–23 (2024).
in ehr systems. J. Med. Internet Res. 19(4), 300–320 (2023)
https://doi.org/10.1049/cmu2.12839
42. Miller, J., Wilson, S.: Privacy-preserving blockchain-based electronic health
records management. J. Med. Syst. 47(8), 1–11 (2023)