A Cloud Infrastructure for Health Monitoring in Emergency Response Scenarios

1. Introduction

The rapid development of advanced technologies such as the Internet of Things (IoT), Cloud Computing, and fifth-generation broadband mobile networks (5G) has led to innovations and new opportunities in many fields. In particular, the use of innovative ways to address common medical healthcare challenges, is now a reality: the acquisition of large volume of clinical data, the remote monitoring of patient at their home or in environments other than the hospital settings, the effective data sharing and collaboration amongst medical centers, the aggregation of (often incomplete and noisy) data and the exploitation of such data in application with strict time and cost constraints, just to cite a few.

Continuous monitoring of vital signs plays a crucial role in modern e-health systems, encompassing hospital settings such as intensive care units, home care for elderly individuals, emergency management, and risk reduction in occupational settings. In these scenarios, stress levels can be measured through the use of miniaturized and wearable IoT devices, which are integrated into the clothing of operators and can continuously acquire bio-signals. By utilizing appropriate computing systems, these raw signals can be processed in real-time, enabling the creation of comprehensive solutions for remote monitoring. This includes data acquisition for offline analysis, tracking operator health, and managing alarms triggered by specific events.

Despite extensive research in the field of e-health monitoring, a lack of versatile solutions or generic frameworks that can be easily adapted to meet specific requirements currently remains. The challenges in developing a comprehensive healthcare monitoring system include time and budget constraints, difficulties in integrating various hardware and software technologies, and the need to integrate solutions into existing ICT systems. Where the use of wearable devices is a crucial factor, the availability of truly comfortable and functional solutions remains very limited.

The integration of wearable IoT technology into e-healthcare services has gained increasing attention, as demonstrated by constant growth in worldwide revenue for the IoT market [1] and extensive scientific literature [2,3,4,5,6]. The general architecture of IoT in e-healthcare comprises five connected components: (1) Sensor devices that gather data from the environment or patient, (2) Networking for transmitting data via networks such as Wi-Fi or cellular, (3) Edge devices that perform local data processing, (4) ICT platform for collecting, storing and processing data from multiple sources, and (5) Application interfaces for healthcare providers and patients to access data and make informed decisions. Approaches discussed in the literature focus on different aspects. In the context of this study, the infrastructure proposed in [7] aims to optimize large-scale data acquisition from a heterogeneous set of IoT medical sensors, with a primary focus on real-time emergency response. A prototype system for monitoring oxygen saturation (SpO2) and electrocardiogram (ECG), and for alerting in the waiting area of an emergency room, is proposed in [8]. The work presented in [9] aims at implementing an infrastructure for patient localization and tracking with the goal of classifying movements and detect hazardous situations. Other studies, such as [10] and [11], explore the usability and feasibility of a system that combines Bluetooth (BT) and Near Field Communication (NFC) technologies, whereas [12] focuses on the remote monitoring of elderly patients using ZigBee-enabled devices. Other relevant works include [13], which highlights the importance of the message-broker pattern for decoupling data producers and consumers, thereby enabling the use of distributed computing. Additionally, [14] demonstrates how an IoT system can be constructed using cost-effective devices and incorporating teleconsulting services in the pipeline to facilitate doctor collaboration. Furthermore, [15] proposes a solution in which data is collected by a gateway through a low-power Wide-Area Network (WAN) that also incorporates alarming functionality on the edge devices. In [16] the IoT devices are equipped with Wi-Fi connectivity so can work independently on a mobile gateway. An important class of proposed solutions focuses on architectural aspects [17,18] and in particular Cloud Computing [19,20]. For instance, [21] focuses on monitoring Mild Cognitive Impairments (MCI) and Chronic Obstructive Pulmonary Disease (COPD), while [22] addresses the monitoring of vital signs obtained from printed wearable devices and remote data processing. Additionally, [23] proposes a cloud solution for fall detection.

Cited references generally provide good solutions for the specific described problem and suggest architectural patterns for the development of new solutions. However, their scope and applicability appear to be limited. Moreover, none of these solutions seem to be generic enough to be readily used in other applications with minimal customizations.

