A conceptual IoT-based early-warning architecture for remote monitoring of COVID-19 patients in wards and at home

Abstract

Due to the COVID-19 pandemic, health services around the globe are struggling. An effective system for monitoring patients can improve healthcare delivery by avoiding in-person contacts, enabling early-detection of severe cases, and remotely assessing patients’ status. Internet of Things (IoT) technologies have been used for monitoring patients’ health with wireless wearable sensors in different scenarios and medical conditions, such as noncommunicable and infectious diseases. Combining IoT-related technologies with early-warning scores (EWS) commonly utilized in infirmaries has the potential to enhance health services delivery significantly. Specifically, the NEWS-2 has been showing remarkable results in detecting the health deterioration of COVID-19 patients. Although the literature presents several approaches for remote monitoring, none of these studies proposes a customized, complete, and integrated architecture that uses an effective early-detection mechanism for COVID-19 and that is flexible enough to be used in hospital wards and at home. Therefore, this article's objective is to present a comprehensive IoT-based conceptual architecture that addresses the key requirements of scalability, interoperability, network dynamics, context discovery, reliability, and privacy in the context of remote health monitoring of COVID-19 patients in hospitals and at home. Since remote monitoring of patients at home (essential during a pandemic) can engender trust issues regarding secure and ethical data collection, a consent management module was incorporated into our architecture to provide transparency and ensure data privacy. Further, the article details mechanisms for supporting a configurable and adaptable scoring system embedded in wearable devices to increase usefulness and flexibility for health care professions working with EWS.

1. Introduction

Public health systems are going through unprecedented challenges due to the COVID-19 pandemic. The American Center for Disease Control and Prevention (CDC) estimated that 14% of the confirmed cases of SARS-CoV-2 infections required hospitalization [1]. The virus is transmitted through respiratory droplets through direct and close contact with infected individuals or indirect contact with contaminated surfaces or objects [2]. The implementation of social distancing policies, use of masks, and basic hygiene measures were shown to be effective policies in controlling the virus’ spread [3,4], with several countries applying such measures to prevent extensive hospital surges due to COVID-19 [5]. While social distancing is essential to reduce the spread of the virus, they also have a severe impact on economies, which is more pronounced in developing countries where income inequality is high [6]. For example, economic issues, misleading information, and lack of infrastructure to sustain the isolation of families leads to the relaxation of social distancing and an increase in the number of cases in Brazil [7].

All these factors contribute to an increased demand for health services. Health professionals and resources are scarce given the number of critically ill patients, causing disruptions in hospital procedures and affecting the quality of care [8]. The capacity of health teams to observe patients is affected both due to necessary distancing procedures and the need for more attention by patients, leading to increased response times in case of an emergency [9]. Monitoring patients is traditionally a fundamental practice in hospital wards, as a decline in vital signs often precedes health deterioration [10]. The monitoring frequency of patients by hospital staff increases as health condition deteriorates, ranging from 12 h intervals to half an hour visits in critical situations [11]. In such cases, a multi-parameter monitor device is linked to several sensors attached to the patient. The infrastructure comprises sensors, patients, and monitors that typically restrict a patient to bed, reducing mobility. Moreover, these technologies are expensive [12], and cumbersome [13]; to better optimize resources, the continuous monitoring of patients is usually reserved for critical cases. In this scenario, sudden changes in physiological parameters may not be easily and quickly noticed as they depend on direct observation during visits from hospital staff. Moreover, non-severe cases are not equipped with monitoring devices, which is concerning for COVID-19 patients as conditions can quickly deteriorate [14]. Solutions that can support smart, early-detection and real-time remote monitoring functionalities are essential to ensure a high quality of care for COVID-19 patients inside hospitals.

In many situations, the patients may not be admitted to an infirmary or be treated in a hospital setting. People living in rural regions will have difficulty accessing health services facilities, such as several regions of India [15], and many people with suspected COVID-19 symptoms avoid going to hospitals due to the risk of contagion and choose to stay at home without monitoring or support. Further, since health facilities are overcrowded, patients with mild symptoms are often sent back home to self-isolate [16]. These situations highlight the importance of an efficient and affordable patient monitoring solution during epidemics [17].

Moreover, keeping track of infected patients allows the study of disease development and treatment responses. Combining the acquired epidemiological data with context information, such as climate, localization, and direct contacts can further help health officials plan precise counter-measures to mitigate the pandemic. For example, a recent study used data from wearable devices to predict COVID-19 trends and trigger early alarms [18].

In the last few years, the increased adoption and use of Internet of Things (IoT) devices enabled the development of IoT-based remote health monitoring solutions [19,20]. Several studies addressed the technological challenges of keeping track of patients’ health and detecting risk situations based on physiological markers. For example, Mohammadzadeh et al. [17] performed a systematic literature review on the use of IoT-based monitoring systems for disease control in epidemic outbreaks, examining 11 studies. Leenen et al. [12] presented another systematic review aimed at healthcare professionals and discussed current evidence regarding the use of wearable devices for continuously monitoring vital signs, selecting 27 studies. Dias and Cunha [21] reviewed wearable health device technologies, system architectures, and specifications for vital signs monitoring for medical and activity areas. The study selected 128 studies in the medical area and 186 in the activity area between 2010 and 2017. Further notable works in this field are explored in Section 2.

IoT-based Health Monitoring Systems (IoT-HMS) combine the use of sensors, information and communication technologies, generation of massive data, applications of big data algorithms, and artificial intelligence [22] to provide efficient and continuous remote monitoring of patients with realtime notifications. IoT-HMS have the potential to minimize healthcare costs while improving patient care [23,24]. Moreover, the monitoring of vital signs allows the extraction of detailed information from patients’ health status [25]. These data, in turn, can be used to monitor changes in symptoms during treatment [26], detect risk conditions early [27], and trigger alarms in case of a worsening in the patient's health conditions [28]. Thus, the IoT-HMS aims to act as an intelligent preventive tool that detects and acts on sudden changes in health status [29]. Another major benefit of remote monitoring systems is the reduction of in-person contact; during COVID-19, this advantage provides critical protection to health professionals [30].

Indeed, IoT-HMS could potentially be implemented as part of governmentwide policies to monitor COVID-19 patients remotely. The COVID-19 pandemic is similar to the 2003 SARS outbreak in many ways, including a lack of preparation from public health authorities [31]. Timely access to epidemiological data could be of great help in mitigating the spread of viruses. If an early-warning remote monitoring system that leverages IoT devices was put in place (potentially as part of regional health authorities’ policies), it would allow public health agencies to access real-time health and behavioral data from the population. This information could be used to efficiently and quickly understand the nature of the viruses, as well as to monitor and improve the health of patients. For example, a recent study using advanced data analysis techniques verified the differences and similarities of documented COVID-19 cases among regions in Iran [32], which the findings could have been enriched with patients’ monitored data. Further, IoT-HMS that use personal devices also have the advantage of monitoring people that are socially distancing and may be experiencing side effects in their mental health due to isolation [33].

It is important to note that any policies to monitor individuals must address privacy concerns (as expanded in the paragraphs below) and consider the characteristics of pandemics. For example, environmental parameters such as temperature and weather might play a pivotal role in the transmission of COVID-19, in addition to socioeconomic characteristics of a region [34]. Government policies and mandates that focus on IoT-HMS implementation can examine these and other factors that govern the COVID-19 pandemic and plan accordingly. For example, Kanga et al. [35] proposed a system to analyze a region's risk of COVID-19 contagion based on remote sensing and geographic information systems (GIS). Such a risk assessment system could be integrated with IoT-HMS and public health policies; for instance, public health agencies could identify areas at a higher risk of COVID-19 exposure and focus on this area to distribute smart devices connected to the IoT-HMS.

Given the potential of IoT-HMS, such systems must correctly identify the degree of illness severity and efficiently detect sudden changes in a patient's health condition. To this end, the National Early Warning Score-2 (NEWS-2) [36], created in the United Kingdom and used in healthcare settings worldwide, can be incorporated. The NEWS-2 provides a score based on several monitored variables to identify the severity of a patient's condition. Specifically for COVID-19, NEWS-2 was found to be an efficient tool for stratifying patients and a good predictor of ICU admission, and in-hospital mortality [37,38]. Moreover, the World Health Organization (WHO) recommends using NEWS-2 to recognize and escalate treatment of COVID-19 patients early [16]. Therefore, a remote system that supports early warning scores, particularly of NEWS-2, can effectively monitor the health status of COVID-19 patients.

