Journal:Blockchain-based healthcare workflow for IoT-connected laboratories in federated hospital clouds

From LIMSWiki
Jump to navigationJump to search
Full article title Blockchain-based healthcare workflow for IoT-connected laboratories in federated hospital clouds
Journal Sensors
Author(s) Celesti, Antonio; Ruggeri, Armando; Fazio, Maria; Galletta, Antonino; Villari, Massimo; Romano, Agata
Author affiliation(s) University of Messina, INdAM-GNCS, IRCCS Centro Neurolesi Bonino Pulejo, ASP Messina
Primary contact Email: acelesti at unime dot it
Year published 2020
Volume and issue 20(9)
Article # 2590
DOI 10.3390/s20092590
ISSN 1424-8220
Distribution license Creative Commons Attribution 4.0 International
Download (PDF)


In a pandemic-related situation such as that caused by the SARS-CoV-2 virus, the need for telemedicine and other distanced services becomes dramatically fundamental to reducing the movement of patients, and by extension reducing the risk of infection in healthcare settings. One potential avenue for achieving this is through leveraging cloud computing and internet of things (IoT) technologies. This paper proposes an IoT-connected laboratory service where clinical exams are performed on patients directly in a hospital by technicians through the use of IoT medical diagnostic devices, with results automatically being sent via the hospital's cloud to doctors of federated hospitals for validation and/or consultation. In particular, we discuss a distributed scenario where nurses, technicians, and medical doctors belonging to different hospitals cooperate through their federated hospital clouds to form a virtual health team able to carry out a healthcare workflow in secure fashion by leveraging the intrinsic security features of blockchain technology. In particular, both public and hybrid blockchain scenarios are discussed and assessed using the Ethereum platform.

Keywords: blockchain, smart contract, workflow, healthcare, hospital, cloud computing, IoT, data federation


Recent advancements in information and communication technology have paved the way toward new innovative telemedicine and other remote healthcare services, which are able to support the growing demand of even more accessible medical treatments.[1][2] Particularly, during a pandemic-related situation such as that caused by the SARS-CoV-2 virus, the need for these types of remote services becomes dramatically fundamental to reducing the movement of patients, and by extension reducing the risk of infection in healthcare settings. However, the recent innovation propogated by the cloud computing and internet of things (IoT) paradigms has been only partially taken into consideration by hospitals and, more generally, by medical centers so far. A crucial aspect that has slowed down wider adoption of these and other information and communication technology paradigms in hospitals is concern about the integrity, security, and privacy of exchanged data. Particularly within the healthcare domain, it is critical that shared clinical data be transmitted securely to prevent intentional or accidental illegal data manipulation. Furthermore, patients’ privacy must be guaranteed.

In recent years, cloud computing and IoT paradigms, along with the concept of data federation, have been combined to form new technological approaches. One such approach is the concept of a federated cloud infrastructure, defined as a mesh of cloud providers that are interconnected to provide a universal decentralized computing environment where everything is driven by constraints and agreements in a ubiquitous, multi-provider infrastructure.[3] With the advent of IoT, an IoT-driven cloud paradim has also arisen. In this case, a set of smart embedded devices are interconnected with a remote cloud infrastructure, platform, or software into an internet-connected distributed system able to provide IoT as a service (IoTaaS). The natural evolution of this IoT-driven cloud concept was a federated ecosystem composed of small, medium, and large IoT-driven cloud providers able to collaborate in order to gain economies of scale and to enlarge their processing, storage, network, sensing, and actuating capabilities to arrange even more flexible IoTaaS.[4] The healthcare domain can benefit from these paradigms to improve clinical services and push down management costs through the creation of hospital IoT clouds[5] able to federate themselves.

In this paper, we focus on the medical laboratory as a case study. We examine the applied science laboratory, typically placed in a hospital or in a clinical center where clinical pathology exams are carried out on clinical samples to obtain information about the health of a patient to diagnose, treat, and prevent diseases. Blood tests (e.g., complete blood count [CBC], blood sugar, and so on) are performed by biomedical laboratory health technicians directly in the clinical laboratory, and results are validated and analyzed by doctors to guide diagnosis and treatment. More specifically, we examine these hospital labs under the emerging context of the IoT-connected laboratory operating in a federated cloud. In the case of these laboratories, clinical exams are performed on patients directly in a hospital by technicians who use IoT-enabled medical diagnostic devices integrated into the hospital's cloud system, with results automatically being sent via the hospital's cloud to doctors of federated hospitals for validation and/or consultation. Biomedical laboratory health technicians, nurses, doctors and other clinical personnel belonging to different hospitals cooperate through their federated hospital clouds (FHCs) to form a virtual health team able to carry out a healthcare workflow.

