A computational model for adaptive recording of vital signs through context histories.

Wearable devices emerged from the advancement of communication technology and the miniaturization of electronic components. These devices periodically monitor the user's vital signs and generally have a short battery life. This work introduces ODIN, a model for optimized vital signs collection based on adaptive rules. Analyzing vital sign values requires preciseness, so the adaption of these collected data allows a personalized analysis of the user's health condition. The comparison with related works indicates that ODIN is the only model that presents context-aware-adaptive vital signs collection. The implementation of a prototype allowed to perform three evaluations of ODIN. The first evaluation used simulations in different scenarios, with the adaptive approach increasing battery life by 119% through the analysis of input data compared to data collection without adaptivity. The second evaluation applied the prototype to a database of real physiologic data, which allowed reduced data collection when the user has regular vital signs. This reduction optimized battery consumption by 66% compared to collection without adaptivity. Finally, the third evaluation applied ODIN through an Arduino and a heart rate monitor (Polar H7). The average power saved across mobile devices was 21%. Consequently, the adaptive strategy presented in this work allows the optimization of computational resources during the collection and analysis of vital signs. This optimization occurs because of the reduction in energy expenditure and the reduction in the amount of data that needs to be collected and stored.

Introduction

Approximately 29 years ago, Weiser introduced the concept of “ubiquitous computing”, which predicted a world where computer devices would be present in objects, environments, and embedded in the people themselves (Weiser 1991). 10 years later, Satyanarayanan reinforced the concept that these devices would naturally interact with users without being noticed (Satyanarayanan 2001).

Ubiquitous computing presents context awareness as one of the most prominent aspect for dealing with information (Barbosa 2015). Context characterizes any information related to people (e.g., individuals or groups) such as vital signs (e.g., heart rate or blood pressure) and information related to things, in particular, wearable devices and computational resources. Contexts have attributes, such as an identity (i.e., unique identification), status, date, and time. All these information help to determine the chronological order in which the events occurred and this chronological order composes the context histories (Rosa et al. 2015; D’Avila et al. 2020).

The current context may not provide the full amount of data needed to obtain relevant information from the user, so context histories can be used to obtain more information on the entity (Barbosa et al. 2018; Dupont et al. 2019). This type of information helps an application to adapt according to the user. The adaptation depends on information from the context where the user is, in addition to the frequent monitoring of these contexts.

With the world’s population aging (United Nations Department of Economic and Social Affairs 2017), the search for better health services has increased. This is because when people get older, they are more susceptible to need medical care. Therefore, mobile solutions play a strategic role in collecting data to monitor the patient and also help reduce medical service costs. Computational resources can be used to automate repetitive tasks that otherwise need a healthcare professional to perform them, allowing these professionals to spend their time doing more important activities.

The development of health monitoring devices, the miniaturization of electronic devices, and the increasing availability of wireless networks have enabled the development of mobile health solutions. These solutions provide opportunities to improve the quality of health services for patients and healthcare professionals (Dias et al. 2020; Bavaresco et al. 2020). The mobility of wearable devices and their integration with smartphones help to monitor users’ information. However, the energy consumption of these devices is a recurring problem that requires the users to constantly recharge them (Baig et al. 2019).

The interpretation of vital sign values usually requires a professional to evaluate any changes and decide the next action in the treatment of the monitored patient. Without the correct information about the patient’s vital sign values, however, the correct action may be delayed or may not occur at all, especially if the patient is not in a clinical or hospital environment. An adaptive collection through wearable devices could be an alternative to optimize the acquisition of this information.

Adaptation could optimize the collection of the physiological and non-physiological information of the user, generating a history of the patient’s health data when the patient shows a change in their regular health situation. In this case, non-physiological information refers to data that can be collected from users’ profiles, such as age and gender, and data from their routines, such as activity level and geographic location. Adaptation may optimize the battery life of devices that collect health information and generate a more considerable amount of data during times of greatest need.

Adaptive systems are usually interactive systems. The systems need to interact with the context where they are inserted and learns how to allocate resources appropriately (Weibelzahl et al. 2020). Decisions are made taking the context into account, such as network connection type, the health status of a patient, potential time, and cost of executing the application or service. Adaptive systems using mobile devices allow the system to be more aware of the context through ubiquitous computing techniques (Nawrocki et al. 2020).

An ontology is used to describe requirements specification documents and formally represent requirements knowledge. An ontology representation can be an important step during the software design phase in order to represent all the instances and classes that systems may have (Komninos et al. 2016; Sun et al. 2020). This work proposes an ontology to describe the user, with the aim of representing the classes, subclasses, and instances of the user condition.

Systematic mapping helped to explore the related literature (Aranda et al. 2020), and the review highlighted various considerations and opportunities regarding this subject. For example, vital signs collection systems tend to use the Internet of Things (IoT) resources through wearable devices, and most of the proposed works use indoor communication techniques. Another issue is the limitation of the battery autonomy of the devices that collect this data.