A final consideration of IoT-HMS includes the confidentiality of patients’ information [20]. The use of sensors increases the number of data collection points, and the type of health data that can be collected from patients. Both aspects make it difficult to know “what, why, and how data are being collected” [39]. While data gathered within hospitals is usually protected in the hospital network and used to treat patients internally, considerations on patient privacy become essential when considering the remote monitoring of patients in external clinical settings. Moreover, pandemics increase the need to share patient data for research studies and public health agencies. Hence, the IoT-HMS must be able to manage patient consent efficiently for data collection. Several jurisdictions have different acts that regulate the collection and use of identifiable information [40], and a remote monitoring solution must ensure that patient privacy is being preserved.

Despite the extensive literature addressing the challenges of monitoring patients using IoT-based solutions, there is a lack of an integrated and configurable method for predicting and detecting clinical changes in patients using connected devices, particularly for COVID-19 monitoring. The goal of this paper is to present a conceptual architecture of a comprehensive early-warning health monitoring system for COVID-19 with integrated and unified mechanisms for collecting, handling, recording, and analyzing a patient's data within hospitals and non-clinical environments. The conceptual architecture presented here has the following distinct features for remote monitoring systems:

• iA comprehensive view of all aspects of the system, from data acquisition and analytic to monitoring processes;
• iiIntegration with an effective early warning score system for health assessment of COVID-19 patients;
• iiiReconfiguration of device parameters for customization of the early-warning score system;
• ivFlexible and configurable integration with hospital systems and patients’ devices;
• vEfficient handling of user privacy by providing a blockchain-based platform for secure management of patients’ consent;
• viIntegration with different connected devices and external APIs, both inside and outside of hospitals;
• viiWearable device's efficient energy optimization through self-adaptive transmission policies and remote customization of parameters.

This set of features is described regarding common challenging requirements of IoT-based solutions and in the face of COVID-19 outbreak, such as scalability, interoperability, network dynamics, context discovery, reliability, and privacy.

The remainder of this paper is divided as follows: Section 2 presents related work in remote monitoring systems, the NEWS-2, and blockchain. Section 3 describes remote health monitoring of COVID-19 patients use cases. Section 4 presents the technical challenges. The proposed system's architecture is described in Section 5. Section 6 comments on architectural sensitive points and potential solutions deployment risks. Section 7 discusses the proposed architecture benefits and drawbacks. Finally, Section 8 presents the final considerations, limitations, and future work.

2. Related work

This section reviews the leading technologies described in this article, namely, remote patient monitoring systems, the use of NEWS-2 in COVID-19 cases, and a brief introduction to the blockchain technology used as a basis for the user consent platform.

2.1. Remote patient monitoring systems

This subsection provides an overview of works that proposed solutions closely related to ours, and further comprehensive reviews of the field can be found in Dias and Cunha [21], Thilakarathne et al. [23], Qi et al. [41], and Usak et al. [42].

Otoom et al. [43] envisioned a solution for detection and monitoring of COVID-19 cases, which collects real-time symptoms data from wearable sensors and uses machine learning to predict suspected cases that can be confirmed by a physician. The predictive model was constructed based on confirmed cases from a COVID-19 public dataset, and the authors proposed manual feature extraction combined with patients’ history. The proposed framework comprises five main entities used for acquiring data from wearable devices, receiving outcome reports from quarantine centers, analyzing the data with machine learning, connecting with health care professionals, and integrating with a cloud infrastructure. The focus of this article was on the workflow to feed the machine learning engine and the associated algorithms, not in a detailed conceptual architecture.

Steinhubl et al. [30] present a proof-of-concept developed in an Ebola treatment center that monitored vital signs using a wireless multi-parameter patch sensor connected with a remote data analytics platform. Skin temperature, ECG, red and infrared photoplethysmography, and 3-D accelerometer sensors were used. Acquired data were transmitted through Bluetooth to an Android smartphone, which utilized a Wi-Fi connection to transmit the data to a notebook within a local area network. This notebook has a satellite connection to a remote site. The data analysis process runs on the notebook, and clinicians can see the processed data on their tablets via Wi-Fi. For clinical status assessment, the solution utilizes a machine learning algorithm known as similarity-based modeling, which analyzes residuals from baseline values and infers stability, improvement, or deterioration of health parameters. The authors concluded that the platform could monitor patients with high accuracy. This interesting solution is a self-contained system aimed at running locally in low-income regions. In contrast, our proposal offers a full-architecture model for wards and home-monitoring scenarios.

Haghi et al. [44] developed an end-to-end solution that combines and synchronizes collected physiological, behavioral, and environmental parameters using wearable wireless devices and a flexible IoT gateway to support several private and open sensor applications. The solution proposes a data management and analytics layer, including external systems (e.g., Fitbit, Nokia, and Garmin cloud applications) as part of this layer. A data collection layer contains an IoT gateway (in this case, a smartphone) as a proxy interface for the external systems and a gateway for the sensor node layer where the health and ambient monitoring sensor nodes pre-process acquired data from the sensor layer. Although the system allows a comprehensive monitoring system with the possibility of configuring alarms using value thresholds, it does not present mechanisms for assessing individual clinical status or detecting health risk-situation.

Akkas et al. [19] describe an IoT-based monitoring system tested in postop ward units at Ege University Hospital in Turkey. The system collects physiological data from patients using a wireless sensor network, transferring the acquired data to a central database and triggering alarms when monitored values surpass pre-determined thresholds. The authors performed tests to check packet loss in wireless communication between the sensor network and a base station in different scenarios, concluding that data accuracy was in accordance with the wired solution and interference with other systems did not affect proper system operation. The focus of this work was on wireless communication and not on conceptual architecture.

Amer et al. [13] used wearable technologies with hospital patients in cardiology, post-surgical, and dialysis wards. Vital signs and estimates of early warning scores were aggregated on a one-minute basis. Additionally, the authors used a hybrid machine learning technique for predicting future values of the monitored vital signs known as the k-nearest neighbors leastsquares support vector machines (KNN-LS-SVM). This method can perform online predictions based on recorded measurements. Although the algorithm achieved promising prediction results, details of the architecture, modules, and processes were not the focus of this work.

Jara et al. [45] describe a comprehensive integrated framework and communication protocol for monitoring vital signs using clinical devices and integrating them into high-level health information systems. The authors also described a series of requirements and services, including access and consent management. The remote monitoring platform, named Monere, connects clinical devices to external networks and executes administrative functions. This platform is extended by a module that offers support for device life cycle management and complex network transactions. Additionally, a communication protocol named YOAPY was developed over the 6LoWPAN technology. The framework was evaluated in an assisted living environment for patients with breathing problems and assessed the YOAPY protocol in terms of power consumption, security level, latency, and communication integrity. Although the authors have described an integrated framework, the focus is on the communication protocol and interoperability functions.

Barroca Filho et al. [46] developed and deployed an IoT-based monitoring solution for critical COVID-19 patients in ICUs. The authors provide a detailed description of the platform, and the solution is aimed to meet the requirements of Remote Patient and Environment Monitoring, Patient Healthcare Data Management, Patient Health Condition Management, and Emergency and Crisis Management. The sensors capture physiological and environmental data which are analyzed to detect anomalies and send alarms. The module provides access to external applications via a RESTFul Web interface and is protected by the OAuth V2 authorization method. Monitored data can be viewed in the hospital or using a smartphone application. The solution integrates the standard multi-parameter monitor using an MQTT gateway running on the Raspberry Pi 3 to send data to the cloud. Benefits of this proposed platform include efficient and centralized monitoring of all ICU patients, reduced manual recording of vital signs and the number of direct contact with infected patients, and ease of access to the collected data. Unlike our solution, this work uses costly multi-parameter monitors to observe observe COVID-19 patients in ICUs. No standard early warning mechanism was utilized; instead, health staff criteria are used to configure alarm thresholds.

