# A Platform for e-Health Control and Location Services for Wandering Patients

Authors: Samantha Yasivee Carrizales-Villagómez; Marco Aurelio Nuño-Maganda; Javier Rubio-Loyola
Journal: Mobile Information Systems
 (2018)

---

## Abstract

Wandering patients frequently have diseases that demand continuous health control, such as taking pills at specific times, constant blood pressure and heart rate monitoring, temperature and stress level checkups, and so on. These could be jeopardized by their wandering behavior. Mobile applications that focus on health care have received special interest from medical specialists. These applications have been widely accepted, due to the availability of smart devices that include sensors. However, sensor-based applications are highly energy demanding and as such, they can be unaffordable in mobile e-health control due to battery constraints. This paper presents the design and implementation of a platform aimed at providing support in e-health control and provision of location services for wandering patients through real-time medical and mobility information analysis. The platform includes a configurable mobile application for heart rate and stress level monitoring based on Bluetooth Low Energy technology (BLE), and a web service for monitoring and control of the wandering patients. Due to battery limitations of smart devices with sensors, the mobile application includes energy-efficient handling and transmission policies to make more efficient the transmission of medical information from the sensor-based smart device to the web service. In turn, the web service provides e-health control services for patients and caregivers. Through the platform functionality, caregivers (and patients) can receive notifications and suggestions in response to emergency, contingency situations, or deviations from health and mobility patterns of the wandering patients. This paper describes a platform that conceals continuous monitoring with energy-efficient applications in favor of e-health control of wandering patients.


---

## Body

## 1. Introduction

Dementia refers to the loss of cognitive functioning. People suffering from dementia are affected in their ability to think, remember, and reason. The most common causes of dementia are Alzheimer’s disease, vascular dementia, or multi-infarct dementia with Lewy bodies and frontotemporal dementia [1]. Although vascular dementia accounts for 20% to 30% of all cases of dementia, Alzheimer’s disease is the most common cause covering 50% to 75% of cases. It destroys brain cells and nerves, affecting the transmitters that send messages to the brain, particularly those responsible for storing memories. As mentioned in [2], age is the most important risk factor for dementia. It is expected that by 2030, 60 countries will have more than 2 million elderly persons over 65 years. This will have a great impact on public health in several countries because dementia is the leading cause of disability in elderly people, accounting for 11.9% of years lived with disability from noncommunicable diseases. Symptoms of Alzheimer’s disease are the sudden loss of memory, confusion in everyday activities, adoption of disturbing behavior such as getting up in the middle of the night or wandering errantly and getting lost [1]. People with dementia are at constant risk of wandering away, being exposed to physical and emotional damage and even death. In addition, wandering patients, mostly elderly people, frequently have other diseases that demand additional health control processes (taking pills, blood pressure and temperature checkups, heart rate and stress level checkups, etc.), which could be jeopardized by their wandering behavior. In this regard, there is a need for e-health monitoring platforms that can provide support to caregivers who take care of patients with wandering behavior.At present, a large number of technology companies worldwide have already announced innovations of portable electronic devices that facilitate the accomplishment of certain tasks. An example is mobile health (mHealth). The term mHealth refers to health care using mobile technologies [3]. That is, with the integration of sensors, mHealth applications allow for the monitoring of chronic diseases through vital signs sensing, raising the mobile technology as a new era in health care. Moreover, there are factors that influence this transformation, such as aging in the population and the requirement to have fast and available access to monitoring and health care. It is here that mobile devices act as a fundamental axis, simplifying monitoring and delivering critical information at the time users require it.The improvements made in the creation and design of sensors that measure vital parameters in the human body represent a huge change for the conventional health-care systems, allowing the creation of patient-centered [4] systems and applications, transforming the current health system by reducing costs, anticipating chronic episodes, and improving the patients’ quality of life. This is the case of the research [5], where the authors designed and implemented a remote monitoring medical system for the prediction and management of heart failure, predicting the risk of heart failure as a function of changes in pressure arterial, and body weight of patients who are in a noninvasive environment. Integration of several functions into a monitoring application has also been achieved, such as a visualization interface of data relating to monitored parameters, graphically presenting the patient’s ECG [6]. Vital signs are indicators of the physiological state of vital organs such as the brain, heart, lungs, and so on. Therefore, systems that perform the monitoring of one or more vital signs (heart rate, respiratory rate, and blood pressure among others) [7] through sensors represent a huge change for conventional health-care systems. The improvements made in the design of intelligent sensors allow for improving the quality and efficiency of mHealth, offering advantages over conventional health care such as ease of use, lower risks of infection, reduced user discomfort, and greater mobility [8].Recent efforts have proposed conceptual frameworks like the PAVISALE framework proposed in reference [9], which is proposed to exploit the monitoring of biological signals by means of novel sensors (invasive and noninvasive), Cloud-based storage and analysis, and the use of big data techniques to analyze massive amount of biological data. Nevertheless, unlike the work presented in this paper, the PAVISALE framework lacks implementation details; it has not been demonstrated in real patients, and its feasibility to address real-life scenarios has not been demonstrated. This paper presents the design and implementation of a configurable platform aimed at providing support in e-health control and provision of location services for wandering patients through real-time medical and mobility information analysis. The platform is a configurable mobile application and a system for heart rate and stress level monitoring (CMA-HR-SL). The CMS-HR-SL platform consists of a mobile application and a web service for monitoring and control of wandering patients. The mobile application allows integrating to a smartphone, an external sensor or Smart-Band through Bluetooth Low Energy (BLE) technology. Due to battery limitations of smart devices, the mobile application includes energy-efficient handling and transmission policies to make more efficient the transmission of medical information from the smartphone. The mobile application extends the smartphone’s capabilities to sensing and transferring medical information through communications networks (Wi-Fi and cellular network) to an external storage server (database (DB)) [10] for further analysis. The medical and location-based information is stored temporally in a Cloud-based service, from where, eventually, a web service retrieves and analyses such information to follow up the evolution of the state of wandering patients. The mobile application processes the heart rate (HR) and physical activity (PA) data in order to calculate the stress level (SL), which is continuously monitored. The mobile application and the web service allow taking precaution or reactive actions based on abnormal heart rate readings, abnormal SL, and abnormal patient locations.The rest of this paper is structured as follows: Section2 describes the structure of our configurable mobile application and system for heart rate and stress level monitoring (CMA-HR-SL); Section 3 describes the components of the mobile application, namely, the proposed mechanisms for heart rate (HR) monitoring, GPS sensing, and the procedure to detect anomalies in the smartphone side of the platform; Section 4 describes the procedure proposed to send the medical information from the smartphone to a Cloud-based server to store relevant information about the medical state of the patients; Section 5 describes the components of our platform system aimed at providing assistance to the patient in the event of abnormal heart rate readings, abnormal SL, and abnormal patient locations; finally, Section 6 presents the experimental scenarios and results of the evaluation of our platform; and finally Section 7 concludes the paper.


## 2. Overview of the Configurable Mobile Application and System for Heart Rate and Stress Level Monitoring (CMA-HR-SL)

The Configurable Mobile Application and System for Heart Rate and Stress Level Monitoring (CMA-HR-SL) manages the information in three phases: (1) a mobile middleware monitors vital signs, GPS, and stress level making use of a smartphone with external sensors; (2) the medical and location information is transmitted to a Cloud-based storage system, which works as an interface between the mobile application and the web service; and (3) the information is appropriately managed and analyzed in the web service to assist the patient when abnormal medical states and location behavior are detected. Figure1 illustrates the interactions among the proposed phases and an overview of the CMA-HR-SL platform.Figure 1
Overview of the CMA-HR-SL platform.In Phase 1, the CMA-HR-SL platform manages the connections between the sensor and the smartphone, collects the data of each sensor, configures the sensing periodicity of the sensor, and decides when it is necessary to transmit the collected data of vital signs and mobility information to the Cloud-based storage. In Phase 2, the CMA-HR-SL implements functions for storing the data in the Cloud, which allows accessing the information when it is required. The Cloud-based service is in charge of sending alerts due to abnormal state of the wandering patients, to the mechanisms implemented in Phase 3. The Phase 2 allows the CMA-HR-SL platform to manage the information of wandering patients easily, with scalable mechanisms, concentrate the information of several patients in a single logical entity (the Cloud), and, most importantly, secure the information of the wandering patients for further assistance when it is required. In Phase 3, the CMA-HR-SL platform gives support to caregivers who register on the web service, allowing them to manage personal information from wandering patients, as well as review and follow up biomedical readings, alert statuses, and abnormal patient locations so as to assist whenever it is needed.


## 3. Phase 1: A Middleware for Monitoring Vital Signs, GPS Position, and Stress Levels of Wandering Patients

Despite the advances in the production of wearables by hardware vendors, there is a need for platform systems that incorporate the sensing of vital signs, such as the blood pressure, heart rate and stress levels, and location services that can provide an API or real-time access to the collected data for proactive or reactive assistance of patients. Such systems are more relevant when taking care of patients with cognitive disability or wandering behavior. This section presents the mobile application of the CMA-HR-SL platform to address the aforementioned critical need.This section describes a middleware that allows monitoring the vital signs with external devices by using the Bluetooth Low Energy (BLE) standard to connect the external devices to Android-based smartphones. This approach allows us to (i) take decisions based on the sensed data; (ii) secure the sensed data in an external, accessible, and scalable Cloud-based storage system for further analysis; and (iii) parameterize the way of storing and sensing data to save energy. The mobile device selected for this type of architecture is a smartphone that has built-in sensors such as GPS, gyroscope, proximity, accelerometer, barometer, and so on. The configurable mobile application is based on an architecture that allows the management of the data acquired from the monitoring of specified vital signs (heart rate and stress state) through a BLE communication and energy consumption based on a reading and GPS transmission of the patient. Because smartphones have access to the Internet through a wireless network or access point, the application is able to send biomedical and location (GPS) data from the wandering patient to a virtual cloud storage server from practically everywhere.The mobile application of the CMA-HR-SL platform is composed of four components: (1) a controller for each sensor connected to the smart device, (2) a sensing scheduler for vital signs and GPS information, (3) a set of energy-efficient handling and transmission policies, and (4) an abnormality and stress level detector. These four components will enable the sensing of multiple vital signs and GPS information through several sensors, orchestrating the periodicity of sensing of each vital sign, managing the storage process of the collected data in the Cloud service accordingly, and triggering warning alerts to caregivers based on detected abnormalities in the patients. These four components are briefly described hereafter.


