Keywords

1 Introduction

According to the World Health Organization (WHO), about 17.9 million people die per year from to cardiovascular diseases (CVDs). This is more than 32% of all the deaths recorded worldwide, with more than 85% of these deaths caused by heart attacks and strokes, sub-categories of CVDs [1]. Furthermore, the European Society of Cardiology (ESC) reports frightening data related to CVDs-caused worldwide deaths. As [14] states, CVDs remain the most common cause of death within the ESC member countries, exceeding the number of cancer deaths for both sexes. These data underline the importance of patients’ continuous health monitoring, especially for the case of heart failures (HF).

In addition, the worldwide pandemic of Covid-19 has shed light on the critical importance that a new generation of remote health monitoring systems are available. These systems should enable physicians and clinicians to effectively supervise patients remotely, with patients being in their home premises. This is already partially possible, but most of the available systems are non-real-time, providing data in batches once or twice a day, and require both a mobile private and carrier-operated connection, and an access to a private cloud operated by the system manufacturer. These last are high-cost facilities for the healthcare system, and does not allow a full control of the monitoring parameters and periods. Remote monitoring systems should instead support for a continuous and real-time feed of data, measured with the help of potentially wearable devices, able both to analyze and record a selected set of vital parameters, with clinical accuracy levels, and to promptly identify significant events, possibly by means of Artificial Intelligence (AI) algorithms. In this way, the need for hospitalizations would significantly decrease, consequently increasing resource availability for major emergencies as well as reducing the patients’ waiting time.

In light of the previous considerations, a novel concept of remote healthcare device can be devised, which may leverages on a sensor fusion approach to enhance analysis capabilities and accuracy, and which is able to provide a continuous and real-time signal analysis. In this paper, the preliminary design of a Smart Healthcare Modular System (SHeMS) is hence proposed, based on a modular paradigm and Internet of Thing (IoT) technologies to enhance both customization and availability of services almost everywhere, and free from carrier-operated services. Modularity is a characterizing feature, allowing the system to be composed around of and adapting to the specific disease and needs of each patient, realizing an interesting reality merging home treatment and care. SHeMS has been devised to provide a seamless, real-time and bi-directional relationship between patients and clinicians, also allowing remote diagnosis, reconfigurability and sensors calibration.

To this goal, the description of this remote monitoring system (SHeMS) prototype is provided where a central unit, hosting the main computing and IoT capabilities, is a gateway for secondary specialized sensing elements. Some of the considered sensing units could be possibly worn by patients, thus directly acquiring and sending to the main computing unit the signals representing relevant vital parameters. The considered vital signs can be related to heart rate (HR), arterial oxygen saturation (SpO2), blood pressure, body temperature and dehydration. Thanks to the modularity of the SHeMS system, additional sensing units could possibly be inserted, e.g. glycemic sensors for diabetic patients and posture sensors. Auxiliary units can be also employed, in order to both test the patient’s cognitive competence, through vocal messages, or to simply assist the patient himself/herself and check for some eventual feedback.

This article is organized as follows. First, an introduction and explanation of the vital parameters to investigate will be presented in Sect. 2. Then, in Sect. 3, the needed general specifications will be provided, together with the discussion about the actually employed components. The employed communication protocol is briefly explained in Sect. 3.4, whereas the currently developed software is discussed in Sect. 3.5. Furthermore, a discussion about employed algorithm for the ECG signal manipulation and peaks detection is carried out in Sect. 4, with an emphasis on the future works the authors are committed to. Finally, the most relevant conclusions will be provided in Sect. 5.

2 Vital Parameters of Interest

In order to realize the modular system introduced in Sect. 1, it is necessary to investigate the main vital parameters that should be common for each patient, independently of the clinical history of each subject. The electrocardiographic signal analysis, namely ECG, through the electrocardiogram is the most common test to diagnose CVDs in hospitals [4], thus it is the most important parameter to be investigated. Indeed, through some signal processing algorithms, it also allows to compute the heart rate, another important indicator for CVDs diagnosis. The ECG signal, whose trace is represented in Fig. 1 is constituted by three main components, or complexes:

  • P waves;

  • QRS-complex;

  • T waves.