In this paper we describe a project developed in collaboration with the Italian National Red Cross Society, aimed at monitoring the health status of personnel involved in rescue operations. As part of this project, a large-scale application has been developed to enable real-time monitoring of vital signs using Internet of Things (IoT) technologies. The focus of this paper is to explore the potential of IoT technologies for monitoring vital signs in a large-scale setting. Through the use of sensors and other IoT devices, the application is able to continuously monitor the vital signs of rescue personnel and provide alarms if any deviations from normal values are detected. This can help ensure the safety and well-being, as well as enhances the overall efficiency of rescue operations.

The analysis of needs identified several application specific requirements, including: (1) a website that allows all personnel involved to access data within a security schema (ACL-like) that specifies which users are granted access to each type of information; (2) integration with the existing authentication system; (3) an onboarding tool for the rapid registration of volunteers interested in the study, including the acquisition of necessary information such as GDPR consent; 4) management of clinical and anamnesis information and to automatically evaluate general eligibility over time; 5) IoT wearable devices for monitoring vital signs along with related ICT components for online and offline use of acquired data; (6) real-time analysis of vital signs to identify changes in health conditions that may lead to potential risks and the generation of suitable alert events; (7) management of the alarm workflow, including involvement of medical staff, assignment alarms to appropriate specialists, and closing of resolved or false positive alarms.

These requirements are well suited to be addressed with a Microservice Cloud Computing Architecture. The cloud is a new way of delivering computing resources, such as storage and processing power, over the internet in a distributed way. The architecture of cloud-based systems is constantly evolving to meet the needs of these systems, and one popular approach is the use of microservices. A microservices architecture involves breaking down a large, complex system into smaller, independent components that can be developed, tested, and deployed separately. This can make it easier to scale and update the system, as well as make it more resilient to failure.

The proposed architecture is based on the orchestration of a set of software components that have been independently developed and deployed on the Amazon Web Services (AWS) Cloud Platform in order to receive and manage data coming from the Hardware components (IoT) that consists of wearable devices connected via Bluetooth to a mobile smartphone which acts as a data collector and a gateway for the mobile network.

There are several advantages to consider when deciding whether to adopt cloud computing infrastructure for a health monitoring system:

1) Scalability, to automatically address the fluctuation during the time of the number of users and in particular the number of requests to access data and services. Cloud Architectures are designed to easily scale up or down as needed.

2) Cloud computing is more cost-effective than building and maintaining in house infrastructure, especially if it is expected to have a large amount of data and services.

3) Cloud providers typically implement robust cybersecurity measures, which are especially important when handling sensitive patient information.

4) Reliability: Cloud infrastructure providers have redundant systems in place to ensure the High Availability of their services.

5) The collection of bio-vital data carried out via a comfortable wearable device allows the parameters to be monitored for a long time without any relevant discomfort for the user.

2. Materials and Methods

2.1. Cloud Architecture

In this paragraph, we will describe the general cloud architecture of the proposed solution, and in the following paragraphs, we will delve deeper into each component. The architecture schema (Figure 1) illustrates the main components of the system, their interactions, and the data flow generated by IoT. These components are divided into four main layers: 1) The IoT layer includes the IoT hardware components (the device sensor printed onto a t-shirt) and the software components that directly interact with them, primarily a Message Queuing Telemetry Transport (MQTT) microservice that receives IoT measures generated from the devices; 2) The persistence layer consists of a Structured Query Language (SQL) database for managing the web application and some NoSQL databases that store IoT measures and alarms; 3) the web frontend and backend layer exposes a website for accessing the application from end users and also includes a set of Application Programming Interface (API) for automating specific procedures (onboarding, device assignment to users, data export, etc.) as explained later; and finally the 4) Analytics Layer is responsible for filtering incoming data streams, ensuring data quality, processing raw data and generating real-time alarms based on predefined criteria.

Each layer is made up of several interacting services that are all secured with authentication and SSL communication. Additionally, all services are deployed in an elastic environment, where elasticity refers to the system’s ability to automatically provision or deprovision resources in response to workload changes throughout the system's lifecycle. This feature is crucial for achieving cost reduction, reliability, and prompt response times. Table 1 displays implementation details for each service in the platform.

