This article has been accepted for publication in IEEE Access.

This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

Digital Object Identifier

Blockchain-Based Processing of Health

Insurance Claims for Prescription Drugs
AYSHA ALNUAIMI1 , AMNA ALSHEHHI2 , KHALED SALAH2 , RAJA JAYARAMAN1 , ILHAAM A.
OMAR1 , AMMAR BATTAH1
1
Department of Industrial & Systems Engineering, Khalifa University of Science and Technology, Abu Dhabi, United Arab Emirates
2
Department of Electrical Engineering and Computer Science, Khalifa University of Science and Technology, Abu Dhabi, United Arab Emirates

ABSTRACT The current legacy system used in processing health insurance claims causes a huge amount
of financial loss every year due to fraud claims. It is also highly prone to privacy and security threats due
to the use of traditional methods. Health insurance claims for prescription drugs are one such claim that
is highly prone to being tampered with. Also, there is a lack of linkage in the prescription data between
the medical care provider and the pharmacy, which also leads to miscommunication and the use of false
prescriptions. In this paper, we propose processing health insurance claims for drug prescriptions using
blockchain technology that manages the processing of prescription drugs in a private, secure, trustworthy,
and decentralized manner. The proposed system utilizes a private Ethereum blockchain. The system
includes two smart contracts: registration and approval smart contracts, which provide traceability and
trustworthiness to the system. The system was integrated with off-chain storage (IPFS) and a fronted
decentralized applications (DApps), which improves the accessibility of centralized patient information by
authorized parties. To maintain the privacy of the data, a gateway is used to filter the data that can be viewed
by the participants. We present the system architecture, sequence diagrams, entity-relationship diagram, and
algorithms to demonstrate the working principles of the proposed process for processing health insurance
claims for prescription drugs using blockchain. The performance of the proposed solution is evaluated by
conducting security analysis and comparing it to the existing solutions. Our smart contract code is publicly
available on GitHub.

INDEX TERMS Blockchain, Ethereum, Insurance Claims, Prescription Drug, Smart Contracts,

I. INTRODUCTION insurance claims for prescription drugs are made. It is started

The health insurance sector has been increasingly studied to when a patient approaches a network hospital for cashless
improve the current crumbling traditional system. A health treatment. Then the registration begins, where the patient
insurance claim is a bill that represents a transaction between provides personal details and insurance information to the
a medical service provider and an insurance company to healthcare provider. After the registration, the care provider
cover the expenses of a patient obtaining a service, such as validates the patient’s details and insurance information, and
medical, pharmaceutical, and dental services. then the patient is referred to a physician to conduct the
There are two main types of health insurance claims: necessary diagnosis. Based on the diagnostic results, the
cashless and reimbursement. In the reimbursement type, the physician writes his medical codes and creates a prescription
patient pays out of pocket for all services rendered by the which is stored in the healthcare centralized system. A net-
physician or hospital, and the insurance provider reimburses. work pharmacy is notified when the prescription is uploaded
In cashless claims, the insurer directly covers all hospital- to the centralized system. The pharmacist then contacts the
ization expenses for the hospital. To receive the benefit of a health insurance company for prescription approval. The in-
cashless claim, an insured must be hospitalized exclusively surance company verifies the claim with their policy benefits
at a network hospital approved by the insurance provider. to evaluate coverage and eligibility. In this step, they verify
Cashless claims cover both planned and unplanned hospital- whether the patient has a deductible, accumulated co-pay, or
izations. In this research, we are considering cashless as it is out-of-pocket expenses, and they decide whether the medical
the most popular type of claim universally [1]. claim is valid and how much of the claim they will pay [2].
There are two scenarios based on the insurance company’s
Figure 1 shows a typical process flow of how health

VOLUME 4, 2016 1

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

FIGURE 1: Typical process flow for processing health insurance claim for prescription drug.

decision. The first one is an "approved claim" in which the US, 345 defendants were charged with fraud, which involved
pharmacist notifies the patient to collect medications and over 100 doctors, nurses, and medical professionals. Many
the claim is paid after the drugs are received. On the other laws and regulations have been enacted to address this issue,
hand, the claim may be rejected, and the pharmacist will ask but it remains a major challenge [8].
if the patient is willing to pay out of pocket or to cancel
Another issue is privacy and security. The insurance claim,
the prescription [3] [4].Recently, it came to the realization
as stated before, includes information about the patients,
that this system is struggling with many drawbacks, such as
which causes a major concern about the security of their
claim abnormality, security and privacy issues, time and cost
information. In the US, 50% of people are concerned about
consumption [5].
their medical data since they believe the healthcare system is
not properly prepared for cyberattacks. Furthermore, health-
The most significant disadvantage is claim abnormality,
care organizations ranked the lowest in cybersecurity among
which can be divided into three categories: fraud, abuse, and
seven other industries globally. It failed in almost all compo-
errors. A fraud claim is one that is purposefully deceived,
nents, such as security in the cloud environment, data center,
misrepresented, or concealed in order to obtain payment from
desktops, laptops, mobile devices, and others [7]. Also, it has
the insurance company. Abuse claims result in unnecessary
been reported by HIPPA journal that in the first quarter of
costs through the use of exorbitant or inappropriate medical
2018, there have been over 77 breaches of healthcare data,
services that do not align with acceptable business or medical
which caused data leakage of more than a million records.
practice. Errors are unintended mistakes made by one or
Although the number of attacks is decreasing, the severity of
some of the parties that cause improper payment [5]. These
them is worsening. The centralization of healthcare data con-
abnormalities cause major losses of money to governments
tinues to be a major threat [9]. The last challenge is the time
and insurance companies across the globe. A recent study
and cost of consumption. This traditional manual paperwork
suggests that fraud claims waste 15% of the total claims in
process takes time, effort, and money. It is estimated that
the insurance sector [6]. In the US, the Department of Health
$375 billion is wasted by insurance companies in paperwork
and Human Services Centers estimates healthcare fraud in
[7].
2010 to be between $77 billion and $259 billion [7]. In the
UK, it is reported that fraud insurance claims result in an Therefore, a novel system is highly required to overcome
annual loss of over one billion pounds. According to another the major baggage that is caused by the current insurance
report, the Indian industry loses between 6 and 8 billion INR claim system. A blockchain technology-based system is a
per year as a result of counterfeit claims [6]. The main cause strong candidate that will resolve the issues of security,
of all this money loss is that the current system is built on trust, and transparency due to its features like immutability,
trust. The insurance company trusts the information provided distribution, traceability, and decentralization. A blockchain
by the patient and the service provider [7]. In 2020 in the system validates and stores transactions in a decentralized
2 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