Fig. 1.
figure 1

ECG signal trace

Full size image

P-waves, in physiological conditions, alternate periodically. More in detail, they represents the atrium depolarization, thus occurring for first and has a general duration of about \(110\,\textrm{ms}\) [8]. After P wave, the QRS-complex is registered. It is constituted by three different peaks (namely, Q, R, S) and represents the depolarization of the ventricle, defining the onset of the ventricular contraction. Its normal duration ranges about \(60\,\textrm{ms}{-}100\,\textrm{ms}\) [13] and it is the easiest complex to identify, due to its amplitude with respect to the other waves. The last complex that is worth mentioning is the T wave, thus the representation of the ventricle repolarization [7]. Its duration in physiological conditions is about \(100\, \textrm{ms}{-}250\,\textrm{ms}\) [9]. After describing the ECG signal components it is possible to conclude that the spectral content of the ECG signal belongs to the low frequencies range (approximately \(0.5\,\textrm{Hz}{-}150\,\textrm{Hz}\)). Foreseeing the useful signal contributes, the highest frequency contribute is contained into the QRS-complex. The lowest frequency contribute is instead contained into the P and T waves, even though they are important indicators of many CVDs. From the analysis of the ECG peaks and characteristics it is possible to detect heart anomalies, together with the heart rate. From the heart rate, another parameter of interest, it is possible to extract the heart rate variability (HRV), that records the beat-to-beat variations of HR, and the intervals between R-R peaks intervals (QRS-complexes) [10]. Another important parameter strictly related to CVDs and other relevant diseases is the blood pressure, namely BP (both systolic and diastolic). As [16] states, there is a strong and significant association between BP and risk of CVDs and this relation is independent of other risk factors for CVDs (e.g. age, gender, body weight). For example, hypertension is considered the leading preventable risk factor for both CVDs and all-cause mortality in developing countries. Blood oxygen saturation (SpO2) and temperature are two additional parameters to be taken into account since they allow the clinician and the patient her/himself to check the general state of health, that in many conditions is an important indicator for patients affected by CVDs.

3 General System Description

The architecture of the proposed SHeMS system is represented in Fig. 2, and is constituted by three main blocks:

  • Data acquisition block;

  • Data collection station block, simply constituted by a Raspberry Pi3;

  • Backend PC block, currently under development.

Fig. 2.
figure 2

SHeMS general architecture

Full size image

In summary, the mainly employed components are resumed in Table 1.

Table 1. Employed components
Full size table

3.1 Data Acquisition Block

An important requirement for this block is to be lightweight and sufficiently small, since it has to be worn by the subject. Its simplified schematic is represented in Fig. 3, where a microcontroller based on the ESP32 architecture is shown on the left, whereas the rightmost module is the measuring sensor, which receives input data directly from the patient. The sensing unit represented in Figs. 2 and 3 is only one of the possible employable devices.

Fig. 3.
figure 3

Data acquisition block preliminary schematic

Full size image

In particular, the current choice has been on a ECG-trace recording based on the AD8232 chip, represented in Fig. 4a [2]. This is a small and cheap integrated signal conditioning block for ECG signals, which specifically allows to manipulate single-lead acquired ECG signals, thus allowing a two or three electrodes configuration. Thanks to its specific internal design, it amplifies and filters the small biopotential signals received by the electrodes, also in noisy conditions. As reported in its datasheet [2], the AD82838 allows for an ultralow power analog-to- digital converter (ADC) or an embedded microcontroller to easily acquire the output signal. For this work, all three electrodes have been employed. Two of them were placed in the wrists, to acquire the biopotential that has to be effectively examined. The third has been placed in the right lower pelvis, in order to reduce the common-mode interference [15].

Together with the AD8232, the data acquisition block is constituted by a microcontroller directly connected to the sensing unit. In this case, an ESP32-WROOM-32 [6] has been employed, which is represented in Fig. 4b. This module presents some significant advantages, the main being:

  • Cheapness;

  • Compact size and low weight;

  • Built-in IoT/network support;

  • Printed on board antenna;

  • Dual-core possible operation.

Fig. 4.
figure 4