### 3.1. A Specific Controller for Each Connected Sensor

Every time a new sensor is added to the middleware, a new controller is instantiated. This controller creates a session with the sensor in order to manage the connections as well as the data that will be sensed. This component also controls the sensing periodicity. According to its configuration, the controller sends information to the sensing scheduler (described below) to keep updated the vital signs that are monitored.


### 3.2. A Sensing Scheduler for Vital Signs and GPS Information

The scheduler component manages the addition of new sensors by creating new controllers. The scheduler orchestrates all the controllers with their connected sensors and receives the data related to the vital signs. The scheduler also prepares the information for the abnormality and stress level detector (described later). Every sensor datum is locally stored in this scheduler until the energy-efficient handling and transmission policies indicate to the scheduler that the data must be sent to the cloud storage service.For the case of a heart rate (HR) sensor, the sensor provides HR data through BLE wireless communication to the mobile application. At the same time, the GPS sensor provides the location of the patient. With the collected data, the application model will be able to classify the stress level (SL) according to the identification of an abnormal HR episode (AHRE) with the help of the abnormality and stress level detector and send this collected data to the private cloud whenever the transmission policy indicates to the scheduler to do it.


### 3.3. Energy-Efficient Handling and Transmission Policies

In order to find trade-offs between energy efficiency and transmission requirements of the patients’ information, we proposed three energy-efficient handling and transmission policies. The policies give caregivers the flexibility to select the criteria that better fits the patients’ needs. The policies are (a) storing by quantity, in which a certain number of data packages are collected, and they are transmitted to the cloud storage server; (b) storing by time, in which a certain number of data packages are collected for a specific time period, and they are transmitted to the cloud storage server; and (c) storing by abnormality detection, every time a collected data package is evaluated as abnormal, this data package is sent to the cloud storage.The data packages transmitted to the Cloud service are integrated by the following sets of sensor-based information: a unique identification (ID), GPS position where the medical data was collected, time stamp (TS), heart rate (HR), stress level (SL), and physical activity (PA). This information is made available to the web service (described later) from which caregivers can analyze and take proactive or reactive decisions.


### 3.4. Abnormality and Stress Level Detector

The abnormality and stress level collector use the collected vital signs data to identify abnormal heart rate episodes (AHREs).AHREs are identified when the HR falls outside the minimum and maximum thresholds for a given time window. The HR thresholds and time window are configured by the caregivers. We developed an algorithm that uses the thresholds to detect abnormal events, that is, to identify HR readings that are outside the configured thresholds for a longer time period than the time window configured.Figure2 shows the diagram for detecting abnormalities. The diagram starts with an abnormality flag in false and continuously receives HR samples. It identifies whether the incoming sample is outside the thresholds. The identification of a normal reading will reset the flag but an abnormality triggers a time stamp that is stored and accordingly sets the abnormality flag to true. Beyond this point, a normal reading resets the flag but further abnormal readings cause a comparison between the time stamp stored and the current time of the abnormal reading. If the period is longer than the time window, the algorithm alerts for an AHRE. Specifically, the steps of the process are described in the Algorithm 1.Figure 2
Diagram for identifying AHREs.double
Algorithm 1: Identification of AHREs.
Require: newSample of HR
Ensure: Identification of abnormality events
(1)
if newSample is normalRead then
(2)
staAbnormality isfalse
(3)
if staAbnormality is true then
(4)
if sampleTime−staAbnTim>gapTime then
(5)
Abnormal Episode
(6)
else
(7)
newSample
(8)
end if
(9)
else
(10)
staAbnormality estrue
(11)
staAbnTim it is equal to sampleTime
(12)
end if
(13)
end ifThe classification of a SL has two possible values: (a) a state without stress (SNS) or (b) a state with stress (SWS). Each one can be found in two types of activities: at rest or at a recurrent activity. The set of rules defined to establish the classification is described in Table1.Table 1
Classification of stress levels.
State
Activity
Rules
SNS
Exercise
LL
≤
HR
⁡
∧
⁡
HR
≤
UL
⁡
∗
⁡
1.15
Rest
LL
≤
HR
⁡
∧
⁡
FC
≤
LS
SWS
Exercise
HR
<
LL
⁡
∨
⁡
HR
>
UL
⁡
∗
⁡
1.15
Rest
HR
<
LL
⁡
∨
⁡
HR
>
ULIn order to classify a condition as SNS, it is important to identify the type of PA, which in turn can be classified as recurrent or rest. A recurrent activity is given when the analysis of the HR threshold set by the physician and a tolerance percentage (15%) are above the lower limit and below the upper limit with the tolerance percentage included. A rest activity is given when the previously configured thresholds are met. Finally, for the classification of SWS, the same set of rules is used; however, if one of them is fulfilled, it is sufficient to perform this classification.The Table1 shows the status classifications of a wandering patient, where HR represents the heart rate, LL the lower HR limit for the patient, and UL the upper HR limit for the patient.


### 3.5. Android Activities of the CMA-HR-SL

Figure3 shows a selection of screenshots of the mobile application of the CMA-HR-SL platform. The figure presents the main functionalities that can be performed with the modules implemented. A brief description of such modules is given hereafter:(i)
Login: Figure 3(a) shows a custom login, which is intended to authenticate user data due to the confidentiality requirements.(ii)
User and contact registration: this module is presented in Figures 3(b) and 3(c). It allows to register the user (i.e., patient) information (name, user, password, age, and sex) and contact information (name, kinship, e-mail, and phone number).(iii)
Central activity: Figure 3(d) shows a menu of submodules: (a) Start of service: it runs the service in the background of the HR monitoring, location sensing, and patient activity. (b) Pairing with the sensor: it performs the search and pairing with the external sensor. (c) Parameter setting: it allows setting HR thresholds, as well as a time window value, for identifying abnormal readings as shown in Figure 3(e). (d) Configuring energy-efficient handling and transmission policies: Figure 3(f) shows the setting of the type of policy with which the data will be transmitted. (e) Exit: to exit from the application.Figure 3
Mobile application modules. (a) Login. (b) Register I. (c) Register II. (d) Central Activity. (e) Configuration Parameters. (f) Configuration Policies.
(a)
(b)
(c)
(d)
(e)
(f)


## 3.1. A Specific Controller for Each Connected Sensor

Every time a new sensor is added to the middleware, a new controller is instantiated. This controller creates a session with the sensor in order to manage the connections as well as the data that will be sensed. This component also controls the sensing periodicity. According to its configuration, the controller sends information to the sensing scheduler (described below) to keep updated the vital signs that are monitored.


## 3.2. A Sensing Scheduler for Vital Signs and GPS Information

The scheduler component manages the addition of new sensors by creating new controllers. The scheduler orchestrates all the controllers with their connected sensors and receives the data related to the vital signs. The scheduler also prepares the information for the abnormality and stress level detector (described later). Every sensor datum is locally stored in this scheduler until the energy-efficient handling and transmission policies indicate to the scheduler that the data must be sent to the cloud storage service.For the case of a heart rate (HR) sensor, the sensor provides HR data through BLE wireless communication to the mobile application. At the same time, the GPS sensor provides the location of the patient. With the collected data, the application model will be able to classify the stress level (SL) according to the identification of an abnormal HR episode (AHRE) with the help of the abnormality and stress level detector and send this collected data to the private cloud whenever the transmission policy indicates to the scheduler to do it.


## 3.3. Energy-Efficient Handling and Transmission Policies

In order to find trade-offs between energy efficiency and transmission requirements of the patients’ information, we proposed three energy-efficient handling and transmission policies. The policies give caregivers the flexibility to select the criteria that better fits the patients’ needs. The policies are (a) storing by quantity, in which a certain number of data packages are collected, and they are transmitted to the cloud storage server; (b) storing by time, in which a certain number of data packages are collected for a specific time period, and they are transmitted to the cloud storage server; and (c) storing by abnormality detection, every time a collected data package is evaluated as abnormal, this data package is sent to the cloud storage.The data packages transmitted to the Cloud service are integrated by the following sets of sensor-based information: a unique identification (ID), GPS position where the medical data was collected, time stamp (TS), heart rate (HR), stress level (SL), and physical activity (PA). This information is made available to the web service (described later) from which caregivers can analyze and take proactive or reactive decisions.


## 3.4. Abnormality and Stress Level Detector

