project #643735 · 1.3 subtasks wp2 1.3 subtasks wp2 parallel to the iterative, cyclic process...

Project #643735www.do-change.eu

D2.3: Revised specifications of tools andservices

[Deliverable D2.3, Revision 1.0]

Key Information from the DoA

Due Date: 31/07/2016

Type: Report

Security: Confidential

Description:

This deliverable contains the (intermediate) results of the second cycle of DoChangeWork Package 2.

Lead Editor: Mart Wetzels (TUE ), Peter Peters (TUE )

Internal Reviewer(s): Bernat Sanchez (BSA ), Magi Lluch-Ariet (EUT ), and Ad vanBerlo (SMH )

Versioning and contribution historyVersion Date Author Partner Descriptionv0.1 13-07-2016 M. Wetzels TUE , DSD , ETZ First draftv0.2 18-07-2016 B. Sanchez BSA First reviewv0.3 19-07-2016 M. Wetzels TUE Second draftv0.4 20-07-2016 P. Bunkham DSD Second reviewv0.5 25-07-2016 I. Ayoola ONMI Edit before third draftv0.6 25-07-2016 M. Wetzels TUE Third draftv0.7 27-07-2016 A. van Berlo SMH Third reviewv1.0 27-07-2016 M. Wetzels TUE Final version

Statement of originality:This deliverable contains original unpublished work except where clearly indicated otherwise.Acknowledgement of previously published material and of the work of others has been madethrough appropriate citation, quotation or both.

D2.3 - Do CHANGE

Executive Summary

This report addresses the work done within Work Package 2 within the Do CHANGE project:User needs and co-design of tools and services. The deliverable consists of (intermediate)results from the second cycle of the project. Within the total health eco-system multiplestakeholders collaborate to create a service for its users. To substantiate, and guide, thedevelopments of this user-centered service the context, needs, and requirements of all usersmust be documented. This is achieved within this deliverable by:

• Conducting focusgroups on privacy within healthcare

• Performing an explorative UI study for DoCHANGE-app development

• Applying methods to visualise patient pathways and discovering opportunities for theDo CHANGE project.

The outcome of this work will feed into other Work Packages as user requirements and enablesdiscussion on the refinement of the use-cases between stakeholders of the ecosystem.

D2.3 - Do CHANGE

TABLE OF CONTENTS

Table of Contents

1 About this document 41.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Description WP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Subtasks WP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Requirements 7

3 Clinical pathways 93.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Case: STEMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Discussion and next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Privacy Study 124.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 Participant information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Do Something Different Cardiac Programmes 155.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Cardiac Do s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Responsive Do’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 App Study 246.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Participant information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 EDL: Responsive Do’s 297.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Study design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 Discussion 32

D2.3 - Do CHANGE 1

INDEX OF FIGURES

Index of Figures

1 STEMI Model (Activities: 40%, Paths: 0%) . . . . . . . . . . . . . . . . . . 92 Example Habit Rater Pillar 4: Healthy Eating Habits . . . . . . . . . . . . . . 163 Example message sent after Do . . . . . . . . . . . . . . . . . . . . . . . . . 174 Screenshot of Do Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Different days compared. The algorithm classifies the first two days as similar

and the third as different from the previous two, based on the fact that theuser visited an extra location. . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 The user left the place he/she slept at sensible different times of the day. . . 237 Scenarios of App Study generated by Just In Mind . . . . . . . . . . . . . . . 248 Demographics represented in stacked bar chart . . . . . . . . . . . . . . . . . 269 MapView of participant geo-distribution . . . . . . . . . . . . . . . . . . . . . 2610 Event-, path-, and activity-filtered model of App Study . . . . . . . . . . . . . 27

List of Tables

1 Contribution WP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Risk factors in STEMI-dataset . . . . . . . . . . . . . . . . . . . . . . . . . 103 Privacy Study progress per country . . . . . . . . . . . . . . . . . . . . . . . 12

D2.3 - Do CHANGE 2

LIST OF TABLES

List of Abbreviations

SMHSmart Homes

TUEEindhoven University of Technology

ETZElizabeth-TweeSteden Ziekenhuis

ONMIONMI

BSABadalona Serveis Assistencials

DSDDo Something Different

DOCDocobo

EUTEurecat

ITRIIndustrial Technology Research Institute of Taiwan

BTCDBuddhist Tzu Chi General Hospital

METCMedical Reviews Ethics Committee (Medisch Ethische Toetsings Commissie)

CVDCardiovascular disease

HIS Hospital Information System

STEMIST Segment Elevation Myorcardial Infarction

EDLExperiential Design Landscapes

D2.3 - Do CHANGE 3

1 About this document

This section of the report provides background information on the nature of the documentand responsibilities that entail Work Package 2.

1.1 Introduction

The work done from March 2016 until July 2016 reported in this document is:

• Methodology, execution, and analysis of privacy focus groups.

• Methodology, execution, and reporting of explorative app study.

• Identifying normative patient pathways models and setup for Process Mining applicationfor descriptive pathways.

• Planning for remaining time in second cycle.

The following partners have directly contributed to the work presented in this report:

Work Partners involved DescriptionPrivacy Study TUE ETZ

BSA BTCD ITRIMethodology and protocol setup byTUE and ETZ . METC requests,recruitment of patients, and per-forming patient interviews done byremaining partners. Full analysiswill be performed by TUE andETZ .

Cardiac DO’s DSD ONMI ETZTUE

Defining of three cardiac DO pro-grammes and documentation.

Care Pathways TUE ETZ SMH SMH provided examples fromother work, TUE processed andanalysed information obtained fromETZ .

App Study TUE ONMI Design, methodology, and valida-tion performed. Other partnerscontributed by finding participants.

Table 1: Contribution WP2

D2.3 - Do CHANGE 4

1 ABOUT THIS DOCUMENT

1.2 Description WP2

In PHC26 (ii) there should be a strong emphasis on co-designing and user needs as a keydriver. Therefore, a Cyclic Design or Iterative Design method will be used. This WP2 willtherefore continue from the beginning to almost the end of the project (month 33). Theobjectives are:

• to make sure that the tools + services are refined and developed from concept to practicalusage and evaluation.

• the mutual understanding of the partners’ values, ways of working and limitations arerefined and developed.