The development of ODIN occurred after identifying resources that were not present in the related works. ODIN is a model that can be used in any environment to optimize vital signs collection to ensure applications run for as long as possible. Therefore, this article’s main scientific contribution is an adaptive collection of vital signs contexts that allow for the optimized composition of context histories.

The remainder of this article is organized as follows. The Sect. 2 provides a review of the literature and related works. The Sects. 3 and 4 describe the proposed model and its evaluation, respectively. The Sect. 5 presents a discussion about the work, and the Sect. 6 presents the final considerations.

Related works

The selected papers are related to the collection of vital signs, ubiquitous computing, and adaptive collection and were obtained through a systematic mapping study (Aranda et al. 2020). The mapping process involved three stages: identification of research questions; elaboration of the search process; and definition of the criteria for filtering the results. Using snowball sampling, more articles were included in the full list of reviewed works (Cooper 2016), and the related works were updated to include papers published in the last year, such as the work of Casalino et al. (2020).

The literature review identified 5,870 articles published in the last 12 years up until July 2020, and the final selection resulted in 10 articles. The final selection criteria meant that only the articles that included a collection, communication, and analysis of health data were selected. The research questions used in the systematic mapping study were seven, and they encompass three general questions, two specific questions, and two statistical questions.

The questions are as follows: (I) How are smart environments using physiological data for healthcare? (II) What are the most common techniques and/or technologies for communication of collected physiological data in smart environments? (III) What are the most common techniques and/or technologies for the analysis of physiological data in smart environments? (IV) What are the most common types of vital signs collected? (V) Was the user profile considered in the analysis of physiological data?(VI) Where were the studies published? (VII) How many publications occurred per year?

The search process prioritized health and computer science research databases. The systematic mapping study used seven databases (ACM Digital Library, IEEE Xplore, Science Direct, Willey Online Library, PubMed, JMIR, and Springer Link). These databases had previously been used in recent systematic review studies (Goncales et al. 2014; Vianna and Barbosa 2017; Dias et al. 2018; Dalmina et al. 2019).

The studies were filtered to select the papers related to the subject and the research questions. Definition of exclusion and inclusion criteria allowed filtering the papers found in the research process. The inclusion criteria are: (IC 1)the study must have been published in a conference, workshop, or journal; (IC 2) the study should be related to the proposed theme – smart environments, as well as analysis and the collection of physiological data; (IC 3) the study should be a complete paper;

The exclusion criteria are: (EC 1) studies published prior to 2008. (EC 2) studies not written in English. (EC 3)studies published as dissertations or theses. (EC 4) studies that did not include data collection or analysis for smart environments. (EC 5) studies that did not have a relationship with the research questions.

First, the papers found in the research process are removed through exclusion criteria EC 1, EC 2, and EC 3. The next filter remove papers according to the title and keywords of the reviewed papers; finally, selected works were filtered according to the content of the abstract of the mapped papers. The next filter represents an approach called the three-pass method (Keshav 2016). Finally, the last filter consists of reading the full text, observing exclusion criteria EC 4 and EC 5.

The mapping verified the most common trends and technologies and most analyzed physiological data technique. Similar reviews have already focused on data collection rather than techniques for analyzing this information. This denotes an opportunity for further studies in the area of vital sign analysis.

Furberg et al. (2017) introduced a model to monitor policemen on duty. The model identified possible stressful situations, allowing the commander of the mission to track the physiological data of their subordinates. Habib et al. (2017) developed work based on vital signs collection and prioritization of sensor data packets through an optimized strategy of data transmission. The evaluation consisted of a collection of employee signal measurements within a company. The constant collection of vital signs helped monitor employee stress levels to avoid accidents in the workplace.

Said et al. (2018) proposed an approach based on deep learning for the collection of vital signs and the compression of these data during transmission and decompression when the data reached the system server. This compression was made possible through an adaptive methodology and indicated a potential for reducing energy consumption and computational resources.

The framework proposed by Fernandes and Lucena (2017) allowed temperature and heart rate to be monitored via Bluetooth, and data analysis by a multi-agent architecture sent alerts in case of a detected risk. The alerts were based on a previously parameterized limit. Swaroop et al. (2019) presented the design of a real-time health monitoring system that stores patients’ health parameters. The data can be made available to a medical practitioner as an alert and for monitoring a specific health condition. Yin et al. (2019) proposed a self-adjustable domain adaptation (SADA) strategy to prevent unlabeled health data. The paper enlarged the database of ECG and radar data with actual records acquired from several testers. Utilizing unlabeled data, SADA combined self-organizing maps with transfer learning to predict labels. Finally, SADA integrated the one-class classification with domain adaptation algorithms.

Pazienza et al. (2020) investigated the most suitable machine learning (ML) technique for the prediction of clinical risk classes of a continuously monitored patient in a particular condition where a limited number of vital parameters are available. Casalino et al. (2020) proposed a mobile health solution to self-measure the blood oxygen saturation through a smartphone camera. This work allow the users to monitor their blood oxygen saturation at home without the use of medical devices. Due to COVID-19 where people must reduce social contact, this work contributes to the social distancing. Choi and Shin (2018) developed a personalized service for healthcare using IoT devices, and personal health records (PHR) to store user health data. This service can determine risks in real-time. Finally, Hassan et al. (2019) proposed a hybrid real-time monitoring framework for users with chronic diseases. They employed a hybrid algorithm to analyze heartbeat, blood pressure, and respiratory flow and detect risks in real-time.