The abnormality and stress level collector use the collected vital signs data to identify abnormal heart rate episodes (AHREs).AHREs are identified when the HR falls outside the minimum and maximum thresholds for a given time window. The HR thresholds and time window are configured by the caregivers. We developed an algorithm that uses the thresholds to detect abnormal events, that is, to identify HR readings that are outside the configured thresholds for a longer time period than the time window configured.Figure2 shows the diagram for detecting abnormalities. The diagram starts with an abnormality flag in false and continuously receives HR samples. It identifies whether the incoming sample is outside the thresholds. The identification of a normal reading will reset the flag but an abnormality triggers a time stamp that is stored and accordingly sets the abnormality flag to true. Beyond this point, a normal reading resets the flag but further abnormal readings cause a comparison between the time stamp stored and the current time of the abnormal reading. If the period is longer than the time window, the algorithm alerts for an AHRE. Specifically, the steps of the process are described in the Algorithm 1.Figure 2
Diagram for identifying AHREs.double
Algorithm 1: Identification of AHREs.
Require: newSample of HR
Ensure: Identification of abnormality events
(1)
if newSample is normalRead then
(2)
staAbnormality isfalse
(3)
if staAbnormality is true then
(4)
if sampleTime−staAbnTim>gapTime then
(5)
Abnormal Episode
(6)
else
(7)
newSample
(8)
end if
(9)
else
(10)
staAbnormality estrue
(11)
staAbnTim it is equal to sampleTime
(12)
end if
(13)
end ifThe classification of a SL has two possible values: (a) a state without stress (SNS) or (b) a state with stress (SWS). Each one can be found in two types of activities: at rest or at a recurrent activity. The set of rules defined to establish the classification is described in Table1.Table 1
Classification of stress levels.
State
Activity
Rules
SNS
Exercise
LL
≤
HR
⁡
∧
⁡
HR
≤
UL
⁡
∗
⁡
1.15
Rest
LL
≤
HR
⁡
∧
⁡
FC
≤
LS
SWS
Exercise
HR
<
LL
⁡
∨
⁡
HR
>
UL
⁡
∗
⁡
1.15
Rest
HR
<
LL
⁡
∨
⁡
HR
>
ULIn order to classify a condition as SNS, it is important to identify the type of PA, which in turn can be classified as recurrent or rest. A recurrent activity is given when the analysis of the HR threshold set by the physician and a tolerance percentage (15%) are above the lower limit and below the upper limit with the tolerance percentage included. A rest activity is given when the previously configured thresholds are met. Finally, for the classification of SWS, the same set of rules is used; however, if one of them is fulfilled, it is sufficient to perform this classification.The Table1 shows the status classifications of a wandering patient, where HR represents the heart rate, LL the lower HR limit for the patient, and UL the upper HR limit for the patient.


## 3.5. Android Activities of the CMA-HR-SL

Figure3 shows a selection of screenshots of the mobile application of the CMA-HR-SL platform. The figure presents the main functionalities that can be performed with the modules implemented. A brief description of such modules is given hereafter:(i)
Login: Figure 3(a) shows a custom login, which is intended to authenticate user data due to the confidentiality requirements.(ii)
User and contact registration: this module is presented in Figures 3(b) and 3(c). It allows to register the user (i.e., patient) information (name, user, password, age, and sex) and contact information (name, kinship, e-mail, and phone number).(iii)
Central activity: Figure 3(d) shows a menu of submodules: (a) Start of service: it runs the service in the background of the HR monitoring, location sensing, and patient activity. (b) Pairing with the sensor: it performs the search and pairing with the external sensor. (c) Parameter setting: it allows setting HR thresholds, as well as a time window value, for identifying abnormal readings as shown in Figure 3(e). (d) Configuring energy-efficient handling and transmission policies: Figure 3(f) shows the setting of the type of policy with which the data will be transmitted. (e) Exit: to exit from the application.Figure 3
Mobile application modules. (a) Login. (b) Register I. (c) Register II. (d) Central Activity. (e) Configuration Parameters. (f) Configuration Policies.
(a)
(b)
(c)
(d)
(e)
(f)


## 4. Phase 2: CMA-HR-SL Functions for Storing Data in the Cloud

This section describes the CMA-HR-SL functions for storing data. It is a Cloud-based solution for storing the medical and location information of wandering patients in a single logical entity (the Cloud). The Cloud-based storage is an interface between the wandering patients and the assistance service (web service described in Section5). The contextual framework and the most important elements of the Cloud-based framework and the assistance services are graphically shown in Figure 4. In addition, the algorithmic representation of the overall monitoring and localization process is presented in Algorithm 2.Figure 4
Monitoring and location service framework.double
Algorithm 2: Monitoring and location process.
Require: Data to be monitored I=GPS,⁡HR,⁡SL not empty
Ensure: Identification of abnormality episodes
(1)
while I≠null do
(2)
if connection BLE is true then
(3)
CMA-HR-SL receivesI and executes anomaly identification algorithm
(4)
else
(5)
connection BLE isfalse
(6)
end if
(7)
Establish WiFi connection and sendI to external storage service
(8)
External storage service providesI to web platform
(9)
Carer visualizes episodes of abnormality of the patient from web platform
(10)
end whileThe main functionality of the cloud storage is to secure the information of the wandering patients for further analysis. It enables storing large data sets for heart rate, stress, and location monitoring services, which can be accessed when required. The storage server is used for sending, handling and visualization of information, and offering availability and practicality in data presentation. Access to the online database is authenticated with both the patient’s smartphone device and the web service. It is important to mention that data management security is outside the scope of the main objective of this research. The storage manager for the CMA-HR-SL storage functions is MySQL. In order to assess the required functionality, the cloud database has five tables that are described in Table2.Table 2
Tables in the system database.
Type of alert
Definition
User
Stores information related to the patient: user ID, name, user, age, gender, and password
Contact
Stores data related to the patient’s direct contact: contact ID, user ID, name, relationship, cell phone, and e-mail
Physician (caregiver)
This table contains personal physician’s (i.e., caregiver) information: physician ID, patient ID, name, user, e-mail, and password
Message
Table storing information of identified alert messages: Message ID, user ID, time stamp of the alert message identification, and the sent message
Readings
Stores information from identified abnormal readings: read ID, user ID, latitude, time stamp length of the reading, HR data, PA status, and SL of the patientThe elements defined above allow storing and organizing the information provided by the monitoring carried out by the mobile application, specifically, for the purpose of processing and analyzing the vital signs and location information stored in the system database.


## 5. Phase 3: CMA-HR-SL Support for Caregivers

The CMA-HR-SL platform allows caregivers to manage personal information from wandering patients, including reviewing and following up biomedical readings (TS, HR, GPS, SL, and PA), alert statuses, and abnormal locations so that they can assist the patients whenever the need arises. The service manages alerts about abnormal readings in order to take precaution or reactive actions as to avoid setbacks and serious alterations in patients’ health.The web platform was developed to browse through the stored information so that caregivers can have access to patients’ information at all times. The platform was developed with PHP language, and it includes the following four configuration modules: (a) Map: it is responsible for creating the map to view the location of the patient and consult the corresponding alert notification records for a given patient or a set of patients; (b) Configuration: this module is intended to protect (through authentication) the data when establishing connections to the DB; (c) GraphFiles: this module is intended to display data from heart rate readings during a short period of time; (d) Files: this module is responsible for making queries to the DB, for registering and displaying patients’ data and contacts. The web platform has two graphical interfaces: (1) Login interface and (2) Central activity interface. The Login interface is intended to register caregivers as well as to control the access to the monitored data of the patients. Figure5 shows the Login interface of the web platform. The Central activity interface allows the caregiver to check the readings, location, and graphical representations of the heart rates of the patients. Figure 6 shows a list of abnormal readings identified for each patient, where each reading includes the heart rate, time stamp, GPS location, and stress state of the patient. Figure 7 shows a patient location map, and Figure 8 shows a graphical representation of a patient’s HR data, date, and time of registration. Alerts can be retrieved or sent from the web server to the caregiver’s mobile device.Figure 5
Login.Figure 6
Central activity: shows list of abnormal readings identified with HR, GPS, TS, SL, and PA.Figure 7
Location of the patient’s GPS.Figure 8
HR chart analysis.


## 6. Results and Discussion

This section evaluates the Configurable Mobile Application and System for Heart Rate and Stress Level Monitoring (CMA-HR-SL) for wandering patients. Section6.1 evaluates the capabilities of our CMA-HR-SL approach to detect accurate heart rates and to determine whether high HR events are due to incremental physical activity or due to arrhythmic episodes. Next, Section 6.2 evaluates the effectiveness of our CMA-HR-SL handling and transmission policies as to save energy in smartphone devices while monitoring vital signs and mobility information of the wandering patients. Following on, Section 6.3 provides an overall monitoring assessment of eleven wandering patients during their everyday activities. For this purpose, patients with chronic diseases as well as healthy patients were monitored in indoor and outdoor areas. This experimental assessment was intended to demonstrate the capabilities of our CMA-HR-SL platform to identify abnormal heart rate, stress levels, and the GPS location of the wandering patients when alert episodes occur due to such alterations. Finally, Section 6.4 presents the typical response times of our CMA-HR-SL approach when abnormal behaviors are registered in the wandering patients. Namely, this section evaluates the response latency of our CMA-HR-SL approach to typical abnormal heart rate behavior.


### 6.1. Evaluation of Heart Rate-Aware Capabilities

This section compares the performance of our CMA-HR-SL approach with six state-of-the-art applications with the intention to put in context the holistic solution presented in this paper with respect to current heart rate monitoring applications. Following on, we present the capabilities of the CMA-HR-SL approach to detect whether a high HR event is due to incremental physical activity or due to arrhythmic episodes, namely high HR of patients in resting state.


#### 6.1.1. Comparing HR Monitoring with State-of-the Art Applications

There are several mobile applications in the market; however, many of them are focused on sports, and they lack continuous and long-term analysis functionality. This first experiment compares six of the best-rated HR monitoring applications in the market with our CMA-HR-SL mobile application. For this purpose, we measured the HR of a wandering patient in a resting state during two minutes with each application. Table3 shows the name, qualification, HR range, and minute of monitoring of the application. The data collected by our application was taken from the web service application. The results demonstrate that our platform collects accurate results which can be stored and analyzed for further assistance in wandering patients, if required.Table 3
Comparison between own app against best-rated HR applications.
Application name
Qualification
HR range at rest
Minute
Own application
—
69–75
h:01
Health-care monitor [11]
4.5
68–75
h:03
Single pulsometer [12]
4.4
66–72
h:05
Pulse heart rate monitor [13]
4.3
68–76
h:07
Runtastic heart rate: pulse [14]
4.3
68–76
h:09
Cardiograph [15]
3.8
69–72
h:11
SmartBand 2 [16]
3.4
68–75
h:13
Average HR
68–74