2.2. IoT Layer

The IoT layer includes both Hardware (HW) and Software (SW) components for continuous multiparameter monitoring. The YouCare medical wearable device (Accyourate wearable technology, [24]) consists of textile garments equipped with innovative non-invasive polymeric sensors embedded in the clothing via ink-jet printing. These devices' wearability and ergonomic characteristics enable a novel method of detecting biovital and kinetic parameters, providing dynamic, real-time measurements of an individual's status. The device, which is a type IIa certified medical device, resembles a T-shirt that covers the upper chest. It has been used to monitor several biovital parameters in home settings and during everyday activities, across different contexts such as healthcare, workplaces, sports, and scientific research. The parameters measured and calculated included heart rate (HR), respiratory rate (RR), skin temperature (SkT) [5,25], and heart rate variability (HRV, expressed as time-domain and frequency-domain parameters) [26]. The sensors within the device, which offer comfortable wearability and favorable ergonomic features, also detect kinetic parameters, enabling dynamic, real-time measurements. Sensor signals are digitized and processed by a miniaturized wearable control unit, which records the data and transmits it to a smartphone app via Bluetooth. The control unit is equipped with various sensors, including a BLE module based on SoC NORDIC nRF52811, Bluetooth 5.1 Low Energy, ECG (1 channel, 16-bit resolution), respiration monitoring (1 channel bioimpedance, 20-bit resolution), temperature, accelerometer, gyroscope, shock detection, 8MB memory, RGB LED, Micro-USB charge, 3.7V 190mAh battery, autonomy > 30 hours, 9.5g weight, 250 Hz sampling frequency, and 2-channel analog front end (24-bit delta-sigma converter). The device's quality was previously assessed in a study [26] that compared 7200 ECG signals from 20 patients with those acquired from a commercial ECG monitor in a controlled clinical setting.

Table 1. Description of the components of the Cloud platform.

Component	Description
Web Worker	A stateless virtual node that manages http requests coming from the web clients.
Load Balancer	A component that distributes the http request over a set of web workers and manages the number of active nodes based on the overall load
Relational Database	The main database for operational activities including individual registry, device management and alert management.
TimeStream Database	NoSQL database for time stream data such as ECG, Respiratory Trace and heart Beats per minute (BPM).
Simple Queue Service (SQS)	A component that uses using message queue to handle asynchronous communication between microservices ensuring decoupling of components
Lambda Function	A serverless and event-driven computing service used to manage asynchronous tasks such as the generation of alarms
IoT Core	The component that handles the connectivity between the Internet of Things (IoT) devices and the backend cloud platform using a publish/subscribe communication based on (MQTT) protocol

Table 1. Description of the components of the Cloud platform.

Component	Description
Web Worker	A stateless virtual node that manages http requests coming from the web clients.
Load Balancer	A component that distributes the http request over a set of web workers and manages the number of active nodes based on the overall load
Relational Database	The main database for operational activities including individual registry, device management and alert management.
TimeStream Database	NoSQL database for time stream data such as ECG, Respiratory Trace and heart Beats per minute (BPM).
Simple Queue Service (SQS)	A component that uses using message queue to handle asynchronous communication between microservices ensuring decoupling of components
Lambda Function	A serverless and event-driven computing service used to manage asynchronous tasks such as the generation of alarms
IoT Core	The component that handles the connectivity between the Internet of Things (IoT) devices and the backend cloud platform using a publish/subscribe communication based on (MQTT) protocol

Each sensor detects raw parameters, which are processed to generate derived parameters following the data flow outlined in Figure 2. Depending on system configuration and internet connectivity stability, derived parameters can be computed remotely in the cloud (cloud), locally on the smartphone CPU (edge), or through a hybrid approach. Raw parameters include ECG traces (one channel at 4000 MHz), respiratory traces, body temperature, and motion data. The first level of derived parameters includes BPM (heart rate), RespRate (respiratory rate), fall detection (frontal, lateral, and posterior), and shock detection, all computed from raw signals. The second level involves the generation of alert events to identify anomalies or abnormal health conditions.

