Received August 13, 2021, accepted August 31, 2021, date of publication September 1, 2021, date of current version

September 10, 2021.

Digital Object Identifier 10.1109/ACCESS.2021.3109822

FogChain: A Fog Computing Architecture

Integrating Blockchain and Internet of Things
for Personal Health Records
ANDRÉ HENRIQUE MAYER, VINICIUS FACCO RODRIGUES ,
CRISTIANO ANDRÉ DA COSTA , (Senior Member, IEEE),
RODRIGO DA ROSA RIGHI , (Senior Member, IEEE), ALEX ROEHRS ,
AND RODOLFO STOFFEL ANTUNES , (Member, IEEE)
Software Innovation Laboratory (SOFTWARELAB), Applied Computing Graduate Program, Universidade do Vale do Rio dos Sinos (UNISINOS), São Leopoldo
93022-750, Brazil
Corresponding author: Cristiano André da Costa (cac@unisinos.br)
This work was supported in part by the Foundation for Higher Education Personnel Improvement (CAPES), Finance Code 001, and in part
by the National Council for Scientific and Technological Development (CNPq) under Grant 309537/2020-7.

ABSTRACT The Internet of Things (IoT) adoption grows significantly and is successful in many different
domains. Nevertheless, the ever-growing demand for more connected devices pushes the requirement for
scalable IoT architectures capable of maintaining the security and privacy of collected data. The latter is a
particularly critical aspect when considering sensitive data, e.g., medical records. One solution to address
this challenge is to modify the centralized back-end model to one based on a Blockchain, changing the way
IoT data is stored and shared by providing a decentralized peer-to-peer network. This technology enables
naming and tracking for connected devices, and in the case of this article, features a high availability of
Personal Health Records, yet protecting patients’ privacy through the use of cryptography. Furthermore,
the addition of Fog computing mechanisms helps to achieve real-time data processing, supports precision
medicine, and avoids single points of failure. As a result, devices have a local and more resilient ecosystem
for operation. In this context, this work proposes an architecture model named FogChain, which combines
the technologies Blockchain, Fog computing, and the IoT for the healthcare domain. Our main contribution
is the FogChain model itself, and its concept of overcoming IoT constraints by employing a differential
approach, adding an intermediary Fog layer near to the edge to improve their capabilities and resources.
Experiments demonstrate that FogChain can achieve a 62.6% faster response time when compared to
Cloud-like Blockchain infrastructures. The results obtained from the evaluation endorses the capacity of
our model in achieving its goals while retaining application performance.

INDEX TERMS Personal health record, Blockchain, fog computing, Internet of Things, distributed systems,
health informatics.

I. INTRODUCTION as privacy-sensitive information without any human interven-

Internet of Things (IoT) refers to the network of physical tion [5]. When applied to the healthcare context, such devices
objects embedded with software and sensor devices capable comprise the Internet of Health Things (IoHT) [12], which
of communicating over the Internet for information exchang- consists of a network of interconnected objects exchanging
ing [1]. Such devices collect, process, and exchange vast and processing medical data focused on improving medical
amounts of data from the surrounding environment as well processes. Such environments impose additional restrictions
on technologies that handle such data due to its sensitivity and
The associate editor coordinating the review of this manuscript and confidentiality issues. As a result, the sensitive nature of such
approving it for publication was Vyasa Sai. networks makes them appealing targets for cyberattacks [15].

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 9, 2021 122723
 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

The privacy of collected data may be at risk when stored functionalities and data collection, supporting extra security
and managed by outsourced companies on centralized servers and privacy turns to be quite challenging [15].
(e.g., cloud hosting). In such cases, the main concerns regard Currently, to the best of our knowledge, there are no studies
data leaks caused by cyberattacks the cloud providers might that focus on integrating Fog and Blockchain technologies
suffer [10]. to the IoHT domain. In this context, this article proposes
In the last few years, the rise of Blockchain technologies FogChain, a model for integrating Fog and Blockchain for
offer secure solutions providing trust, accountability, trace- PHR management. FogChain allows close to real-time data
ability, and integrity of data sharing, to secure distributed processing given that the patient’s health records are to be
data across organizations [18], [24], [40]. That enables solu- locally available in a Fog computing layer, thus improv-
tions to try Blockchain capabilities in the context of health- ing physicians response time and decision making [42].
care to overcome privacy and security problems. Currently, We developed a prototype of the model using JavaScript and
Blockchain is the most popular form of distributed ledger employed Hyperledger Fabric distribution in the Blockchain
technology (DLT). Its features enable IoT applications that level of the model. Experiments demonstrated improvements
require a trusted third party to be decentralized [23]. Thus, up to 40.3% in response time when comparing FogChain with
the need for a central authority is removed without com- a Cloud solution. In summary, the main goals of the current
promising the functionalities and guarantees of applica- research are as follows:
tions [9], [40]. The use of cryptography, a key characteristic of • Build a model for integrating Blockchain and Fog Com-
Blockchain networks, brings authoritativeness behind all the puting to manage PHR in the IoHT field;
interactions in the network [9], where Blockchain has a fun- • Improve response time on registering PHR information
damental role in registering and authenticating all operations in the Blockchain and, consequently, make health data
performed on IoT devices data [10]. This technology could available quickly.
reinvent the way patient’s electronic and personal health
records (EHR and PHR) are shared and stored by providing We have organized the article as follows. Section II
safer mechanisms for health information exchange (HIE), introduces background concepts related to this research.
by securing it over a decentralized peer-to-peer network, Section III presents related research carried for other authors
thus making the health records more available, efficient and in the same domain this research focuses on. Following,
secure [31], [37]. Section IV describes the FogChain model, including design
Regardless of the security challenges, IoHT environments decisions and its architecture. Then, Sections V and VI
require extra performance when it comes to time response. present the evaluation methodology and results, respectively.
Having quick access to processed information from patients Finally, Section VII concludes the article with final remarks
allow fast decision-making by the medical team. That is and future directions.
crucial to improve medical services and deliver a high quality
of service for patients. Frequently, current IoT and health- II. BACKGROUND
care solutions rely on Cloud computing resources to pro- This section gives a brief overview of the main technologies
vide processing of data from sensors [3]. However, such employed in this study: Blockchain, IoHT, and Fog Comput-
solutions impose data to be transferred to cloud servers, ing. The concept of IoT may have different interpretations
which can be physically distant and increase network latency. depending on the context where it is applied. For instance,
That impacts the agility of the system to process and the things-centric (e.g., from the sensor’s point of view) could
produce feedback from data to the medical team. More- potentially be patient-centric by consisting of interconnected
over, a recent study predicts that centralized clouds, fre- objects with the capacity of exchanging and processing data
quently used in current IoT systems, will be unlikely to to improve patient’s health [12]. In this sense, IoHT consists
deliver satisfactory services to customers [46]. From the of interconnected objects with the capacity of exchanging and
core to the edge of the network, adoption of Fog comput- processing data to improve patient health [12]. It relies on
ing alternatives is encouraged and represents a layered ser- the use of wearable sensors and other medical devices that
vice structure that is an extension of the cloud computing communicate via RFID, NFC, or Bluetooth with computing
paradigm [46]. nodes to extract information from the medical environment.
Fog computing can provide faster cloud-like services such They collect and transmit data to remote servers for further
as storage, computing, and networking capabilities closer to processing to generate feedback aiming at improving medical
users and devices, by extending the data management field of processes. The main goal in such environments is to moni-
the cloud and increases the accessibility of IoT resources [49]. tor sensor data providing information regarding the patients,
These abilities are a consequence of allocating Fog nodes medical staff, equipment, and even the environment.
closer to the IoT devices, at the edge of the network, thus In turn, Blockchain is gaining attention in the last few years
reducing communication’s latency and promoting closer to in many different fields. It consists of a Peer-to-Peer (P2P)
real-time communication with the Things layer [6], [36], [46]. DLT for transactions that do not require a central author-
Given that IoT devices spend most of their available energy ity, eliminating the need for third-party verification [10].
and computational resources to execute core application A Blockchain contains sets of chained blocks of transactions

