FogChain: A Fog Computing Architecture Integrating Blockchain and Internet of Things for Personal Health Records

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.


I. INTRODUCTION
Internet of Things (IoT) refers to the network of physical objects embedded with software and sensor devices capable of communicating over the Internet for information exchanging [1]. Such devices collect, process, and exchange vast amounts of data from the surrounding environment as well The associate editor coordinating the review of this manuscript and approving it for publication was Vyasa Sai. as privacy-sensitive information without any human intervention [5]. When applied to the healthcare context, such devices comprise the Internet of Health Things (IoHT) [12], which consists of a network of interconnected objects exchanging and processing medical data focused on improving medical processes. Such environments impose additional restrictions on technologies that handle such data due to its sensitivity and confidentiality issues. As a result, the sensitive nature of such networks makes them appealing targets for cyberattacks [15]. VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ The privacy of collected data may be at risk when stored and managed by outsourced companies on centralized servers (e.g., cloud hosting). In such cases, the main concerns regard data leaks caused by cyberattacks the cloud providers might suffer [10].
In the last few years, the rise of Blockchain technologies offer secure solutions providing trust, accountability, traceability, and integrity of data sharing, to secure distributed data across organizations [18], [24], [40]. That enables solutions to try Blockchain capabilities in the context of healthcare to overcome privacy and security problems. Currently, Blockchain is the most popular form of distributed ledger technology (DLT). Its features enable IoT applications that require a trusted third party to be decentralized [23]. Thus, the need for a central authority is removed without compromising the functionalities and guarantees of applications [9], [40]. The use of cryptography, a key characteristic of Blockchain networks, brings authoritativeness behind all the interactions in the network [9], where Blockchain has a fundamental role in registering and authenticating all operations performed on IoT devices data [10]. This technology could reinvent the way patient's electronic and personal health records (EHR and PHR) are shared and stored by providing safer mechanisms for health information exchange (HIE), by securing it over a decentralized peer-to-peer network, thus making the health records more available, efficient and secure [31], [37].
Regardless of the security challenges, IoHT environments require extra performance when it comes to time response.
Having quick access to processed information from patients allow fast decision-making by the medical team. That is crucial to improve medical services and deliver a high quality of service for patients. Frequently, current IoT and healthcare solutions rely on Cloud computing resources to provide processing of data from sensors [3]. However, such solutions impose data to be transferred to cloud servers, which can be physically distant and increase network latency. That impacts the agility of the system to process and produce feedback from data to the medical team. Moreover, a recent study predicts that centralized clouds, frequently used in current IoT systems, will be unlikely to deliver satisfactory services to customers [46]. From the core to the edge of the network, adoption of Fog computing alternatives is encouraged and represents a layered service structure that is an extension of the cloud computing paradigm [46].
Fog computing can provide faster cloud-like services such as storage, computing, and networking capabilities closer to users and devices, by extending the data management field of the cloud and increases the accessibility of IoT resources [49]. These abilities are a consequence of allocating Fog nodes closer to the IoT devices, at the edge of the network, thus reducing communication's latency and promoting closer to real-time communication with the Things layer [6], [36], [46]. Given that IoT devices spend most of their available energy and computational resources to execute core application functionalities and data collection, supporting extra security and privacy turns to be quite challenging [15].
Currently, to the best of our knowledge, there are no studies that focus on integrating Fog and Blockchain technologies to the IoHT domain. In this context, this article proposes FogChain, a model for integrating Fog and Blockchain for PHR management. FogChain allows close to real-time data processing given that the patient's health records are to be locally available in a Fog computing layer, thus improving physicians response time and decision making [42]. We developed a prototype of the model using JavaScript and employed Hyperledger Fabric distribution in the Blockchain level of the model. Experiments demonstrated improvements up to 40.3% in response time when comparing FogChain with a Cloud solution. In summary, the main goals of the current research are as follows: • Build a model for integrating Blockchain and Fog Computing to manage PHR in the IoHT field; • Improve response time on registering PHR information in the Blockchain and, consequently, make health data available quickly.
We have organized the article as follows. Section II introduces background concepts related to this research. Section III presents related research carried for other authors in the same domain this research focuses on. Following, Section IV describes the FogChain model, including design decisions and its architecture. Then, Sections V and VI present the evaluation methodology and results, respectively. Finally, Section VII concludes the article with final remarks and future directions.