This process facilitates real-time data exchange with the cloud platform, where the post-processing and analysis of collected data occur using dedicated, proprietary software and algorithms. Raw data, except for specific cases delegated to the smartphone (e.g., skin temperature conversion, fall detection, and so on), are processed in the cloud. Artifacts are identified using the algorithm in [27] and subsequently discarded. Derived HRV time-domain parameters include RMSSD, Standard Deviation (SD) of all NN intervals (SDNN), SD of R-R intervals (SDRR), RMSSD to MeanNNI ratio (CVSD), percentage of successive R-R intervals differing by more than 20ms (pNNI-20) or 50ms (pNNI-50), SD of successive differences between NN (SDSD), Mean of NN (M-NNI), and SDNN divided by MeanNN (CVNNI). Derived HRV frequency-domain parameters include Low-Frequency power (LF), High-Frequency power (HF), LF/HF ratio, normalized LF power (LFnu), normalized High-Frequency power (HFnu), and total spectral power.

The clothing designer assigned sensorized textiles to subjects, ensuring a specific fit to each breast circumference. Each subject received an experimental kit consisting of a YouCare T-shirt (Figure 3A), a control unit (Figure 3B) with an anonymous serial number, and accessories including a battery charger, USB type C cable, and the YouCare app. Each medical device was paired with a control unit using an individual pseudo-anonymized code known only to the scientific staff.

The smartphone app offers typical features for this kind of application: device registration on the platform upon initial access, Bluetooth pairing with the Micro Controller Unit (MCU), authentication, initiation and termination of monitoring sessions, and data visualization.

Before transmission to the cloud platform, sensor datasets are enriched with metadata (user identifier, device identifier, and timestamp), packed in JavaScript Object Notation (JSON) format, and compressed. The data are transmitted using the MQTT protocol, where clients publish messages to specific topics, and the broker manages distribution to subscribers. This decoupling of sender and receiver allows independent message transmission, simplifying the overall architecture's scalability. The MQTT broker, a component of the IoT layer, also communicates with the persistence layer by forwarding sensor data to a NoSQL database and sending MQTT events to an SQS queue for real-time processing by the Cloud Platform. More details are provided in the persistence layer section.

2.3. Data Persistence Layer

The Data Persistence Layer (DPL) consists of components and software interfaces that encapsulate routines for accessing data that needs to be permanently stored in the cloud platform. The two primary data flows feeding the DPL are from IoT devices through the IoT Layer and from the Web User Interface. The first data flow includes streams of ECG and respiratory traces, processed time series (such as BPM and temperature), generated alerts, and messages tracking the connectivity status of the devices. Due to the nature of this information (key/value or unstructured stream format), NoSQL databases were chosen: TimeStream for storing data streams and time series measures, and Redis for storing device status. NoSQL databases offer several advantages over traditional relational databases in this context: they are designed to automatically scale horizontally (by adding new computational nodes) as the amount of data grows; they are well-suited for applications requiring high scalability and availability; and they provide efficient access to large volumes of data.

The second data flow originates from user interactions with the Web Interface for managing clinical and anamnesis data, logistic information about device provision, and the current status and history of active alarms. This data must be managed with respect to authorization and permissions (ACL), using the basic Create, Read, Update, and Delete (CRUD) operations. For this purpose, a relational database (PostgreSQL) was selected, as it provides a static, clear, and well-defined data structure that maps seamlessly to application domain objects.

A set of Lambda functions are also part of this layer. In the context of cloud computing, the lambda function is a flexible way to provide event-driven computing without taking care on provisioning the underline computational resources. They can be easily connected to input events (for example MQTT or SQS events) and its output can trigger another event making it possible to implement a fully managed data workflow. In the proposed platform the lambda function are used mainly to preprocess the input coming from the IoT Layer and to generate alarm. In particular:

• the computation of BPM rate, Respiratory rate and motion related event
• the computation of health of alerts
• the generation of alarm to be shown in the web user interface
• the updating of the database which contains the status of the devices

As said before, depending on the configuration, all computations performed by lambda functions can be also performed directly by the mobile device (Edge). Finally, Simple Queue Service (SQS) components are used to buffer the input of lambda functions in order aggregate the data in batch and reduce the amount of calls.