Among the papers found through systematic mapping, ten works that collected and analyzed health data were compared with the ODIN model (Furberg et al. 2017; Habib et al. 2017; Fernandes and Lucena 2017; Said et al. 2018; Choi and Shin 2018; Hassan et al. 2019; Swaroop et al. 2019; Yin et al. 2019; Pazienza et al. 2020; Casalino et al. 2020). The following aspects allowed the analysis of the related works: consider and collect non-physiological data from the user context; optimize the vital sign collection to reduce the effort to store the data; and save computational resources of the involved systems in the collection and analysis of vital signs.

Three papers partially fulfill the first aspect (Said et al. 2018; Choi and Shin 2018; Casalino et al. 2020). In these works, only contextual data were collected and these data were not correlated with physiological data. Therefore, ODIN’s scientific contribution consists of the adaptive collection of vital sign contexts that allow for the optimized composition of context histories.

Vital sign analysis may support health-related decision making. In this sense, the vital signs collected by applications can be formatted as contexts (D’Avila et al. 2020), stored in chronological databases (Vianna and Barbosa 2019, 2020), and used for context predictions (da Rosa et al. 2016; Filippetto et al. 2021). Based on these databases, researchers can design tests of analytical techniques to verify their real effectiveness in assisting health systems. The next section describes the main concepts related to the ODIN model, which approach the specification of the vital signs collection and organization of the rules proposed to fill the gaps.

ODIN model

The ODIN model aims to perform adaptive collections of vital signs to optimize the generation of context histories. This optimization occurs since the model obtains more information from the patient in situations of risk and less information when the patient has regular vital signs. For this, the central part of the model is the multi-agent system that comprises adaptive rules. ODIN can acquire heart rate, temperature and body pressure (manually inserted) data. These vital signs were chosen based on data collected on a triage process when a patient goes to a hospital (Kuriyama et al. 2017). Odin also collects data from the smartphone accelerometer of the user. The following sections detail model’s architecture, the multi-agent approach, besides the organization and elaboration of rules.

Model architecture

Figure 1 shows the architecture of the ODIN based on SAP’s Technical Architecture Modeling (TAM) standard (SAP 2007). ODIN’s components consist of four modules: Mobile Device Agents, Backend, Frontend and Database. The Mobile Device Agents module is related to interaction with vital signs collection devices, while Backend is the controller of rules, notifications, and vital signs. This controller allows access to context histories stored in a Database module. Frontend has the Views of rules, vital signs, and warnings that, are responsible for displaying the information to users. Finally, Database module stores the users’ context histories and personal information, as well as the rules, which are represented through a flowchart and an ontology.

Fig. 1

ODIN’s architecture with four modules and their relationship

Multi-agents system

By definition, agents perform computational tasks autonomously, making decisions based on rules or parameters (Long et al. 2019). Figure 2 illustrates the agents overview diagram, in which agents are described with their perceptions, actions, and messages. ODIN’s agents were modeled using the Prometheus methodology (Larioui 2020).

Fig. 2

Overview diagram of ODIN’s multi-agent distribution

The four agents are: Physiological Collection, Context Collection, Notifier, and Adaptivity. Physiological Collection agent communicates with vital sign sensors, making the collected data available to other agents. Context Collection agent is responsible for collecting information from the current context where the user is inserted, which can be related to the user’s activity or location. This agent performs the collection through sensors such as accelerometers, gyroscopes, and GPS, which can be on the smartphone or on the wearable device. Notifier agent displays notifications to the user according to the adaptations being made by the Adaptivity agent. The parameter setting of the vital signs collection is adapted for each user and can be defined by a health professional.

Adaptivity agent makes two types of adaptations. The first occurs by changing the collection time parameter and is called Wait-Time Adaption (WTA). If the vital signs values go outside of the pre-established regular thresholds, the agent changes the periodicity of the collection of the sensor to a higher frequency. If these values continue to move away from the regular values, the waiting time between collections is further reduced. In contrast, the closer the values are to regular levels, the longer the waiting time is between collections. The collection reaches the maximum waiting time when the values are within the regular threshold. All these changes are made automatically by the Adaptivity agent.

The second type of adaptation consists of activating one or more secondary sensors that may be in a state of pause. This adaptation is called Context Adaptation (CA). If the user has a wearable device with more than one type of vital signs sensor, one or more of these sensors can be defined as Main Sensors (MS) and the remainder as Secondary Sensors (SS). This allows an SS to be triggered only when an MS is outside of the threshold of regular vital signs. The C A will automatically start or pause an S S according to the user’s physiological context. If the connection with the server is not available, the data is stored in a local cache. Once the connection is reestablished, the agent sends the previously cached data to the server.