Components currently employed in the data acquisition block

Full size image

One of the most attracting feature of the chosen computing module is its intrinsic support for data transmission over a Wi-Fi network. This is an ideal feature for this project, since the data acquired from connected sensors can be previously stored in a convenient format, and then sent to a data collection unit, or central gateway, the second block of SHeMS, which resides in the surroundings of the patient, typically within the same building. This will allows module-to-module communications without the need for further network support, and also might possibly exploit already existent Wi-Fi networks. Furthermore, an extremely interesting feature is the presence of two cores, since due to the high amount of data to be acquire and then transmitted, it is hence possible to split the workload in parallel over the two cores, with one continuously managing the sensing units for data acquisition, and the other one instead devoted only to the management of the network interface.

It is worth mentioning that although this work will only briefly discuss the simulation viewpoint in Sect. 4, between the AD8232 and the ESP32 control unit a filtering stage for noise suppression has been designed. In particular, the main noise sources are [5]:

  • Baseline wander, caused by different factors, such as respiration, body movements, poor skin-electrode contact;

  • Powerline interference;

  • Muscle artifacts.

3.2 Data Collection Block

This block is mainly constituted by a Raspberry Pi3 located in the same building of the data acquisition block, as previously mentioned in Sect. 3.1. Basically, it should continuously acquire data, received from the data acquisition station, for a quite long amount of time (e.g. a couple of hours), to let the clinician check the patient health status. After the data collection, it simply elaborates it, following the logic briefly presented in Sect. 4. So far, the latter has been simulated on Matlab, thus not guaranteeing sequentiality between data acquisition and elaboration. The authors are committed to reproduce the same algorithm in another programming language, in order to let Raspberry Pi3 do the final data elaboration.

3.3 Backend PC Block

This block is currently under development but it has been thought as very simple. In particular, it should only display the elaborated data and the relative results, thus merely being a User Interface for the clinician to finally check the patient’s health status and not having any computational power. Needing to be used by a clinician, it will not be located in the surroundings of the patient but, hypothetically, in the clinician’s office. To this aim, the authors will use Wi-Fi technology for the data transmission between the backend PC and the data collection block.

3.4 Employed Communication Protocol

After introducing the general system architecture, it is worth spending some words about the communication protocol stack chosen for data exchange over Wi-Fi, namely MQTT (Message Queue Telemetry Transport).

This is a widespread, simple and lightweight publish/subscribe communication protocol, very interesting for IoT applications (employed for instance in healthcare, energy and utilities, social networking [12]), especially for the case of limited-capabilities smart devices [11], as those employed in this work. It relies on the TCP/IP classic protocol stack, and in particular it typically exploits TCP at the transport layer to ensure the needed reliability. At the same time MQTT is lightweight in that it defines control messages with a very low overhead: these require just a 2 Bytes fixed header, which can be possibly expanded, followed directly by the user payload.

At the base of the MQTT protocol there is a Publish/Subscribe model [12]. Here, the Publisher publishes messages to the Broker, while the Subscriber subscribes to the so-called topics, that can be basically considered message subjects. When subscribing to particular topics, the Subscriber is able to receive every message published to the latter ones. The architecture of an MQTT network involves the entities Client and Broker. More in detail, as it is possible to see in Fig. 5, the Client can be both a Publisher or Subscriber and is in charge of establishing the network connection to the Broker. A client, once connected, can publish messages relevant to a specific subject, subscribe to other subjects for receiving messages, unsubscribe to subscribed subjects, and detach from the Broker [12]. The Broker in turn receives all the messages from the Client, thus being able to decide whether to accept or not Client requests. Furthermore, it can receive published messages by the users, process different requests like Subscribe and Unsubscribe from the users and send the latter to the users.

Fig. 5.
figure 5

MQTT protocol architecture

Full size image

MQTT supports three levels of Quality of Service (QoS):

  • QoS0: the message is sent at most once, thus not necessarily guaranteeing the message delivery;

  • QoS1: the message is sent at least once;

  • QoS2: through 4-ways handshaking, the message is sent once.

