Journal Pre-proofs

Cryptographic Evidence-Based Cybersecurity for Smart Healthcare Systems

Hubert Szczepaniuk, Edyta Karolina Szczepaniuk

PII: S0020-0255(23)01218-5
DOI: https://doi.org/10.1016/j.ins.2023.119633
Reference: INS 119633

To appear in: Information Sciences

Received Date: 1 March 2023

Revised Date: 19 August 2023
Accepted Date: 28 August 2023

Please cite this article as: H. Szczepaniuk, E. Karolina Szczepaniuk, Cryptographic Evidence-Based
Cybersecurity for Smart Healthcare Systems, Information Sciences (2023), doi: https://doi.org/10.1016/j.ins.
2023.119633

This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover
page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version
will undergo additional copyediting, typesetting and review before it is published in its final form, but we are
providing this version to give early visibility of the article. Please note that, during the production process, errors
may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

© 2023 The Author(s). Published by Elsevier Inc.

 Cryptographic Evidence-Based Cybersecurity for Smart
Healthcare Systems
Dr Hubert Szczepaniuka*, Dr inż. Edyta Karolina Szczepaniukb
a Warsaw University of Life Sciences – SGGW, Nowoursynowska 166 ST., 02-787 Warsaw, Poland

b Polish Air Force University, Dywizjonu 303 no. 35 ST., 08-521 Dęblin, Poland

*Correspondingauthor: Hubert Szczepaniuk, Warsaw University of Life Sciences – SGGW,

Nowoursynowska 166 ST., 02-787 Warsaw, Poland, hubert_szczepaniuk@sggw.edu.pl

Abstract

The idea of smart healthcare assumes the implementation of integrated platforms

based on the Internet of Medical Things to improve the quality of medical processes. An
indispensable condition for the development of smart healthcare is ensuring the security of
medical data. The article presents a framework for the implementation of cryptographic proof
of smart contracts in healthcare systems. The proposed architecture implements secure
procedures for processing Electronic Health Records (EHRs) based on an access control
array. The cryptographic proof of smart contracts ensures the security of medical data
processing and also allows for non-repudiation, enforceability, and accountability of digital
agreements made between system actors. We developed an open data exchange format for
EHRs stored in the blockchain based on a nested tree structure and the DOM interface. The
article presents algorithms for creating, executing and validating smart contracts for
processing medical data contained in EHRs. The proposed solutions were subjected to
empirical tests and cybersecurity assessment in terms of threat and vulnerability analysis
using the risk analysis method. Steps recommended by ENISA and elements of the
methodology developed by NIST were used to develop a strategy for minimizing the
identified threats and vulnerabilities.

Keywords: Cybersecurity; Cryptographic Proof; Software Design; Intelligent Systems;

Electronic Health Record; Risk Assessment

1. Introduction

Numerous scientific studies and international organizations emphasize the importance

of digital transformation in healthcare. Advanced digital technologies can improve the quality
of medical processes, provide better diagnostics and support treatment (see e.g., [23]). The
World Economic Forum emphasizes that digital services will be one of the most important
drivers of healthcare transformation in the future [47]. The White Paper of the World
Economic Forum lists four digital themes that will be crucial for the digital transformation of
healthcare: smart care, care anywhere, empowered care, and intelligent healthcare enterprises
[47]. The European Commission has set out priorities for the digital transformation of
healthcare. Secure access to health data, personalization of medical processes through a
European data infrastructure and empowering citizens with digital health information tools
are key priorities [9]. The development of Smart Healthcare Systems (SHSs) assumes the
support of medical processes by new generation IT systems. Progress in supporting medical
processes is possible thanks to the dynamic development of the Internet of Medical Things
(IoMT).

1
 Designing IoMT systems supporting medical processes is a challenge on many levels.
SHSs generate Electronic Health Records (EHRs) that must be stored securely and processed
efficiently. The literature shows that EHR systems are one of the most important requirements
for doctors and hospitals [19]. EHRs include data obtained from the implementation of
various medical processes, e.g., clinical tests, ultrasound, cardiac electrocardiography, x-rays,
laboratory tests, measurements made by wearable monitoring devices, health applications,
medication history, treatment strategies, and diagnosed disease entities (see e.g., [41]). The
presented examples meet the definitional attributes of Big Data. Furthermore, SHS services
require real-time processing and continuous updating of patient data.

Nowadays, the issues of cyber security and its increasing complexity are major
concerns in organizations [12]. Since EHRs involve sensitive data, confidentiality and privacy
must be protected [36]. Ensuring the security of medical data and supporting the
interoperability of systems are other key requirements for the development of SHSs. IoMT
systems can generate many vulnerabilities and be exposed to many threats (see e.g., [44]).
The well-established theory available in ISO/IEC 27001 can be used to define the basic
information security requirements for SHSs. It is widely accepted that the key attributes of
information security are confidentiality, integrity and availability. It should be noted that IoT
systems based on a centralized architecture generate many vulnerabilities for the listed
information security attributes.

Zhou et al. [50] points out that traditional computer platforms cannot effectively
support the electronic processing of medical record data. Moreover, Huang et al. [10] rightly
note that centralized management requires large servers and backups, and query system
performance degrades over time. However, the centralized IoMT architecture can be
contrasted with the blockchain concept based on decentralized, distributed and cryptographic
proof rather than trust. The implementation of blockchain in SHSs brings an opportunity to
improve the cybersecurity of medical processes. In addition, literature analysis shows the
many benefits of integrating blockchain and Big Data technologies. The advantages of such
integration include: increasing data security, improving data integrity, preventing fraud,
supporting real-time data processing, improving data sharing, increasing Big Data quality, and
improving data access [3].

Research findings recently published by Zhao et al. [49] indicate that blockchain is a
promising alternative for the secure storage and management of medical data. The paper
demonstrates improving the cybersecurity of SHSs by implementing cryptosystem techniques
and a blockchain platform to protect sensitive medical data [49]. In particular, the proposed
solution uses Brooks Iyengar Quantum Byzantine Blockchain Networking (BIQBA-BCN)
and presents an authentication system based on the Okamoto Uchiyana Cryptosystem [49].

In this article, we used an extended approach that refers to international strategies for
developing Smart Healthcare Systems, ensuring cybersecurity of medical data, and
interoperability of systems. The article presents a multi-level architecture for the
implementation of cryptographic proof of smart contracts in SHSs.

Our main contributions cover five key aspects:

1. In reference to international strategies for the development of smart healthcare, we

present a framework for the technical architecture of processing EHRs in the
blockchain. The proposed architecture is based on the cryptographic proof of smart
contracts, which supports the non-repudiation, executability, and accountability of

2
 medical data processing.
2. We introduce an open data exchange format for EHRs stored in the blockchain, based
on a nested tree structure and the DOM interface. As a result, cross-platform data
exchange formats such as JSON and XML can be utilized for generating EHRs.
Consequently, this promotes interoperability of SHSs and the universality of EHRs
transformations from a programming perspective.
3. We present algorithms for creating, executing and validating smart contracts for
processing medical data contained in EHRs. The algorithms presented in pseudocode
implement digital contracts between selected system actors: the patient, the doctor,
and the pharmacy.
4. We present the results of empirical tests of the proposed architecture to assess stability
and performance.
5. The proposed solutions were subject to cybersecurity assessment regarding threat and
vulnerability analysis using the risk assessment method. Steps recommended by
ENISA and elements of the methodology developed by NIST were used to develop a
strategy for minimizing the identified threats and vulnerabilities.

The next sections of this article are organized as follows. Section 2 discusses the
methodology adopted in the research with reference to international strategies for the
development of smart healthcare. Section 3 defines a layered technology stack architecture for
IoT systems in smart healthcare. Section 4 examines consensus algorithms for their
implementation in SHSs. Section 5 presents the framework for the technical implementation
of blockchain in SHSs, taking into account the system’s architecture, medical data processing
procedures, access control matrix, interoperable format of EHRs, as well as algorithms for
creating, executing, and validating smart contracts established among the system’s actors.
Section 6 describes the test environment, empirical testing methodology, and stability and
performance results. Section 7 provides a cybersecurity analysis of the proposed architecture.
Section 8 discusses the research results. The paper ends with conclusions that summarize the
research carried out.

2. Research methodology

This article aims to design a framework for implementing blockchain technology in

smart healthcare. The adopted research methodology aims to support the open challenges of
digital healthcare development identified in available publications. Table 1 presents a
synthesis of selected publications concerning recommendations for cybersecurity, Big Data,
and interoperability for the future of smart healthcare.

Table 1. Recommendations and activity areas for digital transformation in healthcare

Recommendations and activity areas Importance for research

Liberate data sources to clarify that patients are Development of mechanisms enabling safe and free
the ultimate owners of their clinical data. access to medical data using a cryptographic proof.

Integration of medical data repositories through Blockchain network as an environment for medical
data standards and infrastructure. data repositories.

3
Interoperability requirements at the global level. Ensuring interoperability in data exchange and
services using APIs.

Developing standards for data quality, Blockchain cybersecurity assessment for SHSs.
reliability, and cybersecurity.

Standardization of Electronic Medical Records. Embedding Electronic Medical Records in

blockchain networks.

Improving interoperability by supporting open Development of an open format for health data in
exchange formats. nested tree notation.

Source: Based on [8], [47].

Taking into account the main objective of the study and the recommendations
presented in Table 1, the following specific objectives were defined:

 Development of the IoMT technology stack, taking into account the requirements of
cybersecurity, interoperability and Big Data.
 Analysis of consensus algorithms for blockchain implementation in SHSs.
 Development of the technical architecture for the implementation of blockchain
technology in SHSs.
 Development of an open data exchange format for EHRs in the blockchain network.
 Implementation of smart contract algorithms for concluding, approving and validating
transactions between stakeholders of medical processes.
 Software development and empirical testing.
 Cybersecurity assessment of the presented concept in terms of identifying threats,
vulnerabilities, and risk analysis.

The applied research methods were based on software engineering. Programming

concepts, software modeling methods, analysis of literature, legal and normative acts were
used in the research. The method of modeling documents in a nested tree structure based on
the DOM interface was used to develop an open data exchange format for EHRs.

Pseudocode programming and the access control matrix method were used to define
the smart contract algorithms. The analysis of blockchain cybersecurity in healthcare was
based on the risk analysis method. The study refers to the steps recommended by ENISA and
elements of the methodology developed by NIST.

3. Internet of Medical Things technology stack for Smart Healthcare Systems