#### 6.2.2. High HR due to Physical Activity or High HR in Resting State

An HR abnormality event may be due to several factors. This section evaluates the capability of the CMA-HR-SL application to identify patients’ physical activity (PA). Specifically, this section demonstrates how the CMA-HR-SL application can determine whether the HR readings outside the configured range are due to physical activity or if the HR readings outside the thresholds occur in when the patient is at rest. This is an important assessment because sometimes a patient’s HR reading can be high due to physical activity (e.g., running, which could be considered normal), and, some others instead, a patient can register high HR during resting periods, the latter being an abnormality that is highly desirable to be detected. This evaluation was carried out during 50-minute activity monitoring, which was divided into rest and mobility episodes. This section determines the accuracy of the CMA-HR-SL application while detecting rest and mobility episodes.The results of this test are summarized in Table4, and they are graphically shown in Figure 9. RE represents an episode of high HR due to physical activity, and RS represents an episode of high HR of the patient in a resting state. Table 4 shows the time at which the RE and RS episodes start (expected start) and the time at which each episode is monitored (monitored start) by the CMA-HR-SL application. The difference between the expected and monitored is the time that the CMA-HR-SL application takes to determine the state of the patient while registering the HR. In average, the CMA-HR-SL application takes 44.5 seconds to determine that a given HR is due to physical activity and 26.5 seconds to determine that the HR is due to potential arrhythmic behavior.Table 4
Average in activity response.
Activity
Expected start
Monitored start
RE
15:18:00
15:18:45
RS
15:28:00
15:28:36
RE
15:38:00
15:38:44
RS
15:48:00
15:48:17
Activity
Average in response
RE
44.5 sec
RS
26.5 secFigure 9
Activity monitoring over time.


### 6.2. Energy Consumption with Energy-Efficient Handling and Transmission Policies

In order to compare the energy load of the CMA-HR-SL application when it runs with other (common) applications in smartphone devices, we defined two experimental test sets: (Set A) tests performed with additional background applications in the smartphone, causing these to affect in some indirect way the rapid consumption of the battery and (Set B) tests performed only with the CMA-HR-SL mobile application without any additional applications. Next, we carried out experimental test and analysis to demonstrate the effectiveness of our CMA-HR-SL handling and transmission policies for saving energy in the smartphone devices while monitoring vital signs and mobility information of the wandering patients.In order to analyze the energy consumption of our monitoring application, two test sets were designed as follows:(i)
Test Set A: tests including our CMA-HR-SL application running with social applications (Facebook, WhatsApp, Gmail, Spotify, Instagram, Twitter, etc.).(ii)
Test Set B: tests including our CMA-HR-SL application running only with essential factory applications, namely, with Android applications needed for functional Smartphone operation.The rest of this section analyses the impact of different energy-efficient handling and transmission policies on the performance of our CMA-HR-SL application for Test Set A and Test Set B described earlier. The policies allow the configuration of the following parameters: size of packages transmitted, time of transmission intervals, and alerts. The tests were executed starting with 100% battery, running only our mobile monitoring application on the smartphone.We have used three energy-efficient management and transmission policies for each set of tests (A and B). For the sake of clarity, we define the three policies included in our experimental tests: Package Policy considers an amount of packages that will be collected by the application and a trigger event to send the package set to the cloud storage service, where each packet is composed of the following data: HR, GPS, TS, SL, and PA; Time Policy drives the collection and sending of packages based on a fixed time. The time parameter of this Policy is previously configured. The Time Policy drives the application to send the packages periodically to the service storage in the cloud; and lastly, Alert Policy considers the identification of only packages with abnormal biomedical readings so that they are sent to the storage service regardless of time and quantity.Based on the information given by a caregiver where monitoring for wandering patients with chronic illnesses should be at least 12 hours, we carried out our experimental tests taking such time-frame into account. The energy consumption results (i.e., battery life time) for Test Set A is provided in Section6.2.1. Tables 5–7 present the data collected from the experimental cases, which show the duration of the monitoring, as well as the total and abnormal readings identified for each test set corresponding to each of the shipping policies. In turn, Figures 10–12 present graphically the impact of the battery consumption for each of the energy-efficient handling and transmission policies, which are Package Policy, Time Policy, and Alert Policy, respectively. Similarly, the energy consumption results (i.e., battery life time) for Test Set B are provided in Section 6.2.2. Tables 8–10 similarly present the data collected from the experimental cases, showing the time of the biomedical monitoring, as well as the total and abnormal readings identified, this for Package Policy, Time Policy, and Alert Policy, respectively. In turn, Figures 13–15 represent graphically the impact of the battery consumption of the mobile device for each of the proposed shipping policies, which are Package Policy, Time Policy, and Alert Policy, respectivelyTable 5
Package Policy over time for Test Set A.
Packages
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
50
12:05:12
21:57:33
09:52:21
11,900
1,555
10,345
70
10:36:43
21:03:16
10:26:33
12,685
1,098
11,587
90
11:29:37
21:36:40
10:07:03
13,912
1,809
12,103Table 6
Time Policy over time for Test Set A.
Time
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
15 min.
11:32:22
21:37:21
10:04:59
4,592
198
4,394
30 min.
12:09:13
23:05:49
10:56:36
4,246
1,221
3,025
60 min.
11:01:39
21:26:21
10:24:42
1,328
682
646Table 7
Alert Policy over time for Test Set A.
Classification
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
Healthy without phisical activity (HPnPA)
09:22:11
21:14:03
11:51:52
345
345
0
Healthy with phisical activity (HPwPA)
12:30:26
22:35:46
10:05:20
1,646
1,646
0
Chronic disease (PwCD)
10:16:32
20:40:30
10:23:58
705
705
0Figure 10
Test Set A: Package Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 11
Test Set A: Time Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 12
Test Set A: Alert Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Table 8
Package Policy over time (B).
Packages
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
50
11:28:43
22:04:51
10:36:08
12,365
1,010
11,355
70
09:53:53
20:31:43
10:37:50
10,058
2,467
7,591
90
09:34:44
20:48:48
11:14:04
13,485
1,187
12,298Table 9
Time Policy over time (B).
Time
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
15 min.
10:46:54
20:49:53
10:02:59
4,664
1,429
3,235
30 min.
12:11:53
23:36:27
11:24:34
4,178
1,307
2,871
60 min.
10:30:30
21:28:40
10:58:10
1,445
1,212
233Table 10
Alert Policy over time (B).
Classification
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
Healthy without phisical activity (HPnPA)
10:42:40
21:24:58
10:42:18
1,559
1,559
0
Healthy with phisical activity (HPwPA)
09:02:53
20:34:02
11:31:09
578
578
0
Chronic disease (PwCD)
10:10:34
20:39:15
10:28:41
1,133
1,133
0Figure 13
Package B: Package Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 14
Set B: Time Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 15
Set B: Alert Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)The results of enforcing our energy-efficient handling and transmission policies in Test Set A and Test Set B, and a discussion of these results are provided hereafter in Sections6.2.1, 6.2.2, and 6.2.3.


#### 6.2.1. Results of Energy-Efficient Handling and Transmission Policies for Test Set A

This section presents the results of battery energy consumption of Test Set A with the three energy-efficient handling and transmission policies: Package Policy, Time Policy, and Alert Policy. For Package Policy, the monitoring application was configured to transmit groups of 50, 70, and 90 packages. For Time Policy, the mobile application was configured to transmit information within time intervals of 15 min, 30 min, and 60 min. For Alert Policy, we defined three types of alerts: (1) healthy wandering patient without physical activity (HPnPA); (2) healthy wandering patient with physical activity (HPwPA); and (3) wandering patient with chronic disease (PwCD).Tables5–7 show the results of the energy consumption for the three policies described above. Each table gives the start time, end time, test duration, number of inserted readings, number of abnormal readings, and the difference between these two. Figures 10–11 present graphically the impact of the battery consumption for each of the energy-efficient handling and transmission policies, namely from 100% to 0% of battery charge. The figures also give the difference between the readings inserted and the abnormal readings identified for each type of policy.


#### 6.2.2. Results of Energy-Efficient Handling and Transmission Policies for Test Set B

In this experiment, the tests were carried out in a controlled scenario, where those must-have applications were eliminated, that somehow realize updates in the system altering the behavior of the battery discharge. Likewise, the tests performed on set A and suspended mode screen were executed but now in this new controlled environment and with the same shipping policy configuration sizes. Tables8–10 also contain seven fields specifying the send variable, start time, end time, test duration, inserted readings, abnormal readings identified, and the difference between these two, also showing graphically the discharge of the battery, as well as the difference between the readings inserted and the abnormal readings identified, all this for each type of policy.


#### 6.2.3. Discussion of Results for Energy-Efficient Policies