122724 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

and every block contains a hash of the previous block. In sum- Library,5 and (vi) Science Direct.6 We chose these databases
mary, a Blockchain is a distributed ledger protocol originally to cover a broad set of scientific literature published in differ-
associated with Bitcoin [16]. It uses public-key cryptography ent areas. In each database, we built the search query filtering
to create an append-only, immutable, and time-stamped chain articles from the last ten years to reach the most recent studies
of content [37]. It was originally designed for keeping a finan- in the area. Following, Section III-A details each selected
cial ledger, but the Blockchain paradigm can be extended to article from our methodology, while Section III-B presents
provide a generalized framework for implementing decen- some discussion and open issues that drive our research.
tralized compute resources even into the Healthcare ecosys-
tem [16]. Blockchain technologies are a promising means to A. STATE-OF-THE-ART
address the barriers with distributed health records by form- In [4], the authors present a multi-tier framework for inte-
ing a unified view of the patient’s personal health records. The grating IoT in EHR systems using Blockchain and Cloud
process of collecting vital signs in hospital wards varies, and technologies. The proposed system uses Elliptic Curve
different approaches are used worldwide. In some cases, data Cryptography (ECC), which may introduce more security
is only manually collected and stored in spreadsheets that are strength compared to other cryptography approaches. How-
discarded after the patient is discharged [12], and is precisely ever, the solution does not provide health records locally.
at this point where Blockchain technology may contribute and Instead, they are accessible through a Blockchain Cloud
become a viable solution for health records management. provider, which is not covered in the article. In [19],
Finally, Fog Computing may be viewed as a layered ser- the authors propose the Secured and Smart Healthcare Sys-
vice structure that is an extension of the Cloud Computing tem (S2HS) to provide security and privacy in healthcare sys-
paradigm. It is composed of low-energy computing nodes tems. The study employs a Wireless Sensor Network (WSN)
with limited hardware specifications. They can provide faster architecture to collect EHR data from IoT wearable devices.
Cloud services such as storage, computing, and networking Blockchain is employed to encrypt and standardize the data
capabilities to end-users, with Fog nodes located near the before storing it on the Cloud.
devices at the edge of the network [46]. The Fog Computing Moreover, [38] introduces a framework for sharing econ-
infrastructure may support distributed applications with the omy services in smart cities combining IoT, Blockchain, and
addition of a new intermediary layer between the devices Edge technologies. The authors propose AI solutions at the
and back-end services, potentially facilitating their integra- Edge of the network to process data from IoT devices across
tion [39]. It may help to prevent unavailabilities originated by several domains. The Blockchain composes the security layer
delays and latency gaps over the public Internet, which are of responsible for validating and encrypting transactions. The
the most concerns on healthcare information exchange appli- core of the system relies on decentralized Cloud platforms
cations [48]. In summary, Fog Computing plays an important in which the IoT data is stored. In [47], the authors propose
role in the healthcare domain and has the potential to be a a healthcare data sharing model to reduce data fragmen-
natural technology integrator. Recent studies point out the tation and allow patients better control of their data. The
benefits of adopting it on an organization’s internal infras- model consists of a dual-network architecture for mutable
tructure, and these benefits could be extended to patients in and immutable data. The latter employs Blockchain to pro-
clinics and hospitals. vide security and privacy. The strategy requires healthcare
providers to manually upload the information of data streams
III. RELATED WORK to the Blockchain service.
This section presents literature studies related to our scope Furthermore, [48] presents a Fog architecture to manage
of research. We followed the principles of the systematic medical records using Blockchain and Cloud. The main goal
literature review [25] to reach the most relevant articles in of the solution is to provide patients the ability to control
the scope of Fog Computing, Blockchain, and IoHT. First, access to their medical data. Fog nodes are placed near the
we defined the following set of keywords to compose a search sensors to provide a decentralized Blockchain authorization
query to be applied to several article databases: layer and make data available close to the applications. The
blockchain AND (intertet of things OR iot) article describes a case study that evaluates the performance,
AND (fog computing OR fog) AND (healthcare privacy, and interoperability requirements of the proposed
OR health) AND (health record OR medical architecture in a home-centered healthcare scenario. In [52],
record OR EHR OR PHR OR EMR) the authors develop a framework for integrating IoT sys-
tems, Fog, and Cloud infrastructure. The proposal consists
Using the string above, we queried six different sci- of several Fog nodes close to sensors providing computing
entific databases: (i) IEEEXplore,1 (ii) PubMed Central,2 capabilities and data processing. The Cloud infrastructure
(ii) Google Scholar,3 (iv) Springer Link,4 (v) ACM Digital works as a back-end which is required when Fog nodes are
1 https://ieeexplore.ieee.org overloaded. In addition, Blockchain is employed in the Fog
2 https://www.ncbi.nlm.nih.gov/pmc/
3 https://scholar.google.com/ 5 https://dl.acm.org/
4 https://link.springer.com/ 6 https://www.sciencedirect.com/

VOLUME 9, 2021 122725

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

layer to ensure the integrity of confidential data. The study importance of working on health records interoperability
does not focus specifically on EHR, however, the authors through the definition of open standards. It may be the key
perform a sleep apnea analysis as a case study. to improvements in healthcare services due to health data
In [21], the authors propose a Blockchain-based frame- needs for sharing yet securely, availability, and integration.
work focused specifically on the storage and management Furthermore, the use of Blockchain technology in clinical
of EHRs. The strategy employs multiple smart contracts to trials may enhance the development of drugs and medical
separate different types of information. The main goal is to devices.
provide privacy and control over the records to the patients. Health records and their acronyms are a key term in our
In turn, [2] proposes the EdgeMediChain architecture to research, both electronic and personal health records (EHR
facilitate medical data exchange by combining Blockchain and PHR) are seen as standardized healthcare information
and Edge infrastructure. It consists of an authentication and models, providing several benefits, ranging from supporting
authorization framework for health data sharing coming from medical prescriptions to enabling possible integration among
IoT medical devices. The main contribution is the ability multiple and different healthcare providers (considered as
of the architecture to perform data processing from several its main advantage). However, limitations exist regarding its
sensors in parallel through Edge-mining pools. Each mining interoperability, e.g., when health organizations adopt inter-
pool consists of several Edge nodes that process data from national but heterogeneous standards. Very few studies com-
sensors within a geographical location. Also focusing on data bine specific technologies in the way we are proposing on our
sharing, [27] seek patient information exchange among sev- FogChain model for the healthcare domain. Most healthcare
eral hospitals. The authors propose a framework employing providers are still storing health records on private centralized
Blockchain to store historical data from patients using smart servers, and in different data formats, which is difficult to
contracts. interoperability.
Some of the aforementioned studies do recommend
B. DISCUSSION AND RESEARCH OPPORTUNITIES and or employ Fog computing to improve their architec-
The current state-of-the-art contains several studies that focus tures in terms of resources availability, latency mitiga-
on bringing Blockchain to the industry and healthcare sec- tion, and increased near-edge storage. These studies have
tors. From the studies gathered according to our review helped us to better understand existing challenges and open
methodology, the most common technology that outstands questions about similar architectural models, allowing us
is Blockchain. In the last few years, Blockchain is gaining to prepare and propose our model for personal health
attention due to its capabilities to provide a decentralized records management in the healthcare domain. Looking at
way of protecting data. In general, proposals make use of Table 1, only two articles include Fog infrastructures in their
smart contracts to validate transactions in medical records. strategies [48], [52]. In particular, these strategies employ Fog
Through them, systems aim to give to the patients the power nodes to provide closer computing capabilities to applica-
of controlling who can access their medical data. Besides, tions. However, they also require a Cloud back-end infrastruc-
solutions employ Blockchain to guarantee data integrity and ture to support overload situations due to their Fog layer be
avoid misuse of sensitive data. limited. Given the context, there is a lack of studies focusing
Although having Blockchain in common, studies differ specifically on the integration of Fog and Blockchain for
on the technologies they integrate with their solutions. For IoHT without requiring a Cloud infrastructure. The require-
instance, on the one hand, most of the studies employ Cloud ment of Cloud infrastructures imposes the strategies to inte-
infrastructures to provide medical data remotely [4], [19], grate their environment with third-party providers which may
[38], [48], [52]. That imposes the systems to rely on network not be ideal for patients. That demonstrates a research oppor-
connections that may suffer from high latency problems and, tunity that drives the current study.
consequently, provide poor quality of service for end-users
and applications. On the other hand, few studies employ IV. FOGCHAIN MODEL
Edge infrastructures to their solutions [2], [38]. In such cases, In this section, we describe the proposed model called
the Edge infrastructure provides data processing capabilities FogChain. As the name suggests, FogChain comprehends
closer to the sensors with a focus on load distribution. That the union of Fog computing and Blockchain technologies,
allows the system scalability focusing on a wide deployment which means we aim to have both co-existing, collaborat-
of a smart city or aggregation of several hospitals. ing, and running in the same container at a Fog computing
Blockchain applications in healthcare are still in the level. While default cloud-hosted IoT and IoHT applications
early stages of development and evaluation, existing obsta- struggle with significant latency issues caused by Internet
cles to be overcome, opening paths for more possibilities network congestion and traffic [11], FogChain employs Fog
in the field. For example, some Blockchain studies aim computing as a middleware layer between sensor devices
to address healthcare’s recordkeeping challenges, such as and the Blockchain which could better suit the IoHT needs.
protecting and securing sensitive health information while Figure 1 depicts FogChain’s main innovation compared to
improving patients’ level of control over their data [4], traditional solutions. FogChain introduces Fog nodes that run
[38], [47], [48], [52]. Another important finding is the very Blockchain peers closer to the sensors. The main idea is