Most SHSs are based on the IoT concept. The analysis of scientific studies shows that
the most popular is the layered approach to modeling the IoT architecture. The literature
review found the following solutions:

 Three-layer model – the most general model includes the sensing, transportation, and
application layers (see e.g., [43]).

4
  Four-layer model – introduces an additional layer of system security support through
the implementation of confirmation mechanisms (see e.g., [14]).
 Five-layer model – includes the perception, transportation, processing, and business
layers. An additional processing layer is responsible for processing the data received
from the perception layer through the transport layer. The business layer handles the
business logic of the IoT system (see e.g., [32]).
 Multi-component model – involves the systemic decomposition of a five-layer model
into a multi-component architecture based on the definition of a computer system
constituting a collaborative hardware and software system [39].

It should be noted that these are not the only IoT architecture models available in the
literature. Recently, the IEEE 2413-2019 standard has been available, which defines the IoT
architecture framework in accordance with the ISO/IEC/IEEE 42010 standard. Two standards
are particularly relevant: the IEEE P2413.1 Standard for Reference Architecture for Smart
Cities (RASC) and the IEEE P2413.2 Standard for Reference Architecture for IoT Power
Distribution (PDIOT). The IEEE P2413.1 standard promotes the Smart City concept based on
cross-domain interactions and semantic interoperability [11]. The Smart City concept
encompasses an Intelligent Operation Center (IOC) based on cloud computing and edge
computing technology, which facilitates city management thanks to the knowledge derived
from IoT and Big Data [11].

Currently, a new term “Internet of Medical Things” appears in the literature. Aman et
al. [2], referring to the IEEE P2413.1 standard, characterized a four-layer IoMT architecture,
which consists of layers of devices, network communication, platform and applications.
Various IoMT architecture models are available in the literature, but most concepts are based
on a layered approach. For example, Lu [16] presented a three-layer model that includes the
application, perception, and network protocol layers. Swarna Priya et al. [37] defined an IoT
technical architecture for implementing intrusion detection techniques.

It should be noted that regardless of the approach used, the following key research
areas can be distinguished in IoMT systems:

 medical and diagnostic devices,

 network communication,
 automation of medical data processing,
 intelligent prediction on Big Data,
 access interface for all stakeholders of medical processes,
 ensuring the cybersecurity of the system,
 ensuring the interoperability of systems.

To achieve our research goals, we propose to extend the layered IoMT model towards
cybersecurity and medical data processing. The proposed layer model is shown in Figure 1.

5
 PARTICIPANTS OF MEDICAL PROCESSES
Patients Doctors Medical Staff Insurance Companies Pharmacies Other IoMT
systems
- Service Oriented Architecture (SOA)
- Application Programming Interface (API)
INTERFACE
- Representational State Transfer (REST)
LAYER - Simple Object Access Protocol (SOAP)
- Fast Healthcare Interoperability Resources (FHIR)
REQUIREMENTS

- Big Data (Data Mining, Predictive and Prognostic

Models, Classification Models)
DATA ANALYSIS
- Artificial Intelligence (Neural Networks, Machine
LAYER Learning, Deep Learning, Expert Systems)
- On-Line Analytical Processing (OLAP)

- Relational databases (MySQL, DB2, PostgreSQL)

- Graph databases (Neo4J, Dgraph, FlockDB)
DATA STORAGE
- Document-oriented databases (MongoDB)
LAYER - Key-value databases (Redis)
CYBERSECURITY

- Blockchain

- Local Area Networks (IEEE 802.3, IEEE 802.11,

IEEE 802.15.1, NFC, Z-Wave, Zigbee)
TRANSPORT
- Low-Power Wide Area Networks (LoRaWAN,
LAYER NB-IoT, LTE-M)
- GSM Networks (4G, 5G)

- Hospital Devices
MEDICAL - Clinical Grade Wearables
DEVICES - Remote Patient Monitoring Devices
LAYER - Intelligent Ambulance Navigation Systems
- Smart Pills

Figure 1. IoMT layered model for Smart Healthcare Systems.

Source: Own work.

The above concept includes a technology stack of SHSs. The presented model
includes five stacked layers and a vertical layer of cybersecurity requirements. All layers must
comply with cybersecurity requirements. In the presented model, each layer has the following
specificity and functionality:

 Interface layer – provides an access interface for all participants of medical processes
and other IoMT systems. The primary task of the layer is to ensure interface
compatibility with other IoMT systems. The layer supports the interoperability of
digital health services. In order to implement the interoperability paradigm, the IoMT
infrastructure can be based on a service-oriented architecture (SOA). Business logic
modeling using atomized and cooperative access services facilitates the design,
development, implementation and management of IoMT system infrastructure. SOA is
related to web services and cross-platform data exchange formats (e.g., XML).
Information exchange within SOA-oriented services can be implemented based on
SOAP (Simple Object Access Protocol) and WSDL (Web Services Description
Language). The interoperability of SHSs can be supported synergistically by

6
 implementing an application programming interface (API) based on the REST
architecture. The API defines a set of development rules for how users and other
systems can communicate with SHS and how to access resources. The API defines a
set of programming rules for how users and other systems can communicate with
SHSs and how to access resources. The REST API does not require the application
calling the service to use a specific programming language [46]. An alternative
approach is the FHRI (Fast Healthcare Interoperability Resources) standard, which
describes the rules for exchanging Electronic Medical Records. FHRI is based on the
REST API architecture and supports XML, JSON, ND-JSON, and RDF data exchange
formats (see e.g., [30]).
 Data analysis layer – provides automated processing of Big Data obtained from the
lower layers of the model. The layer is responsible for supporting diagnostic
processes, monitoring the patient’s condition, and automating all activities related to
the handling of medical processes. The layer is responsible for supporting diagnostic
processes, monitoring the patient’s condition and automating medical processes. The
latest research results demonstrate the effectiveness of using artificial intelligence
methods, such as deep networks (see e.g., [4]), as well as ensemble classifiers and
weighting algorithms (see e.g., [48]), in supporting medical processes. AI methods
have shown particular effectiveness in counteracting the COVID-19 pandemic (see
e.g., [13]). On the other hand, it should be noted that the latest research raises a
legitimate question about the reliability of artificial intelligence applications in critical
domains (see e.g., [22]).
 Data storage layer – provides a manageable space for storing electronic medical data.
Depending on the solution, the layer implements a different degree and form of data
structuring, which results from the data model used in the selected Database
Management System (DBMS). The classic approach is based on relational databases,
where the advantages are the integrity and formalization of the data model. It is
postulated that with the increasing volume and variety of digital health records,
relational databases are not always adequate (see e.g., [41]). For this reason, business
and science are increasingly focusing on NoSQL databases. NoSQL databases include
various DMBSs and data models. The main advantages of NoSQL solutions include
the flexibility of the data model, the ability to adapt the data schema to the structure of
medical records, and the speed of database querying. NoSQL databases include, but
are not limited to, document-oriented solutions that store information in JSON or
BSON format. The document structure of the schema enables its flexible adaptation to
dynamically changing data sets during the implementation of medical processes. The
document-oriented data schema enables its flexible adaptation to the dynamically
changing data structure during the implementation of medical processes. Graph
databases enable modeling of data structures based on the mathematical concept of a
directed graph. The most important advantages of graph databases are the speed of
data querying and an additional layer of semantics enabling freely modeled
relationships between graph nodes. In contrast, key-value databases store data in a
hash table containing a set of keys and values.
 Transport layer – provides data transmission from the medical device layer to the
upper layers. Data transmission in IoMT systems is not limited to a specific
architecture or transmission medium and is based mainly on the TCP/IP protocol stack
and the ISO/OSI model. However, in order to fully realize the potential of IoMT
systems, next-generation networking solutions must be developed. Information-
Centric Networking (ICN) is a new communication paradigm (see e.g., [17]). The ICN
concept is based on an information-oriented architecture rather than a host-oriented

7
 architecture. This assumption is in line with the development of IoT and IoMT
systems. In addition, energy-efficient wireless transmission media are crucial. The
leading wireless communication technologies are LoRaWAN, NB-IoT, LTE-M and
5G networks.
 Medical device layer – supports IoMT end devices, sensors and wearable devices that
enable the implementation of medical processes.
 Cybersecurity requirements – define the security guidelines for medical data at every
stage of medical processes and for all layers of the stack. Ensuring the cybersecurity
of medical processes requires taking into account the attributes of confidentiality,
availability and integrity.

The presented layered architecture is the basis for further research and is a component
of SHSs.

4. Consensus algorithms in Smart Healthcare Systems

In general terms, a blockchain can be described as a distributed database that stores

transactions in blocks connected by a chain structure [45]. Originally, the concept of
blockchain technology was outlined in an article by Satoshi Nakamoto [18]. The main
contribution of the paper is a new paradigm for solving the double-spending problem based
on cryptographic evidence [18]. The architecture framework defined in Nakamoto’s
publication is based on the following assumptions [18]:

 the database structure is based on a digital signature chain,

 a single block represents a transaction between the owner and recipient of digital cash
units,
 the ownership transfer transaction is accomplished by digitally signing the hash
function of the previous transaction and the new owner’s public key,
 ownership can be verified by checking digital signatures,
 the distributed timestamp server generates a computational proof of block order and
confirms that the data must have existed at the specified time,
 the timestamp includes the previous marker in its hash function and thus strengthens
the evidential power of previous entries,
 the distributed timestamp server is based on a proof-of-work algorithm similar to
Adam Back’s Hashcash system,
 the network consists of nodes that work to extend the blockchain through a proof-of-
work algorithm to find the value for hash functions.

The project was released with the open-source Bitcoin Core software, available under
the MIT license. The presented architecture was designed for digital payment transactions, but
its innovation attracted the attention of science and business. Over the last decade, many
theoretical studies and practical implementations based on blockchain technology have been
created, especially in Industry 4.0 (see e.g., [5]). Blockchain is considered a promising
solution to issues related to secure storage, data sharing, trusted network control, and asset
management [45]. The variety of applications has led blockchain technology to evolve
towards new concepts, algorithms and software architectures. Since there are no trusted third
parties in blockchain networks, consensus algorithms are used to ensure transaction security.
The most popular consensus algorithms in blockchain networks are Proof-of-Work (PoW)
and Proof-of-Stake (PoS).

8
4.1. Proof-of-Work