Adaptivity rules

Figure 3 illustrates the rules represented using a flowchart based on event, condition, and action. The event is based on the collection of vital signs, and the condition is then checked through inference in rules. This inference occurs in three stages.

Fig. 3

Adaptive rules based on event, condition, and action

The first stage verifies the user’s condition, i.e., at rest or in movement, whereas the second verifies the user’s profile by identifying the person’s age (e.g., adult, child, or elder) and gender (Spångfors et al. 2019). Based on this information, the third stage selects the correct pattern of the user’s physiological conditions.

Once the user’s physiological condition has been determined, the condition can be classified as regular or alert, with the latter referring to changes in vital signs outside the normal threshold. Figure 4 shows the physiological conditions of a user represented through an ontology with classes, sub-classes, and instances. The ontology demonstrates how each user’s profile can use a different set of rules to determine their risk status. Each profile analyzed in the rule stream detects the appropriate risk for its current context.

Fig. 4

Ontology of physiologic condition

The User class represents an individual and has two subclasses: Male and Female. These subclasses are divided into three more subclasses according to the user’s profile. Male is divided into MaleChild, MaleAdult, and MaleElder, while Female is divided into FemaleChild, FemaleAdult, and FemaleElder subclasses. For the MaleAdult subclasses, for instance, MABodyTemperature, the initial “MA” contextualizes the Male Adult inheritance, whereas “ME” refers to Male Elder and “MC” refers to Male Child. The same is for the Female subclasses, as FA means Female Adult, FE is Female Elder, and FC refers to Female Child. This organization of hierarchical classes is because each user has different physiological values according to the profile, characterized by gender and age (Voss et al. 2015). For example, the tachycardia of an elder person has different threshold than a child or an adult.

The aforementioned classes have subclasses that contemplate a user’s physiological conditions. The status types for each condition are added as instances. Hence, according to the user’s profile, each BodyTemperature subclass represents a physiological condition and this subclass has the following instances: Fever (high body temperature), Hypothermia (low body temperature), and RegularBodyTemperature. The BloodPressure subclass presents the instances of Hypertension (high blood pressure), Hypotension (low blood pressure), and RegularBloodPressure. Finally, the HeartRate subclass has Tachycardia (high heart rate), Bradycardia (low heart rate), and RegularHeartRate as instances. The standardization of the values inside these instances representing values of vital signs follows the definitions proposed by the NHS (National Early Warning Score Development and Implementation Group in the NHS 2012).

The mapping of physiological conditions in the form of rules allows the user’s health condition to be inferred. Equation 1 describes the level of the user’s condition, which calculates the difference in the value of the measured vital signs to the normal threshold of that type of vital sign. These thresholds may vary according to the user’s profile data, e.g. their age and gender (Voss et al. 2015).The obtained value is a real number from 0 to 1, where 0 corresponds to a value exactly equal to the threshold, and 1 is a critical value. For the calculation and inference of the rules, more information may be relevant, such as the user’s state of activity or their degree of sedentarism. Studies have warned the importance of exercise to good mental health (Morres et al. 2018; Johnson et al. 2019), which means that the information about the user’s lifestyle becomes a piece of relevant contextual information.

This information is quite subjective and requires preciseness. Hence, one approach would be to express a numerical value for these conditions correlating with vital sign values. Therefore, instead of using a Boolean set of rules corresponding to only two outputs, true or false, whether the vital signal value is a real value between 0 or 1, this would result in a number with a more accurate amount of risk and alertness.

In order to use this logic to determine a user’s activity level, the Adaptivity agent calculates the difference in milliseconds from one incidence of movement to another. This incidence can be obtained through an accelerometer present in wearable devices or smartphones. For example, a user on a moderate walk will have a high millisecond value, while a user who is running will have a low number due to the greater intensity of the activity.

An example of an activity incidence could be the time difference in milliseconds of two steps taken by a user. The estimate of how many incidences are made per minute corresponds to the ratio of 60,000 (1 minute in milliseconds) by the time difference between the steps. The number of steps per minute defines the intensity of the activity (Gil-Rey et al. 2019). For this, a threshold was used where 0 refers to a stopped user and 1 refers to users at maximum intensity. Equation 2 represents this calculation.These two pieces of information enable the detection of false positives. A user with a heart rate above 100 can be considered tachycardic. If the individual is in movement, the intensity of the activity is considered, through a weighted average calculation between the values. This prevents the inference of the rule generating an alert or making an adjustment when vital sign values are normal. The verification of these rules is replicated for each vital sign measured by the user at a given time.

The risk of stress can be retrieved by the average of adaptiveActivity and adaptiveVitalSign values. Planned adaptations are based on the risk of stress value.

In the case of this work, each output is a different adaptation. The higher the stress level, the more secondary sensors are activated, enabling more information collection. The values from the table vary from 0 to 1, or 0% to 100%. This value is obtained with the average value of the results of equations 1 and 2. The more close to the 1 (or 100%) farther from threshold the vital sign is. Table 1 presents the proposed adaptations.