II. BACKGROUND
This section gives a brief overview of the main technologies employed in this study: Blockchain, IoHT, and Fog Computing. The concept of IoT may have different interpretations depending on the context where it is applied. For instance, the things-centric (e.g., from the sensor's point of view) could potentially be patient-centric by consisting of interconnected objects with the capacity of exchanging and processing data to improve patient's health [12]. In this sense, IoHT consists of interconnected objects with the capacity of exchanging and processing data to improve patient health [12]. It relies on the use of wearable sensors and other medical devices that communicate via RFID, NFC, or Bluetooth with computing nodes to extract information from the medical environment. They collect and transmit data to remote servers for further processing to generate feedback aiming at improving medical processes. The main goal in such environments is to monitor sensor data providing information regarding the patients, medical staff, equipment, and even the environment.
In turn, Blockchain is gaining attention in the last few years in many different fields. It consists of a Peer-to-Peer (P2P) DLT for transactions that do not require a central authority, eliminating the need for third-party verification [10]. A Blockchain contains sets of chained blocks of transactions and every block contains a hash of the previous block. In summary, a Blockchain is a distributed ledger protocol originally associated with Bitcoin [16]. It uses public-key cryptography to create an append-only, immutable, and time-stamped chain of content [37]. It was originally designed for keeping a financial ledger, but the Blockchain paradigm can be extended to provide a generalized framework for implementing decentralized compute resources even into the Healthcare ecosystem [16]. Blockchain technologies are a promising means to address the barriers with distributed health records by forming a unified view of the patient's personal health records. The process of collecting vital signs in hospital wards varies, and different approaches are used worldwide. In some cases, data is only manually collected and stored in spreadsheets that are discarded after the patient is discharged [12], and is precisely at this point where Blockchain technology may contribute and become a viable solution for health records management.
Finally, Fog Computing may be viewed as a layered service structure that is an extension of the Cloud Computing paradigm. It is composed of low-energy computing nodes with limited hardware specifications. They can provide faster Cloud services such as storage, computing, and networking capabilities to end-users, with Fog nodes located near the devices at the edge of the network [46]. The Fog Computing infrastructure may support distributed applications with the addition of a new intermediary layer between the devices and back-end services, potentially facilitating their integration [39]. It may help to prevent unavailabilities originated by delays and latency gaps over the public Internet, which are of the most concerns on healthcare information exchange applications [48]. In summary, Fog Computing plays an important role in the healthcare domain and has the potential to be a natural technology integrator. Recent studies point out the benefits of adopting it on an organization's internal infrastructure, and these benefits could be extended to patients in clinics and hospitals.

III. RELATED WORK
This section presents literature studies related to our scope of research. We followed the principles of the systematic literature review [25] to reach the most relevant articles in the scope of Fog Computing, Blockchain, and IoHT. First, we defined the following set of keywords to compose a search query to be applied to several article databases: blockchain AND (intertet of things OR iot) AND (fog computing OR fog) AND (healthcare OR health) AND (health record OR medical record OR EHR OR PHR OR EMR) Using the string above, we queried six different scientific databases: (i) IEEEXplore, 1 (ii) PubMed Central, 2 (ii) Google Scholar, 3 (iv) Springer Link, 4 (v) ACM Digital Library, 5 and (vi) Science Direct. 6 We chose these databases to cover a broad set of scientific literature published in different areas. In each database, we built the search query filtering articles from the last ten years to reach the most recent studies in the area. Following, Section III-A details each selected article from our methodology, while Section III-B presents some discussion and open issues that drive our research.

A. STATE-OF-THE-ART
In [4], the authors present a multi-tier framework for integrating IoT in EHR systems using Blockchain and Cloud technologies. The proposed system uses Elliptic Curve Cryptography (ECC), which may introduce more security strength compared to other cryptography approaches. However, the solution does not provide health records locally. Instead, they are accessible through a Blockchain Cloud provider, which is not covered in the article. In [19], the authors propose the Secured and Smart Healthcare System (S2HS) to provide security and privacy in healthcare systems. The study employs a Wireless Sensor Network (WSN) architecture to collect EHR data from IoT wearable devices. Blockchain is employed to encrypt and standardize the data before storing it on the Cloud.
Moreover, [38] introduces a framework for sharing economy services in smart cities combining IoT, Blockchain, and Edge technologies. The authors propose AI solutions at the Edge of the network to process data from IoT devices across several domains. The Blockchain composes the security layer responsible for validating and encrypting transactions. The core of the system relies on decentralized Cloud platforms in which the IoT data is stored. In [47], the authors propose a healthcare data sharing model to reduce data fragmentation and allow patients better control of their data. The model consists of a dual-network architecture for mutable and immutable data. The latter employs Blockchain to provide security and privacy. The strategy requires healthcare providers to manually upload the information of data streams to the Blockchain service.
Furthermore, [48] presents a Fog architecture to manage medical records using Blockchain and Cloud. The main goal of the solution is to provide patients the ability to control access to their medical data. Fog nodes are placed near the sensors to provide a decentralized Blockchain authorization layer and make data available close to the applications. The article describes a case study that evaluates the performance, privacy, and interoperability requirements of the proposed architecture in a home-centered healthcare scenario. In [52], the authors develop a framework for integrating IoT systems, Fog, and Cloud infrastructure. The proposal consists of several Fog nodes close to sensors providing computing capabilities and data processing. The Cloud infrastructure works as a back-end which is required when Fog nodes are overloaded. In addition, Blockchain is employed in the Fog layer to ensure the integrity of confidential data. The study does not focus specifically on EHR, however, the authors perform a sleep apnea analysis as a case study.
In [21], the authors propose a Blockchain-based framework focused specifically on the storage and management of EHRs. The strategy employs multiple smart contracts to separate different types of information. The main goal is to provide privacy and control over the records to the patients. In turn, [2] proposes the EdgeMediChain architecture to facilitate medical data exchange by combining Blockchain and Edge infrastructure. It consists of an authentication and authorization framework for health data sharing coming from IoT medical devices. The main contribution is the ability of the architecture to perform data processing from several sensors in parallel through Edge-mining pools. Each mining pool consists of several Edge nodes that process data from sensors within a geographical location. Also focusing on data sharing, [27] seek patient information exchange among several hospitals. The authors propose a framework employing Blockchain to store historical data from patients using smart contracts.

B. DISCUSSION AND RESEARCH OPPORTUNITIES
The current state-of-the-art contains several studies that focus on bringing Blockchain to the industry and healthcare sectors. From the studies gathered according to our review methodology, the most common technology that outstands is Blockchain. In the last few years, Blockchain is gaining attention due to its capabilities to provide a decentralized way of protecting data. In general, proposals make use of smart contracts to validate transactions in medical records. Through them, systems aim to give to the patients the power of controlling who can access their medical data. Besides, solutions employ Blockchain to guarantee data integrity and avoid misuse of sensitive data.
Although having Blockchain in common, studies differ on the technologies they integrate with their solutions. For instance, on the one hand, most of the studies employ Cloud infrastructures to provide medical data remotely [4], [19], [38], [48], [52]. That imposes the systems to rely on network connections that may suffer from high latency problems and, consequently, provide poor quality of service for end-users and applications. On the other hand, few studies employ Edge infrastructures to their solutions [2], [38]. In such cases, the Edge infrastructure provides data processing capabilities closer to the sensors with a focus on load distribution. That allows the system scalability focusing on a wide deployment of a smart city or aggregation of several hospitals.
Blockchain applications in healthcare are still in the early stages of development and evaluation, existing obstacles to be overcome, opening paths for more possibilities in the field. For example, some Blockchain studies aim to address healthcare's recordkeeping challenges, such as protecting and securing sensitive health information while improving patients' level of control over their data [4], [38], [47], [48], [52]. Another important finding is the very importance of working on health records interoperability through the definition of open standards. It may be the key to improvements in healthcare services due to health data needs for sharing yet securely, availability, and integration. Furthermore, the use of Blockchain technology in clinical trials may enhance the development of drugs and medical devices.
Health records and their acronyms are a key term in our research, both electronic and personal health records (EHR and PHR) are seen as standardized healthcare information models, providing several benefits, ranging from supporting medical prescriptions to enabling possible integration among multiple and different healthcare providers (considered as its main advantage). However, limitations exist regarding its interoperability, e.g., when health organizations adopt international but heterogeneous standards. Very few studies combine specific technologies in the way we are proposing on our FogChain model for the healthcare domain. Most healthcare providers are still storing health records on private centralized servers, and in different data formats, which is difficult to interoperability.
Some of the aforementioned studies do recommend and or employ Fog computing to improve their architectures in terms of resources availability, latency mitigation, and increased near-edge storage. These studies have helped us to better understand existing challenges and open questions about similar architectural models, allowing us to prepare and propose our model for personal health records management in the healthcare domain. Looking at Table 1, only two articles include Fog infrastructures in their strategies [48], [52]. In particular, these strategies employ Fog nodes to provide closer computing capabilities to applications. However, they also require a Cloud back-end infrastructure to support overload situations due to their Fog layer be limited. Given the context, there is a lack of studies focusing specifically on the integration of Fog and Blockchain for IoHT without requiring a Cloud infrastructure. The requirement of Cloud infrastructures imposes the strategies to integrate their environment with third-party providers which may not be ideal for patients. That demonstrates a research opportunity that drives the current study.

IV. FOGCHAIN MODEL
In this section, we describe the proposed model called FogChain. As the name suggests, FogChain comprehends the union of Fog computing and Blockchain technologies, which means we aim to have both co-existing, collaborating, and running in the same container at a Fog computing level. While default cloud-hosted IoT and IoHT applications struggle with significant latency issues caused by Internet network congestion and traffic [11], FogChain employs Fog computing as a middleware layer between sensor devices and the Blockchain which could better suit the IoHT needs. Figure 1 depicts FogChain's main innovation compared to traditional solutions. FogChain introduces Fog nodes that run Blockchain peers closer to the sensors. The main idea is  to decrease latency on PHR Blockchain operations and to provide a faster response for decision-making.
FogChain enables real-time data processing, storage, and decision making by given smart contracts conditions satisfied. Whenever dealing with critical and or sensitive information, the response time is crucial and must be taken into account. Approximating the Blockchain peer to the IoHT devices through hosting itself a Peer inside of the Fog attempts to reduce the distance physical gap between components.
Considering possible FogChain's applications for the healthcare domain, it could be employed in healthcare organizations' infrastructures such as hospital departments or wards, handling its internal demands. Also, it could be possible 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 network 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 following 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 a Blockchain-enabled solution for safer PHRs storage, supported by the Fog computing architecture providing performance boost for the application, improving the health things capabilities, and ultimately the patient's experience. Hence, it is safe to say that we focused the scope of this project entirely on the medical informatics field. However, we understand that the model, as it is today, could be used in different domains, as long as some adaptation is made in the Blockchain data structure.

B. ARCHITECTURE
The design and its components aim at supporting PHR management through the employment of Fog computing VOLUME 9, 2021 architecture, where a local Fog layer is combined with Blockchain and IoHT technologies to suit better the requirements identified in the previous steps of research and literature review. Thus, Fog computing-based techniques are employed to ensure high availability and performance, and Blockchain-based strategies were used to provide the privacy and tamper-proof required in the healthcare domain.

1) IoHT LAYER
The first interaction with the IoHT devices is given through an internal component named IoHT++. It is responsible for exchanging messages and communicating with devices, providing some level of protocol interoperability by supporting various protocols and standards. IoHT devices are the points of contact with the physical world [9]. Devices belonging to a wireless sensor network are often limited in terms of computing capacity, storage, memory, and energy availability [35], and for this reason, usually the data is not stored in the devices themselves, but instead sent to the Fog layer. There, the middleware handles communication protocols known by the Health Things, including CoAP (Constrained Application Protocol), MQTT (Message Queuing Telemetry Transport), and HTTP (Hypertext Transfer Protocol).

