Keywords

1 Introduction

The design of so-called Assistive Technologies (ATs) is driven by the aim of improving the Quality of Life (QoL) [1] of end users, including patients, caregivers, and healthcare operators, through the possibility of supporting each of them with specific functionalities and services [2]. This is particularly true for persons with dementia (PwDs), as the lack of an effective and definitive cure makes maintaining or increasing their QoL the primary care goal.

Dementia is a syndrome, meaning that it is possible to identify groups of characteristic symptoms, rather than a disease process, with the exception of some types of dementia, such as Alzheimer’s Disease (AD). Among the most common symptoms it is possible to mention progressive loss of cognitive functioning, including decision making, mathematics, communication, memory and spatial reasoning. Each PwD experiences dementia symptoms uniquely, and this fact reflects on highly individualized care needs. A nurse or caregiver taking care of a PwD adjusts to his/her symptoms, noticing changes in the person throughout the day, and over longer periods. A certain quality of care is attained when the caregiver is able to interpret behavioral symptoms and, in turn, communicate with the PwD appropriately [3].

Given the above premise, context-aware Ambient Assisted Living (AAL) technologies emerge as the most viable approach for the seamless adaptation of the living environment to the fluctuations of the user’s conditions. The design of ATs for dementia looks for technologies that can achieve the same goals of residential caregiving, taking into account the person’s level of need, the way ATs are perceived and used, and the resulting outcomes. Four classes of technologies are typically identified [4]: (i) prevention and engagement technologies; (ii) compensation and assistance technologies; (iii) care support, (iv) enhancement and satisfaction.

Home caregiving provided by relatives, or residential caregiving delivered by nurses, may benefit from a smart environment equipped to predict and minimize safety risks, and to contact help when needed. This can be made possible by gathering information on user patterns and environmental risks, by assessing the individual’s needs, and activating proper actions to alert when a safety threshold is breached. All these functions pose specific requirements: sensors are needed to collect data [5, 6]; proper communication capabilities are necessary to send alerts and notifications [7]; reasoning algorithms shall be applied to generate knowledge from raw data, by identifying patterns and anomalies [8].

A smart home system may collect biosignals and physiological data which help detect behavioral changes, as well as variations in the user’s interaction with the home devices or appliances. A requirement of utmost importance is the possibility to collect such a huge amount of data unobtrusively, and without the need of user’s cooperation. Minimizing the interaction required by the user is especially important with dementia, as declines in procedural memory hinder the capabilities of the user itself. Zero Effort Technologies (ZETs) use algorithms to collect, analyze and apply data autonomously and unobtrusively.

This paper presents the technological evolutions in the design of a ZET kit [9] to unobtrusively monitor PwDs, who are still able to stay at home, but need to be assisted, usually by a relative (spouse, husband, son), or a caregiver. The aim of the kit is to support caregivers in monitoring the PwD, trying to reduce the burden of caring, and ensuring a continuous supervision that can automatically generate alarms and prevent risks by analyzing and detecting anomalous behaviors. The original kit was equipped with sensors and sound/visual alarms; the evolved version of the kit, discussed in this paper, supports remote communication and a set of functionalities running locally on a high-performance embedded board. Some of the improvements related to the sensor network have already been applied and tested for the realization of another project [10]. In that case, however, the kit was employed for the monitoring of patients in a nursing home, so the scenario was different.

The paper is organized as follows: Sect. 2 discusses state-of-art projects and technologies for PwD and their caregivers, whereas Sect. 3 provides a detailed description of the proposed system architecture and functionalities. Preliminary results on the proposed system are discussed in Sect. 4; finally, Sect. 5 concludes the paper.

2 Related Works

In this Section, a closer look at ATs for elderly people living at home or in care institutions, typically suffering from different stages of cognitive decline or frailty, is provided. There is a need to distinguish between:

  • integrated solutions versus solutions looking at single specific aspects;

  • systems that act preventively and try to predict potentially harmful incidents versus systems that detect either short-term emergencies (e.g. falls), or long-term trends (e.g. changing of eating behaviors).

The majority of the applications developed up to now has been focusing on handling immediate needs, like detecting an emergency situation. In fact, several emergency calling systems are available in the market. Some of them are designed for indoor use [11, 12], others also operate outdoor [13, 14]. Most of the commercially available solutions rely on a worn sensor, typically an armband or necklace, equipped with an emergency button that needs to be pressed to call for help. This raises some concerns: if the person cannot act on the button, because unconscious, or does not wear the device, the emergency situation is not automatically detected and no alarm is activated.