ledger. Data integrity is recognized as a key security chal- network to reach a consensus on the outcome after executing
lenge that affects both data transmission and data collection. payment transactions. The participants are from an open
To ensure data integrity, blockchain technology offers three network and are awarded by the payment of Bitcoins, which
essential conditions: immutability, transparency and trace- are "mined" through a cryptographic hash function named
ability of transactions. This ensures that data committed to Proof-of-Work (PoW).
the blockchain is immutable preserved even after moving to The success of Bitcoin led to the need for expansion in
new state in the ledger. As such, an audit trail that can be used blockchain applications. Smart contracts were introduced to
to ensure the validity and integrity of data. This is achieved by represent autonomous programs, as well as a new paradigm
the underlying hash mechanism, where a hash pointer points of Decentralized Applications (DApps) that run on top of
to the previous block in the blockchain. If a block of data is blockchains and include many smart contracts. The Ethereum
tampered with the hash would change, which would in turn system was launched to support smart contracts. It offers its
change the hash of all the proceeding blocks as each block own cryptocurrency named Ether, and it uses an account-
contains the hash of the previous block [21]. To the best of centered model. Many applications, including artificial in-
our knowledge, there is a lack of work on smart systems for telligence, the Internet of Things, and digital assets, have
medical prescription processing, especially blockchain-based successfully adopted Ethereum.
solutions. This paper proposes a blockchain-based insurance The Ethereum architecture has four main layers; the ap-
claim for prescription drug processing systems to eliminate plication layer, the data layer, the consensus layer, and the
fraud cases. The main contributions of this paper are as network layer. All these layers are served up with an environ-
follows: ment layer. All the mentioned layers are briefly explained as
• We propose a private Ethereum blockchain-based solu- follows:
tion to automate health insurance claim processes for
prescription drugs in a fully decentralized, traceable, 1) The Application Layer
transparent, private, secure, and trustworthy manner. There are three main components in this layer: accounts,
• We present detailed algorithms depicting the interac- smart contracts, and EVM. There are two types of accounts:
tions among stakeholders including sequence diagrams externally owned accounts (EOA) and contract accounts. An
that explain the proposed solution for processing health EOA is used to maintain a user’s funds in Wei. It is associated
insurance claims. and addressed by a public key. The EOA is accessed by
• We develop two smart contracts in regards to health authenticating the ownership of a private key. On the other
insurance claims for prescription drugs. hand, contract accounts are associated with smart contracts.
• We evaluate our proposed model and our developed Smart Contracts are executable bytecode that defines busi-
smart contracts using security analysis to demonstrate ness requirements. These two accounts have a dynamic state,
the robustness of our proposed solution against major which is defined by:
security vulnerabilities. • Nonce: Tracks the number of contract transactions ini-
• We compare our proposed approach with other solutions tiated by the owner of EOA or created by the contract
demonstrating the advantages and feasibility of our ap- account
proach. • Balance: The amount of wei in a particular account

The rest of the paper is structured as follows. Sections II • Storage Root: The hash of the root of a contract account

and III present the background and related work, which is storage data structure. It records the contract’s state
classified into two categories, namely, blockchain and non- variable
blockchain-based health insurance claim solutions. Section • Code Hash: The hash value of a contract account’s

IV describes the proposed blockchain-based solution for bytecode

health insurance claims for prescription drugs. Sections V Smart contracts are the building blocks of DApps. A
and VI present the implementation, testing, and validation DApp consists of smart contracts at the back-end and a
details of the proposed solution. In Section VII, we conduct user interface at the front-end. There are many DApps
the security analysis of the proposed approach. Section VIII built on Ethereum, including finance, gambling, governance,
is a summary of our results and concluding remarks. exchange, and wallet applications. Several DApps provide
their own cryptocurrency, named tokens. EVMs are used
II. BACKGROUND to execute smart contracts. They are quasi-turning-complete
In this section, we briefly introduce blockchain technology machines using a stack-based architecture.
and expand the explanation of Ethereum.
Blockchain technology was first introduced in 2008 as a 2) The Data Layer
distributed and public ledger. It records payment transactions A transaction is the commerce between a sender (EOA)
between two parties in a peer-to-peer (P2P) network without and a recipient (another EOA or contract account). Every
a trusted third party (e.g., a bank). Initially, the blockchain transaction has:
system only offered payment services based on the consensus • Nonce: A counter to track the number of transactions
protocol. This protocol allows distrusting nodes in a P2P initiated by the sender
VOLUME 4, 2016 3

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

FIGURE 2: High-level system architecture of the health insurance claims using ethereum smart contracts

•Recipient: Indicates the transaction’s destination (con- two main consensus protocols; proof-of-work and proof-
tract account of EOA) of-stake. Currently, Ethereum uses the GHOST consensus
• Value: The amount of currency in Wei to be sent from protocol, which is a proof-of-work protocol run by miners
the sender to the recipient who compete to solve the mathematical puzzle and create
• Input: The transaction-related data new blocks with successfully processed transactions to link
• Gas Price and Gas Limit: The unit price and maximum them with current blocks. The winner shares the block with
amount of gas that the sender is willing to pay to the the network and earns ethers. According to this protocol, the
winning miner main chain is the chain with the heaviest branch. It is the
• (v, r, s): the Elliptic Curve Digital Signature Algorithm branch with the highest cumulative block difficulty.
(ECDSA) signature of the sender
Once a transaction is executed, the states of the accounts 4) The Network Layer
involved are updated, and hence the blockchain is updated. Ethereum has a peer-to-peer network. Each peer (node)
The data structure for storing Ethereum blockchain data shares and stores information about the entire network. For
is known as a trie. It stores (key, value) pairs. A key is node discovery and routing purposes, each node maintains
the path from the root to a leaf node while the value is a dynamic routing table of 160 buckets, and each bucket
contained within the leaf node. A block header could point contains up to 16 entries of other nodes’ IDs, IP addresses,
to a state trie, a transaction trie, and a receipt trie. Each and UDP/TCP ports. To find target clients, Ethereum uses
contract account uses a separate storage trie to bookkeep the RLPx protocol, and it uses the Ethereum Wire Protocol
the persistent data of the contract. Since the state of the to facilitate the exchange of information between clients.
blockchain dynamically changes, Ethereum has one state trie.
5) The Environment
3) The Consensus Layer The Ethereum blockchain operates in a four-layer envi-
This layer regulates the generation and verification of a block. ronment: a web interface for clients to use the Ethereum
This is done by enforcing network rules for the nodes to blockchain; a database to store all the clients’ blockchain-
reach consensus about the broadcast transaction. There are related data; cryptographic mechanisms for security reasons;
4 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