2) FOG LAYER
The Fog layer is located between the IoHT devices and the Blockchain services. It comprises a solution based on Fog computing, where its technology is used for scaling solutions for Cloud computing, being able to provide storage and computation close to the end-user and edge devices [32]. Also, FogChain has mechanisms to provide further communication and interoperability capabilities for devices and being responsible for dealing with communication protocols, filtering and validating data collected, and finally, transacting with the Blockchain network through API.
The Fog layer of our model aims to run at the border of the Edge, consisting of a Fog computing enabled environment, where our proposed architecture dispose many of its features, as illustrated in Figure 3. It can be described as a middleware component providing microservices responsible for handling, filtering, and validating incoming data from edge devices, before process requests to be persisted in the Blockchain ledger.
The point of contact with the Edge devices is given through the IoHT++ microservice. Working as an entry-point, it is responsible for the communication protocols interoperability support, originated from the Nightbus (IoT++) project implementation [50] and to be available in all FogChain's instances. IoHT++ has two main internal components which are the middleware core and I/O boundaries. The first can be described as a message broker with general publish/subscribe capabilities. It divides messages into topics (categories of messages) and allows for multiple interested clients to both produce and consume messages from topics. Its implementation uses the Apache Kafka software platform, which is a distributed publish/subscribe messaging framework made available by the Apache Software Foundation [50].
Apache Kafka translates incoming client communication semantics into messages that are produced in the middleware core or consume messages from the core, communicating them to the clients. These boundaries are configured and executed in separate processes and were implemented by the original authors as services using the Clojure programming language, running on top of the Java Virtual Machine (JVM): MQTT Subscriber, MQTT Publisher, CoAP Server, CoAP Client, and HTTP Client.
Such communication protocols are supported to exchange information with IoHT devices, where its environment is usually heterogeneous, allowing devices to communicate in different protocols and channels, thus, aggregating some level of protocol interoperability necessary to our model. Whenever a new message successfully passes through the entry-point and is forwarded to the internal FogChain microservices, the incoming data is validated to prevent blank, null, or corrupted information. Moreover, a filtering function is applied, where it is possible to determine which information should be stored in the distributed ledger or to be discarded. For instance, if a wearable device is collecting multi-parametric values, this filtering function allows us to decide which parameters are essential and should be broadcasted to all peers of the Blockchain.