Table 1 presents a summary of analyzed works regarding relevant aspects of the solutions and comparing them to our proposal. Several studies presented promising results and focused on different technological aspects of IoT-HMS solutions. An IoT-based solution to monitor patients during the COVID-19 pandemic seems to be an appropriate tool to improve health services and patient safety. However, different from previous works, our work is focused on an integral architecture solution aimed at COVID-19 patients in the most common scenarios with attention to incorporating a customizable early-warning mechanism and integration to external systems, such as a consent platform, third-party sensor solutions, and public health and research systems. Indeed, our work is one of the few that integrates with personal devices and hospital information systems while also providing customizable early warning scores (to the best of our knowledge, we are the only IoT-HMS work that focuses on the NEWS-2 for COVID-19). In addition to the integration with external applications and a monitoring system outside hospitals supported by innovative data protection methods based on blockchain technologies to manage informed consent. Details of our system are further described in Section 5.

Table 1.

Summary of the reviewed works compared to our proposal.

	Domain	Interoperability	Scalability	Context-discovery	Net. Dynamics	Reliability	Privacy
	Target (Ubiquitous)	Interface to other systems/ devices	Middleware	Health Assessment	Mobility / Wireless	Design and Technology	Data protection	Consent Platform
[43]	Covid-19. Clinical settings	N/D	N/D	Machine Learning	Yes / Yes	Focused on predictive models	N/D	N/D
[30]	Ebola Clinical settings	N/D	N/D	Machine Learning	No / Yes	High-acuity of monitored data	N/D	N/D
[44]	General Clinical settings	Only for devices	N/D	Not clear	Yes / Yes	Notification layer	Yes	N/D
[19]	Chronic diseases Clinical settings	N/D	N/D	Pre-defined thresholds	Yes / Yes	Radio communication	N/D	N/D
[13]	General Clinical settings	N/D	N/D	Machine Learning	N/D	N/D	N/D	N/D
[45]	General. Clinical settings and home	Devices Hospital systems	Yes	Semantic rules	Yes / Yes	MONERE YOAPY protocol	Yes	N/D
[46]	COVID-19 Clinical settings	Based on HL7 standard	Yes	Thresholds, Machine Learning, Customizable	No / Yes	IEC standard	Yes	N/D
Our work (*)	COVID-19, Clinical settings and home	Devices, Hospital Systems, Policy Health Agencies, Research Institutions.	Yes	Thresholds, NEWS2, Customizable, Machine Learning	Yes / Yes	Embedded EWS agent, Data distribution layer, Event Managment	Yes	Yes blockchain platform

N/D - not defined. (*) The proposal will be fully-described in Section 5.

2.2. National early warning score 2 (NEWS-2)

NEWS-2 [36] is a reference method for detecting changes in patients’ clinical status through a risk-index based on monitored symptoms [38]. A score is generated based on the patient's respiratory rate, oxygen saturation, systolic blood pressure, heart rate, level of consciousness, temperature, and supplemental oxygen dependency [47].

The Royal College of Physicians from the United Kingdom included additional recommendations for monitoring patients depending on their NEWS-2 score [37]. Table 2 shows the monitoring periods for each scoring range. High scores of NEWS-2 are associated with worsening clinical outcomes.

Table 2.

NEWS-2 - Scores vs monitoring period.

NEWS-2 Scores	Monitoring Periodicity
0	12 h
Between 1 and 4	4–6 h
Between 5 and 6	Hour
Above 7	30 min

Recently, NEWS-2 has been used for the stratification of COVID-19 patients [37,47]. Gidari et al. [37] further studied NEWS-2 in the context of COVID-19 and found that NEWS-2 was a good predictor of Intensive Care Unit (ICU) admission for these patients. For example, score thresholds of five and seven using the NEWS-2 index were significantly related to ICU admissions [37].

Myrstad et al. [38] conducted a prospective cohort study with COVID-19 patients. They concluded that NEWS-2 score equal to or greater than six predicted severe disease and in-hospital mortality better than other clinical scores.

These results suggest that NEWS-2 is an accurate and efficient metric for monitoring COVID-19 patients’ health status. Moreover, early warning scores based on vital signs of hospitalized patients can be estimated accurately and frequently using wearable devices, and future values of these vital signs can be reliably predicted using machine learning algorithms [13].

2.3. Blockchain

Blockchain technologies can be seen as an immutable distributed ledger equipped with cryptography techniques capable of keeping anonymous and secure records of transactions between two or more peers of the same network [48]. A blockchain transaction can contain any information, such as monetary transactions, medical records, forms, and business object representations. Each new transaction is stored in a data structure called a block, and new blocks are added to the blockchain with a unique hash signature that contains, on its creation, information from the most recent block of the network and a timestamp. This cryptography heritage ensures that the blockchain network cannot be altered; in other words, the chain of blocks is immutable, and any interactions between peers can be easily tracked and audited [48].

In short, blockchain can provide an immutable and timestamped log of an asset, such as user consent [39]. Recently, blockchain technologies have been used in different domains for similar purposes, such as in supply chain management to create and maintain an immutable history of a business object; in healthcare, to control drug lifecycles and avoid counterfeiting of medication prescriptions; and in cryptocurrency's back-end technology, such as Bitcoin and Ethereum [49].

3. Use cases

IoT-HMS, such as the one proposed in this work, can be utilized during the COVID-19 and future pandemics in several ways. Fig. 1 presents examples of preventive and reactive uses. Public health agencies may adopt preventive actions such as mapping and flagging populations at a higher risk of contagion from viruses and providing monitoring devices to these specific groups. The monitoring would allow agencies to take early actions and control pandemic outbreaks in real-time. Known risk groups for developing acute symptoms of COVID-19, including older adults, individuals with chronic conditions, essential workers and people living in nursing homes or distant areas from health services, could be preventively monitored with connected devices and better assisted in case any risks are detected.

Fig. 1.

Preventive and reactive use cases promoted by a health monitoring system during pandemics.

Systems can also be used for COVID-19 patients with mild and moderate symptoms at home, treatment centers, and hospital wards. These patients usually are not continuously monitored with multi-parameter monitors. Remote sensing information can be accessed by health professionals on duty, health monitoring centers, ambulance services, health agencies, research institutions, and patient caregivers. However, to share personal data outside of a hospital setting, the solution must enforce privacy regulations.

Our solution focuses on COVID-19 patients with mild and moderate symptoms since most of the cases are not severe [47]; patients with severe and critical symptoms are typically admitted to intensive care units [16] and continuously monitored with intrusive devices already connected to the hospital system [50]. In general, mild and moderate COVID-19 patients are admitted to a COVID-19 ward or directed to self-isolate at home [16]. Outside hospitals, caregivers may accompany patients and assist them with their immediate needs, such as in case of an emergency or incident.

When patients begin treatment, interconnected devices with embedded sensors acquire physiological signs to identify clinical status. The collected data should be transmitted to and visualized by health professionals. Advanced analytical algorithms can process the data and generate alarms in case of a worsening in the patients’ health condition. Thus, health professionals can answer events. The patient, or the person responsible for his/her medical care (known as the substitute decision-maker [51]), grants or denies permission for the acquisition, use, and handling of his/her medical data and information during and (most importantly) after hospitalization.

The following subsections detail processes related to monitoring COVID19 patients located at hospital wards and home.

3.1. Hospital

New COVID-19 patients admitted to a hospital ward should be equipped with sensors to monitor their vital signs [16]. Based on the patient's bed location, a group of health professionals will be in charge of handling that sector. The sensors are connected to a device with a microcontroller and a wireless radio. The sensors, the microcontroller, and the radio are known as the wearable kit (W-Kit). Acquired data is transmitted to a monitoring application and visualized on a central dashboard. A network link must be available to connect the W-Kit to these applications.

The monitoring system can also be customized to the patient's parameters [29]. The W-Kit does not possess any information on the patient´s identity, and a remote process running on a protected cloud environment links the W-Kit to the patient's identification. In this manner, the W-Kit can be customized based on the patient's health profile. A critical task of the customization process is to configure the parameters used by smart algorithms that detect abnormalities in the monitored data. If a patient's health condition deteriorates, the system must effectively detect this change based on the monitored data and trigger an alarm for health professionals. If the patient's health condition improves before the arrival of a health professional, the alarm can be automatically canceled. Otherwise, the professional attending the call informs the system that the alarm was handled, and he reports any additional feedback on the patient's condition.