Especially for people with cognitive and memory problems, solutions have been developed to automatically turn off potentially hazardous electrical devices, such as a running oven or iron.

Other solutions initially developed for professional institutions working with PwDs deal with area monitoring, access control, and location tracking. They use Radio Frequency IDentification (RFID) technologies, to detect people entering or exiting areas and rooms in a building [15]. Some of these systems observe and track the paths people walk to raise warnings or alarms in case anomalies are detected. Low power, low cost, and high precision indoor localization systems are still under research.

Algorithms for activity recognition and behavior prediction analyze the data collected by a set of sensors installed in the home of the monitored elderly, to find out what the person is, or has been doing, and detect abnormal situations, emergencies, and anomalous trends. This information is delivered to informal or formal caregivers, to timely react with proper counter-measures. Typically, off-the-shelf sensing technologies are used, such as magnetic sensors for doors and windows, and presence detectors, to acquire the data needed [16, 17]. Sometimes, additional sensors such as pressure based bed sensors, floor mats, or depth cameras [18] are utilized. The aim is to detect so-called Activities of Daily Living (ADLs), and Instrumental ADLs (IADLs) (e.g. cooking, cleaning, managing medication and financial issues), but also basic tasks (walking, dressing, eating, personal hygiene etc.) that directly relate to the level of dependency of the older person [19].

Some projects address their monitoring to detect the symptoms of dementia, such as wandering [20], depression, memory loss [21, 22], counting toilet visits (incontinence) or especially focusing on the sleep patterns and the behavior during the night, as people tend to lose their day-night rhythms with the progress of the syndrome [23].

In general, AAL systems for PwDs should be designed in a way that they work unobtrusively in background, implicitly interacting with the user. However, sometimes explicit user interaction is inevitable or even wished. In this case, the design of User Interfaces (UIs) for people at different stages of dementia shall be carefully addressed.

Compared to other existing solutions, the proposed system does not recognize activities and does not analyze the trend of the patients’ conditions. Even if in the system configuration, as will be explained in Sect. 3.4, the caregiver can set some parameters to best adapt his/her needs, however the cognitive stage of the patients does not affect how the system works. Summing up, the system has the following characteristics:

  • it is essentially an alarm system for the detection and notification of dangerous events;

  • it is a support tool addressed to the caregivers;

  • behavior analysis is not provided: only evident abnormal events are recognized;

  • it is a passive system, the patients do not interact with it.

3 System Architecture and Functionalities 


As already hinted in the Introduction section, this work describes the evolution of a kit for PwDs’ monitoring at home. In this section, the system architecture is described (see Fig. 1), and the main applied changes and improvements are discussed.

Fig. 1
figure 1

System architecture representation

Full size image

The core of the system is the so-called “box”, composed by a processing unit and two wireless communication interfaces (SubGHz and GSM/GPRS modules). Environmental sensors detect events and contextual information (such as temperature and humidity), and send them to the central unit, through the SubGHz technology. Once the data have been acquired and processed, the box notifies if an alarming event has occurred, by sending an SMS to the subscribed caregivers. The subscription, i.e. the registration of the caregiver’s phone number, and the setting of other parameters can be managed through a smartphone application designed to enable both a caregiver and a technician interact with the box, for configuration and installation purposes. Finally, at the end of the day, a report summarizing the most relevant events happened during the day is sent by the box to the remote server through the GPRS module.

3.1 Data Acquisition

The system provides a set of sensors installed within the home, to monitor different aspects of the patient’s daily life unobtrusively. In order to keep the installation as simple as possible, a wireless transmission technology has been chosen, specifically a SubGHz technology operating at 868 MHz. Each sensor is connected to a small board in charge of simple processing and data transmission toward a central node. This node is able to identify the data sender thanks to the unique identifier (id) assigned to each sensor. The available sensors are:

  • bed presence: a force sensor to detect the patient’s presence in bed;

  • water: to detect a flooding condition;

  • smoke: standard smoke detector;

  • magnetic sensors: to be placed on doors and window fixtures, and on the refrigerator door;

  • presence sensor: passive infra-red (PIR) sensor to detect the patient’s presence in the bathroom;

  • temperature and humidity sensors.