3) BLOCHCHAIN PEERS
The Blockchain peers are designed to be set in place over a consortium network for a more secure health information exchange (HIE) among participants and to improve clinical data availability near the Edge. In terms of data structure, the Blockchain can be configured to support storage and organization into existing data formats and open standards already established in the health sector, such as FHIR and openEHR. The IoHT devices' hardware usually is too restricted to actively contribute to the Blockchain network since consensus algorithms are complex and require large processing capacity and CPU storage capacity. To overcome these limitations, 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 to achieve consensus among existing peers.
This entire transaction workflow process helps to achieve consensus because all peers have reached an agreement on the order and content of transactions, in a process that is mediated by orderers. The consensus is a multi-step process and applications are only notified of ledger updates when the process is complete. FogChain employs the Hyperledger Fabric 7 framework to implement distributed ledgers. Hyperledger Fabric allows the development of Blockchain applications, and it is currently adopted by several solutions [51]. By employing this framework, FogChain inherits the Practical Byzantine Fault Tolerance (PBFT) algorithm to reach a consensus among all nodes. Studies demonstrate that this algorithm can achieve better performance compared to others [51]. The algorithm requires at least 3f + 1 nodes (n) to participate in the process, where f represents the number of faulty nodes, which can be achieved by f = n−1 3 . The process where participants (patients and physicians) join the network may be facilitated by the employment of smartphones interfacing with the FogChain and acting as a thin client to the network, for instance. This thin client is supported by the Hyperledger Fabric and represents the entity that acts on behalf of an end-user. It must connect to a peer to communicate with the Blockchain. The thin-client can connect to any peer of their choice and submit transaction proposals. Figure 4 depicts a front-end design concept to interface with FogChain back-end API and services, and are better described as follow: (a) A welcome screen for users (patients and physicians) permitting identification and authentication through their 7 https://www.hyperledger.org/use/fabric VOLUME 9, 2021 public keys and or QR code. It should allow new users to register (create wallet) and existing users to effectuate login on the platform; (b) Patients are allowed to visualize and manage their PHR fragments; (c) Each patient is responsible for whom they decide to share their health records, for example, by informing the physician id.