This work package will follow an iterative, cyclic process with three cycles of one year each.The process guarantees that not only the tools + services are refined and developed from con-cept to practical usage and evaluation, but simultaneously the mutual understanding of thepartners’ values, ways of working and limitations is refined and developed as well. This is essen-tial because the partners have different backgrounds and roles such as user, service-provider,technology developer, and integrator. Each cycle consists of (1) requirements definition (2)co-design and implementation (3) usage (4) cooperative evaluation. The subtask T2.1, T2.2,and T2.3 will be synchronised in the same cycles. Note that it is not just co-design and thentesting, the evaluation is a cooperative effort as well since the technology developer’s criteriaare different from the service developer’s criteria, which are not identical to the user’s criteria.Each cycle takes one year precisely so a smooth yearly rhythm of meetings and workshopsemerges as soon as possible. Lead partner is TUE . The main implementation and testingwork takes place in WP3-6 and then the results feed back into WP2.

D2.3 - Do CHANGE 5

1.3 Subtasks WP2

1.3 Subtasks WP2

Parallel to the iterative, cyclic process three subtasks are defined to include in all iterations.A description of the subtasks are listed below:

• Task 2.1: Technical and non-technical requirements: TUE will define the co-design protocols, the observation methods and document the process. SMH will definethe facilities and context. EUT and ITRI bring the sensor technology. ONMI willtake care of connecting the tools to the services. TUE creates Persona’s, Scenarios ofusage, Patient pathways, and detailed technical specs (for the sensor technology andthe software).

• Task 2.2: Co-design of tools - cyclic: EUT and ITRI bring the sensor technology.ONMI will take care of connecting the tools to the services. In Year 1, the tools willbe designed already as-if functioning, although some of the technology will be not fullyembedded. From year 2 onward the tools are functioning (although in year 2 there stillmay be calibration or initialisation technicalities only to be removed in year 3). Thedeployment of the tools will occur in the test lab of SMH (year 1) and at the patient’shome when the devices are connected at DOC (years 2 and 3). Focus groups, actingout, and speak out loud protocols will be used throughout WP2.

• Task 2.3: Co-design of services - cyclic: BSA and DSD will provide the expertisefor the services, DSD and DOC contribute to the software technology. DSD and ETZcontribute the psychological and medical perspective, respectively, and organise the co-designed versions of tools and services to be used by citizens and patients. DSD and ETZwill check and if necessary take action towards the local Medical Ethical Committee. Thepatient’s data recorded will be logged on servers of the partner that provides a specificserver. The test themselves are executed in WP6 but the cooperative evaluation belongsto WP2 to involve all the partners in the consortium so that all members are on thesame ground in terms of understanding the design requirements for technologies andend users, and the scenarios of using the tools and services.

D2.3 - Do CHANGE 6

2 REQUIREMENTS

2 Requirements

This section presents the requirements from work performed in WP2. The requirements arenumbered for the purpose of references in other deliverables.

1. Consortium-basedRequirements derived from internal discussion within the consortium; outside the scopeof the studies.

• 1.1 Temporary non-adherence, due to personal circumstances or other motivations,to the Do CHANGE program should be taken into account when determining theoverall adherence to, and success of, the provided behaviour change.

• 1.2 The granularity of privacy settings need to restricted, or limited, to a user-friendly level; this needs to be restricted within the privacy study.

• 1.3 The required behaviour change impacts the patient’s relatives as well; theinclusion of relatives within the program needs to be considered.

2. Patient InterviewsRequirements derived from the patient interviews [1]

• 2.1 The tools to be provided to patients (in the trial and ecosystem) need to becarefully considered, and mutually agreed upon, by patient and clinician to preventpatients from using tools that do not increase the quality of care.

• 2.2 The device SAL, as a cooking-utensil, needs to be limited to the kitchen envi-ronment; no use-cases outside the home.

• 2.3 The device Horus, as a food scanner, needs to investigate or substantiate thepossible stigmatising effects of using the device in a social environment.

• 2.4 The device MySleeve, as a service, needs to allow users to insert liquid intakemanually for use-cases where MySleeve is not available or uncomfortable to use.

3. Clinician InterviewsRequirements derived from the clinician interviews [1]

• 3.1 An individual clinician should not be responsible for interpreting data fromnon-medical devices; too little time is available and no qualified expertise in thatarea.

• 3.2 The ecosystem should position itself as a decision support system on the pa-tient’s portal; automated alerts to clinicians needs to be investigated due to variedopinions on the matter within the study.

• 3.3 Measurements being taken, from devices, that depict the patient’s activities ofdaily living should be used for personalising the cardiac rehabilitation program andtherefor presented in a non-technical manner; will be investigated by user interfacedevelopment for the clinician portal.

4. App StudyRequirements derived from the experimental app study (Section 6)

D2.3 - Do CHANGE 7

• 4.1 Consolidate profile, and its settings, in a separate TabView for the Do CHANGEapp.

• 4.2 Within the buddies TabView, the primary interaction should be focussed onlinking to existing buddies. Adding new suggested buddies is a secondary featureand should be positioned as such.

• 4.3 The devices should either have a clear icon for the device listing or consolidatethe feature in the settings TabView.

5. Privacy StudyRequirements derived from the privacy study Section(4)

• To be defined after completion of Privacy Study.

D2.3 - Do CHANGE 8

3 CLINICAL PATHWAYS

3 Clinical pathways

3.1 Introduction

This section is a continuation of the Clinical Pathways Section in D2.2 [1]. As a recapitulation,the application of Process Mining within the Do CHANGE project supports the understandingof the hospital context, patients, clinicians, and processes, and explores the possibility ofintegrating Process Mining as a service within the Do CHANGE Ecosystem.

To date, two datasets are planned for analysis: STEMI and Cardiac Rehabilitation. The STEMIdataset has been received in February 2016 and is presented in the next subsection. Permissionfor the Cardiac Rehabilitation set needs to be granted; this is currently in request at ETZ .

3.2 Case: STEMI

Figure 1: STEMI Model (Activities: 40%, Paths: 0%)

D2.3 - Do CHANGE 9

3.2 Case: STEMI