2.4. Web Backend/Frontend Layer

The user interface and associated business logic are implemented in the final layer of the system's architecture. This layer includes a web backend built using the Flask microframework, which provides an API for the web frontend. The backend microservice implements OpenID+JWT-based authentication and interacts with both SQL and NoSQL databases to retrieve data for the user interface.

The backend system has been deployed on an elastic load balancer, which automatically distributes incoming traffic across a group of servers. This helps to ensure that the backend can handle a high volume of traffic and can scale up or down as needed to meet changing demand. The load balancer routes incoming requests to a pool of worker servers, which are responsible for processing the requests and returning the appropriate responses. The number of worker servers can vary over time, depending on the workload, allowing the system to adjust its capacity as needed to handle the load.

The topmost component of the system is the web interface, which is implemented using the Vue open-source JavaScript framework as a single-page application (SPA). It is based on the model-view-viewmodel (MVVM) paradigm, which separates the application's data model from its presentation layer and allows developers to build complex, interactive user interfaces more easily. The web interface allows to perform all operations necessary to view and modify data and to monitor the IoT parameters with plots and forms. See Figure 4 for more details.

One of the main features of the interface is to open and maintain during the web sessions, a stable connection with the Data Persistence Layer through a MQTT-based websocket client. The client subscribes to the topics necessary to maintain the interface up-to-date in response to new IoT events. In particular it is used to show the status of the devices (connected / disconnected) and to receive alarms in real-time.

2.5. Analytics Layer

This layer undertakes the tasks of processing incoming data streams, implementing several algorithms of filtering, artifact detection and QRS and BPM computation. Identifying artifacts poses a critical and recurring challenge in IoT systems, given the typical deployment of IoT devices in uncontrolled environments. The main causes include poor device placement, interference issues, and anomalous body movements that could interfere with the acquired signal.

ECG analysis: The ECG analysis is performed with methods specifically developed for the device in use: filtering and artifact detection is performed with an algorithm [28] that leverages the distinct measurable statistics in good signals compared to artifacts within a 2-second window; ECG signal are then processed to extract the QRS with a variant [25] of the well known Pan-Tompkins method [29], finally the BPM is evaluated as an average of the number of peaks over a 5s window.

Temperature: The values received at 1Hz from the central unit are cached and sent to the cloud every 5 minutes. These value are not subjected to specific analysis before sending to the cloud platform

Respiratory Trace: The analysis of Respiratory Trace is analyzed with a butterworth low pass filter (order size 4, cut off 4Hz) and averaged with a moving window of 25 samples to reduce noise. The frequency is then computed as a count of peaks every 60s.

Fall detection: Body movements are measured with an accelerometer device incorporated into the central unit and fall is recognized with a sudden acceleration of more than 6g is detected.

Alarms: One of its pivotal functions on the analytics layer is the generation of real-time alarms, triggered in response to detected anomalies or critical events, thus ensuring timely interventions and proactive management. To mitigate the risk of false positives and enhance alarm accuracy, the layer employs a window mean filtering and a mechanism that stops the generation of new alarms if an alarm of the same type is already in open state.

3. Results

In this section we describe the web interface of the proposed application, its main workflows and the performance and scalability analysis.

3.1. Web Interface

The central component of the interface is the Dashboard page (Figure 4A), which displays the history of alarms received by the edge devices. The system manages four types of alarms: abnormal BPM values, abnormal breathing frequency, high temperature, and falls. Whenever the platform generates a new alarm, it is instantly captured by the web interface using websockets. Subsequently, it appears at the top of the list, triggering visual and audible alarms on the web page.

Based on the current permissions and roles (administrator, doctor, operator and volunteer), the user can view a set of clinical, physiological, and anamnestic parameters, as well as outcome of medical visits. Additionally, it's possible to access data from IoT devices such as ECG, respiratory trace and temperature with associated timestamps (Figure 4B).

Figure 4. Some screenshots of the web Interface: A) the dashboard of alarms and B) details page all person related information: registry, health status and monitored parameters during working shift.