and the Internet infrastructure to facilitate blockchain com- calculations on this data. However, if n-t or more servers are
munications between peers [10]. truthful, n servers will be unable to learn anything from the
patient’s expenditure data recorded on the blockchain. Fur-
III. RELATED WORK thermore, they proposed that MIStore use Practical Byzan-
In this section, we discuss the existing solutions that tine Fault Tolerance (PBFT) as the blockchain consensus
have been proposed to address the important challenges scheme, with all relevant data stored on the blockchain. The
in processing health insurance claims. We considered both blockchain platform severely limits MIStore’s efficiency.
blockchain and non-blockchain-based approaches. The authors in [14] aim to build a structure for an efficient
way to handle security-related exchanges that relies on the
A. NON-BLOCKCHAIN-BASED SOLUTIONS blockchain-driven phase. They developed various sponsor-
In the non-blockchain section, we will highlight various based smart contracts for various policies. A Hyperledger
approaches that were conducted to enhance the processing of fabric is used as the blockchain framework in this case. The
health insurance claims. One of these approaches is the im- proposed system is primarily intended to eliminate fraud and
provement of decision tree classifier accuracy for healthcare risks in the existing system by employing the concept of a
insurance fraud prediction by using the Extreme Gradient proof-of-work algorithm in order to make the system more
Boosting algorithm. In [11], the authors intend to examine secure. The proposed blockchain distribution platform’s de-
statistical modeling methods that use cutting-edge technol- velopment goal is to execute insurance claims from insurance
ogy to evaluate bogus health benefits. The proposed decision companies as smart contracts and update the results in the
tree algorithm method does not require normalization and system. The proposal is divided into three modules: registra-
thoroughly analyzes each branch to identify decision nodes tion, treatment, and claims. Insurance claims are divided into
that require further investigation. Random forest and extreme three categories: stakeholders, patients, and hospitals.
gradient boosting are included in the algorithm. A decision Moreover, in [15] the authors considered two of the most
tree-based classification learning algorithm uses a gradient common fraud scenarios: patient theft of limited health in-
boosting framework to improve weak learners and perform surance benefits and the use of multiple insurance policies
cache hardware optimization by reserving an internal buffer for additional benefits. They defined a conceptual model
for each thread to save statistics gradient. However, the ex- in which misleading information can be eliminated in ac-
treme gradient boosting is hard to tune and almost impossible cordance with the HIPAA privacy rules established by
to scale up. In addition, it lacks scalability due to its slowness. the United States Department of Health and Human Ser-
In [12], the authors combined graph mining, social net- vices. They use BigchainDB technology, which provides the
work analysis, and data visualization. This combination aided blockchain’s public functions.
in the transformation of a visual pattern discovered during The above-mentioned blockchain-based contributions ex-
the data exploration phase into a network model that reveals plain how blockchain can enhance the current health insur-
underlying mutual referrals from the claims database, allow- ance system and eliminate several frauds. However, in some
ing for an in-depth, scalable analysis of such relationships. of these papers, the smart contracts are not fully investigated.
They examined a dataset containing only claims relating In addition, the testing and results of the proposed model are
to physician-performed procedures. As a result, the claims not fully described. In other words, the full implementation
data can be mapped into a social network by considering of the solution was not established.
connections between healthcare professionals or patients.
They demonstrated how information visualization and social IV. BLOCKCHAIN-BASED SOLUTION FOR PROCESSING
networking techniques can be used to analyze health insur- HEALTH INSURANCE CLAIM OF PRESCRIPTION DRUG
ance claims data, primarily by mapping physicians using In this section, we introduce a blockchain-based solution
shared patients as a proxy. However, this technique of social to process health insurance claims for prescription drugs in
networking lacks immutability. a tamper-proof, secure, private, confidential, and trustable
manner. The system is built on a private Ethereum blockchain
B. BLOCKCHAIN-BASED SOLUTIONS to ensure confidentiality and privacy of records as it contains
In [13], MIStore system has been proposed. It is a sensitive information about patients. Therefore, a permis-
blockchain-based health insurance storage system that op- sioned blockchain can be viewed only by authorized entities.
erates on the Ethereum platform. In a basic instance of the Figure 2 illustrates the high-level system architecture of
system, there is a hospital, a patient, an insurance company, the proposed blockchain-based approach. As it is shown
and n servers. The hospital implements a threshold (t, n) in the figure, there are two smart contracts: the registra-
MIStore protocol between n servers. Any node may become tion smart contract and the approval smart contract. These
some hospital’s server if both the node and the hospital agree. smart contacts can be accessed by authorized actors through
Moreover, the hospital stores patient consumption data on the Fronted Decentralized Applications (DApps). In addition, the
blockchain and protects it with n servers. Any t-server can system architecture includes an application programming in-
assist insurance companies in obtaining the sum of a subset terface (API), such as JSON RPC, Web3 and Infura. APIs can
of patient cost data, and the server can perform homomorphic be used as linkers between smart contracts and the software
VOLUME 4, 2016 5

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

FIGURE 3: Sequence diagram of all interactions in the proposed solution.

devices that access them ( Dapps). Moreover, there is an off- in processing health insurance claims for prescription
chain storage system, IPFS, that is used to store large-sized drugs, granting them access to restricted functions in
files. Also, in order to maintain privacy within the network, the smart contracts. Also, they will have access to the
a gateway has been added to filter what can be accessed by information that is stored on chain and off chain.
patients. In other words, patients will be able to see their own • Decentralized Storage Systems: We utilize a dis-
data to maintain other patients’ privacy. The components of tributed peer-to-peer file system to enhance the storage
the proposed solution are described below: capabilities of the system and increase its scalability.
In specific, we focus on Interplanetary File System
• Actors: The main stakeholders of the system are the (IPFS) which is one of the most common distributed
regulatory authority, patient, physician, pharmacies, and P2P file systems. The file system stores data persis-
insurance company. Each entity will play a unique role
6 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

FIGURE 4: Entity-relation diagram of smart contacts and participants

tently, as it is distributed among several participants. harmoniously to maintain the required security features
Furthermore, IPFS storage is immutable as the data as well as meeting scalability needs, by relieving the
is content-addressable, meaning that a change in con- blockchain from processing and storing large amounts
tent changes the corresponding address. The content of data. Participants of the systems would simply access
on IPFS pointed to using a content identifier (CID), the data on IPFS through the index on the blockchain,
which is a cryptographic hash of the data [20]. This knowing that the data is tamper-free.
complements the nature of the blockchain, as such, a Since IPFS is public P2P system aimed to resist cen-
CID is usually submitted on-chain while large files are sorship and tampering, securing data would need to
stored on the IPFS. Since both the blocks and the link be implemented on top of it. The owner of the data
to the content are immutable, integrity is guaranteed would encrypt the data using a symmetric key as it is
as well as authenticity since transactions are signed fast and proceeds to encrypt the symmetric key using
by participants. Furthermore, the IPFS can store large the recipients public key. As such, we take advantage
volumes of data as the network grows, unlike traditional of the light symmetric encryption while still providing
storage systems that are limited by owned physical the asymmetric security properties. The recipient can
assets. As such, both the blockchain and IPFS work simply proceed to download the data and decrypt it

VOLUME 4, 2016 7

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