The STEMI-dataset consisted of 292 unique cases (anonymised patients) with 18489 events;every patient has a unique pathway in this dataset. The events range from January 3, 2015to January 5, 2016. ETZ stores activities (e.g. nursing days) in different levels (columns inthe database) that provide different levels of detail. For simplicity, only one level has beenexported for analysis and the risk factors, where available, are included as well.

Figure 1 shows a simplified model of the STEMI-dataset generated by Disco [2]. Thetop part of the model shows a series of events that include: visit emergency room, stent,ECG, cardiac catheterisation, angioplasty, outpatient appointment. Due to the restrictedtimestamp, granularity of a day, multiple events on a single day cannot be chronologicallyordered. The order of events is determined by the insertion order in the system of ETZ .To provide a general model of the process this granularity is sufficient. However for moredetailed insights, a higher granularity is needed to determine, for example, the amount of timea patient spends in the ER or to compare the duration of similar events from different patients.

Risk factor Yes No Unknown

Smoking 107 124 61Drink alcohol 88 31 173Family history 91 111 90Diabetes 32 191 69Hypercholesterolaemia 76 137 79Hypertension 91 133 68Adiposity 69 150 73

Table 2: Risk factors in STEMI-dataset

Table 2 shows a simplification of risk factors within the STEMI-dataset. The smoking anddrink alcohol risk factors are simplified by removing the amount of drinking or smoking to Yesor No; in both parameters any drinking or smoking is considered as a Yes whereas patientsthat quit smoking are considered as No. Remarkable in this table is the amount of unknowns;these values are not present within the dataset and cannot be assumed to be either Yes or No.An attempt was made to discover clusters with combination of risk factors, to compare thepathways of those patients within either clusters. Unfortunately, no evident cluster definitionwas defined; probably due to the combination of relatively small number of cases and highernumber of parameters.

D2.3 - Do CHANGE 10

3 CLINICAL PATHWAYS

3.3 Discussion and next steps

The use of the STEMI-dataset provided the means to (partially) understand how the HIS isstructured; what type of data is collected and how this is shaped. The ’cardiac patients’,as they are considered within Do CHANGE , will be present in different subsets of theHIS (dots); like the STEMI and Cardiac Rehabilitation. For example, the Simon SchmidtPersona [1] would be part of the STEMI-dataset when arriving at the hospital’s emergencyroom and continue within the Cardiac Rehabilitation-dataset when enrolling for the cardiacrehabilitation programme.

The Do CHANGE Ecosystem positions itself following the cardiac rehabilitation track of thehospital, where present, thus models of how patients proceeded through the care pathwaycontributes to the overall understanding of the target population.

Considering the services provided by the Do CHANGE Ecosystem, process analysis of care path-ways within the hospital can contribute to the Business Intelligence (BI) of the hospital; betterinsights in how actual events are aligned to the protocol. For example, in the Netherlands,hospitals are rated based on the amount of days a patient is hospitalised after a cardiac event.A clear understanding of what resources (tests, staff, risk factors etc) influence the duration ofthe nursing days can provide the starting point for further investigation to reduce that amount.

When the Cardiac Rehabilitation-dataset is received similar models, as presented from theSTEMI-dataset, will be generated. In addition, more statistical overviews will be generatedrelevant to the cardiac rehabilitation.

D2.3 - Do CHANGE 11

4 Privacy Study

4.1 Introduction

The DoCHANGE ecosystem will aggregate both medical and non-medical data from existingproducts/services and newly developed products within the DoCHANGE project. The coreof the ecosystem is the users ability to determine who can access their data, with certaingranularity in defining the access, and providing transparency on the data collected fromthe user. However, to date, patient perspective on personal data management has notbeen taken into account. Generally, patients are not involved in discussions addressing theirpersonal (medical) information. While shared decision making and patient empowermentregarding disease management are showing favourable outcomes [3], patient empower-ment regarding data management is still understudied. In order to find out what patientspreferences are, performing focus groups with the targeted population is of utmost importance.

The purpose of the focus groups is to identify the patients perspective on personal data storageand privacy in a medical context. The discussions within the focus groups will progress fromcurrent privacy regulations to future scenarios. The future scenarios will include the imple-mentation of medical and non-medical devices either prescribed by their physician or initiatedby the patient. The concept of a Personal Data Store (PDS), a database that holds personalmedical and non-medical data, will be introduced to the participants. The observations fromthe focus groups can lead to design- and user-requirements for the DoCHANGE ecosystem.

4.2 Progress

Table 3 shows the current progress of the privacy study per location. The results of the studyare planned to be presented in D2.4.

Location Participants Progress

Netherlands (ETZ ) 19/24 Final session planned for end of August 2016

Spain (BSA ) 0/24 Expected end of September 2016

Taiwan (BTCD ) 0/24 Expected end of September 2016

Table 3: Privacy Study progress per country

4.3 Methodology

Focus Groups is a methodology often used to capture the opinions, feelings, and attitudesfrom a group of similar participants. In the case of this study, the end-user of the ecosystemis invited for this focus group. The setup of the session is as following:

D2.3 - Do CHANGE 12

4 PRIVACY STUDY

1. Introduction to the focus groups and Do CHANGE project (rules of focus groups).

2. Fill in demographics questionnaire with initial questions on privacy.

3. Introductory round by participants and moderator.

4. Topic 1: sharing of medical data.

5. Topic 2: storage of medical data.

6. Topic 3: transparency and accessibility of medical data.

7. Topic 4: use of medical or life-style devices.

Participants are encouraged to share their own experience with these topics. The order hasbeen defined by initially focusing on current issues -privacy is a hot topic in the last few years- and slowly moving to the future scenarios.

Sessions are recorded using a Zoom H6 with multiple Philips LFH 9172 omnidirectional mi-crophones daisy-chained for optimal sound quality. The recordings will be transcribed to thelocal language and afterwards translated into English for comparison with other countries.

4.4 Participant information

Inclusion criteria: age 18-75 years, newly diagnosed with CAD or HF, having, at least two ofthe following risk factors: smoking, positive family history, hypertension, increased cholesterol,diabetes, sedentary lifestyle, psychosocial risk factors. Patients should also have access to theInternet (and sufficient knowledge on using a personal computer or smartphone), and havesufficient knowledge of the local language. Additional inclusion criteria for HF patients onlyis to have a left ejection fraction of 35% and experience HF symptoms (e.g. shortness ofbreath, chest pain, exhaustion).