The patient will be monitored until one of the following occurs: the patient is discharged; transferred to another unit; transferred to be monitored at home, or dies. The patient's bed is released, and the W-Kit is reset, except when the patient is transferred to home care.

Fig. 2 gives an overview of the common functionalities of the solution for patients in hospitals or at home. The following subsection describes in more detail the home case and the differences from the hospital scenario.

Fig. 2.

Home and hospital use cases common functionalities.

3.2. Home hospitalization

In some cases, Covid-19 patients are not treated in health facilities [16], but try to overcome the illness at home. Hospitals can be overcrowded, too distant from a patient's home, or it may be safer and more convenient for patients with mild and moderate symptoms to stay at their homes [16]. It is also possible that patients are discharged from hospitals but should still be monitored. Further, risk groups (e.g., older adults and individuals with comorbidities [52]) can also be monitored outside clinical settings. To deal with these scenarios, the W-Kit can also be used to monitor patients’ vital signs at their homes.

Sensor data are transmitted through the internet, and an access point must be made available to connect the W-Kit. The monitored data is forwarded not only to the patient but also to caregivers, doctors, and other authorized people as required. However, since the patient is being monitored with several connected devices and sensors outside of the hospital environment, the system must also provide a reliable and safe mechanism for managing consent for collecting and sharing personal health data. Moreover, to increase solution security, the consent mechanism must provide an audit of consent events (e.g., if the patient gives or revokes consent) and monitor any consent violation. This consent management mechanism is included in our solution and described in Section 5.3.3.

The remote monitoring platform must also allow the integration of approved third-party smart monitoring devices. In this manner, the system can benefit from data being collected by any personal smart devices that the patient has and that collects health data (e.g., Fitbit1 or Apple Watch2 ). This integration typically occurs through third-party APIs on the cloud. Our architecture allows all functionalities related to data collected from W-Kit to be available from these third-party solutions, as long as they collect similar data. However, the early warning score module is embedded within W-Kit to assess health status locally, except for third-party devices that this assessment is performed remotely.

It is also important to note that the use of connected devices outside hospital settings allows the collection of context information, such as location, which expands the possibilities of remote monitoring systems to include additional functionalities to mitigate the spread of the pandemic. Examples of these functionalities include contact tracing identification of COVID-19 hot spots and helping public health authorities determine areas at a higher risk of contagion. In addition, patient's symptoms reports can be sent using a mobile application or a Web portal. Machine learning and advanced data analysis techniques perform prediction, classification, support decision-making to actions using monitored data and other medical records. Finally, according to the patient's consent, data can be forwarded to external entities, as illustrated in Fig. 2.

4. Challenges for a monitoring system of COVID-19 patients

This section describes the main challenges of meeting the requirements for monitoring COVID-19 patients in hospitals and at home. Fig. 3 gives an overview of the leading entities, data flows, and actors related to the solution.

Fig. 3.

Patient monitoring main data flows, entities and actors related to the solution.

One of the primary purposes of remote monitoring systems is to assist and protect patients against severe or life-threatening worsening of health condition through regular (and, if possible, continuous) observation of their health status [50]. In the context of COVID-19, these systems provide tools for early diagnosis and have the potential to decrease the number of fatalities [17,29]. Furthermore, storing the monitored parameters and patients’ health history enables analyses of the efficacy of treatment plans and the identification of risk factors for disease outcomes that are required for timely and effective clinical decision-making [53].

Therefore, one of the most challenging tasks of developing a patient monitoring solution for COVID-19 cases is identifying health deterioration and risk situations. Currently, several protocols are used in infirmaries to assess and identify the clinical status of patients based on their vital signs; most notably, the NEWS-2 indicators have shown promising results in assessing COVID-19 patients hospitalized in infirmaries [37,38,47]. Additionally, the analysis of patients’ health conditions should be personalized based on individual characteristics [29]. Patients with COVID-19 have distinct health and demographic profiles [16], and the customization of early-warning scores and parameters increases accuracy for specific populations [37]. However, implementing a solution that supports the customization of assessment methods embedded on devices is challenging in a distributed wireless environment.

Scalability is another major challenge, especially considering the quick spread of the pandemic. The solution must support several thousands of patients being continuously monitored concurrently. Response-time is another concern, as the deterioration of health conditions must be identified and treated as early as possible. In addition, reliability is pivotal for health systems since any failures may lead to severe consequences in the system's adoption as well as in the accuracy of collected data [45]. Flexibility and interoperability must also be taken into account, as remote monitoring systems should be easily integrated into other solutions and take advantage of available resources that could enhance patients’ safety and provide other assistance [45]. Finally, data confidentiality must be considered when dealing with sensor data and sharing information with epidemiological control officials and research groups. In this manner, the management of user consent for data collection with remote devices is necessary to ensure that patient's rights are being respected.

The remote monitoring system must also be easily integrated into legacy systems such as hospital administrative applications, medical record systems, and databases for obtaining all patient information used in treatment [45,54]. COVID-19 records must also be easily accessed by regional and national surveillance systems aimed at controlling the pandemic. The platform should also be flexible enough to allow for an extension with new functionalities (e.g., to support big data technologies that can analyze aggregated data from many sources without disrupting other modules).

Another challenge is the utilization of low-cost IoT devices that have constrained resources in terms of processing, memory, storage, communication, and energy capacities [55]. IoT-based solutions mostly rely on remote processes to analyze acquired data [56]; this approach, however, increases latency and response-time [57]. Monitoring devices also become highly dependent on reliable connections that may not be available (for example, in rural areas and poor communities).

Finally, small IoT devices are typically designed to send data but not receive information [58]. Bidirectional communication can be costly in terms of processing, memory utilization, and radio operation. These factors will affect energy utilization and battery life. Therefore, configuring software agents that are able to customize the system to different scenarios can extend the operational life of devices and optimize the use of constrained resources.

In the next section, we will present the conceptual architecture and functional details to tackle these challenges.

5. Conceptual architecture

Our proposed architecture has a minimum of 3 layers. At one extreme, there are small IoT devices responsible for acquiring data from patients in the Data Acquisition Layer. On the other extreme, control processes, user applications, and legacy systems are contained in the Application Layer, which usually runs on a cloud or local high-end servers. Users have access to the system's functionality via desktop computers and mobile devices such as smartphones or tablets. Data distribution characteristics require an intermediate layer, the Data Distribution Layer, to allow data communication between different modules while supporting scalability. Fig. 4 shows a diagram of the proposed conceptual architecture to meet the requirements identified in Section 4.

Fig. 4.

Conceptual architecture diagram.

The Data Acquisition Layer is responsible for collecting sensor data from the patient's monitoring devices, named wearable kit (W-Kit), and forwarding them to the Data Distribution Layer after executing pre-processing routines. The Data Distribution Layer acts as a messaging broker, redirecting data messages between the data producing and data consuming components in the other two layers.

The Application Layer is split into three parts - User Applications, Data Processing and External Applications. User Applications represent all the applications available to the system's users, both for desktop and mobile interfaces. All data processing, storage, and the main system controls are in Data Processing. External Applications include typical legacy applications to support the institution's processes and the hospital information system, such as Electronic Health Records, Enterprise Resource Planning (ERP), Consent Management platform, Public Health Agency systems, among others. Application Layer modules can exchange data with one another through direct interfaces or via a messaging broker.

Finally, the blue boxes in Fig. 4 represent software agents that interact with each other to achieve device customization and remote configuration features. In the following subsections, we explain in detail each layer and its components.

5.1. Data acquisition layer

This layer consists of two primary modules. The Device module is responsible for acquiring the sensor data and a Gateway module to integrate the devices to the upper layer components.

5.1.1. Gateways

The gateways are responsible for connecting the W-Kit to remote processes running on the Application Layer through the Data Distribution Layer.

Its basic functionality is to exchange messages between two types of radios, a low-power radio that connects with W-Kits and another radio that has access to the Message Broker network. Depending on the type of device and network availability, this access can be a local WiFi network or a mobile network.