The results presented in Section6.2.1 and Section 6.2.2 represent an important source of information to analyze the evolution of smartphone battery consumption as function of the size of packages, time transmit readings, and type of alert classification and to analyze battery consumption when the CMA-HR-SL application is executed in a controlled or not controlled environment.Experimental results for Package Policy: In Test Set A, when the size of the package was 70, the battery lasted 10 hours, 26 minutes, 33 seconds, and a number of1,098 abnormal readings were identified from a total of the 11,587 readings inserted. When the packet size was 90, the battery lasted 10 hours, 07 minutes, 03 seconds with 1,809 abnormal readings identified from the 13,912 readings inserted. From this result, we can conclude that the more abnormal readings registered, the higher the battery consumption. This is because abnormal readings use more data transmission and, therefore, the battery life is lower, regardless of the size of the package transmission. For Test Set B, when the size of the packages was 90, the battery life was 11 hours, 14 minutes, 04 seconds with 1,187 abnormal readings identified from the 13,485 inserted. This is because apart from being in a controlled environment, the number of abnormal readings was lower than that of Test Set A; consequently, the duration of the battery was longer.Experimental results for Time Policy: In Test Set A, when the time to transmit readings was set to 30 minutes, the battery consumption time was 10 hours, 56 minutes, 36 seconds with1,221 identified abnormal readings from the 4,246 readings inserted. However, when the time to transmit readings was set to 60 minutes, the battery consumption time was 10 hours, 24 minutes, 42 seconds with 682 abnormal readings identified from the 1,328 readings inserted. There are two reasons for this behavior: (1) The test was executed with Test Set A, where the system environment of the mobile device is not controlled which means, it has applications that raise the battery consumption; and (2) The abnormal reading identified in the 60 minutes transmission is above the average of the total of readings inserted, leading to higher battery consumption. On the other hand, for Test Set B, when the time to transmit readings was set to 30 minutes, the battery duration was 11 hours, 24 minutes, 34 seconds with 1,307 abnormal readings identified out of a total of 4,178 inserted readings; this was due to the higher number of abnormal readings with respect to Test Set A. In general, Test Set B produced less total readings because of the controlled environment nature of the test, that is, with less applications running on the mobile device.Alert Policy is an important tool for finding trade-offs between intelligent monitoring, efficiency of abnormality notifications, and smartphone battery duration. In this regard, Figures12(a) and 15(a) show results of battery performance for the patient’s medical states considered. Figure 12(a) shows that lower abnormal readings produced less information for upload to the external storage service, resulting in a monitoring time of 10 continuous hours, registering 20% of battery level at the end of the test. On the other hand, the PwCD and HPwPA states registered battery utilization of 1 to 5%, preventing continuous monitoring. It is important to mention that these tests were performed with Test Set A, where the smartphone environment was not controlled. Figure 15(a) presents the results of Alert Policy with Test Set B. The figure shows that HPwPA medical state produced better performance in terms of energy utilization, registering a battery utilization level of 18% after 10 hours of continuous monitoring due to the low number of abnormal readings registered. Instead, the PwCD and HPnPA states registered battery utilization lower than 10% battery in 10 hours of continuous monitoring.Finally, regarding the tests of Alert Policy, the battery duration is a function of the type of health classification of the patient, the patient’s medical state, and number of alert readings identified. The results demonstrate the robustness of our approach to adapt and register abnormalities in the wandering patients. Nevertheless, a more elaborate evaluation of continuous monitoring with wandering patients with several medical states is presented in the following section.


### 6.3. Overall Monitoring Assessment for Patients with Different Medical States

This section presents monitoring results of our CMA-HR-SL approach while monitoring wandering patients with different medical and physical states. We monitored eleven wandering patients grouped as follows: (1) three healthy wandering patients without physical activity (HPnPA); (2) three healthy wandering patients with physical activity (HPwPA); and (3) five wandering patients with chronic disease (PwCD). For these three classifications, we tested the same number of Alert Policies. The details of the type of alert and the patients are provided in Table11.Table 11
Types of alert for patient.
Type of alert
Definition
HPnPA
Healthy wandering patient without physical activity: the patients do not suffer from any chronic disease, and they do not perform physical activities. Three patients
HPwPA
Healthy wandering patient with physical activity: the patients do not suffer from any chronic disease, and they regularly perform physical activities. Three subjects
PwCD
Wandering patient with chronic disease: this classification includes wandering patients with chronic disease without physical activity (PwCDnPA) and wandering patients with chronic disease with physical activity (PwCDwPA). The chronic diseases are: diabetes, high blood pressure (HBP), Wolff Parkinson White (WPW), and nonspecific chronic ulcerative colitis (NSCUC). Five patientsThe monitoring for each wandering patient was performed in their daily activities in order to identify alert episodes of heart rate (HR) and stress levels (SL). The test was carried out using Alert Policy, which consists of identifying abnormal SL episodes according to the SL rules presented in Table1 and abnormal HR episodes. The HR thresholds are defined by the caregiver based on normal heart beats per minute (bpm). For our tests, the caregiver selected the threshold 60bpm≤HR≤100bpm. In this regard, a HR outside of this threshold is considered abnormal, and the web system would issue alerts for appropriate patient’s assistance.Since alerts are issued according to the physical and medical state of each patient, the battery consumption times vary for each patient. We measured the battery consumption time until the charge of the battery was 0%. Four of the eleven tests lasted around eleven hrs and seven lasted around ten hours. Tables12 and 13 provide the duration time for each patient while monitoring HR and SL in our overall assessment.Table 12
Functional test with approximate duration of 11 hours.
Monitoring
Duration
Patient User A
11:15:36
Patient User B
11:21:30
Patient User D
11:07:06
Patient User G
11:35:45Table 13
Functional test with approximate duration of 10 hours.
Monitoring
Duration
Patient User C
10:48:41
Patient User E
10:42:56
Patient User F
10:30:54
Patient User H
10:57:16
Patient User I
10:50:26
Patient User J
10:12:22
Patient User K
10:28:41It is important to mention that the physiological increase in HR of all readings was due to various external events (daily activities, emotions, stress, effort, etc.) as well as due to REs and RSs activities. The lowest and highest physiological HR registered in our tests was45bpm and 140bpm, respectively. Our tests confirmed that the higher the number of alerts, the lower the battery life; moreover, the CMA-HR-SL platform is able to register all of these alerts and, more importantly, is able to issue alerts to caregivers to take care of the wandering patients accordingly. Tables 14–16 show the results (abnormal readings, activity REs readings, stress level, and HR average) of our overall assessment. It is worth mentioning that for the results of the stress level, all patients registered abnormal levels; this is because during the whole test, the patients registered a number of abnormal episodes (registered as abnormal in Tables 14–16). Also, the physical activity and HR were effectively used to determine appropriate stress levels.Table 14
HPnPA classification.
User
Classification
Age
RE activity
SL
Abnormals
HR average
Duration (hh:mm:ss)
User A1
HPnPA
56
71
Abnormal
71
93
11:15:36
User B2
HPnPA
49
58
Abnormal
871
95
11:21:30
User C3
HPnPA
32
201
Abnormal
787
82
10:48:41Table 15
HPwPA classification.
User
Classification
Age
RE activity
SL
Abnormal
HR average
Duration (hh:mm:ss)
User D4
HPwPA
24
175
Abnormal
729
72
11:07:06
User E5
HPwPA
27
84
Abnormal
2,125
72
10:42:56
User F6
HPwPA
24
233
Abnormal
236
84
10:30:54Table 16
PwCD classification.
User
Classification
Age
HR activity
SL
Abnormal
HR average
Duration (hh:mm:ss)
User G7
PwCDwPA (HA y Pre Diabetes)
69
0
Abnormal
4
86
11:35:45
User H8
PwCDwPA (WPW)
26
29
Abnormal
1,055
95
10:57:16
User I9
PwCDwPA (HA)
50
40
Abnormal
191
82
10:50:26
User J10
PwCDwPA (Diabetes)
42
61
Abnormal
1,834
77
10:12:22
User K11
PwCDwPA (CUCI)
24
29
Abnormal
578
82
10:28:41


### 6.4. Response Time of the CMS-HR-SL Platform

The CMS-HR-SL platform presented in this paper has been designed to alert caregivers when wandering patients need assistance. In this sense, timely reaction to sudden issues like abnormal heart rates, abnormal stress levels, and abnormal location of wandering patients is a pivotal requirement. This section evaluates the response time of the CMS-HR-SL platform when patients are in the need for assistance. Table17 presents information of three patients (see patients ID 70, 54, and 60 in the leftmost column in Table 17) that presented alterations in their heart rates during our tests. The column TS-FRA-HR shows the time stamp when the first abnormal heart rate is present in the wandering patient; this information has been obtained from the mobile application. The column TS-NC shows the time stamp when the caregiver receives the alert in the web system, this information has been obtained from the web system directly. The difference between the time when the alert is produced (TS-FRA-HR) and the time when the alert is received by the caregiver (TS-NC) is presented in the Latency column in Table 17. The column ATR-HR presents the amount of alterations of heart rate in the corresponding patient received after the first abnormal reading. From the above, we determined that the order of time needed to receive an alert when an abnormality is recorded in a wandering patient is in the range of 0–3 seconds (minimum) and 10–12 seconds (maximum).Table 17
Time in response.
ID patient
TS-FRA-HR (hh:mm:ss)
TS-NC (hh:mm:ss)
Latency
ATR-HR
70
21:03:05
21:03:05
0 seg.
23
70
21:09:14
21:09:17
3 seg.
6
54
20:11:31
20:11:43
12 seg.
5
54
20:18:58
20:19:08
10 seg.
2
60
12:15:35
12:15:40
5 seg.
2
60
13:23:03
13:23:03
0 seg.
22


## 6.1. Evaluation of Heart Rate-Aware Capabilities

This section compares the performance of our CMA-HR-SL approach with six state-of-the-art applications with the intention to put in context the holistic solution presented in this paper with respect to current heart rate monitoring applications. Following on, we present the capabilities of the CMA-HR-SL approach to detect whether a high HR event is due to incremental physical activity or due to arrhythmic episodes, namely high HR of patients in resting state.


### 6.1.1. Comparing HR Monitoring with State-of-the Art Applications

There are several mobile applications in the market; however, many of them are focused on sports, and they lack continuous and long-term analysis functionality. This first experiment compares six of the best-rated HR monitoring applications in the market with our CMA-HR-SL mobile application. For this purpose, we measured the HR of a wandering patient in a resting state during two minutes with each application. Table3 shows the name, qualification, HR range, and minute of monitoring of the application. The data collected by our application was taken from the web service application. The results demonstrate that our platform collects accurate results which can be stored and analyzed for further assistance in wandering patients, if required.Table 3
Comparison between own app against best-rated HR applications.
Application name
Qualification
HR range at rest
Minute
Own application
—
69–75
h:01
Health-care monitor [11]
4.5
68–75
h:03
Single pulsometer [12]
4.4
66–72
h:05
Pulse heart rate monitor [13]
4.3
68–76
h:07
Runtastic heart rate: pulse [14]
4.3
68–76
h:09
Cardiograph [15]
3.8
69–72
h:11
SmartBand 2 [16]
3.4
68–75
h:13
Average HR
68–74