Table 1

Collected data accordingly with the decision table

Adaptive value	Collected data
0–20%	Heart rate variability (HRV)
21–40%	Heart rate (HR) and HRV
41–60%	HR, HRV and indoor/outdoor location
61–80%	HR, HRV and indoor/outdoor location and arterial pressure (manually inserted)
80–100%	HR, HRV and indoor/outdoor location, arterial pressure (manually inserted) and alert sending

Specialized parameters could provide better solutions to specific problems according to the user’s needs. These parameters can be inserted as rules, allowing a gain in the analysis and adaptation of the collection of vital signs data. In the following section, relevant aspects of ODIN’s evaluation are presented, in particular, the implementation of the prototypes and the obtained results.

Evaluations and results

This work considers three evaluations. The first comprises three scenarios approaching simulated user cases with vital signs data. The purpose of this assessment was to monitor a user in their daily life, besides collecting the data of a user who practices sports, and demonstrate how adaptation in data collection can improve the security of operators of an industry. The second evaluation used vital signs data from a real physiological database that was collected from a user in real-life. The third evaluation presents two more experiments, one using a prototype of vital signs collection and another using a cardiac monitoring chest belt available on the market. In both cases, a control application without the request adaptation rules was used to compare the performance of the adaptivity approach proposed by the ODIN model. The following sections detail the aforementioned types of evaluation and show how this work fills the gaps in the literature.

Simulations

Scenarios can be used for the evaluation of ubiquitous applications and context-aware systems (Wagner et al. 2014; Barbosa et al. 2018; Carpentieri et al. 2020). Using this strategy, ODIN’s evaluation involved an app called the ODIN app, which collected and adapted the data.

For the development of adaptive and control apps, the chosen programming languages were JAVA (Android) and C# (Xamarin). This app requires a server to access and store the history of vital sign contexts through an SQL database. The system uses a relational database to work with the ODIN app properly. The user’s condition is verified on the monitoring screen, and if the main sensor is outside the determined standards, the adaptivity warning is turned on, alerting the user and starting the collection of data by the secondary sensors. Figures 5 and 6 illustrate the monitoring screen, which displays the app with and without the adaptations triggered. Figure 5 displays a regular collection according to the user stress level (17.7%), while Fig. 6 shows a higher stress level (44.2%) that triggers the other adaptations (WTA and CA).

Fig. 5

App screen with the adaptivity off

Fig. 6

App screen with the adapativity on

The ODIN app allows the alteration of the collection parameters (waiting time, and minimum and maximum values of vital signs) by the user or by a health specialist. Each collection of vital signs consumed 0.1% of the battery. The waiting time was 30 seconds for a normal vital sign value and one second for a condition outside the normal vital sign threshold (alertness). These were the parameters in the three simulations; however, as stated above, these values can be changed by the user or a health professional.

The first scenario simulates a user who just wants to monitor his vital signs data. For that, the user utilized the ODIN app. Scenarios 1 and 2 start the simulation with values of 80 beats per minute for heart rate (HR) and 750ms for heart rate variability (HRV). Vital sign values, in addition to activity detection, were generated once a second. This generation occurred through the current value plus a random number that could be -10, 0, or 10 for HRV. Therefore, the change in vital signs occurred linearly, avoiding sudden changes in the collection.

Scenario 1

Scenario 1 comprised a user simulation that sought to map the user’s stress levels only and aimed to monitor a user’s daily life without applying a specific context. The results showed that the adaptation permitted a long battery life and the collection of less data. The description of the scenario and the results are as follows.

“Steve, 66, would like to monitor his stress level during his daily life. Steve uses a wearable device with a HR monitor that works with the ODIN app on his smartphone. During the day, Steve faces stressful situations that are mapped by the ODIN app. When analyzing these situations at the end of the day, Steve checks the context within which the stressful situations occurred. This allows him to adjust these contexts to better manage his stress day by day.”

The user can be notified when a variations of his stress level changes, with the application of this scenario. Through the notifications, the physician and the user can follow the health situation in real-time, enabling better decision-making when choosing a treatment.

The simulation collected 1,000 requests in this scenario. As a result, for the control app without adaptivity, the battery lasted 2 hours, 14 minutes, and 39 seconds. With adaptivity, the battery lasted 4 hours, 48 minutes, and 38 seconds. This represents an increase of 114%.

Scenario 2

The second scenario involved a user who took part in physical activities and wanted to monitor her performance during these activities.

“Linda, 27, usually practices running almost every day. Unfortunately, Linda has already suffered injuries due to the intense practice of her sport. The user has a wearable cardiac monitoring device, which also monitors her HRV. Stressful situations can cause injury, and Linda uses her wearable device in conjunction with the ODIN app. When Linda starts running, her stress levels gradually increase. When her stress levels get too high, Linda stops running to protect herself and prevent an injury. In addition, the adaptation of the collection of vital signs increases the battery life of the wearable device, reducing the need to charge it.”