4) SMART CONTRACTS
Smart Contracts are self-executing programs and protocols stored in Blockchain that facilitate, verify, and guarantee the execution of a contract between members of the network. For example, a patient allows/authorizes a physician to visualize their medical history. These programs provide the ability to directly track and execute complex agreements between parties without human interaction [35].
In the healthcare scenario, smart contracts may be very useful, especially in cases where it is possible to define thresholds for collected data, thus, having smart contracts executed automatically in the background, which could help in the decision. For instance, in a scenario where a patient's heart rate exceeds the established limit, the smart contract could automatically trigger an event on the network notifying the physician of the existing risks.
Smart contracts may feature improvements in the interaction between patients and health providers, by automating and executing agreements predefined over the parties. For instance, evaluating healthcare information collected by IoHT devices, such as multi-parametric devices for vital signs, and comparing these readings with customized threshold values. It could trigger notification events or alerts for the patient itself or healthcare providers such as physicians and nurses when these thresholds exceed. This process provides many possibilities to extend the network and assisting interactions between patients and healthcare providers.

V. MATERIALS AND METHODS
This section describes an experimental evaluation methodology carried out to test FogChain. We highlight that this evaluation aims at developing and deploying a FogChain infrastructure in the laboratory, focusing on comparing FogChain to a traditional Cloud strategy. A multiorganization Blockchain network is in our scope, where each organization may represent a clinic or hospital for example, and each organization is allowed to have multiple Peers spread over its infrastructure, with each Peer encapsulated into a FogChain instance. To test the feasibility of the model, we managed to implement and benchmark the solution, aiming to evaluate not only application throughput but also the impact of a Fog computing environment to mitigate latency on the interaction between edge devices and the Blockchain network.
Backed by the Blockchain as a repository for the health records we created a Fog-enabled environment serving as a middleware. The core of our FogChain architecture is written in JavaScript language, supported by the Node.js runtime to be available in all FogChain instances and all programming can be seen in our code repository. 8 It features microservices to be run locally, providing surrounding services to easy communication with Edge devices while processing requests, filtering and validating data before sending it to the local Blockchain Peer.
Regarding the Blockchain to be used in our implementation, it is possible to state that currently there is a set of available frameworks. To find out which Blockchain platform suits the best for our model we did research based on our requirements and outcomes are presented in Table 2. The table compares potentially available platforms, thus identifying possible strengths and weaknesses in advance for our application model. For means of implementation, we have chosen the Hyperledger Fabric Blockchain distribution, which is a DLT solution, with an open-source license made available by The Linux Foundation, and is in line with our demand given its permission aspect, modularity, tool support, no-fee, and project maturity.
The Hyperledger project was designed for corporate and organizational architectures, with a set of customizable rules, allowing, for example, to operate with different consensus protocols, such as PBFT, Kafka, SOLO, among others. It differs from other Blockchain platforms because it focuses on the development of private and authorized networks, mainly suitable for organizations, rather than a public and open network. It does not allow unknown identities to participate, thus, allowing the location of medical records to remain secure and restricted to hospitals and clinics infrastructure. Hyperledger's Blockchain design does guarantee transaction's integrity by submitting them through three main stages of a workflow process: 1) Transaction Proposal: applications generate a transaction proposal which they send to each of the required set of peers for endorsement; 2) Ordering and packaging transactions into blocks: it receives transactions containing endorsed transaction proposal responses from many applications, and orders the transactions into blocks; 3) Validation and commit: involves the distribution and subsequent validation of blocks and transactions before they can be persisted to the ledger. Every transaction within a block must be validated to ensure that it is valid and has been consistently endorsed by consensus peers. To build this network, a set of tools were employed for the development of the network and its middleware, for example, the Hyperledger Composer, which is a collaboration tool, distributed by the Linux Foundation and built with JavaScript, including Node.js, NPM, and CLI. Figure 5 depicts the components used to implement the Fog Layer of the architecture. One of the first requirements to  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 definition and can be used to express information or knowledge. A Hyperledger Composer model file is usually composed of a single namespace with all resource declarations, and a set of resource definition syntax for assets, transactions, participants, and events. FogChain's Blockchain network is designed to have two main types of participants. Listing 1 presents their modeled interactions and attributes.