Furthermore, a smart control unit, the box, is placed at home to manage the entire monitoring system. The core element of the box is a single-board computer, and is equipped with a module operating in the SubGHz band, to acquire sensors data, and with a GSM/GPRS module for sending voice and text messages, and also for data uploading to a remote server. Finally, a switch enables and disables the alarms for the detection of the events. The detailed mode of operation of the box is described in the following sub-section.

3.2 Data Processing

As highlighted in Fig. 2, the software architecture of the platform is composed by different blocks, that communicate with each other. In particular there are:

Fig. 2
figure 2

Main blocks of the platform software architecture

Full size image

  • modules that listen for events (such as events generated by wireless environmental sensors, or incoming SMS); 


  • modules that elaborate events/data; 


  • modules that execute real time or scheduled actions, through the GSM/GPRS 
module.


The box represents the central unit that receives information from the sensor net- work built around the monitoring area, and also manages the user interaction. At the system startup, the configuration phase runs, in which the software activates all the modules appointed to monitor different situations or events, and discovers the enabled sensors. At the end of this phase, the “Events Elaborator Module” (the real core of the application) is started.

This module runs cyclically, checking for new events every 5 s: if an event is arrived, it is managed by undertaking specific actions in accordance with its type, as described later. The Events Elaborator Module applies a check, called “One Minute Check”, to monitor the state of the system (peripherals, database) and the state of all the enabled sensors, analyzing, for example, if there are communication errors. Each sensor has to be treated in a different way, by following a logical workflow describing the behavior modeled for that type of sensor. In general, for every sensor different types of events can occur:

  • birth event, related to the startup of the radio board; 


  • scenario event, related to the activation/deactivation for digital sensors, or to the 
acquired value for analog sensors; 


  • alive event, created with a certain frequency (in this case fixed to 6 h) in 
order to ensure the system that the radio board connected to the sensor is powered and active.


In order to explain how the system works, the workflows of operations associated to two different sensors are described. The former refers to the “access” sensor typology, for example a magnetic sensor located adjacent to door and windows in order to monitor if a person has opened or closed them. The evaluation is different depending on the arrival of an event or a One Minute Check. The One Minute Check evaluates only if there are communication errors, while in case of an event, it is possible to distinguish if the board has restarted or if the magnetic contact has been opened or closed. Obviously, only the opening event is considered as an alarm. The latter case refers to the “bed” typology, where the alarm condition is related to the fact that the user is not returning to bed over a certain time interval, during the night period defined by the caregiver. This means that a scenario event is treated in a completely different way with respect to the case previously described.


This way the system is really flexible and it is possible to manage every type of sensor or condition in a seamless way. From the functional point of view, another important part of the software concerns the actions performed by the system, as a reply to events. These actions are controlled by the “Action Executor Module” that exploits the GSM/GPRS module for the communication. Besides, the software is completed by the “Scheduler Module” which is able to manage scheduled actions, in this case regarding the creation of a daily report to send to the caregiver, in order to inform him/her about the state of the monitoring. 


3.3 Notification Management

The control unit handles the generation of notifications caused by several types of events. It is able both to send a text message (SMS) to the caregiver, and to perform a call, sending him/her a pre-recorded voice message that varies depending on the specific event to notify. One of the main differences between the solution described in this paper and the system developed previously concerns the confirmation of the notification delivery to the caregivers or patient’s relatives. In fact, it is important to ensure that the caregiver has received the message and distinguish a true answer from an answering machine. For this reason, the improved version of the kit requires the person called to confirm the receiving of the message by pressing a key on the phone.

The system foresees the configuration of two lists of people: the former can include up to six caregivers, the latter includes two installers. Notifications can be related to the events generated by the sensors, or to the configuration requests issued by a caregiver or installer. In the first case, the processing unit evaluates each event in order to classify it as an alarm or not. The following situations are considered as “alarms”:

  • the door or window is open;

  • the patient wakes up and does not get back to bed within a certain time interval (during nighttime);

  • the refrigerator door has not been opened for a long time (over a fixed time interval);

  • the patient has not accessed a certain area of the house for a defined time interval;

  • activation of smoke and water detectors.