Currently, the PoW algorithm is the most widely used consensus mechanism in
consensus-based blockchain networks. PoW algorithms use hardware resources (CPU, GPU,
and ASIC) to generate hash functions for blocks until a valid solution is found. The chance of
finding the correct solution increases in direct proportion to the computing power. The
mathematical concept of the hash function prevents the reverse operation of obtaining input
data from the resulting hash. Using the hash function (e.g., SHA-256) enables
computationally inexpensive integrity verification. It should be noted that as the number of
nodes in the network increases, finding the correct solution for a block becomes more
difficult.

PoW protocols include two classes of algorithms [25]:

 Challenge – Response – there is a direct interactive connection between the provider

and requester nodes. The provider specifies the task, and the requestor must find the
correct answer to the challenge.
 Solution – Verification – there is no direct connection between the client and the
supplier. The provider is responsible for verifying the selection of the problem and
solution.

The main disadvantage of the PoW protocol is the high power consumption, which
increases in proportion to the number of nodes in the blockchain network.

4.2. Proof-of-Stake

Proof-of-Stake protocols assume that blocks and transactions are validated based on
the stakes of participating nodes [29]. The node selection algorithm takes into account many
factors. The main factor is the size of the node’s participation in the blockchain. Node
promotion is based on the declared stake value. This assumption creates the risk that PoS
algorithms may favor selected nodes. Therefore, some PoS algorithms implement fairer node
selection methods. The following methods are used in practice [29]:

 Randomized Block Selection – the algorithm selects nodes based on the hash value and
size of the node's share in the blockchain.
 Coin Age Selection – the algorithm selects nodes based on the declared stake and the
time the node maintains it.

The main advantage of PoS algorithms is energy efficiency. Nodes do not need to use
computational resources to execute complex algorithms. The main disadvantage is the threat
of network centralization. Therefore, the security of PoS algorithms comes from the number
of nodes that hold a copy of all blocks.

4.3. Delegated Proof-of-Stake

Delegated Proof-of-Stake algorithms are an extension of the PoS protocol and are
designed to improve the efficiency and fairness of selecting nodes responsible for committing
new blocks. The basic assumption of DPoS is to guarantee network security by delegates
elected in a voting procedure from other network nodes (stakeholders). Delegates elected by
voting are responsible for approving blocks and ensuring consensus within the network.
Similar to the PoS protocol, the algorithm takes into account the size of the node’s share in

9
the blockchain and the stake that affects the voting power. The main advantage of DPoS
algorithms is the implementation of democratic mechanisms. The main limitation is the threat
of malicious nodes in case of insufficient incentive to vote.

4.4. Smart contacts

Nick Szabo presented the concept of smart contracts in the 1990s as a method that
enables the secure implementation of digital contracts between communication parties in
computer systems [38]. In a blockchain network, smart contracts are described by
programming code that defines a set of rules enforceable by nodes. In the theory of computer
networks, smart contracts in blockchain networks can be seen as secure and trusted distributed
protocols for the enforcement of procedures defined in contracts. The programming code that
executes digital contracts is executed automatically when certain conditions are met.

The key benefits of smart contracts embedded in blockchain networks are:

 saving the content of contracts in blocks – smart contracts are included in approved
blocks for which the network has reached a consensus;
 distributed orientation – smart contracts can replicate to all nodes in the network;
 automation – tasks are performed automatically after meeting the conditions contained
in the contract;
 no modification possible – the blockchain guarantees that the terms of the contract
contained in smart contracts will remain unchanged.

From a programming perspective, smart contracts can be used to build a blockchain

network that meets the Turing completeness postulate. In practice, it is possible to program
distributed applications for solving the same class of problems as the original Turing machine.

5. Blockchain implementation framework for Smart Healthcare Systems

The following assumptions were made when designing the blockchain implementation
framework in SHSs:

 EHRs generated during medical processes can be stored on the blockchain.

 The system architecture should support the key attributes of information security, i.e.,
confidentiality, availability and integrity.
 System actors should have different permission levels to access medical data.
 Data manipulation procedures should be secured with smart contracts.
 The system should support interoperability by standardizing data structures and APIs.

5.1. Data manipulation procedures based on smart contracts

Stakeholders of SHSs are participants in medical processes. According to software

engineering, a set of system actors should be defined at an early stage of designing an IT
system. The study assumed that the set of system actors corresponds to the users defined in
Figure 1. Individual stakeholders (system actors) have different levels of access rights to
EHRs processing procedures. Interactions between stakeholders require the implementation
of secure digital contracts to process EHRs. Therefore, the concept based on smart contracts
in the blockchain network was used to identify stakeholders and implement digital contracts.
Table 2 presents the stakeholders of the designed system and the corresponding procedures
for processing EHRs.

10
Table 2. Processing procedures for Electronic Health Rectors

System actors Data manipulation procedures based on smart contracts

Patients  access to personal data

 access to clinical data
 creating and modifying personal data
 granting permissions for access to medical data for other systems
and entities

Doctors and  access to patients’ personal data

 access to patients’ clinical data
Medical staff  data entry and generation of medical data records

Pharmacies  confirming the fulfillment of a prescription issued by a doctor

 confirming the patient’s insurance in order to sell reimbursed
medications

Insurance companies  confirming the patient’s insurance

 requesting access to patients’ medical data
 access to patient data after obtaining permission

Other Smart Healthcare  requesting access to patients’ medical data

Systems  access to patient data after obtaining permission
 sharing and exchanging data between other systems

Source: Own work.

5.2. System architecture

The designed software architecture consists of cooperating components in order to

implement the defined assumptions as well as the requirements of cybersecurity, Big Data and
interoperability. The proposed framework for the implementation of the blockchain in Smart
Healthcare Systems based on smart contracts is shown in Figure 2.

11
 Insurance companies Pharmacies Other SHS

API REST API REST

Doctors
Smart Contract 1: Issuing a prescription Medical staff
Patients

Smart Contract 2: Granting permission

API Hospital
Smart Contract 3: Data exchange
REST

Smart Contract 4: Insurance confirmation

.
.
. Big Data engine
Smart Contract n: Procedure n EHR’s Manager

EHR Block n EHR Block n+1 EHR Block n+2

Hash Hash Hash
Previous hash Previous hash Previous hash
Time stamp Time stamp Time stamp

EHR Data EHR Data EHR Data

Blockchain nodes securing the network

Figure 2. Smart Health System architecture based on the blockchain network.

Source: Own work.

The key components of the proposed architecture include:

 System Users – a set of stakeholders including patients, doctors, medical staff,

hospitals, insurance companies, pharmacies and other healthcare systems.
 Application Programming Interface (API) – defines the access protocol to resources
provided by system services. The API provides the execution of procedures based on
input parameters and returns service results. This ensures that interoperability is
supported regardless of the internal architecture of the system.
Furthermore, the API-based programming approach increases security by
encapsulating internal procedures and medical data.
 IoMT medical devices – a collection of devices that includes, among others,
distributed diagnostic sensors, monitoring devices, wearables, and hospital technical
equipment.
 Big Data engine EHR’s Manager – an environment for analyzing and processing
medical data with the use of data exploration and extraction tools.
 Smart Contracts – digital contracts embedded in the blockchain with enforceability

12
 and non-repudiation rules that secure the transactions of medical process stakeholders.
 Distributed blockchain – a blockchain network storing EHRs generated during
medical processes.
 Network securing nodes – computer systems securing the network in terms of
transaction validation and generation of new blocks based on consensus algorithms.

In the next step, the presented architecture will be detailed with technical issues
regarding the structure of EHRs, smart contract algorithms and transactions between
stakeholders of medical processes.

5.3. Representation of medical records in a nested tree format

Interoperability of SHSs is supported by the REST API scheme shown in Figure 2.

Unifying SHS interfaces according to REST APIs requires standardizing the format for
storing and exchanging medical data. Unifying interfaces of SHSs in accordance with REST
API requires a compatible format for storing and exchanging medical data. This paper
proposes the use of formats that enable a structured representation of medical data. The
research used platform-independent formats such as JSON and XML. The study used
Document Object Model (DOM) notation to represent EHRs in a nested tree structure. By
using the DOM, it is possible to build a new level of programming interface abstraction for
manipulating EHRs saved in XML or JSON format. The DOM is a programming language-
independent interface for modeling documents as a logical nested tree structure. Each node in
the tree contains a collection of objects.

In order to implement the SHS architecture shown in Figure 2, the EHR is defined as
follows:

𝐸𝐻𝑅 →〈 𝑀𝑒𝑡𝑎𝑑𝑎𝑡𝑎, 𝐵𝑙𝑜𝑐𝑘𝑐ℎ𝑎𝑖𝑛 𝑑𝑎𝑡𝑎, 𝐻𝑒𝑎𝑙𝑡ℎ𝑐𝑎𝑟𝑒 𝑑𝑎𝑡𝑎 〉 (1)

key:

 𝑀𝑒𝑡𝑎𝑑𝑎𝑡𝑎 – a nested subtree describing the metadata of the EHR. The subtree is
defined as 𝑀𝑒𝑡𝑎𝑑𝑎𝑡𝑎→〈 𝐴𝑐𝑐𝑒𝑠𝑠 𝑟𝑖𝑔ℎ𝑡𝑠, 𝐼𝐷 〉. 𝐴𝑐𝑐𝑒𝑠𝑠 𝑝𝑟𝑖𝑣𝑖𝑙𝑎𝑔𝑒𝑠 is described as a
subset of the Cartesian product determined on the set of system stakeholders 𝑆 =
{𝑠1,…,𝑠𝑛} and the set of data access rights 𝑅 = {𝑟1,…,𝑟𝑛}, such that
𝐴𝑐𝑐𝑒𝑠𝑠 𝑟𝑖𝑔ℎ𝑡𝑠 ⊆ 𝑆 × 𝑅. Each ordered pair (𝑠𝑛,𝑟𝑛) defines a single access level for a
given stakeholder. In the JSON notation, the set of access rights to medical data will
be contained in a one-dimensional table 𝐴 [𝑎1,…,𝑎𝑛].
 𝐵𝑙𝑜𝑐𝑘𝑐ℎ𝑎𝑖𝑛 𝑑𝑎𝑡𝑎 – a nested subtree describing the block header data in the