A. IMPLEMENTATION
On the one hand, the Patient entity represents any person receiving or registered to receive medical treatment. During his life, he may have many medical records entries. The Patient gets to choose with whom he shares his medical records, where only Physicians allowed by the Patient may see his medical history. On the other hand, the Physician entity represents any medicine practitioner working in the healthcare system. It may interact with the Patient's medical records if so the patient allows them. These two well-defined types of participants can only interact with each other through pre-defined transaction operations grantAccess and revokeAccess, where they exchange permission over the Medical Record asset. These two operations allow us to grant the patient full control over their PHR.
While designing the Blockchain's data structure to better scale and support the vast and varies amount of healthcare data, we came to the creation of an important feature to add 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 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 servers (off the chain) as per example the IPFS, a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files.
To establish boundaries among what participants can or cannot do, share, or access, the Hyperledger Composer provides an access control language (ACL) that provides declarative access control over the elements of the domain model. By defining ACL rules we can determine which users/roles are permitted to create, read, update or delete elements in a network's domain model. A code snippet presented in Listing 2 we do exemplify a few of our network rules built to protect participants' level of control over other participants and assets (health records).
Regarding the smart contracts on Hyperledger, it is also referred to as chain code in the Hyperledger Fabric documentation.

B. EVALUATION METRICS
Prototyping is a method that confronts users with a partially implemented model of a system intended to obtain quick feedback, for example, on its appearance and/or performance. It is especially useful when it is applied together with the benchmark method. The benchmark tests are used to evaluate the performance of information systems and to test their compliance with user requirements. In general, benchmarking is considered a systematic tool that allows, through metrics, to pursue and determine whether a process and or application is performing at its best. It allowed us to make improvements on the model and adapt specific components, usually to increase some aspect of performance, and is employed as a continuous process in which we continually seek performance improvements [17].
To obtain meaningful metrics to be monitored and assessed during our experiments and analysis, we employed the Goals, Questions, and Metrics (GQM) approach (see Figure 6). GQM is a software metric approach in software engineering that proposes steps for identifying correct metrics for the creation and maintenance of a software system and clarifying which variables are essential to take into account during simulations and test executions. It is carried by identifying a set of quality and productivity goals to improve system performance. From those goals and based upon models of the object of measurement and metrics, we derived questions that define those goals as completely as possible [7]. Given the GQM approach, we selected the latency and throughput metrics as the evaluation goal. Equations 1 and 2 define the Latency and TPS (Transactions Per Second) metrics, respectively. In Equation 1, t i request corresponds to the time a request i is sent and t i response is the time the response for this request i arrives. This particular equation computes Latency in milliseconds (ms). In turn, in Equation 2, TPS is achieved by dividing the total number of requests n by the total time (in seconds) taken to process all requests. We selected these metrics since they are commonly employed to evaluate the performance of Blockchain applications [51].