However, one of the major concerns about the accomplishment of such a workflow regards how to guarantee the non-repudiation and immutability of all health decisions.[6] In recent years, different solutions have been proposed to solve such an issue; among solutions is the option of using blockchain technology. Thanks to its intrinsic features of data non-repudiation and immutability, blockchain has aroused significant interest in both scientific and industrial communities. One of the major applications of blockchain is through the smart contract, i.e., a computer protocol aimed to digitally facilitate, verify, and enforce the negotiation of an agreement between subjects without the need of a certifying third party. Blockchain has been increasingly recognized as a technology able to address existing information access problems in different application domains, including healthcare. In fact, it can potentially enhance the perception of safety around medical operators, improving access to hospital cloud services that are guaranteed by greater transparency, security, privacy, traceability, and efficiency. In the scope of IoT-connected laboratories running in the cloud, smart contracts can make the transactions related to such a healthcare workflow traceable and irreversible.

Specifically, this paper proposes an architecture blueprint and a system prototype of an FHC service that addresses the healthcare workflow of an IoT-connected laboratory operating in the cloud. A special emphasis is given to blockchain, comparing both public and hybrid cloud network scenarios using the Ethereum platform to assess both processing time and economic cost. In particular, addressing the latter is vital as the Ethereum public network platform, available over the internet, requires that users (in our case, federated hospitals) pay a fee to perform each transaction.

The remainder of this paper is organized as follows. A brief overview of most recent initiatives about the adoption of blockchain in healthcare is provided in the next section. Motivations for pursuing an IoT-connected cloud approach are discussed in the subsequent section. A blueprint of FHC architecture is then presented, followed by a description of one of its possible implementations. Experiments specifically focusing on blockchain comparing public and hybrid cloud network scenarios are discussed in the penultimate section. The paper ends with conclusions and promising future developments.

Related work

Recently, the role of blockchain technology in the healthcare domain has been surveyed in a number of scientific works.[7][8][9][10][11] More specifically, some works have demonstrated that blockchain can drastically improve the security of hospital information systems (HIS).[12][13][14][15] However, up to now, most of these scientific initiatives are either theoretical or at an early stage, and it is not always made clear which protocols and pieces of a framework should be used to carry out system implementations that can be deployed in real healthcare environments.

Blockchain has been increasingly recognized as a tool able to address existing open information access issues.[16] In fact, it is possible to improve access to health services by using blockchain to achieve greater transparency, security, privacy, traceability, and efficiency. One such example can be found in the work of Ramani et al.[17], who describe a solution adopting blockchain with the purpose to guarantee authorized access to patients’ medical information. In particular, mechanisms able to preserve both patient’s identity and the integrity of their clinical history are proposed.[17] Another application of blockchain regards the supply chain in the pharmaceutical sector and the development of measures against counterfeit drugs. While the development of new drugs involves substantial costs related to studies to evaluate the safety and efficacy of the drug, the use of smart contracts guarantees informed consent procedures and allows for certifying the quality of the study data.[18] In another work, Shen et al.[19] propose an efficient data-sharing scheme called MedChain, which combines blockchain, digest chain, and structured P2P network techniques to overcome the efficiency issues in healthcare data sharing. Experiments with the system show that work can be performed with higher efficiency, while at the same time satisfying the security requirements of data sharing. Khatoon[20] examines different medical workflows which have been designed and implemented using the Ethereum blockchain platform, which involves complex medical procedures like surgery and clinical trials. In particular, Khatoon examines the smart contract system for healthcare management and estimates the associated costs in terms of feasibility. And finally, Satamraju[21] discusses a framework that integrates IoT networks with a blockchain to address potential privacy and security risks for data integrity in healthcare. In that work, a medical IoT device represented by a Raspberry Pi 3 Model B+ is attached to the patient’s body to monitor their vitals, which are stored in an off-chain database that is accessed by the doctor, pharmacy, and insurance company via a DApp. All transactions take place utilizing smart contracts in a permissioned blockchain system implemented over Ethereum.