Figure 4. Some screenshots of the web Interface: A) the dashboard of alarms and B) details page all person related information: registry, health status and monitored parameters during working shift.

The user can also navigate through temporal data using a menu that allows immediate access to the raw trace associated with the moment an alarm was triggered or other critical points (for example the maximum BPM value). This feature enables visual inspection of the specific data point linked to the alarm occurrence.

3.2. Workflows

The workflow of enrollment of participants is described in Figure 5A. They join after signing an informed consent for data processing based on European General Data Protection Regulation 2016/679 GDPR. Then, they undergo a medical examination to establish an updated and accurate clinical record, crucial for properly configuring device parameters and analyses. At this stage, a volunteer may be excluded from the study if deemed unfit (for instance, in cases of cardiac issues). In research study monitoring scenarios, identification data is removed through pseudo-anonymization methods. Additionally, there exists the provision to exclude patients from the ongoing analysis within the project at any juncture. This exclusion may occur if patients no longer meet the outlined requirements or choose to voluntarily withdraw from their participation in the project. This mechanism ensures the integrity and accuracy of the ongoing analysis by allowing for the removal of data points that no longer align with the project's criteria or are voluntarily retracted by the participants.

The alarm status follows the workflow depicted in Figure 5B. Once an event associated with an alarm is generated, it is immediately displayed on the desktop of the operators of the control center. An operator can promptly reach out to the individual concerned to verify if there have been any technical issues (such as connectivity problems or incorrect device usage) and provide assistance for resolution. If the event is a real health issue, the case is forwarded to the medical center with a priority (low, medium or high), where a doctor handles the situation, conducting a televisit and analysis of the data collected in the immediate time prior to the event. At this point, emergency services can be activated, and the worker's activity can be promptly suspended.

Finally, Figure 4C displays the workflow for offline analysis of ECG signals, which can be performed through automated batch analysis to highlight both technical anomalies (such as excessive noise) and clinical irregularities. Medical staff can annotate the signal with messages visible to the entire team, facilitating a sequence of second opinions on the case, enabling a decision to schedule a visit.

3.3. Case Study

The presented platform has been developed to perform monitoring of vital signs of a group of paramedics and medical workers employed by Italian Red Cross (Croce Rossa Italiana, CRI) during their work session. The invitation to participate was voluntary, following the signing of informed consent forms, and was extended to all CRI national committees of the organization. Compilation of a questionnaire enabled the selection of volunteers based on specific acceptance criteria, which included health status (absence of cardiac disease or motor problems), legal age, weight and height between valid range, and technical specifications regarding the smartphone. Furthermore, medical staff thoroughly evaluated the presence of critical medical history, past interventions, or hospitalizations before confirming inclusion in the experimentation.

Finally each participant received an IoT device, consisting of the sensor-equipped shirt. Additionally, participants will undergo several hours of training on correctly wearing the shirt and utilizing the accompanying mobile application.

According to GDPR only a minimal set of information has been included (see Table 2). Moreover data has been classified in different categories having its own set of permissions based on its use. For example, access to clinical information is granted only to medical staff upon justified request or for the management of critical alarm. Information related to alarm and technical measures are accessible only to operations room staff.