Moreover, other two alarm conditions can be detected by the environmental sensors:

  • the temperature is above or below a threshold;

  • the humidity rate exceeds a certain threshold.

If an alarm event is recognized, the first person in the caregivers’ list is called; in case of no answer, the control unit tries with the following one, till the end of the list. If none of the persons answers, an SMS is sent. Another function offered by the system is the daily dispatch of a message containing the most important events occurred during the day: in this case, it is sent to all the caregivers.

The second notification type is referred to the configuration requests made by means of a mobile application, which is described widely in Sect. 3.4. In fact, as visible, several parameters have to be set, such as time intervals and thresholds, that are properly formatted and sent to the box as SMSs. Likewise, an SMS is sent back from the box to the user with a response.

Finally, in order to increase the system reliability, if the detected event concerns the system operation, such as a malfunctioning, a text message is provided, addressed to the phone numbers of the installers included in the list.

3.4 System Configuration

In order to allow the ongoing dynamic configuration of the kit, an Android application for tablet and smartphone devices has been implemented. A mechanism which allows to configure the processing unit was already provided in the previous version of the project. It gives the possibility to modify some parameters through a web interface, accessible by connecting the box to a computer, with an Ethernet cable. Such a solution was designed to be used as a one-off operation, only by installers. In fact, caregivers could not customize the kit in its first version according to their needs and to those of the elderly to be monitored.

The application presented below is intended to overcome this lack, permitting to dynamically configure the system wherever the user is, in a simple and convenient way. It foresees two access modality: installer and caregiver, selectable via an initial login form. The user interfaceFootnote 1 is the same both for caregivers and installers, but some more technical features are available exclusively to the latter.

As shown in Fig. 3, the functionalities are divided into three main topics: general, notification, and account. The three topics can be selected by a tab bar located on the top of the view.

Fig. 3
figure 3

Android application interface for the settings management: on the top view there is a tab bar to select the type of settings; on the central part of the interface all functionalities related to the chosen topic are shown; finally on the bottom, a button allows to save the changes and send them to the processing unit

Full size image

In the general tab there are all features referring to the system general functioning. More specifically, they allow the user to:

  • set date and time;

  • set parameters to access the remote server;

  • check the residual credit on the box SIM card;

  • set values for the box functioning and request information about its current state;

  • request to forward data reports to the remote server;

  • request the sensor configuration.

Naturally, all the features related to the setting of specific operating parameters, and the report or configuration requests, can be acted upon only by the installer, who has the appropriate skills to manage and use them.

The notification section allows, instead, to modify values concerning the detection of alarms, or to disable notifications from one or more sensors. Specifically, the user can:

  • set thresholds (e.g. temperature and humidity limit values);

  • enable/disable the receipt of notifications from some or all sensors;

  • set timeout values, i.e. the time interval required in some particular situations, as listed in Sect. 3.3.

Finally, the account tab enables to modify the information about the users who interact with the system. Particularly, it is possible to:

  • modify the personal password;

  • add/remove the caregivers’ phone numbers;

  • add/remove the installers’ phone numbers.

The last feature is available only for installers.

Once the user has applied the desired changes, he/she can save and send them to the box by clicking the “save and send” button on the bottom of the screen. In such a case, it is possible to check the modified settings from a summary window (Fig. 4) and decide whether to transmit them or apply further changes.

Fig. 4
figure 4

Summary window to check the modified settings before sending them to the box

Full size image

The Android application communicates with the box through SMSs. The communication protocol is conceived with the aim to reduce the number of characters sent, and consequently the costs. When the caregiver or the installer wants to change a setting or submit a request to the box, the message will be forwarded in the following format:

TECHHOME#FeatureCode#[Parameters]

The SMS starts with the “TECHHOME” keyword, followed by an hash symbol, a numerical code, and then another hash symbol. Optionally it is possible to add some parameters separated by commas. The numerical code allows to establish the desired feature. In fact, for each functionality an identification code and, in some cases, specific parameters are provided. To submit multiple commands on the same message, the “feature code—parameters” pairs must be appended until the number of characters available for a message has finished.

For example, to issue a command to the box for editing the maximum and minimum temperature thresholds and the disabling of notifications coming from a certain sensor, a message as follows is sent:

TECHHOME#0007#MAX-30,MIN-15#0009#DIS-10