C. INFRASTRUCTURE AND CONFIGURATION
To evaluate the model and verify FogChain components' integration, we implemented and configured it on a local Fog environment, responsible for processing and storing medical data information locally. For means of testing, we collected data originated from a clinical vital signs dataset provided by ''The University of Queensland'' [29] institution. The local environment is composed of a physical server with Ubuntu 16.04 (64-bit) Operating System, Intel Xeon E5-2620v4 2.1GHz processor, 32GB RAM, and HDD SAS 600Gb RAID 5 (10,000 RPM). The Hyperledger Fabric Blockchain was installed and configured to run on containers in this physical machine as components of the FogChain. In particular, these containers share the physical machine resources, which makes them less powerful than the physical machine. As a consequence, these less powerful containers mimic Fog nodes which are characterized by having less computing power than physical servers. All libraries and dependencies were managed through Node.js and Node Package Manager (NPM), having all of our modeling and configurations in place, turning our network finally available for tests. The next step was writing an application that reads columns of the aforementioned vital signs dataset [29], such as the electrocardiogram (ECG) and blood pressure, having each record becoming a transaction proposal, to be validated and persisted on the ledger.
To compare our solution with a Cloud infrastructure, we configured a similar environment. Figure 7 depicts two infrastructures employed on the experiments. In this second environment, instead of running the application to input data into the Blockchain locally, the script is hosted in a virtual machine (VM) on the Cloud. We configured an Amazon Web Services VM with the vital signs dataset. The input application runs in the VM and sends requests to the Blockchain in our local infrastructure. This setup characterizes a Cloud environment because sensor data should use the Internet to reach the Blockchain. Given both local and Cloud infrastructures, we can compare them and show the results of employing FogChain.
At the end of the configuration stage, a Blockchain application was set in place with the Hyperledger Fabric Blockchain to store and manage PHR in a Fog environment. This preparation 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 different evaluation scenarios to compare it with Cloud solutions 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 not.
In the second phase, three scenarios were modeled varying the batch size and the number of concurrent sessions. Table 3 presents the parameters employed in each scenario. For each scenario, the total number of requests is equal to 10,000 per session. The evaluation comprises the execution of each scenario ten times. Thus, TPS is achieved by averaging the results of the ten executions. For instance, let the total requests be 10,000, the average of ten executions be 100s, then TPS = 10,000 100 , resulting in 100 TPS. Finally, the third phase consists of comparing both FogChain to Cloud solutions. Therefore, we executed the same scenario in each infrastructure to compare the average latency in each one. More specifically, the scenario comprises 10 executions of the application sending a batch of 50 samples to the Blockchain in each infrastructure presented in Figure 7. Results are obtained by averaging the latency of the ten executions.

VI. RESULTS AND DISCUSSION
In this section we are going to demonstrate all results obtained during the research and development of our model implementation, carried simulations, and benchmarks.

A. BATCH SIZE EVALUATION
Determined to check how long it would take for a single transaction to complete under our Fog computing environment, we executed an initial test using the add operation from the Hyperledger Composer API, which expects only a single asset as an input parameter. It resulted in an average Latency of 180ms for a transaction to be created, ordered, validated, and ultimately persisted in the ledger, which if executed multiple times sequentially would lead to approximately 5 TPS as throughput.
Seeking performance improvements, transactions were organized in bulks (batches) to verify a possible increase of throughput and for that, instead of sending transactions one by one sequentially, we employed the addAll operation, which expects as an input parameter an array of assets, in our case, an array of vital signs readings. In other words, the interaction with our Blockchain network was changed to work in batches and the tricky part is to find an optimum batch size. This process implies our FogChain solution to accumulate data and organize them in an array structure before sending them to the Blockchain. Figure 8 depicts the TPS achieved when employing different batch sizes, as described in Section V-D.
According to the figure, performance degradation was noticed while working with larger batch sizes. For example, a batch with 1,000 transactions would take approximately 23 seconds to complete, with a low average of 43 TPS, while a smaller batch with half transactions (500) would take only six seconds. It was the first indication that our optimum batch size was likely to be a smaller number. Table 4 shows the obtained results for each evaluation scenario. The Light load achieved the best results for all metrics compared to the other two. In this particular scenario, the total number of requests is lower than the Medium and Heavy loads. Thus, it requires less CPU and Memory to compute all transactions. As a consequence, both TPS and Latency achieved the best results. On the other hand, as the scenarios Medium and Load have more requests to compute, their final results increase according to it. For instance, the Medium load achieved higher results than the Light, and the Heavy achieved even higher.

B. ANALYSIS OF DIFFERENT SCENARIOS
For all scenarios, the batch size is equal, however, they achieve different TPS. The Light load obtained similar TPS to the tests performed to evaluate the batch size previously (see Figure 8). However, the same is not true for the Medium and Heavy scenarios. The results demonstrate that, even with the optimal batch size, the TPS is impacted according to the number of concurrent sessions. That imposes concurrency on processing requests, which decreases the final TPS.

C. FOGCHAIN VS CLOUD
The third phase of our experiments aims at evaluating the impact on Latency when employing FogChain versus the employment of a Cloud environment. Figure 9 depicts the difference between the two infrastructures result from the experiments. FogChain ach2ieves a Latency 62.6% smaller when compared to the Cloud environment. As the data and software components involved in running the experiments are the same, we conclude that the main reason for such a difference is the latency introduced by the Internet connection.
As depicted in Section 7, all software and data components are the same in both infrastructures. The only thing that changes from one setup to the other is the location where the input data is. When employing a Cloud environment, the data should be forwarded to the system through the internet connection, which may route data traffic in different paths depending on the Internet providers. On the other hand, when employing FogChain, the Blockchain infrastructure is closer to the data source. That avoids delays imposed by routing protocols from public internet providers, thus, improving the results.