The selection of the QoS level depends on the specific application. In this case, QoS0 has been preliminarily employed, since it represents the option with the lower cost in terms of data transfer volume. Additionally, the connection between the Publisher (in this case, the ESP32 module) and the Broker (with reference to Fig. 2, the Raspberry Pi3 board) was considered reliable, also thanks to the operation environment, considered pretty close to the real future application of the system (at the patient’s home). Clearly, the intended application aims at highly reliable acquisition of vital parameters, therefore the QoS level choice will be further investigated in next project steps.

3.5 Developed Software

In this Section, the developed software for the correct operation of each block will be presented. In particular, the following algorithms will be briefly discussed:

  • MQTT Publisher-Broker data exchange and connection (Publisher side);

  • Acquired ECG signal manipulation for peaks detection.

Fig. 6.
figure 6

Flowchart for the MQTT Publisher-Broker data exchange and connection (Publisher side)

Full size image

The code relative to the MQTT Publisher-Broker connection, at Broker side is not discussed due to its simplicity. Indeed, it simply initially checks whether the Broker, that is the Raspberry Pi3, is connected to the Publisher, that is the ESP32. Then, it continuously acquires the data received by the Publisher and saves the latter into a text file. The data acquisition and the connection can be stopped in any moment.

3.6 MQTT Publisher-Broker Data Exchange and Connection (Publisher Side)

In order to better understand the working principle under this algorithm, a flowchart is represented in Fig. 6. After establishing the Wi-Fi connection, the connection to the Mosquitto Broker is performed, through the employment of a readily available library, namely the PubSubClient library. Nevertheless, its usage will be reviewed in future implementation, since it currently presents some limitations in terms of choice of the QoS level, although at the moment the chosen QoS0 level is supported without issues.

Then, two parallel tasks (threads) are executed over the two cores of the ESP32 microcontroller. In particular, the first task is performed by Core0, and is relevant to the acquisition of the ECG signal measurements. The sampling rate of the acquisition process has been set to \(f_s = 720\) Hz, where each sample is represented by a 4 Bytes floating point data. These measurements are immediately stored within a suitably defined FIFO queue whose size is \(3\,\textrm{KB}\), thus allowing for a maximum storage of 750 samples. In parallel, the second task is run over Core1, and its main duties are the extraction of new samples from the queue, the encapsulation within an MQTT control message and the subsequent transmission over Wi-Fi. Specifically, samples extraction is performed over a period of 1 s (i.e. 720 samples are collected) with the consequent creation of a payload of 2880 Bytes for the MQTT message. Once the message is ready, Core1 initiates an immediate transmission over the Wi-Fi link, to publish the new information message to the Broker. The chosen parameters, i.e. the queue size and the transmission period, have been defined to ensure, on the one hand to decrease the Wi-Fi link usage as much as possible, to improve energy efficiency, trading off with the payload length to avoid data loss over the Wi-Fi link. On the other hand, such parameters ensure a continuous acquisition from the measurement ADC.

4 Algorithm for ECG Signal Manipulation and Peaks Detection: Preliminary Results

In this section, the first preliminary results obtained for the ECG signal acquisition are presented. In particular, at first the signal conditioning technique is described. Then, this is applied to the signals acquired by means of the aforementioned sensor (i.e. the AD8232), which is connected to the ESP32 module, which in turn encapsulates them into MQTT control messages sent over wireless to the Raspberry Pi3 Broker.

As it is possible to see in Fig. 7, after acquiring the data from the Broker and saving it to a text file, a preprocessing has been carried out. As stated in Sect. 3.1, this filtering stage is a simulation of the analog filtering stages that will be introduced in the data acquisition block, in order to manage the noise and interference issues. As previously introduced in Sect. 2, the ECG signal frequencies of interest range from \(0.5\,\textrm{Hz}\) to approximately \(150\,\textrm{Hz}\).

Fig. 7.
figure 7

Signal processing block diagram

Full size image