Exclusion criteria: significant cognitive impairments (e.g. dementia), patients who are on thewaiting list for heart transplantation, life expectancy <1 year, life threatening co-morbidities(e.g. cancers), with a history of psychiatric illness other than anxiety/depression, not havingaccess to internet, and patients with insufficient knowledge of the local language.

The pilot is being performed at ETZ ; BSA and BTCD will proceed afterwards. At ETZ ,patients will be approached for participation by their cardiologist who will also check thatthe inclusion criteria are met. Patients who respond favourably to study participation will beprovided with an informed consent letter which they are allowed to take home and sign in theirown pace.

4.5 Analysis

The transcripts will be reviewed independently by TUE and ETZ , and afterwards comparedto produce a single output document. The same procedure will be followed for the focus

D2.3 - Do CHANGE 13

4.6 Discussion

groups at BSA and BTCD . The review will focus on identifying basic ideas and components,categories, and trying to capture the general thoughts of patients on privacy. To accompanythe qualitative analyses, a text analysis will be performed to identify topics and sentiment; ashas been applied to the patient interviews in D2.2 [1].

4.6 Discussion

The digitalisation of health records, in combination with the sharing of medical data withother care providers, raises the issue of the patient’s privacy; where is data stored and who hasaccess? Some hospitals provide patients access to their health records such as the Mayo Clinic[4], and several Dutch hospitals as listed by ZorgvisieICT [5], but do not provide information,or manageability, of access. Unlike other, questionnaire-based studies [6], the method of FocusGroups triggers discussion between participants and enables them to reason their opinions andperspectives. The outcomes of this study will influence the granularity and default privacymanagement settings of the ecosystem.

D2.3 - Do CHANGE 14

5 DO SOMETHING DIFFERENT CARDIAC PROGRAMMES

5 Do Something Different Cardiac Programmes

5.1 Introduction

The Do CHANGE ecosystem changes lifestyle or behavioural risk factors for coronary heartdisease and hypertensive patients. As a behaviour change technique, Do Something Different(DSD) focusses on getting people to actually change small behaviours in their everyday livesand does not like many other behaviour change techniques focus on any aspect of thinking orcognition, knowledge or attitude. DSD delivers change prompts through small positive actionscalled Dos. These are delivered to the patient in one of several ways through the Care Portal,via SMS or email. There are two broad categories of Do:

Core Doswhich address the psychology of the person and the factors that often prevent healthychanges.

Responsive and Contextual Doswhich are related to the everyday context the person is in or which respond to nearreal-time sensor or wearable data.The responsive and contextual Dos will be consideredin Section 7 (Responsive DO’s Study).

The aim of all Do’s is:

• To override a persons inbuilt impulse to act habitually

• To help them break free from the gravitational pull of habits as they go about their day

• To remind them of the micro-behaviours they need if they are to live more healthily

5.2 Cardiac Do s

In Do CHANGE, DSD has produced 3 different programmes each of which is to get patients toadopt healthier lifestyles in ways that will benefit their condition.These are for those diagnosedwith either:

• Coronary Artery Disease

• Heart Failure

• Complex Hypertension

Each of these programmes provide DSD experiences that are bespoke or personalised tothe psychology of the individual. The Core Dos are determined separately for each patientbased on their DSD diagnostic data. This data is collected via the Care Portal or internetand consists of two types: their personal habits with respect to the problem areas/possiblelifestyle changes and their personal habits or personality.

D2.3 - Do CHANGE 15

5.2 Cardiac Do s

In terms of the 3 cardiovascular-related programmes, all are based on the same behaviouralpillars (as they are called in the DSD system). These are the habit areas we want to seeimprovement or changes in. There are 14 of these, as shown from the academic literature andfrom discussion with the cardiovascular experts in ETZ :

1. Diet

2. Staying informed

3. Activity

4. Healthy eating habits

5. Stress

6. Exercise

7. Relationships/Support

8. Connectedness

9. Health monitoring

10. Adherence to medication

11. Optimism/positive outlook

12. Smoking

13. Alcohol

14. Sleep

The first DSD diagnostic is the Habit Rater which measures these 14 areas via a self-reportinstrument. All the questions ask about the behaviours in terms of How often do you.... Theresponses are rated on a 1-100 scale.

Figure 2: Example Habit Rater Pillar 4: Healthy Eating Habits

D2.3 - Do CHANGE 16


There are questions for each pillar of the programme. Each possible answer on the Habit Rateris then linked to a Do that is designed to alter the habit (according to the DSD algorithms).For example, if a person does a habit only a little this will result in them being sent a differentDo, compared to if they answered sometimes, or a lot. The Do alternatives are different foreach of the 3 cardiovascular programmes. For example, the Heart Failure programme containsmore Dos relating to salt and water intake. The DSD system considers all the Habit Raterresponses and determines the appropriate habit change that is best suited to the individualpatient. Some of the Dos are common for all patients on a programme. These general Doshave the role of acclimatising the person to small simple habit changes and to get them usedto the idea of changing behaviour. They are also to provide a positive experience and are funto do.

Figure 3: Example message sent after Do

In some cases, messages are sent after a Do. These are to provide relevant information thatmight be helpful or motivating in relation to the Do. For example, they may relate to thesalt content of foods or the benefits of activity. The second diagnostic that shapes the Dossent to patients relate to their personality. Different types of people need to received differenttypes of Do to get maximum effect. The Dos relating to personality are called Expanders.

The Behaviour Rater measures 30 behaviours according to 15 different dimensions. These 15dimensions are all different (as shown by statistical tests), even though some appear to clustertogether. The idea is that DSD programme expand or increase behavioural flexibility generally.

D2.3 - Do CHANGE 17

5.2 Cardiac Do s

The purpose of the Expander Dos is:

• to encourage behavioural flexibility

• they are based on a behaviour the person didnt select in the Behaviour Rater

• Research shows that a wider behavioural repertoire leads to new possibilities and bene-ficial change

From all the data and based on our user research we have made each of the 3 DSD cardio-vascular programmes 11 weeks long and consisting of 30 Do’s (+ a starter Do)All 3 programmes have a mix of Expanders, Personalised habits breakers, General Dos andmessages. There are:

• 5 General Dos

• 10 Personalised Dos

• 5 Expanders

• 5 Messages