There are two types of gateways: the fixed base stations at the hospital and an application running on the patients’ smartphones when they are hospitalized at home. The gateways must be registered and activated in the system to start receiving connections from the W-Kit. The communication between W-Kits and gateways is protected by standard protocols such as the Advanced Encryption Standard. Communications between the gateway and the Message Broker network are encrypted using the Transport Layer Security protocol. Each gateway has a unique identifier and can be configured to accept connections to a limited set of W-Kits. In general, gateways running on smartphones can only receive connections from the W-Kit attached to the respective patient, while gateways running in wards can receive several connections simultaneously. Gateways running on smartphones, if authorized by users, may add location information to messages, an essential feature during the COVID-19 pandemic.

The gateway is an important part of the system, enabling the reduction of W-Kit's energy consumption. Powering the gateways with a long-lasting power source allows using an optimized low-power communication protocol with W-Kits. For example, with the radio always on, the gateway allows W-Kits to turn on their radios only when data need to be transmitted. This method saves energy during intervals without communication.

Fixed gateways at wards can also be deactivated for a technical or administrative reason, be stored in stock, or become out-of-service in case of a definitive problem. In the case of an app installed on a patient's smartphones for monitoring at home, the gateway status can be either registered, activated, or deactivated. A deactivated gateway does not receive W-Kits connections and is not allowed to connect to hospital cloud processes in upper layers.

5.1.2. Gateway configuration agent

Gateways receive all W-Kit messages. In the case of using a smartphone, the received information can be visualized on a graphical user interface in the mobile app installed on it. This information is forwarded to a Message Broker running on the cloud or local servers in all cases.

In the opposite direction, gateways are also responsible for forwarding configurations to W-Kit. The system keeps track of which gateway a W-Kit is connected to and sends the configuration commands accordingly. Handovers are handled, and configurations tracked so as not to be delivered and executed twice. The gateway is also prepared to handle the low energy protocol by managing the flow of configuration messages to the W-Kits.

5.1.3. Wearable Kits-W-Kit

The W-Kit is a central entity in our framework. It is responsible for acquiring the patient's vital signs, performing local assessments of the patient's clinical status, triggering alarms, and transmitting acquired data to remote processes. It senses different physiological parameters of the body to provide a view of the patient's health condition.

W-Kit's design represents one of the most significant challenges in our architecture. The specifications as a low-cost, multi-sensor, wireless, wearable, and battery-powered device require a combination of different approaches to arrive at the final design.

The W-Kit is composed of multiple sensors to acquire different data, including skin temperature, heart rate, blood oxygen saturation, respiratory rate, blood pressure, and electrocardiogram (ECG). The sensors can be connected directly to the device or via a wireless link. Some of these sensors may not be present in every W-Kit or may not be active at all times.

The choice of sensors was driven by some of the most common COVID19 symptoms. Fever is a predominant symptom of COVID-19 [59], and it can be detected by the skin temperature sensor. Blood oxygen saturation was further reported as a strong predictor of patients with severe COVID-19 outcomes [60], and respiratory rate during sleep can be used for detecting COVID-19 infection in the first days’ symptoms [61]. Heart rate and blood pressure patterns also seem to be good classifiers between patients with acute respiratory distress syndrome with COVID-19, and without the infection [62]. Monitored vital signs data can be analyzed in real-time or feed longterm time-series datasets to be processed in batches periodically at the Data Processing modules.

Furthermore, the W-Kit contains a low-power micro-controller and a multi-protocol low-power radio transceiver. Our architecture indicates at least two types of radio standards. One is Bluetooth Low Energy (BLE) to connect the W-Kit to gateways based on mobile devices such as smartphones. Another is the IEEE-802.15.4 standard [63] that allows the use of customized protocols to achieve even lower power consumption. The latter uses the same radio in conjunction with the fixed gateways of the wards to help extend the battery life of the W-Kit.

The W-Kit utilizes the appropriate radio to connect to the closest gateway. Once connected to a gateway, the W-Kit is ready to send the monitored vital signs and alarms to remote processes. Each W-Kit has a unique identifier and a status code signaling one of the following: in use, available, cleaning, or out-of-service. The W-Kit becomes in use when connected to a patient and is disinfected when it returns to the hospital staff (corresponding to the cleaning status). When the device is ready for use, it becomes available. If there is a technical problem with the W-Kit requiring maintenance, the status code turns to out-of-service. The W-Kit status can be controlled via direct connection by a particular application running on a smartphone for administrative tasks or remotely from an administrative Web portal.

The data acquired from sensors are the most crucial information feeding the monitoring system. Each sensor produces analog and digital signals that are filtered and transformed into a set of consolidated reading values using mean or median within a time interval. These discrete values are used to check individual scores regarding the configured classes for each sensor. A composite score is calculated to determine the current clinical status before sending a message with these values.

The W-Kit sends three types of health informative messages: periodic messages with the current discrete value of each sensor, an alarm message when clinical status deterioration is detected based on composite scores, and an alarm message when a sharp reading value change occurs. The message types are referred to as Periodic, Alarm, and Condition, respectively.

Other operational messages are also sent by the W-Kit, such as notifications when the battery level is low. Replaceable batteries power the W-Kit and, whenever the batteries reach a certain energy level (i.e., 10% of capacity), a message is sent, and a visual notification can be seen at a controlling dashboard in the infirmary and on the patient's smartphone.

Finally, to reduce energy consumption, the radio must be configured to operate in a short-range and with short data messages. Therefore, the communication protocol with the gateway aims to exchange short messages and keep the receiving radio off as much as possible.

5.1.4. W-Kit-configuration agent

W-Kit intelligence is provided by an embedded agent that has many features and configurable parameters. The agent is responsible for handling signals from sensors, consolidating values, inferring clinical status based on acquired data, triggering alarms, and managing connections and communications.

The software is installed with default values automatically when W-Kit is powered on. It has a unique identification number (UID) and carries no information about the patient's identity. However, there are many configurable properties within the W-Kit, and they are divided into two main groups: operational and health assessment parameters.

Operational parameters regulate reading rates for each sensor, duty-cycle modes for the CPU and the radio, activation/deactivation of sensor readings, communication protocol version, timeouts for communication messages, buffer sizes, minimal level of the battery, cryptographic keys to encrypt messages, and other parameters related to basic services not related to health context. The default communication mode is through radio connection, which uses less power.

Once connected, the W-Kit sends a configuration request with its UID. If available, the gateway can answer the message with the initial parameters or forward the request to a remote process on the cloud. The initial parameters are composed of key-value pairs of properties that differ from default values. The W-Kit is pre-configured with a set of default property templates. In general, the initial parameter indicates which template should be used.

The health assessment parameters are used to customize an early-warning score system, such as NEWS-2. Fig. 5 shows an example of a configuration for the W-Kit Agent. Each sensor represents a physiological parameter, and the monitored values can be classified into eight classes. Sensors not installed are disabled in the configuration. Each class covers a range of continuous values, and so each class has a minimum and maximum value represented by a threshold at each level.

Fig. 5.

W-Kit agent parameters configuration.

Additionally, each class has an associated score. A value read from the sensor is matched to the corresponding class and receives a score. The scores received by each sensor at a particular time are added to form a composite score, which is also classified into categories representing a clinical status (for example, mild, moderate, severe, and critical). The composite score can also have up to eight categories. The number associated with each category represents a time interval in seconds, which is used to regulate the timing of messages transmitted from the W-Kit to the gateway. For example, when the clinical status is mild, messages are sent every five minutes; when it is moderate, every two minutes. Therefore, the inferred patient's clinical status affects the duty-cycle of the W-Kit. Adjusting the duty-cycle is essential to optimize energy consumption as non-critical states allow longer monitoring cycles. This configuration based on clinical status is another difference of our proposed solution, allowing optimization of resources such as power consumption and battery life.

The W-Kit agent also stores previous clinical status classifications to compare against the most recent one. If there is a change in clinical status, an alarm is triggered. It is important to define the categories in an ordered sequence to reflect the stages of clinical conditions. If desirable, the agent can be configured to send only clinical status instead of sending the sensors’ values.

This schema gives enormous flexibility to configure different levels of health status and personalize ranges for each individual considering their conditions. The scores can also be adjusted to a specific patient's profile. For example, vital signs of older adults have low variability when compared to young adults [64], and subtle changes for an older adult can represent a different health condition compared to a younger patient [64]. Moreover, it is possible to configure for each sensor a rate of change of the values read that is considered normal within a time interval. In this manner, drastic changes in a specific interval will be considered abnormal, and an alarm can be sent independently of changes in clinical status. Values acquired from sensors are transformed into discrete values calculated based on a sliding window whose size can also be configured for each sensor. The statistical method to represent the values read during the transmission interval can also be modified, such as mean, median, maximum or minimum.