### 6.2.2. High HR due to Physical Activity or High HR in Resting State

An HR abnormality event may be due to several factors. This section evaluates the capability of the CMA-HR-SL application to identify patients’ physical activity (PA). Specifically, this section demonstrates how the CMA-HR-SL application can determine whether the HR readings outside the configured range are due to physical activity or if the HR readings outside the thresholds occur in when the patient is at rest. This is an important assessment because sometimes a patient’s HR reading can be high due to physical activity (e.g., running, which could be considered normal), and, some others instead, a patient can register high HR during resting periods, the latter being an abnormality that is highly desirable to be detected. This evaluation was carried out during 50-minute activity monitoring, which was divided into rest and mobility episodes. This section determines the accuracy of the CMA-HR-SL application while detecting rest and mobility episodes.The results of this test are summarized in Table4, and they are graphically shown in Figure 9. RE represents an episode of high HR due to physical activity, and RS represents an episode of high HR of the patient in a resting state. Table 4 shows the time at which the RE and RS episodes start (expected start) and the time at which each episode is monitored (monitored start) by the CMA-HR-SL application. The difference between the expected and monitored is the time that the CMA-HR-SL application takes to determine the state of the patient while registering the HR. In average, the CMA-HR-SL application takes 44.5 seconds to determine that a given HR is due to physical activity and 26.5 seconds to determine that the HR is due to potential arrhythmic behavior.Table 4
Average in activity response.
Activity
Expected start
Monitored start
RE
15:18:00
15:18:45
RS
15:28:00
15:28:36
RE
15:38:00
15:38:44
RS
15:48:00
15:48:17
Activity
Average in response
RE
44.5 sec
RS
26.5 secFigure 9
Activity monitoring over time.


## 6.1.1. Comparing HR Monitoring with State-of-the Art Applications

There are several mobile applications in the market; however, many of them are focused on sports, and they lack continuous and long-term analysis functionality. This first experiment compares six of the best-rated HR monitoring applications in the market with our CMA-HR-SL mobile application. For this purpose, we measured the HR of a wandering patient in a resting state during two minutes with each application. Table3 shows the name, qualification, HR range, and minute of monitoring of the application. The data collected by our application was taken from the web service application. The results demonstrate that our platform collects accurate results which can be stored and analyzed for further assistance in wandering patients, if required.Table 3
Comparison between own app against best-rated HR applications.
Application name
Qualification
HR range at rest
Minute
Own application
—
69–75
h:01
Health-care monitor [11]
4.5
68–75
h:03
Single pulsometer [12]
4.4
66–72
h:05
Pulse heart rate monitor [13]
4.3
68–76
h:07
Runtastic heart rate: pulse [14]
4.3
68–76
h:09
Cardiograph [15]
3.8
69–72
h:11
SmartBand 2 [16]
3.4
68–75
h:13
Average HR
68–74


## 6.2.2. High HR due to Physical Activity or High HR in Resting State

An HR abnormality event may be due to several factors. This section evaluates the capability of the CMA-HR-SL application to identify patients’ physical activity (PA). Specifically, this section demonstrates how the CMA-HR-SL application can determine whether the HR readings outside the configured range are due to physical activity or if the HR readings outside the thresholds occur in when the patient is at rest. This is an important assessment because sometimes a patient’s HR reading can be high due to physical activity (e.g., running, which could be considered normal), and, some others instead, a patient can register high HR during resting periods, the latter being an abnormality that is highly desirable to be detected. This evaluation was carried out during 50-minute activity monitoring, which was divided into rest and mobility episodes. This section determines the accuracy of the CMA-HR-SL application while detecting rest and mobility episodes.The results of this test are summarized in Table4, and they are graphically shown in Figure 9. RE represents an episode of high HR due to physical activity, and RS represents an episode of high HR of the patient in a resting state. Table 4 shows the time at which the RE and RS episodes start (expected start) and the time at which each episode is monitored (monitored start) by the CMA-HR-SL application. The difference between the expected and monitored is the time that the CMA-HR-SL application takes to determine the state of the patient while registering the HR. In average, the CMA-HR-SL application takes 44.5 seconds to determine that a given HR is due to physical activity and 26.5 seconds to determine that the HR is due to potential arrhythmic behavior.Table 4
Average in activity response.
Activity
Expected start
Monitored start
RE
15:18:00
15:18:45
RS
15:28:00
15:28:36
RE
15:38:00
15:38:44
RS
15:48:00
15:48:17
Activity
Average in response
RE
44.5 sec
RS
26.5 secFigure 9
Activity monitoring over time.


## 6.2. Energy Consumption with Energy-Efficient Handling and Transmission Policies

In order to compare the energy load of the CMA-HR-SL application when it runs with other (common) applications in smartphone devices, we defined two experimental test sets: (Set A) tests performed with additional background applications in the smartphone, causing these to affect in some indirect way the rapid consumption of the battery and (Set B) tests performed only with the CMA-HR-SL mobile application without any additional applications. Next, we carried out experimental test and analysis to demonstrate the effectiveness of our CMA-HR-SL handling and transmission policies for saving energy in the smartphone devices while monitoring vital signs and mobility information of the wandering patients.In order to analyze the energy consumption of our monitoring application, two test sets were designed as follows:(i)
Test Set A: tests including our CMA-HR-SL application running with social applications (Facebook, WhatsApp, Gmail, Spotify, Instagram, Twitter, etc.).(ii)
Test Set B: tests including our CMA-HR-SL application running only with essential factory applications, namely, with Android applications needed for functional Smartphone operation.The rest of this section analyses the impact of different energy-efficient handling and transmission policies on the performance of our CMA-HR-SL application for Test Set A and Test Set B described earlier. The policies allow the configuration of the following parameters: size of packages transmitted, time of transmission intervals, and alerts. The tests were executed starting with 100% battery, running only our mobile monitoring application on the smartphone.We have used three energy-efficient management and transmission policies for each set of tests (A and B). For the sake of clarity, we define the three policies included in our experimental tests: Package Policy considers an amount of packages that will be collected by the application and a trigger event to send the package set to the cloud storage service, where each packet is composed of the following data: HR, GPS, TS, SL, and PA; Time Policy drives the collection and sending of packages based on a fixed time. The time parameter of this Policy is previously configured. The Time Policy drives the application to send the packages periodically to the service storage in the cloud; and lastly, Alert Policy considers the identification of only packages with abnormal biomedical readings so that they are sent to the storage service regardless of time and quantity.Based on the information given by a caregiver where monitoring for wandering patients with chronic illnesses should be at least 12 hours, we carried out our experimental tests taking such time-frame into account. The energy consumption results (i.e., battery life time) for Test Set A is provided in Section6.2.1. Tables 5–7 present the data collected from the experimental cases, which show the duration of the monitoring, as well as the total and abnormal readings identified for each test set corresponding to each of the shipping policies. In turn, Figures 10–12 present graphically the impact of the battery consumption for each of the energy-efficient handling and transmission policies, which are Package Policy, Time Policy, and Alert Policy, respectively. Similarly, the energy consumption results (i.e., battery life time) for Test Set B are provided in Section 6.2.2. Tables 8–10 similarly present the data collected from the experimental cases, showing the time of the biomedical monitoring, as well as the total and abnormal readings identified, this for Package Policy, Time Policy, and Alert Policy, respectively. In turn, Figures 13–15 represent graphically the impact of the battery consumption of the mobile device for each of the proposed shipping policies, which are Package Policy, Time Policy, and Alert Policy, respectivelyTable 5
Package Policy over time for Test Set A.
Packages
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
50
12:05:12
21:57:33
09:52:21
11,900
1,555
10,345
70
10:36:43
21:03:16
10:26:33
12,685
1,098
11,587
90
11:29:37
21:36:40
10:07:03
13,912
1,809
12,103Table 6
Time Policy over time for Test Set A.
Time
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
15 min.
11:32:22
21:37:21
10:04:59
4,592
198
4,394
30 min.
12:09:13
23:05:49
10:56:36
4,246
1,221
3,025
60 min.
11:01:39
21:26:21
10:24:42
1,328
682
646Table 7
Alert Policy over time for Test Set A.
Classification
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
Healthy without phisical activity (HPnPA)
09:22:11
21:14:03
11:51:52
345
345
0
Healthy with phisical activity (HPwPA)
12:30:26
22:35:46
10:05:20
1,646
1,646
0
Chronic disease (PwCD)
10:16:32
20:40:30
10:23:58
705
705
0Figure 10
Test Set A: Package Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 11
Test Set A: Time Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 12
Test Set A: Alert Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Table 8
Package Policy over time (B).
Packages
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
50
11:28:43
22:04:51
10:36:08
12,365
1,010
11,355
70
09:53:53
20:31:43
10:37:50
10,058
2,467
7,591
90
09:34:44
20:48:48
11:14:04
13,485
1,187
12,298Table 9
Time Policy over time (B).
Time
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
15 min.
10:46:54
20:49:53
10:02:59
4,664
1,429
3,235
30 min.
12:11:53
23:36:27
11:24:34
4,178
1,307
2,871
60 min.
10:30:30
21:28:40
10:58:10
1,445
1,212
233Table 10
Alert Policy over time (B).
Classification
Hour-start
Hour-end
Duration
Readings
Abnormal
Delta
Healthy without phisical activity (HPnPA)
10:42:40
21:24:58
10:42:18
1,559
1,559
0
Healthy with phisical activity (HPwPA)
09:02:53
20:34:02
11:31:09
578
578
0
Chronic disease (PwCD)
10:10:34
20:39:15
10:28:41
1,133
1,133
0Figure 13
Package B: Package Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 14
Set B: Time Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)Figure 15
Set B: Alert Policy. (a) Energy consumption over time. (b) Readings inserted between identified abnormal readings.
(a)
(b)The results of enforcing our energy-efficient handling and transmission policies in Test Set A and Test Set B, and a discussion of these results are provided hereafter in Sections6.2.1, 6.2.2, and 6.2.3.