In this scenario, the user can verify when she is in a possibly stressful situation due to physical exercise. In addition to being alerted about a possible risky situation, the user will also be able to monitor their progress over time once the collected data is stored.

The second scenario also involved 1,000 requests. As a result, due to the physical activity of the user, the battery life was shorter than in scenario 1. Without adaptivity, the battery lasted 56 minutes and 38 seconds. With adaptivity, the battery lasted 2 hours, 29 minutes, and 56 seconds. This represents an increase of 164%.

Scenario 3

Scenario 3 involved monitoring the vital signs that can indicate changes in employee stress levels in an Industry 4.0 environment. Conceptually, this environment consists of several entities (e.g., environment, machinery, and people) generating data over time and feeding the context histories (Sharpe et al. 2019). The data obtained from users within this industrial environment considers the physiological collection to obtain the users’ health information, such as stress. This type of monitoring can be called Smart Connected Workers (Oh and Park 2016).

Stress monitoring can be an important factor in understanding and mitigating problems within an industry. Studies have already been carried out showing the influence of stress on workers’ attention to daily tasks (Jiang et al. 2020; Cahlíková et al. 2020). A lack of attention can make workers vulnerable to accidents at work (Leung et al. 2016), and such accidents can lead to financial losses for the company and physical issues for the workers and can negatively affect company efficiency (Soegoto and Narimawati 2017).

The industrial environment used in scenario 3 consisted of four different areas. The vital signs of four employees were simulated so the app could measure their stress levels while they performed certain tasks. In addition to the collection of vital sign values, each user was given a determined route of movement within the factory.

This scenario was based on the real functioning of a company. As this company preferred to remain anonymous, it is referred to as Ind. LLC. This company had a plant that was around 500 meters wide and 100 meters long that was in use 24 hours a day, 7 days a week.

Due to a high number of accidents at work, a task force was deployed at Ind. LLC. One of the main reasons for these accidents was a lack of communication between the more than 500 company employees. Accidents often happened in one shift and were not reported to the next shift in the same area. In addition, the company also detected that there were many “near misses” where an operator was close to getting hurt. This type of situation was called a work incident, while a fall or a situation that caused some kind of damage to the operator was called an accident. To improve communication between employees and reduce the risk to the operators, both accidents and incidents were reported on paper forms that were deposited into a box. The work safety team read the forms in the box and took action.

When a risky situation occurred in a specific location of the manufacturing plant, a rule was created and replicated for all other operators where the closer the worker was to the risk area, the more context data was collected. The company’s work safety team determined when the situation had been mitigated and the rule could be excluded from the system, thus avoiding false positives. Hence, this scenario was based on a real industrial environment to get information from the operator and the environment. Figure 7 shows that the simulation considered where the users were located (Barbosa et al. 2016, 2018). The locations of the users were based on the sector and function of the operator.

Fig. 7

Ambient screen monitoring

Despite moving between different areas, employees spent most of their time in their own sectors. Environment 1 consisted of a manufacturing area with exposure to high temperatures and constant loud noise from industrial machinery. Environment 2 had a high temperature and loud noises that were sporadic rather than constant. Environment 3 consisted of a production control room that was air-conditioned but still vulnerable to noise due to the proximity of environments 1 and 2. In contrast, environment 4 was an air-conditioned and noise-free administrative environment. Scenario 3 is described as follows:

“Alan, Martina, Josh, and Jessica work at Ind. LLC. The plant has several employees and has suffered from its employees leaving due to mental health problems or work accidents. This factory is divided into several environments, some with greater exposure to stressful situations. To mitigate these problems, the ODIN app was used in conjunction with a wearable device in an indoor location. There was a moment when Alan was in a stressful situation, and the app alerted both Alan and his supervisor Josh. Josh and Jessica, even though they do not work all the time in factory environments, also mapped their stress levels during the day. As they move between all environments, it is feasible for them to leave the environments with a higher incidence of stress to normalize their physiological data. The users’ location information includes the room temperature and noise level. Therefore, in a situation where a user’s vital signs are outside the normal threshold, ODIN begins to collect this data. When the user returns to normal vital sign thresholds, the app adapts again to only acquire physiological data. In the case of an accident at work, one of the employees can indicate the location of the accident so a rule can be created where more data is collected when the users approach a risk area. This allows other interested parties to understand the factors that caused the accident and even prevent new operators from suffering damage due to a problem that has already occurred. When Alan is alerted of a risk in the environment, he moves to environment 3, allowing the work safety team to investigate the risk and reopen the area.”

In the simulation, the location was generated automatically for each user, and it was found that the changes in vital signs were greater in more stressful environments and lower in environments without high temperatures or machinery noise. In environments 1 and 2, HRV changes were -20, 0, or 20, while HR changes were -2, 0, or 2. In environments 3 and 4, the variations were the same as those found in scenarios 1 and 2. When stress was detected, users would be informed of the situation via their smartphones, leaving it up to them to decide whether to rest for a few minutes or leave the environment.