122726 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

TABLE 1. Related work comparison.

Considering possible FogChain’s applications for the

healthcare domain, it could be employed in healthcare orga-
nizations’ infrastructures such as hospital departments or
wards, handling its internal demands. Also, it could be pos-
sible to have a FogChain inside patients’ rooms, handling its
sensors and environment information collected from devices.
The concept behind the model is driven by the idea
of employing Fog computing architecture to improve
Blockchain and IoHT integration, aiming to reduce net-
work latency and increase resources available near the edge.
Besides, the decision to propose and build a viable solution
to the health domain, possibly contributing to future research,
implementations, and taking the patient to the center of the
solution.
A. DESIGN DECISIONS
The design of FogChain takes into consideration the follow-
ing statements:
1) The model focuses on building a feasible solution for
the healthcare domain, possibly contributing to future
research and implementations;
2) FogChain employs Fog computing architecture to
improve Blockchain and IoHT integration, aiming at
reduction of network latency and increasing availability
of resources near the edge;
3) Focus on PHR data to increase patient control over its
medical information;
4) The model design adopts open-source projects and
structures on the application’s development.
We focused the conception of this model on designing
FIGURE 1. Comparison of traditional infrastructures (a) and FogChain a Blockchain-enabled solution for safer PHRs storage, sup-
main idea (b). ported by the Fog computing architecture providing per-
formance boost for the application, improving the health
to decrease latency on PHR Blockchain operations and to things capabilities, and ultimately the patient’s experience.
provide a faster response for decision-making. Hence, it is safe to say that we focused the scope of this
FogChain enables real-time data processing, storage, and project entirely on the medical informatics field. However,
decision making by given smart contracts conditions satis- we understand that the model, as it is today, could be used in
fied. Whenever dealing with critical and or sensitive infor- different domains, as long as some adaptation is made in the
mation, the response time is crucial and must be taken Blockchain data structure.
into account. Approximating the Blockchain peer to the
IoHT devices through hosting itself a Peer inside of the B. ARCHITECTURE
Fog attempts to reduce the distance physical gap between The design and its components aim at supporting PHR
components. management through the employment of Fog computing

VOLUME 9, 2021 122727

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

FIGURE 2. FogChain’s macro visualization.

architecture, where a local Fog layer is combined with computing, where its technology is used for scaling solutions
Blockchain and IoHT technologies to suit better the require- for Cloud computing, being able to provide storage and com-
ments identified in the previous steps of research and lit- putation close to the end-user and edge devices [32]. Also,
erature review. Thus, Fog computing-based techniques are FogChain has mechanisms to provide further communication
employed to ensure high availability and performance, and and interoperability capabilities for devices and being respon-
Blockchain-based strategies were used to provide the privacy sible for dealing with communication protocols, filtering and
and tamper-proof required in the healthcare domain. Figure 2 validating data collected, and finally, transacting with the
depicts FogChain’s architecture showing its components and Blockchain network through API.
iterations. Four main components compose the architecture: The Fog layer of our model aims to run at the border of the
(i) IoHT Layer; (ii) Fog Layer; (iii) Blockchain Peers; and Edge, consisting of a Fog computing enabled environment,
(iv) Smart Contracts. The next subsections detail each com- where our proposed architecture dispose many of its features,
ponent and how the communication process works. as illustrated in Figure 3. It can be described as a middleware
component providing microservices responsible for handling,
1) IoHT LAYER filtering, and validating incoming data from edge devices,
The first interaction with the IoHT devices is given through before process requests to be persisted in the Blockchain
an internal component named IoHT++. It is responsible for ledger.
exchanging messages and communicating with devices, pro- The point of contact with the Edge devices is given through
viding some level of protocol interoperability by supporting the IoHT++ microservice. Working as an entry-point, it is
various protocols and standards. IoHT devices are the points responsible for the communication protocols interoperabil-
of contact with the physical world [9]. Devices belonging to a ity support, originated from the Nightbus (IoT++) project
wireless sensor network are often limited in terms of comput- implementation [50] and to be available in all FogChain’s
ing capacity, storage, memory, and energy availability [35], instances. IoHT++ has two main internal components which
and for this reason, usually the data is not stored in the are the middleware core and I/O boundaries. The first can be
devices themselves, but instead sent to the Fog layer. There, described as a message broker with general publish/subscribe
the middleware handles communication protocols known by capabilities. It divides messages into topics (categories of
the Health Things, including CoAP (Constrained Application messages) and allows for multiple interested clients to both
Protocol), MQTT (Message Queuing Telemetry Transport), produce and consume messages from topics. Its implemen-
and HTTP (Hypertext Transfer Protocol). tation uses the Apache Kafka software platform, which is
a distributed publish/subscribe messaging framework made
2) FOG LAYER available by the Apache Software Foundation [50].
The Fog layer is located between the IoHT devices and the Apache Kafka translates incoming client communication
Blockchain services. It comprises a solution based on Fog semantics into messages that are produced in the middleware

122728 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

FIGURE 4. FogChain’s App wireframe.

The IoHT devices’ hardware usually is too restricted to