blockchain. The subtree is defined as 𝐵𝑙𝑜𝑐𝑘𝑐ℎ𝑎𝑖𝑛 𝑑𝑎𝑡𝑎→
〈 𝐵𝑜𝑐𝑘 ℎ𝑎𝑠ℎ, 𝑃𝑟𝑒𝑣𝑖𝑜𝑢𝑠 ℎ𝑎𝑠ℎ, 𝑇𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 〉. 𝐵𝑜𝑐𝑘 ℎ𝑎𝑠ℎ contains a unique
“fingerprint” for a given block generated using a cryptographic hash function and
digital signatures according to a block generation algorithm. 𝑃𝑟𝑒𝑣𝑖𝑜𝑢𝑠 ℎ𝑎𝑠ℎ contains
a unique “fingerprint” for the previous block in the blockchain. 𝑇𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 contains
information about the block creation time.
 𝐻𝑒𝑎𝑙𝑡ℎ𝑐𝑎𝑟𝑒 𝑑𝑎𝑡𝑎– a nested subtree describing collections of medical data. The
subtree is defined as 𝐻𝑒𝑎𝑙𝑡ℎ𝑐𝑎𝑟𝑒 𝑑𝑎𝑡𝑎→ 〈 𝑃𝑎𝑡𝑖𝑒𝑛𝑡 𝐼𝐷, 𝐷𝑜𝑐𝑡𝑜𝑟 𝐼𝐷, 𝐶𝑙𝑖𝑛𝑖𝑐𝑎𝑙 𝑑𝑎𝑡𝑎 〉.
𝑃𝑎𝑡𝑖𝑒𝑛𝑡 𝐼𝐷 contains the unique identifier of the patient. 𝐷𝑜𝑐𝑡𝑜𝑟 𝐼𝐷 contains the
identifier of the doctor responsible for implementing medical procedures.
𝐶𝑙𝑖𝑛𝑖𝑐𝑎𝑙 𝑑𝑎𝑡𝑎 is the next nested subtree that contains the medical data collection for

13
 transactions added to the blockchain during medical process execution.

Figure 3 shows the EHR model in a nested tree structure based on the DOM interface.

Figure 3. Model of the EHR in a nested tree structure based on the DOM interface.

Source: Own work.

Any EHR defined in a general way according to the formula (1) can be converted to
the form described by the DOM interface to specify the detailed structure of the document in
XML and JSON format. The framework structure of EHRs in XML and JSON formats is
presented in the following documents.

DOCUMENT 1: ELECTRONIC HEALTH RECORD IN XML FORMAT

1
<?xml version="1.0" encoding="UTF-8"?>

2 <metadata>

3 <access_rights type=”array”>

4 <subject name=”s1”> access right r1 </subject>

5 <subject name=”sn”> access right rn </subject>

6 </access_rights>

7 <document_id> … </document_id>

8 </metadata>

9 <blockchain_data>

10 <block_hash> hash function output </block_hash>

14
11 <previous_hash> hash function output </previous_hash>

12 <timestamp> block generation time </timestamp>

13 </blockchain_data>

14 <healthcare_data>

15 <doctor_id> … </doctor_id>

16 <patient_id> … </patient_id>

17 <clinical_data> … </clinical_data>

18 </healthcare_data >

19
</xml>

DOCUMENT 2: ELECTRONIC HEALTH RECORD IN JSON FORMAT

1
{

2 metadata: {

3 access_rights: [ { s1, r1 }, … , { sn, rn } ] ,

4 document_id: “…” }

5 },

6 blockchain_data: {

8 block_hash: “<<hash function output>>”,

9 previous_hash: “<<hash function output>>”,

10 timestamp: “<<block generation time >>”

11 },

12 healthcare_data: {

13 doctor_id: “…”,

14 patient_id: “…”,

15 clinical_data: { … }

16 }

15
17
}

Both XML and JSON formats are independent of programming languages and enable
compatible data exchange between different healthcare systems. From a programming
perspective, JSON and XML formats support value validation and mapping data structures to
programming objects.

5.4. Access control matrix for EHRs

Resource protection in IT systems can be implemented in various ways. One of the

key mechanisms is defining access rights to the objects, processes and datasets to be
protected. Various approaches are used to formally define access rights in information
systems. Access rights can be defined using access console matrixes, capability-based
cybersecurity methods, and access control lists. The study used an approach based on the
access control matrix method.

The universality of the access console matrix enables the transformation and decomposition
of access rights to notations adopted by other methods.

The main categories related to defining access rights in IT systems are [35]:

 Entities – a unit capable of performing activities on the protected object. An entity can
be a user or another system and application executing various procedures on an object.
Typically, three entities are assumed: resource owner, group, and other users.
 Objects – protected system resources.
 Access rights – describe how an entity can control an object and include the following
categories: reading, writing, executing, deleting, creating, and searching.

The first step in creating the access control matrix is to define a set of entities that
relates directly to the system’s actors (see section 5.1). The set S of entities includes patients,
doctors, medical staff, pharmacies, insurance companies, and other SHSs. The set O of system
resources to be protected includes EHRs, smart contracts, and entities. Including entities in
protected system resources means that other entities can grant and revoke access rights to
entities.

The set R of access rights is defined as follows:

 read – data from EHRs stored in the blockchain and reading smart contracts,
 write – adding data to the blockchain,
 execute – execution of a smart contract,
 delete – data deletion,
 create – adding a smart contract to the blockchain,
 search – searching data in the blockchain,
 grant rights – granting entities access rights to EHRs;
 revoke rights – removing access rights to EHRs from entities,
 copy rights – copying access rights to EHRs to another entity.

Table 3 presents the access control matrix for resources of the SHS.

16
Table 3. Access control matrix

Entities System resources (set O)

(set S)
EHRs Smart Contracts Entities

Patients read, search read, create, delete, grant rights,

execute
revoke
rights,

copy rights

Doctors, medical, and hospital read, search, read, create, delete, grant rights,
administrative staff write execute
revoke
rights,

copy rights

Pharmacies read, search, read, execute no rights

write

Insurance companies read, search read, create, delete, no rights

execute

Other SHSs read, search create, delete, execute no rights

Source: Own work.

The access control matrix can be decomposed into columns for conversion into Access
Control Lists (ACL) [35]. Decomposition by rows defines permission tickets [35].

5.5. Smart contract algorithms in the Smart Healthcare System

Smart contracts can describe objects, business processes, and even manage a business
domain. It is possible to define rules for managing any resources, objects and business
processes in smart contracts. However, before stakeholders can transact, a business model
must be defined that includes all processes, rules, and datasets. This paper demonstrates how
smart contracts can be used for issuing, fulfilling and confirming drug prescriptions in Smart
Healthcare Systems. Let’s assume that the analyzed process includes three entities: a doctor, a
patient and a pharmacy. The doctor issues a prescription to the patient, which contains
information about the medicines used. The patient can fill the prescription at any pharmacy
that verifies it and confirms its fulfillment. The doctor, the patient and the pharmacy can
verify the prescription on the blockchain. The smart contract pseudocode for issuing,
fulfilling, and verifying a prescription is presented in algorithms 1, 2 and 3.

17
ALGORITHM 1: ESTABLISHING A SMART CONTRACT IN THE APPLICATION LAYER
1
Initialization of objects and variables: patient, doctor, medications

2
patient ← constructor Patient ( patient_address )

3
doctor ← constructor Doctor ( doctor_address )

4 medications ← constructor Medications ( array [𝑚1,…,𝑚𝑛] )

5
prescription ( patient, doctor, medications )

6
end

ALGORITHM 2: SMART CONTRACT EXECUTION

1 Initialization of objects and variables: medications, pharmacy, doctor, patient

2 query ( medications )

3 get ( medications )

4 return ( medications )

5 end

6 query ( pharmacy )

7 get ( pharmacy )

8 return ( pharmacy )

9 end

10 prescription ( patient, doctor, medications )

18
11 query ( medications )

12 medications.buyer ← patient

13 medications.seller ← pharmacy

14 medications.doctor ← doctor

15 set( medications ).current_date( )

16 return transaction_id

17 end

ALGORITHM 3: SMART CONTRACT VALIDATION

1
request ( patient, doctor, medications, pharmacy )

2
transaction_id ← 𝑡 ∈ {𝑡1,…,𝑡𝑥}

3
signature ← { ( patient, doctor, medications, pharmacy ) & signatory }

4
end

5
response ( request ( patient, doctor, medications, pharmacy ) )

6 approval: { medications.buyer ← patient; medications.seller ← pharmacy;

7 medications.doctor ← doctor }

8 signatures:

9 signed by a doctor

10 signed by a pharmacy

11
end

It should be noted that the implementation of smart contracts for medical processes
depends on the individual logic adopted in a given medical facility.

19
6. Empirical tests

Empirical tests allowed to assess the actual operation of the proposed solutions and
their behavior in various test scenarios and network load conditions. Conducting empirical
tests allowed to verify the stability of the network and assess performance. The
implementation of empirical tests required, among other things, the development of a test
environment, the implementation of the application engine in a chosen programming stack,
the definition of network configurations, the adoption of a methodology for empirical
research, and the analysis of the obtained results.

6.1. Characteristics of the test environment

For the purposes of the research, a private blockchain network was constructed based
on the open-source platform, Hyperledger Fabric. A key advantage of the private blockchain
network is the enhanced protection of sensitive patient health data, as only authorized
stakeholders have access to the system. In contrast, the public blockchain is open to anyone
who wants to view transactions or implement smart contracts. For this reason, privacy in
public blockchains can be significantly limited. Therefore, instead of a public unauthorized
network where nodes with unknown identities can participate, our solution relies on
components being authorized by a trusted member service provider. Thus, all the transaction
processing nodes are authorized machines in the organization’s computer network. This
means that in the proposed architecture, sensitive medical data contained in EHRs, as well as
digital contracts concluded between stakeholders, are encrypted and shared only with
authorized entities.

The test environment included six nodes of the private blockchain network. The six-
node network was used to model a business structure involving two organizations with three
nodes in each. Peer nodes, order nodes, and channel nodes were then created in the designed
business domain. In addition, six nodes ensure high data redundancy and fault tolerance,
which is crucial for processing sensitive patient data. Computer units equipped with an i5-
9400 6x2.9 Ghz processor, 16 GB DDR4 2666 Mhz CL16 RAM and a 512 GB M.2 SATA3
SSD were used to build the network. The Ubuntu 20.04 LTS operating system was installed
on the computer units.

It should be noted that in the production environment, the number of nodes must meet
the needs and requirements of medical facilities.

6.2. Technology stack