The collected context data refers to machinery data and consisted of equipment in operation (true or false), the pressure of the internal engines of the machinery (in bars), and equipment temperature (in ). In addition, environmental information like temperature (in ) and noise level (in decibels) was monitored. This information was collected by Ind. LLC in their manufacturing unit, which is why that context data was selected for the simulation. This information is important for preventing accidents. If the machinery has very high pressure, a hose could blow and burn a nearby user, while very low pressure could indicate a leak, which could cause a user to slip and fall.

Table 2 represents the movement of users and the collection of data from their environments. Their stress levels and the risk level of the machinery in their environment were also collected. The risk levels were obtained by a calculation based on the normal internal pressure of the equipment, with 1.5 bar considered an ideal value. Values above and below this threshold could have posed a risk to users. There was no machinery in environments 3 and 4.

Table 2

Movement list and data collected for scenario 3

User	Stresslevel (%)	Environment	Machineryrisk (%)	Ambienttemperature (^∘C)	Noiselevel (dB)	Timestamp
Alan	19	1	5	37	80	23/03/2020 14:43:57
Alan	26	1	50	39	80	23/03/2020 14:44:27
Alan	17	3	0	23	n/a	23/03/2020 14:44:28
Martina	15	2	2	33	73	23/03/2020 14:44:59
Martina	17	2	8	32	74	23/03/2020 14:45:29
Martina	14	4	0	23	n/a	23/03/2020 14:45:59
Josh	16	3	0	23	n/a	23/03/2020 14:46:29
Josh	15	3	0	23	n/a	23/03/2020 14:46:59
Jessica	13	4	0	22	n/a	23/03/2020 14:47:29
Jessica	13	4	0	22	n/a	23/03/2020 14:47:59

The third scenario also involved 1,000 requests before the battery died. As a result, without adaptivity, the battery duration was 1 hour, 13 minutes, and 19 seconds. With adaptivity, the battery duration was 2 hours, 12 minutes, and 3 seconds. This represent an increase of 96%. Figure 8 shows a weekly estimate of how much time would be spent charging a wearable device with and without adaptivity.

Fig. 8

Scenarios comparison

Evaluation with patient data from a dataset

The vital signs dataset enabled the analysis and adaptability through real physiological data (Liu et al. 2011). The regular threshold of vital signs takes into account the reference standard proposed by the NHS (National Early Warning Score Development and Implementation Group in the NHS 2012).

The time between collections may vary. While monitoring in an Intensive Care Unit (ICU) can involve data collection being performed every few milliseconds (Sen-Gupta et al. 2019), the manual collection of vital signs by health professionals can only be done only a few times a day (Macapagal et al. 2019).

In the dataset used, the user’s physiological context collection lasted three hours. The time between collections was set to 10 seconds for stress below 20% and one second for stress above 20%. The MS was the HRV, while the HR and blood pressure sensors were SS.

The data monitored in this dataset consisted of HR, HRV, and blood pressure. Real data provides more realistic changes in vital signs and allows for a better assessment of data adaptivity. As a result, with adaptation 3,590 requests were made between the data collection device (a wearable device) and the smartphone, while 10,761 requests were made without adaptation, representing a reduction of 66%.

Seven changes in the user’s state were detected within the three-hour collection period. These changes influenced the user’s stress levels, triggering the adaptations provided for the set of rules. The reduction in data collection requests was proportional to the time that the user was in a situation that did not indicate risk.

Evaluation using a prototype

The third type of evaluation involved two experiments: a prototype using an Arduino, which aimed to verify the feasibility of the proposed model and its operation within a real environment, and an experiment with the HR chest belt Polar H7. The following sections describe the results.

Employment of arduino

The hardware prototype evaluation used an Arduino Uno, a Bluetooth ESP32 shield, and a 4MD69 HR sensor to collect vital signs. Communication libraries with Bluetooth Low Energy (BLE), an Arduino Uno, an Arduino Node MCU ESP8266, and an Arduino ESP32 that already had the BLE feature were used in the development of the prototype. An AA battery holder with four rechargeable batteries was used to power the device.

Figure 9 depicts the connections made between the sensors and Arduino. This evaluation used the adaptivity app twice and the control app twice. Table 3 shows the results obtained by comparing the two data collection methods. As a result derived from the comparison of these two collections, there was an increase of about 20% in the battery life of the device. On the other hand, the number of requests was 109% lower compared to the experiment without adaptation.

Fig. 9

Connections of the hardware prototype

Table 3

Collection with and without adaptivity using the Arduino

	Sensors requests	Prototype battery autonomy (HH:MM)
Test 1—With adaptivity	31,245	27:12
Test 2—With adaptivity	30,747	26:48
Test 1—Control	64,398	22:06
Test 2—Control	65,491	22:54

Employment of Polar H7

Polar H7 is a cardiac chest belt that must have contact with the skin. For the evaluation using this wearable device, only the battery life of the smartphone was measured as Polar H7 does not provide access to its total battery.