using their private key. Such an approach has been Once the prescription is created, the physician will upload
discussed in a previous work [23]. the IPFS hash to the smart contract and an event will be sent.
• Ethereum Distributed Ledger: The Ethereum dis- The patient will select from a list of network pharmacies
tributed ledger is the main component of the system. and an event will immediately be emitted. The pharmacies
It contains all transactions, logs, and events that are must confirm that the medicines are available and they can
recorded in a tamper-proof manner. Thus, that ledger process the prescription. In the event that multiple phar-
ensures traceability, transparency, and accountability of macies send confirmation to process the prescription, the
health insurance claims. Moreover, the private Ethereum approval smart contract will select one pharmacy based on
blockchain adds privacy, confidentiality, and authoriza- the FIFO method and announce the Ethereum address of the
tion. selected pharmacy. Then, the selected pharmacy will request
• Ethereum Smart Contracts: There are two smart con- approval from the insurance company in order to process the
tacts in the system: registration and approval. The regis- prescription, and an event will be emitted upon that request.
tration smart contract is responsible for giving permis- The insurance company will evaluate the approval request
sion to the system’s stakeholders, where they are regis- based on their policies and the patient’s plan and coverage.
tered by regulatory authority. The second smart contact, If the request is approved, the pharmacy will prepare the
approval, is responsible for processing the claim of a medicines for collection and an event will be sent. The patient
prescription drug, starting from creating the prescription will collect the medication and an event will be emitted. Once
until the claim is paid by the insurance company. the medication is collected, the pharmacy will send a claim to
• Blockchain Clients: The blockchain client is used as be paid by the insurance company. On the other hand, if the
an access point between the Ethereum blockchain and request is rejected, an event of the rejection will be emitted.
the front-end DApp, which enables the latter to fetch
events and logs from the blockchain and display them to B. PERMISSIONED BLOCKCHAIN
the user/patient. Another role of the blockchain client is In a sensitive domain such as healthcare, exposure, tampering
ensuring that only authorized nodes participate in their or loss of data can be detrimental. As such, we proposed a
assigned network and validate transactions, and this private permissioned Ethereum blockchain with the focus on
ensures that unauthorized entities have no access to the achieving privacy, confidentiality and access control. Unlike
logs and history of the private transactions. Each entity the public Ethereum mainnet, deployers get to build the pri-
requires a client and it enables them to run consensus vate blockchain using Ethereum clients such as Hyperledger
across the participants and set the details of encrypted Besu and GoQourom. We do not confine our solution to
communication, open-source examples of such clients a specific implementation of the private blockchain as to
are Besu1 and GoQourom2 . Clients can also have multi- not restrict the offered customizability, we utilize concepts
tenancy where an establishment has its own client to common to private blockchains. Authenticity of transactions
manage their data. As such, they are able to filter who is maintained similarly between public and private where a
is able to access shared information through the help transaction is signed using the public key of the sender. In a
of Private Transaction Managers (PVMs). For instance, permissioned chain, users are authenticated by a trusted au-
a doctor has access to medical records to several pa- thority through their submitted digital certificate. Ethereum
tients from the hospital database, but a patient is only clients are paired with a PVM, commonly Tessera3 , which
given access to their own medical records. Therefore, offers flexible privacy of transactions on the network. The
selective access to data is achieved through utilization PVM allows the sender to specify privacy groups or send
of blockchain clients. directly to a single receiver. It extends to what transactions
participants can read or save, and what nodes they are al-
A. SEQUENCE DIAGRAM OF THE PROPOSED lowed to connect to. Since private transactions are encrypted,
BLOCKCHAIN-BASED SOLUTIONS any associated data is kept confidential, which is desired for
The interactions among the stakeholders, smart contracts, and sensitive information such as the patient data. This extends
storage systems are represented in this subsection. to data stored off-chain which is encrypted on the distributed
Figure 3 demonstrates the sequence diagram of all inter- storage. Furthermore, private blockchains can employ several
actions in the proposed system. The sequence starts with consensus protocols, most notably proof-of-authority (PoA)
deploying a registration smart contract where a regulatory protocols which can be efficiently employed since stakehold-
authority is responsible for registering all entities. Then, the ers are authenticated and can be assigned their appropriate
process of issuing a prescription drug is started by deploying authority4 . Moreover, the authenticated participants are given
the approval smart contract. A patient will visit a network different authorization levels based on their role. This is
hospital for treatment, and after conducting the necessary achieved by the smart contract which restricts the ability
diagnostics, the physician will create an IPFS prescription.
3 https://docs.tessera.consensys.net/en/stable
1 https://besu.hyperledger.org/en/stable 4 https://besu.hyperledger.org/en/stable/private-networks/how-
2 https://consensys.net/docs/goquorum//en/latest to/configure/consensus/

8 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

to execute functions based on authority of the caller. The Algorithm 1: Registration

aforementioned concepts facilitate trust within the consor- Input: Entity EA
tium, maintaining transparency and privacy as required. Our 1 if caller == regulatory_authority then
solution makes use of both the intrinsic blockchain character- 2 Add Entity EA to the authorized Entities
istics and the customizable permissioned private blockchain 3 Emit an event declaring the details of the entity
features. registration process
4 else
V. IMPLEMENTATION OF THE PROPOSED MODEL 5 Reject.
In this section, we introduce the developed algorithms and 6 end
implementation details of the proposed blockchain-based // Entity registration is completed
solution to process insurance claims for prescription drugs.