### 6.2.1. Results of Energy-Efficient Handling and Transmission Policies for Test Set A

This section presents the results of battery energy consumption of Test Set A with the three energy-efficient handling and transmission policies: Package Policy, Time Policy, and Alert Policy. For Package Policy, the monitoring application was configured to transmit groups of 50, 70, and 90 packages. For Time Policy, the mobile application was configured to transmit information within time intervals of 15 min, 30 min, and 60 min. For Alert Policy, we defined three types of alerts: (1) healthy wandering patient without physical activity (HPnPA); (2) healthy wandering patient with physical activity (HPwPA); and (3) wandering patient with chronic disease (PwCD).Tables5–7 show the results of the energy consumption for the three policies described above. Each table gives the start time, end time, test duration, number of inserted readings, number of abnormal readings, and the difference between these two. Figures 10–11 present graphically the impact of the battery consumption for each of the energy-efficient handling and transmission policies, namely from 100% to 0% of battery charge. The figures also give the difference between the readings inserted and the abnormal readings identified for each type of policy.


### 6.2.2. Results of Energy-Efficient Handling and Transmission Policies for Test Set B

In this experiment, the tests were carried out in a controlled scenario, where those must-have applications were eliminated, that somehow realize updates in the system altering the behavior of the battery discharge. Likewise, the tests performed on set A and suspended mode screen were executed but now in this new controlled environment and with the same shipping policy configuration sizes. Tables8–10 also contain seven fields specifying the send variable, start time, end time, test duration, inserted readings, abnormal readings identified, and the difference between these two, also showing graphically the discharge of the battery, as well as the difference between the readings inserted and the abnormal readings identified, all this for each type of policy.


### 6.2.3. Discussion of Results for Energy-Efficient Policies

The results presented in Section6.2.1 and Section 6.2.2 represent an important source of information to analyze the evolution of smartphone battery consumption as function of the size of packages, time transmit readings, and type of alert classification and to analyze battery consumption when the CMA-HR-SL application is executed in a controlled or not controlled environment.Experimental results for Package Policy: In Test Set A, when the size of the package was 70, the battery lasted 10 hours, 26 minutes, 33 seconds, and a number of1,098 abnormal readings were identified from a total of the 11,587 readings inserted. When the packet size was 90, the battery lasted 10 hours, 07 minutes, 03 seconds with 1,809 abnormal readings identified from the 13,912 readings inserted. From this result, we can conclude that the more abnormal readings registered, the higher the battery consumption. This is because abnormal readings use more data transmission and, therefore, the battery life is lower, regardless of the size of the package transmission. For Test Set B, when the size of the packages was 90, the battery life was 11 hours, 14 minutes, 04 seconds with 1,187 abnormal readings identified from the 13,485 inserted. This is because apart from being in a controlled environment, the number of abnormal readings was lower than that of Test Set A; consequently, the duration of the battery was longer.Experimental results for Time Policy: In Test Set A, when the time to transmit readings was set to 30 minutes, the battery consumption time was 10 hours, 56 minutes, 36 seconds with1,221 identified abnormal readings from the 4,246 readings inserted. However, when the time to transmit readings was set to 60 minutes, the battery consumption time was 10 hours, 24 minutes, 42 seconds with 682 abnormal readings identified from the 1,328 readings inserted. There are two reasons for this behavior: (1) The test was executed with Test Set A, where the system environment of the mobile device is not controlled which means, it has applications that raise the battery consumption; and (2) The abnormal reading identified in the 60 minutes transmission is above the average of the total of readings inserted, leading to higher battery consumption. On the other hand, for Test Set B, when the time to transmit readings was set to 30 minutes, the battery duration was 11 hours, 24 minutes, 34 seconds with 1,307 abnormal readings identified out of a total of 4,178 inserted readings; this was due to the higher number of abnormal readings with respect to Test Set A. In general, Test Set B produced less total readings because of the controlled environment nature of the test, that is, with less applications running on the mobile device.Alert Policy is an important tool for finding trade-offs between intelligent monitoring, efficiency of abnormality notifications, and smartphone battery duration. In this regard, Figures12(a) and 15(a) show results of battery performance for the patient’s medical states considered. Figure 12(a) shows that lower abnormal readings produced less information for upload to the external storage service, resulting in a monitoring time of 10 continuous hours, registering 20% of battery level at the end of the test. On the other hand, the PwCD and HPwPA states registered battery utilization of 1 to 5%, preventing continuous monitoring. It is important to mention that these tests were performed with Test Set A, where the smartphone environment was not controlled. Figure 15(a) presents the results of Alert Policy with Test Set B. The figure shows that HPwPA medical state produced better performance in terms of energy utilization, registering a battery utilization level of 18% after 10 hours of continuous monitoring due to the low number of abnormal readings registered. Instead, the PwCD and HPnPA states registered battery utilization lower than 10% battery in 10 hours of continuous monitoring.Finally, regarding the tests of Alert Policy, the battery duration is a function of the type of health classification of the patient, the patient’s medical state, and number of alert readings identified. The results demonstrate the robustness of our approach to adapt and register abnormalities in the wandering patients. Nevertheless, a more elaborate evaluation of continuous monitoring with wandering patients with several medical states is presented in the following section.


## 6.2.1. Results of Energy-Efficient Handling and Transmission Policies for Test Set A

This section presents the results of battery energy consumption of Test Set A with the three energy-efficient handling and transmission policies: Package Policy, Time Policy, and Alert Policy. For Package Policy, the monitoring application was configured to transmit groups of 50, 70, and 90 packages. For Time Policy, the mobile application was configured to transmit information within time intervals of 15 min, 30 min, and 60 min. For Alert Policy, we defined three types of alerts: (1) healthy wandering patient without physical activity (HPnPA); (2) healthy wandering patient with physical activity (HPwPA); and (3) wandering patient with chronic disease (PwCD).Tables5–7 show the results of the energy consumption for the three policies described above. Each table gives the start time, end time, test duration, number of inserted readings, number of abnormal readings, and the difference between these two. Figures 10–11 present graphically the impact of the battery consumption for each of the energy-efficient handling and transmission policies, namely from 100% to 0% of battery charge. The figures also give the difference between the readings inserted and the abnormal readings identified for each type of policy.


## 6.2.2. Results of Energy-Efficient Handling and Transmission Policies for Test Set B

In this experiment, the tests were carried out in a controlled scenario, where those must-have applications were eliminated, that somehow realize updates in the system altering the behavior of the battery discharge. Likewise, the tests performed on set A and suspended mode screen were executed but now in this new controlled environment and with the same shipping policy configuration sizes. Tables8–10 also contain seven fields specifying the send variable, start time, end time, test duration, inserted readings, abnormal readings identified, and the difference between these two, also showing graphically the discharge of the battery, as well as the difference between the readings inserted and the abnormal readings identified, all this for each type of policy.


## 6.2.3. Discussion of Results for Energy-Efficient Policies

The results presented in Section6.2.1 and Section 6.2.2 represent an important source of information to analyze the evolution of smartphone battery consumption as function of the size of packages, time transmit readings, and type of alert classification and to analyze battery consumption when the CMA-HR-SL application is executed in a controlled or not controlled environment.Experimental results for Package Policy: In Test Set A, when the size of the package was 70, the battery lasted 10 hours, 26 minutes, 33 seconds, and a number of1,098 abnormal readings were identified from a total of the 11,587 readings inserted. When the packet size was 90, the battery lasted 10 hours, 07 minutes, 03 seconds with 1,809 abnormal readings identified from the 13,912 readings inserted. From this result, we can conclude that the more abnormal readings registered, the higher the battery consumption. This is because abnormal readings use more data transmission and, therefore, the battery life is lower, regardless of the size of the package transmission. For Test Set B, when the size of the packages was 90, the battery life was 11 hours, 14 minutes, 04 seconds with 1,187 abnormal readings identified from the 13,485 inserted. This is because apart from being in a controlled environment, the number of abnormal readings was lower than that of Test Set A; consequently, the duration of the battery was longer.Experimental results for Time Policy: In Test Set A, when the time to transmit readings was set to 30 minutes, the battery consumption time was 10 hours, 56 minutes, 36 seconds with1,221 identified abnormal readings from the 4,246 readings inserted. However, when the time to transmit readings was set to 60 minutes, the battery consumption time was 10 hours, 24 minutes, 42 seconds with 682 abnormal readings identified from the 1,328 readings inserted. There are two reasons for this behavior: (1) The test was executed with Test Set A, where the system environment of the mobile device is not controlled which means, it has applications that raise the battery consumption; and (2) The abnormal reading identified in the 60 minutes transmission is above the average of the total of readings inserted, leading to higher battery consumption. On the other hand, for Test Set B, when the time to transmit readings was set to 30 minutes, the battery duration was 11 hours, 24 minutes, 34 seconds with 1,307 abnormal readings identified out of a total of 4,178 inserted readings; this was due to the higher number of abnormal readings with respect to Test Set A. In general, Test Set B produced less total readings because of the controlled environment nature of the test, that is, with less applications running on the mobile device.Alert Policy is an important tool for finding trade-offs between intelligent monitoring, efficiency of abnormality notifications, and smartphone battery duration. In this regard, Figures12(a) and 15(a) show results of battery performance for the patient’s medical states considered. Figure 12(a) shows that lower abnormal readings produced less information for upload to the external storage service, resulting in a monitoring time of 10 continuous hours, registering 20% of battery level at the end of the test. On the other hand, the PwCD and HPwPA states registered battery utilization of 1 to 5%, preventing continuous monitoring. It is important to mention that these tests were performed with Test Set A, where the smartphone environment was not controlled. Figure 15(a) presents the results of Alert Policy with Test Set B. The figure shows that HPwPA medical state produced better performance in terms of energy utilization, registering a battery utilization level of 18% after 10 hours of continuous monitoring due to the low number of abnormal readings registered. Instead, the PwCD and HPnPA states registered battery utilization lower than 10% battery in 10 hours of continuous monitoring.Finally, regarding the tests of Alert Policy, the battery duration is a function of the type of health classification of the patient, the patient’s medical state, and number of alert readings identified. The results demonstrate the robustness of our approach to adapt and register abnormalities in the wandering patients. Nevertheless, a more elaborate evaluation of continuous monitoring with wandering patients with several medical states is presented in the following section.