We also measure coping, and depression and anxiety because the DSD programmes havebeen shown to really improve these often co-morbid conditions. Patients will also have theopportunity to record their experiences and share them (should they choose to) in a socialmedia Do Zone. Social sharing can be valuable for some people and some also learn newoptions and alternatives from such a platform.

Figure 4: Screenshot of Do Zone

D2.3 - Do CHANGE 18


5.3 Responsive Do’s

5.3.1 Introduction

In DoCHANGE, we adopt the use of the Do Something Different program to aid behaviourchange and ultimately improve 1) the compliance to the lifestyle recommendations for HFor hypertensive patients and 2) their quality of life. The do something different interventionprogram is generated based on static diagnostics and does not put into account the reallife context or changes wherein the doer of the program coexists. This brings us to thedevelopment the responsive or contextual (RC) do program. With the RC program, we adoptthe use of real-time or near-real-time sensor data to understand emerging behaviours and itsrelated contexts so as to generate DO’s that are tailored to the doer’s current situation. Thework in developing the RC-DO’s program in DoCHANGE focuses on collecting behaviouralinformation on three macro areas of habits—diet, physical activity, and social connectivity.Smoking habits is another relevant macro area for the target patients. In the next sectionshows a list of data sources selected for DoCHANGE. The data must then be abstracted intoprincipal variables used to generate the RC-DO’s. The DO’s generated thereof should beconsidered as appropriate to the Doer and proximal to the target behaviour. In this section,we present the data sources selected for DoCHANGE, data interpretations variables, and adescription of location-based analysis developed.

5.3.2 Data Sources

Several types of data are used to generate RC-DO’s. The data is collected from differentdevices; each contributes to generating a behavioural profile for the individual.

o Location – by Moves App

– Location

– Steps

o Activity – by FitBit

– Heart rate

– Steps

o Cooking – by SAL (COOKiT)

– Sodium concentration

– Food temperature

– Motion

– Used or not used

– Experiential sampling

o Drinking – by MySleeve

D2.3 - Do CHANGE 19


– Time of day

– Amount consumed

– Active/ not active

– Drinking motion

o Sleep – by Beddit

– Sleep quality

– Time factors

5.3.3 Data Interpretation

The goal of the data interpretation is to understand the individual′s habituality. This is fun-damental to the Do Something Different behavioural methodology. Analysis of habitualityconsists of two elements; the physical behaviour mostly derived from sensors, and the psycho-logical behaviour mostly derived from the pre-diagnostics. In section 5.3.4 the first behaviouralinterpretations are made, focussing on the physical behaviour derived from location based at-tributes.

Location-based attributesThe first layer of variables derived from the location-based attributes are:

• Percentage of the day moving

• Duration spent running/walking/cycling (physical movement)

• Current location

• Visited places (hotspots)

• Step counts

• Distance covered

• Time of leaving the place you slept

• Day similarities

• Routes travelled

• Spent a night out (not where person slept)

• Likelihood to going from one place to the next

• Doing something unusual

The second layer of interpretation constitutes:

• How active physically

• Variety or richness of behaviour

• Social opportunity

D2.3 - Do CHANGE 20


• Mood

• Connection to environment

SAL / COOKiTSAL is designed to facilitate healthy eating habit and enable the Doers to gain controlin preparing their meals. The following cooking variables are derived from SAL:

• Salinity (Na / K)

• Food Temperature

• Motion

• Used or not Used

In addition to the sensor data, the use of SAL will enable the system to trigger experientialsampling. With experiential sampling, the participant will receive targeted questions tolearn about the cooking context. A question can ask about how many people participatedin the cooking event. Through the use of the SAL, the following interpretations areobtainable:

• Adherence to program by the use of SAL

• Cooking with processed or fresh ingredients

• Social involvement

• Involvement in Cooking

• Planning of food

MySleeveMySleeve is designed to understand drinking behaviour of the user. The following datais obtainable from the device when in use:

• An estimation of the amount drunk

• Time of day of drinking

• Active or not active

• Drinking motion

First layer of interpretation:

• Change in the consumed volume

• Reduce craving (by better spreading)

• Drinking method (sip or gulp, speed of drinking)

D2.3 - Do CHANGE 21


5.3.4 Location-Based Analysis

The use of location-based attributes has been the logical starting point in analysingparticipant′s global behaviour and contexts. We adopt the use of the smartphone to track thelocation of participants through their daily lives. Location tracking is a rich source of informa-tion, however, poses a challenging dataset to analyse and semantically represent. Followingthe participants through their everyday life as they move around different locations can tellabout their physical activity patterns and their social opportunities.

Tool – the Moves AppTo locate and follow the participants we adopt a dedicated app called Moves. Weswitched to using Moves after our initial choice of using Google Location Data. Similar tousing Google location services, Moves is developed to track users location and movement.Additionally, Moves implements an easy to use interface to authorise third-party access totheir information in a secure way and provides a set of analytics measures. We developedthe infrastructure to enable participants to authorise our access rights, consume andanalyse their data. The dataset obtainable are: place visited, step counts, distancecovered, the source of transportation, etc. With Google services, we developed a set ofalgorithms to process the location attributes. These algorithms are now supplementedwith analytics provided by the Moves App.

Data OrganisationLocation data is constantly collected to follow users virtually at runtime, but meaningfulinformation can only be extracted if the location attributes are collected and analysedover time. Organising data over different periods of time is useful for the data analysis,also for when the participant just entered the program. Depending on the informationto extract, the minimum duration to collect data can vary. Whenever new informationbecomes available, we interpret it in the context of the earlier events of the day, the pastweek, the past month, etc. Given that the DO program is aimed to adapt new lifestylechanges, a ceiling of three (3) months to trace back is considered appropriate.

Algorithms Similar daysResearch shows that the feeling of living the same day over and over is stronglycorrelated to visiting the same locations, in the same order, every day. In [7], theauthors argue that similar days can be inferred by comparing location that is similar(not semantically but geographically). The geographic location is a fundamentalfactor: visiting a place in your neighbour is not always perceived as visiting anequivalent place when you are on vacation for example. It considers where theplaces are located, rather than their semantic meaning. Days are also consideredfrom 4 am to 4 am, which is closer to how people perceive different days. Figure 5shows the comparison of three days based on location attributes. The first twodays are similar while the third is different due to the new location added to thepattern.