Differently from the aforementioned scientific initiatives—which are mainly based on a public blockchain network approach—this paper focuses on how a hybrid blockchain network approach (mixing both public and private) can be used to carry out the healthcare workflow of an IoT-connected laboratory running in a federated hospital cloud environment. Moreover, we demonstrate that our blockchain hybrid network approach reduces the number of required transactions while enhancing processing time and reducing economic cost.


In this section, after a brief overview of recent advances in diagnostic laboratory devices, we discuss the advantages of an IoT-connected cloud approach.

Recent advancements in diagnostic laboratory devices

A diagnostic laboratory device is defined here as medical equipment able to perform several blood tests, including a CBC, basic metabolic panel, complete metabolic panel, lipid panel, thyroid panel, enzyme markers, sexually transmitted infection tests, coagulation panel. and DHEA-sulfate serum test. Currently, there are many diagnostic laboratory devices available on the market, and they can be classified as “connected” and “non-connected.” Connected diagnostic laboratory devices have USB and network (wired and/or wireless) interfaces and are able to export and send results to other devices. Non-connected diagnostic laboratory devices have no such interface for data transmission.

We provide a brief overview of the major connected diagnostic laboratory devices that are based on future IoT-connected laboratory services. The TeleMedCare Clinical Monitoring Unit (CMU)[22] is a medical device able to perform blood pressure, pulse oximetry, and blood glucose exams. Eversense[23] is a device able to perform continuous glucose monitoring via a chip that is installed subcutaneously on the patient and accessed with a mobile app. Med-Care[24] is an integrated solution for the automatic monitoring of glycemia that works with both web and mobile systems, and that can send alerts via email or SMS. HemoScreen[25] is a low-cost portable haematology analyzer which performs a complete blood count at the point of care, with results shown on a local web interface. The Samsung Labgeo PT10S[26] is a portable clinical chemistry analyzer that improves efficiency by saving time for clinicians and patients through fast, easy, and accurate blood analysis. It includes an ethernet interface for exporting exam result to an external personal computer (PC). It's worth noting that all the aforementioned devices require a blood sample in order to perform exams. However, alternative non-invasive experimental devices able to perform blood tests are the topic of ongoing study for both academic and industrial healthcare communities.

Towards IoT-connected laboratories

An IoT-connected laboratory allows blood exams, results validation, diagnosis, and therapy assignment tasks to be performed in departments located in different hospitals. This is possible utilizing the creation of a virtual healthcare team composed of biomedical laboratory health technicians and doctors belonging to different federated hospitals. Cooperation is possible through the hospitals' FHCs. Hospital federation can involve several satellite clinics belonging either to the same healthcare organization or to different ones. An example of a healthcare organization that incorporates different hospitals is the provincial healthcare organization of Messina (Italy), also referred to as ASP Messina. As shown in Figure 1, it boasts eight health districts, including, Messina, Taromina, Milazzo, Lipari, Barcellona Pozzo di Gotto, Mistretta, and Sant’Agata di Militello.

The health district of Lipari is located on the island of Lipari and provides a limited number of health services. It offers medical assistance to patients using an emergency room and a clinical pathology laboratory. Due to the limited number of health departments, patients with particular diseases are typically transferred to the nearby health districts of Milazzo or Barcellona Pozzo di Gotto (indeed by helicopter for urgent cases) if required. In this scenario, an IoT-connected laboratory service running on the cloud could improve clinical workflow by involving a virtual healthcare team, including technicians and doctors belonging, for example, to the Lipari, Milazzo, and Barcellona Pozzo di Gotto districts. In particular, blood tests could be performed by biomedical laboratory health technicians in the clinical pathology laboratory of Lipari, and results could be transmitted using the FHC ecosystem to a doctor of the Barcellona Pozzo di Gotto district for validation. Furthermore, leveraging the FHC environment, an additional consultation could be done with a doctor of the Milazzo district.

Fig1 Celesti Sensors20 20-9.png

Figure 1. Federation of hospitals: clinical data is shared across participants for cooperation.