Although not frequent, this configuration can be modified during the operation of the W-Kit. After sending messages to the gateway, the W-Kit waits for an acknowledgment message (ACK). ACK messages have a code informing if there are messages to be sent from the gateway to the W-Kit (for example, messages with reconfiguration parameters). The W-Kit will receive these configuration messages, and changes will be applied after the next processing cycle for assessing clinical status. The pending data flag protocol in the ACK message allows W-Kit to turn off the radio between data transmissions to save energy. The custom embedded properties with an optimized mechanism for receiving updates are another important characteristic of the W-Kit.

5.2. Data distribution layer

This layer comprises a main Message Broker module responsible for exchanging data between different parts of the system, and an auxiliary External API module that collects sensor data from third-party devices. Next, we provide details about these two modules.

5.2.1. Message broker

The Message Broker is based on the publish-subscribe paradigm (PubSub) [65]. Publishers are data producers, and subscribers are data consumers. Authorized processes subscribe to a topic of the broker to indicate the interest in consuming data from a specific source. Each topic has a unique name and acts as a data channel. The gateway publishes the data produced by the W-Kits into respective topics. For example, each sensor message type (Periodic, Alarm, Condition, Operational) has its specific topic naming structure. The broker redirects the published data to the respective topic subscribers.

Other modules of the architecture also use the broker to support message exchange. Each message type has a specific topic (channel). Several processes can subscribe to these topics, receive every published message, and handle their processing and destination. For example, a process aimed at distributing readings of periodically monitored data obtains the location of the source sensor based on its UID and publishes it into topics related to its location. Then, caregivers and health staff receive the published data since they are subscribed to these topics. Another process stores all received information into a database to be further analyzed. In addition, a parallel process analyzes the clinical status and triggers/cancels alarms depending on clinical status changes. Other processes integrate received data into the hospital medical record platform. Finally, processed information can be visualized on the ward's controlling dashboard, a doctor's or caregiver´s smartphones, or an internet portal.

5.2.2. External API

The External API allows integration with third-party sensors through web services interfaces. In general, the system will access third-party clouds that integrate values sent by devices associated with the API (e.g., smartphones and smartwatches).

The External API module collects data from external sensors and converts it to be compatible with formats used internally by our platform. However, the use of those sensors is limited since they cannot be customized as in our platform. Unlike the W-Kit solution, assessing the clinical status and detecting critical events for triggering alarms must be processed in the hospital's cloud, not within wearable devices. This method increases the latency and dependency of reliable internet connections, and it can also increase network traffic.

However, similar to the W-Kit scenario, acquired data can be stored, integrated, processed, analyzed, and visualized by authorized processes and applications that had subscribed to corresponding topics. In short, the interoperability between external devices and internal processes is supported by the External API module.

5.3. Application layer

The Application Layer comprises three main parts: User Application, Data Processing, and External Applications. The main objective of this layer is to integrate, aggregate, store, present, and perform complex processing using data acquired in the Data Acquisition Layer. Each part encompasses several processes, described in detail in the following subsections.

5.3.1. User application

User Application encompasses all end-user processes in which a person can interact with the system. There are two main functions: (i) visualizing health information and interacting with health service workflows; and (ii) administering and managing data and tools of the system.

When monitored outside a hospital, patients can visualize their data using a smartphone application installed in conjunction with the gateway application. Through this application, the patient can send information about common COVID-19 symptoms to the system, such as self-reporting the presence of cough, fatigue, headaches, sore throat, and shortness of breath [59] in addition to the objective data monitored by sensors.

The dashboard used for visualizing and interacting with service workflows can be instantiated in two forms: a central control for monitoring several patients and an individual interface for visualizing data from one patient. The central dashboard runs on a computer station located at the hospital, while the individual dashboard runs on smartphones, tablets, and other personal digital assistants of authorized users. The dashboards allow visualization of physiological parameters from each patient, clinical status represented by a color scale, warnings, and alarms. The interfaces allow the input of properties related to the scoring system, such as the use of supplemental oxygen by the patient and questions asked to the patients to check their level of consciousness. These parameters can receive scores and be further added to the inferred clinical status scores in the W-Kits, leading to a new evaluation at this level.

The other group of processes in the User Application comprise the Administrative Tools. These applications allow the management of the data model and configuration of system parameters. Only specific data related to the monitoring system is maintained in this data model since most of the administrative information comes from external applications such as the hospital ERP and Medical Record Systems. A Web-based user interface accesses Administrative Tools. The External Applications part is detailed in the next section.

5.3.2. External applications

Several other applications external to the patient monitoring system comprise this layer. The patient monitoring system is part of the hospital's computational environment, rich in the information provided by legacy applications. For example, the ERP provides information about health professionals, nurses’ and doctors’ shifts, available and occupied beds, and ward sectors. The Medical Record System manages the electronic medical records of patients and provides essential parameters for customizing the assessment of monitored data. Other corporate applications that belong to the health care chain can be accessed by the monitoring system, such as interacting with laboratory systems. This integration during COVID-19 pandemics is crucial to streamline patients’ screening, control, and discharge.

Furthermore, during pandemics, applications and datasets related to authorized Public Health Agencies and pandemic surveillance systems can also benefit from patient data. These systems can receive authorized and anonymized data to plan public actions, compose risk indices, and support epidemiological studies.

These external applications can interact directly or indirectly with the patient monitoring system through web service interfaces, such as the Representational State Transfer (REST) architecture style, WebSockets, and SOAP, and be protected with OAuth V2 protocol and encryption.

Finally, the Consent Management Platform manages the authorization for collecting, storing, distributing, and using a patient's collected information. Details of this platform are expanded in the following subsection.

5.3.3. Blockchain-based consent management platform

Velmovitsky et al. [39] described a blockchain-based platform for consent management, in which the blockchain network provides a log of user consent for data collection. For instance, in this platform, a user can consent for a researcher or institution to collect their health data for a certain period. The platform presented by the authors considers the use case of Active Assisted Living, a field highly related to IoT health monitoring systems that use technology to support older adults to age independently and actively. It can include, for example, the use of wearable sensors to monitor health variables of older adults [39]. Since this population is at high-risk during the pandemic [16], this becomes essential.

With a blockchain-based consent platform, individuals can consent to their data being collected by smart devices, such as smartwatches or the Wkit. The collected data can be analyzed in real-time to detect any changes in health status and emergencies in a way that maintains and preserves user privacy through the management of their health data collection. Further, at any time, individuals can revoke their consent for data collection.

In this manner, integrating a consent management module in our conceptual architecture can ensure that patients’ privacy is being respected while their data is being collected. While this is not a major concern when the patient is under treatment in hospitals, it becomes essential during the COVID-19 pandemic for forwarding information to public health agencies, research institutions, and follow-up treatment; individuals who are at home and do not wish to go to a hospital for risk of contagion; and for individuals living in areas with limited access to healthcare.

For the proposed architecture, the specific use of blockchain technologies for obtaining participants’ informed consent comes from blockchain's native features of privacy, security, immutability, and transparency. Our architecture utilizes Hyperledger Fabric (HF) as the underlying blockchain technology [66] framework. The HF is a permissioned blockchain network that is based on the creation of business consortium networks, where each member of the network (peers) can transact information with others via private communication channels [66]. These channels contain any given subset of peers, and each peer can participate in multiple communications channels. It means that a single peer could hold multiple ledgers (blockchain files) since one ledger is created for each channel. Each ledger keeps records of transactions between members of a specific communication channel. As such, a peer member of a channel can verify the history of transactions between all members.

Transactions in HF are used to update the status of business objects. For example, the ownership of a car can be modeled into a business object and, each time the car is sold to a new owner, its business object status is updated on the ledger. A participant's informed consent is modeled into a business object in our architecture, and its status’ change history is registered into the ledger. The historical record allows network peers to query the most recent status of a given informed consent from a participant and enable our architecture to notify all stakeholders involved in monitoring, sharing, and processing health data. For example, agents from the Data Acquisition Layer can start or stop collecting and transferring data based on the most current status of a participant's informed consent.