D2.3 - Do CHANGE 22


Figure 5: Different days compared. The algorithm classifies the first two days as similar andthe third as different from the previous two, based on the fact that the user visited an extralocation.

Place sleptA second algorithm can extract information on where you slept and when you startyour day by leaving said place. See Figure 6.

Figure 6: The user left the place he/she slept at sensible different times of the day.

Places visitedOther solutions consider the number of places (and new places) participants visitover a period. With this variable, we aim to deliver a do that will expand theplaces visited. We can also extract information on the source of transportationthat participants chose for moving around or the paths they take every day toconnect the places they visit frequently.

D2.3 - Do CHANGE 23

6 App Study

6.1 Introduction

Within WP4, as preparation for the clinical trials, a Do CHANGE mobile application will bebuilt. The intermediate evaluations, this study and EDL: Responsive DO’s 7 , are facilitatedwithin WP2. The App Study addresses the intuitive of the interface whilst performing severalbasic tasks. The study is setup as an explorative quick iteration in the user interface; severalmethods are combined to facilitate the study.

6.2 Methodology

The goal of the study is to identify interaction difficulties for potential users. A commonapproach is to set up a Wizard of Oz-prototype where participants cannot differentiate froma fully-functioning setup [8]; these are however costly because participants need to be invitedto a controlled environment. Within a quantitative study, a larger sample size will providemore substantiated outcomes concerning trends. To facilitate a larger population a mock-up application, limited to executing pre-defined tasks, was designed using Just-In-Mind [9] byONMI . Similar applications have been investigated but JIM enables exporting the mockup to areadable webpage without proprietary software on the client (participant) computer. Examplesof scenarios within the mockup are shown in Figure 7.

Figure 7: Scenarios of App Study generated by Just In Mind

D2.3 - Do CHANGE 24

6 APP STUDY

Besides providing basic demographics (age group and gender), participants are asked to per-form the following tasks:

1. Upload a picture from your camera roll. Use a family picture for this one.

2. Keep a record of what you eat. Upload a picture of your last meal.

3. You have received a new DO! Check it out and then mark it as completed.

4. Change your profile settings so buddies can find you.

5. Text one of your Buddies on your Buddies list.

6. Add a new device to your Devices list.

7. Check your Liquid intake data.

After completing the tasks, participants are asked to provide written feedback for thequalitative analysis.