Using the term “home hospital” to define the hospital that is physically reached by the patient, the generic healthcare workflow accomplishing the aforementioned scenario implies the following phases:

1. Hospitalization: Patient reaches a home hospital. Personal details, date, and type of visit are recorded. The patient is identified by a visit identification code. A doctor schedules all exams required to verify the nature of the disease. A virtual healthcare team is created involving technicians, nurses, and doctors belonging to the home hospital and other federated hospitals.

2. Clinical Analysis: If required, a nurse of the home hospital takes a blood sample from the patient. A biomedical laboratory health technician of the home hospital performs blood tests, and results are saved by IoT medical devices automatically or by the technician manually on the FHC storage in a dedicated patient’s directory.

3. Validation: A doctor belonging to another federated hospital analyzes and validates the results of clinical analysis.

4. Consultation: A selected pool of doctors belonging to the virtual healthcare team establish a teleconference to clarify the patient’s clinical situation. The patient’s health data and clinical analysis are shared among doctors, while still protecting sensitive data.

5. Monitoring: The hospitalized patient is constantly monitored by nurses, who apply treatments based on therapeutic indications. Each treatment is recorded until the patient is released.

Non-repudiation and immutability of all health decisions is a fundamental concern that must be addressed for the accomplishment of such a healthcare workflow. In this regard, the blockchain technology using smart contracts can make all transactions related to the healthcare workflow traceable and irreversible. In the remainder of this paper, we will focus on such an aspect.

System design

It is important to guarantee that only authorized members of the virtual healthcare team are allowed to take actions; a wrong decision can lead to a worsening of clinical condition or the death of a patient. herefore, the FHC system has to guarantee that all actions performed by virtual healthcare team members are traceable and irreversible. To achieve such a goal, the following technologies are fundamental:

  • Blockchain engine: To use the features of a decentralized and distributed certification system with the technology offered by the development and coding of a smart contract
  • Cloud storage: To use an open-source and open-architecture file hosting service for file sharing managed with authorizations to archive all the files required to support the analytical testing of disease causes, including blood tests, computed tomography (CT) scans, and other laboratory tests
  • NoSQL database: To exploit the potential of a document-oriented distributed database able to store and manage patient’s data and diseases through tags for fast and efficient searching, and to store blockchain transaction hashes and links to files stored in cloud storage

Figure 2 describes the FHC architecture. The system entry point of each hospital cloud is a dedicated Web Server Gateway Interface (WSGI) where pieces of electronic healthcare data are created manually by the clinical personnel or automatically collected by IoT devices that can be spread over different federated hospitals.

Fig2 Celesti Sensors20 20-9.png

Figure 2. IoT-connected federated hospital cloud (FHC) architecture

A Data Anonymization Module (DAM) is responsible for hiding the patient’s personal data in electronic health records (EHRs). This is possible by decoupling the patient’s personal data from EHRs storing related pieces of information in different databases. To bind the EHR with the patient, a patient’s anonymized identification number (patient_id) is generated from the DAM and stored within the EHR. Thus, only EHRs are shared between FHCs, whereas pieces of patients’ personal data are never shared to preserve their privacy. All the produced clinical documentation, including EHR data, is uploaded to cloud storage with a patient_id to hide patient’s data. A blockchain engine is responsible for storing information on the blockchain to certify data non-repudiation and immutability of treatment details guaranteeing accountability and authenticity. The transaction hash resulting from the mining process is stored in the NoSQL document-oriented database as an attribute of the treatment. A local database instance containing both patient and hospital personnel data is isolated from other federated hospitals because that information never needs to be shared. Treatments’ details are anonymized and stored in a database shared with other participants in the FHC environment. The whole architecture is deployed using container virtualization to simplify installation, configuration, and maintenance in each FHC.

Hospitals belonging to a federation cooperate, ensuring that appropriate therapies and procedures are carried out. Figure 3 shows the sequence diagram describing an example of healthcare workflow, including three federated hospitals and where an IoT-connected laboratory service is provided. A generic patient who requires a medical visit reaches the emergency room of a home hospital that after evaluating the urgency of the case, identifies an available doctor. The patient is visited by the assigned doctor, who prescribes some sort of analytical testing such as blood tests, which can be done in the home hospital medical laboratory by a biomedical laboratory health technician. If the doctor responsible for the medical laboratory is not available (as with small hospital districts), a doctor belonging to the federated hospital (1) validates the results shared via federated cloud storage. Thence, such a doctor joins the virtual healthcare team, along with involved medical personnel of the home hospital. Should the doctor of the home hospital have a doubt about the therapy to prescribe, they can consult a doctor of a federated hospital (2) via teleconference. After this consultation, a therapy is assigned to the patient.