A. IMPLEMENTATION DETAILS
The proposed solution is built on a private Ethereum be the physician. The patient ID, Drugs CRN, and IPFS
blockchain, so only authorized entities can access and ex- hash will be the inputs. Once the prescription is created, the
ecute functions. Only the assigned regulatory authority is physician will upload the IPFS hash. Then, an event will be
allowed to execute the registration smart contract to register broadcast to declare that the prescription has been created
all the different entities that can execute their corresponding and uploaded.
functions in the approval smart contract. Algorithm 3 demonstrates the pharmacy selection process.
The entity-relationship diagram of all attributes and func- To execute the P harmaciesSelection function, the caller
tions of smart contracts and authorized entities is depicted must be the patient and the selected pharmacies should be
in Figure 4. The registration smart contract has only one registered. Moreover, the number of chosen pharmacies by
regulatory authority, therefore it is declared as an address. the patient should be ≤ 5. If these conditions are met, then
While the others are declared as mapped, which means that the ApprovalState is shown as "pending" which means that
there are multiple physicians, pharmacies, and insurance approval is needed to confirm that the pharmacy can process
companies in the system that can execute the same functions. the prescription. The registered pharmacy that is selected by
The regulatory authority deploys and executes the registra- the patient can execute the P harmacyApproval function to
tion functions of all authorized entities. The approved smart update the ApprovalState to be "Approved" and an event
contract’s attributes and functions are listed in the diagram. will be emitted.
There are different enumerating variables in the approval
smart contract, including ApprovalRequestState that contains Algorithm 2: Prescription Creation
different states of pharmacy confirmation, such as "Pending" Input: PatientID,Drug1CRN,Drug2CRN,
and "Approved". In addition, InsuranceApprovalStates con- Drug3CRN, IPFSHash
tains different states of approval requests, such as "Pending", 1 if (caller == P hysician) then
"Approved" and "Rejected". Moreover, MedicineCollection- 2 Add IP F Shash
State can be "ReadyForCollection" or "Collected". Further- 3 Emit an event declaring the prescription has been
more, the paymentState is either "pending" or "paid". Finally, created and uploaded
as there is only one registration smart contract and multiple 4 else
approval smart contracts, the relationship is represented as 5 Reject.
1:n. 6 end
// The physician creats and uploads
B. ALGORITHMS prescription
The major algorithms are illustrated below to clarify the
concept behind the two smart contracts, registration and
approval. Algorithm 4 illustrates the insurance approval. The se-
The registration smart contract is deployed by the regu- lected pharmacy will execute the RequestInsuranceApproval
latory authority and all authorized entities are registered by function to request approval from the insurance company in
running their corresponding functions. The registered entity order to process the prescription. If the caller is the selected
will have permission to execute their respective functions in pharmacy, then the InsuranceApprovalState is shown as
the approval smart contract later. Algorithm 1 illustrates the "Pending" and an event is broadcast to declare that approval
registration phase of . If the caller is the regulatory authority, is requested. After that, the InsuranceApproval function
then the entity’s Ethereum address will be added to the is executed if the caller is the insurance company and
authorized entity and an event will be emitted to declare the the InsuranceRequestState is "Pending". The insurance
details of each entity’s registration process. company can approve or reject the request. If the request
Prescription creation is explained in Algorithm 2. To exe- is approved, then the InsuranceApprovalState will be
cute the P rescriptionCreation function, the caller should updated to be "Approved" and an event will be emitted. If
VOLUME 4, 2016 9

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

Algorithm 3: Pharmacy Selection

Algorithm 4: Insurance Approval
Input: Pharmacy Address
1 ApprovalRequestState is a customized enumerate
1 InsuranceApprovalState is a customized enumerate
variable that describes different states of the request variable that describes different states of the
if (caller == insurance approval request
patient)∧(selectioncounter[msg.sender] < 5) 2 if (caller ∈RegisteredPharmacies) then
(registeredP harmacy(P harmacyaddress) == 3 InsuranceApprovalState=pending
true) then 4 Emit an event declaring that Approval is
2 selectioncounter[msg.sender] += 1 requested
5 else
ApprovalState=P ending
6 Reject.
3 Emit an event declaring that pharmacies are
7 end
selected
4 else // Approval is requested by the
5 Reject. selected pharmacy
6 end 8 if (caller == Insurance_Company) ∧
7 if (caller ∈RegisteredPharmacies)∧(ApprovalState (InsuranceApprovaltState==pending) then
==P ending) then 9 if ApprovalRequestState==Approved then
8 for i = 0; i < 10 Emit an event declaring that prescription has
selectioncounter[patient]; i++ do been approved
9 if (P harmaciesSelection[patient][i] 11 end
∈RegisteredPharmacies)∧ 12 if ApprovalRequestState==Rejected then
(P harmaciesSelection[patient][i]== 13 Emit an event declaring that prescription has
true) then been rejected
14 end
10 ApprovalState=Approved
15 else
11 end
16 Reject.
12 Emit PharmacyEligible
17 end
13 Emit Approved
18
14 end
15 Emit PharmacyIneligible
16 else

17 end Algorithm 5: Medication collection

// the selected pharmacy confirmed Input: patientID, IPFShash
they can process the prescription 1 MedicineCollectionState is a customized enumarate
variable that describes different states of the
Medicine collection
2 if (caller∈RegisteredPharmacies)∧
not, the InsuranceApprovalState will be "Rejected" and (InsuranceApprovalState ==Approved) then
an event will be emitted. 3 M edicationCollectionState =
Medication collection is described in Algorithm 5. In ReadyF orDelivery
order to execute the function of M edicationP reparation, 4 Emit an event declaring that medication is
the caller must be the selected pharmacy and the prepared and ready for delivery
InsuranceApprovalState must be "Approved". If these 5 else
conditions are met, the pharmacy will prepare the medication 6 Reject.
for collection, and then the M edicationCollectionState 7 end
will be "ReadyForCollection" and an event will be emit- 8 if (caller==patient)∧
ted to declare that the medication is prepared and ready (M edicationCollectionState ==
to be collected. The patient will collect the medication if ReadyF orCollection) then
the M edicationCollectionState is " ReadyForCollection". 9 UpdateM edicationCollectionState = collected
Once it is collected , the state will be updated to "Collected". 10 Emit an event declaring medication collection
Finally, Algorithm 6 shows the final stage where the details
pharmacy will execute the P aymentRequest function and 11 else

that requires the M edicationCollectionState to be "Col- 12 Reject.

lected". Then, the P aymentState is shown as "Pending" 13 end

and an event is emitted to show the payment request details. // The patient collects the
Once the P aymentState is "Pending", the ClaimP ayment medicines
function is executed by the insurance company, and the
10 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

Algorithm 6: claim payment Table 1. The transactions and logs of the main functions are
Input: MedicationInvoiceID,Drugtotalcost shown below.
1 PaymentState is a customized enumarate variable that
describes different states of the claim payment
2 if (caller ∈RegisteredPharmacies)∧
(M edicationCollectionState == collected) then
3 P aymentState = P ending
4 Emit an event declaring the payment request
details
5 else
6 Reject.
7 end
// A claim is send to insurance
company
8 if (caller
==Insurance_Company)∧(P aymentState ==
P ending)∧ (msg.value==DrugT otalCost) then
9 UpdateP aymentState = paid
10 Emit an event declaring that the claim is paid
11 else
12 Reject.
13 end
// Insurance company pays the FIGURE 5: Logs showing a successful registration of insur-
addmisible costs ance company

TABLE 1: The Ethereum addresses of participants in testing

scenario
Ethereum Address
Regulatory Authority 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
Physician 0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C
Patient 0x17F6AD8Ef982297579C203069C1DbfFE4348c372
Pharmacy 1 0x4B0897b0513fdC7C541B6d9D7E929C4e5364D2dB
Pharmacy 2 0xdD870fA1b7C4700F2BD7f44238821C26f7392148
Pharmacy 3 0x03C6FcED478cBbC9a4FAB34eF9f40767739D1Ff7
Insurance Company 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
RegistrationSCaddress 0xd9145CCE52D386f254917e481eB44e9943F39138

paid amount must be equal to the drug’s total cost. If these

conditions are met, then the P aymentState will be updated
to " Paid" and an event will be broadcast to declare that the
claim is paid.

VI. TESTING AND VALIDATION