The mockup is hosted on TUE -servers running a dedicated Virtual Machine for the AppStudy. A Node.js backend serves the static webpages for the study. A JQuery -script isadded to the client to setup a secure websocket connection to the back-end and push allmousedown-events to the server. These events are appended with a timestamp, the Ip-Address,unique session identifier; both identifiers are needed to differentiate participants on the sameexternal Ip-Address. The connections are encrypted using the Secure Sockets Layer (SSL)protocol. Events generated by participants (over 5000) are stored in a MongoDB-collection.All consortium partners have been asked to share the study (https://klikker.id.tue.nl) with10-20 people to achieve the 100-200 participants in total.


The demographics scene of the mockup provides the age-group and gender of the partici-pants. The MongoDB-collection storing the events generated by the study was queried forall Demographics Submitted events; including identifiers. After removing duplicate entries,based on the identifiers, 160 participants submitted demographics. In order to excludeparticipants who did not commit to participating, demographics of participants that com-pleted Task 2 are used in Figure 8; this resulted in a reduction to 94 participants included inthe demographics overview. Figure 8 shows a bias towards males between the age of 18 and 45.

D2.3 - Do CHANGE 25


0 10 20 30 40 50 60

18-25

26-45

45-60

61-75

75+

Demographics for participants completing Task 2

female

male

Figure 8: Demographics represented in stacked bar chart

A Python-script was written to trace the country of origin based on the Ip-Address usingthe IpInfoDb.com-API [REF]. The resulting list of countries was converted to a frequencyper country. Using the Folium-package [10] for Python, a world-view was annotated withgeographic participant data presented in Figure 9. The figure shows a bias in the Netherlandswhich can be explained by 4 out of 10 consortium partners originating from the Netherlands.

Figure 9: MapView of participant geo-distribution

D2.3 - Do CHANGE 26

6 APP STUDY

6.4 Analysis

The events recorded are imported using Disco [2] ; non task-related events are filtered. Figure10 shows the model resulting after filtering non-frequent activities and paths to visualise thecommon pathways. The red line shows the correct route and circle represent bottlenecks inthe model where < 50 participants followed that route. Bottlenecks are present in tasks 4,5,and 6. A larger model is available in Appendix X.

242 secs

42 secs

588.1 secs

653 secs

388.5 secs

44.5 secs

75 secs

17.9 secs

773 secs

21.5 secs

763 secs

353 secs

75 secs

623 secs

311 secs

225.5 secs

72 secs

2012.5 secs

524.5 secs

213.5 secs

652.9 secs

46.4 secs

805 secs

52 secs

41 secs

11 secs

16 secs

19.9 secs

424 secs

64 secs

13.1 secs

63.9 secs

633 secs

92 secs

52.9 secs

673.9 secs

25.9 secs

51.1 secs

613 secs

12 secs

14.9 secs

792.9 secs

334 secs

14 secs

413.9 secs

91 secs

39 secs

5986 millis

511 secs

23 secs

14.1 secs

362 secs

682.9 secs

34 secs

63 secs

33 secs

823 secs

21.5 secs

52 secs

12 secs

223 millis

51.9 secs

93 secs

84.5 secs

784 secs

273 secs

231 secs

36.1 secs

12 secs

23.5 secs

1055 secs

203 secs

633 secs

373 secs

304 secs

21.5 secs

824 secs

342 secs

43 secs

313 secs

11 secs

164 secs

4998 millis

15 secs

802.9 secs

76 secs

683 secs

44.6 secs

11 secs

42 secs

32 secs

33 secs

624 secs

12 secs

813 secs

47 secs

53 secs

57 secs

285 secs

759.9 secs

11.9 secs

723 secs

42 secs

35 secs

13 secs

663 secs

182 secs

344 secs

824 secs

12 secs

229 millis

43 secs

11.1 secs

792 secs

514 secs

62 secs

211 secs

52 secs

111

314

48

rtr-s-btn_START_T1_0160 (instant)

rtr-s-btn_ADD_PIC_170 (instant)

rtr-s-btn_FAMILY_PIC_095 (instant)

rtr-s-btn_T1_COMPLETION_086 (instant)

rtr-s-btn_NEXT_TO_T2_094 (instant)


rtr-s-btn_ADD_PIC_0149 (instant)

rtr-s-btn_PASTA_PIC_097 (instant)

rtr-s-btn_T2_ANALYSE_086 (instant)




rtr-s-btn_NEW_DO_096 (instant)




rtr-s-tab_settings_0134 (instant)

rtr-s-toggle_T4_COMPLETION_092 (instant)



rtr-s-tab_BUDDIES_094 (instant)

rtr-s-btn_BUDDY_079 (instant)




rtr-s-tab_devices_090 (instant)

rtr-s-btn_ADD_DEVICE_072 (instant)



rtr-s-btn_WATER_075 (instant)

rtr-s-btn_FINSIH_TEST_067 (instant)

rtr-s-btn_yesterday_010 (instant)

rtr-s-btn_DSD_Notification_06 (instant)

rtr-s-btn_BACK_TO_INTRO_066 (instant)

s-bg_buddies6 (instant)

rtr-s-btn_NOT_BUDDIES_YET_2_014 (instant)

rtr-s-btn_BUDDY_HIDDEN_04 (instant)

rtr-s-btn_skip_task_063 (instant)

rtr-s-btn_cancel_050 (instant)

rtr-s-btn_skip_025 (instant)

s-t3_dash9 (instant)

s-bg_settings15 (instant)

rtr-s-tab_home_01 (instant)

s-bg_settings_25 (instant)

rtr-s-btn_activity_02 (instant)

rtr-s-SUBMITED_027 (instant)

rtr-s-btn_BACK_06 (instant)

rtr-s-btn_back_03 (instant)

rtr-s-tab_buddies_062 (instant)

rtr-s-btn_FOOD_PIC_017 (instant)

s-bg_pic_family14 (instant)

rtr-s-btn_NORMAL_PIC_016 (instant)


s-bg_buddy_tim_26 (instant)

rtr-s-btn_PROFILE_023 (instant)

rtr-s-btn_list_of_dos_05 (instant)

rtr-s-btn_back_to_camera_04 (instant)

rtr-s-btn_DO_022 (instant)

rtr-s-T1_INTRO_03 (instant)

rtr-s-btn_quote_06 (instant)

s-bg_pasta27 (instant)


rtr-s-btn_FINSIH_TEST_16 (instant)

s-bg_devices4 (instant)

rtr-s-btn_analyse_02 (instant)

rtr-s-btn_cancel_1_04 (instant)

rtr-s-btn_post_01 (instant)

rtr-s-btn_shooter_04 (instant)


rtr-s-text_bubble_02 (instant)

s-bg_buddy_Tim9 (instant)

s-btn_NEXT_TO_T61 (instant)

rtr-s-THANKS_04 (instant)

rtr-s-btn_home_01 (instant)


s-btn_START_T42 (instant)

Figure 10: Event-, path-, and activity-filtered model of App Study

D2.3 - Do CHANGE 27

6.5 Results

6.5 Results

The circles in Figure 10 show bottlenecks in the following tasks:

Task 4: Change your profile settings so buddies can find youAlthough the majority followed the correct activity, going to settings to change, thesecond largest group searched for the settings in the buddies panel. This shows unclarityin how to change the profile settings.

Task 5: Text one of your Buddies on your Buddies listThe majority chose a buddy that was not listed as a friend yet; the top of the list. Tostimulate the social experience from the application, a suggested friend list is put on topof the screen. Considering that the largest group chose the first item on the list, it canbe concluded that the suggested buddies disrupts the user flow.

Task 6: Add a new device to your Devices listAs stated in the qualitative feedback, and low number of participants choosing thecorrect event, the intended device button in the interface did not identify itself as such.

Appropriate changes, according to the results, are included as requirements (Section 2).

6.6 Discussion

The methodology used to facilitate the insights was fitting for the short-time exploration;results clearly identify issues with the current design of the UI. The initially defined sample size,from 100-200, should be changed to 150+; considering that a large portion of the participantsdid not complete or pass the second task. The usage of the demographics visualisation inboth gender/age-group and geolocation provides a good overview of the bias in the samplepopulation. The initial target population, CVD patients, would have provided a strongerrelation to the features of the application; due to time constraints it was not possible toapproach 100-200 CVD patients. However the intent of the study was not to evaluate thefeatures of the application but the intuitiveness of the interface. Tracking general usage of theapplication, by recording events, proved to be very insightful in investigating UI improvements.Therefore, this approach will be included in the EDL: Responsive DOs (Section 7) study. Aquick iteration on the design, leading to the development of the application, is appropriate forthe co-design approach of Work Package 2; feedback from the users can be included during, oreven before, the development. The challenge in choosing the content of the study lies withindefining the scope of topics to be investigated. In this case, using simple tasks, provided theresults that are needed for this phase of the development.

D2.3 - Do CHANGE 28

7 EDL: RESPONSIVE DO’S

7 EDL: Responsive Do’s

7.1 Introduction

7.1.1 Experiential Design Landscapes

”Experiential Design Landscapes (EDL): a method where an infrastructure is createdthat, on one hand, stimulates the creation of new, disruptive, propositions in a semi-open environment where new these new propositions are used as agents to facilitate newand emerging behaviour and that, in parallel, enables the detailed analysis of the emerg-ing data patterns as a source of inspiration for the design of future services and products.” [11]

The EDL methodology enables researchers and designers to develop and iterate proposedbehaviour change probes. Within the Do CHANGE project, the proposed behaviour changeis a collection of tools developed within the project and commercially available products.Individual tools are tested in a controlled environment and conceptually validated by patientinterviews. The Controlled Environment Study in Work Package 6 will include multiple toolsbeing used by 10 participants at the Smart-Home of SMH .

7.1.2 Responsive and Contextual Do’s

”Responsive and Contextual Do’s are related to the everyday context the person is in or whichrespond to near real-time sensor or wearable data.”

Defining responsive and contextual Do’s requires contextual information obtained fromvarious sensors. Multiple data streams are investigated -data fusion- to identify triggers thatcorrespond with a pre-defined personal do. The identification of triggers require real-lifedatasets for analyses and creation of algorithms that can monitor user behaviour.

7.1.3 EDL meets Responsive Do’s

The EDL: Responsive Do’s study will focus on development the foundation of the responsiveDo’s, validate usage of tools, and serve as a co-design method to define the Do CHANGEmobile application. The setup of the study, and methodology, enables observing of real-lifeuse-cases and allows to act upon them by implementing changes in use and design (for mobile)during the study.

7.2 Study design

The study will invite 25 volunteers, referred to participants from now on, that will participatein the study for at least 3 months. Each participant will be given a Fitbit Charge HR [12],Beddit [13], and a development mobile application will be installed on their mobiles phones(Android or iOS). Participants are asked to used the Fitbit and Beddit as they would’vebought it themselves; using the dedicated mobile applications. The 3rd-party data aggregator,

D2.3 - Do CHANGE 29

7.3 Next Steps

Consume, will provide access to the participant’s data generated by the devices. The mobileapplication will receive data from the Meteor back-end, called Synergy, running on the TUEserver. The framework used for the mobile application is React-Native [14]. At the start ofthe study a Minimum Viable Product (MVP) will provided with basic functionality to performthe study; connectivity, chat with researchers, and basic data visualisations. Throughout thestudy more features will be added, and developed, according to the feedback from participantsand required functionality for the application.

Randomised participants will receive MySleeve, SAL, and Horus (as a mobile service). Thesefeatures will be enabled on the participant’s device and asked to use it accordingly.

The intended start of the study is October 2016 and will last until December 2016 (3 months),although the study duration can be extended if both participant and researcher agree tocontinue. The protocol is currently under progress and the research team is assembled withmembers within the consortium. Participants will be contacted in September 2016.

Short examples of the study is as following:

• Participant X has been using devices for a week and the research team identifies a fixedbehaviour. Through the chat functionality the team can ask for more information onsaid behaviour.

• Participant X’s activity is consistently dropping during the weekend (sedentary lifestyle).The research team decides to send a contextual do to stimulate an activity.

• Participant X is using SAL during cooking. SAL has not been used for several days sothe team can investigate why it has not been used. In case of non-use due to technicalor usability issues this can be used as input for further development. If the person hasnot used SAL because they have not been cooking themselves, a do can be sent lateron to encourage participant X to cook.

7.3 Next Steps

As preparation to the study several tasks need to be performed:

ProtocolThe protocol of the study needs to include, informed consent, inclusion/exclusion criteria,state the objectives of the study, and -specifically for this methodology- guidelines onhow to interact with participants and how to implement changes in the intervention. Thelatter will include the scope of changes permitted; ranging from changing features or UIfor the application, the amount of notifications to be sent daily, and how much effortcan be asked from the participant to prevent them from discontinuing their participationin the study.

Development environmentsIn a traditional study, the development of the artefact is finished before starting the study.

D2.3 - Do CHANGE 30

7 EDL: RESPONSIVE DO’S

During the EDL: Responsive Do’s study development will continue. This requires settingup multiple environments for development, staging, and production in both backend andmobile application. In addition, a feature toggle per participant needs to be defined toenable features for specific participants.

MVPThe feature list for the Minimum Viable Product needs to be defined and developed.Internal testing on a range of devices, with different versions of OSs, will be performed.

D2.3 - Do CHANGE 31

8 Discussion

The results from the first cycle of Work Package 2 provided the foundation for understandingthe end-users; interviews, personas, and use-cases. The second cycle is focussed more oninvestigating the integration of Do CHANGE in the cardiac population; privacy study, appstudy, and EDL: responsive Do’s.

Evident from the patient interviews, different views on the topic of privacy within the healthcontext are expected. This raises the challenge of flexibility within the design of a healthecosystem; it should be adoptable for different contexts or cultures or provide differentimplementations.

The EDL: responsive Do’s study will provide insight in the actual use of different devices andenable to perform iterations before using them in the clinical studies.

The D2.4 deliverable, concluding the second cycle, will report the results of the studies ad-dressed in this deliverable and include video scenarios of the tools in-use.

D2.3 - Do CHANGE 32

REFERENCES

References

[1] M. Wetzels and P. Peters, “D2 . 2 : First-cycle completion report including integrateduse-cases,” 2016.

[2] Fluxicon, “Disco,” 2015.

[3] D. Stacey, C. L. Bennett, M. J. Barry, N. F. Col, K. B. Eden, M. Holmes-Rovner,H. Llewellyn-Thomas, A. Lyddiatt, F. Legare, and R. Thomson, “Decision aids for peoplefacing health treatment or screening decisions.,” The Cochrane database of systematicreviews, no. 10, p. CD001431, 2011.

[4] Mayo Clinic Staff, “Personal health record: A tool for managing your health,” 2014.

[5] ZorgvisieICT, “Overzicht patientportalen ziekenhuizen,” 2015.

[6] A. Roosendaal, O. Nieuwenhuis, M. Ooms, A. Bouman-Eijs, and N. Huijboom, “Priva-cybeleving op het internet in Nederland,” tech. rep., TNO, 2015.

[7] J. Biagioni, James and Krumm, “Days of our lives: Assessing day similarity from locationtraces,” in International Conference on User Modeling, Adaptation, and Personalization,pp. 89–101, Springer, 2013.

[8] B. Hannington and B. Martin, Universal Methods of Design: 100 Ways to ResearchComplex Problems, Develop Innovative Ideas, and Design Effective Solutions. RockportPublishers, february 1 ed., 2012.

[9] Justinmind, “JustInMind.”

[10] R. Story, “Folium,” 2015.

[11] S. H. V. Gent, C. J. P. G. Megens, M. M. R. Peeters, C. C. M. Hummels, and Y. Lu,“Experiential Design Landscapes as a design tool for market research of disruptive intelli-gent systems,” 1st Cambridge Academic Design Management Conference, no. September,pp. 1 – 10, 2011.

[12] Fitbit, “Fitbit Charge HR.”

[13] Beddit, “Beddit.”

[14] Facebook, “React-Native,” 2016.

D2.3 - Do CHANGE 33

project #643735 · 1.3 subtasks wp2 1.3 subtasks wp2 parallel to the iterative, cyclic process...

Documents