Fig3 Celesti Sensors20 20-9.png

Figure 3. Sequence diagram describing an example of healthcare workflow accomplished in a FCH environment

System prototype

The FHC architecture was designed to enable a virtual healthcare team to carry out every healthcare workflow, such as that described in the previous Section. Figure 4 shows the main software components of a possible system prototype implementation.

Fig4 Celesti Sensors20 20-9.png

Figure 4. Hospital cloud software components

All requests coming from patients, nurses, technicians, and doctors flow through the WSGI interface developed with the Python web application framework Flask and deployed on the Gunicorn Python WSGI HTTP server. All the components are configured as Docker containers to take advantage of virtualization technology, allowing service portability, resiliency, and automatic updates that are typical of cloud-based infrastructure as a service (IaaS). The WSGI provides a front-end that allows retrieving all existing patients’ information (such as personal details, disease and pharmaceutic codes, links to clinical documentation, and blockchain hash verification), adding new patients, and submiting new treatments specifying all the required pieces of information. Specifically, a web page is dedicated to the registration of a new patient for saving their primary personal information, and another web page is dedicated to the registration of a new treatment. It is possible to select the medical examination date, patient, and doctor who does the registration.

All the produced clinical documentation is uploaded in a local instance of NextCloud storage using a folder for each treatment, which does not contain any patient’s personal data but rather a patient’s anonymized identification number. Every change in the files or content of the folder is tracked, making it possible to keep a history of the documentation and its modifications. Recently, a few related works were published for data anonymization in a multicloud storage healthcare environment; however, these do not guarantee that pieces of data are traceable and irreversible.[27][28] Since patients’ sensitive data must be anonymized and health records and treatments must be traceable and irreversible, related pieces of information are stored combining a MongoDB NoSQL database management system (DBMS) with the Ethereum blockchain platform. Therefore, all pieces of information are stored in both MongoDB and in the Ethereum network through smart contracts developed in Solidity. For experimental purposes (that will be discussed later), the Ethereum network was implemented in both public and hybrid configurations. In the first case, all FHCs share the public Ethereum network available over the internet, whereas, in the second case each FHC hosts a private Ethereum network to store local transactions and a public Ethereum network to synchronize the local transactions performed in each FHC.

The smart contract accepts the input parameters such as anonymized patient id and doctor id, disease, and pharmaceutic codes and stores these pieces of information in a simple data structure. The hash code resulting from the mining of each transaction is stored in the MongoDB database and can be used for verification using services like

This service is capable of detecting any modification that occurred to files or a folder using a listener called External script. It is then possible to store the fingerprint and timestamp of each modification in the database, thus making it possible to track the history of each treatment. This feature is important to guarantee data integrity.


Currently, the most adopted blockchain configuration is based on a public network approach. As such, Ethereum is one of the major blockchain platforms. A public Ethereum instance is available over the internet and requires the payment of a fee for the execution of each transaction. However, the Ethereum platform can be also downloaded and installed in a private network. In this paper, using Ethereum, the objective of our experiments was to verify if the blockchain system of an FHC ecosystem including an IoT-connected laboratory service can be optimized in terms of both processing time and economic cost using the proposed hybrid network approach. Apart from processing time, it is important to highlight that considering the Ether (ETH) cryptocoin concurrency used in Ethereum, a small saving of ETH can result in putting aside a relevant amount of money (e.g., USD or EUR) in just a few months. In the following, we provide a description of both considered approaches.

  • Ethereum public network: Each healthcare treatment is recorded in the public Ethereum blockchain network where time-to-mine and cost are subject to Ethereum network traffic (depending on the queue size, more time is required to extract transaction data, meaning higher costs for transaction management).
  • Ethereum hybrid network: Each healthcare treatment is recorded in a private instance of an Ethereum blockchain network consisting of at least one node for each FHC and only one hash code, calculated as the MD5 of the last 100 concatenated treatments’ transaction hash, and written in the public Ethereum blockchain network. In case the number of daily treatments is less than 100, the MD5 hash code is calculated as the concatenation of the last 24 hours' treatment transactions hash. The result of this is a negligible waiting queue and ETH cost but, on the other hand, there is a reduction of the mining power as a reduced number of miners are present in the private network as compared to the public one.

