movecare multiple-actors virtual empathic cargiver for the …€¦ · stimulation, monitoring and...
TRANSCRIPT
MOVECARE
Multiple-actOrs Virtual Empathic CARgiver for the Elder
Project N. 732158
Research & Innovation Action
Call: H2020-ICT-2016-single-stage
Deliverable reference number
and title:
D.6.2: Virtual Caregiver
Due date of deliverable: December 2018
Actual submission date: February 2018
Start date of project: 1 January 2017
End date of the project: 31 December 2019
Organisation name of lead
contractor for this deliverable
ORU
Other organizations involved All
Project co-funded by the European Commission within the H2020 Programme (2016-2020)
Dissemination Level
PU Public X
PP Restricted to other programme participants (including the Commission Services)
RE Restricted to a group specified by the consortium (including the Commission Services)
CO Confidential, only for members of the consortium (including the Commission Services)
2
History chart
ISSUE DATE CAUSE OF CHANGE IMPLEMENTED BY
1.0 20/01/2019 Creation of the Document ORU
1.1 14/02/2019 First draft delivered ORU, EURECAT
2.0 28/02/2019 Integration of the partners’ comments
First release candidate
ORU, EURECAT
2.1 04/03/2019 Integration of comments ORU
This project is supported by funding from the Information Society Technologies Program under the H2020 Research Framework
Program of the European Union.
Disclaimer: The information in this document is subject to change without notice. Company or productnames mentioned in this document may be trademarks or registered trademarks of their respectivecompanies.
All rights reserved.The document is proprietary of the MOVECARE consortium members. No copying or distributing, inany form or by any means, is allowed without the prior written agreement of the owner of the propertyrights.
This document reflects only the authors’ view. The European Community is not liable for any use that
may be made of the information contained herein.
3
CONTENT
1. INTRODUCTION..............................................................................................................................................6
2. OVERVIEW OF THE VC’S FUNCTIONALITIES ......................................................................................7
2.1. OVERALL ARCHITECTURE ............................................................................................................................7
2.1.1. Channel movecare/vc/all..........................................................................................8
2.1.2. Channel movecare/vc/orchestrator ..........................................................................9
2.2. DESCRIPTION OF THE UTILITY COMPONENTS ................................................................................................9
2.2.1. Orchestrator..............................................................................................................9
2.2.2. User’s location .......................................................................................................10
2.2.3. Reminders ..............................................................................................................12
2.2.4. Report Generation..................................................................................................13
2.3. DESCRIPTION OF THE SCENARIOS COMPONENTS.........................................................................................14
2.3.1. Body Weight Monitoring.......................................................................................14
2.3.2. Call for help ...........................................................................................................17
2.3.3. Neuropsychological tests .......................................................................................18
2.3.4. Search for lost objects............................................................................................20
2.3.5. Spot questions ........................................................................................................23
2.4. DESCRIPTION OF THE VC WEBSERVICE ......................................................................................................25
2.4.1. Ranking of the activities ........................................................................................25
3. SHORT-TERM ANALYSIS ...........................................................................................................................26
3.1. EXCESSIVE DAYTIME SLEEPINESS ...............................................................................................................273.2. RAPID LOSS OF WEIGHT ..............................................................................................................................273.3. RAPID INCREASE OF WEIGHT ......................................................................................................................273.4. LOSS OF GRIP FORCE / FATIGUE INCREASE .................................................................................................273.5. NO SOCIAL CONTACT ..................................................................................................................................283.6. SEDENTARY LIFE SYMPTOMS ......................................................................................................................283.7. BAD PERSONAL HYGIENE ............................................................................................................................283.8. RAPID COGNITIVE DECLINE.........................................................................................................................283.9. NUMBER OF STEPS REDUCTION...................................................................................................................29
4. LONG-TERM ANALYSIS .............................................................................................................................29
4.1. POSSIBLE METHODOLOGIES........................................................................................................................29
4.1.1. Qualitative Spatio-Temporal Reasoning................................................................29
4.1.2. Trend detection ......................................................................................................30
4.1.3. Statistical Based Techniques..................................................................................30
5. RISK ANALYSIS.............................................................................................................................................31
5.1. USER NOT FOUND........................................................................................................................................315.2. CONTEXT NOT DETECTED ...........................................................................................................................325.3. UNEXPECTED ERROR...................................................................................................................................325.4. INTERNET ACCESS NOT AVAILABLE ............................................................................................................32
6. REFERENCES.................................................................................................................................................32
4
EXECUTIVE SUMMARYThis document aims at describing the development performed in WP6, related to the Virtual
Caregiver (VC). The first prototype of the VC has been described in D.6.1, which focused on the
architecture developed to allow the deployement of the VC as well as the profiling of the user. This
deliverable focuses on the functionalities implemented by the VC for the pilot, according to the
scenarios defined in D9.2.
This document also describes metrics and strategies used for short and long-term analysis. However,
due to the needs of data gathered during the pilot in order to apply the described techniques, the
results of these metrics and strategies will be documented in D8.2.
The deliverable is organised as follows: Section 1 presents the overall goal of the Virtual Caregiver.
Section 2 focuses on the Virtual Caregiver’s architecture by describing each of its component. Section
3 depicts the different metrics used for short term analysis and Section 4 describes the techniques use
for long term analysis. Finally, Section 5 provides a technical risk analysis by identifying the possible
points of failure of the Virtual Caregiver and providing contigencies.
LIST OF ACRONYMS
API - Application Programming Interface
CBAC - Community Based Activity Center
DB - Database
DoA - Description of Action
MQTT - Message Queue Telemetry Transport
MS - Milestone
VC - Virtual Caregiver
D.6.1 - First prototype of the virtual caregiver
D.5.3 - Final prototype of the monitoring systems
D.7.3 - Virtual community advanced functionalities
D.8.2 - Integrated Software/Hardware prototype validated
D.9.2 - Specification Refinements
WP - Work Package
WP1 - Management
WP2 - Functional requirements
WP3 - Implementation requirements
WP4 - Robot development
WP5 - Monitoring systems
WP6 - Virtual Caregiver
WP7 - Community Based Activity Center
WP8 - Integration and testing
WP9 - Testing with users
WP10 - Dissemination, Communication and Exploitation
5
GLOSSARY OF TERMSThis glossary is shared by D4.1, D5.1, D6.1, D7.1, and D3.2 to setup a common ground to facilitate a
common reading of all the documents.
The MoveCare system is an overarching system with a hierarchical structure. It can be subdivided
into modules encompassing heterogeneous components.
MoveCare modules are heterogeneous aggregates of components achieving a specific function.
In MoveCare we can identify 4 modules:
1) the Activity Center mainly promotes physical, cognitive and social activities.
2) the Monitoring System mainly aims at detecting early signs of the elder’s decline
3) the Robot with its autonomous navigation and perceptual capabilities allows an intelligent
interaction with the user to assist his/her needs;
4) the Virtual Caregiver offers semantic and spatio-temporal reasoning for decision making and
interventions.
5) The Virtual Community of user put in contact all the users of Movecare and supports
socialization.
The first three modules constitute the service layer of the platform, the Virtual Caregiver represents
the core layer. These modules are related to the platform that is deployed at the user site. The Virtual
Community of users connects together the different users (DoA, Figure 1).
MoveCare components are tools used by the modules to achieve their specific aims. The
components can be devices, sensors, user interfaces and software.
MoveCare Functionalities are the functional needs elicited by the potential user, more specifically
stimulation, monitoring and assistance (see MS2)
MoveCare Scenarios are the application use cases defining all the interactions between the user and
the components through which the MoveCare Functionalities are achieved.
Measurements are raw readings from a specific sensor.
Indicators represent a state of the user.
Metrics are defined as the changes of the indicators in long-term.
Interventions are actions of the system / robot.
User is the general user that can interact with the MoveCare system. It includes PILOT USERS
CAREGIVER USERS and COMMUNITY USERS.
Pilot User is a MoveCare participant
Caregiver user is a caregiver associated to one participant of MoveCare.
Community user is any user from the virtual community of Movecare.
Data Center is the main data repository that saves all the data from the 4 modules that are accessed by
the Virtual Caregiver for short and long term reasoning and decision making.
6
1. Introduction
The Virtual Caregiver is a central component of the MoveCare systems. First, it aims at
detecting early signs of possible cognitive and/or physical decline for the elder by building a
robust picture of the elder through profiling and long term trend detection. Second, it aims at
mitigating risks by giving suggestions (called interventions) to the user. These suggestions
encompasses physical or cognitive activities to perform, social interactions...
In addition, the Virtual Caregiver acts as a helper in every-day life by providing different
utilities such as reminders or a search for objects service.
From a technical point, the VC communicates through MQTT messages. It is constantly
listening to the “messages” sent by the components that contains information about the
environment and other smart devices (WP5). The VC than uses a layer of “intelligence” in
order to infer the current status of the users, and suggest actions. The process of inference
is rule-based which were determined in tight interaction with the clinicians and domain
experts represented in the project. The suggestions/intervention is triggered according to
pre-defined templates which constantly check whether the current status matches the need
for an intervention to be given. For example, every 7 days the weight is analysed if it falls
within a reasonable window of values, and if not, an intervention for the system to prompt or
remind for a weight at a higher frequency is made.
The VC furthermore is the glue for many of the modues in the system. It is the module
(made of several components) which receive the data and in turn connects this information
to the actions that the robot or other agents may need to take. It is a central node to the
MoveCare system.
The VC has been designed in a modular fashion. As users should be able to tailor the
components as they need, where certain components may be activated or deactivated
depending on the needs of the user and the scenario. This deliverable will describe the
overall architecture of the VC and give the details of the implementation of a number of
components. Furthermore, the deliverable will propose how components for long-term trend
detection could be designed using this framework.
The actual instantiation of the VC is outlined here. Data that has been collected and outlines
how the VC has performed in the pilots will be described in D8.2., after the pilots have been
deployed.
7
2. Overview of the VC’s functionalities
2.1. Overall Architecture
Figure 1 presents the global architecture of the Virtual Caregiver.
Figure 1 General overview of the Virtual Caregiver
The VC is organized as a set of components of two different types: the utility components,
implementing a functionality that is required across scenarios, and the scenario
components. This separation is similar to the description of the scenarios and additional
functionalities given in D.9.2. However, in two scenarios from D.9.2, meaning the grip force
scenario and the cognitive games, the role of the VC is limited to suggesting to the user to
play the grip force or cognitive game. The VC do not expect any answer from the user. For
this reasons, these two scenarios do not appear as “scenario components” in our separation
but are regrouped under the “reminders” component.
The VC also includes one webservice, implementing the users and activity ranking when
queried by the CBAC.
The utility components are the following:
· The orchestrator takes care of the delivery of the interventions generated by all the
other components depending on pre-defined rules and context information. It also
ensures that there are not too many interventions delivered per day.
· The user location component takes care of locating the user in the home thanks to
the PIR sensors. It also detects when the user is not at home (presence at home
functionality).
· The reminders component implements the different reminders for the users. These
reminders are independent from the scenarios and concerns the charging of smart
objects, advices resulting from monitoring (like playing more cognitive games or the
grip force game
8
· The report generation generates alerts from the data gathered by the VC and
creates monthly reports to send to the caregiver.
· The smart button component implements the smart button functionality to switch
off/on the system whenever the user needs it.
The scenario components are the following:
· The spot questions component implements the spot questions functionality by
creating interventions to deliver the spot questions to the user and store the result.
· The weight monitoring component implements the weight monitoring functionality
to remind the user to weigh themselves and analyze the data.
· The call for help component implements the call for help scenario by sending an
email to the caregiver containing the link to activate teleoperation.
· The neuro-psychological tests component generates interventions when it is time
for the user to perform their neuro-psychological tests.
· The find lost objects component implements the search object scenario by
maintaining statistics about the previous locations of the objects and creating an
intervention when a search object command is initiated by the user. The VC includes
the statistics about last known location and possible locations in this intervention.
Each of these components as well as the webservice will be described more in details in the
following sections. This architecture allows the VC to be configurable and easily extendable.
In order to communicate with each others, the components are using internal MQTT
channels shown in Figure 1. The messages sent through these MQTT channels are not
stored in the database and no other Movecare component should use them, with the
exception of the CBAC which notifies the VC when a new user is created. In addition to
these channels, each component also subscribes to the specific channels it needs to
perform its task.
2.1.1. Channel movecare/vc/all
This channel is used to send information to all the components in the VC, with the exception
of the startup component. Two types of messages are sent through this channel:
1. An add_new_patient message
2. A terminate message
The add_new_patient message has the following format:
{"function":"add_new_patient","userid":"2c938084683d9f8701684cbc43e80020","username":"sunny.guy1","firstname":"Nicola","lastname":"Basilico","email":"[email protected]","approved":True,"usertype":"pilot","instance":"CBAC1","time":{"temporaliy":"timestamp","t":1547475854.227}
}
9
It is sent in two occasions:
1. At startup, the VC checks in the CBAC database is patients already exist. This is
done to ensure that if the VC encounters an unexpected error during the pilot and is
required to restart, previously created patients are registered again and that their
monitoring can continue. If existing patients are found in the CBAC database, the
message is sent to all the components during initialization.
2. When a new patient is created through the CBAC, the CBAC sends this message to
the VC to inform it of the new registration and give the necessary informations.
The terminate message is internal to the VC and is sent when the VC is stopping at the
end of the pilot. It unregisters all the patients, deletes all the cached data and stops all
analysis.
2.1.2. Channel movecare/vc/orchestrator
In the VC architecture, the orchestrator receives all the interventions created by the other
components, prioritizes them and decides when to deliver them. The
movecare/vc/orchestrator channel allows the components to send requests to the
orchestrator with the intervention to be delivered to the user.
After delivering an intervention to the user, the robot sends an acknowledgment to the VC.
Each component is responsible for listening and treating the acknowledgment adequately,
usually by logging that the intervention has been delivered or rescheduling it for later the
user declined.
2.2. Description of the utility components
2.2.1. Orchestrator
The main role of the Virtual Caregiver is to deliver interventions to the user. The delivery of
these interventions should be timed to avoid any disturbance in the user’s daily life. The role
of the orchestrator is to determine when the user is available to receive an intervention. It is
based on two different aspects: a rule-based orchestration and a context-based
orchestration.
Rule-based orchestrationDeriving the context from the sensor data is possible but cannot be guarantee 100% correct.
In order to avoid any major disturbance in the user’s life (for instance an intervention
delivered during the night, when the user is sleeping), a set of hard-coded rules have been
implemented. These rules are summarized in Table…
NAME DESCRIPTION
Night No intervention is generated between 09:00 pm and 09:00 am,whatever the result of the context-recognition
Max-nb-intervention No more than 5 interventions should be delivered each day
Min-time-between-interventions
A minimum of 1 hour should be ensured between 2 interventiondeliveries
10
Robot-battery-ok Intervention should not be delivered if the robot battery is lessthan 20%. This is to ensure that the robot does run out ofbattery in the middle of the intervention delivery
Context based orchestrationIn addition to hand-coded rules, the virtual caregiver is capable of making sense of the
context in order to decide when to deliver an intervention. The context elements taken into
account are summarized in the following table.
NAME DESCRIPTION
Presence athome
The VC detects whether the user is present at home or not.
Resting The VC detects whether the user is currently lying on the bed
In thebathroom
The VC detects whether the user is currently in the bathroom (if thebathroom is monitored)
Presence at HomeUsing PIR sensors and accelerometer in bed the VC is capable of deriving whether the user
is present at home or not and therefore postpone delivery of intervention until the user
returns.
RestingUsing PIR sensors and accelerometer in bed, the VC is capable of detecting that the user is
lying on the bed. This information is used by the VC to ensure that no intervention is
delivered in this case.
In the bathroomDepending on the user’s choice, the bathroom in the apartment might be monitored by a
motion sensor. If it is monitored, the VC can user this sensor to detect that the user is in the
bathroom and prevent interventions to be sent. The only exception to this rule is in the
weight monitoring scenario. Indeed, in this case, after the user weighed him/herself, the
robot should acknowledge the reception of the measurement. In that case, a talk intervention
is issued even if the user is in the bathroom (as it is probable that the scale will be located in
the bathroom).
2.2.2. User’s location
For the robot to be able to reach the user to deliver interventions, it is important that the user
can be located in the home. The location of the user is “room-based” (in the kitchen, in the
living room…) and uses the PIR present in the environment. The VC receives the activation
pattern of the PIR in real-time and, using the floor plan stored in the database, derive in
which room the user is located. This operation can be disturbed by the robot navigating in
the environment, which would activate the PIR sensors. However, the robot should most of
the time stay in its docking station. Therefore, the following process has been decided to
derive the user’s location:
11
1. When the robot starts navigating in the environment, it sends the following MQTT
message to the VC
{ "userid" : "12345", "ecode" : "ROBOT", "time" : {"temporality" : "timestamp", "t" : 1494257800.105}, "data" : { "pose" : "[23.5 0.23 2.14]", "battery" : { "voltage":23.6, "percentage":0.98, “power_supply_status":2
}, "intervention":"IDLE", "navigating":true }}
2. When the robot stops navigating, it sends the following MQTT message to the VC:
{ "userid" : "12345", "ecode" : "ROBOT", "time" : {"temporality" : "timestamp", "t" : 1494257800.105}, "data" : { "pose" : "[23.5 0.23 2.14]", "battery" : { "voltage":23.6, "percentage":0.98, “power_supply_status":2
}, "intervention":"IDLE", "navigating":false }}
3. When the VC receives a new activation line from a PIR sensor, its inference depends
on the status of the robot:
a. If the robot is currently navigating, the VC suspend all inference
b. If the robot is not currently navigating, the VC extracts from the floor-plan the
location of the PIR sensor that has been activated and update the latest
known location of the user. It then sends the following MQTT message to
update the robot about the user’s location:
{ "userid" : "12345", "icode" : "RLC", "time" : {"temporality" : "timestamp","t" :1494256770.105}, "data" : { "location" : { "value" : "kitchen", "units" : "code"
12
} }}
4. When the VC sends an intervention that requires the robot to navigate to the user,
the robot uses the latest known location. Upon arriving in the said room, the robot
scans the room to find the user.
a. If the user is found, the robot delivers the intervention
b. If the user is not found, the robot waits for some second for the VC to update
the user’s location. If after 20 seconds, the location has not been updating,
the robot starts the roaming procedure to find the user.
2.2.3. Reminders
The reminders component implement the logic to reminds the user of certain things to
perform or certain desirable behaviors. These reminders are independent from the
scenarios.
The reminders the current component generates are listed in the folowing table. This table
also shows the condition necessary to trigger this reminder and the sentence actually given
by the robot to the user when the reminder is triggered. These sentences will be refined and
translated in Spanish and Italian by month 26.
REMINDER Condition Sentence
Play the gripforce game
No data from the grip force gamehave been recorded in the past 7days
“I noticed you haven’t tested yourgrip force for more than a week. Itis important for you to do itregularly. Why don’t you connect tothe CBAC and test it now? It isimportant for me that you performthis test regularly.”
Recharge anduse the smartpen
No data from the smart pen hasbeen recorded in the DB in thepast 7 days.
“I noticed you haven’t been usingyour smart pen for a while. Did youremember to charge it? Rememberthat it is important for me that youuse it regularly”
Play cognitivegames
No game has been playedthrough the CBAC in the past 7days.
“I noticed you haven’t played anygame for a while. Why don’t youconnect to your activity center andplay?”
Do somephysicalactivity
None of the following activitieshas been detected in the past 7days:
1. exer-games2. outdoor walk3. gentle exercising
“I noticed you haven’t done muchphysical activity lately. Why don’tyou connect to your activity centerto do some exercising”
“I noticed you haven’t done muchphysical activity lately. Why don’tyou go outside for a walk?”
Have moresocial
None of the following activitieshas been detected in the past 7
“I noticed you haven’t got manysocial interactions lately. Why don’t
13
interaction days:1. multi-player game on the
CBAC2. phone call
you connect to your activity centerto play with a friend? Or maybe calla friend to take some news?”
The reminder to perform physical activities adapts to the context around the user. To do so,
it queries an online API1 to retrieve the weather forecast in the next 3 hours at the location of
the user’s home. If the weather is not rainy, then it will suggest to the user to go outside. If
the weather is rainy, it will suggest instead to play some game on the activity center.
2.2.4. Report Generation
The report generation component generates reports to send to the user’s caregiver. These
reports contain alerts that might have been detected and that should be noted by the
caregiver. These reports are sent either weekly, if a relevant alert has been detected during
the week, or monthly in any case.
The following table summarizes the alerts generated by scenarios as described in D.9.2.
Scenario Alert Frequency
Body WeightMeasurement
User lost 2% of their weight in a week Weekly
User gained 2% of their weight in a week Weekly
User following a trend of loosing weight Monthly
User following a trend of gaining weight Monthly
Call for help The call for help scenario has been triggered X times Monthly
Cognitivegames
User's scores have worsen during last month Monthly
User's scores have improved during last month Monthly
The following table summarizes the alerts generated by the additional functionalities as
described in D.9.2.
Additionalfunctionality
Alert Frequency
Grip force Grip force has worsen during last month Monthly
Spotquestions
User's performance has worsen during last month Monthly
User's performance has improved during last month Monthly
Lying in bed User has changed their lying in bed pattern(increased time in bed)
Monthly
User has changed their lying in bed pattern(decreased time in bed)
Monthly
1 https://openweathermap.org/api
14
Physicalactivity
User has done less then X hours of physical activitylast month
Monthly
Socialinteraction
User might have low social interactions Monthly
2.3. Description of the scenarios componentsFor each scenario component, we will present the internal structures used by the component
to provide the service, the flow the followed by the component (triggers and actions), the
specification of the MQTT messages the component receives and the specification of the
intervention it generates.
The description of each scenario with user cases and activity diagrams can be found in
D.9.2.
Each component maintains internally a list of registered users (the users who accepted to
use the scenario they provide) associated to the instance they are on (Spain or Italy).
2.3.1. Body Weight Monitoring
Internal dataThe body weight monitoring component maintains two different dictionaries:
1. latest weight measurement per patient
2. number of days before the next measurement per patient
Both dictionaries have been implemented in order to prevent unnecessary queries to the
database.
The first one contains the weight received from the smart scale during the previous
measurement (whether this measurement followed an intervention or not).
The second one contains the number of days remaining before the patient should be asked
to measure themselves again.
Flow
Step Condition Effect
1 At 01:00 am every day The VC checks for each patient the number ofdays remaining before their next measurementand updates the dictionary.
2 The measure is due forthis day
The VC generates an intervention to deliver to thepatient to reminds them that the weightmeasurement is due
3 The VC received a weightmeasurement
The VC compares the weight measurementreceived with the previous one from the dictionary
3.1 The weight is normal The VC updates the dictionaries with the newweight measurement and with the new number ofdays (7 days)
3.2 The weight is not normal The VC generates an intervention to ask the user
15
to repeat the measurement
3.2.1 The weight is normal The VC updates the dictionaries with the newweight measurement and with the new number ofdays (7 days)
3.2.2 The weight is still notnormal
The VC updates the dictionaries with the newweight measurement and with the new number ofdays (3 days)
4 Measurement has beenreceived
The VC sends feedback to the user.
In addition to the step described in the previous table, the VC performs step 3 (and substep)
whenever a weight measurement is received, whether an intervention had been sent
previously or not.
Messages received
Publis-her
Channel Message MQTT format
HGW movecare/measure-ments/<userid>/<sensorid>/BWT
the weight valuesent by the smartscale
{ "userid":"abc1234", "sensorid" : "BLE-<mac_address>", "mcode" : "BWT", "time" : {"temporality":"timestamp", "t" : 123456789, }, "data" :
{ "value" : 81.0, "units" : "kg" }}
Interventions generatedThe weight monitoring component generates four different interventions, described in the
following table.
• An intervention to ask the user to measure their weight
• An intervention to ask the user to repeat the measure if an error has been detected
• An intervention to give feedback to the user in case of a normal weight
• An intervention to give feedback to the user in case of an abnormal weight.
Code Content MQTT format
WM Ask the user to take aweight measurement
{ "id" :"aaa-bbb-ccc",
16
"userid" : “abc1234” ,"ivcode" : “INFO” ,
"time" : { "temporality" : "timestamp", "t" : 123456789 }, "data" : { "code" : "WM", }}
VSC An variation of at least2% has been detected.The VC asks the user torepeat themeasurement
{ "id" : "aaa-bbb-ccc", "userid" : "abc1234", "priority" : 3, "time" : { "temporality" : "timestamp", "t" : "<timestamp>"
}, "data" : { "code" : "VSC" }}
TALK Delivers a feedback tothe user in case of anormal weight.
{ "id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporality" : "timestamp", "t" : "<timestamp>" }, "data" : { "code" : "TALK", "text" : “I have registered yourmeasurement. Thank you” , "find_user" : false },
"priority": 3}
TALK Delivers a feedback tothe user in case of anabnormal weight.
{ "id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporality" : "timestamp", "t" : "<timestamp>" }, "data" : { "code" : "TALK",
17
"text" : “I have registered yourmeasurement. Thank you. Your nextmeasurement will be due in three days.” ,
"find_user" : false }, "priority": 3}
2.3.2. Call for help
Internal dataThe call for help component does not keep any internal data
Flow
Step Condition Effect
1 The component receivesthe call confirmationmessage
The VC sends an email to the caregiver with thelink for the teleoperation
Messages received
Publis-her
Channel Message MQTT format
HGW movecare/in-dicators/<userid>/EMERG-CALL
the call to thecaregiver has beenconfirmed
{ "userid" : “abc1234” , "icode" : "EMERGCALL", "time" :
{ "temporaliy" : "timestamp", "t" : 123456789 } "data" : { "code" : "CH", "caregiver": "xyz5678",
"status" : "CONFIRMED" }}
Interventions generatedNo intervention is generated in this component.
18
2.3.3. Neuropsychological tests
The neuropsychological test component reminds the user to perform their
neuropsychological tests at the beginning and at the end of the pilot, as described in D 5.1.
Similarly to the body weight component, it maintains an internal dictionary of the next time
each patient should perform the tests. When a patient is created, the time for the test is
planned for the following day.
Every day at 01:00am, the component wakes up and check which patient should perform the
tests on this day. For each of them, the component sends an intervention to the orchestrator
to deliver to the patient. The day after the intervention is delivered, at 01:00am, the
component verify that the complete tests data are present in the database. If they are, then
the component plan the next reminder for 7 weeks later. If not, the component plans a
reminder for the same day.
After the reminder has been schedule and the patient has agreed to perform the tests, a
message is sent to the VC webservice backend to inform it about the tests to be performed.
When the user connects to the CBAC and the CBAC interrogates the VC about the activities
to perform, the VC indicates that the neuropsychological tests have to be performed and the
CBAC can prioritize them.
Internal dataThe neuropsychological test component maintains two dictionaries:
a. The number of days remaining before the next tests for each patient
b. If the patient agreed to take the tests
As for the body weight component, the first dictionary is used to avoid unnecessary daily
queries to the database. It contains for each patients the number of days remaining before
they need to take the tests again and is updated each day.
The second dictionary is used as a memory to check if the user has agreed to take the tests.
Indeed, the tests results are updated from the CBAC only once a day. Therefore, if the
patient agreed to take the tests, the VC must verify in the database the day after that the
tests have actually been taken.
Flow
Step Condition Effect
1 At 01:00am every day The component checks for each patient if theirtests are due this day and updates the dictionary
2 The tests are due this day The component generates an intervention toremind the patient that the tests are due
2.1 The patient accepted totake the tests
2.2 The patient postponetaking the tests
Nothing happens until the next day
3 Tests results are presentin the database
The VC updates the dictionary with the number ofdays before the next tests (48 days)
19
Note that steps 2.1 and 2.2 concern only the neuropsychological tests component. If the
patient agrees to take the tests however, the webservice (described in Section 2.4) will
provide the tests
Messages received
Publis-her
Channel Message MQTT format
CBAC movecare/indica-tors/<userid>/BELL
the bell testshave beenperformed
{ "userid" : "abc1234", "icode" : "BELL", "time" : { "temporality" : "timestamp", "t" : 123456789 }, "data" : { "items" : [ { "name": "Duration", "value": 300, "units" : "s" }, ... ] }}
CBAC movecare/indica-tors/<userid>/TMTA
the TMT-Atests havebeenperformed
{ "userid" : "abc1234", "icode" : "TMTA", "time" : { "temporality" : "timestamp", "t" : 123456789 }, "data" : { "items" : [ { "name" : "Duration", "value" : 130, "units" : "s" }, ... ] }}
CBAC movecare/indica-tors/<userid>/TMTB
the TMT-Btests havebeenperformed
{ "userid" : "12345", "icode" : "TMTB", "time" : {
20
"temporality" : "timestamp", "t" : "1494257770105" }, "data" : { "items" : [ { "name" : "Duration", "value" : 130, "units" : "s" }, ... ] }}
Interventions generated
Code Content MQTT format
CT Ask the user to performthe cognitive tests
{ "id" : "aaa-bbb-ccc", "userid" : "abc1234",
"ivcode" : "INFO", "time" : { "temporality" : "timestamp", "t" : 123456789 } "data" : { "code" : "CT", }}
2.3.4. Search for lost objects
In the Search for lost objects scenario, the VC maintains statistics over previous locations
(number of time the object has been found in each room of the apartment). When the
scenario is triggered, the intervention created by the VC contains this information. If the robot
finds the object, it sends to the VC the location at which it has been found and the VC
updates its internal statistics. These statistics are only a tool to render the search object
more efficient and do not provide any meaningful information about the user’s profile. For
this reason, they are not stored in the database.
The CBAC ensure that it is impossible for the user to start a second object search while one
is still active and to give feedback.
Internal dataThe search for lost objects component maintain internally a dictionary associating a statistic
object to each user.
This statistic object contains:
• a list of all the room existing in user’s home
• a list of all the objects that can be searched
21
• for each room-object combination, the number of times the object has been found in
the room
Flow
Step Condition Effect
1 A new patient is created The component queries the database to retrievethe floorplan and create the statistic object
2 A new search for object isinitiated by the CBAC
The component generates an intervention to askthe robot to initiate the search. It adds to thisintervention as a parameter the list of roomsordered by the number of time this object hasbeen found
3 The object has been foundby the robot
The component updates the statistics
4 The object has not beenfound by the robot
Nothing happens until a new search object isstarted
5 The search has beeninterrupted by the user
Nothing happens until a new search object isstarted
Messages received by the VC
Publis-her
Channel Message MQTT format
CBAC
movecare/acknow-ledgments/<use-rid>/INFO
The search object
scenario has been
triggered by the VC
{ "id":"aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporaliy" : "timestamp", "t" : 123456789 } "data" : { "code" : "OS", "objectid" : "123def456"
}}
Robot
movecare/acknow-ledgments/<use-rid>/INFO
The object has been
found by the robot{ "id" : "ddd-eee-fff", "intervention_id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : {
22
"temporality" : "timestamp", "t" : 123456789 } "data" : { "code" : "OS", "objectid" : "123def456", "response" : "Found", "location": "XXXXXXXX", "roomID" : "Y"
}}
Robot
movecare/acknow-ledgments/<use-rid>/INFO
The object has not
been found{ "id" : "ddd-eee-fff", "intervention_id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporality" : "timestamp", "t" : 123456789 } "data" : { "code" : "OS", "objectid" : "123def456", "response" : "Not Found", "location": "XXXXXXXX",
"roomID" : "Y" }}
CBAC
movecare/inter-ventions/<use-
rid>/INFO
The object search has
been stopped{ "intervention_id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporaliy" : "timestamp", "t" : 123456789 }
23
"data" : { "code" : "STOP_OS",
"objectid" : "123def456" }}
It is important to note from the previous table that the object search start is triggered by the
CBAC by sending an acknowledgment message which is then transferred to the robot
through an intervention generated by the VC (described in the next section) while the object
search stop message is an intervention directly generated by the CBAC. This is due to the
fact that the VC computed statistics must be included in the start message while the stop
message does not require any reasoning and can therefore be sent directly by the CBAC.
The VC simply monitors it to update its internal state.
Interventions generated
Code Content MQTT format
OS Start the object searchand provides statisticsabout previouslocations (list of roomsordered by highestprobability to find theobject in this room)
{ "id" : "aaa-bbb-ccc", "userid" : “abc1234” , "time" : { "temporality" : "timestamp", "t" :123456789 } "data" : { "code" : "OS", "objectid" : "123def456", "rooms":
[ "livingroom", "office", "kitchen" ] }}
2.3.5. Spot questions
The spot questions component asks some questions regularly to the user, following a pattern
designed by the clinical experts. The description of all the spot questions can be found in
D.5.3.
Internal dataThe VC maintains the following data:
- a list of all the possible spot questions references
- a pattern object containing the frequency at which questions need to be asked (as
described previously)
24
- a dictionary containing for each patient the references of the questions asked this day
- a dictionary containing for each patient their score for each spot question type
Flow
Step Condition Effect
1 At 01:00 am every day The VC checks the list of spot question to see if aquestion should be asked this day
2 A question is planned tobe asked this day
The VC selects a question among those notalready asked and queries the database for theanswer to the question (if any) and generates anintervention with the spot question referencenumber and the corresponding answer
3 The VC receives the resultof the spot question(correct/incorrect/error)
The VC update the score of the patient
Messages received by the VC
Publis-her
Channel Message MQTT format
Robot
movecare/acknow-ledgments/<use-rid>/INFO
The result of the
spot questions
{ "id":"ddd-eee-fff", "intervention_id" : "aaa-bbb-ccc", "userid" : "abc1234", "time" : { "temporality" : "timestamp", "t" : 123456789 }, "data" : { "code": "XY01", "result" : 0
}}
Interventions generated
Code Content MQTT format
Accordingtodescription
The spot questionto be asked andthe expectedanswer
{ "id":” aaa-bbb-ccc” , "userid" : “abc1234” , "time" :
25
{ "temporality" : "timestamp", "t" : 123456789 }, "data" :
{"code": "XY01","answer" : "yes"
}}
2.4. Description of the VC webserviceThe VC webservice exposes an API that the CBAC can call when the user logs in. It is used
to retrieve a list of suggested activities and possible opponents. It is also used in the
neuropsychological test scenario to enable the user to perform their tests.
The webservice’s API exposes two different routes:
• <vc-ip>/<string:user-id>/rankingReturns the activities ranked for a certain user
• <vc-ip>/<string:user-id>/<string:activitytype>/peersReturns a ranking of possible peers to play with for a given activity
If the intervention for the neuropsychological tests has been issued, then the tests will be
added in the list of the possible activities to perform when the CBAC calls the first route.
2.4.1. Ranking of the activities
The activities suggested to the user are ranked according to the user’s preferences and
previous activities as well as context information. In the version of the VC developed for the
pilot, the context information includes weather data from the location of the user’s home.
The metric used to rank each activity A given a user is the following:
with :
TotalPlayTimeA being the total amount of time (in min) this user has played the
activity
PreferenceA being the preference score given by the user in their static profile
for this activity
ContextModifierA being a modifier, between -1 and 1, computed by the VC
according to the current context.
In the version of the VC developped for the pilot, the context modifier equals 1 for each
activity which is not physical. For physical activities, the context modifier equals 1 if the
outside temperature is below 25°C and -1 otherwise. In future developpement, the
calculation of the context modifier would be improved with more information (humidity, time
of the day, previous level of activity from the user...)
26
Ranking of the peersThe users are ranked according to their previous scores at the considered activity. For each
possible peer, the VC queries the DB to retrieve the peer’s global score (Gscore) (described
in D.7.3, section 7.4.2) and calculates their adequacy to the user’s.
Two lists are created, a “ranked” and an “unknown” list. The ranked list contains the list of
peers for which previous data is available and that can therefore be ranked according to our
metrics. The unknown list contains all the peers for whom no previous data is available and
therefore no adequacy can be comptued.
The adequacy between the user and a peer is calculated as follows:
3. Short-Term analysis
In this section we provide a description of the short-term analysis carried out that are to be
used within the VC for reasoning with and studying the data that is stored in the database
closely in the form of indicators and measurements.
The following table presents all selected short-term indicators to be included in the VC. Next,
they are explained in detail.
Short-termindicator
Frequency Calculation Threshold
Excessive daytimesleepiness (EDS)
Daily Based on hours in bed (day)(HBD)
HBD ≥ 120 minutes
Rapid loss ofweight (RLW)
Weekly RLW := BWt - BWt-1 ≤ -2% ×BWt-1
RLW ≤ -2% × BWt-1
Rapid increase ofweight (RIW)
Weekly RIW := BWt - BWt-1 ≥ 2% ×BWt-1
RIW ≥ 2% × BWt-1
Loss of grip force /fatigue increase(LGFFI)
Monthly Inferred from stress ball LGFFI ≥ 5%
No social contact(NSC)
Daily NSC := {no home visits, nocalls}
Three days in a row
Sedentary lifesymptoms (SLS)
Weekly Inferred from detection ofpressure (DPR) sensor
SLS ≥ 40 hours
Bad personalhygiene (BPH)
Daily BPH := no bath neithershowers
Three days in a row
Rapid cognitivedecline (RCD)
Whenapplicable
RCD := CAQt - CAQt-1 ≤ -5%× CAQt-1
CAQ ≤ 60% during 3months
Number of stepsreduction (NSR)
Weekly Inferred from outdoor gaitsensor
Baseline to bestablished
27
3.1. Excessive daytime sleepinessExcessive daytime sleepiness (EDS) is characterized by persistent sleepiness and often a
general lack of energy, even during the day after apparently adequate or even prolonged
night time sleep. Accurate diagnosis is important, not only because of the negative impacts
of sleepiness and its root causes on health and social function, but because excessive
sleepiness is generally remediable with appropriate treatment [Guilleminault, 2001].
According to the National Sleep Foundation 2000 Omnibus Sleep in America Poll: “a sizable
proportion of adults (43%) report that they are so sleepy during the day that it interferes with
their daily activities a few days per month or more; and, one out of five (20%) experience this
level of daytime sleepiness at least a few days per week or more”. In [Powell, 1999], the
authors demonstrated that decreased performance due to sleepiness may be worse than
that associated with alcohol intoxication.
Daytime sleepiness is common but often unrecognized. EDS may be marked by lapses into
sleep during sedentary moments during the day.
In MoveCare, an indicator of EDS will be computed to help users and clinicians detect EDS.
The calculation will be based on the time the user is in bed during the day. This presents
some shortcomings, e.g., daytime sleepiness might occur somewhere else than in bed,
where the only sleeping sensors are installed; the sleeping sensors do not present 100%
accuracy when differentiating whether the user is sleeping. However, the EDS will give an
alert to caregivers so as they are triggered to ask the user about his/her sleeping habits.
3.2. Rapid loss of weightWeight loss can be intentional, such as from dieting and exercise, or unintentional and be a
manifestation of illness. Weight loss can result from a decrease in body fluid, muscle mass,
or fat. A decrease in body fluid can come from medications, fluid loss, lack of fluid intake, or
illnesses such as diabetes. MoveCare will alert caregivers in case users are losing weight
too quickly so there is time to act if that was a sign of illness.
Rapid loss of weight (RLW) stands for a significant difference in user’s weight, i.e. more than
2%. This indicator plays a role in the body weight scenario. In case of RLW, the VC asks to
repeat the measurement to ensure that it has been done properly, and plans a new
measurement in 3 days in case the result is confirmed.
3.3. Rapid increase of weightRapid increase of weight (RIW) can be the manifestation of a disease: RIW is very common
for people with heart failure due to fluid accumulation, as well as for people with
hypothyroidism or those who are resistant to insulin.
The implementation in MoveCare mimics the one presented in section 1.3. but focusing on
the gain of weight.
3.4. Loss of grip force / fatigue increaseFatigue is defined as a sense of persistent general tiredness. It is becoming increasingly
recognized as a specific geriatric entity since both prevalence and incidence appear to
increase with advancing age, and for the majority, fatigue per se exists independently of any
specific diagnostic conditions. Task-specific measures of tiredness have been examined in
clarification of the theoretical assumption that fatigue may be instrumental in the disablement
process. In particular, self-reported tiredness while performing daily activities has been
examined, and among non-disabled elderly people, it has been found to be a determinant of
subsequent utilization of health and social services, walking limitations, onset of disability,
and a reduction in both 10- and 15- year survival.
28
The computation is performed using the stress ball sensor.
3.5. No social contactHuman interactions are governed by the explicit willingness of establishing meaningful social
relationships. Recognizing social interactions between humans is a complex and extremely
diversified field. Face-to-face interactions detection often depends on the phenomena under
observation: in certain cases, only short events with a very small distance between the
individuals are relevant, in others, only prolonged proximity that would give individuals a
chance to have meaningful conversations are pertinent. A tie between two individuals is
defined as a combination of the amount of time, the emotional intensity and the reciprocal
intimacy that characterizes the tie itself [Granovetter, 1983]. More clearly, each tie is a link
between humans, and its strength depends on several factors [Marsden, 1984], such as the
frequency of their interactions, the intimacy level, and the affinity of the subjects involved.
Several ways to analyse human behaviour exist, for example through a direct or indirect
observation of their actions. One of main issues of a direct observation is the observer itself
since may influence the natural behaviour of individuals
In literature, human interactions have been assessed using different techniques, including
subjective and self-reported questionnaires, and technologies, such wearable devices
equipped with dedicated hardware [Lederman, 2017], [Huang 2014].
In MoveCare, the social information available is limited. Hence, the solution implemented
only pretends to alert caregivers in case symptoms of loneliness have been detected, in this
case those are defined as not having social communication in 3 days in a row. This is
detected through information that comes from two different devices: a sensor that studies the
visits that come home, and the phone records.
3.6. Sedentary life symptomsA sedentary lifestyle is defined as a way of living that involves very little or no physical
activity. In other words, a person who lives this way spends most of their time either sitting or
lying down.
MoveCare aims at detecting sedentary life symptoms (SLS) in order to alert the caregiver
and help the user change his/her lifestyle. This will be done using the detection of pressure
(DPR) sensor. SLS are defined as spending more than 40 hours per week sitting or lying
down during the day.
3.7. Bad personal hygienePoor hygiene can be a sign of self-neglect, which is the inability or unwillingness to attend to
one's personal needs. Poor hygiene often accompanies certain mental or emotional
disorders, including severe depression and psychotic disorders.
Bad personal hygiene (BPH) is measured based on the number of bath/showers that user
takes. If the user has not taken any bath/shower for three days in a row, the VC will send a
note to the caregiver so as the user receives help in case any mental or emotional disorder
is affecting him/her.
This will not be implemented in the pilot due to its low importance in relation with the main
functionalities of the MoveCare system.
3.8. Rapid cognitive declineRapid cognitive decline (RCD) stands for a significant difference in user’s cognitive status.
Predicting RCD might help clinicians provide prognostic information for Alzheimer-type
dementia, for instance. In MoveCare this can be assessed through the Percentage of
29
correctly answered spot questions (CAQ). In particular, we prompt an alert signal when
40%-45% of the questions are answered wrongly during 3 months.
3.9. Number of steps reductionUser steps during exercises are measured by the wearable through the use of an embedded
accelerometer sensor. Noted the user medium step length, the distance covered by the user
during the exercise can be estimated by wearable using the steps information.
The number of steps reduction will be based on a user-specific baseline, defined as the
historic average value.
4. Long-Term analysis
The work carried in T6.4. so far analyzed and evaluated different methodologies that can be
used for long-term analysis. These methodologies will be implemented and tested on the
data gathered from the pilots and results will be presented in D.8.2.
In this section, we will describe each methodology and discuss their advantages and
limitations.
4.1. Possible Methodologies
4.1.1. Qualitative Spatio-Temporal Reasoning
Qualitative Spatio-Temporal Reasoning is a major field of study in Artificial Intelligence that
deals with encoding the human perspective of time through simel qualitative descriptions
such as precedes, meets or overlaps. Two well-known formalisms for representing
qualitative relations are Allen’s Interval Algebra (IA) [Allen1983] and the Region Connection
Calculus (RCC) [Randell et al. 1992].
These formalisms allow us to create a high-level timeline of the user’s daily activities that
can be then analyzed, either by a human caregiver or by another automated system, to
detect trends and patterns.
The timeline of the patient is created using pre-conditions and events, represented by a
publicly available2 ontology called Smart Home [Alirezaie et al. 2017]. The Smart Home
ontology is a network of ontology modules representing different aspects of a smart
environment. The most important component in our case, the SmartHomeEvent module,
represents an event by encoding its preconditions. One of these preconditions is the
temporal distance, which is itself an ontology module (named TemporalDistance). The
Description Logic (DL) expressions for the SmartHomeEvent and the TemporalDistance are
as follows:
2 http://ecareathome-ontology.mpi.aass.oru.se/SmartHome.owl
30
Using this representation, the Interval Algebra relations between events and their
preconditions can be inferred from the quantified temporal intervals associated with an
instance of an activity in the ontology.
More details about this process has been published in [Sioutis et al. 2017]
Qualitative Spatio-Temporal Reasoning thus allows us to create high-level timelines of the
user daily activities, which can serve as a input for spatio-temporal pattern recognition or
trend detection techniques. The main advantage of this approach is its expressiveness and
its great efficiency even with a little amount of data. However, the modelling can be
extremely complex depending on the activities the system needs to recognize. In tha case of
MoveCare, the (relatively) large variability between the pilot’s users and their habits makes it
difficult to implement. However, it might be possible to describe a subset of activities and
compare the results with other techniques.
4.1.2. Trend detection
Trend detection has already been successfully applied to recognizing elderly’s daily routine
and detect significant deviations. Different techniques can be used to perform trend
detections, depending on the type of data we wish to analyze. For instance, for activity trend
detection, some examples use temporal clustering: a cluster is determined for a user using
motion and bed sensors data. As data are added over time, the cluster will change and other
clusters may form, indicating changes in the user’s activity pattern. Another approach can be
found in [Anderson et al. 2012] where the authors define mathematically a similarity measure
for anomaly detection and comparing human behavior.
Density maps have also been used to track the level of activity of the user in room and
detect sudden changes [Rantz et al. 2008].
Within MoveCare, we intend to implement some of these techniques and test them on the
data we gather to evaluate whether it is possible to correlate a change (or not) in the Bell
and TMT tests with the patterns recognized through long-term analysis.
4.1.3. Statistical Based Techniques
A rudimentary alternative to the above two approaches would be also to perform simple
statistics to summarize the trends or long-term behaviours of the users. In this case a long-
term trend analysis (LTTA) is based on dividing the timeline into epochs, which are typically
a day each. (Some of the statistics are almost only meaningful with daylong epochs). These
day-long epochs can either be from midnight to midnight (day epochs), or from noon to noon
(night epochs). The latter is useful for investigating night-time activities: if e.g. the user
31
sleeps from 9pm to 7am, that should fit into one epoch. The different statistics that could be
relevant concern both how much/often an activity is performed, and when it is performed:
1. Number of occurrences per epoch
2. Sum of durations per epoch
3. Average duration per epoch
4. Earliest starting time per epoch
5. Latest ending time per epoch
6. Average time for activity per epoch
The LTTA can also compute running averages over several epochs. Typically, the longer the
total period investigated, the more epochs should be used for computing this average. The
running averages are important for separating the signal from the noise when a large
number of epochs are considered. It is recommended to use running averages to linear
trends, as the former can capture more patterns than just long-term increases and
decreases of a parameter.
5. Risk Analysis
The following table presents a summary of the identified technical risks for the Virtual
Caregiver.
Functionality Risk name Riskdescription
Likelihood Impact Contigency
User’slocalization
User notfound
The usercannot belocalized
High Medium Roamingstrategy &Reschedule
Context-awareorchestrator
Context notdetected
The data doesnot allow toidentify thecontextproperly
Low Medium Theorchestratorfollows hard-codedconstraints
All Unexpectederror
An unexpectederror forces theVC to restart
Low Critical Users’ idavailable forrecoverythrough CBAC
Internetaccess notavailable
Internet is notaccessible
Low High VC operates ona reduced set offunctionalities
5.1. User not foundLikelihood: High
Impact: Medium
Using the environmental sensors, the VC is capable of determining in which room the user
currently is. However, errors in the measurements of the sensors are to be expected as
sensors are not 100% precise and can be affected by events in and outside the home (e.g.
object falling, movement outside the window...). Due to these errors, it might happen that the
user is not found in the expected room, affecting the ability of the system to deliver the
32
interventions. Note that this risk considers only the case in which the user is known to be at
home but not found. The case where the user is not at home is part of the normal operation
of the VC.
Two different strategies will be implemented to overcome this risk:
1. Roaming: The robot roams in all the rooms of the home to find the user.
2. Reschedule: The VC is alerted that the intervention could not be deliver and reschedule
the delivery for a later time.
5.2. Context not detectedLikelihood: Low
Impact: Medium
The context information is used by the system to deliver the intervention in a non-obtrusive
way. If the context cannot be detected due to a lack of appropriate sensors or errors in the
sensors measurement, then this functionality can be affected and interventions might be
delivered at an inappropriate time. To overcome this risk, we will define hard-coded rule on
when the intervention can and cannot be delivered in the absence of context. As an
example, we can decide that no intervention should be delivered between 09:00pm and
08:00am in order not to wake the user up.
5.3. Unexpected errorLikelihood: Low
Impact: Critical
In case of an unexpected error, the VC might be forced to restart. The critical problem with
this scenario is that the VC locally keeps necessary information for each patient (as the
patient id) which is only given to it at the creation of the patient. Loosing this id means that
the VC is not capable of doing its tasks anymore. To overcome this risk, recovery strategies
must be implemented such as a local cache, keeping the user’s necessary information.
5.4. Internet access not availableLikelihood: Low
Impact: High
An important part of the VC is present in the cloud and needs an Internet access to receive
messages and data. If Internet is not available, this part of the VC cannot work anymore.
However, this risk is mitigated by allowing the most critical aspects of the VC (especially the
“call for help” scenario) to run locally. From the interventions’ point of view, interventions
which couldn’t be delivered will be rescheduled at a later time.
6. References
[Alirezaie et al. 2017] Alirezaie, M., Hammar, K., & Blomqvist, E. (2017). A pattern language
for smart home applications. Semantic Web Journal
[Allen 1983] Allen, J. F. (1983). Maintaining Knowledge about Temporal Intervals. Commun.
ACM 26:832–843
[Anderson at al. 2012] Anderson, D. T., Ros, M., Keller, J. M., Cuéllar, M. P., Popescu, M.,
Delgado, M., & Vila, A. (2012). Similarity measure for anomaly detection and comparing
human behaviors. International journal of intelligent systems, 27(8), 733-756.
33
[Granovetter 1983] Granovetter, M. (1983). The strength of weak ties: A network theory
revisited. Sociological theory,201-233.
[Guilleminault 2001] Guilleminault, C. a. (2001). Excessive daytime sleepiness: a challenge
for the practising neurologist. Brain, 1482--1491
[Huang 2014] Huang, W. a.-S. (2014). Opo: a wearable sensor for capturing high-fidelity
face-to-face interactions. En W. a.-S. Huang, Proceedings of the 12th ACM Conference on
Embedded Network Sensor Systems (págs. 61-75). ACM
[Lederman 2017] Lederman, O. a. (2017). Open badges: A low-cost toolkit for measuring
team communication and dynamics. arXiv preprint arXiv:1710.01842.
[Marsden 1984] Marsden, P. V. (1984). Measuring tie strength. Social forces, 482-501.
[Ohayon 2017] Ohayon, M. a. (2017). National Sleep Foundation's sleep quality
recommendations: first report. Sleep Health, 6-19
[Powell 1999] Powell, N. B. (1999). A comparative model: reaction time performance in
sleep‐disordered breathing versus alcohol‐impaired controls. The Laryngoscope, 109(10),
1648-1654.
[Randell et al. 1992] Randell, D. A.; Cui, Z.; and Cohn, A. (1992). A Spatial Logic Based on
Regions & Connection. In KR
[Rantz et al. 2005] Rantz, M. J., Aud, M. A., Alexander, G. L., Oliver, D., Minner, D., Skubic,
M., ... & Miller, S. (2008). TigerPlace: an innovative educational and research environment.
Nursing publications (MU).
[Sioutis et al. 2017] Sioutis, M., Alirezaie, M., Renoux, J., & Loutfi, A. (2017). Towards a
synergy of qualitative spatio-temporal reasoning and smart environments for assisting the
elderly at home. In IJCAI Workshop on Qualitative Reasoning (pp. 901-907).