actively contribute to the Blockchain network since con-
sensus algorithms are complex and require large processing
capacity and CPU storage capacity. To overcome these limi-
FIGURE 3. FogChain internal view structure and components. tations, the FogChain model proposes to add the Blockchain
Peer inside the Fog instances, where ideally hardware tends
to be more robust. Each FogChain peer has a copy of the
ledger and may actively contribute to the network by helping
core or consume messages from the core, communicating
to achieve consensus among existing peers.
them to the clients. These boundaries are configured and
This entire transaction workflow process helps to achieve
executed in separate processes and were implemented by the
consensus because all peers have reached an agreement on
original authors as services using the Clojure programming
the order and content of transactions, in a process that is
language, running on top of the Java Virtual Machine (JVM):
mediated by orderers. The consensus is a multi-step pro-
MQTT Subscriber, MQTT Publisher, CoAP Server, CoAP
cess and applications are only notified of ledger updates
Client, and HTTP Client.
when the process is complete. FogChain employs the Hyper-
Such communication protocols are supported to exchange
ledger Fabric7 framework to implement distributed ledgers.
information with IoHT devices, where its environment is usu-
Hyperledger Fabric allows the development of Blockchain
ally heterogeneous, allowing devices to communicate in dif-
applications, and it is currently adopted by several solu-
ferent protocols and channels, thus, aggregating some level of
tions [51]. By employing this framework, FogChain inherits
protocol interoperability necessary to our model. Whenever
the Practical Byzantine Fault Tolerance (PBFT) algorithm to
a new message successfully passes through the entry-point
reach a consensus among all nodes. Studies demonstrate that
and is forwarded to the internal FogChain microservices,
this algorithm can achieve better performance compared to
the incoming data is validated to prevent blank, null, or cor-
others [51]. The algorithm requires at least 3f + 1 nodes (n)
rupted information. Moreover, a filtering function is applied,
to participate in the process, where f represents the number
where it is possible to determine which information should
of faulty nodes, which can be achieved by f = n−1 3 .
be stored in the distributed ledger or to be discarded. For
The process where participants (patients and physicians)
instance, if a wearable device is collecting multi-parametric
join the network may be facilitated by the employment of
values, this filtering function allows us to decide which
smartphones interfacing with the FogChain and acting as a
parameters are essential and should be broadcasted to all
thin client to the network, for instance. This thin client is
peers of the Blockchain.
supported by the Hyperledger Fabric and represents the entity
that acts on behalf of an end-user. It must connect to a peer
3) BLOCHCHAIN PEERS to communicate with the Blockchain. The thin-client can
The Blockchain peers are designed to be set in place over connect to any peer of their choice and submit transaction
a consortium network for a more secure health information proposals. Figure 4 depicts a front-end design concept to
exchange (HIE) among participants and to improve clinical interface with FogChain back-end API and services, and are
data availability near the Edge. In terms of data structure, better described as follow:
the Blockchain can be configured to support storage and (a) A welcome screen for users (patients and physicians)
organization into existing data formats and open standards permitting identification and authentication through their
already established in the health sector, such as FHIR and
openEHR. 7 https://www.hyperledger.org/use/fabric

VOLUME 9, 2021 122729

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

public keys and or QR code. It should allow new users in JavaScript language, supported by the Node.js runtime to
to register (create wallet) and existing users to effectuate be available in all FogChain instances and all programming
login on the platform; can be seen in our code repository.8 It features microservices
(b) Patients are allowed to visualize and manage their PHR to be run locally, providing surrounding services to easy
fragments; communication with Edge devices while processing requests,
(c) Each patient is responsible for whom they decide to filtering and validating data before sending it to the local
share their health records, for example, by informing the Blockchain Peer.
physician id. Regarding the Blockchain to be used in our implementa-
tion, it is possible to state that currently there is a set of avail-
4) SMART CONTRACTS able frameworks. To find out which Blockchain platform suits
Smart Contracts are self-executing programs and protocols the best for our model we did research based on our require-
stored in Blockchain that facilitate, verify, and guarantee the ments and outcomes are presented in Table 2. The table
execution of a contract between members of the network. For compares potentially available platforms, thus identifying
example, a patient allows/authorizes a physician to visualize possible strengths and weaknesses in advance for our appli-
their medical history. These programs provide the ability cation model. For means of implementation, we have chosen
to directly track and execute complex agreements between the Hyperledger Fabric Blockchain distribution, which is a
parties without human interaction [35]. DLT solution, with an open-source license made available by
In the healthcare scenario, smart contracts may be very The Linux Foundation, and is in line with our demand given
useful, especially in cases where it is possible to define its permission aspect, modularity, tool support, no-fee, and
thresholds for collected data, thus, having smart contracts project maturity.
executed automatically in the background, which could help The Hyperledger project was designed for corporate and
in the decision. For instance, in a scenario where a patient’s organizational architectures, with a set of customizable rules,
heart rate exceeds the established limit, the smart contract allowing, for example, to operate with different consensus
could automatically trigger an event on the network notifying protocols, such as PBFT, Kafka, SOLO, among others. It dif-
the physician of the existing risks. fers from other Blockchain platforms because it focuses on
Smart contracts may feature improvements in the inter- the development of private and authorized networks, mainly
action between patients and health providers, by automat- suitable for organizations, rather than a public and open
ing and executing agreements predefined over the parties. network. It does not allow unknown identities to participate,
For instance, evaluating healthcare information collected by thus, allowing the location of medical records to remain
IoHT devices, such as multi-parametric devices for vital secure and restricted to hospitals and clinics infrastructure.
signs, and comparing these readings with customized thresh- Hyperledger’s Blockchain design does guarantee transac-
old values. It could trigger notification events or alerts for the tion’s integrity by submitting them through three main stages
patient itself or healthcare providers such as physicians and of a workflow process:
nurses when these thresholds exceed. This process provides 1) Transaction Proposal: applications generate a transac-
many possibilities to extend the network and assisting inter- tion proposal which they send to each of the required set
actions between patients and healthcare providers. of peers for endorsement;
2) Ordering and packaging transactions into blocks:
V. MATERIALS AND METHODS it receives transactions containing endorsed transaction
This section describes an experimental evaluation proposal responses from many applications, and orders
methodology carried out to test FogChain. We highlight the transactions into blocks;
that this evaluation aims at developing and deploying a 3) Validation and commit: involves the distribution and
FogChain infrastructure in the laboratory, focusing on com- subsequent validation of blocks and transactions before
paring FogChain to a traditional Cloud strategy. A multi- they can be persisted to the ledger. Every transaction
organization Blockchain network is in our scope, where each within a block must be validated to ensure that it is valid
organization may represent a clinic or hospital for example, and has been consistently endorsed by consensus peers.
and each organization is allowed to have multiple Peers To build this network, a set of tools were employed for the
spread over its infrastructure, with each Peer encapsulated development of the network and its middleware, for example,
into a FogChain instance. To test the feasibility of the model, the Hyperledger Composer, which is a collaboration tool,
we managed to implement and benchmark the solution, aim- distributed by the Linux Foundation and built with JavaScript,
ing to evaluate not only application throughput but also the including Node.js, NPM, and CLI.
impact of a Fog computing environment to mitigate latency
on the interaction between edge devices and the Blockchain A. IMPLEMENTATION
network. Figure 5 depicts the components used to implement the Fog
Backed by the Blockchain as a repository for the health Layer of the architecture. One of the first requirements to
records we created a Fog-enabled environment serving as a
middleware. The core of our FogChain architecture is written 8 https://bitbucket.org/uhospital/fogchain/src/multi-org/

122730 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

TABLE 2. Blockchain platforms comparison.

FIGURE 5. FogChain’s protoype layared visualization.

create our FogChain implementation was to start defining and

modeling who would be able to join the network. Specifying
what kind of information and in which format data would
be stored. For that, an important feature of the Hyperledger
Composer was handy, the object-oriented modeling language
that is used to define the domain model for a business network Listing 1. Hyperledger’s Composer model file.
definition and can be used to express information or knowl-
edge. A Hyperledger Composer model file is usually com-
posed of a single namespace with all resource declarations, Physician entity represents any medicine practitioner work-
and a set of resource definition syntax for assets, transactions, ing in the healthcare system. It may interact with the Patient’s
participants, and events. FogChain’s Blockchain network is medical records if so the patient allows them. These two
designed to have two main types of participants. Listing 1 well-defined types of participants can only interact with each
presents their modeled interactions and attributes. other through pre-defined transaction operations grantAccess
On the one hand, the Patient entity represents any person and revokeAccess, where they exchange permission over the
receiving or registered to receive medical treatment. Dur- Medical Record asset. These two operations allow us to grant
ing his life, he may have many medical records entries. the patient full control over their PHR.
The Patient gets to choose with whom he shares his While designing the Blockchain’s data structure to better
medical records, where only Physicians allowed by the scale and support the vast and varies amount of healthcare
Patient may see his medical history. On the other hand, the data, we came to the creation of an important feature to add