System assessment was conducted analyzing the total execution time required to perform a varying number of transactions in healthcare workflows. Each FHC was simulated considering a server with following hardware/software configuration: Intel Xeon E3-12xx v2 @ 2.7GHz, 4 core CPU, 4 GB RAM running Ubuntu Server 18.04. Each test was repeated 30 times considering 95% confidence intervals, and the average results were plotted. Table 1 summarizes experiment setup and average outcomes.

Table 1. Summary of experiments performed
Parameter Value
Number of transactions tested [1; 100; 1000]
Test executed for each run 30
Confidence interval 95%
Gas price (Gwei) 2
Average cost per transaction (ETH) 0.0002
Average mining time (s) 130

Figure 5 shows the time-to-mine difference expressed in seconds between the two approaches, considering new treatment registration requests. On the x-axis we reported the number of treatment registration requests, whereas on the y-axis we reported the processing time expressed in seconds. Looking at the graph, we can observe that for roughly 80 treatment registration requests, both configurations present a similar trend, whereas by increasing the number of requests, the hybrid Ethereum network shows better performances than the public one thanks to the reduced waiting time in the mining queue.

Fig5 Celesti Sensors20 20-9.png

Figure 5. Time comparison for public and hybrid Ethereum network approaches considering a varying number of treatment registration requests

Figure 6 describes a cost comparison in Ether (ETH) for the two approaches. On the x-axis we reported the number of treatment registration requests, whereas on the y-axis we reported the cost expressed in Ether (ETH). From our tests, we appreciated that the average cost of a single transaction (i.e., a simple smart contract representing a new treatment memorization or modification) that has to be written in the public Ethereum blockchain is roughly 0.0002 ETH. It can be noted that for a small number of transactions there is not a perceptible convenience in preferring the proposed hybrid approach. This is because at least one transaction per day is written in the public Ethereum blockchain. However, it is clear that cost savings increases exponentially, increasing the number of transactions because only one public transaction out of every 100 private treatments will be paid with ETH cryptocurrency, resulting in an important cost-saving for the FHC ecosystem.

Fig6 Celesti Sensors20 20-9.png

Figure 6. Cost comparison for public and hybrid Ethereum network approaches

Test results demonstrate how the Ethereum hybrid network approach can be adopted to improve both processing time and cost savings, maintaining the same level of accountability and data certification as the public approach through certification on blockchain.

Conclusions and future work

This paper demonstrated how an IoT-connected laboratory service can be developed through a healthcare workflow running in an federated hospital cloud environment leveraging blockchain. Experimental results highlight that the performance of the Ethereum hybrid network certification system is improved in terms of cost and response time compared to an alternative public approach.

Without a doubt, blockchain technology is destined to evolve, improving system capabilities and robustness, and public test instances with different consensus protocols will be made available with benefits on performance and scalability.

In a pandemic-related situation such as that currently caused by the SARS-CoV-2 virus, the need for IoT-connected, cloud-based laboratory services becomes dramatically fundamental to reducing the movement of patients, and by extension reducing the risk of infection in healthcare settings. We hope that with this paper, we succeeded in stimulating the attention of both academic and industrial communities toward the adoption of Blockchain in the healthcare context to speed up the development of innovative services.

In the future, this work can be extended by integrating a comprehensive healthcare scenario with different involved organizations, such as a pharmaceutical company that registers in the blockchain all the phases of drug production, all the way to final packaging and shipment. In this case, when a patient buys a prescribed medicine, it would be possible to link the patient with the medicine box, which would mean an important step towards the end of falsified pharmaceuticals and an important assurance for the end user, who can be identified in case a specific drug package has been recalled.


Author contributions