To enhance security measures, OAuth2 and OpenID have been employed for authentication, delegating authentication and permission management to GAIA (Gestione Avanzata ed Integrata dell'Anagrafica) platform of Italian Red Cross [29].

Out of the 3600 invited, only about 2935 participants passed the selection criteria, were recruited and began the experiment after a few weeks. During the study, some participants were excluded for various reasons (personal reasons or errors in parameter recording and so on), leaving 892 who actively participated in the project.

The participants are fairly evenly distributed between male (52%) and female (48%), have an average age of 41.5±14.3 years (40.3±14.9 for male and 43.0±13.33 for female) and are across the entire Italian territory, organized by regional committees, and grouped into northern, central, and southern regions (see Figure 6).

The study lasted approximately one year (330 days with 316 days with at least 1 active device), totaling about 23,000 hours of activity where 1 hour counted for each participant if at least 1 stream signal (ECG or Respiratory Trace) is registered in the platform (see Figure 6 for more information).

In our experimentation, a total of 100GB of persistent data was collected from the wearable devices deployed in our monitoring system being the ECG data the most prominent. This data collection process involved capturing a wide range of vital signs, including ECG and breathing patterns, during various work sessions. The ECG data underwent a rigorous validation process to ensure its quality and reliability. We removed all artifacts and noise from the data using the proprietary methods described before performing any further analysis, which is crucial for obtaining accurate results for intermediates measures and finally for the alarms generation.

A total of about 4000 alerts that were generated throughout the monitoring period more than 72% are related to BPM anomalies and 15% are related to body temperature increasing above the risk threshold. Among these, more than 40% were identified as false positives (artifacts or incorrect wearing of the device). This high number of false positives underscores the importance of continuous refinement of our alerting system. We recognize the need for improvements to reduce the incidence of false alerts and enhance the precision of the alerting mechanism, ensuring that only real issues are flagged in order to make accurate evaluation of the risk in working activity.

Looking ahead, we plan to implement a comprehensive clinical labeling process for the ECG data. This process will involve categorizing different types of ECG events and correlating these events with the clinical data collected. Our goal is to conduct an in-depth correlation analysis between the clinical data and the alerts received. This analysis will help us to better understand the relationship between vital sign patterns and real-time alerts, contributing to the refinement of our monitoring platform. Our future work aims to improve the predictive capabilities of our system by enhancing its accuracy and reliability. By doing so, we hope to not only improve emergency response but also gain valuable insights into vital sign trends and their connection to alert events. This ongoing research will play a crucial role in advancing our understanding of how wearable technology can be optimized for effective health monitoring and emergency management.

4. Discussion

Continuous vital sign monitoring is pivotal in modern e-health across hospital, home care, emergency management, and occupational safety, but it is a task laden with technical complexities mainly related to the management of real time data.

We introduced a cloud-based monitoring architecture aimed at remote vital sign tracking for paramedics and medical workers leveraging the potential of low-cost and wearable IoT sensors. The continuous monitoring of vital signs, such as ECG and breathing, emerges as a pivotal tool in emergency management, reducing risks during rescue operations and ensuring worker safety.

This solution, equipped with inherent resilience and elasticity, circumvents the limitations of traditional infrastructure and addresses the challenges posed by massive data volumes, network congestion, and computational demands inherent in IoT monitoring. Moreover it orchestrates the management of essential health metrics during work sessions, providing real-time alerts to a central personnel management center. This implementation empowers efficient tracking and immediate response to critical events, exemplifying the practical application of wearable IoT technology in safeguarding frontline workers' well-being. The performance of the system in its critical paths has been evaluated and implemented in order to assess scalability and robustness in view of bigger case studies. In particular, caching systems and elastic features (resource adaptation based on load) has been adopted in all data paths of the cloud infrastructure.

This technological model is guided by a cooperative intent, making multidisciplinary collaboration possible even in particularly challenging areas such as research on pathologies with syndromic conditions that are difficult to investigate, unless solutions such as YouCare and its monitoring platform are available. A study conducted on RETT syndrome carriers and their caregivers was recently published [31], through real-time monitoring of biovital and environmental parameters, in which YouCare played an essential role in the success of the research. Furthermore, several studies based on the telemonitoring of adapted physical activity are underway, involving research groups operating in Neuromotor Science, Physiatry, Pharmacology and Psychology. Moreover, it shows how complex scenarios can be challenging ecosystems for the growth of highly innovative solutions like WaidX, increasing the diffusion of good health practices and boosting the use of modern technologies in healthcare.

The application of such advanced wearable technology is an example of how technological innovation can act as a game changer, if designed for the specific needs of particular user groups and operators, enhancing the diffusion of modern approaches for healthcare and research.

As future works we are planning to further develop the platform in three direction: 1) a new advanced textile technology able to integrate three ECG derivations in order to perform a full compliant Holter clinical examination; 2) embedding a 4G and 5G modem for directly transmit data to the cloud without the mediation of a smartphone; 3) a set of new and more accurate cinematic sensors (IMU) will be integrated and motion detection data will be acquired into the cloud platform.