Software engineering specifies that the choice of software architecture and technology
stack should be determined by the organization’s business requirements as well as the
functional and non-functional requirements of the system. In the context of SHSs, it is crucial
to consider cybersecurity, medical data privacy, network scalability, transaction processing
efficiency, compliance with applicable laws, compatibility with existing solutions,
interoperability and support for open-source solutions.

The Hyperledger Fabric framework was used as the core of the proposed solution due
to the possibility of flexible adaptation to business specifications and support for Java SDK.
CouchDB is the recommended database for the Hyperledger Fabric environment due to its
replication mechanisms. The gRPC and TLS protocols were chosen for communication
between nodes in the network due to their proven security.

20
 The technology stack used in the test environment included, among others, the
following platforms, tools and architectural components:

1. Hyperledger Fabric – an open platform for creating distributed business applications

based on blockchain.
2. Hyperledger Fabric Java SDK – the official development platform for Java that
provides an API to interact with the Hyperledger Fabric network.
3. Java Development Kit – a set of programming tools for developing software in Java.
4. Maven – an open development tool for managing Java projects.
5. Spring Boot – a framework for Java that provides many ready-made solutions and
facilitates API development.
6. Docker – an open platform for virtualizing isolated containers.
7. Fabric CA – a certification service that enables the identification of users in the
network.
8. Protocols: TLS, gRPC.
9. CouchDB – a database for storing metadata and transaction data.

In Table 4, the main components of the technology stack are presented along with the
justification for their selection, benefits for SHSs, and possible alternatives.

Table 4. Technology choices, justification and alternatives

Technologies Justification and potential benefits for SHSs Alternatives

Hyperledger The platform enables the implementation of a private blockchain with Ethereum, Codra,
Fabric access control mechanisms. The solution provides access control to OpenChain,
medical data and authentication of individual network elements using Quorum
a trusted member service provider.

Hyperledger The ability to flexibly define transaction logic, validation rules, access SDK for Python,
Fabric Java SDK control policies, and node management in Java is important for SHSs Go, Node.js
that often have to adapt to specific requirements and needs.

Java The cross-platform nature of Java allows applications to run on Python,

Development Kit various hardware and software platforms, which is essential for
(JDK) medical systems that can run on a variety of devices. C#, Go,

Node.js

Maven The ability to integrate with Hyperledger Fabric Java SDK and Gradle, Apache
manage the application implementation process, in particular Buildr
dependencies, naming convention and versioning of application
modules.

Spring Boot Support for system interoperability through the implementation of Micronaut, Vert.x
RESTful API.

Docker Docker enables container virtualization and application isolation. An Kubernetes, CRI-
additional layer of encapsulation improves the security of medical

21
 data. O, LXC Podman

Fabric Certificate Fabric CA offers many security features for secure certificate Let’s Encrypt,
Authority management. EJBCA

This prevents unauthorized access to medical data and controls

network access.

TSL The protocol is responsible for data confidentiality during SSL, IPSec, DTSL
transmission and authentication mechanisms.

gRPC The protocol is responsible for establishing a session for a given client Ethereum JSON-
identity. The returned object enables interaction with the blockchain RPC, Web3.js
and access to smart contracts.

CouchDB The database supports data replication and synchronization MongoDB,

mechanisms, which makes it a good choice for blockchain networks. LevelDB

Source: Own work.

The choice of technologies included in Table 4 was dictated by their stability,

efficiency and proven security, as well as the popularity of ready-made frameworks and
development tools that facilitate the implementation of blockchain applications. In particular,
open-source solutions were promoted.

6.3. REST API endpoints and sequence diagrams

Two smart contracts were implemented for the empirical tests in accordance with the
algorithms 1-3 proposed in the article, which implement the following business logic:

 smart contract A – registration of a new prescription for medications for a patient,

 smart contract B – fulfillment of a prescription for medications in a pharmacy.

The sequence diagram for the execution of the smart contract A is shown in Figure 4.

22
 Figure 4. Sequence diagram for the smart contract A.

Source: Own work.

The sequence diagram for the execution of smart contract the B is shown in Figure 5.

Figure 5. Sequence diagram for the smart contract B.

23
 Source: Own work.

The definition of REST API endpoints for the examined smart contracts is as follows:

1. Smart contract A – registration of a new prescription for medications for a patient:

 purpose: adding a new prescription for medications for a patient with a specific
identifier,
 HTTP method: POST,
 URL: /ehr/api/prescriptions-add,
 authorization method: JWT token with information about the user’s permissions,
 request structure: JSON format as defined in Document 3.

DOCUMENT 3: REQUEST STRUCTURE FOR SMART CONTRACT A

1
{

2
“patientID”: Object(Global Patient Identifier),

3
“doctorID”: Object(International Doctor ID),

4
“medicines”: [

5 {

6 “name: “aspirin”,

7 “dose: “1000 mg”,

8 “duration: “5 days”

9 },

10 {

11 “name: “vitamin C”,

12 “dose: “500 mg”,

13 “duration: “10 days”

14 }

15
]

16
}

 response structure: JSON format as defined in Document 4.

24
DOCUMENT 4: RESPONSE STRUCTURE FOR SMART CONTRACT A
1
{

2
“prescriptionID”: Object(Global Prescription Identifier),

3
“status”: “successfully added”

4
}

2. Smart contract B – fulfillment of a prescription for medications in a pharmacy:

 purpose: to fill a prescription for drugs for a patient with a specific identifier,
 HTTP method: PUT,
 URL: /ehr/api/prescriptions/{id}/execute
 authorization method: JWT token with information about the user’s permissions,
 request structure: JSON format as defined in Document 5.

DOCUMENT 5: REQUEST STRUCTURE FOR SMART CONTRACT B

1
{

2
“pharmacyID”: Object(PharmaID),

3
“prescriptionID”: Object(Global Prescription Identifier),

4
“timestamp”: “Thu Jan 12 2023 07:46:00 GMT+0000”

5
“medicines”: [

6 {

7 “name: “aspirin”,

8 “quantity: “2”,

9 “price: “4.55”

10 },

11 {

12 “name: “vitamin C”,

25
 13 “quantity: “4”,

14 “price: “1.99”

15 }

16
]

17
}

 response structure: JSON format as defined in Document 6.

DOCUMENT 6: RESPONSE STRUCTURE FOR SMART CONTRACT B

1
{

2
“prescriptionID”: Object(Global Prescription Identifier),

3
“status”: “successfully completed”

4
}

Chaincode scripts programmed according to algorithms 1-3 were used to translate

REST API endpoints into smart contract logic in the blockchain network.

6.4. Initial configuration of the blockchain network

Running the test environment requires the propagation of the network’s initial state,
which all nodes N1-N6 must know about. Then the genesis block was generated. The initial
state of the network was initialized with parameters in the crypto-config.yaml and
configtx.yaml files. The advantage of the Hyperledger Fabric platform is the ability to model
the business domain by defining consortia, organizations, member service providers,
channels, and certification authorities. Authorized blockchain network components use X.509
certificates to identify each other and confirm that they come from a trusted organization.

The structure of two medical organizations belonging to one consortium was modeled
for the empirical tests. The following assumptions were made in the research:

1. The business domain consists of two medical organizations, MedOrg1 and MedOrg2,
belonging to one medical consortium.
2. Three nodes were created for each organization: one ordering node and two peer
nodes.
3. A blockchain channel was created for each organization that contained only peer
nodes belonging to that organization.
4. A channel linking the MedOrg1 and MedOrg2 containing peer and ordering nodes was
established.

26
 5. The Membership Service Provider was defined to implement the identification and
authentication of network elements for each organization to ensure the security of
medical data.
6. The blockchain network contains smart contracts for processing patients’ medical
data.

The modeled structure considers two medical organizations operating within one
consortium, which means that they have similar business goals and follow the rules defined in
a common business domain. Therefore, the established consortium defines the operating
framework for both medical organizations. However, each organization controls its data and
transactions processed on the blockchain network. The six-node structure ensures a higher
level of data redundancy in the network and better resistance to potential failures.

Orderer node settings are also critical during network initialization. In particular,
values for address, time, and packet_size must be specified. The BatchTimeout,
MaxMessageCount and AbsoluteMaxBytes parameters were adjusted to the conditions of the
test environment and were set to 2s, 10, 99MB, respectively.

6.5. Empirical testing methodology

The implementation of empirical tests required the definition of test objectives, test
cases and the adoption of metrics used during the experiment.

6.5.1. Test objectives

The study adopted the following empirical test objectives:

 basic assessment of prototype stability,

 performance assessment of the blockchain network, taking into account the proposed
format of EHRs and defined smart contract algorithms.

Assessing the stability involves studying the behavior of the network under generated
load within a specified time horizon. Performance evaluation estimates how many
transactions the tested architecture can process within a given time frame. The performance
tests included multiple scenarios with various data sizes defined for the processed
transactions.

The stability assessment involved examining the network’s behavior under generated
load within a specified time horizon. The performance evaluation estimated how many
transactions the tested network could process within a given time frame and the delay in
transaction processing. Performance tests encompassed multiple scenarios with varying data
sizes for the processed transactions.

6.5.2. Test cases and adopted metrics

The study defined one test case for each test objective. The basic stability assessment
test case includes simulated network load generation, logging the number of network failures
along with the duration of incidents.

Network load parameters:

 block size: 8KB,

27
  number of sessions: 10 - 500.

Based on the methodology adopted by Roehrs et al. [27], the study used the following
metrics to assess network stability:

 Mean Time Between Failures (MTBF) [27]:

𝑇𝑜𝑡𝑎𝑙𝑊𝑜𝑟𝑘𝑖𝑛𝑔𝑇𝑖𝑚𝑒 ― 𝑇𝑜𝑡𝑎𝑙𝐵𝑟𝑒𝑎𝑘𝑑𝑜𝑤𝑛𝑇𝑖𝑚𝑒
𝑀𝑇𝐵𝐹 = 𝑇𝑜𝑡𝑎𝑙𝐵𝑟𝑒𝑎𝑘𝑑𝑜𝑤𝑛𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑠 (3)

 Mean Time to Repair (MTTR) [27]:

𝑇𝑜𝑡𝑎𝑙𝐵𝑟𝑒𝑎𝑘𝑑𝑜𝑤𝑛𝑇𝑖𝑚𝑒
𝑀𝑇𝑇𝑅 = 𝑇𝑜𝑡𝑎𝑙𝐵𝑟𝑒𝑎𝑘𝑑𝑜𝑤𝑛𝐼𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑠 (4)

 Availability (A) [27]:

𝑀𝑇𝐵𝐹
𝐴 = 𝑀𝑇𝐵𝐹 + 𝑀𝑇𝑇𝑅 (5)

The performance evaluation test case involved a transaction between a patient and two
medical organizations using the proposed nested tree structure for EHRs.

The test case involved examining two smart contracts:

 smart contract A – registration of a new prescription for medications for a patient,

 smart contract B – fulfillment of a prescription for medications in a pharmacy.

The network test load was defined as follows:

 number of sessions: 100-1000,

 block size: 8 KB, 16 KB, 32 KB.
The following metrics were adopted for performance evaluation:
 number of transactions per second (TPS),
 latency (ms) – the total time from when the session was submitted to when it was
served,
 CPU load and RAM usage.

6.6. Test results

The network configured according to the presented initial parameters was launched
according to the stability assessment test scenario for ten consecutive days, i.e., 240 hours.
During the study, stress tests were performed once a day according to the parameters
specified in the test scenario, increasing the number of simultaneous sessions from 10 to 500.
The obtained measurements made it possible to determine the MTBF metric, which amounted
to 15.8667 and the MTTR metric, which amounted to 0.1334. Based on the MTBF and MTTR
metrics, the system availability (A) was estimated, which in the analyzed period amounted to
0.9917. During the stability assessment, the average utilization of hardware resources was
also estimated. The obtained results are presented in table 5.

Table 5. Average consumption of hardware resources of network nodes.

28
Hardware resources 10 sessions 200 sessions 500 sessions

Processor (CPU) 0,2 Ghz 1 Ghz 2,2 Ghz

Memory (RAM) 1,2 GB 1,9 GB 2,4 GB

SSD/HDD 0,2 MB/s 4,2 MB/s 8,6 MB/s

Source: Own work.

In turn, the performance evaluation test scenario evaluates the execution of the smart
contracts per 1000 sessions. Based on the analysis of the collected metric values (latency, TPS
value and hardware resource consumption), the performance of the blockchain network can
be assessed at various block sizes, i.e., 8 KB, 16 KB and 32 KB. Tables 6 and 7 show the
obtained values of network performance metrics for 1000 sessions.

Table 6. Results for the performance evaluation test scenario – smart contract A

Avg
Block Min Latency Max Latency CPU Memory
Succ Fail TPS Latency
size (ms) (ms) (%) (MB)
(ms)

8 KB 1000 0 41 34 346 211 48 2740

16 KB 1000 0 25 32 377 279 52 2967

32 KB 1000 0 17 41 323 298 61 3289

Source: Own work.

Table 7. Results for the performance evaluation test scenario – smart contract B

Avg
Block Min Latency Max Latency CPU Memory
Succ Fail TPS Latency
size (ms) (ms) (%) (MB)
(ms)

8 KB 1000 0 51 20 222 151 38 1115

29
 16 KB 1000 0 33 20 301 206 43 1340

32 KB 1000 0 20 28 312 244 59 1960

Source: Own work.

Figures 6 and 7 show the average processing latency of the smart contacts with
different block sizes.

350
Avg Latency (ms)

300
250
200
150
100
50
0
0 100 200 300 400 500 600 700 800 900 1000
Sessions

8 KB 16 KB 32 KB

Figure 6. Processing latency for smart contract A.

300
Avg Latency (ms)

250
200
150
100
50
0
0 100 200 300 400 500 600 700 800 900 1000
Sessions

8 KB 16 KB 32 KB

Figure 7. Processing latency for smart contract B.

The results of the study indicate that the TPS value decreases as the block size
increases.

The resource consumption of nodes increases with the block size. It should be noted that the
processing performance for smart contract B is higher than for smart contract A. This might
stem from the fact that smart contract A is more write-oriented than smart contract B. Reading
data is typically less complex at the smart contract level than writing data at the I/O level,

30
leading to faster transaction processing. The analysis of the latency metric indicates that the
average latency increases with the increase in block size and number of sessions, which
negatively affects the TPS factor. The average session latency for the smart contract A is
between 200 and 300 ms and for the smart contract B it is around 150-250 ms, depending on
the block size and number of sessions. The performance of the tested network depends on the
block size and the type of smart contracts. With many simultaneous sessions and complex
transactions, memory and CPU usage are critical, which can negatively impact network
performance.

7. Blockchain cybersecurity analysis for Smart Healthcare Systems

The application of blockchain technology in SHSs requires cybersecurity assessment

in terms of threat and vulnerability analysis. Analyzes of various attack vectors on blockchain
networks are available in the literature. Critical threats to blockchain networks specifically
include the Race attack, 51% attack, Eclipse attack, Sybil attack, Finney attack, DoS attack,
Routing attack, and Replay attack (see e.g., [1], [26]). Table 8 presents attack scenarios on
blockchain networks for the above-mentioned threats.

Table 8. Attack vectors on the blockchain network

Cyberattack Attack scenario

Race attack The attack involves replacing the first transaction with another one before the
original transaction is written to the blockchain.

51% attack The attacker possesses over 50% of the computational power of the network’s
security nodes. Therefore, it is possible to take control of the blockchain network by
manipulating transactions.

Eclipse attack The attack isolates the user or node and redirects the victim’s connections to nodes
controlled by the attacker. The attack may be preceded by flooding the victim with
the attacker’s IP addresses and a DoS attack to force a node restart. As a result, the
attacker can manipulate the node and generate unauthorized transaction
confirmations.

Sybil attack The attack involves creating and maintaining multiple nodes in the blockchain
network. In the case of PoS algorithms, the attacker can vote for trusted nodes,
sabotage the network, and reject block verification.

Finney attack The attack occurs when a user accepts an unconfirmed transaction. In a typical
scenario, the attacker has two addresses. The attacker can send a transaction between
these addresses and then lock the transaction. In the next step, the attacker sends a
transaction to another user’s addresses. If the user accepts the unconfirmed
transaction, the attacker releases the initial transaction lock.

DoS and The attack blocks network services and can be carried out using various attack

31
DDoS attacks vectors, including buffer overflow attack, SYN flood attack and ICMP flood attack.

Routing attack The attack exploits vulnerabilities in the Internet infrastructure to manipulate routing
tables. The attack is carried out at the level of the Internet Service Provider. Based
on the BGP protocol, blockchain networks are partitioned to create disconnected
subnets. As a result, the propagation of new blocks may be delayed.

Replay attack The attack involves the interception and retransmission of data. The attack is feasible
if a hard fork splits the network. If a transaction validated in the initial blockchain is
also valid in the new blockchain, it can be transferred from the first blockchain to the
second.

Source: Based on [1], [2], [26], [31].

Blockchain networks are exposed to a number of threats and vulnerabilities. Some

threats are specific to blockchains implementing cryptocurrencies. Other threats depend on
the number of nodes and network computing power. The next stage of the research is the
assessment and analysis of the threats identified in Table 8 in order to determine the risk
minimization strategy.

The research used the steps recommended by ENISA for identification, analysis and
evaluation [6], [7] and elements of the methodology developed by NIST [21]. The impact of
the threat on the SHS was rated on a scale of 1 to 5. The likelihood of a given threat occurring
in the identified system vulnerability was also estimated on a scale of 1 to 5.

The adopted assumptions were used to determine the risk score in accordance with the
following formula:

𝑅=𝐼∗𝐿 (2)

key:

R – risk score,

𝐼 ∈ {1,2,3,4,5} – coefficient of the estimated impact of the identified threat on the Smart
Healthcare System,

𝐿 ∈ {1,2,3,4,5} – coefficient of the estimated likelihood of the threat occurrence in the

identified system vulnerability.

The adopted impact and likelihood levels made it possible to develop the risk matrix
presented in Table 8.

Table 9. Risk matrix

Impact levels
Likelihood levels
Very low Low Medium High Very high (5)

32
 (1) (2) (3) (4)

Very high (5) 5 10 15 20 25

High (4) 4 8 12 16 20

Medium (3) 3 6 9 12 15

Low (2) 2 4 6 8 10

Very low (1) 1 2 3 4 5

Source: Own work.

Based on the risk matrix and the obtained values of the risk ratio, the following risk
levels were determined:

 low risk: 𝑅 ∈ < 1, 5 > ,

 medium risk: 𝑅 ∈ < 6, 15 > ,
 high risk: 𝑅 ∈ < 16, 25 > .

Risk analysis and evaluation was conducted based on determined levels. The research
results are presented in Table 10. The table also includes risk minimization strategies.

Table 10. Risk analysis and evaluation with risk minimization strategies

Risk
Score
Impact Likelihood
Cyberattack Risk minimization strategies
(I) (L)
(R = I x
L)

Race attack 3 3 9 Implementation of mechanisms for accepting

only confirmed transactions.
(medium)

51% attack 5 3 15 The level of protection is determined by the

number of nodes securing the network.
(medium)

Eclipse attack 4 4 16 Firewalls should be configured to block

inbound and outbound connections for
(high) untrusted nodes.

33
Sybil attack 5 4 20 Firewall configuration policies should include
blocking inbound and outbound connections for
(high) untrusted nodes.

Finney attack 3 3 9 Implementation of mechanisms for accepting

only confirmed transactions.
(medium)

DoS and 5 4 20 The level of protection is determined by the

DDoS attacks number of nodes securing the network. DoS and
(high) DDoS attack early detection statistics
monitoring strategies.

Routing attack 3 2 6 Intensifying the diversity of IP connections for

network nodes. Implementing a monitoring
(medium) strategy for routing statistics, Round-trip time
(RTT) metrics, and network connection
statistics to recognize early attack signals.

Relay attack 2 2 4 Strong replay protection method. Opt-in replay

protection method.
(low)

Source: Own work.

Table 9 shows that the critical threats to the blockchain in SHSs are the Eclipse attack,
Sybil attack, and both DoS and DDoS attacks. The key protection strategies against identified
threats include ensuring the security of network nodes, defining the rules for creating new
blocks and proactively monitoring network traffic statistics for early detection of attacks. As
demonstrated in the article, blockchain technology improves the security of medical data and
healthcare stakeholders as well as supports the interoperability of SHSs. However, the
implementation of new software architecture concepts in healthcare brings new risks and
vulnerabilities that must be addressed early. Based on the results of the risk analysis, the main
guidelines for risk migration plans for blockchain technology in healthcare were formulated:

1. Risk analysis: the system design phase should be preceded by a complete and detailed
risk assessment. Threats and vulnerabilities must be identified, taking into account the
confidentiality, availability and integrity of medical data.
2. Authorization: blockchain technology provides a high level of security thanks to a
distributed architecture based on cryptographic proofs. However, it may be subject to
problems with identifying and authenticating users and network components,
especially on public networks. It is crucial to develop secure authorization
mechanisms for stakeholders and network components.
3. Technology stack: the software architecture stack should be determined by the
functional and non-functional requirements resulting from the logic of medical

34
 processes. Security, interoperability, performance, scalability and compliance are key
considerations.
4. Standardization: undertaking global standardization initiatives to implement
blockchain technology in healthcare minimizes risk, promotes good practice, and
increases compatibility and interoperability.
5. Education: promoting educational activities and training in the safe use of blockchain
technology by medical staff and patients.
6. System testing: stringent requirements for the reliability of IT systems in medicine
require an advanced software testing strategy before the system goes into the
production environment.
7. Continuous improvement: regular system security audits will help identify and
minimize risks and eliminate vulnerabilities that may occur during system operation.

A holistic risk migration plan should include a set of interrelated steps to ensure safe
system use by all healthcare stakeholders.

8. Discussion

The discussion in this section provides a critical analysis of the research results. The
results presented in this article cover a multi-stage research process. The first step was to
develop an IoMT architecture for SHSs. The model was developed based on the concepts of
layered IoT architecture available in the literature. The layered approach ensured compliance
with general IoT concepts and extended the model with functionalities related to medical
processes. In particular, the model considers cybersecurity as a systemic element.

In the next research step, the technical architecture framework of the blockchain
network for SHSs was developed. The presented concept contains many synergistic elements
and aims to support the recommendations in international strategies for developing digital
healthcare. The recommendations concern, inter alia, unifying the structure of medical data,
improving interoperability and ensuring cybersecurity of medical processes. To meet the
above postulates, this paper presents an open data exchange format for EHRs embedded in the
blockchain. The universal nested tree notation according to the DOM interface was used in
the research.

The research results support the concept presented by Thuy et al. [40] for the semantic
transformation of XML medical data into the OWL ontology. Embedding EHRs in the
blockchain and basing their structure on a nested tree enables the use of universal
transformation methods based on the XML format. Moreover, the reference to the alternative
JSON format supported interoperability from the programming side. In particular, it is
possible to implement modern RESTful JSON APIs for remote procedure call services. The
open-source gRPC platform enables the implementation of a remote procedure call protocol
using the http/2, Protobuf, and streaming protocols to create high-performance real-time
services [20]. The gRPC platform supports, among others, Go, C++, Java, Python, C#.
Additionally, there are development platforms available for creating full technology stacks for
a web-based JSON API using gRPC services. For instance, gRPC JSON transcoding is an
extension of ASP.NET Core for crafting modern RESTful JSON APIs for gRPC services
[20]. Therefore, using the indicated programming tools, it is possible to create modern APIs
supporting interoperability based on the architecture framework of the SHS presented in this
paper. It should be noted that this is particularly important in software backend programming.

35
 The next important research step was to define algorithms for concluding, approving
and validating transactions between stakeholders of medical processes based on smart
contract cryptographic evidence. In this paper, contracts between stakeholders of medical
processes are transformed into executable programs. Smart contracts can describe any
business process and define resource management rules. The study used the access control
matrix method to define access rights for entities and objects. The obtained results correspond
to the research of Sookhak et al. [34], which evaluated smart contracts in terms of access
control in healthcare. It should be noted that in systems based on blockchain technology and
smart contracts, there may be some difficulties in revoking user privileges [34]. To counteract
this, the ABE, IBE methods and the lazy revocation cryptosystem are used [34].

The next research step involved empirical tests to assess the stability and performance
of the proposed architecture. For the purposes of empirical tests, the software was
implemented in a selected architectural stack. Test objectives, test scenarios, and metrics were
defined in the study. The empirical tests evaluated two smart contracts concluded between the
patient, the doctor and the pharmacy regarding the issuance and fulfillment of a prescription.

In the latest literature, there are also innovative concepts and prototypes of the use of
blockchain technology in the medical industry. For the purposes of the discussion,
publications on the practical applications of blockchain technology in healthcare and medical
data security were selected.

Sharma et al. [33] published research findings on the use of blockchain technology to
issue unique identifiers for medical certificates. The study showed the effective use of smart
contracts for user registration, generation of medical certificates and their verification.
Although the authors used a different Ethereum-based platform, the conclusions of the
research are similar. Blockchain technology provides more secure processing of EHRs than
currently used centralized systems. The research results presented by Sharma et al. [33] may
be complementary to the research findings of this paper in implementing various smart
contract scenarios for EHRs in a nested tree structure.

The key study was also published by Sammeta and Parthiban [28], who developed a
machine learning-based model for diagnosing diseases. The machine learning algorithm
extracted data from the Hyperledger Fabric-based blockchain. The results of the study
indicate the high efficiency of the algorithm in the diagnosis of diseases [28]. The results of
the discussed article may synergistically complement this paper in terms of data formats and
smart contract algorithms, as well as software implementation in the presented architectural
stack. Machine learning algorithms and blockchain technology can be extended with the EHR
format based on the nested tree structure, which offers an additional layer of semantics for
artificial intelligence techniques.

In another study, Vazirani et al. [42] emphasized that the IT systems currently used in
the medical industry have significant interoperability gaps, which leads to dangerous
situations in healthcare. The research results of the discussed article indicate that blockchain
supports the interoperability of medical records management [42]. To improve
interoperability, our solution recommends the use of global identifiers for patients, doctors
and medical facilities. It is also worth noting the research findings published by Qu et al. [24],
in which the authors emphasize that quantum computers can threaten the security of
blockchain technology. The identified issues require urgent research.

9. Conclusions

36
 The development of SHSs is an open and interdisciplinary research challenge. The
presented blockchain implementation architecture for SHSs addresses the open challenges
defined in international digital healthcare development strategies. The defined IoMT
architecture model takes into account the requirements for cybersecurity, interoperability and
supports the processing of medical data. Full interoperability of SHSs cannot be achieved
without open formats for medical data exchange. The article presents the structure of an open
data exchange format for EHRs based on the nested tree model. The proposed structure is
hardware and software independent. Medical data processing is conducted using algorithms
secured by the cryptographic proof of the blockchain. For this purpose, algorithms for
concluding, approving and validating transactions are presented. The conducted empirical
tests showed high stability and performance of the proposed architecture in various test
scenarios. The risk analysis identified possible threats and vulnerabilities of using blockchain
in SHSs.

The proposed architecture can be applied in practice to secure the processing of

medical data through cryptographic proof of smart contracts. In our solution, the security of
stakeholders in medical processes is ensured by the non-repudiation, enforceability, and
accountability of smart contracts. Moreover, from a programming perspective, the presented
format of EHRs facilitates the implementation of APIs and the transformation of medical data
into other programming constructs.

Future research directions pertain to new encryption concepts based on personal

attributes. An important avenue of research is the application of results obtained by Liu et al.
[15] for dynamic access control to EHRs.

10. References

[1] Aggarwal S, Kumar N. (2021). Chapter Twenty - Attacks on blockchain, in: S. Aggarwal,
N. Kumar, P. Raj (Eds.), Advances in Computers, pp. 399-410.
https://doi.org/10.1016/bs.adcom.2020.08.020

[2] Apostolaki M, Zohar A, Vanbever L. (2017). Hijacking Bitcoin: Routing Attacks on

Cryptocurrencies. IEEE Symposium on Security and Privacy (SP), pp. 375-392.
https://doi.org/10.1109/SP.2017.29

[3] Deepa N, Pham Q-V, Nguyen DC, Bhattacharya S, Prabadevi B, Gadekallu TR,
Maddikunta PKR, Fang F, Pathirana PN. (2022). A survey on blockchain for big data:
Approaches, opportunities, and future directions. Future Generation Computer Systems, 131,
pp. 209-226. https://doi.org/10.1016/j.future.2022.01.017

[4] Ding, W., Abdel-Basset, M., Hawash, H., & Pedrycz, W. (2023). MIC-Net: A deep
network for cross-site segmentation of COVID-19 infection in the fog-assisted
IoMT. Information Sciences, 623, 20–39. https://doi.org/10.1016/j.ins.2022.12.017

[5] Feng, X., Wu, J., Wu, Y., Li, J., & Yang, W. (2023). Blockchain and digital twin
empowered trustworthy self-healing for edge-AI enabled industrial Internet of
things. Information Sciences, 642(119169), 119169. https://doi.org/10.1016/j.ins.2023.119169

[6] ENISA. (2022). Interoperable EU Risk Management Framework.

https://www.enisa.europa.eu/publications/interoperable-eu-risk-management-framework,
(accessed 26 June 2022).

37
[7] ENISA. (2022). Compendium of Risk Management Frameworks with Potential
Interoperability. https://www.enisa.europa.eu/publications/compendium-of-risk-management-
frameworks (accessed 26 June 2022).

[8] European Commission. (2018). Communication on enabling the digital transformation of

health and care in the Digital Single Market; empowering citizens and building a healthier
society. https://digital-strategy.ec.europa.eu/en/library/communication-enabling-digital-
transformation-health-and-care-digital-single-market-empowering (accessed 04 June 2022).

[9] European Commission. (2022). eHealth. https://digital-

strategy.ec.europa.eu/en/policies/ehealth (accessed 04 June 2022).

[10] Huang C, Xu G, Chen S, Zhou W, Ng E.Y.K., Albuquerque V.H.C. de. (2022). An

improved federated learning approach enhanced internet of health things framework for
private decentralized distributed data. Information Sciences, 614, pp. 138–152.
https://doi.org/10.1016/j.ins.2022.10.011

[11] IEEE. (2018). Standard for a Reference Architecture for Smart City (RASC).
https://standards.ieee.org/ieee/2413.1/7331/ (accessed 10 June 2022).

[12] Javaheri D, Gorgin S, Lee J-A, Masdari M. (2023). Fuzzy logic-based DDoS attacks and
network traffic anomaly detection methods: Classification, overview, and future
perspectives. Information Sciences, 626, 315–338. https://doi.org/10.1016/j.ins.2023.01.067

[13] Khan M, Mehran MT, Haq ZU, Ullah Z, Naqvi SR, Ihsan M, Abbass H. (2021).
Applications of artificial intelligence in COVID-19 pandemic: A comprehensive review.
Expert Systems with Applications, 185, 115695. https://doi.org/10.1016/j.eswa.2021.115695