VOLUME 9, 2021 122731

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

Listing 2. Hyperledger Composer ACL rules example.

flexibility regarding the size of the transaction’s body, where

an optional field named ‘‘offchainDataLink’’ may be present FIGURE 6. GQM - The goal question metrics approach.
on the patient’s Medical Record asset. The off-chain approach
allows the storage of more heavyweight information such
as clinical images (e.g. X-Ray), into external file system simulations and test executions. It is carried by identifying
servers (off the chain) as per example the IPFS, a peer-to-peer a set of quality and productivity goals to improve system
distributed file system that seeks to connect all computing performance. From those goals and based upon models of
devices with the same system of files. the object of measurement and metrics, we derived questions
To establish boundaries among what participants can or that define those goals as completely as possible [7]. Given
cannot do, share, or access, the Hyperledger Composer pro- the GQM approach, we selected the latency and throughput
vides an access control language (ACL) that provides declar- metrics as the evaluation goal. Equations 1 and 2 define
ative access control over the elements of the domain model. the Latency and TPS (Transactions Per Second) metrics,
i
respectively. In Equation 1, trequest corresponds to the time
By defining ACL rules we can determine which users/roles
are permitted to create, read, update or delete elements in i
a request i is sent and tresponse is the time the response for this
a network’s domain model. A code snippet presented in request i arrives. This particular equation computes Latency
Listing 2 we do exemplify a few of our network rules built in milliseconds (ms). In turn, in Equation 2, TPS is achieved
to protect participants’ level of control over other participants by dividing the total number of requests n by the total time
and assets (health records). (in seconds) taken to process all requests. We selected these
Regarding the smart contracts on Hyperledger, it is metrics since they are commonly employed to evaluate the
also referred to as chain code in the Hyperledger Fabric performance of Blockchain applications [51].
documentation.
i i
Latency(i) = tresponse − trequest (1)
B. EVALUATION METRICS n
Prototyping is a method that confronts users with a partially TPS = 1 Pn−1 (2)
implemented model of a system intended to obtain quick 1000 × i=0 Latency(i)
feedback, for example, on its appearance and/or performance.
It is especially useful when it is applied together with the C. INFRASTRUCTURE AND CONFIGURATION
benchmark method. The benchmark tests are used to evaluate To evaluate the model and verify FogChain components’
the performance of information systems and to test their com- integration, we implemented and configured it on a local Fog
pliance with user requirements. In general, benchmarking is environment, responsible for processing and storing medical
considered a systematic tool that allows, through metrics, data information locally. For means of testing, we collected
to pursue and determine whether a process and or application data originated from a clinical vital signs dataset provided
is performing at its best. It allowed us to make improve- by ‘‘The University of Queensland’’ [29] institution. The
ments on the model and adapt specific components, usually local environment is composed of a physical server with
to increase some aspect of performance, and is employed as Ubuntu 16.04 (64-bit) Operating System, Intel Xeon E5-
a continuous process in which we continually seek perfor- 2620v4 2.1GHz processor, 32GB RAM, and HDD SAS
mance improvements [17]. 600Gb RAID 5 (10,000 RPM). The Hyperledger Fabric
To obtain meaningful metrics to be monitored and assessed Blockchain was installed and configured to run on containers
during our experiments and analysis, we employed the Goals, in this physical machine as components of the FogChain.
Questions, and Metrics (GQM) approach (see Figure 6). In particular, these containers share the physical machine
GQM is a software metric approach in software engineering resources, which makes them less powerful than the physical
that proposes steps for identifying correct metrics for the machine. As a consequence, these less powerful containers
creation and maintenance of a software system and clarifying mimic Fog nodes which are characterized by having less
which variables are essential to take into account during computing power than physical servers.

122732 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

TABLE 3. Evaluation scenarios with different parameters.

infrastructures, we can compare them and show the results of

employing FogChain.
At the end of the configuration stage, a Blockchain applica-
tion was set in place with the Hyperledger Fabric Blockchain
to store and manage PHR in a Fog environment. This prepa-
ration allowed us to collect metrics of this integration of
technologies such as IoHT, Fog computing, and Blockchain,
leading us to the next section where we finally execute all
tests and assess the benchmark results.

D. EVALUATION SCENARIOS
One of the main goals of FogChain is to improve response
time for IoHT applications. Therefore, we designed differ-
ent evaluation scenarios to compare it with Cloud solu-
tions to verify FogChain’s applicability. Additionally, some
parameter-wise decisions may influence the performance of
the model. Thus, we also cover this analysis in the evaluation
scenarios. The evaluation of FogChain was carried in three
different phases. The first phase consists of discovering the
optimal batch size of requests sent to the Blockchain that
results in the best latency and TPS. The latency metrics and
their calculation were carried by the execution of multiple
end-to-end requests, thus calculating the average results in
comparison with each other. It comprises ten executions of
four different batch sizes: 50, 100, 200, and 1,000. This phase
aims at evaluating whether the batch size impacts TPS or
FIGURE 7. Cloud and FogChain infrastructures employed for experiments. not.
In the second phase, three scenarios were modeled vary-
ing the batch size and the number of concurrent sessions.
All libraries and dependencies were managed through Table 3 presents the parameters employed in each scenario.
Node.js and Node Package Manager (NPM), having all of For each scenario, the total number of requests is equal to
our modeling and configurations in place, turning our net- 10,000 per session. The evaluation comprises the execution of
work finally available for tests. The next step was writing each scenario ten times. Thus, TPS is achieved by averaging
an application that reads columns of the aforementioned the results of the ten executions. For instance, let the total
vital signs dataset [29], such as the electrocardiogram (ECG) requests be 10,000, the average of ten executions be 100s,
and blood pressure, having each record becoming a trans- then TPS = 10,000
100 , resulting in 100 TPS.
action proposal, to be validated and persisted on the Finally, the third phase consists of comparing both
ledger. FogChain to Cloud solutions. Therefore, we executed the
To compare our solution with a Cloud infrastructure, same scenario in each infrastructure to compare the average
we configured a similar environment. Figure 7 depicts two latency in each one. More specifically, the scenario comprises
infrastructures employed on the experiments. In this second 10 executions of the application sending a batch of 50 samples
environment, instead of running the application to input data to the Blockchain in each infrastructure presented in Figure 7.
into the Blockchain locally, the script is hosted in a vir- Results are obtained by averaging the latency of the ten
tual machine (VM) on the Cloud. We configured an Ama- executions.
zon Web Services VM with the vital signs dataset. The
input application runs in the VM and sends requests to the VI. RESULTS AND DISCUSSION
Blockchain in our local infrastructure. This setup character- In this section we are going to demonstrate all results obtained
izes a Cloud environment because sensor data should use the during the research and development of our model implemen-
Internet to reach the Blockchain. Given both local and Cloud tation, carried simulations, and benchmarks.

VOLUME 9, 2021 122733

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

FIGURE 8. Multiple batch configuration benchmark results.

FIGURE 9. FogChain vs Cloud response-time comparison.

A. BATCH SIZE EVALUATION