where 0007 is the numerical code identifying the temperature threshold feature, the number 30 is the maximum value in degrees, and 15 the minimum. The 0009 code represents, instead, the enabling/disabling of a sensor; the “DIS” keyword indicates the disabling and the number 10 is the id of the sensor to disable. The same message format is adopted also when the box needs to forward information to the smartphone, for example the sensors configuration.

3.5 Remote Storage

The project foresees the adoption of a remote server that collects data of several users. The introduction of this element, which was not present in the previous architecture, is mainly due to the following reasons:

  • the availability of information about a patient enables to perform a long-term analysis of his/her condition;

  • to allow care providers and medical personnel to access the patient’s data for monitoring purpose; 


  • to access information remotely; 


  • to overcome memory space problems of the home box.

Each evening, the processing unit creates a report containing all the information related to the daily activities. It includes the events collected by the sensors, the requests made through the configuration app, and the notifications, in addition to status information of the box. This report is sent to the remote server over a GSM/GPRS connection, through the File Transfer Protocol (FTP). The report structure follows a JSON formatting (JavaScript Object Notation), whose main fields are: 


  • box_number, 


  • report_date, 


  • last_boot_date, 


  • last_boot_state, 


  • sensors, 


  • notifications, 


  • requests.


The box that have sent the file is recognized by means of a unique identifier, the “box_number”. The “last_boot_date” indicates day and time of the last boot of the box, which is currently in the “last_boot_state” (e.g. “Configured”). Each element of the array “sensors” corresponds to one of the sensors installed in the house. Some specific information are included: id, name, type and minimum RSSI value (Received Signal Strength Indicator) registered during the day. Furthermore, the sensor events are listed, grouped by type: Activations, Deactivations, Errors, Births, Timeouts. As an example, the structure of one element of “sensors” could be the following: 


{ 


“sensor_id”: 11, 


“name”: “sensorName”,

“sensor_type”: 1,


 ”rssi_min”: “low_value”,

“activations”: [

{“id_event”:112233, “date_event”:“18-01-2016 08:57:07”}, {“id_event”:112234, “date_event”:“18-01-2016 09:45:07”},

]

“deactivations”: […],

“births”: […],

“errors”: […],

“timeouts”: […]

}

All the events have their own id, which is unique within the box. The RSSI value is helpful to recognize whether the sensor battery is low. Some arrays can be empty in the report: in fact, it is possible for example that no errors have occurred during the day. Moreover, different sensors provide different types of events: for example, the temperature and humidity sensors just provide activations and errors, or the timeout event is not present for water and smoke sensors.

The array “requests” contains the operations performed by the system installer or caregiver through the configuration application described in paragraph 3.4. A unique identifier is associated to each request, which is also composed of the timestamp of the operation, the user identification and type (installer/caregiver), the requested parameters and the result (success or not).

All the events and requests that have generated a notification are listed in the “notifications” array. Thus, each item includes the id of the corresponding event or request. Notifications can consist of a call or an SMS toward the mobile phone numbers provided during the system configuration. The first choice is generally the call, and in case of no answer an SMS is sent, as explained in Sect. 3.3. The outcomes of this procedure are reported as follows:

“called_caregivers”: [ 


{“number”: “3331234567”, “answer”: 0},

{“number”: “3474142433”, “answer”: 0},

{“number”: “3382122233”, “answer”: 0}

],

“sms_notification”: 1

Both the numbers and results of the calls are present, and also the indication of the SMS notification (1 if sent, 0 if not sent). In this example, none of the caregivers answered, thus an SMS has been sent.

The creation and forwarding of the JSON file is only the first step in the remote storage and data management. The authors are also working on the set up of a server with a twofold purpose: not only to store the file with the patient’s data, but also to provide a web interface to display information. On one hand, the FTP connection for the daily report exchange is replaced by the HyperText Transfer Protocol (HTTP). The server processes the requests by extracting information and inserting it in a database. On the other hand, a web interface is provided, in which a user (e.g. caregiver) can log in with his credentials and access the various sections: events, requests, notifications and RSSI values. The contents are organized in different web pages and in a tabular fashion, in order to display the information more clearly.

4 Preliminary Tests and Discussion