[14] Kumar NM, Mallick PK. (2018). The Internet of Things: Insights into the building
blocks, component interactions, and architecture layers. Procedia Computer Science, 132, pp.
109-117. https://doi.org/10.1016/j.procs.2018.05.170

[15] Liu X, Liu Q, Peng T, Wu J. (2017). Dynamic access policy in cloud-based personal
health record (PHR) systems. Information Sciences, 379, 62–81.
https://doi.org/10.1016/j.ins.2016.06.035

[16] Lu, X. (2023). Implementation of art therapy assisted by the internet of medical things
based on blockchain and fuzzy set theory. Information Sciences, 632, 776–790.
https://doi.org/10.1016/j.ins.2023.03.044

[17] Lu, Y., Wang, C., Yue, M., & Wu, Z. (2023). Consumer-source authentication with
conditional anonymity in information-centric networking. Information Sciences, 624, 378–
394. https://doi.org/10.1016/j.ins.2022.12.051

[18] Nakamoto S. Bitcoin: A Peer-to-Peer Electronic Cash System.

https://www.debr.io/article/21260.pdf, 2008 (accessed 20 June 2022).

[19] Naseer Qureshi K, Din S, Jeon G, Piccialli F. (2020). An accurate and dynamic
predictive model for a smart M-Health system using machine learning. Information Sciences,
538, pp. 486–502. https://doi.org/110.1016/j.ins.2020.06.025.

38
[20] Newton-King J, Microsoft, gRPC JSON transcoding. https://docs.microsoft.com/pl-
pl/aspnet/core/grpc/httpapi, 2022 (accessed 19 June 2022).

[21] NIST, Guide for Conducting Risk Assessments, SP 800-30 Rev. 1.

https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final, 2012 (accessed 26 June 2022).

[22] Pedrycz, W. (2023). Autonomous and sustainable machine learning: pursuing new
horizons of intelligent systems. AI and Autonomous Systems, 2023(1): 0002.
https://doi.org/10.55092/aias20230002

[23] Qi, P., Chiaro, D., Giampaolo, F., & Piccialli, F. (2023). A blockchain-based secure
Internet of medical things framework for stress detection. Information Sciences, 628, 377–
390. https://doi.org/10.1016/j.ins.2023.01.123

[24] Qu, Z., Zhang, Z., & Zheng, M. (2022). A quantum blockchain-enabled framework for
secure private electronic medical records in Internet of Medical Things. Information
Sciences, 612, 942–958. https://doi.org/10.1016/j.ins.2022.09.028

[25] Quamara, S., & Singh, A. K. (2022). A systematic survey on security concerns in
cryptocurrencies: State-of-the-art and perspectives. Computers & Security, 113(102548),
102548. https://doi.org/10.1016/j.cose.2021.102548

[26] Ramos S, Pianese F, Leach T, Oliveras W. (2021). A great disturbance in the crypto:
Understanding cryptocurrency returns under attacks. Blockchain: Research and Applications.
2,3, 100021. https://doi.org/10.1016/j.bcra.2021.100021

[27] Roehrs, A., da Costa, C. A., da Rosa Righi, R., da Silva, V. F., Goldim, J. R., & Schmidt,
D. C. (2019). Analyzing the performance of a blockchain-based personal health record
implementation. Journal of Biomedical Informatics, 92(103140), 103140.
https://doi.org/10.1016/j.jbi.2019.103140

[28] Sammeta, N., & Parthiban, L. (2022). Hyperledger blockchain enabled secure medical
record management with deep learning-based diagnosis model. Complex & Intelligent
Systems, 8(1), 625–640. https://doi.org/10.1007/s40747-021-00549-w

[29] Sanda, O., Pavlidis, M., Seraj, S., & Polatidis, N. (2023). Long-Range attack detection on
permissionless blockchains using Deep Learning. Expert Systems with
Applications, 218(119606), 119606. https://doi.org/10.1016/j.eswa.2023.119606

[30] Saripalle R, Runyan C, Russell M. (2019). Using HL7 FHIR to achieve interoperability
in patient health record. Journal of Biomedical Informatics, 94, 103188.
https://doi.org/10.1016/j.jbi.2019.103188

[31] Saxena S, Bhushan B, Ahad MA. (2021). Blockchain based solutions to secure IoT:
Background, integration trends and a way forward. Journal of Network and Computer
Applications, 181, 103050. https://doi.org/10.1016/j.jnca.2021.103050

[32] Sethi P, Sarangi SR. (2017). Internet of Things: Architectures, Protocols, and
Applications. Journal of Electrical and Computer Engineering, 9324035.
https://doi.org/10.1155/2017/9324035

39
[33] Sharma, P., Namasudra, S., Gonzalez Crespo, R., Parra-Fuente, J., & Chandra Trivedi,
M. (2023). EHDHE: Enhancing security of healthcare documents in IoT-enabled digital
healthcare ecosystems using blockchain. Information Sciences, 629, 703–718.
https://doi.org/10.1016/j.ins.2023.01.148

[34] Sookhak M, Jabbarpour MR, Safa NS, Yu FR. (2021). Blockchain and smart contract for
access control in healthcare: A survey, issues and challenges, and open issues. Journal of
Network and Computer Applications, 178, 102950.
https://doi.org/10.1016/j.jnca.2020.102950

[35] Stallings W & Brown L (2018). Computer Security: Principles and Practice, 4th Edition,
Pearson

[36] Su Y, Li Y, Zhang K, Yang B. (2021). A privacy-preserving public integrity check

scheme for outsourced EHRs. Information Sciences, 542, pp. 112–130.
https://doi.org/10.1016/j.ins.2020.06.043

[37] Swarna Priya RM, Maddikunta PKR, Parimala M, Koppu S, Gadekallu TR, Chowdhary
CL, Alazab M. (2020). An effective feature engineering for DNN using hybrid PCA-GWO
for intrusion detection in IoMT architecture. Computer Communications, 160, pp. 139-149.
https://doi.org/10.1016/j.comcom.2020.05.048

[38] Szabo N. (1996). Smart Contracts: Building Blocks for Digital Markets.
https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinte
rschool2006/szabo.best.vwh.net/smart_contracts_2.html (accessed 10 June 2022).

[39] Szczepaniuk H, Szczepaniuk EK. (2021). Cybersecurity Management within the Internet
of Things, in: S.K. Sharma, B. Bhushan, N.C. Debnath, (Eds.), IoT Security Paradigms and
Applications: Research and Practices. Taylor & Francis CRC Press, pp. 24-41.
https://doi.org/10.1201/9781003054115

[40] Thuy PTT, Lee Y-K, Lee S. (2021). S-Trans: Semantic transformation of XML
healthcare data into OWL ontology. Knowledge-Based Systems, 35, pp. 349-356.
https://doi.org/10.1016/j.knosys.2012.04.009

[41] Tomar D, Bhati JP, Tomar P, Kaur G. (2019). Chapter 2 - Migration of healthcare
relational database to NoSQL cloud database for healthcare analytics and management, in: N.
Dey, A.S. Ashour, C. Bhatt, S.J. Fong (Eds.), Advances in ubiquitous sensing applications for
healthcare, Healthcare Data Analytics and Management, Elsevier Academic Press, pp. 59-87.
https://doi.org/10.1016/B978-0-12-815368-0.00002-6

[42] Vazirani, A. A., O’Donoghue, O., Brindley, D., & Meinert, E. (2020). Blockchain
vehicles for efficient Medical Record management. Npj Digital Medicine, 3(1), 1.
https://doi.org/10.1038/s41746-019-0211-0

[43] Voundi Koe, A. S., Ai, S., Chen, Q., Tang, J., Chen, K., Zhang, S., & Li, X. (2023).
Hieraledger: Towards malicious gateways in appendable-block blockchain constructions for
IoT. Information Sciences, 632, 87–104. https://doi.org/10.1016/j.ins.2023.02.077

[44] Wang, J., Jin, H., Chen, J., Tan, J., & Zhong, K. (2022). Anomaly detection in Internet of
medical Things with Blockchain from the perspective of deep neural network. Information
Sciences, 617, 133–149. https://doi.org/10.1016/j.ins.2022.10.060

40
[45] Wen, B., Wang, Y., Ding, Y., Zheng, H., Qin, B., & Yang, C. (2023). Security and
privacy protection technologies in securing blockchain applications. Information
Sciences, 645(119322), 119322. https://doi.org/10.1016/j.ins.2023.119322

[46] Woody SK, Burdick D, Lapp H, Huang ES. (2020). Application programming interfaces
for knowledge transfer and generation in the life sciences and healthcare. npj Digital
Medicine, 3,24. https://doi.org/10.1038/s41746-020-0235-5

[47] World Economic Forum. (2016). White Paper Digital Transformation of Industries:
Healthcare Industry. In collaboration with Accenture. https://report.weforum.org/digital-
transformation/wp-content/blogs.dir/94/mp/files/pages/files/dti-healthcare-industry-white-
paper.pdf (accessed 19 August 2023)

[48] Yan, F., Huang, H., Pedrycz, W., & Hirota, K. (2023). Automated breast cancer detection
in mammography using ensemble classifier and feature weighting algorithms. Expert Systems
with Applications, 227(120282), 120282. https://doi.org/10.1016/j.eswa.2023.120282

[49] Zhao Z, Li X, Luan B, Jiang W, Gao W, Neelakandan S. (2023). Secure Internet of

Things (IoT) using a novel Brooks Iyengar quantum Byzantine Agreement-centered
blockchain Networking (BIQBA-BCN) model in smart healthcare. Information Sciences, 629,
pp. 440–455. https://doi.org/10.1016/j.ins.2023.01.020

[50] Zhou L, Fu A, Mu Y, Wang H, Yu S, Sun Y. (2021). Multicopy provable data possession

scheme supporting data dynamics for cloud-based Electronic Medical Record
system. Information Sciences, 545, pp. 254–276. https://doi.org/10.1016/j.ins.2020.08.031

41
42
43
44
45
CRediT authorship contribution statement

Hubert Szczepaniuk: Conceptualization, Methodology, Software, Formal analysis,

Investigation, Writing - Original Draft, Writing - Review & Editing, Visualization. Edyta
Karolina Szczepaniuk: Conceptualization, Methodology, Software, Formal analysis,
Investigation, Writing - Original Draft, Writing - Review & Editing, Visualization.

46