Two tests were carried out with adaptation and two were carried out without adaptation. The sensor request value represents the number of times the Polar H7 sent data to the smartphone. A high number of sensor requests means less battery life. As a result derived from the comparison of the adaptivity with the control tests, the battery life increased by 22%, while the number of requests was 56% lower in comparison to the control app. Table 4 shows these results obtained by comparing the two methods of data collection.

Table 4

Data collection with and without adaptivity using a Polar H7 HR belt

	Sensors requests	Battery autonomy (HH:MM)
Test 1—With adaptivity	16,531	15:13
Test 2—With adaptivity	18,176	14:11
Test 1—Control	26,580	12:05
Test 2—Control	27,589	11:51

The experiment demonstrated data collection in real-time and how much battery life can be saved in a practical situation. When analyzing the data, it was observed that in a real situation, the energy expenditure may be greater than what is found during a simulation.

Discussion

The main advantage of this work is the focus on the user. When looking for a preventive solution, wearable sensors could be useful for indicating a health problem before it occurs. On the other hand, when the problem already exists, a better solution is to use consolidated medical equipment. Other advantage in this work is the possibility of the user change the parameters and rules of the collection, in the smartphone through the ODIN app, allowing it to be personalizable.

The model is dependent on the sensors of the devices. If the user is not wearing their smartphone or the wearable device, the proposed adaptations will not occur. In addition, many wearable devices have limitations regarding their manipulation, and the parameters of their sensors cannot be changed. In these cases, only the sensors of smartphones can be adapted and battery and data generation savings are reduced. However, data collection from the user’s current context is still feasible, which allows a better understanding of their condition when correlating physiological data.

In a real situation, normal smartphone consumption can interfere with battery saving. The constant use of the collection device can also mean that the batteries do not always perform the same. It was observed that the battery life in the simulations had an average gain of 119% compared to the same solution without adaptation. When real data was used, the consumption gain was 66%, and when a prototype was used, the average gain was 21%. This difference between battery life gains occurred because of the different user contexts. In the two first scenarios, the simulation only considered the energy consumption of vital sign collection sensors. In the third scenario, the simulation considered the battery expenditure required to determine the user’s location. In this case, as they are everyday situations, the maximum and minimum time between collections may be greater.

In the evaluation that used patient’s ICU data, the chance of risk was theoretically higher. Therefore, the maximum and minimum values of the collection times should be lower. This would cause more instances of data collection, consuming more of the battery power of the devices.

Additionally, during real situations there are factors that influence the battery consumption of devices that did not appear in the first two evaluations. For example, the amount of smartphone screen usage, incoming calls/notifications, and communication problems, all of which increase the energy consumption of the smartphone.

The times between collections used in this work are for evaluation purpose only, and the user can change them in the settings of the ODIN app. When changing these values, it was observed that the longer the time between collections, the greater the potential for battery savings. However, long periods between collections could allow some changes in vital signs to go unnoticed. Therefore, it is up to the user to define the amount of time between collections that it best suited to their goals.

There may be cases where the vital signs of a user at rest remain outside the values considered regular. Users who live in warmer environments may experience a change in skin temperature, registering a higher value, without affecting the health condition of the user. Just as users who practice sports at rest may have a reduced heart rate. In these cases, there may be a false positive, where the Odin app may be locked in a state of danger due to the context of the user. Although this only occurs in specific situations, and at this point the objective of ODIN is to be feasible for the majority of the users, specific cases will be treated at future works.

Conclusion

This work presented a model for collecting vital signs called ODIN that uses adaptive strategies based on adaptive rules. The proposed model potentially fills the gaps identified in the related works. ODIN performs real-time analysis of physiological data to monitor the health conditions of users based on the parameters for collecting vital signs. The context histories are analyzed, allowing the collection of data to adapt to the current situation. The adaptation of vital signs collection involves making more collections when there are notable changes in vital signs and fewer collections when the user is in a situation without risk.

According to the user’s physiological context, vital sign sensors and context sensors can be made active or returned to a paused state automatically. Based on the literature review presented in the related works section, the contribution of ODIN’s scientific approach is the adaptation of the collection of physiological sensors for optimal generation of vital sign context histories. For the evaluation of the model, the issue of mapping stress contexts was addressed. These contexts consist of the user’s vital signs and the context information occurring at that moment as a level of physical activity or geolocation.

The reduction in requests by wearable devices and mobile devices can positively impact the battery life of these devices. However, these savings cannot always be precisely measured. More in-depth studies are needed concerning the best usage of energy by these devices through adaptive sending of data packages or similar solutions.

Future works should look at the model’s scalability. The proposed solution should not affect the application’s performance with multiple users. The adaptive collection proposal could also be useful in conjunction with IoT technologies or Industry 4.0 as these technologies are dynamic and can benefit from an adaptive approach.

In some specific cases, the system can be locked in a “danger” state. This occurs because of the user context (e.g., warmer places may increase the skin temperature). The use of a self-adapting agent will mitigate this problem as future work. This agent will standardize the threshold of vital signs for the user after a certain period (weeks, months). In case the vital sign values remain in this pattern, the system will change its rules to this new threshold, preventing the system from being stuck in a false positive.