At the end of the previous pilot, participants filled in a satisfaction questionnaire which has allowed to understand the strong and weak aspects of the technological kit. Among the weak aspects, it has emerged for example that some sensors showed operating problems and caused false alarms [24]. To overcome these problems, the bed and water sensors have been replaced. In fact, the new bed sensor provides a calibration that adapts the sensing to the patient’s weight. As for the flooding detection, a different type of device have been chosen to avoid the false alarms due to high humidity rates. Additionally, these events generate acoustic alarms locally, that in some cases have frightened the users, and therefore have been removed.

With respect to the first realization, other sensors have been included in the kit to enhance the degree of monitoring. A presence sensor is used to monitor the user’s presence in a room, for example to verify that he/she enters the bathroom periodically. Moreover, a magnetic sensor placed on the refrigerator door can detect its opening and thus give information about eating.

In the first kit, in case of unexpected energy blackout, the processing unit shut down abruptly. In order to avoid this situation, a battery pack have been added to the box, so that the processing unit can continue its normal operation for a certain time interval. Then, if the interruption prolongs over time, it shuts down in a controlled and correct way.

As already described, one of the main improvements brought by the new kit is the remote communication toward a server, to send data related both to users and system operation. From the reliability point of view, this makes possible a continuous monitoring, the detection of eventual malfunctions and a prompt intervention if necessary. In the feedbacks received by the users, some have pointed out that the box is quite big, so it does not look good and occupies space. Thanks to more accurate design and technical choices, it has been possible to remove some elements and thus significantly reduce the dimension of the box. Finally, at the caregivers’ opinion, the system should be more flexible, and adaptable to the patient’s needs. Therefore, the configuration of some parameters has been made easier and user-friendly thanks to the mobile application.

After the implementation of the new kit, a prototype composed by a complete set of sensors and a central unit has been tested in a laboratory environment. The test is divided into three parts.

The first, lasting two weeks, consisted in the installation, configuration and normal daily usage of the system. All the dangerous situations requiring alarm notifications (see Sect. 3.3) have been verified in the laboratory. Several tests have been performed in order to check the capability if the control unit to contact the selected phone numbers in the expected order, through a call or SMS, and in different possible conditions, such as phone off, rejected or missed calls, for both home and mobile phone numbers. One of the goals of the proposed solution is to try to reduce care burden and stress among caregivers through the use of technology. In order to do this, the home monitoring kit must have as few problems as possible, avoid false alarms, and promptly notify malfunctions. Also thanks to the data log created in the normal system operation, it has been possible to detect and solve a few minor problems that occurred during the test. After completing these interventions, no technical issues emerged at the end of this first stage, as the system correctly detects and notifies alarms.

For the second part of the test, the transmitter boards have been disconnected from the sensors and connected temporarily to another board to perform a “stress” test. This board has been programmed to simulate signals corresponding to the ones generated by the sensors, but with such a frequency that the number of events of a whole year have been generated in a few hours. Despite the high number of events generated with a frequency absolutely impossible for real-life situations, the system continued to work correctly. The only effect observed was a delay between the event detection and its notification, due to the increasing queue of events to be processed.

A third significant test has been done, by switching on/off the system around 100 times randomly, so to prove the behavior of the new solution to sudden and not expected power-leaks.

The solution described in this paper takes part in a wider project, that will test the impact of the designed technology to support the caregivers of PwDs who are still living in the community. The hypothesis is that technology can substitute in part the time caregivers spend in supervision and monitoring activities for patients. The decreased time is expected to reduce the caregiver burden, and thus result in an overall improvement of quality of life for carers and PwDs.

5 Conclusion

This paper presents a system aimed at supporting the caregivers in monitoring the PwDs. It consists in a ZET kit, able to ensure the continuous monitoring of the subject, the automatic generation of alarms, and the prevention of dangerous situations, simply by analyzing the data collected by environmental sensors and sending notifications to caregivers. The system described so far is an evolution of a previous solution, tested on a large group of users. The feedbacks obtained allowed the authors to make significant improvements oriented toward the caregivers’ specific needs.

The new solution presented in this paper has been thoroughly tested by both functional and stress tests in a laboratory environment.

The project foresees a controlled trial lasting 12 months, which will start soon and will take place in Sweden, thanks to an international collaboration. A total of 320 dyads including PwDs and their primary informal caregivers (640 participants in total) will be recruited. They all will receive home visits from a dementia nurse in charge of data collection. Among them, an “intervention” group will also have the technological monitoring kit installed in their homes.