Determined to check how long it would take for a single all transactions. As a consequence, both TPS and Latency
transaction to complete under our Fog computing environ- achieved the best results. On the other hand, as the scenarios
ment, we executed an initial test using the add operation from Medium and Load have more requests to compute, their final
the Hyperledger Composer API, which expects only a single results increase according to it. For instance, the Medium
asset as an input parameter. It resulted in an average Latency load achieved higher results than the Light, and the Heavy
of 180ms for a transaction to be created, ordered, validated, achieved even higher.
and ultimately persisted in the ledger, which if executed For all scenarios, the batch size is equal, however, they
multiple times sequentially would lead to approximately achieve different TPS. The Light load obtained similar TPS
5 TPS as throughput. to the tests performed to evaluate the batch size previously
Seeking performance improvements, transactions were (see Figure 8). However, the same is not true for the Medium
organized in bulks (batches) to verify a possible increase and Heavy scenarios. The results demonstrate that, even
of throughput and for that, instead of sending transactions with the optimal batch size, the TPS is impacted according
one by one sequentially, we employed the addAll operation, to the number of concurrent sessions. That imposes con-
which expects as an input parameter an array of assets, in our currency on processing requests, which decreases the final
case, an array of vital signs readings. In other words, the inter- TPS.
action with our Blockchain network was changed to work
in batches and the tricky part is to find an optimum batch C. FOGCHAIN VS CLOUD
size. This process implies our FogChain solution to accu- The third phase of our experiments aims at evaluating
mulate data and organize them in an array structure before the impact on Latency when employing FogChain ver-
sending them to the Blockchain. Figure 8 depicts the TPS sus the employment of a Cloud environment. Figure 9 depicts
achieved when employing different batch sizes, as described the difference between the two infrastructures result from the
in Section V-D. experiments. FogChain ach2ieves a Latency 62.6% smaller
According to the figure, performance degradation was when compared to the Cloud environment. As the data and
noticed while working with larger batch sizes. For exam- software components involved in running the experiments are
ple, a batch with 1,000 transactions would take approx- the same, we conclude that the main reason for such a differ-
imately 23 seconds to complete, with a low average ence is the latency introduced by the Internet connection.
of 43 TPS, while a smaller batch with half transactions As depicted in Section 7, all software and data components
(500) would take only six seconds. It was the first indica- are the same in both infrastructures. The only thing that
tion that our optimum batch size was likely to be a smaller changes from one setup to the other is the location where
number. the input data is. When employing a Cloud environment,
the data should be forwarded to the system through the inter-
B. ANALYSIS OF DIFFERENT SCENARIOS net connection, which may route data traffic in different paths
Table 4 shows the obtained results for each evaluation sce- depending on the Internet providers. On the other hand, when
nario. The Light load achieved the best results for all metrics employing FogChain, the Blockchain infrastructure is closer
compared to the other two. In this particular scenario, the total to the data source. That avoids delays imposed by routing
number of requests is lower than the Medium and Heavy protocols from public internet providers, thus, improving the
loads. Thus, it requires less CPU and Memory to compute results.

122734 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

TABLE 4. Average results from ten executions each at Fog environment with 95% confidence interval.

D. DISCUSSION It is safe to say that Fog computing can play a big role
FogChain focuses on employing Fog Computing to bring in healthcare applications, providing local processing power,
Blockchain closer to PHR IoT devices. The main goal is services, and increasing resources availability. It allows appli-
to decrease response time on registering records in the cations to decrease the amount of access to the cloud, where
Blockchain, making them available quicker. This strategy the connection is subject to delays on worldwide network traf-
makes the solution independent from Cloud infrastructures. fic, turning to be a viable and potential integrator of IoHT and
At the same time, as it employs several Fog nodes, the infras- Blockchain technologies. The current state-of-the-art focuses
tructure can be easily scaled by adding more nodes with on providing Blockchain solutions for healthcare with Cloud
Blockchain peers. Despite that, the evaluation we employ computing support. Therefore, it inherits the latency of net-
focuses on proving the performance improvement in response work connections to reach Cloud infrastructures. In this con-
time for application. The implemented evaluation demon- text, FogChain aims at bringing the Blockchain infrastructure
strated the capacity of our architecture as a technology closer to the healthcare environment decreasing latency for
integrator, providing an alternative to traditional Cloud-IoT its operations. Its main contribution relies on a Fog infras-
solutions, and the obtained results for latency and throughput tructure encompassing Blockchain peers for validation of
metrics did highlight the performance boost driven by the Fog PHR operations.
computing adoption. The need for more investment and efforts to consolidate
Having a complete patient’s medical history available in open standards for health records data structure has become
loco turns to be an intangible benefit for the healthcare clear and yet challenging, improving its levels of interop-
domain, leaving the solution with no external dependencies erability among health providers could end up easing the
such as ISP and or services, which is in contrast, for example, Blockchain adoption from the healthcare industry players.
with previous models assessed in the related work section. Furthermore, our model itself does not solve the intrin-
The FogChain implementation for PHR management demon- sic interoperability issues regarding different data formats
strated a slice of how Blockchain could be employed in between health providers, which are a broader concern in
the healthcare domain, benefiting from its cryptography and the healthcare area. Another important variable that must be
tamper-proof nature, which adds a security layer so necessary taken into account when considering the Blockchain solution
for healthcare applications. However, the FogChain model is is the scalability constraints in terms of the trade-off between
not limited to the healthcare domain only and could be also the volume of transactions and computer power for process-
adapted to other domains, for example, supply chain, smart- ing time of transactions.
city, and cross-industry applications.
Moreover, working with batches of transactions demon- VII. CONCLUSION
strated to be favorable, and with this approach in place, The implementation’s evaluation demonstrated satisfactory
we managed to obtain a satisfactory application throughput. proofs regarding the feasibility of FogChain architecture and
It resulted in performance improvements on TPS capacity of the combination of its components. A possible future direc-
our architecture and combined with the local Fog computing tion to this research could be carrying tests in clinics and
benefits, promoted closer to real-time features on the process hospitals scenario. Some challenges were identified during
of vital signs’ collecting, securing, and storage. As bandwidth our research and development process, such as technological
measures how much data can flow through a specific connec- limitations, industry adoption, infrastructure costs, among
tion at one time, it turns out it strongly relies on the physical others. Furthermore, currently available frameworks may not
hardware used in the experiment. For instance, a gigabit Eth- have full compliance with the healthcare regulatory organiza-
ernet connection has a bandwidth of 1,000 Mbps, while the tions such as HIPAA and GDPR. For example, in a scenario
Fast Ethernet compliant network may transfers data at rates where a patient has the right to be forgotten, requiring the
up to 100 Mbps. Thus, considering the local nature of the Fog, entire deletion of their stored health data in the network,
its bandwidth relies on the local infrastructure itself while which would clash directly with the immutability principle
the Internet Service Providers (ISP) restrain it in cloud-like of Blockchain solutions.
environments. More specifically, in our scenario, the patient’s Finally, our solution has some limitations that can be
wearable sensors usually collect and transfer raw data, which addressed in future work. First, the Fog infrastructure we
are typically lightweight, not consuming extensive network employ is based on a single server running containers. The
bandwidth. However, the more the sensors evolve, the more ideal setup can consider employing less powerful nodes dis-
they need larger bandwidth on the network. tributed physically instead of virtualized ones in the same

VOLUME 9, 2021 122735

 A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