## 6.3. Overall Monitoring Assessment for Patients with Different Medical States

This section presents monitoring results of our CMA-HR-SL approach while monitoring wandering patients with different medical and physical states. We monitored eleven wandering patients grouped as follows: (1) three healthy wandering patients without physical activity (HPnPA); (2) three healthy wandering patients with physical activity (HPwPA); and (3) five wandering patients with chronic disease (PwCD). For these three classifications, we tested the same number of Alert Policies. The details of the type of alert and the patients are provided in Table11.Table 11
Types of alert for patient.
Type of alert
Definition
HPnPA
Healthy wandering patient without physical activity: the patients do not suffer from any chronic disease, and they do not perform physical activities. Three patients
HPwPA
Healthy wandering patient with physical activity: the patients do not suffer from any chronic disease, and they regularly perform physical activities. Three subjects
PwCD
Wandering patient with chronic disease: this classification includes wandering patients with chronic disease without physical activity (PwCDnPA) and wandering patients with chronic disease with physical activity (PwCDwPA). The chronic diseases are: diabetes, high blood pressure (HBP), Wolff Parkinson White (WPW), and nonspecific chronic ulcerative colitis (NSCUC). Five patientsThe monitoring for each wandering patient was performed in their daily activities in order to identify alert episodes of heart rate (HR) and stress levels (SL). The test was carried out using Alert Policy, which consists of identifying abnormal SL episodes according to the SL rules presented in Table1 and abnormal HR episodes. The HR thresholds are defined by the caregiver based on normal heart beats per minute (bpm). For our tests, the caregiver selected the threshold 60bpm≤HR≤100bpm. In this regard, a HR outside of this threshold is considered abnormal, and the web system would issue alerts for appropriate patient’s assistance.Since alerts are issued according to the physical and medical state of each patient, the battery consumption times vary for each patient. We measured the battery consumption time until the charge of the battery was 0%. Four of the eleven tests lasted around eleven hrs and seven lasted around ten hours. Tables12 and 13 provide the duration time for each patient while monitoring HR and SL in our overall assessment.Table 12
Functional test with approximate duration of 11 hours.
Monitoring
Duration
Patient User A
11:15:36
Patient User B
11:21:30
Patient User D
11:07:06
Patient User G
11:35:45Table 13
Functional test with approximate duration of 10 hours.
Monitoring
Duration
Patient User C
10:48:41
Patient User E
10:42:56
Patient User F
10:30:54
Patient User H
10:57:16
Patient User I
10:50:26
Patient User J
10:12:22
Patient User K
10:28:41It is important to mention that the physiological increase in HR of all readings was due to various external events (daily activities, emotions, stress, effort, etc.) as well as due to REs and RSs activities. The lowest and highest physiological HR registered in our tests was45bpm and 140bpm, respectively. Our tests confirmed that the higher the number of alerts, the lower the battery life; moreover, the CMA-HR-SL platform is able to register all of these alerts and, more importantly, is able to issue alerts to caregivers to take care of the wandering patients accordingly. Tables 14–16 show the results (abnormal readings, activity REs readings, stress level, and HR average) of our overall assessment. It is worth mentioning that for the results of the stress level, all patients registered abnormal levels; this is because during the whole test, the patients registered a number of abnormal episodes (registered as abnormal in Tables 14–16). Also, the physical activity and HR were effectively used to determine appropriate stress levels.Table 14
HPnPA classification.
User
Classification
Age
RE activity
SL
Abnormals
HR average
Duration (hh:mm:ss)
User A1
HPnPA
56
71
Abnormal
71
93
11:15:36
User B2
HPnPA
49
58
Abnormal
871
95
11:21:30
User C3
HPnPA
32
201
Abnormal
787
82
10:48:41Table 15
HPwPA classification.
User
Classification
Age
RE activity
SL
Abnormal
HR average
Duration (hh:mm:ss)
User D4
HPwPA
24
175
Abnormal
729
72
11:07:06
User E5
HPwPA
27
84
Abnormal
2,125
72
10:42:56
User F6
HPwPA
24
233
Abnormal
236
84
10:30:54Table 16
PwCD classification.
User
Classification
Age
HR activity
SL
Abnormal
HR average
Duration (hh:mm:ss)
User G7
PwCDwPA (HA y Pre Diabetes)
69
0
Abnormal
4
86
11:35:45
User H8
PwCDwPA (WPW)
26
29
Abnormal
1,055
95
10:57:16
User I9
PwCDwPA (HA)
50
40
Abnormal
191
82
10:50:26
User J10
PwCDwPA (Diabetes)
42
61
Abnormal
1,834
77
10:12:22
User K11
PwCDwPA (CUCI)
24
29
Abnormal
578
82
10:28:41


## 6.4. Response Time of the CMS-HR-SL Platform

The CMS-HR-SL platform presented in this paper has been designed to alert caregivers when wandering patients need assistance. In this sense, timely reaction to sudden issues like abnormal heart rates, abnormal stress levels, and abnormal location of wandering patients is a pivotal requirement. This section evaluates the response time of the CMS-HR-SL platform when patients are in the need for assistance. Table17 presents information of three patients (see patients ID 70, 54, and 60 in the leftmost column in Table 17) that presented alterations in their heart rates during our tests. The column TS-FRA-HR shows the time stamp when the first abnormal heart rate is present in the wandering patient; this information has been obtained from the mobile application. The column TS-NC shows the time stamp when the caregiver receives the alert in the web system, this information has been obtained from the web system directly. The difference between the time when the alert is produced (TS-FRA-HR) and the time when the alert is received by the caregiver (TS-NC) is presented in the Latency column in Table 17. The column ATR-HR presents the amount of alterations of heart rate in the corresponding patient received after the first abnormal reading. From the above, we determined that the order of time needed to receive an alert when an abnormality is recorded in a wandering patient is in the range of 0–3 seconds (minimum) and 10–12 seconds (maximum).Table 17
Time in response.
ID patient
TS-FRA-HR (hh:mm:ss)
TS-NC (hh:mm:ss)
Latency
ATR-HR
70
21:03:05
21:03:05
0 seg.
23
70
21:09:14
21:09:17
3 seg.
6
54
20:11:31
20:11:43
12 seg.
5
54
20:18:58
20:19:08
10 seg.
2
60
12:15:35
12:15:40
5 seg.
2
60
13:23:03
13:23:03
0 seg.
22


## 7. Concluding Remarks and Future Work

This paper has presented the design and implementation of a platform aimed at providing support in e-health control and provision of location services for wandering patients through real-time medical and mobility information analysis. The paper has focused on heart rate and stress level monitoring and analysis for wandering patients. We have demonstrated that through external, nonintrusive sensors, it is possible to perform smartphone-based continuous monitoring of vital signs and, more importantly, to determine abnormal medical states accurately by means of correlation of vital parameters in runtime and on demand. The experimental results demonstrate that through our platform, it is possible to identify chronic episodes of a wandering patient through alerts as well as provide the location of the patient for appropriate assistance. It is also worth mentioning that through our platform, it is possible to provide assistance to caregivers when wandering patients register abnormal episodes of heart rate and stress levels for reactive or proactive health-care assistance. The platform gives support to caregivers allowing them to avoid physical and continuous evaluations of wandering patients; instead, it allows them the flexibility to browse through patients’ state and analyze the evolution of vital signs remotely from a web-based service for remote clinical checkups of the patient.We have demonstrated that it is possible to manage battery consumption by means of energy-efficient handling and transmission policies for more efficient transmission of medical information from the sensor-based smart device to the web service. The platform system gives the flexibility to adopt the more appropriate policy for taking care of the patients according to their medical follow-up requirements. In this regard, our platform conceals continuous monitoring with energy-efficient applications in favor of more granular and more focused e-health control of wandering patients.We strongly believe that systems like our CMA-HR-SL platform are important for enhancing medical care, as they give caregivers the possibility of offering quality and prompt attention to patients with diverse needs. We performed our platform’s evaluations on eleven wandering patients with different medical conditions. Our experimentation trials lasted approximately 690 hours considering the evaluation of all the monitoring and analysis parameters. We are aware that a more diverse population of wandering patients would enhance the statistical validation of our results. Moreover, the results obtained through the performed evaluation tests have allowed us to determine the effectiveness of the approach, and they have been useful to draw the above conclusions. Therefore, future work will be devoted to analyzing the performance of our platform in more patients with other diseases, as well as extending its functionality to include body sensors for monitoring other types of biological information in accordance with patients’ requirements. Another area of future work is the integration of other sensors to extend the medical care capabilities of our CMA-HR-SL platform. Finally, due to the proposed design, another fundamental aspect is the definition of self-adjustable energy-efficient handling and transmission policies, which can adjust the time and amount of package sizes according to context or type of alerts, with the intention of finding a balance between battery usage and the needs of the mobile application.



---

*Source: 8164376-2018-04-11.xml*