Decentralized Authentication of Distributed Patients in Hospital Networks Using Blockchain

Abstract

In any interconnected healthcare system (e.g., those that are part of a smart city), interactions between patients, medical doctors, nurses and other healthcare practitioners need to be secure and efficient. For example, all members must be authenticated and securely interconnected to minimize security and privacy breaches from within a given network. However, introducing security and privacy-preserving solutions can also incur delays in processing and other related services, potentially threatening patients lives in critical situations. A considerable number of authentication and security systems presented in the literature are centralized and frequently need to rely on some secure and trustful third party with communications. This, in turn, increases the time required for authentication and decreases throughput due to known overhead, for patients and inter-hospital communications. In this paper, we propose a novel decentralized authentication of patients in a distributed hospital network, by leveraging blockchain. Our notion of a healthcare setting includes patients and allied health professionals (medical doctors, nurses, technicians, etc), and the health information of patients. Findings from our in-depth simulations demonstrate the potential utility of the proposed architecture. For example, it is shown that the proposed architecture's decentralized authentication among a distributed affiliated hospital network does not require re-authentication. This improvement will have a considerable impact on increasing throughput, reducing overhead, improving response time, and decreasing energy consumption in the network. We also provide a comparative analysis of our model in relation to a base model of the network without blockchain to show the overall effectiveness of our proposed solution.