Each new transaction is evaluated by each peer member of a communication channel via smart contracts to ensure security and accountability. A smart contract is a piece of software that represents a business control logic to ensure that incorrect or illegally modified information is not added to the ledger. In HF, one or more smart contracts are grouped in a chain code (CC) [66], and each new CC deployed into the network requires endorsement from specific communication channel members. The endorsing peers are defined based on whether consortium members possess some liability or legal obligations and need to oversee the integrity of all transactions. In our architecture, new informed consent data issued from a participant to an external application must be validated by proper stakeholders before sharing a participant's health data.

5.3.4. Data processing

The Data Processing in the Application Layer has four main modules: event management, stream processing, machine learning engine, and data storage module. The event management module controls the flux of events that occurs within the system. It controls process requests from the User Application and External Application modules, as well as events from the Message Broker.

Furthermore, one process of the event management module is responsible for checking the periodicity of received messages according to frequency configurations. If one active W-Kit stops sending messages, an alarm is sent to the group of people in charge of that patient. Moreover, an exclusive process from this module interacts with the Consent Management Platform to check periodically for patients’ consent status. If a change is noticed, a reconfiguration message is sent to the required modules. For example, a reconfiguration message can be sent to interrupt the collection of sensor data in the W-Kit or revoke an external research group's access.

Fig. 6 gives an example of a sequence of events between a user application and the W-Kit controller by the event management module.

Fig. 6.

Events during a user application connection life-cycle.

In block A of Fig. 6, a User Application sends a login request captured by the event management process that confirms the login. Then, the application asks and receives the configuration parameters. Once this is completed, the User Application subscribes to specific topics to receive updates and notifications from W-Kits attached to target patients while W-Kits send periodic messages with the values of physiologic parameters.

After subscribing to receive the patients’ information, the User Application starts receiving periodic updates in block B. An alarm triggered by W-Kit is confirmed by the controller and forwarded to the application. However, in the next periodic message, the patient's inferred clinical status has improved, and the alarm is canceled.

In block C, a special condition occurs, signaling a drastic change in a physiological parameter. The User Application receives the notification, and the user recognizes the warning, asking for the history of the events. In block D, the User Application receives the historic data forwarded by the event management process from the database's data. Finally, in block E, the event management process adjusts an administrative parameter, such as including a new patient to be monitored by that user, and the user notifies the event management of the log out in the system.

In summary, the W-Kit sends periodic updates with current monitored physiological values, alarms, and warnings when a specific condition occurs. The application sends login and logout requests, requests for initial configuration parameters, subscription requests to receive data from specific patients, queries to consult historical data, and alarm recognition messages. The event management handles requests and responds to applications after processing received data from sensors and integrates them with information from external applications if needed. Scalability can be managed at this level, instantiating new event management processes when the load increases and splitting requests among these processes following load distribution policies.

The stream processing module provides accurate and updated information about patients’ status. Using current information is helpful for managing resources and anticipating situations, as well as for discovering temporal patterns in monitored data.

The Data Processing part is also responsible for performing complex analyses such as data mining. Machine learning models can be used to predict and classify risk situations, and support decision-making based on the monitored data and other medical record features [67]. In the same way, historical data can be analyzed to infer the best treatment plan for certain symptoms or to indicate procedures that have the potential to minimize the number of fatalities.

The monitored data can be stored in SQL and NoSQL formats. Relational databases are useful for integrating patients’ data with other structured data and checking data integrity rules. In contrast, NoSQL databases such as the ones using the Resource Description Framework format can be useful for using ontologies, semantic rules, and formal logic to infer health contexts and integrate with other medical knowledge bases [68]. However, the use of these ontologies requires a mapping mechanism that links key-value pairs in message payloads to ontology vocabulary, such as JSON-Linked Data. [69].

6. Architectural sensitive elements and potential risks

The proposed solution utilizes state-of-the-art hardware, software, architecture, and software frameworks to reduce, by design, the number of vulnerabilities and cybersecurity threats. However, there are still sensitive elements and risks that must be addressed.

A key point of this project is the use of wearable devices and wireless communication to monitor patients’ vital signs in scale, given the increasing number of cases during a pandemic outbreak. However, the management of large cohorts of devices and their functionalities still needs production environment validation over long periods. Moreover, if third-party platforms and devices are included in the architecture, managing different battery life, communication protocols, and data types become increasingly demanding.

Further, W-Kit power consumption determines the size of the battery and energy autonomy. Battery weight and physical dimensions should be limited by the comfort and practicality of use by a patient. With reduced dimensions, the battery replacement requires special attention because of operational and material costs. The proposed architecture optimizes energy utilization by choosing low-power profile components, providing self-adaptive modes of operation and communication; however, the more severe the health condition, the greater the energy utilization by the devices.

The lack of an internet connection for monitoring patients at home in certain regions is another limitation. In many low-income areas, connectivity is precarious, and many people do not own a smartphone or cannot afford an internet plan. Despite the implementation of local assessments of patients’ health conditions decoupled from external systems, socioeconomic conditions may limit a remote monitoring system's availability and limit its benefits for public health.

Privacy and individual rights are also a concern. Regulatory acts, such as General Data Protection Regulation (GDPR) and General Personal Data Protection Law (LGPD) requirements [70,71], also imposes limitations in the conceptual architecture. Sharing data without informed consent is not always possible without strict anonymization policies and obtaining and maintaining informed consent from large cohorts is necessary. Regulatory acts also impose rights to data subjects such as data access, information rectification, right to be forgotten, halt of personal data sharing and processing, and notifications of personal data usage by data processors and third parties. Regulatory acts also require privacy protection of data subjects’ identities to prevent physical, mental, and financial harm from being bestowed upon them with penalties for data breaches. Our solution mitigates several of these concerns through the Consent Management module, but the management of user consent and data from large population groups and during emergencies is still a challenge.

Finally, some other sensitive elements may impair the effective use of IoTHMS during pandemics, such as considerations on the quality of collected information, interoperability with proprietary hospital information systems, and cyber-attacks that are more difficult to combat in large and highly dynamic distributed platforms. However, to combat the COVID-19 pandemic that threatens population health as well as social and economic stability, the benefits surpass by far the limitations and risks. The proposed architecture presented in this work mitigates these risks through the implementation of several functionalities and modules.

7. Discussion

The COVID-19 pandemic is putting a strain on health systems across the world, and an IoT-based patient monitoring solution can tackle the presented challenges [72], minimize the burden on medical services, and improve the quality of care.

Several proposed IoT-HMS are based on middleware architectures following the Service Oriented Architecture approach since it decomposes complex and monolithic applications into simpler and well-defined modules [73]. Our proposed conceptual architecture follows these principles by defining layers, parts, and modules.

General architecture descriptions for IoT systems commonly describe modules for abstracting objects, managing services, inferring contexts, and abstracting applications interfaces [73,74]. In the context of patient monitoring, objects are represented by the physiological parameters captured from the patient's body; services are the regular updates of messages tracking these parameters; contexts are patients clinical conditions and risk situations; and the application abstractions represent any applications that can transform and present information, such as the health tracking system itself and data mining applications.

In addition, a three-tier approach for IoT-based solutions is usually referred to in the literature and possesses the factors of perception, transportation, and application layers [20,75]. In our context, we referred to Data Acquisition, Data Distribution, and Application layers playing the roles of sensing the real world, integrating with the virtual world, and transforming data into relevant and valuable information, respectively.

Patient monitoring IoT solutions also face the following challenges inherent to IoT applications and exacerbated during COVID-19 pandemics: (i) scalability; (ii) interoperability; (iii) network dynamics; (iv) context discovery; (v) reliability; (vi) and privacy [45,73] [76] [77] [–78]. Each of these considerations were addressed by our proposal and are described below.

First, scalability was handled by the use of an asynchronous approach using the Pub-Sub data distribution paradigm, which allows several processes to access the same information in parallel. The scalability of Pub-Sub solutions is well-established in many fields [79,80]. Further, part of the context discovery processing is distributed and performed within the W-Kit in our solution. This feature offloads processing and regulates the frequency of messages, reducing the number of transmissions and, consequently, network traffic. In this manner, the scalability of our solution is improved, which is essential for any solution dealing with a large number of COVID-19 cases.