Therefore, at first a high pass filter (HPF) with a cut-off frequency of \(f_1 = 0.5\,\textrm{Hz}\) has been implemented, followed by a low pass filter (LPF) whose cut-off frequency is set at \(f_2 = 150\,\textrm{Hz}\). Then, a band-stop filter (BSF) with \(f_3 = 50\,\textrm{Hz}\) center frequency has been applied, in order to address the powerline interference issue. Besides the filtering stage, other secondary signal processing operations have been programmatically performed, like signals resampling at \(f_s = 720\,\textrm{Hz}\) and successive normalization to maximum. Subsequently, a pair of derivative filters and max filtering were employed for peaks detection, following the approach suggested in [3]. The derivative and max filters were applied on windows of \(W = 4000\,\textrm{samples}\) with a sliding window of size \(S = 3200\,\textrm{samples}\), thus with an overlap between windows of \(\frac{1}{5}\,W\).

The result can be appreciated in Figs. 8 and 9, for signals acquired with a duration of \(60 \,\textrm{s}\). As stated in Sect. 3.1, the electrodes in charge of the ECG-acquisition were positioned in correspondence of the wrists and the third electrode was positioned in the right lower pelvis. Foreseeing the ECG signal represented in Fig. 8, the patient did not carry out very fast movements but simply stood up and down, moved the arms and hands and slowly walked. The R-peaks are all successfully detected, albeit also two P-wave peaks have been also marked. In order to overcome this issue, a comparison algorithm is being developed.

Fig. 8.
figure 8

R-peak detection algorithm for a signal characterized by a low-noise level. The patient stood up and down quite slowly and did some steps calmly

Full size image
Fig. 9.
figure 9

R-peak detection algorithm for a signal characterized by only noise. As it is possible to notice, no R-peaks have been detected by the algorithm. The patient carried out very fast movements, trying to be as much agitated as possible

Full size image

The compared signals are the one resulting from the application of the algorithm of [3] and a signal resulting from a band-pass filter, to which an envelope signal has been applied. In this way the missing R-peaks can be inserted and the erroneously detected P-wave peaks can be removed. The signal presented in Fig. 9 is instead characterized by only noise, thus the patient moved very fast the wrists, thus worsening the skin-electrodes contact surface, stood up and down very rapidly and without caring about the presence of the right lower pelvis-positioned electrode, so as to dirty the acquired signal trace as much as possible.

5 Conclusions

This paper addressed a very hot research topic, further underlining the importance and the possibility of patients’ remote health monitoring. Indeed, the introduction of a modular system that is easily reconfigurable depending on the clinical history of the patient could help the clinicians to more precisely provide more accurate diagnosis to the patients. The employment of a very compact, lightweight, cheap and, at the same time, powerful MCU board, such as ESP32, together with the exploitation of its two cores that guarantee a continuous data acquisition and transmission to the data collection station, represents an important point for this research. While the Core 0 of the MCU is acquiring data, basing on the Tasks priority, the Core 1 is simply passing them to the Raspberry Pi3 via MQTT, that is an easy-to-use communication protocol. The code Tasks division is very helpful for the data transmission integrity and clarity. Indeed, by giving a different priority to each Task for the ECG signals, oxygen saturation and body temperature, it will be possible to let the data collection station choose how to elaborate data. Moreover, modularity and reconfigurability characterize the system so that it could be employed in a wider range of applications, not only for CVDs-affected subjects. In the perspective of a complete development of the described system, namely SHeMS, the authors presented some preliminary results that appear to be promising for the ongoing work. While this article reported about an ongoing project, several considerations can be already drawn about future activities and enhancements. As a matter of fact, the forthcoming embedding of all the previously mentioned modules, such as temperature, oxygen saturation, blood pressure and vocal messages will clearly help to additionally provide a more personalized medical care. Besides, inserting these modules means to deeply analyze computational capabilities of the chosen ESP32 microcontrollers, and of the MQTT protocol settings. Moreover, even though the multicore microcontroller architecture is beneficial for this type of application, a more sophisticated sychronization algorithm between the Publisher and the Broker is under development. Another important advancement is relevant to the peak detection algorithm, based on the comparison of the processed signal and bandpass filtered signals in the frequencies of interest (relative to R-peaks, P and T waves frequencies), that will help to consolidate the peaks detection, trying to face the problem of patients’ sudden movements, that could imply missed peaks’ classification or, additionally, peaks misclassification.