Full text

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
1
Decentralized Authentication of Distributed Patients
in Hospital Networks using Blockchain
Abbas Yazdinejad1, Gautam Srivastava (Senior Member, IEEE)2,4, Reza M. Parizi (Senior Member, IEEE)3,
Ali Dehghantanha (Senior Member, IEEE)5, Kim-Kwang Raymond Choo (Senior Member, IEEE)6, and
Mohammed Aledhari (Member, IEEE)3
Abstract—In any interconnected healthcare system (e.g., those
that are part of a smart city), interactions between patients,
medical doctors, nurses and other healthcare practitioners need
to be secure and efficient. For example, all members must be
authenticated and securely interconnected to minimize security
and privacy breaches from within a given network. However,
introducing security and privacy-preserving solutions can also
incur delays in processing and other related services, potentially
threatening patients lives in critical situations. A considerable
number of authentication and security systems presented in
the literature are centralized, and frequently need to rely on
some secure and trusted third-party entity to facilitate secure
communications. This, in turn, increases the time required for
authentication and decreases throughput due to known overhead,
for patients and inter-hospital communications. In this paper,
we propose a novel decentralized authentication of patients
in a distributed hospital network, by leveraging blockchain.
Our notion of a healthcare setting includes patients and allied
health professionals (medical doctors, nurses, technicians, etc),
and the health information of patients. Findings from our
in-depth simulations demonstrate the potential utility of the
proposed architecture. For example, it is shown that the proposed
architecture’s decentralized authentication among a distributed
affiliated hospital network does not require re-authentication.
This improvement will have a considerable impact on increasing
throughput, reducing overhead, improving response time, and
decreasing energy consumption in the network. We also provide
a comparative analysis of our model in relation to a base model of
the network without blockchain to show the overall effectiveness
of our proposed solution.
Index Terms—Blockchain; Decentralized Authentication; IoT;
Healthcare; Health big data; Security.
I. INT ROD UC TI ON
Internet of Things (IoT) can be broadly defined to be a
collection of inter-connected devices, in the sense that these
devices connect to the Internet and often to each other to share
information [1]. Applications of IoT include medical settings
[2], [3], which is not surprising given the increasing focus on
1Cyber Science Lab, School of Computer Science, University of Guelph,
Ontario, Canada, Email: abbas@cybersciencelab.org
2Department of Computer Science, Brandon University, Canada, Email:
srivastavag@brandonu.ca
3College of Computing and Software Engineering, Kennesaw State Uni-
versity, GA, USA, E-mail: {rparizi1,maledhar}@kennesaw.edu
4Research Center for Interneural Computing, China Medical University,
Taichung 440402, Taiwan, Republic of China
5Cyber Science Lab, School of Computer Science, University of Guelph,
Ontario, Canada, Email: adehghan@uoguelph.ca
6*Department of Information Systems and Cyber Security, University of
Texas at San Antonio, TX, USA, Email: raymond.choo@fulbrightmail.org
(corresponding author)
improving healthcare services. For example, a considerable
number of countries are dealing with a lopsided ratio of
patients to healthcare professionals, and consequently patients
may find it more challenging to gain access and care from a
primary medical doctor or caregiver. The deployment of IoT
and wearable devices can potentially result in improved patient
quality of care, for example via remote patient monitoring
(RPM).
RPM provides a way to monitor patients outside the con-
ventional clinical environment, and allows doctors and other
relevant members in the healthcare industry to treat more
patients than was previously possible in just face-to-face
interaction. First, it can allow patients an inherent convenience
of service. Patients can remain connected with healthcare
providers as needed. It also decreases medical costs and
reduces the need for quality care directly on-site in hospitals
and clinics. This is the main reason that healthcare providers
are tackling means by which to supply RPM devices to the
masses. RPM devices can also provide IoT type connectivity.
In an IoT setting, one can envision a network of wearable
clothes, sensors, and actuators which enables the wearable
device to connect and exchange information by many different
stakeholders. To categorize such health and patient data with
other institutions (for example a network of affiliated hospitals
in a smart city), such foundations require secure data sharing.
For example, in the United States certain insurance providers
affiliate with a network of hospitals, thus producing a necessity
to share patient and treatment information throughout such a
network. Patient’s health data is extremely private and sharing
of data may enhance the medical treatment options but also
increases the risk of information breaches. In addition, current
traditional systems of data sharing use a centralized archi-
tecture which requires centralized trust. IoT intends to bring
health applications for hospitals to the next level. Hospital
technology has become fairly advanced, so it is an ideal time to
explore blockchain as an avenue for data sharing that enables
security, privacy, and trust. In any smart environment including
a distributed hospital network, IoT devices can be on the move
of fixed in a distinct location. There are security limitations
for most health applications due to privacy concerns that
have existed in healthcare since the beginning of digitization.
Moreover, health data collection and security of interactions
create their own constraints [4], [5]. Interactions between
devices must be authenticated to hold secure communication.
To overcome the issue of data privacy and security,
blockchain technology is one of several viable solutions
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
2
(partly evidenced by the increasing interest from the research
community [6]–[8]). For example, Dwivedi et al. provided a
decentralized privacy-preserving healthcare blockchain for IoT
in [9]. They proposed a framework of modified blockchain
models suitable for IoT devices that depend on their distributed
nature and other additional privacy and security properties of
the network. In general, they tried to resolve the issues of
using blockchain with IoT devices. In another related work,
Irving et al. [10] presented a method for using blockchain
to provide proof of pre-specified endpoints in a hospital
setting. Srivastava et al. [11] presented a medical blockchain,
which makes use of directed acyclic graphs proposed by
Zohar and Somplisnky [12]. Specifically, the transactional
protocol for RPM (that uses GHOSTDAG) implements both a
public blockchain and a private blockchain. The approach is
designed to mitigate known security issues, without affecting
scalability. Yazdinejad et al. [13] presented a blockchain-based
approach to facilitate authentication in 5G networks, which
also utilizes software defined networking (SDN). Specifically,
they eliminate the need for re-authentication when devices /
calls move between cells in 5G networks. Other blockchain-
based authenication approaches include those presented in
[14]–[16]. This is also the focus of our paper.
In our context, we consider a typical hospital scenario
where a group of staff members interact with each other. Each
node is managed by a nurse station (NS; see Section III).
Using the secure communication mode, authentication of new
members (patient, doctor, nurse or other staff) in the hospital
network that is not part of a region, hospital, or division, is
complex. This is because authentication of these new mem-
bers requires decentralization of the authentication authority.
Most conventional authentication methods are centralized and
usually require the involvement of a trusted third-party entity.
Here forth, we refer to centralized authentication methods as
traditional methods. There is a strong push in IoT for secure,
decentralized approaches that remain flexible and scalable for
communications in a broad range of settings, more specifically
here for a hospital network. In the latter, security, privacy and
trust are crucial, partly due to the exacting requirements associ-
ated with the sector. Due to the mobility of users coupled with
the frequency of movement between parts of a hospital or be-
tween hospitals, frequent authentication (or re-authentication)
is a norm, to facilitate the identification and authentication of
devices. That being said, identification and authentication of
devices incur high computational costs and introduce latency,
which can result in potentially fatal consequences. Moreover,
high computational and time overheads are impractical for
deployments involving resource constrained devices. To ensure
robustness when designing security solutions, one should also
bear in mind the heterogeneous architecture of such systems
and the need to authenticate users and devices using different
authentication mechanisms.
In this paper, we investigate a secure, transparent, and time-
efficient authentication approach that can be deployed in a
distributed network hospital. Our approach is decentralized,
and designed for IoT devices with limited computational,
memory and energy capabilities. Specifically, we use a public
blockchain and the IoT devices in the hospital network are
connected through Peer-to-Peer (P2P) networks using a shared
ledger. Participating users can migrate to other affiliated hos-
pitals (e.g. seeking treatments at another specialized hospital)
via their distributed identity easily, in the sense that the
migration of any authenticated user from one hospital to a
different hospital will not require authentication of devices to
happen repetitively. This feature, by itself, has a considerable
impact on decreasing the time needed for the authentication
of users/devices. That is, if a user/device that is currently in
any affiliated hospital and has already been approved, that
user/device will also be trusted/approved in any other hospital
and can communicate with other users/devices with ease.
The rest of paper is organized as follows. In Section II,
we present an overview of the related background. Next, in
Sections III and IV, we present our proposed approach and
describe the evaluation and simulation results. Finally, we
conclude the paper in Section V.
II. PR EL IM INA RI ES
Blockchain can be defined as a sequence of blocks, which
can hold a comprehensive list of transaction history similar
to how a conventional public ledger would. The first block of
a blockchain is called a Genesis block which has no parent
block. We will now explain the internals of a blockchain in
detail.
A. Blocks
A block consists of the block header and the block body as
shown in Fig. 1. In particular, the block header includes:
•Block version: indicates which set of block validation
rules to follow.
•Merkle tree root hash: the hash value of all the transac-
tions in the block.
•Timestamp: current time as seconds in universal time
since January 1, 1970.
•nBits: target threshold of a valid block hash.
•Nonce: an 4-byte field, which usually starts with 0 and
increases for every hash calculation
•Parent block hash: a 256-bit hash value that points to the
previous block.
Fig. 1: Blockchain Overview [17]
The block body is composed of a transaction counter and
transactions. The maximum number of transactions that a
block can contain depends on the block size and the size of
each transaction. Blockchain uses an asymmetric cryptography
mechanism to validate the authentication of transactions [18]–
[20].
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
3
We refer readers interested in blockchain and healthcare se-
curity topics to [2], [9], [11], [15] for more in-depth discussion.
B. Notation
Table Igives the descriptions and notations that are used
throughout the rest of the paper.
TABLE I: Summary of Notation
Equation Parameters Description
NSkNursing Station of Affiliated Hospital k
PiPatient i
TjTransaction j
NNurse
DDoctor
SOther staff in hospial
MkMessage transfer to hospital K
HkHealth information in hospital K
Fig. 2: Distributed Hospital Network in a Smart City
III. PROP OS ED AR CH IT EC TU RE
Our proposed architecture creates efficient decentralized au-
thentication using blockchain technology. As shown in Fig. 2,
a high-level overview of the proposed architecture contains
several affiliated hospitals within a distributed network. As
illustrated, we consider a distributed network of affiliated hos-
pitals using blockchain. Each hospital has a NS that manages
the hospital. We define a NS in comparison to other units in the
hospital as having no limit on energy and power. We assume
here that all other devices in the network are constrained in
both energy and computation.
A. Affiliated Health Network
Every hospital in our architecture can take part in the af-
filiated health network which includes patients, staff (doctors,
nurses, technicians) and patient’s respective health informa-
tion. All existing hospitals in the network can communicate
securely with each other through the distributed network. In
this architecture, we have general access to health services
throughout the network, and in doing so provide an integrated
healthcare system.
In each hospital, all patient’s health information can be
recorded in the blockchain by RPM devices, and by staff as
shown in Fig. 3. Therefore, authorized hospital staff are able to
check patient’s health information from any affiliated hospital
in the network while they are authenticated. In addition, pa-
tients are not joined to specific hospitals and doctors since their
health information is available anywhere. In an emergency
situation, doctors can consult with other hospitals within the
network via blockchain as necessary.
B. Encryption and Blockchain Details
A Symmetric key encryption known as ARX algorithms is
deployed in our proposed system. We use ARX to encrypt
the data for our blockchain. This technique was introduced in
[21]. ARX algorithms are composed of simple operations such
as (ADD)ition, (ROT)ation, and XOR. All operations support
lightweight encryption. Among well-known examples of ARX
algorithms, one example is SPECK, which was originally
designed and used by the National Security Agency (NSA).
SPECK is prescribed here due to its resilience against key re-
covery attacks. Additionally, we consider a public blockchain
since patients may arrive abruptly needing emergency care.
Every hospital has a ledger for communications that it provides
for a consistency of user type in the hospital. We have
presented the structure of our blockchain in Fig. 4.
In the implementation of blockchain used here, each block
includes a HASH,KEY, and transactions. Transactions
include data (unique features and patient’s health information)
collected during health services. The transaction information
is very specific. For example, Patient2 indicates the second
patient, in hospital H2 of the network, is in NS 2 which
his/her doctor and nurse are a doctor with code Doctor2 and
a nurse with code 2in the hospital. Info defines the specific
information of patients like the type of test and medicine. In
the transaction one can also get more details about his/her
health information, number of transactions and previous hash
as shown in Fig. 4
ANS can check the network behaviour at run-time and pre-
vent the network from rising attacks and malicious behaviours.
C. Intricate Example
Transactions:When Patient isubmits transaction jin
Hospital kto the NSk, the N Skacts as a validator in
the hospital. These operations are happening (Pi(Tj)→
NSk(Validator), and Tj=Vector info (data). NSkperforms
a preliminary check of the transaction in order to decline
abnormal transactions (Validator checks the field which is sent
by the Pi, Validator →check (ValidateTransaction(Tj))). Then
the execution unit in the hospital (NSk) starts to execute
a transaction (Exe unit →ExecuteTransaction (Tj)). After
executing the transactions, returns the result without errors
to Pi(Validator →Pi(Add Ti WithValidation ())). When the
validator of NSkreceives a transaction from a Pi, it verifies
that the sequence number for the transaction, then it announces
to Pi. In accepting a transaction, the patient offers a transaction
to the validating authority (Validator), which is defined here
as a (NS). The NS accepts transactions. (Pi→NS)NS will
make a validation analysis, such as signature verification,
indicating that the patient’s account has a sufficient balance.
(NS →Validator). For giving a transaction With Validators,
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
4
Fig. 3: Blockchain Network in Each Hospital
Fig. 4: Public Blockchain in the Hospital Network
Fig. 5: Architecture of Proposed Method
the NS will add transactions to the ledger. NS may already
include multiple transactions carried out from a given patient’s
address. Applying the data in the blockchain, a Validator will
yield the transactions in its Validator with other validators
(in different hospitals) and place transactions obtained from
the other validators into its Validator. (Validator →Other
Validators). If a Validator is a proposer, it will pick a block of
transactions from its Validators and replicate this block as a
recommendation to other validators via its consensus compo-
nent. (Consensus →Validators) The consensus component of
Validators is accountable for organizing cooperation among
all validators on the order of transactions in the recommended
block. (Consensus →Other Validators).
Adding Members to Network:To add a staff member
or patient, the NS generates a transaction and shares a key
pair (public/private). After receiving the key, users can start
recording or reading health information directly while their
key is valid on the blockchain. For reducing the authentication
time and computational overload of all users in a given
affiliated hospital, the use of a public blockchain, Proof-of-
Work (POW), and adding new blocks to the blockchain is done
only by the NS. The NS starts to register users in the hospital,
grant a public and private key for each user and register unique
identifiers for each user on the blockchain. Next, each user
is controlled by symmetric encryption forming a robust and
safe solution. Our architecture is developed based on a public
blockchain, and each hospital is allowed to communicate
securely and record health information on the ledger using
the existing users’ key.
Proposed Workflow:In Fig. 5, we present the workflow of
the proposed architecture. First, P1requests to join hospital A,
which is controlled by an NSA. Here, the secure communica-
tion of P1with NSAis established in Procedure 1 (See
Fig. 6). In the next phase, P1is authenticated, and NSAwants
to send a vector health information to the blockchain, such as
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
5
NSA:P1is admitted, which means N SAguarantees that P1
is trustful and NSAshares a symmetric key for safe transfer
health information with P1. These health transactions are valid
in a new block and are recorded by NSA. The controversial
question which arises here is that how can P1get the key pair
securely from NSA? In fact, when P1requests to join NSA,
NSAcreates key pair based on unique information of P1
such as using the MAC address of their device and gives read
permission when accessing these keys to P1in Procedure
1. Generally, each NSAshares securely a key pair for users,
and just that user can use the generated key pair by NSAsince
it is based on the vector information and the MAC address of
a user.
Migration to other Hospitals:If and when P1migrates to
different affiliated hospital, for example to hospital Bmanaged
by NSB,P1sends a request to N SBto join this hospital.
NSBrefers to the blockchain and checks for P1’s authentica-
tion. If P1is valid, NSBtakes its keys (public and private).
Then NSB, after conducting the encryption/decryption oper-
ation, sends a health transaction (NSB:P1is accepted) to
the blockchain. The public and private key pair of the user
is shared with the destination NS and not shared with other
NSs. In fact, such information is shared with the specific NS
provided that P1is valid during the migration. NS gets the
public and private key pair since there is a possibility that P1
may get compromised during movement. This will ensure to
have trusted evidence in place for validation on users.
If P1wants to move to another hospitals say C, then NSC
checks its authentication in the public blockchain. Therefore,
there is no need for re-authentication when entering different
clusters, or transferring between them. It just takes a key pair
from one of the hospital to the other (NSBor N SC).
In any affiliated hospital, the NS can move the health data
to the blockchain. All users in the hospital have the ability
to exchange health data together between hospitals in a P2P
manner, which, according to keys (public and private), sign,
transcribe, and decrypt the health transactions. The process
of migration by patient, doctor and nurse among hospitals is
shown in Algorithm 1.
The process of file transferring among hospitals is presented
in Algorithm 2.
The hash is calculated by the NS in each hospital in
Algorithm 3. Also, the NS in each hospital is responsible for
the mining process. Algorithm 3shows a summarized pseudo-
code of the mining procedure in the proposed architecture.
Algorithm 4gives a detailed overview of necessary proce-
dures for proofing a mined block in the hospital by the NS.
D. Summary
In summary, we presented proposed architecture for an
affiliated hospital network. Based on our proposed architec-
ture, we used a distributed network among affiliated hospitals
using blockchain. With the help of the proposed architecture
equipped with blockchain, we obtain secure communication as
patient’s data moves around. Using the proposed architecture,
there is the possibility of migration of patients and staff from
one affiliated hospital to another without re-authentication
Algorithm 1 Migration Patient, doctors and nurses among hospitals
Call register (PkDkNkS) // Reg all in hospital
while (register == 1) do
PkDkNkS→Req authentication
Send (authenticationvector (Public & Private/ Key)) →
ALL Participat
end while
Hash Function ()
Node PkDkNkS: receive (Hash 256)
Call Join hospital (A) // join to hospital
if (PkDkNkS== Rang A) then
auth = 1
Calculate (mobility)
elas auth = 0
Calculate (migration)
else
auth = 1
Calculate (mobility)
elas auth = 0
Calculate (migration)
end if
if (moving ==1) then
if ( If (PkDkNkS6=Rang)
if ( auth = 1 )
PkDkNkS= Join hospital()
else
Block (Call Join hospital)
end if
while (auth =0 ) do
if (Mobility = 1 or migration = 1) then
if (authenticate)) // in hospital
H i: Message (i)// hospital i
Update (cluster info)
Migrate (i, current, Target)
else
H i: Message (Blcokchain)// send to BC Update X1
end if
end while
while (migrate or mobility! =0) do
New hospital head = Received (data i)
New hospital head = Decrypt (Create header)
end while
Algorithm 2 Transfer health information in hospital
PAnnounces to D// Patient wants to send information to doctor
While (user Pi== authentic in hospital && trust)
Hi(Check traffic hospital)
Picalculate (optimize (path))
PiEncrypt (send data (Mk)) // encrypt with Private key
Pi= Send (Hk)
Dj= monitor trust-data (Pi)
Dj=Received (data)
Dj=Decrypt (data) // using private key and re-organize
data
if (PkDkNkS6=authentic in hospital && trust) then
Add to block ()
end if
requirements. This feature leads to less overall delay of
information exchange throughout the network. Patient P1in
hospital Acan easily communicate with a doctor or hospital
geographically far away, provided they are all part of the same
affiliated network. Moreover, they can securely interact via
blockchain anywhere within the network. As an example, a
doctor in hospital Cwill be able to communicate with hospital
Bfor surgical procedures on a given patient that has visited
either one at some time in the past.
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
6
Fig. 6: Joining Hospital Network Procedure
Algorithm 3 Hash calculating and mining procedure by NS
Input = Information to create Block in chain→B, Block Version→VB,
Previous Block Hash→prev, Timestamp→tnow, difficulty →d and
Trans = [T1;T2. . . Tn]
Output = Nonce value (NV )
Bool variable Ans = FALSE;
while (NOR Ans)do
Torder rand = rand num(n)// integers within range [1, n];
Calculate Merkle tree ()
Create the hashed block header ()
if (B = VB and Prev == true) then
Number nonce = 0;
Hash output result ()
while (NOR Ans & NOT POW) do
min result = d hash ();
Nonce ++ ;
if (d == 1 & NOT got POW ) then
Nonce - 1;
Ans = TRUE;
return (nonce - 1);
else
if (receive POW) then
Ans = TRUE;
return 0;
end if
end if
end while
end if
end while
IV. EVALUATION AND RESULTS
In this section, we first evaluate the performance metrics
like throughput, time overhead, response time and energy con-
sumption of the proposed architecture in Section IV-A. Next,
we present a security analysis of the proposed architecture in
Section IV-B.
Algorithm 4 Proof the Block by NS unit
Input = Mined Block Header H; Block payload P
Output = Bool variable RESULT M = Correct
Extract nonce value (H)
Calculate Merkle Tree (B)
Create header verify (H, P, B)
verify()
Calculate hashed value( result)
if (result == 0) then
Correct = TRUE;
else
Correct = FALSE;
end if
return RESULT M;
End
A. Performance Evaluation
In this section, our proposed work is evaluated using NS-2
V2.35 simulator as initially given in [22] and shown to be
very effective in [23]. We test the effectiveness and perfor-
mance of the proposed architecture by considering related
viable parameters. NS-2 is a well established network simu-
lator that is used for a considerable number of research areas,
alongside a fairly well known open source Blockchain plug-
in for it [24]. It is one of the most powerful simulators for
networks [25]. Our parameters for evaluating the proposed
architecture are presented in Table II. We run simulation
for approximately 10 minutes, during which 3000 health
transactions occur. The average outcome is measured over
50 simulations of our scenario. Throughput, time overhead,
response time and energy consumption are the simulation
metrics that were considered.
For comparing the proposed architecture’s performance met-
rics, we consider a separate scenario during the simulation as
the base case. In this base case, the base model does not use
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
7
TABLE II: Simulation Parameters
Simulation Parameters Values
Simulator Used NS-2.35
channel type Wireless
Radio range Random
Propagation model Propagation/Two ray channel
MAC protocol Mac/802.11
Mobility model Random
Members speed 4/6/8/10 m/s
Number of Patients/Doctor/nures/NS 400/100/250/20
malicious persons 50
Number of Hospital 20
Traffic Type Constant Bit Rate (CBR)
Type of Antenna Antenna/Omni Antenna
Simulation Time 600
Evaluation parameters Throughput, Time overhead,response Time
Energy consumption, Authentication attacks
Number of Simulation runs/scenario 50
Area 10 Km * 10 Km
Packet size 32-512 Byte
Packet Length (NS to Blockchain) 32 Byte
Previous hash 8 Byte
Transaction counter 0-8 Byte
Block Header 80 Byte
Block Size 16 Byte
blockchain technology or a distributed network. Also, it only
uses traditional methods for user authentication of patients in a
hospital as given in [26]. The base model requires a third-party
for communications and a variety of authentication servers
among heterogeneous parts of a hospital.
Throughput:In the context of this paper, throughput is
defined as the number of requests of health transactions
that are completed among affiliated hospitals. In Fig. 7, we
compare the throughput of our proposed architecture and
the base model. Due to the fact that we used a distributed
network among affiliated hospitals and optimized algorithms
for authentication of patients, we achieved an increase in
throughput compared to the base model.
Fig. 7: Comparison of Throughput
Time Overhead:Can be defined here as the processing time
of each authentication. When a NS responds to requests, as
shown in Fig. 8, the base model takes more time to authenti-
cate than the proposed architecture because it requires many
re-authentication operations in the base model. In addition,
our architecture uses advanced authentication procedures for
Fig. 8: Comparison of Time Overhead
patients, doctors, and other staff, which is a fast and efficient
transmission.
Response Time:Can be defined here as the time for
recording of health information and updates of new informa-
tion between patient and doctors or a NS. In our proposed
authentication, we show an improvement compared to the base
model due to using a unique NS in each affiliated hospital.
Fig. 9shows the average response time to record health
information and update new information with different sizes
in an affiliated hospital. We show that our architecture has less
overhead than the base model.
Energy consumption:Mainly considered by IoT devices
during record creation or updates to health information in the
blockchain. The energy consumption can be calculated using
Equation 1.
Et= (Pt×T)+[T×(NS ×en)]+
[T×(D×ei)] + [T×(n×ec)] (1)
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
8
Fig. 9: Comparison of Response Time
Fig. 10: Average Energy Consumption
where
•Etis total energy consumption by all persons
•Ptis the number of patient transactions
•NS is the number of NS’s in the distributed hospital
network
•enis energy consumed by the NS
•Dis the number of doctors
•eiis energy consumed by doctors
•nis the number of nurses
•ecis the energy consumed by nurses
The base model for re-authentication among migration in
affiliated hospitals is more energy intensive. We also use an
efficient authentication protocol when transmitting/receiving
data in the proposed architecture. The results of this compar-
ison are shown in Fig 10.
Our results positively demonstrate that our architecture is
more secure than a base method due to the use of blockchain
and can detect authentication attacks through any NS using our
authentication algorithm. Additionally, using the proposed ar-
chitecture increases throughput, reduces energy consumption,
while also reducing both time overhead and response time.
B. Security Analysis
In this section, we define a threat model associated with
the proposed architecture for secure communication in the
Fig. 11: Threat Modeling and Analysis
distributed hospital network. We then analyze attacks on
the proposed architecture. Finally, we observe the benefit of
authentication during a secure communication in the proposed
architecture.
Threat Modeling and Analysis Process for Secure Com-
munication:Modeling and analysis process for threats are
defined in Fig 11.
This process includes four steps which intertwine defining
what security means for secure communication in the dis-
tributed hospital network, selecting threats, analyzing threats
and their related risks, and evaluating how counteraction
results to the achievements of security goals. In the proposed
architecture, we have multiple patients with a single ledger
in each hospital that allows patients to move to other hos-
pitals for treatment if necessary. Also, they require secure
communication with each other. In fact, we utilize Algorithm
1and Algorithm 2for optimizing the proposed architecture
and having secure communication during patient movements.
The full process is kept in a Threat Evaluation module that
forms the threat pattern to be used all over the expansion life
cycle.
Security has various means based on different applications.
For instance here, security of a patient information system
should be defined in terms of authorized access to patient’s
information like the health information for doctor, nurse or
others. For online healthcare system however, security must
include availability of the system for 24-hour online patient
healthcare. Hence, the first step in the security threat modeling
process is to explicitly describe what security means in the
context of the system being expanded.
For the distributed hospital, we model the description of
security via determining a high-level security goal and refining
it by topic, policy, AND/OR parsing to more specific goals.
The top-level security-online healthcare system in the hospital-
is reformed by policy to Security [patient] informing that
patient reports are the major health information assets to
be protected in the blockchain. This is further AND-parsing
into confidentiality[patient], integrity [patient], and availabil-
ity[patient] goals. The refinement of the description can be
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
9
Fig. 12: Attack Detection Probability
done iteratively until an adequate level of detail is captured to
describe the security objectives of the Healthcare System and
their area.
Next step is to extract security threats that we use threat
classification method like STRIDE (Spoofing, Tampering, Re-
pudiation, Denial of service, and Elevation of privilege) [27].
Furthermore, it can be used to extract security threats for a
healthcare system in the distributed hospital network.
Threat Analysis:Each architecture must consider security
requirements such as Confidentiality, Integrity, and Availability
(CIA triad). As a result, the proposed architecture for a
distributed hospital network must address them. Confidential-
ity ensures that only authorized patients, doctor or nurses
can access patient’s information in the blockchain. Integrity
is responsible for transactions sent to the hospitals without
unauthorized modifications. Availability refers to patient’s data
that is always available when needed.
In many cases, malicious entities attempt to access health
information or vital content without having to properly authen-
ticate themselves. Here, we are interested to understand how
the proposed architecture will operate in case of some common
attacks such as DOS/DDOS attacks (UDP Flood, SYN Flood,
TCP Flood, authentication attack (AUTH), Link-ability attack
(LB), ID spoofing (ID-s) and Numb attack (NA))[28], [29]
which can occur when a patient attempts to join a hospital
or the hospital network in general. Moreover, a NS is usually
faced with these attacks in any given hospital. For instance,
through authentication attacks, patients frequently want to join
a hospital network or other parts with malicious intent, or want
to join the network among hospitals with fake or blocked IDs.
Fig. 12 demonstrates the attack detection rate based on
common attacks in the proposed distributed hospital.
ANS is often faced with a considerable numbers of attacks
via malicious entities. Here, malicious entities frequently want
to join a NS in an affiliated hospital with insecure and unsafe
behavior for accessing health information or content without
having to properly authenticate within the hospital. Also, in
the simulations, we considered the attacks where entities want
to join an affiliated hospital with an impostor ID. Also, any
DoS/DDoS attack defined by floods a target with UDP and
TCP packets. As a result, through P2P communication attack-
Fig. 13: Attack Detection Rate
ers can access sensitive data of the hospitals in the blockchain.
During the evaluation of the attacks as shown in Fig. 12, we
simulated the capability of the proposed architecture, with 20
hospitals, 100 doctors, 50 malicious entities, 20 NS, and 250
patients. The NS are able to detect attacks based on the patients
indicated. Also, a NS has access to valid IDs of patients
through Internet of Things connected networks.
Moreover, Fig. 13 presents the possibility of attacks in an
affiliated hospital. The proposed architecture and the base
model are compared during 500 iterations where the proposed
architecture has shown a higher attack detection rate when
compared to the base model.
Effect of Authentication during Secure Communication:
We focus here on authentication during secure communication
in the proposed architecture. The evaluation of authentication
in the proposed architecture is compared with base model
when attacks are observed during secure communication be-
tween patients in the distributed hospital network.
In the base model, patients should be registered in the
hospital and upon repeated movements among the hospitals
become re-authenticated to ensure continuous secure commu-
nication. This method requires re-approval and separate proto-
cols among different hospitals for continuity in authentication.
During secure communication in our proposed architecture,
patients do not need to be re-authenticated when moving
among different hospitals since they are valid in adjacent
hospital and a simple handover, removes the re-authentication
delay. This is a well motivated case, as often patients are
moved between hospitals to facilitate faster treatment in emer-
gency situations. The comparison between our authentication
delay and the base method on the rate of authentication for
distributed hospital network is presented in Fig. 14.
Network efficiency during secure communication can be
defined as the total amount of secure patient’s data that reaches
the processing rate ratio for each hospital. When the network
load is low, our model is not effected. Furthermore, when
the patient count increases and there is mobility among the
hospitals, the network load increases our model shows less
negative effects, showing its suitability for use in a distributed
hospital network.
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order

2168-2194 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2020.2969648, IEEE Journal of
Biomedical and Health Informatics
10
Fig. 14: Comparison of Authentication
V. CO NC LU SI ON
The importance of authentication in achieving secure com-
munication in hospital (or any other) networks is evident.
Blockchain-based authentication approaches are one recent
trend, due to the fact that blockchain can be leveraged to pro-
vide a transparent and efficient communication platform. Our
blockchain-based approach is designed to allow the recording
of data securely in a geographically diverse hospital network.
All members in the presented authentication scheme can also
participate in the P2P communication and easily migrate to
other affiliated hospitals in the network via their distributed
identity. The authentication process used does not require re-
authentication of devices, which results in increased through-
put, reduced time overhead and reduced energy consumption
on the devices.
Future research will include implementing a prototype of
the proposed approach in a real-world setting, for example in
collaboration with a small-scale hospital. This would allow us
to identify any potential weaknesses or areas that need further
refinement.
REF ER EN CE S
[1] C. Yu, X. Xiang, Q. Zhang, and G. Xu, “Adaptive fuzzy trajectory
tracking control of an under-actuated autonomous underwater vehicle
subject to actuator saturation,” International Journal of Fuzzy Systems,
vol. 20, no. 1, pp. 269–279, 2018.
[2] M. Mettler, “Blockchain technology in healthcare: The revolution starts
here,” in 2016 IEEE 18th International Conference on e-Health Net-
working, Applications and Services (Healthcom). IEEE, 2016, pp. 1–3.
[3] Q. Xia, E. B. Sifah, K. O. Asamoah, J. Gao, X. Du, and M. Guizani,
“Medshare: Trust-less medical data sharing among cloud service
providers via blockchain,” IEEE Access, vol. 5, pp. 14 757–14767, 2017.
[4] M. H. Berlian, T. E. R. Sahputra, B. J. W. Ardi, L. W. Dzatmika,
A. R. A. Besari, R. W. Sudibyo, and S. Sukaridhoto, “Design and
implementation of smart environment monitoring and analytics in real-
time system framework based on internet of underwater things and big
data,” in 2016 International Electronics Symposium (IES). IEEE, 2016,
pp. 403–408.
[5] T. Hyakudome, H. Matsumoto, Y. Nakano, Y. Watanabe, T. Fukuda,
R. Suga, K. Meguro, H. Yoshida, T. Kasaya, and H. Iwamoto, “Devel-
opment of asv for using multiple auvs operation,” in OCEANS 2018
MTS/IEEE Charleston. IEEE, 2018, pp. 1–4.
[6] F. Casino, T. K. Dasaklis, and C. Patsakis, “A systematic literature review
of blockchain-based applications: Current status, classification and open
issues,” Telematics and Informatics, vol. 36, pp. 55–81, 2019.
[7] T. McGhin, K. R. Choo, C. Z. Liu, and D. He, “Blockchain in healthcare
applications: Research challenges and opportunities,” J. Network and
Computer Applications, vol. 135, pp. 62–75, 2019.
[8] J. Xie, H. Tang, T. Huang, F. R. Yu, R. Xie, J. Liu, and Y. Liu, “A survey
of blockchain technology applied to smart cities: Research issues and
challenges,” IEEE Communications Surveys & Tutorials, vol. 21, no. 3,
pp. 2794–2830, 2019.
[9] A. D. Dwivedi, G. Srivastava, S. Dhar, and R. Singh, “A decentralized
privacy-preserving healthcare blockchain for iot,” Sensors, vol. 19, no. 2,
p. 326, 2019.
[10] G. Irving and J. Holden, “How blockchain-timestamped protocols could
improve the trustworthiness of medical science,” F1000Research, vol. 5,
2016.
[11] G. Srivastava, R. M. Parizi, A. Dehghantanha, and K.-K. R. Choo,
“Data sharing and privacy for patient iot devices using blockchain,” in
International Conference on Smart City and Informatization, G. Wang,
A. El Saddik, X. Lai, G. Martinez Perez, and K.-K. R. Choo, Eds.
Singapore: Springer Singapore, 2019, pp. 334–348.
[12] Y. Sompolinsky and A. Zohar, “Phantom: A scalable blockdag protocol.”
IACR Cryptology ePrint Archive, vol. 2018, p. 104, 2018.
[13] A. Yazdinejad, R. M. Parizi, A. Dehghantanha, and K. R. Choo,
“Blockchain-enabled authentication handover with efficient privacy pro-
tection in sdn-based 5g networks,” IEEE Transactions on Network
Science and Engineering, pp. 1–1, 2019.
[14] S. Huh, S. Cho, and S. Kim, “Managing iot devices using blockchain
platform,” in 2017 19th international conference on advanced commu-
nication technology (ICACT). IEEE, 2017, pp. 464–467.
[15] R. Guo, H. Shi, Q. Zhao, and D. Zheng, “Secure attribute-based
signature scheme with multiple authorities for blockchain in electronic
health records systems,” IEEE Access, vol. 6, pp. 11676–11 686, 2018.
[16] M. T. Hammi, B. Hammi, P. Bellot, and A. Serhrouchni, “Bubbles of
trust: A decentralized blockchain-based authentication system for iot,”
Computers & Security, vol. 78, pp. 126–142, 2018.
[17] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of
blockchain technology: Architecture, consensus, and future trends,” in
2017 IEEE International Congress on Big Data (BigData Congress),
June 2017, pp. 557–564.
[18] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain
challenges and opportunities: A survey,” International Journal of Web
and Grid Services, vol. 14, no. 4, pp. 352–375, 2018.
[19] P. J. Taylor, T. Dargahi, A. Dehghantanha, R. M. Parizi, and K.-K. R.
Choo, “A systematic literature review of blockchain cyber security,”
Digital Communications and Networks, 2019.
[20] R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and A. Singh, “Empirical
vulnerability analysis of automated smart contracts security testing on
blockchains,” in Proceedings of the 28th Annual International Confer-
ence on Computer Science and Software Engineering. IBM Corp.,
2018, pp. 103–113.
[21] A. D. Dwivedi, P. Morawiecki, and G. Srivastava, “Differential crypt-
analysis of round-reduced speck suitable for internet of things devices,”
IEEE Access, vol. 7, pp. 16 476–16 486, 2019.
[22] Q. Chen, F. Schmidt-Eisenlohr, D. Jiang, M. Torrent-Moreno, L. Del-
grossi, and H. Hartenstein, “Overhaul of ieee 802.11 modeling and
simulation in ns-2,” in Proceedings of the 10th ACM Symposium on
Modeling, analysis, and simulation of wireless and mobile systems.
ACM, 2007, pp. 159–168.
[23] J. Li, Y. Zhang, J. Zhao, Y. Wang, X. Ma, and W. Wu, “Ns-2 simulation
of vanet for safety applications: issues and solutions,” in Proceedings of
the 8th International Conference on Computer Modeling and Simulation.
ACM, 2017, pp. 67–72.
[24] A. Gervais, “Github bitcoin-simulator for ns3,” Oct 2016. [Online].
Available: https://github.com/arthurgervais/Bitcoin-Simulator
[25] T. Issariyakul and E. Hossain, “Introduction to network simulator 2
(ns2),” in Introduction to network simulator NS2. Springer, 2009, pp.
1–18.
[26] Z. Riha, “Toward reliable user authentication through biometrics,” IEEE
Security & Privacy, no. 3, pp. 45–49, 2003.
[27] F. Swiderski and W. Snyder, Threat modeling. Microsoft Press, 2004.
[28] S. T. Zargar, J. Joshi, and D. Tipper, “A survey of defense mechanisms
against distributed denial of service (ddos) flooding attacks,” IEEE
communications surveys & tutorials, vol. 15, no. 4, pp. 2046–2069,
2013.
[29] N. Vladimirova, “New attacks against 4g lte mobile networks
registered,” https://www.virusguides.com/new-attacks-4g-lte-mobile-
networks-registered/, 2018.
Downloaded from https://iranpaper.ir https://www.tarjomano.com/order