Conceptualization, A.C., M.F., M.V., A.R. (Agata Romano); Methodology, A.R. (Armando Ruggeri), A.G.; Software; Validation, A.R. (Armando Ruggeri), A.G.; Formal Analysis A.R. (Armando Ruggeri); Investigation, A.C., M.F., M.V.; Resources, A.R. (Agata Romano), A.R. (Armando Ruggeri); Data Curation A.R. (Armando Ruggeri); Writing—Original Draft Preparation A.C., A.R. (Agata Romano), A.R. (Armando Ruggeri); Writing—Review & Editing, A.C., A.R. (Armando Ruggeri), M.F., M.V., A.R. (Agata Romano); Visualization, A.R. (Armando Ruggeri), A.G.; Supervision, A.C., M.V.; Project Administration, A.C., M.V.; Funding Acquisition, A.C., M.V. All authors have read and agreed to the published version of the manuscript.


This research was funded by the Italian PON project “TALISMAN,” grant ARS01_01116 and by the Italian Healthcare Ministry Young Researcher project “Do Severe acquired brain injury patients benefit from Telerehabilitation? A Cost-effectiveness analysis study,” grant GR-2016-02361306.

Conflict of interest

The authors declare no conflict of interest.


  1. Hassenteufel, P.; Schweyer, F.-X.; Gerlinger, T. et al. (2020). "The role of professional groups in policy change: Physician's organizations and the issue of local medical provision shortages in France and Germany". European Policy Analysis 6 (1): 38–57. doi:10.1002/epa2.1073. 
  2. Dubas-Jakóbczyk, K.; Domagała, A.; Mikos, M. (2019). "Impact of the doctor deficit on hospital management in Poland: A mixed-method study". International Journal of Health Planning and Management 34 (1): 187-195. doi:10.1002/hpm.2612. PMID 30132977. 
  3. Moreno-Vozmediano, R.; Huedo, E.; Llorente, I.M. et al. (2015). "BEACON: A Cloud Network Federation Framework". Proceedings of ESOCC 2015: Advances in Service-Oriented and Cloud Computing: 325–37. doi:10.1007/978-3-319-33313-7_25. 
  4. Celesti, A.; Fazio, M.; Giacobbe, M. et al. (2016). "Characterizing Cloud Federation in IoT". Proceedings of the 30th International Conference on Advanced Information Networking and Applications Workshops: 93–98. doi:10.1109/WAINA.2016.152. 
  5. Mulfari, D.; Celesti, A.; Puliafito, A. et al. (2013). "How cloud computing can support on-demand assistive services". Proceedings of the 10th International Cross-Disciplinary Conference on Web Accessibility: 1–4. doi:10.1145/2461121.2461140. 
  6. Lian, J-W.; Yen, D.C.; Wang, Y.-T. (2014). "An exploratory study to understand the critical factors affecting the decision to adopt cloud computing in Taiwan hospital". International Journal of Information Management 34 (1): 28–36. doi:10.1016/j.ijinfomgt.2013.09.004. 
  7. Griggs, K.N.; Ossipova, O.; Kohlios, C.P. et al.. "Healthcare Blockchain System Using Smart Contracts for Secure Automated Remote Patient Monitoring". Journal of Medical Systems 42 (7): 130. doi:10.1007/s10916-018-0982-x. PMID 29876661. 
  8. Zubaydi, H.D.; Chong, Y.-W.; Ko, K. et al.. "A Review on the Role of Blockchain Technology in the Healthcare Domain". Electronics 8 (6): 679. doi:10.3390/electronics8060679. 
  9. Agbo, C.C.; Mahmoud. Q.H.; Eklund, J.M.. "Blockchain Technology in Healthcare: A Systematic Review". Healthcare 7 (2): 56. doi:10.3390/healthcare7020056. PMC PMC6627742. PMID 30987333. 
  10. Hölbl, M.; Kompara, M.; Kamišalić, A. et al.. "A Systematic Review of the Use of Blockchain in Healthcare". Symmetry 10 (10): 470. doi:10.3390/sym10100470. 
  11. Qadri, Y.A.; Nauman, A.; Zikria, Y.B. et al.. "The Future of Healthcare Internet of Things: A Survey of Emerging Technologies". IEEE Communications Surveys & Tutorials 22 (2): 1121–1167. doi:10.1109/COMST.2020.2973314. 
  12. Chakraborty, S.; Aich, S.; Jim, H.-C.. "A Secure Healthcare System Design Framework using Blockchain Technology". Proceedings of the 21st International Conference on Advanced Communication Technology: 1260–64. doi:10.23919/ICACT.2019.8701983. 
  13. Dasaklis, T.K.; Casino, F.; Patsakis, C.. "Blockchain Meets Smart Health: Towards Next Generation Healthcare Services". Proceedings of the 9th International Conference on Information, Intelligence, Systems and Applications: 1–8. doi:10.1109/IISA.2018.8633601. 
  14. Srivastava, G.; Crichigno, J.; Dhar, S.. "A Light and Secure Healthcare Blockchain for IoT Medical Devices". Proceedings of the 2019 IEEE Canadian Conference of Electrical and Computer Engineering: 1–5. doi:10.1109/CCECE.2019.8861593. 
  15. Hossein, K.M.; Esmaeilli, M.E.; Dargahi, T. et al.. "Blockchain-Based Privacy-Preserving Healthcare Architecture". Proceedings of the 2019 IEEE Canadian Conference of Electrical and Computer Engineering: 1–4. doi:10.1109/CCECE.2019.8861857. 
  16. Zhang, P.; White, J.; Schmidt, D.C. et al.. "FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data". Computational and Structural Biotechnology Journal 16: 267–78. doi:10.1016/j.csbj.2018.07.004. PMC PMC6082774. PMID 30108685. 
  17. 17.0 17.1 Ramani, V.; Kumar, T.; Bracken, A. et al.. "Secure and Efficient Data Accessibility in Blockchain Based Healthcare Systems". Proceedings of the 2018 IEEE Global Communications Conference: 206–12. doi:10.1109/GLOCOM.2018.8647221. 
  18. Biggs, J.; Hinish, S.R.; Natale, M.A. et al. (2017). "Blockchain: Revolutionizing the Global Supply Chain by Building Trust and Transparency". Rutgers University. 
  19. Shen, B.; Guo, J.; Yang, Y.. "MedChain: Efficient Healthcare Data Sharing via Blockchain". Applied Sciences 9 (6): 1207. doi:10.3390/app9061207. 
  20. Khatoon, A.. "A Blockchain-Based Smart Contract System for Healthcare Management". Electronics 9 (1): 94. doi:10.3390/electronics9010094. 
  21. Satamraju, K.P.; Malarkodi, B.. "Proof of Concept of Scalable Integration of Internet of Things and Blockchain in Healthcare". Sensors 20 (5): 1389. doi:10.3390/s20051389. PMC PMC7085612. PMID 32138380. 
  22. "TeleMedCare". TeleMedCare. Retrieved 20 March 2020. 
  23. "Eversense". Senseonics, Inc. Retrieved 20 March 2020. 
  24. "Med-Care". T4A Srl. Retrieved 20 March 2020. 
  25. "HemoScreen". PixCell Medical Technologies Ltd. Retrieved 20 March 2020. 
  26. "LabGeo PT10". Samsung. Archived from the original on 05 May 2020. 
  27. Galletta, A.; Bonanno, L.; Celesti, A. et al.. "An approach to share MRI data over the Cloud preserving patients' privacy". Proceedings of the 2017 IEEE Symposium on Computers and Communications: 94–99. doi:10.1109/ISCC.2017.8024511. 
  28. Galletta, A.; Celesti, A.; Tusa, F. et al.. "Big MRI Data Dissemination and Retrieval in a Multi-Cloud Hospital Storage System". Proceedings of the 2017 International Conference on Digital Health: 162–66. doi:10.1145/3079452.3079507. 


This presentation is faithful to the original, with only a few minor changes to presentation. Some grammar and punctuation was cleaned up to improve readability. The original title—Blockchain-Based Healthcare Workflow for Tele-Medical Laboratory in Federated Hospital IoT Clouds—was changed slightly as "tele-medical laboratory" is a confusing phrase that elicits thoughts of "telemedicine," which is not an accurate portrayal of the article. The new title intends to capture the true spirit of the concept, and this change was also propogated throughout this version of the article. In some cases important information was missing from the references, and that information was added. The Samsung Labgeo PT10S has since been discontinued; an archived version of the URL for it is used here.