physical machine. In addition, the evaluation does not con- [15] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, ‘‘Blockchain for
sider scenarios with different nodes available, which would IoT security and privacy: The case study of a smart home,’’ in Proc. IEEE
Int. Conf. Pervas. Comput. Commun. Workshops (PerCom Workshops),
be required to assess the scalability of the solution. Second, Mar. 2017, pp. 618–623.
we developed a single application to extract data from a [16] A. Ekblaw, A. Azaria, J. D. Halamka, and A. Lippman, ‘‘A case study for
dataset and input it into the system. Further research should be blockchain in healthcare: ‘MedRec’ prototype for electronic health records
and medical research data,’’ in Proc. IEEE Open Big Data Conf., vol. 13,
done employing real-time critical applications instead. Third, Aug. 2016, p. 13.
the evaluation focuses mainly few parameters and metrics, [17] L. Hagge and J. Kreutzkamp, ‘‘A benchmarking method for information
which future experiments can explore further. Finally, another systems,’’ in Proc. J. Lightw. Technol., Sep. 2003, pp. 245–253.
[18] M. U. Hassan, M. H. Rehmani, and J. Chen, ‘‘Privacy preservation in
point of attention is on the evaluation scenarios. We do sug- blockchain based IoT systems: Integration issues, prospects, challenges,
gest adding more participants and roles to the network, for and future research directions,’’ Future Gener. Comput. Syst., vol. 97,
example, allowing insurance companies to join the network, pp. 512–529, Aug. 2019.
[19] G. Tripathi, M. A. Ahad, and S. Paiva, ‘‘S2HS-A blockchain based
moreover, proposing and implementing interoperability fea- approach for smart healthcare system,’’ in Healthcare. Amsterdam, The
tures for the PHR storage, regarding data format and transac- Netherlands: Elsevier, 2019, Art. no. 100391.
tion block structures. [20] D. Ichikawa, M. Kashiyama, and T. Ueno, ‘‘Tamper-resistant mobile health
using blockchain technology,’’ JMIR mHealth uHealth, vol. 5, no. 7,
p. e111, Jul. 2017.
DECLARATION OF COMPETING INTEREST [21] J. Vora, A. Nayyar, S. Tanwar, S. Tyagi, N. Kumar, M. S. Obaidat,
The authors declare that there is ‘‘No Conflict of Interest’’ in and J. J. P. C. Rodrigues, ‘‘BHEEM: A blockchain-based framework for
securing electronic health records,’’ in Proc. IEEE Globecom Workshops
the current manuscript. (GC Wkshps), Dec. 2018, pp. 1–6.
[22] E. Karafiloski and A. Mishev, ‘‘Blockchain solutions for big data chal-
REFERENCES lenges: A literature review,’’ in Proc. IEEE EUROCON 17th Int. Conf.
Smart Technol., Jul. 2017, pp. 763–768.
[1] E. Ahmed, A. Islam, M. Ashraf, A. I. Chowdhury, and M. M. Rahman, [23] A. Kaur, A. Nayyar, and P. Singh, Blockchain Cryptocurrencies and
‘‘Internet of Things (IoT): Vulnerabilities, security concerns and things Blockchain Technology Applications. Hoboken, NJ, USA: Wiley, 2020,
to consider,’’ in Proc. 11th Int. Conf. Comput., Commun. Netw. Technol. pp. 25–42.
(ICCCNT), Jul. 2020, pp. 1–6. [24] M. A. Khan and K. Salah, ‘‘IoT security: Review, blockchain solutions,
[2] R. Akkaoui, X. Hei, and W. Cheng, ‘‘EdgeMediChain: A hybrid edge and open challenges,’’ Future Gener. Comput. Syst., vol. 82, pp. 395–411,
blockchain-based framework for health data exchange,’’ IEEE Access, May 2018.
vol. 8, pp. 113467–113486, 2020. [25] B. Kitchenham, R. Pretorius, D. Budgen, O. P. Brereton, M. Turner,
[3] S. Ali, Y. Hafeez, N. Z. Jhanjhi, M. Humayun, M. Imran, A. Nayyar, M. Niazi, and S. Linkman, ‘‘Systematic literature reviews in software
S. Singh, and I.-H. Ra, ‘‘Towards pattern-based change verification engineering—A tertiary study,’’ Inf. Softw. Technol., vol. 52, vol. 8,
framework for cloud-enabled healthcare component-based,’’ IEEE Access, pp. 792–805, 2010.
vol. 8, pp. 148007–148020, 2020. [26] T.-T. Kuo, H.-E. Kim, and L. Ohno-Machado, ‘‘Blockchain dis-
[4] S. Badr, I. Gomaa, and E. Abd-Elrahman, ‘‘Multi-tier blockchain tributed ledger technologies for biomedical and health care applica-
framework for IoT-EHRs systems,’’ Procedia Comput. Sci., vol. 141, tions,’’ J. Amer. Med. Inform. Assoc., vol. 24, no. 6, pp. 1211–1220,
pp. 159–166, Jan. 2018. Nov. 2017.
[5] K. Biswas and V. Muthukkumarasamy, ‘‘Securing smart cities using [27] R. M. Amir Latif, K. Hussain, N. Z. Jhanjhi, A. Nayyar, and O. Rizwan, ‘‘A
blockchain technology,’’ in Proc. IEEE 18th Int. Conf. High Perform. remix IDE: Smart contract-based framework for the healthcare sector by
Comput. Commun., IEEE 14th Int. Conf. Smart City; IEEE 2nd Int. Conf. using blockchain technology,’’ Multimedia Tools Appl., vol. 79, pp. 1–24,
Data Sci. Syst. (HPCC/SmartCity/DSS), Dec. 2016, pp. 1392–1393. Nov. 2020.
[6] R. Buyya and J. Son, ‘‘Software-defined multi-cloud computing: A vision, [28] V. L. Lemieux, ‘‘A typology of blockchain recordkeeping solutions and
architectural elements, and future directions,’’ in Proc. Int. Conf. Comput. some reflections on their implications for the future of archival preser-
Sci. Appl. Melbourne, VIC, Australia: Springer, 2018, pp. 3–18. vation,’’ in Proc. IEEE Int. Conf. Big Data (Big Data), Dec. 2017,
[7] R. van Solingen, B. Rini, C. Vic, and R. Gianluigi, ‘‘Goal question metric pp. 2271–2278.
(GQM) approach,’’ in Encyclopedia of Software Engineering. American [29] D. Liu, M. Görges, and A. S. Jenkins, ‘‘University of Queensland
Cancer Society, 2002, doi: 10.1002/0471028959.sof142. vital signs dataset,’’ Anesthesia Analgesia, vol. 114, no. 3, pp. 584–589,
[8] E. C. Cheng, Y. Le, J. Zhou, and Y. Lu, ‘‘Healthcare services across Mar. 2012, doi: 10.1213/ane.0b013e318241f7c0.
China—On implementing an extensible universally unique patient iden- [30] K. Mannaro, G. Baralla, A. Pinna, and S. Ibba, ‘‘A blockchain approach
tifier system,’’ Int. J. Healthcare Manage., vol. 11, no. 3, pp. 210–216, applied to a teledermatology platform in the Sardinian region Italy,’’ Infor-
Jul. 2018. mation, vol. 9, no. 2, p. 44, 2018.
[9] K. Christidis and M. Devetsikiotis, ‘‘Blockchains and smart contracts for [31] A. H. Mayer, C. A. D. Costa, and R. D. RosaRighi, ‘‘Electronic health
the Internet of Things,’’ IEEE Access, vol. 4, pp. 2292–2303, 2016. records in a blockchain: A systematic review,’’ Health Informat. J., vol. 26,
[10] M. Conoscenti, A. Vetro, and J. C. De Martin, ‘‘Blockchain for the Internet no. 2, pp. 1273–1288, 2019.
of Things: A systematic literature review,’’ in Proc. IEEE/ACS 13th Int. [32] G. Mokhtari, A. Anvari-Moghaddam, and Q. Zhang, ‘‘A new layered
Conf. Comput. Syst. Appl. (AICCSA), Nov. 2016, pp. 1–6. architecture for future big data-driven smart homes,’’ IEEE Access, vol. 7,
[11] M. A. Cyran, ‘‘Blockchain as a foundation for sharing healthcare data,’’ pp. 19002–19012, 2019.
Blockchain Healthcare Today, vol. 1, Mar. 2018. [Online]. Available: [33] S. B. Moon, P. Skelly, and D. Towsley, ‘‘Estimation and removal of
https://www.blockchainhealthcaretoday.com/index.php/journal/article/ clock skew from network delay measurements,’’ in Proc. 18th Annu. Joint
view/13, doi: 10.30953/bhty.v1.13. Conf. IEEE Comput. Commun. Soc. (INFOCOM), vol. 1, Mar. 1999,
[12] C. A. da Costa, C. F. Pasluosta, B. Eskofier, D. B. da Silva, and pp. 227–234.
R. da Rosa Righi, ‘‘Internet of Health Things: Toward intelligent vital [34] M. Niranjanamurthy, B. Nithya, and S. Jagannatha, ‘‘Analysis of
signs monitoring in hospital wards,’’ Artif. Intell. Med., vol. 89, pp. 61–69, blockchain technology: Pros, cons and SWOT,’’ Cluster Comput., vol. 22,
Jul. 2018. pp. 14743–14757, Mar. 2018.
[13] G. G. Dagher, J. Mohler, M. Milojkovic, and P. B. Marella, ‘‘Ancile: [35] O. Novo, ‘‘Blockchain meets IoT: An architecture for scalable access
Privacy-preserving framework for access control and interoperability of management in IoT,’’ IEEE Internet Things J., vol. 5, no. 2, pp. 1184–1195,
electronic health records using blockchain technology,’’ Sustain. Cities Apr. 2018.
Soc., vol. 39, pp. 283–297, May 2018. [36] J. Pan and J. McElhannon, ‘‘Future edge cloud and edge computing for
[14] C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Internet of Things applications,’’ IEEE Internet Things J., vol. 5, no. 1,
Performance Metrics IPPM, document RFC 3393, Nov. 2002. pp. 439–449, Feb. 2018.