In this section, the main functions of the two smart contracts
are tested and validated using the Remix IDE. It is a web-
based development environment for developing and execut-
ing smart contracts. The smart contract code is made publicly
available at GitHub5 . The functionality of smart contracts
is evaluated by deploying the registration smart contract
and the approval smart contract at "0xd9145CC...43F39138"
and "0x9D7f74d...9e3b5E99", respectively. The Ethereum FIGURE 6: Logs showing a successful creation of prescrip-
addresses of actors that are used in testing are presented in tion
5 https://github.com/InsuranceMangment/Insurance/blob/main/code.sol

VOLUME 4, 2016 11

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

FIGURE 9: Logs showing a successful execution of claim

payment function

• Insurance Company Registration: This function can

be executed only by the regulatory authority where
FIGURE 7: Logs showing a successful execution of insur- Ethereum addresses of authorized insurance companies
ance approval function are registered. Figure 5 depicts a successful execution of
the insurance company registration function , as well as
the corresponding events and logs.
• Prescription Creation: This function can be executed
by an authorized physician. The physician runs the func-
tion by entering several inputs such as patient ID, drug
codes, and IPFS hash. The inputs do not reflect a real-
life case scenario; they are assumptions used for testing
purposes. Figure 6 displays a successful execution of the
function and its related events and logs.
• Insurance Approval: Once pharmacy 2 sends con-
firmation, it requests approval from the insurance
company to process the prescription by executing
RequestInsuranceApproval. The insurance company
then will either approve or reject the request by running
the insurance approval function. Figure 7 shows a suc-
cessful execution of the insurance approval function.
• Payment Request: This function is executed by the se-
lected pharmacy after the medication is collected by the
patient. Figure 8 shows a successful payment request.
• Claim Payment: This function is executed by the in-
surance company to pay the admissible costs that are
requested by the pharmacy in exchange for the medica-
tion given to the patient. The tested result is shown in
Figure 9.

VII. DISCUSSION
In this section, we will discuss the security analysis, com-
FIGURE 8: Logs showing a successful execution of payment parison with existing models, and the generalization of our
request function proposed solution.

12 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

A. SECURITY ANALYSIS promise all the nodes to do so. Furthermore, the system
In this section, we address major security and privacy con- is available for both access of transaction data, as well
cerns related to trust, integrity, availability, and vulnerability as generating and submitting transactions to the ledger.
to cyber-attacks and how key blockchain properties help to As such, the system can run with no-downtime which
eliminate these issues. detrimental in a critical industry such as healthcare. This
ensures that critical cases can be handled and processed
• Confidentiality and Anonymity: Confidentiality pre- without hindrance.
serves the privacy of medical data of end-users, where it • Vulnerability to Cyber-Attacks: Cyber-attacks like
is disclosed only to authorized entities. In our solution, Man-In-The-Middle (MITM) and distributed denial-of-
we employ both on-chain and off-chain confidentiality. service (DDoS) are mitigated through the redundancy
On-chain confidentiality is ensured by the deployed of a decentralized network [19]. Commonly in cen-
private blockchain, where data is shared only with au- tralized systems, compromising the central server de-
thorized entities using TLS (Transport Layer Security). nies service of the system. However, in decentralized
A trusted certificate authority issues certificates which networks the attacker would have to either flood the
are utilized between the nodes to establish a secure con- network or overload most of the participants, effectively
nection. As for off-chain confidentiality, sensitive data is disrupting legitimate service of the system [22]. On the
encrypted using a combination of symmetric and asym- network level, flooding the system effectively would
metric cryptography, this is done to preserve features of be difficult because of the costs associated with each
authenticity and non-repudiation by asymmetric cryp- transaction. Furthermore, the entities are registered on
tography and speed of symmetric cryptography. The the Registration SC, as such only valid participants have
sender would encrypt the data with a symmetric key, the ability to execute transactions on the network. As
and then proceeds to encrypt the symmetric key with the such, it is difficult to coordinate a large-scale DDoS
public key of the receiver, such that only the receiver can attack between valid entities, with non-repudiation en-
decrypt it using their private key. Furthermore, identities sured with their associated EOA. Therefore, the attack
of patients are kept confidential as only the assigned is mitigated through prevention, and the effectiveness
stakeholders are able to view their information. The pa- of it would be limited to congesting the network rather
tients operate under pseudonyms that act as their digital than denying service, which can also be resolved by
identity with no linkability to their real identity. This removing misbehaving participants.
does not impede on the transparency and accountability
in the system, as timestamped transactions are stored
on the blockchain acting as an audit trail which would
ensure non-repudiation to the associated pseudonym
(EOA) signing the transaction.
• Integrity and Authenticity: By leveraging the
blockchain in our solution we preserve the integrity
through the immutability of blocks, where any changes
are easily detected and invalidate the blocks. As such,
changes are committed through new sequential trans- FIGURE 10: Registration smart contract vulnerability analy-
actions, creating a timeline of the changes to the data. sis
Furthermore, each participating node has a keypair
which is used to sign transactions. Each participant
signs a transaction with their private key which can be
decrypted by the public key to ensure authenticity of
the transaction and its data. Therefore, non-repudiation
of transactions is ensured, and entities will be account-
able for the provided data. This is imperative for this
application, especially stakeholders such as pharmacies,
hospitals, and insurance companies since the processed
health insurance claim would be immutable, transparent
and auditable, ensuring valid prescription drugs will not FIGURE 11: Approval smart contract vulnerability analysis
be altered by any participant.
• Availability: Since the blockchain is a decentralized
network with a shared distributed ledger, the services of B. SECURITY ANALYSIS OF THE SMART CONTRACTS
the system are available as long as there are participants. CODES
Data is stored at several nodes making it difficult to We perform the security analysis of the smart contracts de-
disrupt services, where the attacker is required to com- veloped. The Remix IDE provides code-debugging as well as
VOLUME 4, 2016 13

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