D. DISCUSSION
FogChain focuses on employing Fog Computing to bring Blockchain closer to PHR IoT devices. The main goal is to decrease response time on registering records in the Blockchain, making them available quicker. This strategy makes the solution independent from Cloud infrastructures. At the same time, as it employs several Fog nodes, the infrastructure can be easily scaled by adding more nodes with Blockchain peers. Despite that, the evaluation we employ focuses on proving the performance improvement in response time for application. The implemented evaluation demonstrated the capacity of our architecture as a technology integrator, providing an alternative to traditional Cloud-IoT solutions, and the obtained results for latency and throughput metrics did highlight the performance boost driven by the Fog computing adoption.
Having a complete patient's medical history available in loco turns to be an intangible benefit for the healthcare domain, leaving the solution with no external dependencies such as ISP and or services, which is in contrast, for example, with previous models assessed in the related work section. The FogChain implementation for PHR management demonstrated a slice of how Blockchain could be employed in the healthcare domain, benefiting from its cryptography and tamper-proof nature, which adds a security layer so necessary for healthcare applications. However, the FogChain model is not limited to the healthcare domain only and could be also adapted to other domains, for example, supply chain, smartcity, and cross-industry applications.
Moreover, working with batches of transactions demonstrated to be favorable, and with this approach in place, we managed to obtain a satisfactory application throughput. It resulted in performance improvements on TPS capacity of our architecture and combined with the local Fog computing benefits, promoted closer to real-time features on the process of vital signs' collecting, securing, and storage. As bandwidth measures how much data can flow through a specific connection at one time, it turns out it strongly relies on the physical hardware used in the experiment. For instance, a gigabit Ethernet connection has a bandwidth of 1,000 Mbps, while the Fast Ethernet compliant network may transfers data at rates up to 100 Mbps. Thus, considering the local nature of the Fog, its bandwidth relies on the local infrastructure itself while the Internet Service Providers (ISP) restrain it in cloud-like environments. More specifically, in our scenario, the patient's wearable sensors usually collect and transfer raw data, which are typically lightweight, not consuming extensive network bandwidth. However, the more the sensors evolve, the more they need larger bandwidth on the network.
It is safe to say that Fog computing can play a big role in healthcare applications, providing local processing power, services, and increasing resources availability. It allows applications to decrease the amount of access to the cloud, where the connection is subject to delays on worldwide network traffic, turning to be a viable and potential integrator of IoHT and Blockchain technologies. The current state-of-the-art focuses on providing Blockchain solutions for healthcare with Cloud computing support. Therefore, it inherits the latency of network connections to reach Cloud infrastructures. In this context, FogChain aims at bringing the Blockchain infrastructure closer to the healthcare environment decreasing latency for its operations. Its main contribution relies on a Fog infrastructure encompassing Blockchain peers for validation of PHR operations.
The need for more investment and efforts to consolidate open standards for health records data structure has become clear and yet challenging, improving its levels of interoperability among health providers could end up easing the Blockchain adoption from the healthcare industry players. Furthermore, our model itself does not solve the intrinsic interoperability issues regarding different data formats between health providers, which are a broader concern in the healthcare area. Another important variable that must be taken into account when considering the Blockchain solution is the scalability constraints in terms of the trade-off between the volume of transactions and computer power for processing time of transactions.

VII. CONCLUSION
The implementation's evaluation demonstrated satisfactory proofs regarding the feasibility of FogChain architecture and the combination of its components. A possible future direction to this research could be carrying tests in clinics and hospitals scenario. Some challenges were identified during our research and development process, such as technological limitations, industry adoption, infrastructure costs, among others. Furthermore, currently available frameworks may not have full compliance with the healthcare regulatory organizations such as HIPAA and GDPR. For example, in a scenario where a patient has the right to be forgotten, requiring the entire deletion of their stored health data in the network, which would clash directly with the immutability principle of Blockchain solutions.
Finally, our solution has some limitations that can be addressed in future work. First, the Fog infrastructure we employ is based on a single server running containers. The ideal setup can consider employing less powerful nodes distributed physically instead of virtualized ones in the same VOLUME 9, 2021 physical machine. In addition, the evaluation does not consider scenarios with different nodes available, which would be required to assess the scalability of the solution. Second, we developed a single application to extract data from a dataset and input it into the system. Further research should be done employing real-time critical applications instead. Third, the evaluation focuses mainly few parameters and metrics, which future experiments can explore further. Finally, another point of attention is on the evaluation scenarios. We do suggest adding more participants and roles to the network, for example, allowing insurance companies to join the network, moreover, proposing and implementing interoperability features for the PHR storage, regarding data format and transaction block structures.

DECLARATION OF COMPETING INTEREST
The authors declare that there is ''No Conflict of Interest'' in the current manuscript.