122736 VOLUME 9, 2021

A. H. Mayer et al.: FogChain: Fog Computing Architecture Integrating Blockchain and IoT

[37] K. Rabah, ‘‘Challenges & opportunities for blockchain powered healthcare VINICIUS FACCO RODRIGUES received the
systems: A review,’’ Mara Res. J. Med. Health Sci., vol. 1, no. 1, pp. 45–52, Ph.D. degree in applied computing from the
2017. Universidade do Vale do Rio dos Sinos
[38] M. A. Rahman, M. M. Rashid, M. S. Hossain, E. Hassanain, M. F. Alhamid, (UNISINOS), Brazil, in 2020. He has been a
and M. Guizani, ‘‘Blockchain and IoT-based cognitive edge framework Research Assistant with the Software Innova-
for sharing economy services in a smart city,’’ IEEE Access, vol. 7, tion Laboratory (SOFTWARELAB), UNISINOS,
pp. 18611–18621, 2019. since 2016, where he is working on research
[39] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz, ‘‘On blockchain
projects. His research interests include distributed
and its integration with IoT. Challenges and opportunities,’’ Future Gener.
systems, computer networks, high-performance
Comput. Syst., vol. 88, pp. 173–190, Nov. 2018.
[40] R. Ribitzky, J. St. Clair, D. I. Houlding, C. T. McFarlane, B.‘Ahier, computing, health informatics, and artificial
M. Gould, H. L. Flannery, E. Pupo, and K. A. Clauson, ‘‘Pragmatic, inter- intelligence.
disciplinary perspectives on blockchain and distributed ledger technology:
Paving the future for healthcare,’’ Blockchain Healthcare Today, vol. 1,
Mar. 2018. [Online]. Available: https://www.blockchainhealthcaretoday.
com/index.php/journal/article/view/24, doi: 10.30953/bhty.v1.24. CRISTIANO ANDRÉ DA COSTA (Senior Mem-
[41] A. Roehrs, C. A. da Costa, and R. da Rosa Righi, ‘‘OmniPHR: A distributed ber, IEEE) is currently a Full Professor with
architecture model to integrate personal health records,’’ J. Biomed. the Universidade do Vale do Rio dos Sinos
Inform., vol. 71, pp. 70–81, Jul. 2017. (UNISINOS), Brazil, and a Researcher on produc-
[42] A. Roehrs, C. A. da Costa, R. D. R. Righi, and K. S. F. de Oliveira, tivity at the National Council for Scientific and
‘‘Personal health records: A systematic literature review,’’ J. Med. Internet Technological Development (CNPq). His research
Res., vol. 19, no. 1, p. e13, Jan. 2017. interests include ubiquitous, mobile, parallel, and
[43] A. Roehrs, C. A. da Costa, R. da Rosa Righi, V. F. da Silva, J. R. Goldim, distributed computing. He is a Senior Member of
and D. C. Schmidt, ‘‘Analyzing the performance of a blockchain-based ACM and a member of IADIS and the Brazilian
personal health record implementation,’’ J. Biomed. Informat., vol. 92,
Computer Society (SBC).
Apr. 2019, Art. no. 103140.
[44] M. Samaniego, U. Jamsrandorj, and R. Deters, ‘‘Blockchain as a service for
IoT,’’ in Proc. IEEE Int. Conf. Internet Things (iThings) IEEE Green Com-
put. Commun. (GreenCom) IEEE Cyber, Phys. Social Comput. (CPSCom)
IEEE Smart Data (SmartData), Dec. 2016, pp. 433–436. RODRIGO DA ROSA RIGHI (Senior Member,
[45] Z. Shae and J. J. P. Tsai, ‘‘On the design of a blockchain platform for IEEE) received the Ph.D. degree in computer sci-
clinical trial and precision medicine,’’ in Proc. IEEE 37th Int. Conf. Distrib. ence from UFRGS University, Brazil, in 2009.
Comput. Syst. (ICDCS), Jun. 2017, pp. 1972–1980. He concluded his postdoctoral studies at Korea
[46] P. K. Sharma, M.-Y. Chen, and J. H. Park, ‘‘A software defined fog node Advanced Institute of Science and Technology
based distributed blockchain cloud architecture for IoT,’’ IEEE Access, (KAIST), under the following topics: RFID and
vol. 6, pp. 115–124, 2018. cloud computing. He is currently an Assistant Pro-
[47] B. Shen, J. Guo, and Y. Yang, ‘‘MedChain: Efficient healthcare data fessor and a Researcher with the Universidade do
sharing via blockchain,’’ Appl. Sci., vol. 9, no. 6, p. 1207, Mar. 2019. Vale do Rio dos Sinos, Brazil. His research inter-
[48] C. A. Silva, G. S. Aquino, S. R. M. Melo, and D. J. B. Egídio, ‘‘A fog ests include load balancing and process migration.
computing-based architecture for medical records management,’’ Wireless He is a member of ACM.
Commun. Mobile Comput., vol. 2019, pp. 1–16, Feb. 2019.
[49] S. P. Singh, A. Nayyar, R. Kumar, and A. Sharma, ‘‘Fog computing: From
architecture to edge computing and big data processing,’’ J. Supercomput.,
vol. 75, no. 4, pp. 2070–2105, Apr. 2019.
[50] F. Suad, C. A. D. Costa, R. D. R. Righi, M. Gomes, and A. L. Bertoldi, ALEX ROEHRS received the Ph.D. degree in
‘‘Exploring extensibility and interoperability in the Internet of Things land- computer science from the Universidade do
scape,’’ in Proc. 17th Int. Conf. WWW/Internet, P. Isaías and H. Weghorn, Vale do Rio dos Sinos (UNISINOS), in 2019.
Eds. 2018, pp. 339–343. He is currently an Assistant Professor and a
[51] C. Fan, S. Ghaemi, H. Khazaei, and P. Musilek, ‘‘Performance evalua- Researcher at UNISINOS. His research inter-
tion of blockchain systems: A systematic survey,’’ IEEE Access, vol. 8, ests include distributed systems, blockchain, and
pp. 126927–126950, 2020.
health informatics.
[52] S. Tuli, R. Mahmud, S. Tuli, and R. Buyya, ‘‘FogBus: A blockchain-
based lightweight framework for edge and fog computing,’’ J. Syst. Softw.,
vol. 154, pp. 22–36, Aug. 2019.

ANDRÉ HENRIQUE MAYER received the mas- RODOLFO STOFFEL ANTUNES (Member,
ter’s degree from the Applied Computing Graduate IEEE) received the B.Sc. degree in computer sci-
Program, Universidade do Vale do Rio dos Sinos ence from UNISINOS, in 2009, and the Ph.D.
(UNISINOS), Brazil, where he is currently pursu- degree in computer science from UFRGS, in 2016.
ing the Ph.D. degree. He is currently a Research He is currently an Assistant Professor and a
Assistant at UNISINOS. His research interests Researcher at UNISINOS. His research inter-
include blockchain and the Internet-of-Things. ests include the Internet-of-Things and distributed
systems.

VOLUME 9, 2021 122737