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":"nicola.basilico@unimi.it","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).