run-time error warnings. However, it is not enough to secure contribute to the approval of future claims. Lastly, the in-
the smart contract. Therefore, to improve the reliability of the clusion of different medical entities, especially pharmacies,
smart contracts, a specialized tool named Oyente can be used since we are considering medical prescription problems,
to test and validate the developed Ethereum smart contracts other papers take a general approach and don’t specify or drill
against vulnerabilities. It establishes trust in the strength of down into the problem.
the deployed smart contract by making the code risk-free.
Oyente is a Linux-based tool that thoroughly examines the D. GENERALIZATION
Solidity code to see if it is vulnerable to exploitation and Our proposed system is carefully designed to be specific yet
cyber assaults. broad at the same time. It processes prescription drug claims,
Figure 10 shows Oyente’s security results for the registra- but it can also be applied to different health insurance claim
tion smart contract, whereas Figure 11 shows the security re- types, including inpatient or outpatient. In our model, we in-
sults for the approval smart contract. The smart contracts are clude different actors such as insurance company, physician,
written in Solidity, a high-level programming language. It’s patient, pharmacies, and regulatory authority. The regulatory
converted into EVM code, which is a low-level stack-based authority is trusted external entity that is utilized to aid
bytecode language [18]. The smart contract’s EVM code in authentication, to align with the features offered by our
coverage was found to be 99.9% and 82.9% respectively, in solution it can be decentralized if cooperation is established
the security study. The number of opcodes executed divided between the participating authorities. To accommodate a
by the total number of opcodes is the Ethereum Virtual Code different type of health insurance claim, different actors
coverage percentage. For all types of probable vulnerabilities should be added depending on the requirements, such as
in the generated smart contract code, the Oyente tool returned therapists, nurses, surgeons, technicians, etc. Furthermore,
"False". our proposed solution has two smart contracts; registration
SC and approval SC. Minor modifications to the functions in
C. COMPARISON WITH THE EXISTING SOLUTIONS the smart contracts can be made to adapt to different health
To better understand our contribution compared to the state- insurance claims. For example, approvals for various exam-
of-the-art, a comparison shown in Table 2 was made. This inations, surgeries, therapy sessions, and so on. All these
comparison was made with respect to critical parameters requirements can be easily adapted into our proposed system
such as decentralization, security, and including pharma- since it will follow the same proposed process illustrated
cies as participants. We provide a decentralized system that in Figure 3. Moreover, different health insurance claims
provides resilience and security against the single point of will require storing large files to store different examination
failure problem, which is critical to a healthcare system. A results, hence the system will require off-chain storage. Also,
centralized model is more vulnerable to attacks and down- minor modifications are required to be made to the algorithms
time. Other solutions that provide centralized solutions can’t to adapt to different claims.
guarantee continuous run time. Furthermore, observing Ta- Furthermore, our proposed solution can also be used to
ble 2 and taking work [14] as a comparison example, our address other claim abnormalities such as abuse and error
solution provides testing and validation of the smart contract due to the intrinsic characteristics of blockchain technology.
code using the Remix IDE environment. Our solution also For instance, unnecessary costs incurred due to the use of
incorporates DApps to ease the communication between inappropriate medical services can be easily detected and
stakeholders without the need for external influencers such traced as all activities and transactions will be approved
as government corporations or developers to facilitate their and stored in the distributed ledger, where all authorized
transactions. Lastly, our solution uses decentralized storage stakeholders in the private network will be able to know
to store information off-chain in order to reduce the load on exactly who was responsible and when it was carried out due
the blockchain network. to the immutability and transparency of the data. The same
logic applies for claiming abnormalities arising due to errors.
TABLE 2: Comparison with state-of-the-art
Features [16] [17] [7] [14] Our Solution VIII. CONCLUSION
Blockchain-Base No No Yes Yes Yes In this paper, we proposed processing health insurance claims
Smart Contract NA NA No Yes Yes
Decentralized Storage No No Yes No Yes
for prescription drugs using blockchain in a confidential,
Security No No Yes Yes Yes private, secure, trustworthy, and decentralized manner. The
Include Pharmacies No No Yes No Yes proposed system utilizes a private Ethereum blockchain,
where two smart contracts were developed to contribute to
In addition, a major concern of people is the privacy of recording and logging events automatically. Also, to deal
their data. Hence, providing a highly confidential system with the limitation of storage, the network was integrated
is a requirement, and controlling what can be viewed and with off-chain storage (IPFS) to store the large-sized data that
accessed through encryption and DApps is necessary. Also, is expensive to be stored on the blockchain network. A se-
the integrity of the data is important since all transactions curity analysis was conducted to demonstrate the robustness
shouldn’t be altered or canceled after validation, which may and security of our proposed solution against major security
14 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

vulnerabilities. The proposed decentralized system provides [13] L. Zhou, L. Wang, and Y. Sun, “MIStore: A blockchain-based medical
resilience and security against the single point of failure insurance storage system,” Journal of Medical Systems, 2018, vol. 42, no.
8.
problem, which is critical to a healthcare system. Lastly, the [14] M. Thenmozhi, R. Dhanalakshmi, S. Geetha, and R. Valli, “Implementing
proposed system can be generalized to serve different health Blockchain Technologies for health insurance claim processing in Hospi-
insurance claims systems, including inpatient or outpatient. tals,” Materials Today: Proceedings, 2021.
[15] G. Saldamli, V. Reddy, K. S. Bojja, M. K. Gururaja, Y. Doddaveer-
In future work, although the proposed blockchain-based appa, and L. Tawalbeh, “Health care insurance fraud detection using
approach has considered important issues, there are still blockchain,” 2020 Seventh International Conference on Software Defined
some limitations that should be taken into consideration. For Systems (SDS), 2020.
[16] S. Bae, and B. Yi, "Development of eClaim system for private indemnity
instance, the immutability feature in our proposed solution health insurance in South Korea: Compatibility and interoperability,"
could be an issue because any human error will be perma- Health Informatics Journal, 2022, vol. 28, no. 1,pp. 1–10.
nently stored and cannot be modified or deleted. In addition, [17] A. Zhang, A. Bacchus†, and X. Lin, "A Fairness-Aware and Privacy-
Preserving Online Insurance Application System," 2016 IEEE Global
the privacy and confidentiality can be improved by using Communications Conference (GLOBECOM), 2016, pp. 1-6, doi:
the Quorum platform that supports transaction and smart 10.1109/GLOCOM.2016.7841495.
contract privacy, where it allows creating private transactions [18] L.Luu, D.-H. Chu, H.Olickel, P.Saxena, and A.Hobor ,“Makingsmart con-
tracts smarter,” in Proc. ACM SIGSAC Conf. Comput. Commun. Secur.,
that are visible only to specific participants, which is not the Oct. 2016, pp. 254–269, doi: 10.1145/2976749.2978309.
case in our approach, as the transaction can be viewed by [19] Ekparinya, Parinya, Vincent Gramoli, and Guillaume Jourjon. "Impact of
all authorized entities. Also, it can enhance the performance man-in-the-middle attacks on ethereum." 2018 IEEE 37th Symposium on
of the system due to the simplistic consensus algorithms. Reliable Distributed Systems (SRDS). IEEE, 2018.
[20] Daniel, Erik, and Florian Tschorsch. "IPFS and friends: A qualitative
Furthermore, our solution is planned to be deployed and comparison of next generation peer-to-peer data networks." IEEE Com-
tested on the real Ethereum network, and an end-to-end munications Surveys & Tutorials, 2022, vol. 24, no.1 pp. 31-52.
DApp will be built to be used by different stakeholders. [21] Zhang, Rui, Rui Xue, and Ling Liu. "Security and privacy on blockchain."
ACM Computing Surveys (CSUR), 2019, vol. 52, no.3, pp. 1-34.
[22] McDowell, Mindi. "Understanding denial-of-service attacks." National
IX. ACKNOWLEDGEMENT Cyber Alert System, Cyber Security Tip ST04-015.2004, 2004.
[23] Battah, Ammar Ayman, Mohammad Moussa Madine, Hamad Alzaabi,
This publication is based upon work supported by the Khalifa
Ibrar Yaqoob, Khaled Salah, and Raja Jayaraman. "Blockchain-based
University of Science and Technology under Award No. multi-party authorization for accessing IPFS encrypted data." IEEE Ac-
CIRA-2019-001. cess, 2020, vol. 8, pp. 196813-196825.