Interoperability with third-party sensors is also handled in the Data Distribution Layer using a proxy approach that converts the proprietary formats of those sensors to data patterns utilized internally. Moreover, our messaging broker is agnostic to the payload encoding formats. One possibility is JSON-Linked Data (JSON-LD) as message payload formats to map key and values to standard semantics vocabularies. JSON-LD allows the link of keys and value pairs to well-defined ontologies, which serve as a shared knowledge ground for integrating the monitored data to external applications that recognize such ontology [69]. Standard interfaces like RESTful and WebSockets for integrating the solution with other entities, such as public health agencies and research institutions, were also accounted for in our design, as sharing information during a pandemic outbreak is essential.

Network dynamics in our context are expressed in terms of adding and removing new patients, W-Kit mobility, and intermittent connections inherent from wireless communications. The connection and disconnection of W-Kits represent the entrance and exit of patients to our platform. This process is performed effortlessly and transparently by the establishment of radio connections between the W-Kits and gateways. In hospital wards, the environment is controlled, and the disposal of gateway devices will determine radio ranges. Handovers between gateways are not critical since a mechanism of application-level acknowledgments controls the state transactions. At home, the gateway function is performed by the patient's smartphone, which can be easily carried everywhere. Regarding intermittent connections, the communication between W-Kits and gateways is reliable as the message receipt is confirmed and can be re-transmitted in case of failures.

The system supports several intelligent mechanisms for context discovery. Clinical status is detected by the implementation of a configurable early-warning system, such as the NEWS-2. Given the extensive and successful use of NEWS-2 in infirmaries to detect changes in clinical status of COVID-19 patients [37,38,47], the system can infer a deterioration in the patient's health promptly and efficiently, alerting the staff to take appropriate measures. This is specially true considering that the majority of variables monitored by the NEWS-2 are related to COVID-19 [59–62]. Moreover, remote processes running on the cloud, such as the stream processing module, can apply complex event rules to identify temporal patterns in shorter and longer time series. Monitored data can also be integrated with other electronic medical records’ properties to assess the patient's health condition. At the same time, external proprietary sensors can provide additional readings through the External API modules that are processed by the assessment routines in the cloud. The Data Processing layer can generate new alarms or cancel previous alarms based on current and past patient information. It can also process and integrate information collected by the User Applications, such as the use of supplemental oxygen and the level of consciousness. User Applications can also collect reports of COVID-19 symptoms from users to classify risk and support medical decisions. Further, patients monitored outside clinical facilities may inform their location, which can be used to analyze different aspects of the pandemic, such as the viruses’ relationship with geographic and environmental settings.

Moreover, compared to the standard monitoring frequencies of approximately three times per day in wards [37], the regular tracking of physiological parameters can be updated every 5 min or less and can be checked remotely, enhancing the quality of care. It is also important to note that our architecture supports remote patient monitoring outside hospitals. Given the social distancing and quarantine policies implemented to mitigate the spread of the pandemic, a system such as the one proposed in this paper can be of great help in monitoring individuals who do not have prompt access to healthcare (such as in rural areas) as well as COVID-19 patients who are self-isolating at home.

The proposed solution also implements several mechanisms to assure the reliability of the system in different layers:

• 1The early-warning system is embedded on devices to uncouple the dependency of remote processing and reducing latency.
• 2Event management monitors disconnected W-Kits and detect if messages are not being sent regularly.
• 3An internal W-Kit process checks battery levels and warns when levels are low.
• 4All communication is based on reliable protocols with acknowledgment messages in different layers.
• 5Critical messages, such as alarms, are configured to a higher quality of service levels in the Pub-Sub messaging infrastructure.

Finally, ensuring the privacy of participants for healthcare solutions is vital. Acts that regulate the collection and use of identifiable information typically state that security measures to ensure the privacy of individuals must be implemented [40]. Our architecture does not use identifiable information from participants unless strictly necessary and with explicit consent from the data owner. Moreover, a consent management module is integrated into the architecture (and we propose using a blockchain-based consent platform, as described in previous sections), which allows efficient management of patient consent. W-Kit agents are notified via configuration parameters if the patient's consent is revoked, in which case the agent stops monitoring immediately to respect user privacy.

Table 3 summarizes the key elements of our proposed architecture that are distinct to the combat of the COVID-19 pandemic.

Table 3.

Summary of the distinct features of the proposed architecture.

Sensinglayer
∗ Physiological sensors (skin temperature, heart rate, blood oxygen saturation, respiratory rate, and blood pressure), aimed at detecting most common COVID-19 symptoms.
∗ An early warning score system (NEWS-2) to assess COVID-19 patient health status efficiently.
∗ Assessment of patient health status embedded within the wearable device, working independently of an internet connection.
∗ Self-adaptive and context-specific features that extend battery life for reducing operational costs of the W-Kits and the gateways.
∗ Flexible and customizable score system to individualize assessments of health condition.
∗ The use of affordable and pervasive technologies to be used inside and outside hospitals, a requirement during pandemic outbreaks.
∗ Efficient radio protocol customized to run on crowded wards.
∗ Sensors and devices do not carry any patient's identification, and transmitted packets are encrypted.

Data Distribution layer
∗ Asynchronous Message Bus based on the Pub-Sub paradigm for handling scalability.
∗ Use of secure communication channels to protect data privacy.
∗ Proxy interface for accessing third-party sensors (increased coverage).
∗ Agnostic payload formats (facilitate interoperability with other systems).
∗ Data distribution is subjected to consent permissions from the patient or substitute decision-maker.

Application layer
∗ Interface with a Consent Platform based on blockchain.
∗ Interface with Public Health Agencies (pandemic management).
∗ Interface with machine learning, stream processing and big data systems (learning, prediction, classification, and support for decision-making).
∗ Interface with Legacy Systems (enriched data attributes).
∗ Mobile and dashboard views of monitored data.
∗ Alarms and messages aimed to caregivers and health staff.
∗ Verification of consent profile for data distribution, storage, and use of information.

8. Conclusion

This article describes in detail an IoT-based conceptual architecture for a COVID-19 patient monitoring system. The solution incorporates a valid and widely used early-warning score method for checking and monitoring hospitalized patients and contains a mechanism for customizing this assessment method to ensure the individualization of assessments. Moreover, IoT-based remote monitoring systems face many challenges, and this article discussed how system features could improve scalability, interoperability, network dynamics, context discovery, reliability, and privacy. Architectural sensitive points and potential risks were also discussed, addressing the ratification in a production environment, managing heterogeneous devices, energy autonomy, access to an internet connection, and privacy requirements. Regarding the latter, our proposal gives a particular emphasis on a consent management module and a blockchain-based platform for consent management. The proposed platform maintains patients’ privacy rights by securely storing individual consent and allowing the implementation of procedures to check that they are not violated.

The architecture also presents mechanisms for integrating the monitoring system with external sensors and legacy applications. In this sense, a Data Distribution Layer based on the Pub-Sub paradigm gives enormous flexibility for data exchange among distributed modules. Moreover, the article describes simple and well-defined modules in our architecture, allowing them to communicate directly using service-oriented interfaces.

Our architecture also provides modules for data analytics. Hereupon, we passively collect patient information and actively analyze health data to provide patients and health professionals with feedback and insights. The architecture design also supports two common scenarios for treating COVID19 patients: in a hospital ward and at home, and this work presents some possibilities in using the solution to help authorities and researchers to control and combat pandemics outbreaks.

This study is part of a collaborative work of several research groups. Future work will involve investigating the validity of sensor data using different sensing technologies (e.g., collecting skin temperature using optical, resistance, and thermocouples sensors). We will also analyze energy consumption using different message frequencies and wireless technologies. Furthermore, we will study the distribution of robust context discovery algorithms to the devices and compare them with centralized models. Methods for device customization based on machine learning algorithms and stream processing will also be studied and mechanisms for integrating data protection policies in embedded software agents. Finally, we intend to instantiate this architecture for the two described monitoring scenarios.

Ultimately, the solution proposed here will support public health efforts and allow for smarter, safer, and more efficient monitoring of COVID-19 patients and future pandemic outbreaks.

Declaration of Competing Interest

The authors declare no conflict of interest.