REFERENCES AUTHOR BIOS

AYSHA ALNUAIMI is a graduate student in Engineering Systems
[1] “Health Insurance Claim: Medical Insurance claim settlement ratio,”
and Management program at Khalifa University, Abu Dhabi, UAE. She
Policybazaar. [Online]. Available: https://www.policybazaar.com/health-
received her B.S. degree in electrical engineering from United Arab
insurance-claim/. [Accessed: 08-Mar-2022].
Emirates University, UAE, in 2020. She is currently a Research and a
[2] “health insurance claim 101: What you need to know,” Definitive Health-
Teaching Assistant at the Department of Industrial Systems Engineering,
care. [Online]. Available: https://www.definitivehc.com/blog/medical-
Khalifa University. Her research interests include blockchain applications
claims-101-what-you-need-to-know. [Accessed: 08-Mar-2022].
in healthcare.
[3] L. Norris, “An overview of prescription drug insurance,” Verywell Health.
[Online]. Available: https://www.verywellhealth.com/prescription-drug- AMNA ALSHEHHI is a graduate student in the Department of
insurance-4013242. [Accessed: 24-Mar-2022]. Electrical Engineering and Computer Science at Khalifa University, Abu
[4] D. Bell, S. Straus, D. Belson, S. Wu, D. Green, and J. Crosson, “A Toolset Dhabi, United Arab Emirates. Her research interests include blockchain
for E-Prescribing Implementation in Physician Offices,” AHRQ Publ., technology and Internet of Things (IoT) applications.
2011, no. 11.
[5] J. Lu et. al, "Embedding for Anomaly Detection on Health Insurance KHALED SALAH is a full professor at the Department of Electrical
Claims," IEEE 7th International Conference on Data Science and Ad- and Computer Engineering, Khalifa University, UAE. He received
vanced Analytics (DSAA), 2020, p. 459. the B.S. degree in Computer Engineering with a minor in Computer
[6] S. kareem et. al, "Framework for the Identification of Fraudulent Health Science from Iowa State University, USA, in 1990, the M.S. degree in
Insurance Claims using Association Rule Mining," 2017. Computer Systems Engineering from Illinois Institute of Technology,
[7] B. Alhasan et. al, "Blockchain Technology for Preventing Counterfeit in USA, in 1994, and the Ph.D. degree in Computer Science from the same
Health Insurance," in International Conference on Information Technology institution in 2000. He joined Khalifa University in August 2010, and
(ICIT), 2021. is teaching graduate and undergraduate courses in the areas of cloud
[8] L. Ismail and S. Zeadally, "Healthcare Insurance Frauds: Taxonomy and computing, computer and network security, computer networks, operating
Blockchain-Based Detection Framework (Block-HI)," IEEE Digital Ob- systems, and performance modeling and analysis. Prior to joining Khalifa
ject Identifier, 2021. University, Khaled worked for ten years at the department of Information
[9] G. Saldamli et. al, "Health Care Insurance Fraud Detection Using and Computer Science, King Fahd University of Petroleum and Minerals
Blockchain," in Seventh International Conference on Software Defined (KFUPM), KSA. Khaled has over 190 publications and 3 patents, has
Systems (SDS), 2020. been giving a number of international keynote speeches, invited talks,
[10] H. CHEN et. al. "A Survey on Ethereum Systems Security: Vulnerabilities, tutorials, and research seminars on the subjects of Blockchain, IoT, Fog
Attacks, and Defenses" ACM Computing Surveys, 2020, Vol. 53, No. 3. and Cloud Computing, and Cybersecurity. Khaled was the recipient of
[11] N. A. Akbar, A. Sunyoto, M. Rudyanto Arief, and W. Caesarendra, Khalifa University Outstanding Research Award 2014/2015, KFUPM
“Improvement of decision tree classifier accuracy for healthcare insurance University Excellence in Research Award of 2008/09, and KFUPM
fraud prediction by using extreme gradient boosting algorithm,” 2020 Best Research Project Award of 2009/10, and also the recipient of the
International Conference on Informatics, Multimedia, Cyber and Informa- departmental awards for Distinguished Research and Teaching in prior
tion System (ICIMCIS), 2020. years. Khaled is a senior member of IEEE, and serves on the Editorial
[12] V. F. Santana, A. P. Appel, L. G. Moyano, M. Ito, and C. S. Pinhanez, Boards of many WOS-listed journals including IET Communications,
“Revealing physicians referrals from health insurance claims data,” Big IET Networks, Elsevier’s JNCA, Wiley’s SCN, Wiley’s IJNM, J.UCS,
Data Research, 2018, vol. 13, pp. 3–10. and AJSE. Khaled is the Track Chair of IEEE Globecom 2018 on Cloud

VOLUME 4, 2016 15

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3219837

Computing. He is an Associate Editor of IEEE Blockchain Newsletter and

a member of IEEE Blockchain Education Committee.

RAJA JAYARAMAN is an Associate Professor at the Department

of Industrial Systems Engineering at Khalifa University, Abu Dhabi,
UAE. He received his Ph.D. in Industrial Engineering from Texas
Tech University, a Master of Science degree in Industrial Engineering
from New Mexico State University, Masters and Bachelor’s degree in
Mathematics from India. Raja’s research interests includes application of
blockchain technology, NFTs, IoT and process optimization techniques
to characterize, model and study complex systems with applications to
supply chains, maintenance planning, and healthcare delivery. His post-
doctorial research was on technology adoption and implementation of
innovative practices in the healthcare supply chains and service delivery.
He has led several successful research projects and pilot implementations
of supply chain data standards in the US healthcare system.

ILHAAM A. OMAR is a Research Associate at the Department

of Industrial Systems Engineering, Khalifa University, United Arab
Emirates. She received her Bachelor’s degree in Electrical and Electronic
engineering and Master’s degree in Engineering Systems and Management
from Khalifa University. Ilhaam’s research interests are in the applications
of Blockchain, Smart Contracts and IoT technology across variety of
industries.
AMMAR BATTAH is a Research Associate at the Department of Indus-
trial & Systems Engineering, Khalifa University, United Arab Emirates.
He received his B.Sc. and M.Sc. degrees in Computer Engineering from
Khalifa University in 2019 and 2022, respectively. His current research
interests include Blockchain technologies, the Internet of Things (IoT)
security, and Information security.

16 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/