PROJECT i-PROGNOSIS: Intelligent Parkinson early detection guiding novel supportive interventions
GRANT AGREEMENT No.
690494
D2.1 - First version of user requirements analysis
CONTRACTUAL SUBMISSION DELIVERABLE VERSION DATE
June 2016 4.0
ACTUAL SUBMISSION DATE MAIN AUTHOR(S)
June 2016 Alexandra Rizos (KCL) Stelios Hadjidimitriou (AUTH)
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 690494.
i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
GRANT AGREEMENT No. 690494 PROJECT ACRONYM i-PROGNOSIS
PROJECT FULL TITLE Intelligent Parkinson early detection guiding novel supportive interventions
Type Of Action Research & Innovation Action (RIA) Topic H2020-PHC-21-2015 - Advancing active and healthy ageing with ICT: Early risk detection and intervention Start Of Project 1 February 2016 Duration 48 months Project URL www.i-prognosis.eu EU Project Officer Ramón Sanmartín Sola
DELIVERABLE TITLE First version of user requirements analysis DELIVERABLE No. D2.1 Deliverable Version 4.0 Deliverable Filename i-PROGNOSIS-690494_D2.1.docx Nature Of Deliverable R (Report) Dissemination Level PU (Public) Number Of Pages 210 Work Package WP2 - User Requirements and Technical Specifications Partner Responsible KCL Author(s) Alexandra Rizos (KCL), Dhaval Trivedi (KCL), Stelios Hadjidimitriou (AUTH), Vasileios Charisis (AUTH), Konstantinos Kyritsis (AUTH), Evdokimos Konstantinidis (AUTH), Leontios Hadjileontiadis (AUTH), Anastasios Delopoulos (AUTH), Fotis Karayiannis (MICROSOFT), Michael Stadtschnitzer (FRAUNHOFER), Alexander Esser (FRAUNHOFER), Nikos Grammalidis (CERTH), Kosmas Dimitropoulos (CERTH), Julia Wadoux (AGE), Nathalie De Craecker (AGE), Peter Fagerberg (KI), Ioannis Ioakeimidis (KI), Hugo Plácido da Silva (PLUX), Lisa Klingelhöfer (TUD), Sofia Balula Dias (FMH) Editor Leontios Hadjileontiadis (AUTH)
ABSTRACT The main purpose of this deliverable is to present the user requirements along with the methodological i-PROGNOSIS-690494_D2.1.docx p. 2/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
framework applied towards their identification. The bases for the user requirements identification were face-to-face sessions, focus groups and the large scale i-PROGNOSIS Web-survey. In the direction of efficient user requirements identification and i- PROGNOSIS components development, usage scenarios and the related business processes that cover the majority of actions that the stakeholders of i-PROGNOSIS can perform, are presented. Moreover, this deliverable includes state-of-the-art analysis regarding technology-based approaches similar to the i-PROGNOSIS focus areas against Parkinson’s disease. In the end, 122 functional and non-functional requirements were identified and are expected to be updated based on the spiral development model of i- PROGNOSIS.
KEYWORDS Business process; Focus group; Functional / Non- functional requirement; Questionnaire; State-of-the- art; Statistical analysis; UML; Usage scenarios; User requirement; Web survey;
i-PROGNOSIS-690494_D2.1.docx p. 3/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
SIGNATURES
WRITTEN BY RESPONSIBILITY - DATE COMPANY
Alexandra Rizos Main author 1 - KCL 6/10/2016
Stelios Hadjidimitriou Main author 2 - 6/17/2016 AUTH
REVIEWED BY
Fotis Karayiannis Internal Reviewer 1 - 6/25/2016 MICROSOFT
Anastasios Delopoulos Internal Reviewer 2 - 6/27/2016 AUTH
APPROVED BY
Leontios Hadjileontiadis Project Coordinator - 6/30/2016 AUTH
i-PROGNOSIS-690494_D2.1.docx p. 4/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
TABLE OF CONTENTS
LIST OF MAIN ABBREVIATIONS ...... 7 1 EXECUTIVE SUMMARY ...... 8 2 INTRODUCTION ...... 9 2.1 PURPOSE AND STRUCTURE OF DOCUMENT ...... 9 2.2 THE ACTIVE AND HEALTHY AGEING CONCEPT ...... 10 2.3 BRIEF INTRODUCTION TO THE I-PROGNOSIS PROJECT ...... 12 2.4 FOCUS ON TASK 2.1 ...... 14 3 STATE-OF-THE-ART ...... 15 3.1 CONVENTIONAL PD DIAGNOSIS AND INTERVENTIONS ...... 15 3.1.1 Introduction ...... 15 3.1.2 Diagnosis ...... 17 3.1.3 Interventions ...... 17 3.2 ASSISTED LIVING TECH NOLOGIES ...... 18 3.2.1 Introduction ...... 18 3.2.2 Devices and sensors ...... 19 3.3 TECHNOLOGY-BASED APPROACHES RELATED TO I-PROGNOSIS FOCUS AREAS ...... 20 3.3.1 Voice analysis ...... 21 3.3.2 Gait analysis ...... 22 3.3.3 Tremor analysis ...... 25 3.3.4 Typing pattern and handwriting analysis...... 27 3.3.5 Facial expression information from photos ...... 28 3.3.6 Text sentiment analysis ...... 29 3.3.7 Exploratory walkability ...... 30 3.3.8 Sleep status evaluation ...... 31 3.3.9 Heart rate variability - ECG analysis ...... 33 3.3.10 Bowel sound analysis ...... 34 3.3.11 Food intake curve ...... 37 3.3.12 Body and hand gestures ...... 38 3.3.13 Serious games ...... 39 4 OVERALL PROCESS FOR THE IDENTIFICATION OF USER REQUIREMENTS ...... 41 4.1 AIMS AND OBJECTIVE ...... 41 4.2 THE GLOSSARY ...... 42 4.2.1 Glossary design ...... 42 4.2.2 Glossary realisation ...... 42 4.3 CONSORTIUM FACE-TO-FACE SESSIONS ...... 42 4.4 FOCUS GROUPS ...... 44 4.4.1 Design of questionnaires...... 44 i-PROGNOSIS-690494_D2.1.docx p. 5/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
4.4.2 Focus groups set up and organisation ...... 44 4.5 WEB SURVEYS ...... 46 4.5.1 Design of Web questionnaires ...... 46 4.5.2 Realisation and dissemination...... 47 4.6 ANALYSIS AXES ...... 48 4.7 COMPLEMENTARY INFORMATION FROM EUROBAROMETERS ...... 48 5 RESULTS ...... 49 5.1 FOCUS GROUPS OUTCOMES ...... 49 5.2 WEB SURVEYS RESULTS ...... 51 6 USAGE SCENARIOS & BUSINESS PROCESSES ...... 69 6.1 INTRODUCTION ...... 69 6.2 DEFINITION OF ACTORS AND SYSTEM COMPONENTS ...... 69 6.2.1 Actors ...... 69 6.2.2 System components ...... 70 6.3 FIRST STAGE OF PARKINSON'S DISEASE DETECTION ...... 77 6.3.1 Usage scenario & UML use case diagram ...... 77 6.3.2 Business processes ...... 81 6.4 SECOND VERSION OF PARKINSON'S DISEASE DE TECTION ...... 91 6.4.1 Usage scenario & UML use case diagram ...... 91 6.4.2 Business processes ...... 95 6.5 SUPPORTIVE INTERVENTIONS ...... 101 6.5.1 Usage scenario & UML use case diagram ...... 101 6.5.2 Business processes ...... 107 7 FIRST VERSION OF IDENTIFIED USER REQUIREMENTS ...... 130 7.1 FUNCTIONAL REQUIREMENTS ...... 130 7.2 NON-FUNCTIONAL REQUIREMENTS ...... 170 8 DISCUSSION AND CONCLUSIONS ...... 177 REFERENCES ...... 179 APPENDIX I - FOCUS GROUPS QUESTIONNAIRE ...... 187 APPENDIX II - WEB QUESTIONNAIRE LINKS ...... 200 APPENDIX III - GUIDELINES FOR INTERVIEWERS ...... 201 APPENDIX IV - FOCUS GROUPS DETAILED OUTCOMES ...... 204 KCL FOCUS GROUPS ...... 204 TUD FOCUS GROUPS ...... 206 AUTH FOCUS GROUPS ...... 207 AGE INTERVIEWS ...... 209
i-PROGNOSIS-690494_D2.1.docx p. 6/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
LIST OF MAIN ABBREVIATIONS
AHA Active and healthy ageing ALS Assistive living services ALT Assistive living technology BP Business process CEM Consortium experts' meeting DATSCAN Dopamine Transporter Scan DoA Description of Action EC European Commission ECG Electrocardiogram EIP European Innovation Partnership FAQ Frequently asked questions FGO Focus group observation FR Functional requirement GRGI Gait rhythmic guidance intervention HCP Health care professional ICT Information and communications technology IMU Inertial measurement unit NFR Non-functional requirement PD Parkinson's disease PET Positron emission tomography PGS Personalised game suite PTSD Post-traumatic stress disorder QALY Quality-adjusted life-year SoA State-of-the-Art TNI Targeted Nocturnal intervention UI User interface UML Unified modelling language UPDRS Unified Parkinson Disease Rating Scale US Usage scenario WO Web survey observation VEI Voice enhancement intervention WHO Word Health Organisation
i-PROGNOSIS-690494_D2.1.docx p. 7/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
1 EXECUTIVE SUMMARY
Task 2.1 entitled “Definition of user requirements” is to define user requirements and usability issues for the i-PROGNOSIS application. KCL is the Task 2.1 leader and chief editor of Task 2.1 deliverables. Deliverable D2.1 – First version of user requirements analysis provides a first version of the methodology applied towards the identification of user requirements along with the identified requirements. Moreover, it presents usage scenarios and the related business processes that alleviated the user requirements identification, along with state-of-the-art analysis regarding technology-based approaches against Parkinson’s disease (PD).
In order to identify the user requirements and usability issues, a series of steps were followed. As a starting point, KCL and relevant partners gathered pertinent data, so as to then design a final paper-based user requirement questionnaire that was used as an acquisition means in four focus groups. Then, the information gathered form the latter, informed a Web-based questionnaire that was widely disseminated and based on this Web survey and the idendified usage senarios and business processes the final user requirements were identified and classified to functional and non-functional ones. Ultimately, the i-PROGNOSIS system will be developed according to the user’s needs, thus all means of acquisition of the user requirement had to constitute a reference guide for the development of the different functions of the i-PROGNOSIS ecosystem. KCL and all partners accomplished Task 2.1 through a variety of activities and decisions as detailed below:
Face-to-face focus groups by clinical partners to guide the structure and content of the paper-based questionnaire; Review of the information from the focus groups relevant to the costruction of the questionnaire; Development and prioritisation of a list of potential questions that will satisfy the information requirements; Determination of the types of questions to be asked, decision on the specific wording of each question and assessment of each potential question; Determination of the structure of the questionnaire; Evaluation of the questionnaire and compilation of the received feedback and comments into one document ready for conversion to Web-survey by the technical partners; Web-based questionnaire realisation and dissemination to large numbers of relevant repsondents by clinical and all other partners; Thorough analysis of the Web-survey data informing the definition of usage scenarios and business processes; Each identified requirement was classified and qualified with respect to its importance (functional and non-functional), development risk, development priority and clinical value; Accumulation of relevant information and formation of Unified Modelling Language (UML) use case diagrams.
The starting point of the basis for the identification of user requirements was recognised and set by the i-PROGNOSIS consortium clinical and ICT experts through i-PROGNOSIS-690494_D2.1.docx p. 8/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
face-to-face sessions. As mentioned above, requirements derived from this procedure were further refined by the focus groups' observations and the results of the i-PROGNOSIS Web survey. The latter had a triple role: a) to disseminate user requirements directly from a large population belonging to the target groups (healthy older than 40 years old, PD patients and PD experts), b) to validate or shape certain technical specifications of the i-PROGNOSIS components, and, and c) collaterally and early disseminate the project to the target population.
Results of the Web survey were consistent in terms of the answers the different groups of participants gave and no controversies were observed. The latter are based on answers from 877 Web survey participants, received by the beginning of June, 2016. This deliverable was finalisedaround the and of June, whereby the numbers of participants were almost over 1700. Initial screening of the updated results shows most of the major observations unaffected; however, a few observations which were affected will be accounted for during the first developmental cycle of the i- PROGNOSIS components.
The presentation of the usage scenarios and business processes are a vital section to this deliverable, with greater elaboration on business processes to acknowledge the vast majority of tasks major stakeholders of the i-PROGNOSIS would need to undertake. This form of detailed approach has allowed for indication of typical user requirements, which ultimately facilitates the development of i-PROGNOSIS components.
The first version of the analysis identified 102 functional and 20 non-functional user requirements. In keeping with a spiral developmental approach, the first set of requirements will be updated after the first pilots and user acceptance evaluation, paralleled with continuous stream of data from Web surveys.
2 INTRODUCTION
2.1 PURPOSE AND STRUCTURE OF DOCUMENT
The scope of this document is to provide the first version of the identified user requirements, as well as the systematic approach to the identification process. A section of this deliverable is dedicated to the presentation of the state-of-the-art regarding approaches for PD-related diagnosis and interventions approaches, with emphasis on ICT-based solutions.
To this end, this document is structured in eight sections, namely: Section 1 provides an executive summary of the project; Section 2 describes a brief introduction regarding the i-PROGNOSIS project and Task 2.1 - Definition of User Requirements; Section 3 is dedicated to the relevant state-of-the-art; Section 4 refers to the overall process for the identification of user requirements including the aims of the respective task, a project glossary, the description of the process of designing the questionnaires to identify relevant user requirements, and the actual actions towards the identification (organisation of focus groups and Web survey); Section 5 provides the focus groups outcomes, as key observations, and the quantitative Web survey i-PROGNOSIS-690494_D2.1.docx p. 9/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
results and corresponding observations; Section 6 provides a detailed description of usage scenarios regarding the i-PROGNOSIS final system, along with general UML use case diagrams, which are further broken down to business processes; Section 7 provides the first set of identified user requirements by categorising them into functional and non-functional ones; finaly, Section 8 discusses the findings and concludes the deliverable.
Complementary, there are also four appendices, i.e.: Appendix I provides the complete questionnaires used during focus groups; Appendix II provides the links to versions of the Web-based questionnaire in six languages; Appendix III presents instructions that were used as guidelines for the interviewers leading each focus group; and Appendix IV presents the detailed outcomes of the focus groups and the interviews.
2.2 THE ACTIVE AND HEALTHY AGEING CONCEPT
The goals, objectives and impact of i-PROGNOSIS are situated within the area of active and healthy ageing (AHA). The latter is the process of optimising opportunities for health, participation and security in order to enhance quality of life as people age. European-innovation-partnership (EIP) has this concept as part of its strategy. Originally, it was derived from active ageing –a policy framework the World Health Organisation (WHO) (2002) (see FIGURE 1). It applies to both individuals and population groups.
‘Health ageing’ can incorporate physical, mental, as well as social well-being, whilst ‘Active ageing’ incorporates a range of aspects, including social, economic, cultural, spiritual and civic affairs, and labour force. EIP considers ageing as an opportunity, whereby older patients are a valued and recognised part of a growing society. It aims to empower these individuals in their communities using innovative service delivery with the user in mind.
FIGURE 1 The determinants of active ageing according to the policy framework1 of the WHO (2002).
i-PROGNOSIS-690494_D2.1.docx p. 10/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Innovation in services and products for AHA may require large investments and certainly carries risks. Furthermore, it needs knowledge develoment and integration of the supply-and-demand aspect in line with the whole research and innovation cycle. However, when the solutions are effective, cost-efficient and evidence-based, then the gain is greater and more meaningful. Hence, healthy aging is an economic multiplier, which allows for a better outcome for older adults, healthcare professional satisfaction, quality of life improvements, and financial security for carers, all of which are achieved with improved efficiency and increased productivity of health and social care systems. Innovation is able to bring value to older adults in parallel with delivering long-run budgetary savings as these returns are not mutually exclusive.
Supporting dynamic and sustainable health and care systems of tomorrow
The European health and social care systems in place play a fundamental role in various aspects of its citizens’ lives, the national economy and the society through supporting optimal health, quality of life and the ability to live independently. The need for innovative approaches to better foster efficiency of health and social care systems and guarantee their sustainability has been increased due to the growing demand (ageing, chronic diseases expansions), the outflow of healthcare professionals, carers, and ongoing budgetary consolidation. With the addition of the current economic crisis, there is added pressure on the situation leaving an enormous task on public finances and on citizens’ access to affordable health and social care services and products.
An urgent action to shift the focus from secondary based care to proactive primary care, which focuses on integration of social and health care is needed. This should be underpinned by promotion of good health, preventative strategies, independent living and integration of health, social, community and self-care. These need to be supported by an environment empowering older adults to remain functional and active.
It is also essential that future care systems -while continuing to be based on the common values of universality, access to good quality care, equity and solidarity- must accommodate new realities and acknowledge the need for cost-efficient investments.
Defining priority areas of work and actions as a first step
The work needed is based on three pillars reflecting the 'life stages' of the older individual in relation to care processes, namely:
1. Prevention, screening and early diagnosis; 2. Care and cure; and 3. Active ageing and independent living.
Responding to the complex issue of AHA requires comprehensive work on a broad scale. In order to determine the best way forward and focus on those innovative actions which deliver the highest impact.
i-PROGNOSIS-690494_D2.1.docx p. 11/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The i-PROGNOSIS project is also considered under first pillar (i.e., Prevention, screening and early diagnosis). It will also undertake initiatives that increase the awareness for the early risk of PD on a social scale, via social interventions for raising awareness for active and healthy ageing. The initiatives will foster:
Creation of the i-PROGNOSIS Community with the participation as many as possible users of the i-PROGNOSIS tools that would act as promoters of the “early PD detection initiative”, fostering the concept of donating individual behavioural data when interacting with smart devices (e.g., smartphones, smartwatches) to produce refined PD prognostic indices for the benefit of the whole society; Mobilisation of young people to assist older adults to use the i-PROGNOSIS application at their meeting centres, as a means of PD-related risks prevention via the initiative “the young adopt older adults”. Construction of socio-economic models for new cost-effective ICT-based PD early detection and interventions practices and policies, establishing appropriate recommendations to all engaged stakeholders.
2.3 BRIEF INTRODUCTION TO THE i-PROGNOSIS PROJECT i-PROGNOSIS aims to create an intelligent ICT-based approach for early PD symptoms detection and early intervention in older adult’s everyday life (FIGURE 2), promoting active and healthy ageing, by introducing new ways of health self- managing tools, set within a collaborative care context with health professionals. This would be achieved by creating an ICT-based behavioural analysis approach for capturing, as early as possible, the PD symptoms appearance and applying ICT-based interventions countering identified risks based on early PD detection, relating to progressive frailty, falls and emotional shift towards depression. i-PROGNOSIS adopts a radically novel approach to capture the risk of transition from healthy status towards PD, by unobtrusive behavioural sensing and large scale collection of elderlies’ data, acquired from their natural use of smart devices (mobile smartphone/smartwatch), after their granted permission, via corresponding mobile applications. Based on downloadable applications, the data are collected from a large number (in the range of thousands) of users (40+ years of age), forming the i- PROGNOSIS Community, are anonymised and analysed using big data analytics and machine learning, in order to identify individuals’ behavioural feature vectors that could reliably reveal the shift from healthy to PD status; thus, idendifying those that are at risk of developing PD and provide to them novel ICT-based interventions. Due to the unobtrusive character of i-PROGNOSIS, the applications are running on the background of the user’s mobile phone, and after getting his/her consent, they automatically collect the required information, uploading it to the Microsoft-based data centres (Azure Cloud) for further analysis, complying with all European norms of data security and privacy. The i-PROGNOSIS system concept is depicted in Fig. 2. From the latter it is clear that the i-PROGNOSIS includes two stages for the PD early detection, starting from general population (1st stage) and focussing on specific population (2nd stage), followed by ICT-based early interventions.
i-PROGNOSIS-690494_D2.1.docx p. 12/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FIGURE 2 The i-PROGNOSIS system concept includes two stages for PD detection based on smartphone, smartwatch and internet-of-things (IoT) user interaction and the interventions stage (serious games, nocturnal and assistive interventions, as well as monitoring). Besides, the i-PROGNOSIS automated indication of a user's behavioural change related to PD, the role of the physician is crucial regarding the validation of the indication and the transition from one stage to the next one.
The main innovative elements of i-PROGNOSIS are:
Introduction of new early diagnostic tests for PD symptoms based on features extracted from secure Cloud-stored behavioural and sensorial data, collected by smart devices (e.g., smartphone, smartwatch), wearable biosensors and IoT-based everyday living sensorial artefacts, and processed by advanced big data analytics and machine learning techniques; Design and implementation of novel ICT-based adaptive, gamified, and personalised interventions, along with assistive interventions, taking into account older adult’s physical and psychological status, promoting his/her health self-management at the family setting by providing dynamic feedback towards the improvement of older adult’s skills and functionalities for reduction of the PD-related risks of frailty, depression and falls; and Fostering of social awareness for volunteerism in early PD detection and construction of socio-economic and informed behavioural models for new cost effective ICT-based PD early detection and related risks-reduction intervention practices and policies for the sustainability of health and care systems and the benefit of the older adults.
Apart from the early PD risk detection, the i-PROGNOSIS project proposes appropriate ICT-based interventions. Currently, no treatment exists that fully accounts for the therapy of PD itself; hence, the designed ICT-based interventions of the i- PROGNOSIS tackle the risks that are related with the effect of the PD on the health condition of the older adults that exhibit PD symptoms; that is, frailty (due to reduced physical condition/skills), falls (due to decreased flexibility, balance/gait stability) and depression (due to chemical changes in the brain and frontal lobe under-activation). i-PROGNOSIS-690494_D2.1.docx p. 13/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The proposed interventions are realised via the i-PROGNOSIS Platform, consisting of a game-based suite Personalised Game Suite (PGS), along with nocturnal and assistive interventions, holistically supporting in a personalised way: muscle tension reinforcement, walking pattern/posture reestablishment, dietary habits adaptation for reduction of constipation/depression, expressive face encouragement, natural blinking reestablishment and depression/ anxiety treatment, handwriting pattern correction/reestablishment and hypophonia reduction, increased relaxation and sleep quality, voice enhancement and gate rhythm guidance, facilitating communication with others and socialisation. In i-PROGNOSIS intervention Platform, integrated technology modules will be developed to monitor and support older adult’s physical (daily/nocturnal) and emotional status enhancement, towards the decrease of the PD- related risks and increase of their quality-adjusted life-years (QALYs). The mutual interaction with the PGS by small groups of remote participants promotes elderlies’ social connectivity and fosters health affecting social interaction, peer support and peer mentoring, contributing to the effective lifestyle behaviour changes (physical activity/skills, dietary habits, emotional expression, interaction/socialisation) and adherence to medical plans.
The aforementioned is supported by i-PROGNOSIS data management system capable of linking large amounts of important sensed information during the interventions (e.g., response to PGS/nocturnal/assistive interventions, behavioural change data), most of which were not previously available to the healthcare professional, so they can be mined, analysed and modelled to provide the healthcare professional with knowledge and pertinent feedback on demand to make more accurate and informed decisions in relation to older adult’s health care. This makes the health professional an informed consultant, who assisted by the ICT-based interventions outcome, supports the older adults, in a personalised way, in achieving his/her optimal quality of life.
All the i-PROGNOSIS applications will be freely downloadable and adequally informative to the user, whilst extensive updated information will be circulated within the members of the i-PROGNOSIS Community and the wider public, via the i- PROGNOSIS dissemination channels and the i-PROGNOSIS website (www.i- prognosis.eu).
2.4 FOCUS ON TASK 2.1
Task 2.1 aims to define user requirements that will shape the development of the i- PROGNOSIS system. All clinical partners were asked to involve the largest number of users (e.g., elderly people, medical doctors, nurses, care assistants) to collect requirements and usability issues. Each agreed requirement (both functional and non-functional) is identified, classified and qualified with respect to its importance (“required", "preferred”, “optional”), and its clinical value.
All technical, user-oriented and clinical partners carried out series of activities:
During the kick-off meeting all clinical, technical and end-user partners had face-to-face sessions where all pilot partners were asked to define the scenarios and use cases from their perspective by means of small surveys and i-PROGNOSIS-690494_D2.1.docx p. 14/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
small focus groups. The basis for the identification of user requirements was set and built upon by the i-PROGNOSIS consortium experts through face-to- face sessions. All requirements derived from this procedure were further refined by the focus groups' observations and the results of the i-PROGNOSIS Web survey. KCL as being a leader for this task circulated a draft set of potential questions to all partners in order to obtain their input, opinion and comments for the development of the user requirements questionnaire. All partners provided comments and suggestions which KCL further refined. All medical partners employed a large number of users to further develop the user requirements questionnaires through a series of focus group meetings. Each focus group meeting was specific to healthcare professionals or patients/ users. Once again an updated questionnaire was circulated amongst the partners for further development in focus group meetings and finally a final draft paper- based questionnaire was designed. Web based surveys open to a wider target group. The technical partners accumulated all the information and form it into UML case models comprising: 1) actor lists and benefits, 2) usage scenarios and bussiness processes, and 3) general UML use case diagrams.
All the aforementioned had a triple role: a) to source user requirements directly from a large population belonging to the target groups (healthy older than 40 years old, PD patients and PD experts), b) to validate or shape certain technical specifications of the i-PROGNOSIS components and, c) collaterally and early disseminate the project to the target population.
All the identified user requirements will be updated during the realisation of the i- PROGNOSIS, based on its spiral model of development.
3 STATE-OF-THE-ART
3.1 CONVENTIONAL PD DIAGNOSIS AND INTERVENTIONS
3.1.1 Introduction
Parkinson's disease (PD), named after Dr. James Parkinson (1755-1824), who first identified the disease, is a progressive, degenerative, neurological disorder that is caused by the loss of brain cells (neurons) in the area of the brain called the substantia nigra, which produces the chemical messenger dopamine (Obeso et al., 2008). The more neurons die, the less dopamine is produced and transported to an area of the brain responsible for the coordination of movement, i.e., the striatum. It is estimated that approximately 6.3 million people worldwide suffer from PD, with no differentiation for race or culture. In Europe alone, 1.2 million people have the disease, equating to a rate of more than 1 out of 1000 people, making it the second most common neurodegenerative disorder. The estimated annual cost reaches €13.9 billion (Gustavsson et al., 2011) in Europe, continuing to grow as the population ages.
i-PROGNOSIS-690494_D2.1.docx p. 15/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The age of onset is typically over 60 years (Tanner et al., 2002), while 15% of people with the condition develop "young-onset" PD before reaching age 50. PD is marked by the presence of certain recognisable motor symptoms (collectively referred to as Parkinsonism) (Reichmann et al., 2010) that worsen as the disease progress. These include uncontrollable shaking or tremor at rest, bradykinesia, rigidity of limbs, balance (posture) and coordination problems, as well as, speaking and writing difficulties. In addition, non-motor symptoms (Chaudhuri & Odin, 2010) are increasingly recognised by the medical community, including, amongst others, constipation, mood swings, sleep disturbances, as well as changes in dietary habits, weight and energy loss that severely affect the quality of life. It is evident that the escalation of the latter symptoms progressively leads to frailty, maximisation of the risk of falls, and depression due to decreased self-esteem and socialisation. FIGURE 3 presents the stages of PD ranging from prodromal to palliative stage including non-motor and motor symptoms. In general, patients are diagnosed in the stable PD stage (early stage) after the onset of typical motor symptoms.
FIGURE 3 Stages of PD according to Chaudhuri & Fung (2016).
Furthermore, five stages have been described to characterise the progression of motor symptoms, which are based on the Hoehn and Yahr rating scale (Hoenh & Yahr, 1967):
I. Stage I is the mildest form of PD with unilateral symptoms, including minimal tremor that are often missed. II. Stage II is considered a moderate form of PD and the symptoms, including more notable bilateral tremor, bradykinesia, rigidity and hypomimia (reduced facial expressions, masked face), which are becoming fairly noticeable. III. Stage III marks a turning point in the progression of PD with common symptoms as Stage II, but loss of balance and decreased reflexes also occur. IV. In Stage IV, symptoms have progressed to an extent that independence in movements is starting to decrease (need for walker or other assistive device) rendering patients unable to live alone due to inability to perform daily tasks. i-PROGNOSIS-690494_D2.1.docx p. 16/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
V. Stage V is the most severe stage of PD and symptoms are so advanced that patients have no ability to stand, experience hallucinations, and require wheelchairs and around-the-clock assistance.
3.1.2 Diagnosis
Currently, there are no tests (such as laboratory or imaging) available for early detection of Parkinson’s disease. Furthermore, there are no effective neuroprotective drugs available which could slow down or prevent the progression of Parkinson’s disease or ideally cure the neurological degeneration.
In most cases Parkinson’s disease clinical diagnosis takes place according to the UK Parkinson’s Disease Society Brain Bank clinical diagnostic criteria including bradykinesia (slowness of movement) plus one of the following: rigidity (stiffness or inflexibility of muscles) resting tremor and postural instability. This assessment is usually performed by a physician specialised in Movement disorders. Further evidence can be provided by a positive response of the person at risk to appropriate drugs. Auxiliary laboratory tests that provide evidence of dopamine depletion in the striatum are Dopamine Transporter Scan (DATSCAN) and 18-flurodopa Positron Emission Tomography scan (F-DOPA PET). As an example, the sensitivity and specificity for a clinical diagnosis of “possible” PD at an early stage has been reported to be as high as 98% and 67% respectively (de la Fuente-Fernandez, 2012).
However PET is very expensive and is performed in few specialised laboratories across Europe (< 350, mainly used for research purposes) that is rendered unsuitable for wide penetration in health care systems (Buck et al., 2010). A definite diagnosis can only be made at autopsy. The main concern arising from the diagnosis process is that PD symptoms at the onset of the disease are so mild that are often missed and do not raise concerns to the person at risk in order to proceed to clinical examination. From the latter emerges the need for new detection methods focusing on early PD symptoms.
3.1.3 Interventions
The clinical symptoms of Parkinson’s disease can be very effectively treated and managed with a combination of drug treatment as well as multidisciplinary input. The gold standard for the treatment of Parkinson’s disease is Levodopa (or L-dopa (Schapira et al., 2009). However, in order to minimise the side effects of long term treatment with Levodopa such as dyskinesia, patients start receiving a dopamine agonist if not contraindicated. Furthermore, Monoamine Oxidase B inhibitors (MAO-B inhibitors) as well as Catechol-O-Methyl-Transferase inhibitors (COMT inhibitors) can be beneficial.
Surgical treatment may be also considered for patients whose PD symptoms cannot be adequately controlled with medical management, in the form of deep brain stimulation which involves implanting a type of pacemaker into specific areas of the brain that control movement in order to function better (Rodriguez-Oroz et al., 2005). Various non-medical interventions exist that are implemented to treat the symptoms of PD and extend the quality-adjusted life years QALYs, especially if applied during i-PROGNOSIS-690494_D2.1.docx p. 17/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
the early stages of the disease, including physiotherapy, speech rehabilitation, diet and sleep regulation and psychological support. It is evident that the latter treatments require regular visits to and interaction with specialists and, in order to be effective, uptake and adherence play a crucial role. However, being away from home or disrupting everyday life, in conjunction with the degrading psychological condition leading to lack of self-motivation, constitute major risks for reduced uptake and adherence. Providing interventions for reducing the progression of early PD symptoms in the living environment, where they are comfortable and familiar with, addresses a number of these issues. The latter further empowers patients to self- manage their health and boost their self-confidence and satisfaction (Grosset, 2005) and, in addition, there are benefits to all members of the health eco-system to move away from a healthcare provider centric system to a co-production model; a home based system facilitates this. In fact, there is already evidence of life quality improvement from empowering patients to self-manage their PD disorder (Chenoweth et al., 2008), as well as chronic diseases in general (Lorig et al., 1999).
3.2 ASSISTED LIVING TECHNOLOGIES
3.2.1 Introduction
Assisted Living Technologies (ALT) refer to all the devices, sensors and communication systems, which help people maintain their independence and dignity, and are usually targeted to older people and/or people with disabilities1,2,3. Usually such people do not require 24-hour care, but still need some level of supervision and/or assistance with daily activities, such as feeding, bathing, dressing, grooming, work, homemaking and leisure, to ensure their health, safety, and well-being.4 Furthermore, ALTs are used for monitoring and coordination of services by external healthcare providers.
Assisted Living Services (ALSs) include:
Telecare and telehealth services, delivering social and medical care including monitoring to elderly or disabled people from a remote location. Digital participation services, delivering services to enrich the lives of older and disabled people into social, educational and entertainment. Activities Wellness services, delivering services to encourage older and disabled people to adopt and maintain a healthier lifestyle.
The general network architecture (FIGURE 4) presented below can support all the above-identified ALSs. It defines three main networks:
Body area network, i.e. the network with which the devices attached to the human body communicate (usually Bluetooth or wireless IP)
1 http://stakeholders.ofcom.org.uk/binaries/research/technology-research/Assisted.pdf 2 http://www.skillsforcare.org.uk/Topics/Assistive-living-technology/Assistive-living-technology.aspx 3 https://en.wikipedia.org/wiki/Assisted_living 4 https://en.wikipedia.org/wiki/Activities_of_daily_living i-PROGNOSIS-690494_D2.1.docx p. 18/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Local area network, i.e. the network inside the home (usually wireless or wired) Wide area network, i.e. the network with which the home network communicates with the rest of the world, which is usually wireless (3G/4G/ WiFi/Wimax) or via a telephone line or cable (PSTN/ADSL/COAX).
FIGURE 4 A general architecture for ALTs (Lewin & Adshead, 2010)
There are a series of initiatives from Member States and the European Commission (EC) around ALT. One such European-wide initiative from both Member States and EC is the Active and Assisted Living Joint Programme (AAL JP). The EC also founded in 2011 the European Innovation Partnership on Active and Healthy Ageing (EIP–AHA).
Patients with Parkinson’s disease may benefit from ALT and ALSs. Depending on the severity of the patient, she/he can benefit from both remote and local services and a series of equipment (devices and sensors), which are described in the next section
3.2.2 Devices and sensors
Memory disorders and dementia are perceived as diseases which ALT and ALSs can help the most. However, Parkinson’s disease is also one of the diseases that such technologies and services can also benefit the patients and their partners or caregivers.5
The ALT equipment usually covers the areas of the services presented below1, 2, in most cases helping the patient maintain their independence or providing monitoring and triggering alarms or intervention actions. Up to now there is no clear evidence that ALT and related devices and sensors can help in the early detection of PD or its symptoms, although related research6,7 exists in the literature.
5 http://www.assisted-living-directory.com/content/parkinsons-assisted-living.cfm 6https://www.researchgate.net/publication/266080900_A_Smartphone_Application_for_Parkins on_Tremor_Detection i-PROGNOSIS-690494_D2.1.docx p. 19/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Telecare and telehealth services: o A series of sensors that can trigger preset alarms such as an accessory or ornament that can either call for help or for local use after fall, smoke, flood, extreme temperature, fire, etc. o A series of monitors, e.g. bed occupancy, location or motion detection or movement sensors, which can transmit information to a central monitored location o Voice tools or memo systems to remind people of what they should do o Medical measurement devices, passive or active (such as heart pacemakers) that can communicate information about blood pressure, pulse rate, blood oxygen level, glucose, weight, etc. Smartwatches, smart bands or smart remotes can also include several such sensors. o Gait monitoring and intervention systems for assisting gait. o Smart belts able to detect constipation o Wireless headphones for playing special sounds to improve sleep. o A communication hub and system with a user interface that can communicate to the internet. Digital participation services: o Devices for social, educational and entertainment activities such as mobile phones or smartphones, tablets, laptops or computers, smartphones and smartwatches, video call facilities, smart TV, smart remote, set-top boxes, gaming devices including motion or other sensors (such as Wii or Microsoft Kinect), and more. Wellness services o Devices such as personal training, nutritional scanning systems (e.g. Mandometer), smartwatches or smart bands, smartphones delivering services to encourage older and disabled people to adopt and maintain a healthier lifestyle.
In particular, for Parkinson’s disease, the smartphones and special applications, smartwatches/smart bands, TV smart remotes, Mandometers, Electronic games have a special role to play. i-PROGNOSIS plans to use the state-of-the-art (SoA) ALTs and ALSs, including the above devices and sensors, not only for improving the lives of PD patients, but also for the PD early detection, and this is one of the main novelties of the project.
3.3 TECHNOLOGY-BASED APPROACHES RELATED TO i-PROGNOSIS FOCUS AREAS
This section constitutes an extension of the state-of-the-art presented in the i- PROGNOSIS Description of Action (DoA) by referring mainly to higher level ICT-based approaches against PD, i.e., projects and applications.
7https://www.researchgate.net/publication/288323914_Detection_of_freezing_of_gait_for_Parki nson's_disease_patients_with_multi-sensor_device_and_Gaussian_neural_networks i-PROGNOSIS-690494_D2.1.docx p. 20/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
3.3.1 Voice analysis
The need: Speech impairments associated with PD, termed hypokinetic dysarthrias (Darley et al., 1969) include hypophonia (reduced voice volume), dysphonia (breathy, hoarse voice), hypokinetic articulation (imprecise articulation due to reduced articulatory movement range), hypoprosodia (reduced speech pitch variability), palilalia (disfluent, hesitant speech) and hypernasality (increased nasal resonance). Hypophonia and dysphonia emerges in the early stages of PD (Ho et al., 1998), while imprecise vowel articulation is shown to be present in mild stages of PD (Skodda et al., 2011; Skodda et al., 2012). Voice analysis algorithms focusing on these symptoms can be used for the (early) detection of PD.
Key projects and applications: In the last few years, various projects and works focusing on audio analysis for the detection of PD have been carried out. The very interesting doctoral thesis of A. Tsanas (Tsanas, 2012), examines a multitude of voice features and evaluates their discriminative capabilities with respect to PD. The list contains the Glottal-to-Noise Excitation Ratio (GNE) and the Vocal Fold Excitation Ratios (VFER) that both measure the ratio of glottal pulse energy over the concurrent turbulent noise as an indicator of hypokinetic vocal folds. A dense multiclass support vector machine (SVM) is then used as a classificator for the prediction of motor and total Unified Parkinson Desease Rating Scale (UPDRS). In (Sakar et al., 2013) a large audio database compiled from a set of speaking exercises for PD patients was collected and analysed. The authors report that sustained vowels carry more PD- discriminative information than isolated words or short sentences too. Additionally, rather than using each voice recording of each subject as an independent data sample, representing the samples of a subject with central tendency and dispersion metrics improved the generalisation of the predictive model. In (Geman, 2011) tremor, gait and speech signals of PD patients are analysed for the goal of creating a screening test in order to early identify PD. In (Wei & Yun, 2016) a study is performed which aims to investigate the potential of using sustained vowel phonations towards objectively and automatically replicating the speech experts' assessments of PD subjects' voices. In this work a stable dysphonia measures subset is identified. The experimental results have shown that the algorithm can obtain high stability and classification performance for speech assessment. In (Scherer et al., 2015) an automatic unsupervised machine learning approach is proposed to assess the vowel space measures of subjects with and without psychological conditions associated with psychological distress, namely depression, post-traumatic stress disorder and suicidality. The experiments show a significantly reduced vowel space in conversational speech for depression, posttraumatic stress disorder (PTSD), and suicidality.
Integration with i-PROGNOSIS: In i-PROGNOSIS the voice analysis component has the “privilege” of access to long term recordings of the subjects. Speech recordings becoming available from users’ smartphones will be periodically analysed yielding features like the previously described ones or new developed features. But instead of taking instantaneous decisions the system will resort on statistically derived aggregates like Fisher Vectors (Csurka, 2011) and their derivatives to detect PD robustly and to track the trend of the degree of the symptoms over time. It is also i-PROGNOSIS-690494_D2.1.docx p. 21/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
important to highlight that the semantic content of the voice signal will not be analysed. Also, it will be investigated if it is more efficient to implement this module as part of the mobile dialler application for local analysis (less resources for data transmission) or as an external remote service operating in the data storage server.
3.3.2 Gait analysis
The need: Despite optimal medication therapy, gait problems associated with PD are often characterised by a decreased stride length and walking speed, an increased cadence and double limb support, shuffling gait, gait festination and freezing (Giladi, 2001). Facilitation of gait of patients with PD with the help of cueing has been reported since 1942 (Martin, 1967). In fact, external cueing can significantly improve gait and gait-related activities in patients with PD (Darmon et al., 1999; Rubinstein et al., 2002). Given the fact that Parkinsonian symptoms particularly affect complex and sequential movements, external rhythmical cueing is operationally defined as applying temporal (rhythmical) or spatial stimuli associated with the initiation and ongoing facilitation of motor activity (gait) (The Rescue Consortium, 2005). According to Lim et al. (2005), there is strong evidence that rhythmical auditory cueing enhances walking speed in patients with PD. Moreover, recent studies show that familiarity with music increases walking speed in rhythmic auditory cuing (Leow et al., 2015; Bella et al., 2015).
Key projects and applications: SUREGAIT8 is an FP6-SME project (2007-2009) that aimed at the development of a portable, inexpensive, non-invasive, 3-Dimensional gait analysis system that can be used in the community. All the data from the various sensors and the matching video clips will be sent to a doctor, anywhere in the EU, with expertise in gait analysis via e-mail, or mobile phone technology, for diagnosis. Each skin-mounted EMG sensor allows force measurement and positional analysis of the patient. Sensors are highly innovative in that they are truly wireless, running off low power, negating the need for the patient to carry heavy battery packs or trailing cables.
WIISEL9 is an FP7 project (2011-2015) that its main goal was to develop an unobtrusive, self-learning and wearable prevention and warning system to decrease the incidence of falls in the elderly population. The idea was that elderly people put a specifically designed insole in their shoes, which monitors their walking pattern. This way the system may detect changes in gait and balance in the daily environment of the older person, which helps predict the likelihood of falling. Thus the system provides security to the elderly and reduces their fear of falling, directly improving their quality of life.
REMPARK10 is an FP7-ICT project (2011-2015) with an ultimate goal to develop a personal health system with closed loop detection, response and treatment capabilities for management of PD patients at two levels: a) development of a wearable monitoring system able to identify in real time the motor status of the PD
8 http://cordis.europa.eu/project/rcn/85593_en.html 9 http://www.wiisel.eu/ 10 www.rempark.eu/ i-PROGNOSIS-690494_D2.1.docx p. 22/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
patients, and evaluating ON/OFF/Dyskinesia status, with sensitivity greater than 80% and specificity greater than 80% in operation during ambulatory conditions, along with the development of a gait guidance system able to help the patient in real time during his/her daily activities and (b) use of the intelligent analysis of data provided by the first level, supported with a disease management system that allows the neurologist in charge to access accurate and reliable information to decide about the treatment that best suits the patient, improving the management of their disease, in particular to adjust the so called therapeutic window.
Wi-Shoe11 is an FP7-SME project (2014-2015) that aimed at the development of a completely non-invasive wearable shoe-based system for measuring gait parameters and energetic expenditure during walking. The system integrates miniature sensors in a custom designed sole for different shoe types. The project answers the actual need of the rehabilitation and sport sectors for a person-centric product that will allow continuous monitoring of the subject without an expert’s intervention, promoting the role of “home as care environment”.
With regard to related applications the following could be identified:
Gaitometer12: This application measures human gait asymmetry when walking (or running) using the built-in accelerometer of a smartphone, and provides real-time gait analysis and therapy using audible and visual feedback to assist the user in obtaining a more symmetric and normal gait. A selectable Gait Warning sound can be used to provide immediate feedback to help the user reduce the measured gait abnormality. In addition to immediate feedback for an abnormal gait, gait history is stored and displayed in increments of minutes, hours, and days to monitor gait improvements. The Gaitometer should be worn at the centre of the body, and will work best on consistent surfaces such as smooth sidewalks, running tracks, and treadmills.
GaitAnalysisPro13: This application is developed for healthcare providers, such as doctors, physical therapists, physical trainers, and uses the build-in accelerometer of a smartphone to measure basic gate parameters, such as gate speed, step length, as well as coefficient of variance, symmetry of and centre of mass displacement during gate.
RanchoGait II14: This application is the first of a series of apps to provide instruction on how to evaluate both normal and pathologic gait with the final application in the series aimed at prescription of lower extremity orthoses which was developed at Rancho Los Amigos National Rehabilitation Center for individuals with neurologic impairments. The RanchoGait application allows the user to be an active participant in learning the essential elements of Normal and Pathologic Gait and engages critical thinking in the learning process. The RanchoGait application contains the highlights and essential elements of Normal Gait, including Phases, Functional Tasks, Task
11 http://www.wishoe.eu/ 12 http://www.gaitometer.com/about/index.htm 13 https://itunes.apple.com/us/app/gaitanalysispro/id915232074?mt=8 14 https://play.google.com/store/apps/details?id=ranchorep.android.mops&hl=en i-PROGNOSIS-690494_D2.1.docx p. 23/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Accomplishments, and Critical Events; and the Pathologic Gait describes the different deviations during the phases of human gait.
MyWalk15: This is a mobile application to enable gait rehabilitation in the community. Particularly, it can be used to treat and assess step-time asymmetry (STA) -which occurs when the amount of time between consecutive heel strikes is uneven. Temporal gait asymmetry, of which STA is a form, is common post-stroke and could result in difficulties, such as joint degeneration or musculoskeletal pain. By enabling STA rehabilitation on a smartphone, post-stroke patients can now improve and assess their STA within the context of their everyday environments.
Angel416: This "Angel4" consists of a waist sensor which detects, stores and sends to a server the main PD-symptoms like dyskinesia (involuntary muscle movements), bradykinesia (slow movements) and freezing of gait (a temporary and involuntary inability to move). The "Angel4" is part of the product portfolio of SENSE4CARE- a spin-off of Universitat Politècnica de Catalunya, Spain. The device is intended for a medical context and the company is currently working to get the "CE marking" (which ensures compliance with the European Directive on Medical Devices) before it can be introduced in the market. SENSE4CARE received funding from the new EU SME instrument Phase 1 (part of the Horizon 2020 programme) to develop a business plan for the new device. The company is currently exploring the possibility to market a commercial version for patients’ personal use in 2016.
The abovementioned projects and applications justify the need for a reliable gait analysis as a means for evaluating the walking status of the user and especially the PD patient who suffers from various gait effects. The projects mainly target wearable- based solutions for gait tracking (e.g., smart shoe), whereas the applications use the accelerometer information from the smartphone. Taking into account the unobtrusiveness of the i-PROGNOSIS in the identification of the gait changes that shift towards the PD, the second approach will be adopted, yet enriched, as described in the succeeding section.
Integration with i-PROGNOSIS: i-PROGNONSIS aims at developing assistive cueing methodologies realised in the form of assistive intervention, by effectively presenting to the PD patient a variety of cueing inputs, unobtrusively and during his/her everyday activities. The smartphone (sound/visual) and smartwatch (vibration) will be used as means for transferring the cueing information to the PD patient. Older adults’ effective gait analysis, speed, periodicity, complexity in walking patterns (via the estimation of the corresponding fuzzy fractal dimension (Zhang et al., 2014)), along with walking habits combined with current location information and current physiological status (e.g., Heart Rate Variability data) will be combined, so to provide personalised cueing to the PD patient. The latter include, among others, identification of gait patterns according to the patient’s PD level, adaptation of the assistive cueing methodology to his/her unique walking characteristics and his/her medication
15 https://www.researchgate.net/publication/256506266_MyWalk_A_Mobile_App_for_Gait_ Asymmetry_Rehabilitation_in_the_Community 16 http://www.sense4care.com/en# i-PROGNOSIS-690494_D2.1.docx p. 24/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
protocol. The derived behavioural data and the underlying behavioural compliance to the cueing characteristics could lead to more conclusive results for the maximisation of the cueing positive effect to the PD patients.
3.3.3 Tremor analysis
The need: Tremor, especially during resting, is a well-known symptom of PD and it is usually used as a first point of reference for the existence of PD. It has been extensively studied, and a review of these works is presented in (Deuschl et al., 2000). A lot of effort has also been devoted towards automatic detection of resting tremor in early stages, in order to use it as an indicator for PD (Eberhart et al., 1999; Salarian et al., 2007; Salarian et al., 2009; Wood et al., 2014; Zhang et al., 2014).
Key projects and applications: The EU funded PERFORM17 project (2008-2011) aimed to tackle problems associated with the efficient remote health status monitoring, the qualitative and quantitative assessment and the treatment personalisation for people suffering from neurodegenerative diseases and movement disorders, such as PD. The PERFORM project aspired to research and develop an innovative, intelligent system for monitoring neurodegenerative disease evolution through the employment of a wide range of wearable micro-sensors, advanced knowledge processing and fusion algorithms. Advanced sensors, attached to everyday personal devices (e.g., cloths, accessories) were able to 'sense' the user's behaviour and motor status and store the recorded data in a local portable/handheld computer. These data are then processed and seamlessly transmitted to the centralised system for further fusion, monitoring and evaluation. An indicative list of measurements includes: tremor through accelerometers or gyroscopes and possibly ElectroMyoGram (EMG), skin conductivity and sweating through appropriate Galvanic Skin Response (GSR) sensors, SPO2 and pulse rate through a pulse oximeter sensor, bradykinesia, through the finger tapping, other similar tests using devices to detect finger pressure.
MarkMD18 was an EU funded Industry Academia Partnerships and Pathways project (finished in February 2013) that focused on genetic (mainly CNVs) and clinical markers of PD and Essential Tremor (ET), two frequent neurological diseases. Co- operation and transfer of knowledge was dedicated to the establishment of new tools for the detection of disease associated genetic markers and clinical markers in patients as well as healthy at-risk groups.
NeuroTREMOR19, a three-year EU funded project (2012-2015), aimed at the validation in a technically, functionally and clinically way of a novel system for understanding, giving support to diagnosis, and remotely managing tremors. The system comprised of two platforms, i.e., the hospital-based platform that provides with detailed recordings of the central and peripheral nervous systems together with kinematic measurements, including a novel machine tool to support diagnosis of tremors, and
17 http://www.perform-project.eu/ 18 http://www.markmd.eu/ 19 http://www.g-nec.com/project_Neurotremor.html i-PROGNOSIS-690494_D2.1.docx p. 25/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
the neuroprosthetic platform that constitutes a novel alternative for remote management of upper limb tremors.
PROPHETIC: “An innovating Personal Healthcare Service for a holistic remote management and treatment of Parkinson patients”, is a 3-year Horizon2020 Marie Skłodowska-Curie Research and Innovation Staff Exchange (RISE) (ends 31-12-2017). PROPHETIC will exploit modern smart miniaturised systems and advanced information systems towards an infrastructure for remote, continuous, non-invasive acquisition and advanced processing of multi-parametric data and friendly telecare provision based on serious gaming. It will use embedded electronics (suite and cap) capable of measuring neural, psychological, physiological, and biomechanical parameters. Continuous monitoring while aware of the patient’s Levodopa medication will help determine health and motor status and avoid Levodopa side effects e.g. dyskinesia, freezing, low blood pressure, and falls. It will support caregivers’ decisions and allow early interventions. Appropriate information could be shared between the actors through, e.g., smart phones with access according to their role. Tremor is one of the factors that will be analysed by PROPHETIC.
A three-year European project (2015-2017), namely PD_manager20, aims to build and evaluate an innovative, mhealth, patient centric ecosystem for PD management. It also includes tremor data analysis but refers to already diagnosed PD patients, implementing a Decision Support Platform with suggestions for modifications in the patient’s medication trying to support him/her for self-managing of his/her condition.
With regard to related applications the following could be identified:
Parkinson mPower21: This application includes scenarios for different symptoms of PD, amongst them is also the PD patient’s tremor. Actually, it is a personal tool and research instrument to track symptoms of PD, review trends and share this information with researchers. It acquires activity-based measurements of Parkinson symptoms that include a memory game, voice recording, walking, and finger tapping as a means to measure the tremor.
Lift Pulse22: This application identifies, records and calculates the magnitude of a person’s hand tremor using the phone’s built-in sensors and cutting-edge algorithms. It is designed as a useful research tool, of interest to people with PD and their families too.
TremorTracer23: This application is used in the neurosciences to assess fine motor control along with resting and intention tremors, especially via handwriting exercises, such ach the Archimedes Spiral Test, the writing test and the straight line test.
20 www.parkinson-manager.eu 21 https://itunes.apple.com/us/app/parkinson-mpower-study-app/id972191200?mt=8 22 https://play.google.com/store/apps/details?id=com.liftlabsdesign.liftpulse&hl=en 23 http://www.touchdx.com/solutions/tremortracer i-PROGNOSIS-690494_D2.1.docx p. 26/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
StudyMyTremor24: This application records, analyses and tracks the trembling of the hand. This application uses a highly sophisticated, scientifically proven method to measure and analyse tremors. It gives the ability to assess and quantify the tremor and to keep track of the values. Moreover, it connects to the relevant site (studymyhealth.com) that provides the ability to transfer, manage and compare the measured tremor values with other users.
Apparently, the abovementioned projects and applications take into considerations the tremor as the indicator of the PD symptom. They do not, however, apply this in the everyday scenarios, so to track the existence of the first signs of tremor in the everyday activities in an unobtrusive way.
Integration with i-PROGNOSIS: The ambition of i-PROGNOSIS is to remove the need of dictated resting and perform tremor detection and quantification from accelerometer and gyroscope data collected from the daily use of smartphones, smart watches (from the members of the i-PROGNOSIS community that will download the relevant applications) and smart TV control devices (from the selected subjects with early indication of first PD symptoms that will be monitored at home). This implies that accurate ‘rest phase’ detection will precede tremor analysis. i- PROGNOSIS will be informed by the optimal visualisation of the tremor data based on the feedback analysis of the relevant applications mentioned before and will produce new tremor indices to the physicians (e.g., complexity measures) that could be used as quantitative evaluators associated with the Unified Parkinson's Disease Rating Scale (UPDRS).
3.3.4 Typing pattern and handwriting analysis
The need: As typing on a keyboard (physical or virtual) requires motor-based finger actions and in conjunction with the gradual loss of motor skills that PD patients exhibit, the latter interaction with typing interfaces may reveal information about the early onset of the disease25. On the other hand, handwriting that also requires coordinated motor-actions it has been shown that its quality deteriorates due to PD (Letanneux et al., 2014). Thus, an intervention targeting the rehabilitation or sustenance of handwriting skills would be of great value to patients.
Key projects and applications: As indicated by many recent works, there are features that are obtained by typing pattern and handwriting analysis, which can be used in the diagnosis of Parkinson. In (Atilla Ünlü, 2006), the authors used a novel electronic pen that captured pressure in x,y,z directions and the inclination relative to the x-y plane, and proposed a few features, such as relative number of loop extremes and impulse correlation and writing power rate coefficients to successfully discriminate between healthy people and people suffering from Parkinson’s disease. In (Smits et al., 2014), the authors conducted drawing and writing experiments to diagnose patients suffering from Parkinson’s disease. The results revealed that patient’s with Parkinson’s disease have a mean writing velocity and acceleration lower than healthy individuals (bradykinesia) and draw smaller letters than healthy people
24 http://stateoftech.net/study-tremors 25 http://news.mit.edu/2015/typing-patterns-diagnose-early-onset-parkinsons-0401 i-PROGNOSIS-690494_D2.1.docx p. 27/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
(mikrographia). In (Letanneux et al., 2014), the authors proposed the term dysgraphia to encompass all characteristics of Parkinson’s handwriting. They found that kinematic variables (velocity, fluency) differentiate better between control participants and PD patients, and between off- and on-treatment PD patients, than the traditional measure of static writing size. Although reduced writing size is an important feature of PD handwriting, the deficit is not restricted to micrographia in a strict sense. In (Weber, 2014), the authors extracted biometric data from healthy and PD subjects by measuring tremor, instability, dislocation and velocity of handwriting. Afterwards, they employed an SVM classifier to achieve an overall accuracy over 92% in the identification of patients suffering from Parkinson’s disease. In (Drotár, 2014), the authors propose a novel feature to discriminate healthy people from PD patients. They found out that the in-air trajectories performed when the hand moves in the air from one stroke to the next hold valuable information for the identification of patients suffering from Parkinson’s disease.
As far as typing on a keyboard is concerned, a recent study of Giancardo et al. (2015) showed that a system to detect psychomotor impairement is feasible and sufficiently accurate via routine typing on a physical keyboard, regardless of the language or the text input. Researchers suggested that this research may be applied on other medical domains where motor changes are expected, such as PD. Currently, no application has been developed that incorporates such features for the early detection of the disease.
Integration with i-PROGNOSIS: i-PROGNOSIS will take into account previous research on typing pattern and handwriting analysis and apply it for early detection of Parkinson's disease based on the users' interaction with mobile devices (mainly smartphone) and for the improvement of the users' handwriting during the interventions phase (Handwriting games).
3.3.5 Facial expression information from photos
The need: The effect of hypomimia (masked face) is a common secondary motor symptom of Parkinson's disease (Jankovic, 2008). Hypomimia is a reduced degree of facial expression that can be caused by motor impairment (for example, weakness or paralysis of the facial muscles). As reported in (Simons, 2003), experiments revealed that the PD participants showed reduced spontaneous facial expressivity across experimental situations and had more difficulty than controls posing emotional expressions and imitating non-emotional facial movements.
Therefore, the detection of hypomimia may be used for the diagnosis of Parkinson. In (Vinokurov et al., 2015) methods are developed to automatically detect and assess the severity of hypomimia, using machine learning tools and a 3D sensor that allows for fairly accurate facial movements tracking. Encouraging results are obtained, providing proof of concept that automatic evaluation of hypomimia can be suciently reliable to be useful for clinical early detection of PD-related hypomimia. In (Mergl et al., 2005), hypomimia is investigated in patients suffering from depression using ultrasonic markers placed on participants faces. New wearable technology could
i-PROGNOSIS-690494_D2.1.docx p. 28/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
enable home monitoring of patients, but since the number of sensors that can be put on the patients face is limited, the quality of assessing hypomimia severity is reduced.
Key projects and applications: No projects have been identified dealing with the detection of hypomimia for PD Diagnosis. According to (Ricciardi, 2015), little attention has been paid to this relevant clinical aspect of the disease and there is still a lack of validated assessment methods and therapeutic approaches. The most commonly used assessment method for clinical and scientific purposes is the sub- item 19 of the Unified Parkinson Disease Rating Scale—motor score (UPDRS-III) (Metman, 2004), which accounts only for the motor facet of hypomimia and gives no attention to the emotional aspect of facial expression.
Integration with i-PROGNOSIS: In i-PROGNOSIS, we plan to study new ways to detect motor impairments in facial muscles by analysing selfies photos and/or videos that are captured by the user using his/her smartphone (e.g. while watching a short video or movie). For instance, hypomimia detection methods such as (Vinokurov et al., 2015), may be extended to use videos from standard (e.g. mobile phone) cameras instead of a 3-D camera sensor or other more obtrusive sensors.
3.3.6 Text sentiment analysis
The need: It is well-known that PD affects the ability to communicate emotions (Paulmann, 2010) and may result to depression. On the other hand, recent advances in natural language processing, text analysis and computational linguistics facilitate sentiment extraction from different text sources (e.g. social media, blogs, SMS, etc). However, until today, related work on detecting such PD symptoms using sentiment analysis is extremely limited.
In (Chaffar et al., 2011), the authors adopted a supervised machine learning approach to recognise six basic emotions (anger, disgust, fear, happiness, sadness and surprise) using a heterogeneous emotion-annotated dataset which combines news headlines, fairy tales and blogs. (Aman, 2007), deals with identification of emotions in text by labelling certain words and counting occurrences of such words. In (Arora, 2010), the authors propose a novel representation of text based on patterns derived from linguistic annotation graphs. A subgraph mining algorithm is employed to automatically derive features as frequent subgraphs from the annotation graph. This process generates a very large number of features, many of which are highly correlated. A genetic programming based approach to feature construction is then proposed, which creates a fixed number of strong classification predictors from these subgraphs.
Key projects and applications: No projects were found using text sentiment analysis for Parkinson’s detection.
Integration with i-PROGNOSIS: In i-PROGNOSIS, sentiment monitoring from texts (e.g. SMS messages or tweets) created by a user will be used as a means for detecting depression. An 80% accuracy of this task has been reported by Wang et al. (2013).
i-PROGNOSIS-690494_D2.1.docx p. 29/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
3.3.7 Exploratory walkability
The need: The Centers for Disease Control and Prevention (CDC), the World Health Organization (WHO), and other health organisations advocate increasing the walkability of communities to promote fitness, combat obesity, and enhance sustainability. In fact, time outside of the home can increase social connections and may improve social support (Mair et al., 2008), which, in turn, can be protective against stress and depressive symptoms (Kubzansky et al., 2005), which are often met in PD. Several studies link higher walkability with lower depression in older adults and especially in men (Berke et al., 2007; Saarloos et al., 2011; Richardson, 2013). In addition to promoting physical and mental health, walkability supports independence for people of all ages and abilities and contributes to a greater quality of life for everyone (Neal & DeLaTorre, 2016). Using the available accelerometers on the smartwatch and smartphone, accurate classification of activity type, as well as intensity, can be achieved (Staudenmayer et al., 2009). As a result, mobility habits and walkability of the subjects can be accurately estimated, in a completely unobtrusive way. This can enable early detection of PD, since reduction of walkability and shifting from exploratory to monotonous nature are common symptoms in PD patients due to depression and gait problems.
Key projects and applications: To our knowledge, no key project has been funded tackling the walkability changes related to the appearance of early PD symptoms. There is only one relevant project (FP6, 2006), yet not centred in the PD case but in the children and infants, i.e., the IDEFICS-Study26: 'Identification and prevention of dietary- and lifestyle-induced health effects in children and infants', where it developed a Global Index System (GIS)-methodology to describe the 'obesogenic' environment around schools and kindergartens, creating an index of 'walkability' and 'playability' to describe opportunities for outdoor physical activity and the types of food on offer to children.
With regard to related applications the following could be identified:
Parkinson mPower27: This application includes scenarios for different symptoms of PD, amongst them is also the PD patient’s walking style. Actually, it is a personal tool and research instrument to track symptoms of PD, review trends and share this information with researchers. It acquires activity-based measurements of Parkinson symptoms that include a memory game, finger tapping, voice recording, and, as mentioned, walking.
There are some applications about the walkability, such as Walkshed28, Walkonomics29, Walk Score30, CAI Asia31, yet all these refer to the conditions of the
26 www.ideficsstudy.eu 27 https://itunes.apple.com/us/app/parkinson-mpower-study-app/id972191200?mt=8 28 http://www.walkshed.org/ 29 https://itunes.apple.com/us/app/walkonomics-find-beautiful/id597789063?mt=8 30 https://www.walkscore.com/iphone/ 31 https://www.androidpit.com/app/com.dzo.walkability i-PROGNOSIS-690494_D2.1.docx p. 30/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
environment that facilitate walkability and not to the way a user is actually performing his/her route.
Integration with i-PROGNOSIS: i-PROGNOSIS approaches the walkability from the user’s point of view and uses it as vehicle to identify any behavioural shifts from exploratory to monotonous walkability or less walkability. The ambition of i- PROGNOSIS is to combine activity type recognition (mainly focused on locomotive activity types), gait tracking to create patterns of time spent in each room/places, as well as transportation habits and the complexity of routing, in terms of increased variety and exploration of the environment, weighted by the level of familiarity and distance from a point of reference (e.g., home). This will enable the behavioural profiling of subjects, in order to detect declination of outdoors locomotive activities, such as walks, strolls and even reduction of in-house transitions, both of which are dominant in PD subjects and evolve as the state of the PD advances.
3.3.8 Sleep status evaluation
The need: Sleep disturbances, such as poor sleep quality, excessive daytime sleepiness, delays in falling asleep, and difficulty staying asleep, have been estimated to occur in ∼60–98% of patients with PD (J΄auregui-Barrutia et al., 2010; Covassin et al., 2012). Moreover, some studies have shown that sleep disturbances are negatively correlated with mood disorders in patients with PD (Boreket al., 2006; Zhang et al., 2013), whereas others have explored the relationships among depression, anxiety and sleep disturbances in PD patients (Fan et al., 2016). The complexity of sleep disorders relates with insomnia, restless legs syndrome, periodic limb movements of sleep, rapid eye movement sleep-behaviour disorder (RBD), sleep fragmentation and excessive daytime sleepiness. In fact, RBD are markers of prodromal PD and may influence the process of neurodegeneration (Dulski et al., 2015). Sleep problems frequently remain undeclared and/or under-recognised by someone; hence, sleep status evaluation could provide valuable information about the shift from healthy to PD status, before the appearance of the PD motor symptoms.
Key projects and applications: A two-year European project (2011-2012), namely ALL4REST32, was focused on the development of comfort-improved rest systems, using non-obtrusive technologies that promote deeper, more restorative sleep and prevent nocturnal awakenings. Within the global comfort improvement, physical and thermal parameters were investigated, establishing quantitative and qualitative evaluation of comfort and sleep quality system. Biomaterials and research of new ones, eco-friendly technologies and processes in fabrics destined to rest were employed so to allow the development of new products focused on obtaining an improved rest system, basically focusing at new biofibre-based clothes for nightwear. Although this project tackles the sleep quality, it does not account for the specific characteristics of PD and their relation to the sleep disturbances.
A two-year European project (2014-2016), namely BabyCareSleep33, was focused on developing a novel non-invasive intelligent monitoring system to prevent unexpected
32 http://www.all4restgo2market.com/ 33 http://babycaresleep.com i-PROGNOSIS-690494_D2.1.docx p. 31/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
deaths in previously healthy infants and to detect risky situations in an early stage. Integrated in the cot through biosensing textiles, matrices of sensors are used to detect the most relevant biological parameters that enable the detection of potential risky situation and performing preventive actions. The preventive system stimulates sufficiently the baby’s brain (generate a sleep arousal) avoiding infant's hypoxia and resuming breathing activity and goes so gentle to not awake the baby from sleep. This project relates with the sleep monitoring in babes and does not take into account the PD effects on sleep quality.
A three-year European project (2015-2017), namely PD_manager34, aims to build and evaluate an innovative, mhealth, patient centric ecosystem for Parkinson’s disease (PD) management. It also includes sleep data analysis but refers to already diagnosed PD patients, implementing a Decision Support Platform with suggestions for modifications in the patient’s medication trying to support him/her for self-managing of his/her condition.
Recently, applications/devices that make easier to figure out what specific sleep problems exist and help getting a good night’s rest have emerged. Amongst them the following exhibit some prominent functional characteristics:
ResMed S+35: This device sits on a nightstand and records light, temperature and sound to help pinpoint whether an overheated bedroom or a snoring partner cause wakening. It also plays sounds that sync with the user’s breathing, helping his/her drift off. Withings Aura36: This is an intelligent bedside clock, designed to look a bit like an old steamship funnel, connects to a long pad placed under the mattress to measure sleep patterns. At night produces read light and plays soothing sounds to evoke drifting off. It uses blue light and gentle music for the light sleep phase, making the waking process less jarring. Headspace37: This is a smartphone application that works as a beginner’s guide to mindfulness meditation so to help reduce anxiety and improve sleep. Fisher-Wallace Stimulator38: This FDA-cleared device uses cranial-electrical stimulation (“electrosleep”), a tiny current that passes between two electrodes placed on the head twice a day. It takes about two weeks to start having an effect and mainly tackles the insomnia problem. Acoustic Sheep SleepPhones39: This is a cloth band that fits snugly around the head and contains two tiny speakers connected by Bluetooth to a smartphone or music player, avoiding the discomfort of ungainly headphones. The idea is to listen to relaxing music with comfort truing to reduce insomnia.
From the above listed applications/devices, none of them is dedicated to or accounts for the PD specific characteristics that affect sleep quality.
34 www.parkinson-manager.eu 35 http://www.resmed.com/us/en/consumer/s-plus.html 36 https://www.withings.com/us/en/products/aura 37 https://www.headspace.com/ 38 http://www.fisherwallace.com/ 39 http://www.acousticsheep.com/ i-PROGNOSIS-690494_D2.1.docx p. 32/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Integration with i-PROGNOSIS: i-PROGNOSIS will combine sleep quality data (heart rate, accelerometer data, body temperature) from the user's smart watch in order to evaluate his/her state during sleep and in case of detected sleep disturbances it will automatically trigger a playlist of binaural beats-embedded sounds, stored in his/her smart phone/tablet, that will be transferred via Blue-tooth and wireless headphones to the user. The latter would be based on the use of a similar technology to Acoustic Sheep SleepPhones or other miniaturised headphones. The stimulation with the binaural beats (Oster, 1973) for the enhancement of sleep quality includes sound artefacts that evoke brain states in response to two similar pure tones being presented separately to each ear. The rhythm of the binaural beat equals the difference between the two tones and, if sustained, this rhythm can be entrained throughout the brain, a phenomenon called "frequency following response" (Krishnan, 2006). The frequency of the binaural beat can thus be selected to produce dominant brainwave frequencies associated with psycho-physiologic states such as calmness (Wahbeh et al., 2007). i-PROGNOSIS will transfer this effect to the sleep state and will use it as an auditory stimuli-based brain activity regulator, inducing to the brain a shift to lower frequency functionality (e.g., from gamma (>35Hz) to beta (13-35Hz), to alpha (8-12Hz), to theta (4-7.5Hz) and delta (0.5-3.5Hz) waves). The latter intervention will cease by the time the detected sleep quality indicates that the user fell in restful sleep. This concept constitutes an adaptive intervention that is triggered based on the users' behaviour during sleep and it is less obtrusive in terms that it does not require from the user to perform any actions.
3.3.9 Heart rate variability - ECG analysis
The need: Although further investigation is needed, past research suggests that subjects with PD exhibit changes in the cardiovascular patterns, as perceived through Heart Rate Variability (HRV) and Electrocardiographic (ECG) data analysis. In (Jain et al. 2012) the authors have performed a 14-year longitudinal study involving 5888 adults, among which 154 PD cases were identified; their conclusions highlight that ECG abnormalities occur prior to motor signs, thus potentially working as a pre- motor indicator or risk factor for PD diagnosis. Autonomic dysfunctions expressed by means of HRV indicators have been studied by (Alonso et al., 2015); in a study that involved 12162 subjects with an 18-year follow-up (average) where 78 PD cases were identified, the authors have found that decreased HRV was associated with an increased risk of PD, thus potentially providing added-value information early-stage assessment of the risk of developing PD. Also exploring the HRV, Soares and colleagues (Soares et al., 2013) have evaluated the differences in multiple HRV features between a group of 36 healthy control and 36 patients diagnosed with PD; their conclusions further reinforce the association between reductions in HRV indexes and PD, reflecting loss of balance between the sympathetic and parasympathetic nervous systems, which is hypothesised to be a result of the structural damages caused by PD. In a smaller study by (Valappil et al., 2010) that involved 11 controls and 11 untreated idiopathic REM sleep behaviour disorder patients, evidence has also pointed towards the use of HRV impairment as an early sign of PD.
Key projects and applications: In addition to the above-mentioned scientific work, the Michael J. Fox Foundation has funded the project “Assessing Heart Rate i-PROGNOSIS-690494_D2.1.docx p. 33/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Variability (HRV) in the Parkinson's Associated Risk Study (PARS) Cohort”40 in 2009, with the focus of evaluating the behaviour of HRV in PD patients. More recently, in 2011 a grant from The Parkinson Alliance has funded the project “Developing screening procedures for pre-motor Parkinson’s disease”(Burke, 2011), with the of identifying tools that can be used to screen for PD in the general population before the development of potentially motor or cognitive changes. The underlying technologies used in most of the work known to date, are mostly bound to short- term analysis from data collected using devices operating in a clinical setting, either using hospital cardiographs or Holter monitors.
Integration with i-PROGNOSIS: i-PROGNOSIS plans to build upon previous research and investigate explore novel acquisition methodologies, in particular, the growing trend towards the integration of biosignal sensing in convenient wearable devices has opened new horizons. An example of such devices is the Microsoft Band 241, developed by i-PROGNOSIS partner Microsoft, and which enables periodic acquisition of heart rate data in a user-friendly wrist-worn form factor. Collected heart rate data will be post-processed for feature extraction according to the well- established standards defined by the Task Force of The European Society of Cardiology and The North American Society of Pacing and Electrophysiology (Malik et al., 1996). The features resulting from post-processing will then be aggregated to the SData and analysed by the i-PROGNOSIS machine learning algorithms.
Besides HRV, in some research fields (e.g. affective computing), morphological analysis of the ECG waveform itself has been found to contain relevant information to improve the recognition rates of machine learning algorithms for example in the case of attention detection (Carreiras et al., 2012). As previously mentioned in the particular case of PD (Jain et al., 2012) have found that ECG abnormalities precede motor signs in patients later diagnosed with PD. Given that the Microsoft Band 2 only provides heart rate data, from which the ECG waveform cannot be derived, i- PROGNOSIS will also incorporate ECG sensing in the form of a novel sensor arrangement incorporated in smart TV remote control. Feedback for real-world users has shown a high receptivity to this concept. This development follows a recent research trend focusing on the development of sensors that are placed in everyday use objects (Silva et al., 2015), to provide more convenient and acceptable interfaces for the users (i.e. wearable devices need to be recharged often, people need to remember wearing them, styling may be an issue, etc.).
3.3.10 Bowel sound analysis
The need: Unlike flatulence, which is the sound made when gas leaves your body, bowel sounds typically occur in the small or large intestine during digestion. Bowel sounds range from normal to hyperactive, hypoactive or absent. This variety relates with the current intestinal activity and could be a good indicator of the existence of bowel dysfunction noticeable in constipation. The latter is one of the earliest non-
40 https://www.michaeljfox.org/foundation/grant-detail.php?grant_id=624 41 https://www.microsoft.com/microsoft-band/en-us
i-PROGNOSIS-690494_D2.1.docx p. 34/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
motor symptoms to be present in patients with PD (Korczyn, 1990). In fact, people with constipation are at a higher risk of developing PD compared with those without and constipation can predate PD diagnosis by over a decade (Adams-Carr et al., 2015). Constipation relates with decreased gastrointestinal motility associated with decreased activity and the increased sympathetic nervous system activity that occurs with anxiety (Maurer, 2015). The absence of flatus confirms the diagnosis of constipation leading to decreased (hypoactive) or absent bowel sounds; hence, the latter could serve as good indicators of constipation and they can be unobtrusively sensed.
Key projects and applications: To our knowledge, there is a clear absence of key projects that are devoted to the constipation problem in the context of PD. The only related, yet in the periphery, is the FP7-SME-2013 Primomed project (use of PRIMate MOdels to support translational MEDicine and advance disease modifying therapies for unmet medical needs), which focuses on advancing drug development for innovative treatment options for the chronic inflammatory and degenerative disorders, such as asthma, multiple sclerosis and Parkinson disease42. In the latter case, an effort was undertaken to find better symptomatic drugs that address certain PD symptoms, such as fatigue, constipation or balance.
Regarding the relevant applications, these refer to constipation symptom tracking, based on relevant information manually entered by the user, i.e.:
Tummy Trends43: Constipation and irritable bowel syndrome tracker, by Takeda Pharmaceuticals, which is an application of a personal guide designed to manually track symptoms associated with constipation and irritable bowel syndrome. It needs symptoms entering by the user, keeps tracking of meals, and warns for factors with negative effect. It provides graphic output and sharing of the reports with the doctor.
Melavie44: Developed by Biocodex, Melavie is an application that allows the user to manually track the status of his/her bowel movements over time. Melavie facilitates the management of constipation by the doctor, gathering information on the frequency of stool and the type of stool passed, compiled into graphs that can easily be shared with the doctor during the consultation.
Gi BodyGuard45: This application, developed under the medical advice of Canadian Digestive Health Foundation (CDHF), allows people with a digestive disorder to record and track factors relevant to their intestinal health, with the aim of recognising trends, and creating a summary of health information to be shared with the doctor during the next visit. Factors that can be recorded and tracked include: symptoms; pain (location and severity); food consumed; stool details (consistency, frequency, presence of blood); weight; exercise levels; medications taken; medical history.
42 http://www.primomed.fp7sme.eu/parkinson/ 43 https://itunes.apple.com/us/app/tummy-trends-constipation/id513358882?mt=8 44 http://www.medecingeek.com/melavie-une-application-pour-la-prise-en-charge-de-la- constipation/ 45 http://myhealthapps.net/app/details/401/Gi-BodyGuard-from-the-CDHF i-PROGNOSIS-690494_D2.1.docx p. 35/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Toilet diary46: This application is a bowel movement diary, with the visits to toilet manually entered by the user, as a means to create a pattern of his/her bowel movements.
Bowel Movement47: It is an application that allows the user to easily record his/her every bowel movement, including toilet time, shape of stool and special observation. It also provides with statistics information to let him/her clearly understand his/her bowel movement pattern over a period.
Toilet Tracker48: It is a lifestyle management and statistical analysis application, which allows the user to easily record details about toilet usage, providing charting of gathered data in the form of tables and graphs and scheduling reminders at a pre-set time after the last toilet use and integrating with social media (e.g., Facebook) to provide public notification of toilet use to friends.
Constipation Diagnosis Doctor49: It is a self-diagnosis medical application for constipation, designed to provide an instant diagnostic analysis of the user’s constipation symptoms by asking a series of relevant questions. The application, which is a form of artificial intelligence, will analyse the user’s answers and provide a list of the most likely diagnoses in order of their probability, along with their descriptions and relevant information.
All the above (key project and apps) do not propose any automated way for unobtrusively identifying the existence of constipation and all apps do not consider the special case of PD patients, who could not be so efficient to manually enter the relevant data to the apps.
Integration with i-PROGNOSIS: i-PROGNOSIS targets the unobtrusive capture of constipation; hence, it introduces an automated acquisition of bowel sounds as a vehicle that could lead to the identification both of its existence and classification of its severity level. This is a totally different approach from the ones followed in the literature, as a new bowel sound acquisition system will be structured in the form of IoT (smart belt), expanding the Bitalino acquisition board of PLUX (www.bitalino.com), by incorporating new methodologies of denoising and feature extraction (Hadjileontiadis et al., 2000; Hadjileontiadis & Rekanos, 2003a, 2003b; Hadjileontiadis, 2005a, 2005b; Taplidou & Hadjileontiadis, 2010; Hadjileontiadis, 2015). The way the relevant information will be communicated to the user will be based upon the most accepted data representation already adopted by the reviewed relevant apps (e.g., graphs, statistics etc.), complying with the users’ requirements and physicians’ guidelines.
46 https://play.google.com/store/apps/details?id=com.eonsoft.DefecationDiaryV2&hl=en 47 https://play.google.com/store/apps/details?id=com.acj0.bowelmove&hl=en 48 https://play.google.com/store/apps/details?id=com.beaksoft.android.toilettracker&hl=en 49 https://play.google.com/store/apps/details?id=com.easydiagnosis.constipation&hl=en i-PROGNOSIS-690494_D2.1.docx p. 36/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
3.3.11 Food intake curve
The need: Significant weight reduction is a well-documented fact in PD patients, with Body Mass Index (BMI) reduction <20 kg/m2 often reported (Kistner et al., 2014), no matter if the disease is prevalent across all BMI groups, from underweight to overweight individuals (Morales-Briceño et al., 2012). The weight loss (Lebouvier et al., 2009) and the disturbance in eating behaviours (Lorefält et al., 2006), largely caused by dysphagia and deteriorated swallowing function, in turn affecting food type selection (e.g., preference to semi-solid diets, (Lorefält et al., 2006), often predate the initial diagnosis, probably reflecting the early degeneration of the dopaminergic system (Gaig & Tolosa 2009). As the disease progresses, the effects on the body weight and the eating behaviours of the patients become more prominent (Sheard et al., 2013), and there is an increased risk of malnutrition (Fereshtehnejad et al., 2014). On the other hand, deep brain stimulation (Barichella et al., 2003) and the use of dopamine agonists (Kumru et al., 2006) are associated with significant weight gain in PD patients while in care (Barichella et al., 2009). In practice, the limited amount of objective data due to the predominant use of self-reporting concerning eating behaviour in PD, result into incomplete understanding of the precise eating behaviour changes and nutritional characteristics in the disease (Sheard et al., 2013). In i-PROGNOSIS, nutritional and eating behaviour monitoring and interventions, especially related to the food intake curve can be a valuable contribution to the understanding of the PD process and need of care.
Key projects and applications: In the past, intake curve analyses have not been used for the quantification of the eating behaviour mechanics in PD. However, the use of similar methodologies in clinical (Bergh et al., 2013), experimental (Ioakimidis et al., 2011) and real life settings (EU project “SPLENDID"50) have contributed a lot on the general understanding and the development of the mechanics of eating, allowing for the development of successful methodologies for the modification of eating habits (Bergh et al., 2013). Specifically, the Mandometer – a weighting scale that counts the progressive weight changes from a plate with food during a meal, augmented with new algorithms, used to compute the food intake curve characteristics reliably and effortlessly (Papapanagiotou et al., 2015), will simplify the process of analysing and modifying eating behaviours in PD.
Integration with i-PROGNOSIS: In i-PROGNOSIS, during the SData stage, when specialised data are collected, we plan to investigate the distribution of food intake parameters in individuals with PD-derived eating disturbances, and test their association with other PD-related scores. After the identification of suspect behaviours, in the intervention phase, users will be trained, via gamification, to eat optimally as far as the behavioural elements affecting food intake are concerned (e.g., bite, chewing and swallowing frequency) in a virtual environment. The changes of these behavioural characteristics will be evaluated through Mandometer meals, collected repeatedly from each user. Continuous, longer term personalised
50 http://splendid-program.eu/
i-PROGNOSIS-690494_D2.1.docx p. 37/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
behavioural training of the user, on a virtual environment and during real-life meals, will ensure the improvement of the relevant behavioural characteristics.
3.3.12 Body and hand gestures
The need: It is well-known that motor impairments are an important symptom of PD. For this reason, recently, many techniques using wearable sensors have been developed that can provide detailed information about such problems that PD users usually have to deal with, allow for interventions that can alleviate this problem and monitor their progress.
In (Starner, 2000), a wearable device that recognises hand gestures for home use and medical monitoring is presented. (Al-Jawad, 2012) and (Adame, 2012) present application of inertial sensors and corresponding algorithms to automate the Timed Up and Go (TUG) (Brusse, 2005), which is a clinical test used widely to measure balance and mobility, e.g. in Parkinson’s disease (PD). Maetzler (2013a) presents a review on recent therapeutic interventions for Gait disability and balance impairment, discussing the associated opportunities and challenges. In the work of Maetzler (2013b), a review of recent literature on wearable sensors for PD patients is presented. More specifically, the article discusses promising wearable technology, addresses which parameters should be prioritised in such assessment strategies, and reports about studies that have already investigated daily life issues in Parkinson’s disease using this new technology. Regarding motor disabilities, the article focuses on wearable technologies for dealing with the following symptoms and signs: Axial disability (gait and transfer deficits, freezing of gait, balance deficits, and falls), distal bradykinesia, dyskinesias, tremor, dysarthria and sedentary lifestyle and physical inactivity. In the work of Al-Jawad (2013), an extended Kalman filter is used to measure postural instability evaluation (e.g. of PD patients), by using data from low- cost MEMS inertial sensors attached on the lower back of the person.
Key projects and applications: The specific and ultimate goal of the REMPARK project51 was to develop a Personal Health System (PHS) with closed loop detection, response and treatment capabilities for management of Parkinson's Disease (PD) patients at two levels: a) At the first level, the project developed a wearable monitoring system able to evaluate the motor status of the PD patients. It also developed a gait guidance system able to help patients during their daily activities. b) At a second level, the intelligent analysis of data provided by the first level, supported with a disease management system will allow the neurologist in charge to access accurate and reliable information and decide about the treatment that best suits the patient.
The complete REMPARK system consisted of a sensor worn at the waist, a smartphone acting as a gateway for sending and receiving information, a server receiving the data and communicating with medical staff, an auditory cueing system and a sensory functional electrical stimulation device.
51 http://www.rempark.eu/ i-PROGNOSIS-690494_D2.1.docx p. 38/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The aim of the SENSE-PARK project52 was to develop an unobtrusive and empowering information system for use in the home environment, which provides PD patients with practical, engaging and motivating tools to monitor patterns in their condition.
CuPiD53 was a 3 year EU project to provide personalised rehabilitation exercises for people with Parkinson’s disease at home. It developed and tested a combination of services for at home rehabilitation and training of major motor impairments caused by PD. Key components of the CuPiD solution are: 1) a home-based rehabilitation system (based on unobtrusive wearable sensors, on-board intelligence for real-time biofeedback, virtual reality, and modular, multi-modal restitution interfaces); and 2) an intelligent telemedicine infrastructure for remote monitoring and supervision of the rehabilitation program by a clinician
The HELP Project54 consortium designed a Health Monitoring System specifically targeted for the needs of Parkinson Disease (PD) patients. The HELP System (“Home- based Empowered Living for Parkinson’s disease patients”) proposed solutions to improve the quality of life of PD patients, including a Body Sensor and Actuator Network (BS&AN) made up of portable/wearable and home devices to monitor health parameters (e.g. blood pressure) and body activity (e.g. to detect gait, absence of movement), and to release a controlled quantity of drugs in an automatic fashion.
Integration with i-PROGNOSIS: Using sensor data and algorithms to monitor analyse body and hand gestures will be a central feature in i-PROGNOSIS project. There is significant work, both in literature and recent projects, for using wearable sensors to detect motor impairments, design treatment interventions and monitor the progress of PD patients. i-PROGNOSIS will carefully study this previous work and extend it a) using modern sensors such as smartphones /smartwatches/bands b) defining algorithms for early warning for motor impairments in normal subjects c) designing new personalised behavioural health interventions centred on physical activity.
3.3.13 Serious games
The need: Serious games contribute in detecting and reducing specific motor and non-motor symptoms of Parkinson’s disease (Barry, Galna, & Rochester, 2014). In particular, the areas that are positively influenced by Exergames are gait, bradykinesia, rigidity, range of motion, balance, coordination and stooped posture (Pachoulakis, Papadopoulos, & Spanaki, 2015). There is also a big impact on the psychological level such as self-esteem, socialisation and quality of life, and moreover on cognitive levels such as learning ability, dual task performing and memory improvement (Assad et al., 2011).
Key projects and applications: Two research groups collaborated to produce nine "clinically inspired" games, similar to Wii and Kinect games to improve coordination
52 http://www.sense-park.eu/ 53 http://www.cupid-project.eu/ 54 http://www.aal-europe.eu/projects/help/ i-PROGNOSIS-690494_D2.1.docx p. 39/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
in people with Parkinson's disease as part of the project55 “Computer Games Help People with Parkinson's Disease” in 2008. Twenty participants were involved with moderate levels of the disease. After playing the games for 12 weeks, 65% of game players demonstrated longer stride length, 55% increased gait velocity, and 55% reported improved balance confidence.
A three-year European Collaborative project called "CuPid"56 kicked off in 2011 involving 30 patients and aiming at improving motor function and reducing disability and social isolation. The project relied on custom and wearable sensors and provided a home-based rehabilitation system, tailored to the patient's needs and the principles of motor learning in Parkinson’s disease.
Furthermore, Assad et al. (2011) developed a collection of five motion-based games designed for the Parkinson's disease named "WuppDi". The research implicated 13 patients, in order to help the patient enjoy rehabilitation at home. Results revealed a positive motivational effect of WuppDi, but also the limitation of being used by individual patients on their own.
More recently, McNaney et al. (2015) designed a fruit-picking game called "SCRUMP” which encouraged upper and lower limb movement. The study, involving eight patients, emphasised on designing real world activities, providing positive feedback, developing dynamic adjustments. It finally highlighted the factors that motivate patients for supporting long-term engagement of Exergames at home.
Macedo et al. (2014) conceptualised a game, which proposed series of challenges and mini-games in order to promote amplitude, complexity, speed, working memory, visual exploration and divided attention. The trial, involving four patients, insisted on the fact that the game should be simple, as close as possible to reality, as flexible as possible and that it should assess parameters of performance.
The aforementioned projects identified useful requirements regarding serious games and showed that there is great potential in developing them further. Serious gaming constitutes a promising field for improving multiple aspects of patient's conditions and there is still more research to be conducted in the near future. The fact that the emergence of serious games does not go too far in the past, along with the fact that only recently the perception of employing serious games in therapy and rehabilitation contexts started to change and serious games are now considered as a tool for new treatment options (Robert et al., 2014), justifies the rather limited number of works on the field (Barry et al., 2014). In addition, a significant number of these studies are mainly suggesting serious games or development of Exergames that have not been evaluated by patients with Parkinson’s.
Integration with i-PROGNOSIS: i-PROGNOSIS will develop a unified solution for a battery of serious games ranging from Exergames, Dietary and Emogames to Handwriting and Voice games towards a holistic rehabilitation program for the Parkinson's patients. i-PROGNOSIS serious games design will follow a participatory
55 https://nursing.ucsf.edu/news/computer-games-help-people-parkinsons-disease 56 http://www.cupid-project.eu/project i-PROGNOSIS-690494_D2.1.docx p. 40/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
approach, in accordance with the co-creation principles, where professionals and patients with Parkinson’s will be involved from the early stages of design. Requirements, guidelines or considerations stemming from the literature will be adopted by the Web-based FitForAll (Konstantinidis, Bamparopoulos, & Bamidis, 2016) serious gaming platform for the Parkinson's patients. i-PROGNOSIS serious games will focus on the intervention aspects (Konstantinidis, Billis, Mouzakidis, et al., 2016) and especially on mitigating the deterioration while continuously and unobtrusively assessing (formative assessment) the user’s cognitive and physical status (Konstantinidis, Billis, Bamparopoulos, Papageorgiou, & Bamidis, 2016; Konstantinidis, Bamidis, Billis, Kartsidis, & Papageorgiou, 2016; Konstantinidis, Antoniou, & Bamidis, 2015), as well as on the intensity of the detected symptom. In order to maximise the detection resolution and the engagement levels, i-PROGNOSIS introduces the adaptation algorithms towards keeping the user in the “flow zone” which represents the feeling of being complete and energised focus in an activity with a high level of enjoyment and fulfilment. Finally, recognising the potential contribution of the serious games performance, i-PROGNOSIS serious games incorporate an ontology for publishing open gaming data (Bamparopoulos, Konstantinidis, Bratsas, & Bamidis, 2016).
4 OVERALL PROCESS FOR THE IDENTIFICATION OF USER REQUIREMENTS
4.1 AIMS AND OBJECTIVE
The main aim of the initial phase of Task 2.1 is the identification of the first version of detailed user requirements regarding the i-PROGNOSIS system, including both the detection and the interventions aspects of the system, as well as the detailed definition of usage scenarios. The pool of users includes the main target groups of people aged over 40 years that are at risk of PD and already diagnosed PD patients, as well as health care professionals (e.g. PD expert physicians) and carers of patients. Due to the holistic nature of the proposed system and the diversity of target user groups, the objective was to systematically capture detailed user requirements by employing the following steps:
Exploiting the expertise of the members of the i-PROGNOSIS consortium to identify the initial set of user requirements, through face-to-face sessions between clinical, user-oriented and technical partners. Capturing the opinion of main potential stakeholders of the i-PROGNOSIS system to further shape or enrich the initial set of user requirements, through the organisation of focus groups (small scale survey) and Web questionnaires (large scale survey). Elaboration and granulirisation of the users-shaped requirements to produce the first detailed version of user requirements based on usage scenarios and respective business processes.
The following sections provide the details on how the aforementioned steps, forming the overall process for the identification of user requirements, were realised. i-PROGNOSIS-690494_D2.1.docx p. 41/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
4.2 THE GLOSSARY
4.2.1 Glossary design
Since the i-PROGNOSIS Glossary is meant to be the result of the joint effort by all the partners, thus reflecting the wide variety expertise present in the Consortium, the tool chosen to implement it was a dedicated page in the i-PROGNOSIS site, as this will allow all the partners to easily add/integrate/modify/review definitions.
Thus the i- PROGNOSIS Glossary will encompass definitions for:
‘wide’ terms that are key to the project and to the research field in general (e.g.: Active and Healthy Ageing, Parkinson’s Disease, i-PROGNOSIS Community, Smart devices, Internet-of-Things (IoT)); technical terms that are relevant to the project and require a very precise and in-depth understanding (e.g.: behavioural vector, GData, SData, Exergames, dietary game, emotional games, distributed learning); terms specific to a single research domain but needs to be disambiguated as they are closely related to other research domains (e.g.: gaming scenario, EatWell Plate model, empathy level).
4.2.2 Glossary realisation
The glossary has been set up by AUTH with the support of KCL and TUD. Furthermore, usage guidelines have also been developed in order to support the consortium members.
Presently the structure of the Glossary encompasses definitions and sources. Thus, each page can include a basic definition (with its sources), but also alternative definitions (and further sources) (see FIGURE 5).
The completion of the Glossary is an ongoing process that has just started, but nevertheless Glossary will be updated along the project. It is available through the project website at: http://www.i-prognosis.eu/?page_id=1179.
4.3 CONSORTIUM FACE-TO-FACE SESSIONS
Consortium face-to-face sessions constituted the stepping stone and the main source for the identification of user requirements. The latter sessions refer only to meetings of experts participating in the i-PROGNOSIS consortium. Towards the identification of user requirements, the sessions that took place were:
Project Kick-off meeting in Thessaloniki, Greece (February 2016): The meeting paved the way and identified the initial set of generalised user requirements. Two separate workshops were organised the second day of the meeting, a medical and a technical one, involving medical partners and technical partners, respectively. The workshops provided also the general guidelines on which the focus groups questionnaires and the Web survey questionnaires were based, as well as issues of concern that had to be clarified by the target user groups. i-PROGNOSIS-690494_D2.1.docx p. 42/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Sessions between technical teams located in Thessaloniki, Greece (March and May 2016, Thessaloniki, Greece): Two face-to-face sessions between members of the technical teams of AUTH and CERTH were also organised. The latter sessions elaborated on the initial identified set of generalised user requirements and resolved issues relating to the interaction of the users with the technologies involved in i-PROGNOSIS. Second project meeting in Lisbon, Portugal (May 2016,): The meeting served, amongst others, to refine the detailed user requirements and identify any missing ones. Three workshops were organised the second day of the meeting, i.e., a workshop about the i-PROGNOSIS PD detection approach, a workshop related to the i-PROGNOSIS supportive interventions, and a workshop regarding the general user experience and data management. In all workshops, members of technical partners as well as medical or user-centric partners were present to holistically refine the user requirements.
In between the aforementioned consortium face-to-face sessions, technical members of AUTH were producing the usage scenarios, the related business processes and the detailed user requirements regarding the i-PROGNOSIS system as an end product, which were constantly refined based on the sessions feedback and the results of the focus groups and the Web surveys. AUTH technical members in collaboration with other partners' technical teams evaluated the identified user requirements in terms of importance, development priority and risk. Finally, medical partners evaluated the identified user requirements in terms of clinical value.
FIGURE 5 The Glossary-dedicated Web page of the i-PROGNOSIS website.
i-PROGNOSIS-690494_D2.1.docx p. 43/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
4.4 FOCUS GROUPS
4.4.1 Design of questionnaires
Phase 1: During the first stage, a collection of potentially relevant user requirements was compiled by KCL. This compilation was sent out by KCL to all partners, in order to obtain their comments and suggestions for any additional relevant matters to be included in the questionnaire. In addition, KCL organised focus group meetings to ask potential users, as well as health care professionals, for any subjects to be covered. Following the first consortium face-to-face meeting, KCL held the following focus group sessions: An expert patient group meeting, including 4 males and 7 females, (total 11); patients (3), carers (2), patient group representative (1), physicians (2), and researchers (3). An evening meeting, which involved 9 males and 13 females, (total 22); users: patients and carers (11) and healthcare professionals (11), consisting of physicians (3), therapists (2), researchers (4) as well as PD specialist nurses (2).
Phase 2: Taking into account all responses and relevant information on devices and sensors by technical partners, a draft questionnaire including all suggestions and comments was composed and circulated to all partners for use in their individual focus groups, including health care professional focus groups and patient/ user focus groups. All clinical partners provided feedback and comments on the user requirement questionnaire, with a particular focus on:
The i-PROGNOSIS mobile PD detection application and consenting process. All devices and sensors (Smartwatch, Smart belt, smart TV remote and Mandometer) planned to be used for PD detection, as well as monitoring of users during interventions. Interventions including matters on the respective application, the personalised game suite and the assistive interventions.
Phase 3: KCL reviewed all the received comments and suggestions from partners and compiled a final paper questionnaire (see Appendix I).
4.4.2 Focus groups set up and organisation
KCL Focus groups
The process of setting up the focus groups started with identifying who would be:
a) Potential users of the application and b) Healthcare professionals who would be able to judge which features are required to capture clinically relevant details and to protect the required confidentiality of the users.
Once the users were identified, it was then possible to set up focus groups specific to the different groups of people e.g. patients/users/carers and healthcare professionals; such as medical doctors, nurses, allied health specialists, therapists etc. The focus i-PROGNOSIS-690494_D2.1.docx p. 44/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
groups were set up to identify useful and informative data collection, user requirements and usability issues.
KCL made use of different types of focus group meetings: 1) Expert patient group meetings (CRISP)- Community for Research Involvement and Support for people with Parkinson’s 2) Health care professional (HCP) focus groups (Multi-disciplinary team meetings); 3) Evening meetings including patients, carers and HCPs 4) Patient and users focus group meetings
AGE Interviews Per se, AGE has not conducted focus groups. As AGE is a European wide organisation, its members are scattered all over Europe and it was not feasible to organise a physical focus group within a reasonable timeframe. The alternative of a focus group at distance has been considered; but from the past experience, it is not the best solution to get real added value: participants feel less comfortable, there is a tendency to have two/three people leading the conversation and most of our members do not have an IT system that allows video conferencing – even via Skype – in a stable way. In this vein, AGE decided to organise bilateral interviews at distance, with one of them being a physical interview.
It should be underlined that while each interviewee was asked to answer from his/her point of view, they were also asked to give a feedback regarding their friends/relatives and on older people in general in their country wherever possible. The interviews were conducted in a quite flexible way starting from a general understanding of the i-PROGNOSIS project going through the use of new technologies in general and then in relation to the project.
AGE has brought together 10 different task forces which allow them to decide which topic(s) they want to follow and contribute to. Two task forces are relevant to the i- PROGNOSIS project:
Task force on healthy ageing (35 persons) Task force on accessibility, new technologies and mobility (40 persons)
A call for expression of interest to participate in an interview has been launched to the two task forces on the 4th of March with a set of possible dates. Considering the small number of answers, bilateral reminders were sent. Between the 11th of March and the 8th of April, seven interviews have been conducted with a diverse participation of: 4 males, 3 females, with average age of 70 years old, from the countries of the Netherlands, Sweden (2), United Kingdom, Malta, Greece, and Iceland.
TUD Focus groups
Regarding the definition of user requirements of the i-PROGNOSIS system, focus groups of healthcare professionals have been organised. Three different focus groups i-PROGNOSIS-690494_D2.1.docx p. 45/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
were designed: physicians (older and younger aged), nurses and physician assistants. With each of the three focus groups of healthcare professionals a discussion round was held. In these discussion rounds general aspects of user requirements for the i- PROGNOSIS application were discussed and the provided paper questionnaire of user requirements was used for orientation. Furthermore, healthcare professionals of each group, who could not join the discussion round, were provided with a paper questionnaire for completion.
AUTH Focus groups
Towards the identification of user requirements AUTH organised three focus groups with medical experts, healthy subjects and PD patients. More specifically, the first focus group was composed of 12 neurologists (5 males – 7 females) aged 47.3 ± 9.2, eight of whom were specialized in movement disorders. The second focus group was composed of 15 healthy, non-experts (7 males – 8 females) aged 55.6 ± 10.4 and the third focus group was composed of nine PD patients (7 males – 2 females) aged 66.7 ± 5.1. All focus groups took place at the 3rd University Department of Neurology, G. Papanikolaou Hospital, Thessaloniki, Greece, between 29 March and 4 April 2016. Prior to the focus groups discussions, the coordinator of each focus group briefed the participants about the key objectives of the project and the technology that is intended to be used. The questionnaire, on which the focus groups discussions were based, was translated into Greek by Greek native speakers with excellent knowledge of English.
For all the aforementioned actions a set of guidelines was established to facilitate the discussion process and maximize the value of the outcomes (see Appendix III).
4.5 WEB SURVEYS
4.5.1 Design of Web questionnaires
Apart from the focus groups, a Web survey was conducted in order to identify user requirements, define system specifications and, more generally, evaluate and testify the i-PROGNOSIS concept. The Web survey was performed via a specifically designed Web questionnaire. The Web questionnaire consists of four parts:
Part I: Provides an introduction to i-PROGNOSIS project, describes the aim of the questionnaire and identifies if the participant is: i) a Parkinson’s disease patient, ii) a healthcare professional or carer, and iii) a healthy person.
Part II: Includes general demographic questions
Part III: Includes questions regarding the Parkinson’s disease detection functionality of the system. More specifically, there is a small description along with questions about the smartphone application that is planned to be developed, the smartwatch, the smart belt, the Mandometer plate-scale and the TV smart remote control.
Part IV: Includes questions regarding the interventions functionality of the system. More specifically, there is a small description along with questions i-PROGNOSIS-690494_D2.1.docx p. 46/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
about the electronic games, night-time intervention, gait intervention and voice enhancement intervention.
Parts II and III apply to all participant, while Part IV applies only to healthcare professionals/carers and Parkinson’s disease patients. The Web questionnaire was based on the focus group questionnaire and the number of questions was kept as small as possible in order to facilitate participation.
4.5.2 Realisation and dissemination
The Web questionnaire was realised in Google Forms that is a free, convenient and fully customisable tool to create and analyse surveys. It supports various types of questions, page branching and question skip logic. Google Forms supports the major Web browsers and is responsive, which means that the Web-questionnaire adapts to the screen size of the device used to access the questionnaire. The responses to the questionnaire are neatly collected in Forms and can be extracted in Google Sheets for further processing.
The questionnaire was originally developed in English and later translated in five languages, i.e., German, French, Swedish, Portuguese and Greek, with the aid of the corresponding partners. The translation was performed by native speakers who are familiar with the context of i-PROGNOSIS. During the process of translation, the emphasis was on conceptual approach rather than literal (word-for-word) translation, as well as the use of natural/acceptable language for the broadest audience. Moreover, in order to keep the same structure and logic of the original questionnaire (English version), as well as to find the most appropriate translation for difficult terms, opinions from local/national and bilingual experts in the field of ICT and with experience in translation were considered.
The questionnaires are accessible via a dedicated webpage57 in the i-PROGNOSIS website (see also Appendix II). Moreover, a quick access image was added to the “slider” module at the front page of the i-PROGNOSIS website. All the partners of the consortium put significant effort in order to circulate and disseminate the Web survey through appropriate channels to their network. Some exemplary dissemination actions are:
Web questionnaire circulation to all faculty members of Aristotle University of Thessaloniki. Press release by COSMOTE58. SMS sending to the subscribers of COSMOTE who are aged over 40 years old. Article in the newsletter of BAGSO59 that is the umbrella organisation of older people in Germany.
57 http://www.i-prognosis.eu/?page_id=1084 58 https://www.cosmote.gr/fixed/corporate/media-center/news/details/- /asset_publisher/wpF6f9kWWozI/content/i-prognosis-ερευνητικο-εργο-για-τη-νοσο-του- παρκινσον-με-τη-συμμετοχη-της-cosmote 59 http://www.bagso.de/index.php?id=1862 i-PROGNOSIS-690494_D2.1.docx p. 47/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Article in the newsletters of Senior Actu60 and AgeVillage61 that focus on ageing issues. Dissemination as part of MICROSOFT networks, including the professional social network Yammer that is being used inside MICROSOFT. Dissemination through channels of the European Parkinson's Disease Association (EPDA). Dissemination to UNIVERSIA Portugal, Academia Cruz Vermelha Portuguesa elderly group, Portuguese Association of Parkinson's Disease Patients and Raríssimas Association . It should also be highlighted that the Web survey will not cease by the submission date of the current deliverable (end of June 2016). On the contrary, it will continue to be active until the definition of the final version of user requirements in deliverable D2.4 (May 2018), so as to be able to gather and consider as many opinions as possible and identify potential changes in the trends of the target group.
4.6 ANALYSIS AXES
For the efficient analysis of the Web survey results, the responses to all six questionnaires were accumulated and processed collectively. A simple, yet adept, statistical analysis took place in order to extract the frequencies of each available response for the majority of questions. Only the responses of participants that were aged over 40 were considered in the above procedure because younger participants do not constitute the target group of the project and are not the prospective users of the system. The statistical analysis of the responses was conducted separately for the three participant categories, i.e., healthy, patients and healthcare professionals/carers, in order to identify potential diverse opinions and needs. The analysis results are presented in the following section in the form of stacked bar plots for a more conclusive interpretation.
4.7 COMPLEMENTARY INFORMATION FROM EUROBAROMETERS
Eurobarometers are surveys conducted at European scale on different topics. Eurobarometers that were taken into consideration for shaping the first version of user requirements are presented below along with summarised key points:
E-Communications and Telecom Single Market Household Survey of January 2014 (Ebs 414)62: The key points of the survey indicate a significant proportion of potential i-PROGNOSIS users aged 55+ and, specifically, for the age group 55-64, 64% of households have an internet connection. The percentage is similar for the age group 30-59 as well. Nevertheless, the availability of internet access declines as the age increases. It is noted here that the i-
60 http://www.senioractu.com/Parkinson-participez-a-l-enquete-du-projet-europeen-i- PROGNOSIS_a19045.html 61 http://www.agevillage.com/index.php5 62 European Commission. Special Eurobarometer 414 / Wave EB81.1 - TNS opinion & social (2014). http://ec.europa.eu/public_opinion/archives/ebs/ebs_414_en.pdf i-PROGNOSIS-690494_D2.1.docx p. 48/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
PROGNOSIS system operations will depend heavily on home internet connection. The aforementioned percentages do not differ significantly in the specific case of broadband internet connection. A special Eurobarometers dedicated to Data Protection has also been published in March 2015 (Ebs 431)63: Europeans have widespread concerns about the misusage of their data. More than two thirds of respondents who feel that they do not have complete control over their personal data say they are concerned about this lack of control. At the same time, less than a fifth of the respondents admit that they fully read privacy statements when they are asked to provide personal information online, mainly because they are too long or difficult to read. The Qualitative Study on Future Innovation, Science and Technology published in June 2015 provides additional interesting insights64: Older people, while expressing the same concerns as above, were often more troubled about being “left behind" – unable to keep up with the advances of the technology and the skills required to take advantage of the benefits that it offers. Older people were just as concerned about being “side-lined” – being made redundant in a less literal sense and having less control, less choice, being made to feel of no purpose even in their homes. Older people were also more likely to be concerned about accessibility – not just intellectually but financially. Older people also tended to be more concerned about the implications of these advances on data security. Younger people who grew up in the digital age were just as likely to mention these concerns (more aware perhaps of the implications regarding data security) but tended to be less troubled, in general, than older people. Instead, they were more worried about specific (mis)usage of this data.
5 RESULTS
5.1 FOCUS GROUPS OUTCOMES
This section presents qualitatively the key outcomes derived from the focus groups and relate to user requirements and concerns, in the form of discrete observations (FGO#). The detailed outcomes for each focus group are provided in Appendix IV. The reader is referred to Section 6.2.2 "System Components" for clarifications on terminology.
User requirements
FGO1 Privacy, anonymisation and data protection is very important for the i- PROGNOSIS project
63 European Commission. Special Eurobarometer 431 / Wave EB83.1 – TNS opinion & social (2015). http://ec.europa.eu/public_opinion/archives/ebs/ebs_431_en.pdf 64 European Commission. Special Eurobarometer 431 / Wave EB83.1 – TNS opinion & social (2015). http://ec.europa.eu/public_opinion/archives/ebs/ebs_431_en.pdf i-PROGNOSIS-690494_D2.1.docx p. 49/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FGO2 There must be versions of the i-PROGNOSIS application in different languages.
FGO3 The consent form must be carefully structured and clearly state what data will be captured, the reason why and how they will be processed and exploited.
FGO4 The consent form must be readable with ease on the display of a mobile device.
FGO5 There must be an option for the users to withdraw their consent.
FGO6 Photos of users processed must be anonymised also.
FGO7 Brief instructions when installing the i-PROGNOSIS application are preferred instead of extensive instructions
FGO8 Notifications and feedback via the i-PROGNOSIS detection application should not be included as this may affect the users' natural use of their smartphones and, in turn, this could skew the collected data.
FGO9 The system must include technical support.
FGO10 The smartwatch/fitness tracker must support regular watch functionalities, i.e., display the time and provide alarms.
FGO11 The smart belt must be thin, light and comfortable, with a clear indication of which way the belt should be worn. Its materials must be soft and hypoallergenic in order to be worn directly on the skin.
FGO12 The i-PROGNOSIS detection application must not provide feedback regarding the ECG captured by the smart TV remote, as this may distress users.
FGO13 Feedback regarding captured data provided by the i-PROGNOSIS applications must be provided as a summary on a weekly/fortnightly basis.
FGO14 Headphones involved in the targeted nocturnal intervention must be comfortable and soft.
FGO15 The gait rhythmic guidance intervention must be capable of intervening automatically.
FGO16 The voice enhancement intervention is considered useful.
FGO17 Accessibility must be seriously taken into consideration in designing the i- PROGNOSIS applications.
FGO18 Services and processes of the i-PROGNOSIS applications must not have significant impact on the battery life of mobile devices.
Concerns i-PROGNOSIS-690494_D2.1.docx p. 50/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FGO19 There were concerns about the smartphone and new technology in general penetration in the elderly population.
FGO20 There were concerns about the availability of internet connection at homes of the elderly population.
FGO21 There were concerns about the usefulness of capturing eating mechanics using the Mandometer and the user friendliness of capturing constipation data using the smart belt during the i-PROGNOSIS detection phase.
FGO22 There were concerns about the user acceptance of the targeted nocturnal intervention.
FGO23 The role of the physician must remain central in the process of PD diagnosis.
FGO24 Reliability of the i-PROGNOSIS applications must be reassured before making them available to the public as the first experience must be positive in order not to discourage users.
5.2 WEB SURVEYS RESULTS
This section provides the quantitative results of the Web surveys. Each question of the survey is presented along with a percentage histogram based on the answers of three groups of users, i.e., healthy adults over 40 years of age (Healthy), PD patients (Patients) and experts (physicians or caregivers) with experience in PD (Experts). Each of the questions is accompanied by a brief observation deduced based on the results.
Results presented in this section are based on answers from 877 Web survey participants, 648 belonging to the Healthy group (> 40 years old), 114 belonging to the Patients group and 115 belonging to the Experts group, received by the beginning of June, 2016. At the time of the writing of this report, the number of participants has risen to 1728 (all ages), due to extensive dissemination efforts by partners. After a first screening of the updated results, the vast majority of observations are not affected. The small number of observations affected will be taken into consideration during the first development cycle of the i-PROGNOSIS system and the updated Web survey results and observations will be presented in the second version of the present deliverable (D2.4 "Final version of user requirements analysis") on month 28 of the project.
The list of questions, the respective results and observations (WO#) follows:
Answered by all groups
Q1: Do you use a smartphone?
i-PROGNOSIS-690494_D2.1.docx p. 51/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Yes No
HEALTHY 96% 4%
PATIENTS 72% 28%
EXPERTS 91% 9%
WO1: The majority of the target group uses a smartphone; thus, the fundamental i- PROGNOSIS concept idea is solid.
Q2: If you do not own a smartphone and if you knew that it could help monitor and potentially improve your health status, would you buy one and how much would you spend (contract free)?
Yes, 100 €-200 € Yes, 200 €-400 € Yes, 400 €-600 € Yes, >600 € No, I would not buy one
HEALTHY 32% 29% 12% 13% 14%
PATIENTS 42% 32% 4% 20%
EXPERTS 50% 17% 8% 25%
WO2: Even if members of the target group do not own a smartphone, the majority of them are willing to pay at least 100€ to buy one, so the i-PROGNOSIS concept is further grounded.
Q3: Do you use a smartwatch/fitness band?
Yes No
HEALTHY 8% 92%
PATIENTS 13% 88%
EXPERTS 10% 90%
WO3: The majority of the target group does not own a smartwatch/fitness band, so it should be an optional feature or it should be provided by the project.
Q4: If you do not own a smartwatch/fitness band and if you knew that it could help monitor and potentially improve your health status, would you buy one i-PROGNOSIS-690494_D2.1.docx p. 52/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
and how much would you spend?
Yes, <100 € Yes, 100 €-150 € Yes, 150€ -200 € Yes, >200 € No, I would not buy one
HEALTHY 37% 11% 10% 19% 23%
PATIENTS 36% 10% 15% 19% 21%
EXPERTS 30% 14% 14% 18% 25%
WO4: Even if the target group does not own a smartwatch/fitness band, the majority is willing to buy one. So, if it proves to be useful, the smartwatch/fitness band-related functionalities will have a great potential.
Q5: How often (on average) do you use your phone/smartphone for writing text messages (SMS) per week?
Every day 4-5 days 2-3 days 1 day Rarely Never
HEALTHY 53% 15% 18% 6% 6%
PATIENTS 52% 5% 11% 5% 15% 12%
EXPERTS 59% 12% 22% 6%
WO5: Only 50% (approximately) of the target group writes SMSs every day. So, the sentiment analysis through SMS functionality should be of low development priority.
Q6: How often (on average) do you use your phone/smartphone for writing posts on social media (like Facebook, Twitter) per week?
1 day 2-3 days 4-5 days Rarely Never
HEALTHY 5% 10% 10% 28% 47%
PATIENTS 4% 8% 22% 63%
EXPERTS 9% 11% 9% 14% 57%
WO6: The majority of the target group do not engage with social media posts. Therefore, the sentiment analysis through social media posts functionality should be of low development priority.
i-PROGNOSIS-690494_D2.1.docx p. 53/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q7: How often (on average) do you use your phone/smartphone for taking self- pictures (selfies) per year?
Every day Every week Every month A few times per year Never
HEALTHY 7% 9% 46% 35%
PATIENTS 5% 12% 26% 55%
EXPERTS 8% 10% 8% 41% 33%
WO7: The majority of the target group is not used to taking selfies. So, emotion analysis through selfies functionality should be of low development priority.
Q8: Do you have anyone to help you with a smartphone, internet or any applications?
Yes No
HEALTHY 21% 79%
PATIENTS 52% 48%
EXPERTS 35% 65%
WO8: A significant proportion of the target group needs help for using a smartphone, the internet and any applications. So, the i-PROGNOSIS application should be as simple as possible and easy to use.
Q9: Do you have Wi-Fi internet access at home?
Yes No
HEALTHY 99%
PATIENTS 97%
EXPERTS 100%
WO9: The Wi-Fi internet access at home is commonplace and should be taken advantage for the transfer of data captured by the i-PROGNOSIS application to the cloud.
i-PROGNOSIS-690494_D2.1.docx p. 54/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q10: Could you imagine participating in such a project which implies the installation of a specific application (the i-PROGNOSIS application), sharing of health data, etc.?
Yes No
HEALTHY 96% 4%
PATIENTS 93% 7%
EXPERTS 94% 6%
WO10: The vast majority of the target group is willing to participate in a project like i-PROGNOSIS. So, the i-PROGNOSIS application is expected to exhibit increased popularity, leading to the collection of sufficient amount of data.
Q11: How important is it to you to have the option to select which data are collected by the application?
Very Moderately Little Mixed feelings Not at all
HEALTHY 61% 17% 17%
PATIENTS 29% 36% 11% 14% 11%
EXPERTS 70% 12% 6% 10%
WO11: The i-PROGNOSIS application should offer the option to the user to select which data are collected by the application.
Q12: Would you consent to share your health status data and daily routines for research purposes in an anonymous and secure manner?
Yes No
HEALTHY 97% 3%
PATIENTS 96% 4%
EXPERTS 96% 4%
WO12: The i-PROGNOSIS concept has a huge potential to be realised since the vast majority of the target group is willing to share, in a secure and anonymous manner, health status data and daily routines for research purposes.
i-PROGNOSIS-690494_D2.1.docx p. 55/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q13: Would you like to receive feedback about your data (e. g., steps per day, sleep hours per day, average daily/weekly/monthly statistics, comparative figures) and how often?
Yes, daily Yes, weekly Yes, monthly Not at all
HEALTHY 32% 37% 20% 11%
PATIENTS 28% 44% 21% 7%
EXPERTS 28% 42% 24% 6%
WO13: The i-PROGNOSIS application should provide personal feedback to the user. The frequency should be daily, weekly or monthly.
Q14: Would you like to receive feedback about the project results (not related to yourself)?
I would require I would prefer I would like to have the option No
HEALTHY 20% 31% 39% 10%
PATIENTS 15% 43% 40%
EXPERTS 30% 36% 30% 4%
WO14: The majority of the target group would prefer or would like to have the option to receive feedback about the project results.
Q15: Would you like the application to run “silently” in the background of your smartphone without bothering you at all?
I would require I would prefer I would like to have the option No
HEALTHY 14% 37% 35% 13%
PATIENTS 12% 49% 34% 5%
EXPERTS 18% 42% 32% 8%
WO15: The services of the i-PROGNOSIS application should run in the background
Q16: For how long would you keep the i-PROGNOSIS application running in i-PROGNOSIS-690494_D2.1.docx p. 56/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
the background?
1 week - 15 weeks 4 months - 11 months A Year Longer than a year
HEALTHY 38% 19% 16% 27%
PATIENTS 12% 21% 19% 48%
EXPERTS 25% 13% 31% 31%
WO16: The majority of target group are willing to keep the i-PROGNOSIS application for more than 4 months. So, the usage of the resources should be minimised.
Q17: Would you wear a smartwatch throughout the day?
Yes No
HEALTHY 94% 6%
PATIENTS 88% 12%
EXPERTS 90% 10%
WO17: The functionalities of the i-PROGNOSIS application that are related to smartwatch could be used to capture data during the day.
Q18: Would you wear a smartwatch while sleeping?
Yes No
HEALTHY 89% 11%
PATIENTS 76% 24%
EXPERTS 82% 18%
WO18: The functionalities of the i-PROGNOSIS application that are related to smartwatch could be used to capture data during sleeping.
i-PROGNOSIS-690494_D2.1.docx p. 57/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q19: Have you used self-monitoring devices before?
Yes No
HEALTHY 13% 87%
PATIENTS 26% 74%
EXPERTS 22% 78%
WO19: The target group has no experience is self-monitoring devices. So, the related functionalities should be easy to use.
Q20: If you used self-monitoring devices before, have you dropped out?
Yes No
HEALTHY 32% 68%
PATIENTS 17% 83%
EXPERTS 21% 79%
WO20: The drop-out rate of self-monitoring devices is low. So, the related functionalities of i-PROGNOSIS have increased potential.
Q21: Would you be comfortable wearing a smartwatch for...?
A Week A Month Six Months A Year Longer than a year
HEALTHY 26% 23% 11% 31% 9%
PATIENTS 6% 10% 14% 55% 15%
EXPERTS 13% 28% 9% 40% 11%
WO21: The smartwatch-related applications should minimise the usage of resources since the smartwatch is expected to be worn for more than six months.
i-PROGNOSIS-690494_D2.1.docx p. 58/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q22: Would you wear the smart belt during the day?
Yes No
HEALTHY 89% 11%
PATIENTS 69% 31%
EXPERTS 73% 27%
WO22: The recording of bowel sounds is possible to take place during the daytime, when bowel movements are increased.
Q23: Would you wear the smart belt during the night?
Yes No
HEALTHY 37% 63%
PATIENTS 55% 45%
EXPERTS 55% 45%
WO23: The recording of bowel sounds could also take place during the night.
Q24: If the belt needs to be worn directly on the skin, would you use it?
Yes No
HEALTHY 90% 10%
PATIENTS 69% 31%
EXPERTS 69% 31%
WO24: There is no restriction if the belt is needed to be worn directly on the skin.
Q25: Would you be comfortable wearing a smart belt for...? i-PROGNOSIS-690494_D2.1.docx p. 59/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
1 week - 15 weeks 4 months - 11 months 6 months A Year Longer than a year
HEALTHY 59% 23% 9% 8%
PATIENTS 15% 28% 16% 29% 11%
EXPERTS 43% 29% 5% 19% 5%
WO25: Considerable amount of bowel sounds data are expected to be collected by the i-PROGNOSIS application.
Q26: Would you place your plate on a Mandometer for main meals during the day at home?
Yes No
HEALTHY 93% 7%
PATIENTS 80% 20%
EXPERTS 88% 12%
WO26: The Mandometer-based modules of the i-PROGNOSIS application are expected to be accepted by the target group.
Q27: Would you like the Mandometer to give you direct feedback about your eating habits?
I would require I would prefer I would like to have the option No
HEALTHY 23% 37% 21% 18%
PATIENTS 13% 38% 32% 17%
EXPERTS 26% 42% 18% 14%
WO27: The i-PROGNOSIS application should provide or at least give the option to provide feedback about the eating habits of the user.
i-PROGNOSIS-690494_D2.1.docx p. 60/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q28: Would you use the Mandometer if you were eating outside of your home?
Yes No
HEALTHY 28% 72%
PATIENTS 32% 68%
EXPERTS 54% 46%
WO28: The use of Mandometer will be mainly at home.
Q29: Do you like the idea of having a remote control that can capture your electrocardiogram (ECG)?
Yes No
HEALTHY 94% 6%
PATIENTS 81% 19%
EXPERTS 84% 16%
WO29: The concept of the smart remote control that captures ECG data has great potential
Q30: Are any other people in your household that are using the same remote control?
Yes No
HEALTHY 87% 13%
PATIENTS 64% 36%
EXPERTS 82% 18%
WO30: Since multiple people will use the same remote control, the related service should be able to identify the user.
Answered by Patients and Experts i-PROGNOSIS-690494_D2.1.docx p. 61/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q31: Would you like to listen to music during the games?
I would require I would prefer I would like to have the option No
PATIENTS 10% 25% 46% 19%
EXPERTS 8% 26% 42% 24%
WO31: The i-PROGNOSIS application should provide the option to the user to listen to music during the games
Q32: Would you like the instructions through animations or through an actual person on a video showing you what to do?
Animations I do not mind Actual Person
PATIENTS 11% 50% 39%
EXPERTS 12% 32% 56%
WO32: The idea of animated instructions is not popular among the target group. So, the i-PROGNOSIS application should provide instructions through actual persons on a video
Q33: Would you prefer the graphics of the games to be realistic or abstract/animated?
Realistic Abstract/animated I do not mind
PATIENTS 48% 5% 48%
EXPERTS 70% 28%
WO33: Based on the experts, mainly, the graphics of the games should be realistic
Q34: Is it important to you to have a social dimension in the game suite (e.g., collaboration, competition)? i-PROGNOSIS-690494_D2.1.docx p. 62/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
I would require I would prefer I would like to have the option No
PATIENTS 23% 41% 33%
EXPERTS 8% 18% 52% 22%
WO34: The game suite should include optional social-based features
Q35: Would you like to receive feedback in the form of a score or of a rank (e.g. "good", "excellent" etc.)?
Yes with both Yes with rank Yes with score I do not mind No
PATIENTS 38% 11% 17% 25% 8%
EXPERTS 30% 24% 20% 20% 6%
WO35: The game suite should provide feedback to the user in the format of rank.
Q36: Is it important that you receive motivational messages (e.g. “you are doing very well – please keep up”)?
Very Enough Little Mixed feelings Not at all
PATIENTS 19% 23% 8% 33% 16%
EXPERTS 18% 48% 10% 12% 12%
WO36: Motivational messages should be provided to the user, based, mainly, on the experts’ opinion.
Q37: What would be a convenient duration of a game session for you?
i-PROGNOSIS-690494_D2.1.docx p. 63/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
>15 minutes 15 - 30 minutes 30 minutes - 1 hour I do not mind Whatever the doctor/ expert recommends
PATIENTS 19% 42% 12% 25%
EXPERTS 30% 44% 6% 8% 12%
WO37: A game session should not last longer than 30 minutes, unless the doctor/expert recommends
Q38: How often do you imagine yourself playing the games?
1-2 times/week 3-4 times/week Every Day Never
PATIENTS 38% 31% 19% 12%
EXPERTS 58% 18% 10% 14%
WO38: The majority of the target groups would engage at least once a week with the intervention games
Q39: What type of Exergames would you be interested in?
Full body physical activity Physical activity seated No physical activity
PATIENTS 78% 18% 4%
EXPERTS 69% 24% 6%
WO39: The Exergames should engage full body physical activity
Q40: Would you like to play the games alone or with other people in the same room? i-PROGNOSIS-690494_D2.1.docx p. 64/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
I'd rather alone Participate in a group Both
PATIENTS 49% 11% 40%
EXPERTS 38% 12% 50%
WO40: The games may include a local multiplayer option
Q41: Have you ever played games with other family members (grandchildren, nephews, etc.) and how did you like it?
Yes and I enjoyed it Yes and I did not like it No and I do not know if I would like it or not No but I would like to No and I would not like it
PATIENTS 52% 4% 25% 15% 5%
EXPERTS 57% 12% 22% 8%
WO41: About half of the target group has positive previous experience with playing games with other family members while the rest do not have such kind of experience.
Q42: Would you consider wearing unobtrusive wireless headphones during the night in order to improve your sleep quality?
Yes No
PATIENTS 78% 22%
EXPERTS 68% 32%
WO42: The concept of night time intervention seems to have a great potential
i-PROGNOSIS-690494_D2.1.docx p. 65/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q43: If yes, would you prefer in-ear headphones or headphones embedded in a headband?
In ear (A) Headband (B)
PATIENTS 53% 47%
EXPERTS 66% 34%
WO43: The in-ear headphones seem to be slightly more popular.
Q44: Would you like to have the option to manually activate this intervention?
I would require I would prefer I would like to have the option No
PATIENTS 13% 33% 43% 11%
EXPERTS 9% 37% 37% 17%
WO44: The user should be able to manually activate the night time intervention.
Q45: Would you like to have the option to choose the type and volume of sounds?
I would require I would prefer I would like to have the option No
PATIENTS 22% 33% 37% 8%
EXPERTS 24% 33% 26% 17%
WO45: The user should be able to choose the type and volume of sounds.
i-PROGNOSIS-690494_D2.1.docx p. 66/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q46: How many gait freezing episodes do you experience in a week?
0 to 5 5 to 10 More than 10
PATIENTS 89% 8%
EXPERTS 88% 7% 5%
WO46: Only, a few freezing episodes are experienced every week. So, the gait intervention could be of low development priority.
Q47: When a freezing episode is detected, should the gait intervention start automatically?
I would require I would prefer I would like to have the option No
PATIENTS 15% 38% 39% 8%
EXPERTS 25% 40% 30% 5%
WO47: It would be useful if the gait intervention could be started automatically.
Q48: How helpful would you find this intervention in your everyday life?
Very much Much Medium Little Not at all
PATIENTS 14% 14% 24% 23% 25%
EXPERTS 22% 27% 17% 10% 24%
WO48: Despite WO46, the gait intervention would be very useful in the users’ everyday life, based, mainly, on the experts’ opinion.
i-PROGNOSIS-690494_D2.1.docx p. 67/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Q49: Should this application have an option to give you a discreet signal when it detects your voice is not loud or clear enough, so that you can try to balance your voice before activating the intervention?
I would require I would prefer I would like to have the option No
PATIENTS 26% 30% 41% 4%
EXPERTS 28% 35% 26% 11%
WO49: The voice enhancement intervention should notify the user when his/her voice is not loud/clear and allow for self-management, prior to the activation of the intervention.
Q50: Would you like to use this intervention when you are in a face-to-face conversation?
I would require I would prefer I would like to have the option No
PATIENTS 10% 26% 54% 10%
EXPERTS 11% 28% 43% 17%
WO50: The voice enhancement intervention should have the option to be used in face-to-face conversations.
Q51: Would you mind if this intervention changed the tone and pitch of your voice during a phone call to achieve better understanding?
Yes No
PATIENTS 40% 60%
EXPERTS 38% 62%
WO51: Distortion of voice features would not disturb the users. i-PROGNOSIS-690494_D2.1.docx p. 68/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
6 USAGE SCENARIOS & BUSINESS PROCESSES
6.1 INTRODUCTION
The aim of this section is to provide a detailed description of the i-PROGNOSIS usage scenarios. It is structured based on four subsections, with the first one presenting cumulatively the actors and system components and with each of the following three corresponding to a general usage scenario, i.e., the first stage of i-PROGNOSIS PD detection, the second stage of i-PROGNOSIS PD detection and the supportive interventions period. Each of these subsections includes:
Usage scenario: a description of how the system will be used from the perspective of the user. In the scenario, the actors and the components of the system are defined. Unified modelling language (UML) case diagram: a general UML case diagram illustrating the relationships between the actors and the interactions with the system components. Business processes: a granular break-down of the usage scenarios into business processes, i.e., a detailed description of tasks included in the usage scenario.
The content of this section is then associated with the identified user requirements presented in the next section and their combination, along with the upcoming deliverable D2.3 "First version of system specification", will provide the initial guidelines for the development and realisation of the i-PROGNOSIS system components.
6.2 DEFINITION OF ACTORS AND SYSTEM COMPONENTS
6.2.1 Actors
This section provides the list of actors participating in the following usage scenarios and business processes.
Actor Definition Adult An adult that is interested in participating in the i- PROGNOSIS first or second stage of detection. Caregiver A person (professional or not) close to the interventions user that helps her/him with her/his activities of daily living. Diagnosed PD An adult that has been medically diagnosed with patient Parkinson's disease (PD), without being a participant in the i-PROGNOSIS detection stages. Expert physician A physician with expertise in PD diagnosis and treatment and with knowledge of the i-PROGNOSIS solutions. First stage user An adult that participates in the i-PROGNOSIS first stage of i-PROGNOSIS-690494_D2.1.docx p. 69/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Parkinson's detection and uses the respective system components. Game friend A separate interventions user that has been linked to the interventions user of interest (through their expert physician) and, together, they participate in a healthy competition regarding their gamified interventions performance. Interventions user An adult that follows the i-PROGNOSIS interventions and uses the respective components. Second stage user An adult that participates in the i-PROGNOSIS second stage of Parkinson's detection and uses the respective system components.
6.2.2 System components
This section provides the list of the main system components that are involved in the following usage scenarios and business processes.
System component Definition Assistive The general reference term of i-PROGNOSIS intervention interventions that do not belong to the Personalised game suite (PGS). Auxiliary menu A menu in the detection/interventions application that displays additional options when active. Behavioural A sub-system of the i-PROGNOSIS system that uses modelling sub- interventions engagement data and monitoring system data stored in the interventions platform to form a behavioural model of the interventions user. Body/gesture A service of the interventions platform that recognises recognition service the interventions user's movements during the Exergames based on data provided by the Kinect device. Bowel sound service A background service of the detection/ interventions application that captures bowel sound data streamed to the smartphone by the smart belt, when the actor wears the smart belt, and processes them. Caregiver account A set of credentials (user name and password) that allows access to the interventions platform components for the specific caregiver. Cloud server An i-PROGNOSIS server of the Cloud-based data management infrastructure (server farm) that processes / stores the uploaded data from the detection/interventions application. Data-to-feedback A service on the Cloud server, part of the i-PROGNOSIS-690494_D2.1.docx p. 70/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition service interventions platform, that will be responsible for the transformation of monitoring data and interventions engagement data into statistical measures to be presented to the respective actor as feedback elements. Decision sub-system A sub-system that uses the detection behavioural model in order to produce a decision on whether a particular first stage or second stage user exhibits a behavioural change that relates to PD. Detection The i-PROGNOSIS mobile application (for smartphone) application that includes the UI and all the services needed for the first and second stage of the i-PROGNOSIS PD detection. Detection The model formed by the uploaded data arising from the behavioural model detection application and used by the decision sub-system to reach a decision for a particular first stage or second stage user regarding her/his behaviour against PD symptomatology. Dietary game An electronic game involving a set of gamified scenarios, part of the PGS, targeting the improvement of dietary habits. ECG processing A background service of the detection/ interventions service application that captures ECG data streamed to the smartphone by the smart TV remote, when the actor holds the smart TV remote, and processes them. Emogame An electronic game involving a set of gamified scenarios, part of the PGS, targeting the improvement of facial emotional expressions. Exergame An electronic game involving a set of gamified exercise scenarios, part of the PGS, targeting a specific physical activity. There are more than one Exergames, each one targeting a different physical activity. Expert account A set of credentials (user name and password) that allows access the interventions platform components for the specific expert physician. Feedback element A UI element that serves to provide feedback to the actor about an activity of her/his or another actor's. Feedback tab A tab in the main menu of the interventions application that displays feedback elements and expert physician/caregiver contact information.
i-PROGNOSIS-690494_D2.1.docx p. 71/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition First launch A tutorial presenting the UI elements of a UI, their tutorial functionalities and how the actor can interact with them, the first time an application is launched. Food intake service A background service of the detection/ interventions application that captures food intake data streamed to the smartphone by the Mandometer, when the actor has the Mandometer under the plate of her/his meal, and processes them. Gait rhythmic An assistive intervention targeting the sound-based guidance reinstatement of normal gait when the interventions intervention (GRGI) user walks and has a freezing episode. Game Instruction A panel preceding the beginning of each game scenario Panel that shows the interventions user multimodal instructions on how to perform the tasks in the particular game scenario. Game scenario The context and the ensemble of actions that form a stage of each game in the PGS. GRGI service A background service of the interventions application, part of the GRGI, that detects freezing episodes based on data streamed to the smartphone by the smartwatch, when the interventions user walks and wears the smartwatch, and triggers the gait rhythmic sound-based reinstatement mechanism. Handling service A background service of the detection/ interventions application that captures and processes smartphone orientation data when the actor handles the smartphone in certain ways. Handwriting game An electronic game involving a set of gamified scenarios, part of the PGS, targeting the improvement of handwriting. Help & feedback An option, displayed by the auxiliary menu that allows option the actor to proceed with her/his request/upload of help/feedback. Home screen The first UI screen that the actor sees when opening an application (except for the first time). Image processing A background service of the detection/ interventions service application that parses the smartphone stored front- facing camera photos on a scheduled basis, analyses them and extracts features. Intervention An activity of the i-PROGNOSIS system developed to sustain the quality of life of the interventions user. i-PROGNOSIS-690494_D2.1.docx p. 72/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition Interventions The i-PROGNOSIS mobile application (for smartphone and application tablet) that includes the UI and all the services needed for the interventions phase of the i-PROGNOSIS. Interventions The model produced by the behavioural modelling behavioural model sub-system for a particular interventions user regarding self-health management. Interventions Data generated by the engagement with and use of engagement data interventions by the interventions user. Interventions A Web-based platform that includes all the UI elements platform and services needed for the interventions user, the expert physician and the caregiver regarding interventions. Interventions tab A tab in the main menu of the interventions application that displays the list of interventions from where the interventions user can access each one. Key generator A functionality of the interventions platform that allows the expert physician to generate keys for upgrading the detection application Kinect A commercial device that has the required sensors for the interventions user to interact with the Exergames by gestures and body movements. The Kinect® is developed by Microsoft Corporation, Redmond, WA. Location service A background service of the detection/ interventions application that captures and processes the smartphone location when the actor carries her/his smartphone when commuting. Log-out option An option in the auxiliary menu of the mobile interventions application that allows the interventions user to log out from the application Main menu The menu with the main options of the interventions application (feedback tab, interventions tab, monitoring services tab). Mandometer A plate scale that is placed under the plate of the meal that the actor consumes and that collects and transmits food intake data to the smartphone. The Mandometer® is developed by Mando Group AB, Huddinge, Sweden. Monitoring data Data produced by the movement service, physical activity service and sleep stage service (smartwatch), the food intake service (Mandometer), the bowel sound service (smart belt), the ECG processing service (smart TV remote), the voice i-PROGNOSIS-690494_D2.1.docx p. 73/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition service, the typing pattern service, the text processing service, the image processing service, the handling service, and the location service (smartphone) during the interventions period. The monitoring data is not used for learning purposes of the decision sub-system as in detection stages. Monitoring services A tab in the main menu of the interventions tab application that displays the list of monitoring background services from where the interventions user can activate/deactivate each one. Movement service A background service of the detection/ interventions application that captures orientation data streamed by the smartwatch, when the actor wears the smartwatch, and processes them. Notifications tab A tab of the main menu of the interventions application where all the interventions-related notifications are presented. Performance metric The metric that will quantitatively or qualitatively indicate how the interventions user performed during a PGS scenario. Personal computer The personal computer device of the actor. (PC) Personalisation A service of a PGS game that adapts the game play based service on the interventions user's previous performance. Personalised game The collection of the i-PROGNOSIS gamified suite (PGS) interventions (Exergames, Dietary game, Handwriting game, Voice game, Emogame) with personalised adaptation mechanisms for the interventions user. Physical activity A background service of the detection/ interventions service application that captures physical activity data from the smartphone (steps) or streamed by the smartwatch (heart rate, accurate steps, skin temperature) when the actor wears the smartwatch, and processes them. Receive decision The option given to the first stage user to be option informed through the detection application about the i-PROGNOSIS decision on her/his status against PD during the first stage of detection. Review consent An option, displayed by the auxiliary menu that allows option the actor to proceed and review her/his consent form. Schedule option An option of the interventions platform that allows i-PROGNOSIS-690494_D2.1.docx p. 74/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition the expert-physician to schedule a new PGS scenario. Scheduler service A service of the interventions platform that manages scheduled game scenarios and presents them to the interventions user, the expert physician and the caregiver, through the respective interventions platform UI for each actor and the interventions user's interventions application. Sleep earphones A pair of wireless earphones that are designed so as to be worn as comfortably as possible during sleep and that will be used for the TNI. Sleep stage service A background service of the detection/ interventions application that captures sleep stage data streamed by the smartwatch, when the actor wears the smartwatch during her/his sleep, and processes them. Smart belt A belt worn around the abdomen that bears microphones and other hardware that captures and transmits bowel sounds to the smartphone. Smart TV remote A TV remote controller that besides serving as a regular and universal TV remote controller bears electrocardiogram (ECG) sensors and other hardware that captures and transmits ECG data to the smartphone. Smartphone The smart mobile phone of the actor. Smartwatch The smart (with advanced features and sensors) watch of the actor that connects to her/his smartphone. Syncing service A background service that manages the extracted features of other background services of the detection / interventions application and uploads the product on the Cloud. Tablet The tablet device of the actor. Targeted nocturnal An assistive intervention targeting the sleep stage intervention (TNI) reinstatement of the interventions user after a sleep disturbance episode. Television set (TV The television set of the interventions user. set) Text processing A background service of the detection/ interventions service application that parses the smartphone stored sent text messages on a scheduled basis, analyses the text and extracts features. TNI service A background service of the interventions application, part of the TNI, that detects sleep i-PROGNOSIS-690494_D2.1.docx p. 75/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition disturbances based on data streamed to the smartphone by the smartwatch, when the interventions user sleeps and wears the smartwatch, and triggers the sleep stage sound-based reinstatement mechanism. Typing pattern A background service of the detection/ interventions service application that captures and processes typing patterns when the actor types on the smartphone keyboard. UI element An element of the user interface, e.g. a button or a text field. Upgrade option An option, displayed by the auxiliary menu that allows the actor to proceed with the upgrade of the detection application in order to activate new UI elements and services. User account A set of credentials (user name and password) that allows access to the interventions application and interventions platform components for the specific interventions user. User interface (UI) All the elements in the i-PROGNOSIS system components with which all types of actors will interact. VEI service A background service of the interventions application, part of the VEI, that activates when the interventions user accepts a phone call on her/his smartphone and triggers the voice quality enhancement mechanism. Virtual tutor A virtual avatar, representing a tutor, that is part of the interventions platform and it guides and motivates interventions users before, during and after their engagement with the PGS games using natural language (oral or text). Voice enhancement An assistive intervention targeting the real-time intervention (VEI) improvement of voice quality when the interventions user talks on the smartphone during a call. Voice game An electronic game involving a set of gamified scenarios, part of the PGS, targeting the improvement of oral communication. Voice service A background service of the detection/ interventions application that captures and processes the voice of the actor during a phone call to extract features. Website The i-PROGNOSIS website (www.i-prognosis.eu). Withdraw consent An option, displayed by the auxiliary menu that allows i-PROGNOSIS-690494_D2.1.docx p. 76/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
System component Definition option the actor to proceed with the withdrawal of her/his consent form.
6.3 FIRST STAGE OF PARKINSON'S DISEASE DETECTION
6.3.1 Usage scenario & UML use case diagram
Usage scenario identifier: US-1 Actors in this scenario: Adult; First stage user; Expert physician System components in this scenario: smartphone; smartwatch; detection application; user interface (UI); UI element; home screen; voice service; handling service; typing pattern service; location service; image processing service; text processing service; syncing service; movement service; physical activity service; sleep stage service; Cloud server; auxiliary menu; withdraw consent option; review consent option; website; help & feedback option; upgrade option; decision sub-system; receive decision option; detection behavioural model Benefits: The i-PROGNOSIS decision sub-system based on a detection behavioural model "learns" from the collected features extracted from different types of data arising from the first stage user's interaction with the smartphone (and conditionally smartwatch) in order to possibly provide the first stage user with a first indication of behavioural status or behavioural change that relates to PD, which is subsequently validated by an expert physician.
Description: US-1 unfolds when an adult chooses to download and install the i-PROGNOSIS detection application on her/his smartphone for the first time from the application store. On opening the detection application for the first time on her/his smartphone, the adult is presented with an epitomised consent form65 at the end of which there is a link to the detailed consent form on the i-PROGNOSIS website and the options to agree or decline. If the adult agrees, s/he is presented with a confirmation screen and the option for the consent downloaded and stored locally on the mobile device. After completing the consent process, the adult becomes a first stage user and an entry is created in the i-PROGNOSIS Cloud
65 Depending on the progress during T3.7 - Machine Learning Algorithms for Behavioural Changes Detection, an alternative approach may be attempted. In the aforementioned approach, i-PROGNOSIS will be introducing discrete consent levels which reflect directly on the user’s desired level of participation. The first stage user will be able to select the consent of her/his choise, depending on the data types s/he is willing to share. The concept of multiple consent levels will be used to enchance the robustness of the machine learning approaches in the event of algorithm degeneration due to the user de-activating key data sources. i-PROGNOSIS-690494_D2.1.docx p. 77/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
server. The first stage user is then presented with a series of screens. In each of these screens, the first stage user is required to answer a question regarding her/his health status, including if s/he is a PD patient or has a history of PD in the family. After answering the questions, the first stage user is presented with another series of screens. In each of these screens, the type of data captured by the detection application is presented along with the reason why (related PD symptom), the way the data are processed by i-PROGNOSIS and the option to deactivate the collection of the particular type of data. The final screen presents the first stage user with the option (receive decision option) to be informed about the i-PROGNOSIS decision or not on her/his status against PD. After the latter series of screens, the first stage user is presented with the main user interface (UI) of the detection application (home screen) and a short first launch tutorial on the purpose of each UI element.
Upon completing all the aforementioned steps, the detection application is ready to process data. The first stage user can close the detection application. The detection application comprises a number of services that run in the background, i.e., no actions are required from her/him. Background services of the detection application run regardless of the status of the detection application (open or not). Each service is responsible for the processing of a type of data arising from the first stage user's everyday interaction with her/his smartphone. In particular:
When the first stage user answers a call on the smartphone, the voice service processes her/his voice for short intervals to extract features. When the first stage user handles her/his smartphone to perform certain actions, the handling service processes accelerometer and gyroscope data to extract features. When the first stage user uses the keyboard to type a text message on her/his smartphone, the typing pattern service processes her/his typing patterns to extract features. When the first stage user carries her/his smartphone when commuting, the location service analyses location data to extract features. Additionally, a physical activity service records movement data related to physical activity (e.g., steps). The first stage user takes photos of himself/herself with the front-facing camera of her/his smartphone. The image processing service has access to the first stage user's photos. The image processing service parses the stored photos on a scheduled basis to analyse the photos taken with the smartphone front-facing camera and extract features. A dedicated background service (text processing service) has access to the first stage user's sent text messages (SMS) stored on her/his smartphone. The text processing service parses the stored sent text messages on a scheduled basis, analyses the text and extracts features. (Conditional) The first stage user has a compatible - with the detection application - smartwatch paired with her/his smartphone. When, the first stage user wears the smartwatch during the day, the smartwatch streams accelerometer and gyroscope data to the smartphone where a background service (movement service) of the detection application i-PROGNOSIS-690494_D2.1.docx p. 78/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
captures and processes the data to extract features. The physical activity service now captures additional physical activity data (heart rate, accurate steps, skin temperature) and processes them. When the first stage user wears the smartwatch during her/his sleep, the smartwatch streams sleep stage data to the smartphone where a background service (sleep stage service) captures and processes them.
Each of the aforementioned background services delivers the extracted features to a syncing service, which caches and processes them and uploads the processing product on the i-PROGNOSIS Cloud server, when the first stage user's smartphone is connected to a Wi-Fi network and it is charging.
At any time and within the detection application, the first stage user can view and modify the permissions and select which data sources are processed, through the respective UI element of the home screen. The first stage user can perform further actions using the options in the auxiliary menu of the detection application home screen. In particular, the first stage user can withdraw her/his consent and halt all data processing services via the withdraw consent option. In this case and if the first stage user selects the respective option during the withdrawal of the consent, the data generated from the particular first stage user are deleted from the i-PROGNOSIS Cloud server. The first stage user can further review the consent form (review consent form option), request/provide help/feedback (help & feedback option), and upgrade the application (upgrade option - linked to the next usage scenario) via the auxiliary menu. When the first stage user decides to uninstall the detection application from her/his smartphone, the consent is not withdrawn, data generated by the particular first stage user are not deleted, but any further data upload is terminated.
If the i-PROGNOSIS decision sub-system, based on the fusion of the acquired data and the detection behavioural model, produces a first inference of change in the behaviour of the first stage user that points to PD and if the first stage user has chosen to receive the decision through the receive decision option, the first stage user will receive a secure notification on her/his smartphone by the detection application to visit an expert physician in order for the expert physician to validate the change.
FIGURE 6 illustrates cumulatively the use cases and the actors in US-1 as a UML use case diagram.
i-PROGNOSIS-690494_D2.1.docx p. 79/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FIGURE 6 The UML use case diagram corresponding to US-1. Human figures represent the actors participating in the usage scenario, text bubbles represent the use cases, <
i-PROGNOSIS-690494_D2.1.docx p. 80/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
6.3.2 Business processes
This section presents the list of business processes (BPs) related to usage scenario US-1.
BP-1 Reference to scenario: US-1 Title: The first stage user locates the i-PROGNOSIS detection application Description: The first stage user searches for the i-PROGNOSIS detection application by typing the search query “i-prognosis” in the application store. Alternatively, the first stage user can be redirected to download the i-PROGNOSIS application from the application store by visiting the i-PROGNOSIS website (www.i-prognosis.eu) dedicated webpage and by following the respective hyperlink.
BP-2 Reference to scenario: US-1 Title: The first stage user installs the i-PROGNOSIS detection application Description: After successfully searching for the i-PROGNOSIS detection application in the application store, the first stage user follows the standard application installation procedure (tapping “install” button). The main installation process also installs the background services (i.e. the voice, handling, typing pattern, location, image processing, text processing, syncing, sleep stage*, movement* services and the decision sub-system) to the mobile device, however, the background processes remain inactive until the first execution of the detection application (BP-3) Depending on the operating system (OS) version of the first stage user's device, the installation process can take two different paths. In certain OS versions, the first stage user reads through the required-access list (provided below) before the actual installation commences and either accepts and proceeds with the installation process or declines and the installation is terminated. On the other hand, in newer OS versions, accepting the required-access list isn’t necessary at the point of installation. The first stage user will be prompted to grant access when the detection application launches for the first time. The required access list includes granting access to: Read text messages Network adapter (Wi-Fi) Phone calls Storage Location i-PROGNOSIS-690494_D2.1.docx p. 81/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Camera Image Gallery Motion sensors (accelerometers, gravity, gyroscopes and rotational vector sensors) Environmental sensors (barometers, photometers and thermometers) Position sensors (orientation sensors and magnetometers) Microphone sensor Keyboard input The i-PROGNOSIS detection application is now installed on the first stage user's mobile device.
BP-3 Reference to scenario: US-1 Title: First stage user launches the detection application for the first time Description: On launching the detection application for the first time, the first stage user is presented with the summary of the consent form with the option of viewing the detailed version on the website (hyperlink that opens with a Web view component inside the application). After reading the consent (the brief version and/or the detailed one), the first stage user can either choose to accept and proceed to the confirmation screen, with the consent downloaded and stored locally on the mobile device, or decline and terminate the process. After accepting the consent form, a unique user entry is created in the i-PROGNOSIS cloud servers. The first stage user is presented with a series of screens that require to provide details about her/his gender, age and health status (healthy or PD diagnosed patients at stage #, or healthy with PD medical history in the family). After providing all the necessary information (age, gender, etc.), the first stage user is presented with a series of screens, each one explaining in detail the types of data captured by the detection application, the way each data source is processed and the goal of the processing (target PD symptom). Each screen is dedicated to a single data source. At the bottom of each of the aforementioned screens the first stage user is prompted to allow or deny access to the respective type of captured data. At this point, if the OS version of the first stage user's device is new, the OS platform will prompt the user (using a pop-up window) whether or not s/he would like to grant access to the sub-systems (i.e. sensors, complete list can be found in BP- 2) related to capturing those data sources. After the first stage user concludes on deciding whether to grant access or not, s/he is presented with the main user interface (UI) of the detection application, called the home screen. Upon viewing the home screen for the first time, the first stage user is presented with a short first launch tutorial i-PROGNOSIS-690494_D2.1.docx p. 82/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
explaining the purpose and the operation of each UI element (i.e. buttons, sliders, etc.) available.
At this point, the detection application is fully functional and the first stage user can close the application window and can continue using her/his smartphone the same way as before installing the i-PROGNOSIS detection application.
BP-4 Reference to scenario: US-1 Title: The first stage user modifies the list of authorised data sources s/he wants to share with i-PROGNOSIS Description: After successfully executing the detection application for the first time (BP-3), the first stage user has already set her/his preferences regarding the authorisation of certain data sources. If the first stage user decides to modify her/his preferences, s/he can do it by executing the i-PROGNOSIS detection application which will automatically guide her/him in the home screen after a short loading period. From the home screen the first stage user can interact with the UI elements (i.e. sliders, checkboxes, etc.) next to each data source in order to allow or disallow it (i.e. grant access to it, in order to be captured by i- PROGNOSIS or prohibit access respectively). The indication that the first stage user disallowed certain data sources, is forwarded to the syncing service (BP-15) in order to be manipulated in a way that resolves ambiguous interpretation (e.g., lack of selfies indicate behavioural change). The action mentioned above is reversible and is not in any way related with deleting her/his data from the Cloud server. The process of modifying the list of authorised data sources is available on-demand (meaning, whenever s/he wants) to the first stage user.
BP-5 Reference to scenario: US-1 Title: The first stage user withdraws her/his consent Description: The first stage user can perform the withdrawal of her/his consent at any time by executing the i-PROGNOSIS detection application. From the home screen the first stage user can access the auxiliary menu by selecting the respective UI element. From the auxiliary menu the first stage user selects the withdraw consent option. At this point, the first stage user is presented with the option of whether or not s/he wishes to permanently delete all of her/his up-to-date data from the i- PROGNOSIS Cloud server. If the first stage user selects to delete her/his data, the unique user entry is deleted from the Cloud server, as well as any stored data, excluding derived indicators that inherently cannot reveal personal information. On i-PROGNOSIS-690494_D2.1.docx p. 83/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
the other hand, the first stage user can select to withdraw her/his consent without deleting her/his data from the Cloud server; this, as a result, halts any further data capturing/processing/transmission from i-PROGNOSIS, however it does not remove the unique user entry from the Cloud server.
BP-6 Reference to scenario: US-1 Title: The first stage user reviews her/his consent form Description: The first stage user can select to further review her/his consent form at any time by executing the i-PROGNOSIS detection application. From the home screen the first stage user accesses the auxiliary menu by selecting the respective UI element. From the auxiliary menu the first stage user selects the review consent form option. The aforementioned option, allows the first stage user to examine the accepted consent form, as generated from the first launch (BP-3) of the detection application. If at any point the consent form is updated, due to changes in the legislative regulations and/or changes in the regulations from the dissemination platform (e.g. Google play store, Microsoft Store, etc.) the original consent form (from BP-3) is replaced with the updated version and the first stage user is asked to select whether s/he wishes to accept or deny.
BP-7 Reference to scenario: US-1 Title: The first stage user uninstalls the i-PROGNOSIS detection application Description: The first stage user selects to uninstall the i-PROGNOSIS detection application by following the standard procedure for uninstalling application in an OS platform. In contrast with BP-5, uninstalling the i-PROGNOSIS detection application will not remove the first stage user's up-to-date data or unique user entry from the Cloud server. Furthermore, uninstalling the detection application will not cause a consent form withdrawal. The immediate effect of uninstalling is to prevent any further data capturing/processing/transmission and communication with the i- PROGNOSIS Cloud servers. The uninstall process removes all software items related to the i-PROGNOSIS detection application, from the first stage user's mobile device without affecting other user-installed applications. The most popular way of uninstalling an application in an OS platform is to “tap & hold” on the i-PROGNOSIS shortcut and then perform a “drag & drop” to the i-PROGNOSIS-690494_D2.1.docx p. 84/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
uninstall area that pop-ups in the screen.
BP-8 Reference to scenario: US-1 Title: The first stage user provides feedback and/or requests help Description: The first stage user can select to request help or to provide feedback at any time by executing the i-PROGNOSIS detection application. From the home screen the first stage user accesses the auxiliary menu by selecting the respective UI element. From the auxiliary menu the first stage user selects the help & feedback option. Upon selecting the previous option, a Web view component emerges within the detection application and the first stage user is presented with a UI element (e.g. dropdown selection) with the options of “request help” and “provide feedback” and two additional UI elements, a text box and a submit button. The first stage user initially selects either the “request help” or “provide feedback” option from the top UI element, and then uses the text box to type her/his question or suggestion (feedback) respectively. After the first stage user finishes typing the question/feedback, s/he selects the relevant UI element for submission (submit button), and s/he is presented with a pop-up windows indicating that her/his message was submitted successfully. After dismissing the message the Web view component for help and feedback can now be closed safely. If the first stage user used the help & feedback option in order to request help, any messages received related to her/his query will appear as a notification in the home screen of the detection application. The communication is based on a unique application id that is generated during the download and installation process of the detection application; hence no e-mail address needs to be provided. The first stage user can select the relevant UI element in order to view the received message and then dismiss it and continue with the typical operation of the detection application. The options “request help” and “provide feedback” are used to categorise and label the incoming messages on the i-PROGNOSIS side, in order to be properly addressed.
BP-9 Reference to scenario: US-1 Title: The voice service collects data from the first stage user Description: The voice service, if granted the first stage user’s authorisation, runs silently in the background and gets trigged by a calling event. When the first stage user i-PROGNOSIS-690494_D2.1.docx p. 85/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
receives and successfully answers a voice call (or initiates a calling event), the voice service is triggered and records short intervals of the first stage user's voice from the device’s microphone sensor, without requiring any further interaction from the first stage user's side, starting from the beginning of the call. The first stage user's call experience isn’t affected by the capturing process and s/he can terminate the call whenever s/he decides to. The voice data recorded by the voice service are on-the-fly processed, in order to extract the features required for the detection of voice-related PD symptoms (e.g. dysphonia detection or emotional analysis in conjunction with features from other data sources). When the processing (feature extraction) finishes, the extracted features are directed to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-10 Reference to scenario: US-1 Title: The typing pattern service collects data from the first stage user Description: The typing pattern service, if granted the user’s authorisation, operates silently in the background and gets triggered when the first stage user uses the smartphone keyboard to compose a new text message (SMS or IM). The typing pattern service captures the keystrokes delivered by the first stage user to the virtual keyboard and processes them in order to extract features targeting the detection of motor-related PD symptoms. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-11 Reference to scenario: US-1 Title: The location service collects data from the first stage user Description: The location service, if granted the first stage user’s authorisation, collects location-related data while operating silently in the background. The location data are collected throughout the day, while the first stage user carries the phone performing everyday activities without requiring any interaction from her/his side. Location data can be generated from multiple sources such as GSM, GPS and/or Wireless networks. i-PROGNOSIS-690494_D2.1.docx p. 86/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
At the end of the day at a predefined time, the captured data are processed to generate features related to the detection of emotional (e.g. depression, social exclusion), or motor-related PD symptoms, either standalone or in conjunction with features from different data sources. The extracted features are “de-identified”, meaning that they are uncorrelated with the first stage user’s absolute location coordinates and only carry a semantic description of the first stage user’s location and her/his routes. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-12 Reference to scenario: US-1 Title: The image processing service collects data from the first stage user Description: The image processing service, if granted the user’s authorisation, runs silently in the background and gets triggered on a predefined schedule. The purpose of the image processing service is to access the current period’s stored images that are captured by using the front facing camera sensor and to extracts visual characteristics (features) related to physiological (e.g. masked face) or/and emotional (e.g. depression) PD symptoms, either standalone or in conjunction with other feature sources. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-13 Reference to scenario: US-1 Title: The text processing service collects data from the first stage user Description: The text processing service, if granted the user’s authorisation, operates silently in the background and gets triggered on a predefined schedule. The text processing service accesses and processes the current period’s stored SMS messages of the first stage user in order extract text-based features related to the detection and analysis of emotional PD symptoms. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
i-PROGNOSIS-690494_D2.1.docx p. 87/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
BP-14 Reference to scenario: US-1 Title: The handling service collects data from the first stage user Description: The handling service, if granted the first stage user’s authorisation, operates silently in the background and captures inertial measurement unit (IMU) data, i.e., accelerometer and gyroscope data. The aforementioned data originate from the first stage user's smartphone, captured throughout the day while the first stage user performs certain activities (such as answering a call), without requiring any interaction. The handling service processes the IMU data in order to extract features related to the detection and analysis of motor PD symptoms (such as postural tremor), either standalone or in conjunction with other feature sources. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-15 Reference to scenario: US-1 Title: The syncing service stores and transmits the authorised information to i-PROGNOSIS Cloud server Description: The syncing service runs silently in the background and gets triggered when the smartphone is re-charging while being connected to a Wi-Fi network. The purpose of the syncing service is twofold. Initially, the syncing service is responsible for transforming the data (according to the protocol described in D2.2 “Data Collection and Medical Evaluation Protocol”) received from the data capturing services in order to achieve secure storage in the smartphone internal memory. Furthermore, the syncing service is also responsible for encrypting the stored data (according to D2.2) in pursuance of secure communication with the i- PROGNOSIS Cloud server. Alternatively, in a distributed learning scenario, the syncing service is also responsible for securely retrieving the probabilistic models from the i-PROGNOSIS Cloud server. The retrieved models are then forwarded to a dedicated learning mechanism responsible for adapting the models based on the data stored locally in the smartphone by the syncing service.
BP-16 Reference to scenario: US-1 i-PROGNOSIS-690494_D2.1.docx p. 88/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Title: The Cloud server stores the transmitted information from the syncing service Description: The i-PROGNOSIS Cloud server receives batches of transmitted data from each first stage user's installed syncing service. In this scope, the purpose of the Cloud server is to follow the protocol described in D2.2 regarding the transformation/anonymisation of the received information, in order to achieve secure data storage. Alternatively, in a distributed learning scenario, the Cloud server is also responsible for transmitting the up-to-date probabilistic models to first stage users' smartphones and, subsequently, for handling the aggregation process upon receiving them.
BP-17 Reference to scenario: US-1 Title: (Conditional) The movement service collects data from the first stage user Description: The movement service, if granted the first stage user’s authorisation, operates silently in the background and captures accelerometer and gyroscope data. The aforementioned data originate from the first stage user's smartwatch, captured throughout the day while the first stage user performs everyday tasks, without requiring any interaction. The movement service processes the current period’s smartwatch data in order to extract features related to the detection and analysis of motor PD symptoms, either standalone or in conjunction with other feature sources. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-18 Reference to scenario: US-1 Title: (Conditional) The sleep stage service collects data from the first stage user Description: The sleep stage service, if granted the first stage user's authorisation, operates silently in the background and captures sleep stage data, originating from the first stage user's smartwatch during sleep. The sleep stage service processes sleep stage data in order to extract sleep quality features. The aforementioned features can be employed individually or in i-PROGNOSIS-690494_D2.1.docx p. 89/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
conjunction with other feature sources to infer about the overall health deterioration as a PD related symptom. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-19 Reference to scenario: US-1 Title: The physical activity service collects data from the first stage user Description: The physical activity service, if granted the first stage user's authorisation, operates silently in the background and captures physical activity data, originating from the first stage user's smartphone or smartwatch (conditionally) during day activities. The physical activity service processes physical activity data (heart rate, steps, skin temperature) in order to extract physical activity features. The aforementioned features can be employed individually or in conjunction with other feature sources to infer about the overall health deterioration as a PD related symptom. The extracted features are then forwarded to the syncing service (more details are given in BP-15) to handle the storage process in the device’s internal memory (caching) and further communication with the i-PROGNOSIS Cloud server.
BP-20 Reference to scenario: US-1 Title: The decision sub-system infers the first stage user's behavioural changes Description: Depending on the followed approach, the decision sub-system can either be located in the mobile device/smartphone or in the i-PROGNOSIS Cloud server. In a distributed learning scenario, the decision sub-system (located in the smartphone) operates in conjunction with the syncing service at a probabilistic model level. More specifically, the syncing service either requests the latest aggregated model from the i-PROGNOSIS Cloud server or uses the latest stored models, in order to infer about the first stage user's behavioural changes. Alternatively, the decision sub-system (this time located in the Cloud server) cooperates with the syncing service at a decision level. In this scenario, the first stage user's authorised information types forming the detection behavioural model are already stored in the Cloud server, and the inference process takes place remotely (Cloud server).
i-PROGNOSIS-690494_D2.1.docx p. 90/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
BP-21 Reference to scenario: US-1 Title: The detection application suggests that the first stage user visits an expert physician Description: If the decision sub-system detects a behavioural change that points to PD and if the first stage user has chosen to receive the decision through the receive decision option, s/he receives a secure notification via the detection application in her/his smartphone indicating that s/he should visit an expert physician in order to validate/confirm the diagnosis/hypothesis (according to the medical evaluation protocol as described in D2.2), if the first stage user wishes. The notification also includes the reasons why i-PROGNOSIS reached the decision in an epitomised form and plain language. The first time the notification is received, it is fully displayed on the home screen of the detection application awaiting the first stage user to interact with the respective UI elements. The first stage user can proceed and contact an expert physician immediately or dismiss the notification. If the first stage user chooses to contact the expert physician, s/he is presented with a list of expert physicians near her/him. After finishing interacting with the notification or if the first stage user decides to dismiss the notification, the notification remains minimised on the home screen of the detection application. By tapping on it the first stage user can view the full notification.
6.4 SECOND VERSION OF PARKINSON'S DISEASE DETECTION
6.4.1 Usage scenario & UML use case diagram
Usage scenario identifier: US-2 Actors in this scenario: first stage user; adult; second stage user; expert physician System components in this scenario: smartphone; detection application; review consent option; upgrade option; withdraw consent option; help & feedback option; website; home screen; auxiliary menu; user interface (UI); UI element; movement service; physical activity service; sleep stage service; food intake service; bowel sound service; ECG processing service; handling service; image processing service; location service; text processing service; typing pattern service; voice service; syncing service; Cloud server; decision sub-system; Mandometer; smart belt; smart TV remote; smartwatch; key generator; detection behavioural model Benefits: The i-PROGNOSIS decision sub-system based on the updated detection behavioural model "learns" from the collected features extracted from different i-PROGNOSIS-690494_D2.1.docx p. 91/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
types of data arising from the second stage user's interaction with the smartphone and the use of the smartwatch, Mandometer, smart belt and smart TV remote - administered by the expert physician - in order to provide the second stage user with a final inference of extensive behavioural change that relates to PD, which will be further validated by the expert physician.
Description:
US-2 unfolds, conditionally, after US-1 or as a standalone scenario. At the end of US- 1, and if the i-PROGNOSIS decision sub-system detects a behavioural change, the first stage user is securely notified to visit an expert physician. The expert physician examines the first stage user and validates or overrules that the change in the behaviour may relate to PD. If the behavioural change is validated, the expert physician recommends to the first stage user to use four additional devices that will gather additional types of data in order for a solid decision to be reached. An adult, who has not participated in the first stage, can visit an expert physician and receive the same recommendation.
In this case, the expert physician briefs the adult / first stage user on the additional devices and their purpose and provides her/him with instructions on how to set them up and use them. Moreover, the expert physician generates a key, via a key generator, that unlocks additional features of the smartphone detection application that allow for data exchange between the additional devices and the smartphone. The adult / first stage user opens the new / existing detection application on her/his smartphone and inputs the key via the upgrade option of the home screen auxiliary menu. In case of successful activation, the adult / first stage user is presented with an updated consent form and the options to agree or decline as in US-1. If the adult / first stage user agrees, s/he becomes a second stage user, a confirmation message appears and the new services of the detection application are activated and the new UI elements appear with a short first launch tutorial on how to interact with them.
The additional usage sub-scenarios are:
If the second stage user does not have a compatible - with the detection application - smartwatch, such a smartwatch is provided66 to her/him. The second stage user pairs the smartwatch with her/his smartphone with the help of the expert physician - the smartwatch is ready to use. From this point, this usage sub-scenario unfolds as in US-1. A Mandometer is provided to the second stage user. The second stage user pairs the Mandometer with her/his smartphone with the help of the expert physician - the Mandometer is ready to use. The second stage user is instructed to place the Mandometer under her/his main meal plate when at home, during her/his main meals (breakfast, lunch, dinner). The
66 The specification of the provider (including financing) of the equipement, regarding i- PROGNOSIS as a final product, is not relevant to the scope of the present document. The options and specifications for this matter will be defined initially in D8.4 - Initial exploitation plan and socioeconomic analysis report (Month 24). i-PROGNOSIS-690494_D2.1.docx p. 92/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Mandometer captures food consumption data and streams them to the smartphone where a background service (food intake service) of the detection application captures and processes them. A smart belt is provided to the second stage user. The second stage user pairs the smart belt with her/his smartphone with the help of the expert physician - the smart belt is ready to use. The second stage user wears the smart belt around her/his abdomen at home. The smart belt captures bowel sounds and streams them to the smartphone, where a background service (bowel sound service) of the detection application captures and processes them. A smart TV remote is provided to the second stage user. The second stage user pairs the smart TV remote with her/his smartphone with the help of the expert physician - the smart TV remote is ready to use. The second stage user holds and uses the smart TV remote as a normal TV remote when at home, watching television. The smart TV remote captures electrocardiogram (ECG) data and streams them to the smartphone where a background service (ECG processing service) of the detection application captures and processes them.
Data processing services of the detection application reported in US-1 continue to function during US-2 as in US-1, with the sole difference being that the second stage user is advised by the expert physician to keep all data processing services "on" in order to capture all types of data. Each of the aforementioned background services delivers the extracted features to a syncing service, which caches and processes them and uploads the processing product on the i-PROGNOSIS Cloud server, when the second stage user's smartphone is connected to a Wi-Fi network and it is charging.
At any time and within the detection application, the second stage user can perform additional actions using the options of the auxiliary menu of the home screen that offer the same functionalities as in US-1. When the second stage user decides to uninstall the detection application from her/his smartphone, the consent is not withdrawn, data generated by the particular second stage user are not deleted, but any further data upload is terminated.
If the i-PROGNOSIS decision sub-system, based on the fusion of the acquired data and the updated detection behavioural model, produces a final inference of change in the behaviour of the second stage user that points to PD, the second stage user will receive a secure notification on her/his smartphone by the detection application to visit an expert physician in order for the expert physician to validate the change. The receive decision option is not available in the upgraded detection application.
FIGURE 7 illustrates cumulatively the use cases and the actors in US-2 as a UML use case diagram.
i-PROGNOSIS-690494_D2.1.docx p. 93/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FIGURE 7 The UML use case diagram corresponding to US-2. Human figures represent the actors participating in the usage scenario, text bubbles represent the use cases, <
i-PROGNOSIS-690494_D2.1.docx p. 94/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
6.4.2 Business processes
This section presents the list of business processes (BPs) related to usage scenario US-2.
BP-22 Reference to scenario: US-2 Title: The expert physician evaluates the inference of the decision sub-system for the first stage of detection Description: If the first stage user decides to contact an expert physician (BP-21), the expert physician schedules an appointment with the first stage user. During the appointment the expert physician requests from the first stage user to review the notification sent that includes the reasons why i-PROGNOSIS reached the inference. After reviewing the reasons why, the expert physician evaluates the condition of the first stage user based on a medical evaluation protocol (according to D2.2). If the expert physician, based on the medical evaluation, rejects the inference of i- PROGNOSIS decision sub-system, the first stage user can continue participating in the first stage of detection or quit (BP-5 or/and BP-7). If the expert physician, based on the medical evaluation, concurs with the inference of i-PROGNOSIS decision sub-system, s/he advises the first stage user to proceed with the second stage of detection. If the first stage user agrees, s/he becomes a second stage user and the following BPs unfold. If the first stage user declines, s/he is presented with options outside i-PROGNOSIS by the expert physician and s/he can quit the first stage of detection (BP-5 or/and BP-7).
BP-23 Reference to scenario: US-2 Title: The first stage user upgrades the detection application Description: The first stage user can perform the upgrade of the detection application given that certain criteria have been met. The criteria includes that the expert physician confirms the hypothesis (BP-22) of the decision sub-system, as well as the intention of the first stage user to proceed with the i-PROGNOSIS second stage of detection. In order to upgrade the detection application, the first stage user accesses the auxiliary menu by selecting the respective UI element. From the auxiliary menu the first stage user selects the upgrade option. At this time the first stage user can input the upgrade key and proceed with the upgrade process. The key is generated by the expert physician (BP-65 of US-3), via a key i-PROGNOSIS-690494_D2.1.docx p. 95/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
generator, and handed over physically to the first stage user when visiting the expert physician's office, if the expert physician agrees with the outcome of the decision sub-system. This procedure is linked to US-1 and essentially converts the first stage user to the second stage user. As a result, the detection application is upgraded in order to fit the needs of the second stage of Parkinson’s disease detection.
BP-24 Reference to scenario: US-2 Title: The expert physician provides the required devices to the second stage user Description: Following BP-22 and BP-23, the expert physician provides the second stage user with the devices required to collect additional data in order for her/him to reach a solid decision. Additional devices are: a smart belt, a smart TV remote, a Mandometer and a compatible smartwatch (if the second stage user does not already own one). For each of the devices, the expert physician briefs the second stage user about: i) the reasons why the additional devices are required, ii) the data they collect, iii) how to use them properly, iv) how to set them up and charge them, v) the safety precautions and vi) the way the second stage user can request for technical support through the detection application. If requested by the second stage user, the expert physician can help her/him pair the devices with her/his smartphone. Finally, the expert physician advices the second stage user to keep all services of the detection application "on" in order to capture all types of data.
BP-25 Reference to scenario: US-2 Title: An adult participates directly in the second stage of detection Description: An adult that has not participated in the first stage of detection can visit an expert physician in order to be examined against PD. The expert physician examines the adult with conventional methods at her/his disposal and if s/he cannot reach a solid diagnosis, s/he recommends to the adult to proceed directly to the second stage of detection. If the adult agrees, s/he downloads the detection application on her/his smartphone and upgrades it with the help of the expert physician (BP-23). The expert physician informs the user about the devices that s/he has to use at this stage of detection (BP-24) and the data collected, including, in this case, the data i-PROGNOSIS-690494_D2.1.docx p. 96/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
collected in the first stage of detection. At this point, the adult has become a second stage user.
BP-26 Reference to scenario: US-2 Title: The second stage user launches the upgraded detection application for the first time Description: On launching the upgraded detection application for the first time, the second stage user is presented with the summary of the updated consent form highlighting the new data and services involved in the second stage of detection, with the option of viewing the detailed version on the website (hyperlink that opens with a Web view component inside the application). After reading the consent (the brief version and/or the detailed one), the first stage user can either choose to accept and proceed to the confirmation screen, with the consent downloaded and stored locally on the mobile device, or decline and terminate the process. After accepting the consent form, the user entry created in the i-PROGNOSIS Cloud servers in the first stage is updated for the second stage. The second stage user is then presented with the home screen of the detection application. On the first launch, the second stage user is presented with a short first launch tutorial explaining the purpose and the operation of the UI elements (i.e. buttons, sliders, etc.) corresponding to the new services of the upgraded detection application. At this point, the updated detection application is fully functional and the second stage user can close the application window and can continue using her/his smartphone the same way as before installing the i-PROGNOSIS detection application.
BP-27 Reference to scenario: US-2 Title: The second stage user modifies the updated list of authorised data sources s/he wants to share with i- PROGNOSIS Description: After successfully upgrading and launching the updated detection application for the first time (BP-26), the second stage user can modify which services are active as in BP-4. The difference here is that three additional services appear in the list, i.e., the food intake service, the bowel sound service, the ECG processing service. The second stage user retains the option to activate/deactivate the services on demand, but s/he has been advised by the expert physician to keep all services i-PROGNOSIS-690494_D2.1.docx p. 97/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
activated to collect all types of data.
Business processes BP-5 to BP-19 apply for the second stage user as well, adapted to US-2. BP-17 to BP-19 are not conditional in US-2.
BP-28 Reference to scenario: US-2 Title: The second stage pairs the devices with her/his smartphone Description: The second stage turns on the device [smartwatch (if given for the first time in the second stage of detection), smart belt, smart TV remote or Mandometer] or its Bluetooth connectivity. S/he then turns on the Bluetooth connectivity on her/his smartphone and searches for the device on the list of the nearby devices presented on her/his smartphone. The two devices must be located near each other (<10 m). When the second stage finds the device of interest and selects it, the smartphone gets paired with the particular device. In the event of abrupt loss of connection during the devices’ communication with the smartphone, reconnection is attempted in a way that is automatic and transparent for the second stage. The pairing is lost when the device or its Bluetooth functionality is turned off, when the Bluetooth connectivity of the smartphone is turned off, or when the device and the smartphone are not nearby (< 10 m).
BP-29 Reference to scenario: US-2 Title: The food intake service collects data from the second stage user Description: The second stage user is getting ready to eat one of her/his main meals at home. At first, the second stage user turns on the Mandometer and then s/he turns on the Bluetooth connectivity on her/his smartphone. The smartphone must remain nearby (< 10 m). The two devices are paired (BP-28). The second stage user places her/his plate containing the food of her/his main meal on the Mandometer. The food intake service of the detection application, if allowed by the second stage user, detects the Mandometer and starts capturing raw data streamed by the device (the weight of the content placed on the Mandometer under a certain sampling frequency). When the second stage user finishes her/his meal, s/he turns off the Mandometer and the pairing with the smartphone stops. This is detected by the food intake service, which halts the capturing of data and i-PROGNOSIS-690494_D2.1.docx p. 98/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
processes the collected data to extract food intake-related features. When the processing (feature extraction) finishes, the extracted features are directed to the syncing service (more details are given in BP-15) that handles the storage process in the device internal memory (caching) and further communication with the i-PROGNOSIS Cloud server. The raw data are deleted from the device internal memory by the food intake service.
BP-30 Reference to scenario: US-2 Title: The bowel sound service collects data from the second stage user Description: The second stage user is at home. The second stage user wears the smart belt, adjusts it and turns it on. S/he then turns on the Bluetooth connectivity on her/his smartphone. The smartphone must remain nearby (< 10 m). The two devices are paired (BP-28) and the second stage user can continue with her/his tasks. The bowel sound service of the detection application, if allowed by the second stage user, detects the smart belt and starts capturing raw data streamed by the device (bowel sounds) under a certain sampling frequency. When the second stage user turns off the smart belt, the pairing with the smartphone stops. This is detected by the bowel sound service, which halts the capturing of data and processes the collected data to extract constipation-related features. When the processing (feature extraction) finishes, the extracted features are directed to the syncing service (more details are given in BP-15) that handles the storage process in the device internal memory (caching) and further communication with the i-PROGNOSIS Cloud server. The raw data are deleted from the device internal memory by the bowel sound service.
BP-31 Reference to scenario: US-2 Title: The ECG processing service collects data from the second stage user Description: The second stage user is at home and starts watching television. The second stage user uses the smart TV remote as a regular TV remote controller to interact with the television. If s/he wishes, she turns on the Bluetooth connectivity on the smart TV remote and on her/his smartphone. The smartphone must remain nearby (< 10 m). The two devices are paired (BP-28) and the second stage user can continue interacting with the television. The ECG processing service of the detection application, if allowed by the second stage user, detects the smart TV remote and starts capturing raw data i-PROGNOSIS-690494_D2.1.docx p. 99/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
streamed by the device (ECG signal) under a certain sampling frequency. When the second stage user turns off the smart TV remote, the pairing with the smartphone stops. This is detected by the ECG processing service, which halts the capturing of data and processes the collected data to extract ECG-related features. When the processing (feature extraction) finishes, the extracted features are directed to the syncing service (more details are given in BP-15) that handles the storage process in the device internal memory (caching) and further communication with the i-PROGNOSIS Cloud server. The raw ECG data are deleted from the device internal memory by the ECG processing service.
BP-32 Reference to scenario: US-2 Title: The decision sub-system infers the second stage user's extended behavioural changes and the probability of PD Description: The decision sub-system functions as in BP-20. The difference here is that the decision sub-system exploits the updated detection behavioural model and is trained by the additional types of data. The decision sub-system continues to be trained by data collected in US-1 and continue to be collected in US-2. As a result, it can provide an inference on extended behavioural changes of the second stage user and a more confident probability of PD.
BP-33 Reference to scenario: US-2 Title: The detection application suggests that the second stage user visits the expert physician Description: If the decision sub-system detects an extended behavioural change that points to high probability of PD, the second stage user receives a secure notification via the detection application in her/his smartphone indicating that s/he should visit the same expert physician as in BP-22, in order to validate/confirm the diagnosis/hypothesis (according to the medical evaluation protocol as described in D2.2), if the second stage user wishes. The notification also includes the updated reasons why i-PROGNOSIS reached the decision in an epitomised form and plain language. The second stage user can interact with the notification as in BP-21.
i-PROGNOSIS-690494_D2.1.docx p. 100/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
6.5 SUPPORTIVE INTERVENTIONS
6.5.1 Usage scenario & UML use case diagram
Usage scenario identifier: US-3 Actors in this scenario: second stage user; interventions user; diagnosed PD patient; expert physician; caregiver; game friend System components in this scenario: smartphone; tablet; interventions application; auxiliary menu; first launch tutorial; main menu; review consent option; website; withdraw consent option interventions platform; user interface (UI); UI element; user account; expert account; caregiver account; Cloud server; Mandometer; smart belt; smart TV remote; smartwatch; personalised game suite (PGS); intervention; assistive intervention; Exergame; Dietary game; Handwriting game; Voice game; Emogame; game instruction panel; game scenario; help & feedback option; home screen; targeted nocturnal intervention (TNI); TNI service; sleep earphones; voice enhancement intervention (VEI); VEI service; gait rhythm guidance intervention (GRGI); GRGI service; performance metric; interventions engagement data; personalisation service; scheduler service; virtual tutor; Kinect; personal computer (PC); television set (TV set); schedule option; feedback element; feedback tab; notifications tab; interventions tab; monitoring services tab; log-out option; food intake service; movement service; physical activity service; sleep stage service; bowel sound service; ECG processing service; voice service; typing pattern service; text processing service; image processing service; handling service; location service; syncing service; body/gesture recognition service; monitoring data; data-to-feedback service; behavioural modelling sub- system; interventions behavioural model; key generator Benefits: The interventions user, depending on her/his condition, takes advantage of the PGS and assistive interventions to improve her/his health status and mitigate risks relating to PD, under the supervision of the expert physician and the help of the caregiver. The i-PROGNOSIS behavioural modelling sub-system learns from the interventions user's engagement with the interventions and forms interventions behavioural models regarding the self-health management of PD.
Description:
US-3 unfolds, conditionally, after US-2 or as a standalone scenario. At the end of US- 2, and if the i-PROGNOSIS decision sub-system detects a high probability of PD, the second stage user is securely notified to revisit the expert physician. The expert physician examines the second stage user and validates or overrules the high probability of PD. If the high probability is validated, the expert physician recommends to the second stage user to proceed with the i-PROGNOSIS interventions. A diagnosed PD patient, by conventional means and not i-PROGNOSIS-690494_D2.1.docx p. 101/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
originating from the US-2, can receive the same recommendation by the expert physician. If the second stage user or diagnosed PD patient agrees to proceed with the interventions, s/he becomes an interventions user.
In this case, the expert physician briefs the interventions user on the additional devices required and the purpose of the interventions and provides her/him with instructions on how they will proceed. The expert physician67 creates a user account for the interventions user, through the interventions platform running on the i-PROGNOSIS Cloud server, and provides the interventions user with the user account credentials. The user account links the interventions user and the expert physician through the interventions platform. The interventions platform can be accessed via the interventions application on a smartphone/tablet or via a Web browser on a personal computer (PC), provided that they are connected to the internet. Once the user account is created, the expert physician evaluates and recommends which interventions shall be followed by the interventions user, depending on her/his condition and the progress of PD. Not all interventions may be required at the beginning of the interventions period. The interventions user keeps using devices and related services included in US-2, but s/he does so for monitoring purposes - not for detection purposes. If the interventions user was not a second stage user, s/he is provided with the devices and instructions on how to use them by the expert physician.
Interventions are divided in two general categories, the personalised game suite (PGS) and the assistive interventions. The interventions user downloads the interventions application on her/his smartphone and optionally on her/his tablet (if available) from the application store and logs into with her/his user account credentials. The interventions user is presented with the consent form and the options to agree or decline as in US-1 and US-2. If the interventions user agrees, s/he is presented with the home screen of the interventions application and a short first launch tutorial on the purpose of each UI element. Usage sub-scenarios regarding the interventions application are:
The interventions application has a tabbed menu (main menu). The home screen of the interventions application coincides with the first tab (feedback tab) of the main menu that displays the exercise and food intake feedback elements, and the UI elements allowing access to the contact information of both the expert physician and the caregiver. When the interventions user selects the second tab (notifications tab), s/he is presented with the next scheduled PGS game scenarios that the interventions user has to follow and other notifications.
67 Tasks relating to user administration are presented here as a responsibility of the expert physician. However, a separate role, e.g., user administrator, may be introduced to handle the respective tasks. The latter will depend on the business model adopted for the i- PROGNOSIS final product that will be presented initially in D8.4 - Initial exploitation plan and socieconomic analysis report (Month 24). i-PROGNOSIS-690494_D2.1.docx p. 102/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
When the interventions user selects the third tab (interventions tab) of the main menu, s/he is presented with the list of interventions (PGS and assistive interventions). When the interventions user selects the PGS, s/he is redirected to the Web-based interventions platform, inside the interventions application, where s/he can select the PGS category s/he wishes to engage with. If the interventions user selects any other assistive interventions from the interventions list, s/he is presented with the respective UI based on which s/he can interact with the respective intervention. When the interventions user selects the fourth tab (monitoring services tab) of the main menu, he is presented with the list of services related to monitoring [the movement service, physical activity service and sleep stage service (smartwatch), the food intake service (Mandometer), the bowel sound service (smart belt), the ECG processing service (smart TV remote), the voice service, the typing pattern service, the text processing service, the image processing service, the handling service, and the location service (mobile device)] that s/he can activate/deactivate. These services function as in US-2 and deliver monitoring data to the syncing service. The monitoring data are stored on the i-PROGNOSIS Cloud server. The interventions application has also an auxiliary menu that includes the same options and allows the interventions user to perform the same actions as in US-1 and US-2. An additional option is the log-out option that allows the user to log out from the interventions application. In such a case, all interventions application services stop.
Usage sub-scenarios relating to PGS interventions68 are:
(Applicable to all PGS games) If the interventions user wants to engage with a game category of the PGS, s/he logs into the interventions platform (if not already) via an appropriate device (PC, smartphone or tablet) and selects the appropriate game type (Exergames, Dietary game, Emogame, Voice game, Handwriting game) via the respective UI element. The interventions user is presented with the game scenario s/he has to go through and proceeds to engage with it. The virtual tutor greets the interventions user upon her/his log-in and informs her/him about new scheduled game scenarios. The expert physician logs into the interventions platform with her/his expert account credentials and set-ups the Exergame game scenarios for the particular interventions user. For the Exergames, the interventions user is provided with a Kinect device and sets it up with her/his PC, connected to a television set (TV set). Exergames are available only when the interventions user logs in from her/his PC. In the Exergames section, the interventions user is also presented with a UI element
68 Game scenarios and specific actions for each game type are not described in detail here. The refinement of the aforementioned is an ongoing process that will conclude with the initial presentation of the PGS in D4.2 - First version of PD-related risks interventions (Month 27). i-PROGNOSIS-690494_D2.1.docx p. 103/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
denoting whether or not the Kinect sensor is properly functioning. Once the interventions user selects to play and provided that the Kinect sensor is functional, s/he is presented with a screen that instructs her/him to stand properly in front of the Kinect device. Once the interventions user is positioned properly, s/he is presented with the Exergame virtual environment where s/he selects to start the Exergame and performs the game scenario. During the game scenario, a body/gesture recognition service of the interventions platform recognises the interventions user's movements based on the data provided by the Kinect. By selecting the scheduled Dietary game scenario, the interventions user is presented with the Dietary game virtual environment and s/he selects to start the Dietary game scenario. The interventions user uses the mouse/touchpad (on a PC) or her/his fingers (on a smartphone/tablet) to play the game scenario. By selecting the scheduled Emogame game scenario and provided that the device from where the scenario is accessed has a front-facing camera, or access to Kinect (similarly to the Exergames), the interventions user is presented with a screen that instructs her/him to position her/his face properly in front of the camera. Once the interventions user's face is positioned properly, s/he is presented with the Emogame virtual environment and s/he selects to start the Emogame and performs the game scenario. By selecting the scheduled Voice game scenario and provided that the device from where the game scenario is accessed has a microphone, the interventions user is presented with a screen that instructs her/him to test the microphone by speaking naturally. Once it is ascertained that the interventions user's microphone is functioning, s/he is presented with the Voice game virtual environment and s/he selects to start the Voice game and performs the game scenario. The Handwriting game is intended to be played when the interventions user logs in from her/his smartphone or tablet. By selecting the scheduled Handwriting game scenario, the interventions user is presented with a screen that instructs her/him to use a compatible stylus or her/his fingers for the game. Then, the interventions user is presented with the Handwriting game virtual environment, s/he selects to start the Handwriting game and s/he performs the game scenario. (Applicable to all PGS games) Before the interventions user selects to start and perform a game scenario s/he is presented with a short game instruction panel on how to act in the game scenario. A personalisation service adapts the game play based on the interventions user's previous performance. During the game scenario, the virtual tutor provides motivational messages to the interventions user. When the game scenario ends, the interventions user is provided with her/his performance metric regarding the particular game scenario by the virtual tutor along with a related lifestyle behavioural change message. If the interventions user is connected to other interventions users as game friends, the interventions user's performance metrics are presented in the form of a ranking among game friends. The i-PROGNOSIS-690494_D2.1.docx p. 104/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user can publish and notify this ranking to her/his game friends. Afterwards, the interventions user is redirected to the next scheduled game scenario. The interventions user is able to pause or exit the game scenario at any time and to restart it in a short-term time window. If the interventions user does not restart the game scenario within the time window or exits, the game scenario is considered by the scheduler service as missed.
Usage sub-scenarios relating to assistive interventions are:
Prior to starting walking and if s/he needs to, the interventions user, wearing the smartwatch, opens the interventions application on her/his smartphone and accesses the gait rhythm guidance intervention (GRGI) section via the dedicated UI element. The interventions user activates the GRGI via the dedicated UI element. The latter apply if the GRGI is not already activated. The activation triggers a background service (GRGI service) of the interventions application that captures the IMU and steps data streamed by the smartwatch or/and IMU data from the smartphone and processes them locally (on the smartphone) to detect a freezing episode while the interventions user is walking. If a freezing episode is detected by the GRGI service, the GRGI service triggers a rhythmic sound cue that is presented to the interventions user via the smartphone speaker or - if s/he wears -her/his earphones. The rhythmic sound cue is being reproduced until the GRGI service recognises that normal gait has been reinstated. The latter action does not terminate the GRGI service, which continues to run until the interventions user deactivates the GRGI inside the interventions application. Prior to starting talking on the smartphone and if s/he needs to, the interventions user opens the interventions application on her/his smartphone and accesses the voice enhancement intervention (VEI) section via the dedicated UI element. The interventions user activates the VEI via the dedicated UI element. The latter apply if the VEI is not already activated. The activation triggers a background service (VEI service) of the interventions application that detects when the interventions user accepts a phone call and processes her/his voice in real-time to evaluate its quality and enhance it if required. The VEI service continues to run in the background in stand-by for future phone calls until the interventions user deactivates the VEI inside the interventions application. Prior to sleeping and if s/he needs to, the interventions user, wearing the smartwatch, opens the interventions application on her/his smartphone and accesses the targeted nocturnal intervention (TNI) section via the dedicated UI element. The interventions user activates the TNI via the dedicated UI element. The latter apply if the TNI is not already activated. The activation triggers a background service (TNI service) of the interventions application that captures heart rate, accelerometer, and skin temperature data streamed by the smartwatch and processes them locally (on the smartphone) to evaluate the sleep stage and if there is a disturbance, while the interventions user is sleeping. If a sleep disturbance i-PROGNOSIS-690494_D2.1.docx p. 105/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
episode is detected by the TNI service, the service triggers pacifying sounds that are presented to the interventions user via a pair of earphones (sleep earphones) that the interventions user wears. The TNI service continues to evaluate the sleep stage and it halts the reproduction of sound when the interventions user reaches a certain sleep stage. Afterwards, the TNI service continues to run in the background in stand-by to detect potential following sleep disturbances. The TNI service is terminated when it evaluates that the interventions user woke up. When the TNI service is terminated, it also deactivates the TNI. (Applicable to all assistive interventions) Each time an assistive intervention is activated by the interventions user, this information is delivered to the syncing service that uploads it on the interventions platform, along with assistive intervention-specific data.
Interventions engagement data (performance metrics of PGS games, number of completed/quitted/missed game scenarios, number of assistive interventions activations and specific data) along with monitoring data are used by the behavioural modelling sub-system to produce an interventions behavioural model of the interventions user.
Usage sub-scenarios relating to the active role of the expert physician and the caregiver are:
The expert physician can monitor the performance/use and configure the interventions that her/his interventions users engage with. The expert physician can log into the interventions platform via a browser on her/his PC/smartphone/tablet with her/his expert account credentials. The home screen of the UI displays the interventions users that the expert physician monitors, their basic statistics regarding the use of interventions, and the option to add a new interventions user. By selecting an existing interventions user, the expert physician is transferred to the interventions user's dedicated profile page where s/he can see personal and health info, feedback elements based on the monitoring data, the interventions engagement data for the particular interventions user, the scheduled PGS game scenarios and the schedule option that allows the expert physician to schedule a new PGS game scenario and to add game friends. By selecting the schedule option, the expert physician is presented with the list of PGS interventions and by selecting an item of this list, he is presented with the UI that allows her/him to schedule the PGS game scenario, which will then appear as a scheduled PGS game scenario on the interventions user's interventions platform page. The expert physician can also select to notify the particular interventions user for the new scheduled game scenario via an interventions application notification that will appear on the interventions user's smartphone. The scheduled event and the notification are handled by the scheduler service of the interventions platform.
i-PROGNOSIS-690494_D2.1.docx p. 106/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The caregiver (if there is one) of the interventions user can monitor the performance/use of the interventions that the interventions user engages with. The expert physician can create a caregiver account on the interventions platform, upon request of the caregiver, and connect to both the interventions user and the expert physician. The caregiver with her/his caregiver account credentials can then log into the interventions platform via a browser on her/his PC/smartphone/tablet. The home screen of the UI displays the interventions users that the caregiver monitors, their basic statistics regarding the use of interventions, and the option to add a new interventions user via a request to the expert physician. By selecting an existing interventions user, the caregiver is transferred to the interventions user's dedicated page where s/he can see the contact information (for both the particular interventions user and her/his attending expert physician), the detailed interventions statistics for the particular interventions user and the scheduled PGS game scenarios. The caregiver cannot schedule a PGS game scenario. Nevertheless, the role of the caregiver is not limited solely on passive monitoring of the interventions user, but it also includes active assistance on the initiation and interaction of the interventions user with the i-PROGNOSIS interventions, especially in the case of interventions users at a later stage of PD or/and with limited computer skills.
FIGURE 8 illustrates cumulatively the use cases and the actors in US-3 as a UML use case diagram.
6.5.2 Business processes
This section presents the list of business processes (BPs) related to usage scenario US-3.
BP-34 Reference to scenario: US-3 Title: The expert physician evaluates the inference of the decision sub-system for the second stage of detection Description: If the second stage user decides to contact the expert physician (BP-21), the expert physician schedules an appointment with the second stage user. During the appointment the expert physician requests from the second stage user to review the notification sent that includes the reasons why i-PROGNOSIS decision sub-system reached the inference. After reviewing the reasons why, the expert physician evaluates the condition of the second stage user based on a medical evaluation protocol (according to D2.2). If the expert physician, based on the medical evaluation, rejects the decision of i- i-PROGNOSIS-690494_D2.1.docx p. 107/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
PROGNOSIS decision sub-system, the second stage user can continue participating in the second stage of detection by request of the expert physician or stop. If the second stage user stops, s/he handles the devices back to the expert physician and quits the second stage of detection (BP-5 or/and BP-7 adapted to US-2). If the expert physician, based on the medical evaluation, concurs with the decision of i-PROGNOSIS decision sub-system, s/he advises the second stage user to proceed with the i-PROGNOSIS interventions phase. If the second stage user agrees, s/he becomes an interventions user and the following BPs unfold. If the second stage user declines, s/he is presented with options outside i-PROGNOSIS by the expert physician and s/he handles the devices back to the expert physician and she can quit the second stage of detection (BP-5 or/and BP-7 adapted to US-2).
BP-35 Reference to scenario: US-3 Title: The expert physician creates a user account for the interventions user Description: Following BP-33 and if the second stage user agreed to proceed with the i- PROGNOSIS interventions, i.e., s/he became an interventions user, the expert physician creates a user account for the particular interventions user. S/he does so by logging into the interventions platform using her/his expert account credentials, via a browser on a PC, tablet or smartphone. In the background, the interventions platform verifies that these credentials are valid and correspond to an expert account. After logging into the interventions platform successfully, the expert physician is presented, amongst others, with the option to add a new interventions user. By selecting this option, the expert physician is presented with a screen to enter the details of the new interventions user (e.g., name, age, contact info, health status descriptors), to set the new user account username (e.g. e-mail address) and to generate or set the password. After following these steps, the expert physician selects to finish the creation of the new user account that leads to the interventions user being added to the interventions users that s/he monitors and the new user account to be created in the interventions platform Cloud-server. Then, the expert physician provides the user account credentials to the interventions user. By using these credentials, the interventions user can log into the Web-based interventions platform, via a browser on her/his PC, tablet or smartphone, or into the mobile interventions application on her/his smartphone or tablet.
BP-36
i-PROGNOSIS-690494_D2.1.docx p. 108/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Reference to scenario: US-3 Title: The interventions user downloads and installs the interventions application Description: Prior to downloading and installing the interventions application, the interventions user is asked by the expert physician to uninstall the detection application, if already installed on the interventions user's smartphone. The latter takes place in order to avoid conflicts between common background services of the two applications. Then and after locating the i-PROGNOSIS interventions application in the application store with the help of the expert physician, the interventions user follows the standard application installation procedure as in BP-2. The main installation process also installs all the required background services on the mobile device (smartphone or tablet). The required access list includes granting access to: Read text messages Network adapter (Wi-Fi) Phone calls Storage Location Camera Image Gallery Motion sensors (accelerometers, gravity, gyroscopes and rotational vector sensors) Environmental sensors (barometers, photometers and thermometers) Position sensors (orientation sensors and magnetometers) Microphone sensor Keyboard input The i-PROGNOSIS intervention application is now installed on the interventions user's mobile device.
i-PROGNOSIS-690494_D2.1.docx p. 109/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FIGURE 8 The UML use case diagram corresponding to US-3. Human figures represent the actors participating in the usage scenario, text bubbles represent the use cases, <
BP-37 Reference to scenario: US-3 Title: The expert physician provides the required devices to the interventions user Description: Following BP-34 to BP-36, the expert physician provides the interventions user with the devices required during the interventions phase, depending on the type of interventions that the interventions user will follow. The devices that can be provided to the interventions user are a Kinect, a stylus and a pair of sleep earphones. The latter apply for interventions users who were second stage users. For each of the devices, the expert physician briefs the interventions user about: i) the reasons why the additional devices are required, ii) the data they collect, iii) how to use them properly, iv) how to set them up and charge them, v) the safety precautions and vi) the way the interventions user can request technical support through the interventions application. If requested by the interventions user, the expert physician can help her/him pair the devices with her/his smartphone. Finally, the expert physician advices the second stage user to keep all services capturing monitoring data of the interventions application activated in order for the monitoring process to be effective. If during the interventions phase, the expert physician decides that additional types of interventions should be followed by the interventions user, the interventions user is contacted and asked to visit the expert physician, who, in turn, provides her/him with the additional required devices and information on how to use them properly, as described above.
BP-38 Reference to scenario: US-3 Title: A diagnosed PD patient participates directly in the interventions phase Description: A diagnosed PD patient that has not participated in the i-PROGNOSIS detection stages can visit an expert physician in order to use the i-PROGNOSIS interventions. The expert physician examines the diagnosed PD patient with conventional methods at her/his disposal to assess the condition of the diagnosed PD patient and suggest the interventions that s/he should follow. If the diagnosed PD patient agrees to proceed with the interventions phase, s/he becomes an interventions user. From this point on, BP-35 to BP-37 unfold. The only difference is that the interventions user is provided from the beginning of the interventions phase with additional devices, i.e., a Mandometer, a smart belt, a smart TV remote and a compatible smartwatch (if s/he does not own one already) by the expert i-PROGNOSIS-690494_D2.1.docx p. 111/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
physician.
BP-39 Reference to scenario: US-3 Title: The interventions user launches the interventions application for the first time Description: By tapping on the interventions application icon on her/his mobile device (smartphone or tablet) for the first time, the interventions user is presented with a log-in screen. By entering her/his user account credentials correctly (see also BP-41), the interventions user is presented with the interventions consent form and follows the steps to agree or decline as in BP-3. If the interventions user agrees, the interventions platform entry for the particular user account is updated with this information, i.e., the interventions user gave consent, and s/he is presented with the UI of the interventions application and a first launch tutorial about the functionality of each UI element and how s/he can interact with it. After the first launch tutorial ends, the interventions application is ready to use and the respective background services are active. If the interventions user does not give consent, a screen appears that displays a message that the interventions application cannot be used without consent and the options to launch the consent process again or log out. By selecting to launch the consent process again, the interventions user is presented with the interventions consent form and the necessary steps, as mentioned above. If the interventions user selects to log-out, the log-out process takes place and s/he is presented again with the log-in screen. Until the interventions user gives consent, all background services of the interventions application are inactive.
BP-40 Reference to scenario: US-3 Title: The interventions user logs into the Web-based interventions platform for the first time and navigates through it Description: In order to log into the interventions platform, the interventions user opens a browser on her/his PC or mobile device (smartphone or tablet) and types in the Web address of the interventions platform. The interventions platform loads and the log-in page appears. If the interventions user enters the user account credentials correctly (BP-41), s/he is presented with the detailed consent form and the options to agree or decline. If the interventions user declines, s/he is redirected to the log-in screen. i-PROGNOSIS-690494_D2.1.docx p. 112/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
If the interventions user agrees, s/he is presented with the home screen UI of the interventions platform that coincides with the UI of the personalised game suite (PGS). Thus, in the case of the interventions user, the home screen presents the game types of the PGS (BP-51). Through the UI of the interventions platform, the interventions user can seek for technical support (BP-61) or log out (BP-44) via the dedicated UI elements.
BP-41 Reference to scenario: US-3 Title: The interventions user logs into the mobile interventions application or the Web-based interventions platform Description: The interventions user can log into the interventions application on her/his mobile device (smartphone or tablet) or into the interventions platform via a browser on her/his mobile device or PC. In both situations, the interventions user is presented with a log-in screen where s/he has to enter her/his user account credentials. When the interventions user enters the credentials and selects to log in, the credentials are checked against the entries of the interventions platform to grant access or not. If the interventions user enters the user account credentials correctly, s/he presented with the home screen of the interventions application (except for the first launch) or home screen of the interventions platform. If the interventions user enters wrong credentials, a message appears on the log-in screen displaying which of the credentials was wrong (username or/and password). If the interventions user has forgotten her/his password, s/he can select the option on the log-in screen that activates the process of resetting the user account password. By selecting the latter option, an e-mail with a hyperlink is sent to the provided e-mail address of the interventions user. The interventions user must access the e-mail and click on the hyperlink. By clicking on the hyperlink, s/he is redirected to a dedicated page of the Web-based interventions platform that allows her/him to enter a new password and save it. The latter process is standard regardless of the device that the interventions user is using. If the interventions user has forgotten both her/his credentials, s/he can contact the expert physician to provide her/him with the correct user account credentials, securely. If the interventions user logs into the interventions application on a mobile device successfully once, s/he stays logged in, until s/he decides to log out or uninstalls the interventions application from the mobile device. If the interventions user desires to use the installed interventions application on another mobile device, s/he has to log in again. If the interventions user logs into the Web-based interventions platform, s/he remains logged in a period of time (specified by an authentication cookie) - i-PROGNOSIS-690494_D2.1.docx p. 113/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
even if s/he closes the browser - after which s/he has to log in again. The interventions user can also log out on demand at any time using the respective option on the home screen of the interventions platform.
BP-42 Reference to scenario: US-3 Title: The interventions user navigates through the interventions application Description: When the interventions user launches the interventions application on her/his mobile device and provided that s/he has logged in (except for the first launch of the application), s/he can see the home screen and the main menu of the application that consists of three tabs and the auxiliary menu. In the first tab (feedback tab), visible on launching the interventions application, the interventions user can see the feedback elements with each one providing easy-to-understand information or graphs arising from the monitoring data. Not all monitoring data will be transformed to feedback elements. The feedback elements are refreshed on a scheduled basis (daily, weekly or monthly). The interventions user can also see the options to contact her/his expert physician and caregiver (if there is one). By selecting one of these options, the interventions user is presented with the respective contact information (telephone number, address and e-mail). By selecting the second tab (notifications tab), the interventions user is presented with the scheduled game scenarios that s/he has to follow, as well as notifications arising from the PGS interventions, such as "pokes" from her/his game friends. Each entry in the notifications tab includes the date it was created. Entries on this tab are pushed by the scheduler service of the interventions platform. By selecting the third tab (interventions tab), the interventions user is presented with the list of interventions. The list includes four options corresponding to the personalised game suite interventions, the targeted nocturnal intervention (TNI), the voice enhancement intervention (VEI), and the gait rhythmic guidance intervention (GRGI). By selecting one of these options, the interventions user is presented with the respective UI and s/he can further interact with the respective intervention. By selecting the fourth tab (monitoring services tab), the interventions user is presented with the list of background services of the interventions application that capture monitoring data and the respective UI elements (checkbox or slider) that allow her/him to activate/deactivate each service. Certain background services maybe a priori deactivated or non-existent depending on the mobile device the interventions application is installed on. By selecting the auxiliary menu, the interventions user is presented with the same options and can perform the same actions, adapted to US-3, as in BP-5, BP-6 and BP-8. There is also the additional option of logging out that allows the i-PROGNOSIS-690494_D2.1.docx p. 114/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user to log out from the interventions application on the particular mobile device.
Business processes BP-5, BP-6 and BP-8 apply for the interventions user as well, adapted to US-3.
BP-43 Reference to scenario: US-3 Title: The interventions user logs out on demand from the mobile interventions application Description: When inside the interventions application, the interventions user selects the auxiliary menu and then the option to log-out. A confirmation message appears with the options to log out or cancel the action. If the interventions user selects to log out, s/he is then presented with the log-in screen. By logging out, all background services of the interventions application halt in the particular mobile device and no data is uploaded on the Cloud server. The background services are activated once the interventions user logs in again. The log-out action does not affect the log status of the interventions user on other mobile devices or the Web-based interventions platform. If the interventions user selects to cancel, the log out action is cancelled and s/he stays logged-in in the particular mobile device.
BP-44 Reference to scenario: US-3 Title: The interventions user logs out on demand from the interventions platform Description: When inside the interventions platform from a browser on PC or a mobile device (smartphone or tablet), the interventions user selects the option to log out using the respective UI element. A confirmation message appears with the options to log out or cancel the action. If the interventions user selects to log out, s/he is then presented with the log-in screen. The log-out action does not affect the log status of the interventions user or background services in other mobile devices or the Web-based interventions platform on another PC. If the interventions user selects to cancel, the log out action is cancelled and s/he stays logged-in until other conditions apply (BP-41).
i-PROGNOSIS-690494_D2.1.docx p. 115/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
BP-45 Reference to scenario: US-3 Title: The interventions user accesses the intervention platform through the interventions application (interventions tab) on her/his mobile device Description: When inside the interventions application on a mobile device (smartphone or tablet), the interventions user selects the second tab on the main menu (interventions tab). The interventions user is presented with the list of interventions and s/he selects the item corresponding to the PGS interventions. A Web-view opens inside the interventions application and the interventions user is presented with the home screen of the interventions platform. The interventions user does not log into the interventions platform again, as s/he logged in the interventions application. When finishing her/his interaction with the interventions platform, the interventions user can close the Web view via the respective UI element. By closing the Web view, the interventions user is presented back with the interventions tab of the interventions application.
BP-46 Reference to scenario: US-3 Title: The interventions user modifies the status (active/deactivated) of the interventions application background services that capture monitoring data Description: When inside the interventions application on a mobile device (smartphone or tablet), the interventions user selects the monitoring services tab of the main menu. The interventions user is presented with the list of background services that capture monitoring data. Each item on the list has a UI element (check box or slider) that allows the interventions user to activate/deactivate the respective background service. If the interventions user deactivates a background service, the service halts immediately and no data are uploaded on the Cloud server by the particular service. Depending on the background service deactivated, the pairing between the mobile device (smartphone or tablet) and the Mandometer, smart TV remote and smart belt or smartwatch through the interventions application is not possible. When the interventions user deactivates a background service on a mobile device, the activation status of the service is not affected on other mobile devices.
i-PROGNOSIS-690494_D2.1.docx p. 116/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Business processes BP-9, BP-10 to BP-15, BP-17, BP-18, BP-19, BP-28, BP-29, BP- 30 and BP-31 apply for the interventions user as well, adapted to US-3.
BP-47 Reference to scenario: US-3 Title: Data collected from the interventions user are transformed to feedback elements by the data-to- feedback service Description: A data-to-feedback service on the Cloud server, part of the interventions platform, will be responsible for the transformation of monitoring data and interventions engagement data into statistical measures. In particular, the data- to-feedback service will draw the stored monitoring data and interventions engagement data from the respective fields of an interventions user's entry in the Cloud server database, based on her/his user account, and it will calculate all the predefined statistical measurements. The statistical measurements will then be passed through the appropriate channels (interventions application or interventions platform) so as to be presented to the respective actors. Either on the interventions application or the interventions platform, statistical measures produced by the data-to-feedback service will be formalised into preformatted feedback elements, the appearance of which will depend on the type of data. These feedback elements will then be communicated to the interventions user via the mobile interventions application, as well as the expert physician and the caregiver via the Web-based interventions platform. The content of the feedback elements will be refreshed on a scheduled basis (e.g., weekly). Not all monitoring data will be formalised into feedback elements.
BP-48 Reference to scenario: US-3 Title: The interventions user uses the targeted nocturnal intervention (TNI) Description: As the interventions user prepares to sleep for the night, s/he launches the interventions application on her/his mobile device (smartphone or tablet). S/he selects the interventions tab and, afterwards, the TNI option. The interventions user is transferred to the dedicated UI of the TNI, where s/he can activate the intervention via the respective UI element. The latter steps apply if the TNI is not already activated. When activated, the TNI service is also triggered. The interventions user is presented with a message warning her/him that for the TNI to function properly s/he must wear her/his smartwatch and sleep earphones. The interventions user can also select the type of pacifying sounds that will be i-PROGNOSIS-690494_D2.1.docx p. 117/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
reproduced, in case of sleep disturbance, from a list via the respective UI element (checkbox) adjacent to an item on the list. The interventions user can leave/close the interventions application. The interventions user, having activated the TNI and wearing her/his smartwatch and sleep earphones falls into sleep. The interventions user's mobile device must be located nearby (< 10 m). As the interventions user sleeps, accelerometer, heart rate and skin temperature data are captured by the smartwatch and streamed to the mobile device. The TNI service captures the streamed data and, based on the time of day, processes them in order to infer if the interventions user is sleeping along with the sleep stage, at a certain sampling rate. If a sleep disturbance episode is detected, based on the sleep stage history, the TNI service triggers the playback of the pacifying sounds selected by the interventions user. The sounds are played back to the interventions user through the sleep earphones at a user-defined volume level. The TNI service continues to assess the sleep stage of the interventions user. When, the TNI service infers that a satisfactory sleep stage level has been reinstated, it stops the reproduction of sounds. The TNI service continues to assess the sleep stage of the interventions user and if a new sleep disturbance episode is detected, the aforementioned process is repeated. The TNI service halts its operations when it infers that the interventions user woke up, based on the time and the streamed smartwatch data. After waking up or when s/he wishes to, the interventions user can deactivate the TNI via the interventions application. The latter stops the TNI service operations indefinitely. If the interventions user wishes to use the TNI for the following night s/he has to activate it again. If the interventions user does not deactivate the TNI, at some point after waking up, the TNI service remains idle or it is triggered based on the time of day. During its active status, the TNI service records statistics regarding the times the interventions user activated the TNI on demand, as well as, how many sleep disturbance episodes the interventions user experienced during the night (if any) per night. The statistics data are handled to the syncing service in order to be uploaded on the Cloud server.
BP-49 Reference to scenario: US-3 Title: The interventions user uses the voice enhancement intervention (VEI) Description: The interventions user launches the interventions application on her/his smartphone. S/he selects the interventions tab of the main menu and, afterwards, the VEI option. The interventions user is transferred to the dedicated UI of the VEI, where s/he can activate the intervention via the respective UI element. The latter steps apply if the VEI is not already activated. When activated, the VEI service is also triggered. The interventions user can leave/close the interventions application. i-PROGNOSIS-690494_D2.1.docx p. 118/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The VEI service waits for the smartphone to receive a phone call. Upon receiving a phone call and if the interventions user accepts it, the VEI service starts capturing the interventions user's voice data and processes them, in real-time, to assess the voice quality, at a specific sampling rate. When the VEI service infers that the voice quality of the interventions user deteriorates, it triggers the voice enhancement process that receives raw voice segments as input, enhances them near real-time and outputs the enhanced voice segments. The enhanced voice segments are then passed to the interventions user's listener via the phone call, with the smallest possible delay. The VEI service, in parallel, continues to assess the interventions user's voice quality and when it infers that the interventions user has managed to improve her/his voice quality, it halts the voice enhancement process. The VEI service continues to assess the voice quality and repeats the aforementioned process if needed during the phone call. When the phone call ends, the VEI service halts its operations and returns to the idle state, waiting for the next phone call. The VEI service is completely deactivated when the interventions user deactivates the VEI through the interventions application. During its active status, the VEI service records statistics regarding the time the interventions user kept the VEI active, as well as, how many times the voice enhancement process was triggered during a phone call per duration of the phone call. The statistics data are handled to the syncing service in order to be uploaded on the Cloud server.
BP-50 Reference to scenario: US-3 Title: The interventions user uses the gait rhythmic guidance intervention (GRGI) Description: The interventions user prepares to walk, either in public or at her/his home. S/he launches the interventions application on her/his smartphone. S/he selects the interventions tab of the main menu and, afterwards, the GRGI option. The interventions user is transferred to the dedicated UI of the GRGI, where s/he can activate the intervention via the respective UI element. The latter steps apply if the GRGI is not already activated. When activated, the GRGI service is also triggered. The interventions user is presented with a message warning her/him that for the GRGI to function more effectively s/he must wear her/his smartwatch and preferably earphones. The interventions user can leave/close the interventions application. With the GRGI activated and wearing her/his smartwatch, the interventions user starts walking. The interventions user must also carry her/his smartphone. As the interventions user walks, the smartwatch streams accelerometer and gyroscope data to the smartphone. IMU data provided by the smartphone are also exploited. The GRGI service captures the streamed smartwatch data and/or smartphone IMU data and assesses the gait rhythm. If the GRGI service detects a freezing episode, i.e., the interventions user stops walking and her/his feet are i-PROGNOSIS-690494_D2.1.docx p. 119/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
"glued" to the ground, it triggers a rhythmic acoustic cue that is being played back to the interventions user through her/his earphones, connected to her/his smartphone, or the smartphone speaker. The GRGI service assesses, in parallel, the gait rhythm and by the time the rhythm has been reinstated to normal, it stops the reproduction of the acoustic cue. The GRGI service continues to assess the gait rhythm and repeats the whole process if needed. When the interventions user desires to, s/he deactivates the GRGI through the interventions application. During its active status, the GRGI service records statistics regarding how many times the GRGI was activated on demand by the interventions user, as well as, how many freezing episodes were detected per GRGI use. The statistics data are handled to the syncing service in order to be uploaded on the Cloud server.
BP-51 Reference to scenario: US-3 Title: The interventions user selects the appropriate game type and engages with the game scenario Description: Just after logging into the interventions platform successfully, the interventions user is presented with the UI of the personalised game suite (PGS) and the UI elements corresponding to the different game types that are enabled for her/him. Maximum five categories will be presented to the user as options via large, illustrated and well discriminated UI elements. The options, depending on what has been assigned to the interventions user by the expert physician, may include Exergames scenarios, Dietary game scenarios, Emogame scenarios, Voice game scenarios and Handwriting game scenarios. This presumes that the expert physician has already assigned a first set of game scenarios for the particular interventions user (BP-52). Once the interventions user selects the preferred game type, the virtual environment of the game scenario is presented to her/him. Prior to the beginning of the selected game scenario, the virtual tutor informs the interventions user about the game scenario that follows. The information presented is about the expected duration, the type of game, the scope of the game and the achievements (goal oriented) that will be pursued during game play. If the expert physician customised a set of game scenarios that span more than one game type, the virtual tutor motivates the interventions user to go through all game types regularly and according to the schedule created by the expert physician and delivered by the scheduler service to the interventions user.
BP-52 Reference to scenario: US-3 Title: The expert physician set ups a game scenario for a i-PROGNOSIS-690494_D2.1.docx p. 120/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
particular interventions user, via the interventions platform Description: When the expert physician logs into the interventions platform, the home screen of the UI displays, amongst others, the interventions users that s/he monitors. By selecting an existing interventions user, the expert physician is transferred to the interventions user's dedicated profile page where s/he can see, amongst others, the scheduled PGS game scenarios and the schedule option that allows the expert physician to schedule a new PGS game scenario for the particular interventions user and to add game friends. From the list of the already scheduled game scenarios, the expert physician can delete or modify the game scenario through the UI elements, adjacent to the list item. If the expert physician selects to modify a scheduled game scenario, s/he is presented with the scheduling options and with the options to save the game scenario or cancel it (see below). By selecting the option to schedule a new game scenario, the expert physician is presented with a list of the available game scenarios. By selecting an item of this list, s/he is presented with the scheduling options. From there, s/he can modify the scheduling options of the particular game scenario, i.e., the frequency as well as the parameters and baseline difficulty of certain game scenarios. Then, the expert physician can save or cancel the new game scenario. When the expert physician modifies/deletes an already scheduled game scenario or adds a new scheduled game scenario, this information is passed to the scheduler service that further passes it through the appropriate channels to the interventions user and the caregiver.
BP-53 Reference to scenario: US-3 Title: The expert physician adds game friends for a particular interventions user, via the intervention platform Description: When inside the profile of an interventions user and when modifying or adding a new scheduled game scenario, the expert physician can add/modify game friends regarding the particular game scenario. S/he does so by selecting the respective UI element and bulk-selecting other interventions users from the list. Only interventions users monitored by the particular expert physician are included in the list. Game friends can be either interventions users, who are friends with the particular interventions user in real life, or interventions users unknown to the interventions user, expanding, in this way, the socialisation of the interventions user. The criteria based on which the expert physician decides which game friends are added are not standard and rely on the judgment of the expert physician. i-PROGNOSIS-690494_D2.1.docx p. 121/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
However, factors such as the condition of the interventions user or the age may be taken into consideration. Upon request of the interventions user, the expert physician may delete game friends.
BP-54 Reference to scenario: US-3 Title: The interventions user set ups the Kinect device, required for the Exergames, at home, for the first time Description: For the Exergames, the interventions user is provided with a Kinect sensor by the expert physician and sets it up with her/his PC, connected to a television set (TV set). The PC handles the Kinect connectivity automatically without any action from the interventions user side and is responsible for uploading Kinect data on the interventions platform Cloud server. To facilitate the interventions user with identifying any malfunctions, the Kinect connectivity status is presented to her/him through a dedicated UI element of the interventions platform UI, when logged-in. The interventions platform must enable the actor (not exclusively the interventions user) to configure the connection and the settings, pertaining to the Kinect device, during the set up of the first time.
BP-55 Reference to scenario: US-3 Title: The interventions user is guided by the Exergames to position her/himself in the viewport of Kinect Description: When engaging with an Exergame game scenario, the interventions user is guided to position her/him self in the viewport of the Kinect device, based on continuously assessing the interventions user’s postures and gestures (body/gesture recognition service). The latter process occurs every time the Exergame cannot identify the silhouette of the interventions user. In such a case, the current game scenario gets paused and animated instructions on where and how the interventions user must stand in order to be in the Kinect field of view are presented. Once the interventions user gets into the Kinect field of view, the game scenario resumes to where it was left, automatically.
BP-56 Reference to scenario: US-3
i-PROGNOSIS-690494_D2.1.docx p. 122/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Title: The interventions user is presented with a game instruction panel before each game scenario Description: Before the beginning of each game scenario, a game instruction panel is presented to the interventions user. The panel provides multimodal instructions about the game play or the physical task to be undertaken during the game scenario. A combination of a short video showing a person doing the task that is required by the interventions user to perform with text, sounds and symbols is included in the panel. The virtual tutor has an active role in presenting the instructions. The interventions user takes as much time as s/he wants to get through the instructions or repeat the video. After assimilating the instructions, the interventions user may press the start button to continue. A short count-down is presented that allows for the interventions user to prepare before the game scenario begins.
BP-57 Reference to scenario: US-3 Title: A personalisation service adapts the game play based on the interventions user's previous performance Description: Being initially determined by the expert physician as a baseline, the game settings and difficulty are continuously being adapted to the interventions user's condition and needs. The personalisation service, executed at the end of each game scenario, accumulates the previous performance metrics, analyses them and elicits the new difficulty levels which will be applied to the updated game scenarios, the next time the interventions user logs into the interventions platform. If it is required and depending on the processing power available on the Cloud server, the personalisation service may be executed once per two or three game scenarios, provided that the interventions user's status does not change dramatically within one week time.
BP-58 Reference to scenario: US-3 Title: The interventions user is provided with motivational messages and performance metrics during/after a game scenario Description: During the game scenario and at particular triggering events, the interventions user is presented with motivational messages by the virtual tutor. The i-PROGNOSIS-690494_D2.1.docx p. 123/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user receives encouraging messages or reward messages regarding her/his performance metrics or her/his effort during the game play. Messages appear as pop-up texts on the corners of the game scenario virtual environment or are provided orally to the interventions user. At the end of each game scenario, an overview of the performance metrics, in the form of scores or achievements, is presented to the interventions user. Given the expected deterioration of the physical capacity over time, the interventions user may be keen on being presented with her/his achievements instead of scores as performance metrics. A mechanism inside the PGS undertakes the transformation of scores to achievements. When applicable, the virtual tutor will provide also hints regarding lifestyle behavioural changes related to the scope of the game scenario for the interventions user to follow them in their everyday lives or as motives to improve her/his performance during the PGS games.
BP-59 Reference to scenario: US-3 Title: The interventions user is presented with her/his performance metrics compared to the game friends Description: Provided that the expert physician assigned game friends to the interventions user (BP-53), the PGS promotes socialisation by encouraging social interaction with the interventions user’s game friends. In particular, the PGS encourages collaboration or competition among the game friends by presenting to the interventions user with her/his game friends' performance metrics after each game scenario ends. Alongside, the interventions user can use an intuitive way - a gesture at the end of the game scenario or through a UI element - to publish her/his achievements to her/his game friends (e.g., "poke" them) via the intervention platform or the intervention application.
BP-60 Reference to scenario: US-3 Title: The interventions user manages the progression of a game scenario Description: The interventions user is given certain options to manage the progression of a game scenario. The interventions user can pause the game scenario at any time and to restart it within a short-term time window. The interventions user can select to pause a scenario either by an intuitive gesture (using the Kinect) or via a dedicated UI i-PROGNOSIS-690494_D2.1.docx p. 124/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
element appearing on the screen. When a game scenario is paused, the interventions user is presented with a countdown, corresponding to the specified time window, and the option to completely exit the scenario. If the interventions user does not restart the game scenario within the time window or exits the game scenario, the game scenario is considered by the scheduler service as missed. Therefore, in case of an interruption of the game scenario by mistake, the interventions user will not be redirected to the beginning of the game scenario. During the game scenario, the interventions user can review the game instructions panel either by making an intuitive gesture or via the dedicated UI element. In such a case, the game scenario pauses and the game instructions panel appears for a specified time window. As soon as, this time window ends, the game scenario continues automatically. When the game scenario finishes and the performance metrics panel is presented, the interventions user is redirected to the next scheduled game scenario. A panel with the performance metrics of all the performed game scenarios is presented to the interventions user after the last scheduled game scenario.
BP-61 Reference to scenario: US-3 Title: The interventions user seeks for technical support Description: In case the interventions user wishes to receive technical support, s/he can do so either via the interventions application or the interventions platform. The procedure regarding the interventions application is described in BP-8. Regarding the interventions platform, the interventions user can receive support from any screen of the interventions platform, provided that s/he is logged-in, via the respective UI element. When selecting the UI element, the interventions user is redirected to a page of the interventions platform, where s/he presented with hyperlinks to a frequently asked questions (FAQ) section, a tutorial videos section, and a contact form section. By clicking on a hyperlink, the interventions user is presented with the respective content, i.e., a set of FAQ and answers, a number of short video tutorials about key functionalities relating to the interventions platform or the interventions application, and a contact form that s/he can fill and submit/send to the i-PROGNOSIS technical support.
BP-62 Reference to scenario: US-3 Title: The virtual tutor augments the interaction of the interventions user with the PGS interventions Description: The virtual tutor has a supportive and guiding role in the interaction of the i-PROGNOSIS-690494_D2.1.docx p. 125/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user with the PGS of the interventions platform. Every time the interventions user logs into the interventions platform, s/he is greeted by the virtual tutor that further communicates to the interventions user if there are any new scheduled game scenarios. Additionally, the virtual tutor is involved in the presentation of the game instruction panel of each game scenario (BP-56). During a game scenario, the virtual tutor provides motivational messages to the interventions user and upon completing the game scenario the virtual tutor presents the interventions user with a message containing lifestyle behavioural change tips (BP-58). The interaction of the virtual tutor with the interventions user is one way, i.e., the virtual tutor communicates messages to the interventions user, but the interventions user cannot dictate commands to the virtual tutor. Messages to the interventions user are communicated in natural language, orally and/or in written text appearing on the screens of the PGS - the latter will depend on the device from where the interventions platform is accessed by the interventions user. The virtual tutor will be a virtual anthropomorphic avatar and it will appear on a fixed position in the different screens of the PGS. The virtual tutor will also have a first name.
BP-63 Reference to scenario: US-3 Title: The behavioural modelling sub-system forms an interventions behavioural model Description: The behavioural modelling sub-system will use the monitoring data and the interventions engagement data produced by a particular interventions user and stored on the Cloud server of the interventions platform as input. The latter data will form the behaviour of the interventions user. The behavioural modelling sub-system will then process this behaviour and its inner correlations in order to produce an interventions behavioural model that will output the dynamic behavioural score of the interventions user related to different aspects of life style (e.g. dietary habits or physical exercise) that may also relate to PD, a general interventions user's score and sub-scoring regarding the engagement and motivation. The interventions behavioural model will be updated by the behavioural modelling sub-system on a scheduled basis based on the new behaviour of the interventions user over time. The outputs of the interventions behavioural model will allow for dynamic predictions concerning the risk of drop-outs and the performance of the interventions user.
BP-64 Reference to scenario: US-3 i-PROGNOSIS-690494_D2.1.docx p. 126/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Title: The expert physician or caregiver logs into the interventions platform Description: By opening a browser on a PC, smartphone or tablet, the expert physician or caregiver can access the Web address of the interventions platform. The expert physician or caregiver is presented with the log-in screen of the interventions platform, if s/he is not already logged in. The expert physician or caregiver enters her/his expert or caregiver account credentials and s/he waits while the credentials are checked against the user entries of the interventions platform in terms of validity. If the credentials are valid and depending on the identified role the expert physician or caregiver is presented with the respective UI of the interventions platform. If the expert physician or caregiver enters wrong credentials, a message appears on the log-in screen displaying which of the credentials was wrong (username or/and password). If the expert physician or caregiver has forgotten her/his password, s/he can select the option on the log-in screen that activates the process of resetting the account password as in BP-41. The expert physician or caregiver stays logged-in until other conditions apply (end of BP-41) or s/he logs out on demand via the respective UI element. If it is the first time that an expert physician or caregiver logs into the interventions platform, at first, s/he presented with the license agreement and the options to agree or decline. If s/he agrees, s/he can proceed with using the interventions platform. If s/he denies, s/he is returned to the log-in screen.
BP-65 Reference to scenario: US-3 Title: The expert physician navigates, interacts with and receives feedback through the intervention platform Description: When logged into the interventions platform, the expert physician is presented with the respective UI and can perform certain actions. The home screen of the interventions application includes a list of the interventions users that s/he monitors (only) and a list of the caregivers s/he collaborates with (only). The options to add a new interventions user (BP-35) or a caregiver (BP-67) and the option to generate a new upgrade key for the detection application (BP-23) via a key generator are also present on the home screen via dedicated UI elements. By selecting an interventions patient from the list, the expert physician is redirected to the profile page of the particular interventions user where s/he can: See the interventions engagement data regarding the performance metrics and compliance of the interventions user with the PGS interventions, the statistics of usage provided by the assistive interventions (end of BP-48, BP-49, BP-50), monitoring data deductions i-PROGNOSIS-690494_D2.1.docx p. 127/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
and interventions behavioural model outputs in the form of qualitative or quantitative feedback elements. See the personal and health information of the particular interventions user and the caregiver assigned to her/him. The expert physician can modify the profile information of the interventions user by selecting the respective UI element. See the scheduled, missed and performed game scenarios of the interventions user and modify the scheduled game scenarios or add a new scheduled game scenario (BP-52). S/he can also add game friends for each game scenario (BP-53). In case of any modification, the expert physician can either cancel or save the modifications made to the interventions user's profile. The expert physician can then close the profile of the particular interventions user. If there are unsaved modifications to the profile, the expert physician is warned and is given to options to exit the profile by saving it or not. At any time the expert physician can log out from the interventions platform via the dedicated UI element. The process described in BP-44 applies here. Based on the feedback received for each interventions user, the expert physician contacts the interventions user to schedule appointments during the interventions phase so as for the expert physician to systematically and medically evaluate (according to D2.2) the progress of the interventions user.
BP-66 Reference to scenario: US-3 Title: The caregiver navigates, interacts with and receives feedback through the intervention platform Description: When logged into the interventions platform, the caregiver is presented with the respective UI and can perform certain actions. The home screen of the interventions application includes the list of the interventions users that s/he cares for (only). By selecting an interventions patient from the list, the caregiver is redirected to the profile page of the particular interventions user where s/he can: See the interventions engagement data regarding the performance metrics and compliance of the interventions user with the PGS interventions, the statistics of usage provided by the assistive interventions (end of BP-48, BP-49, BP-50), monitoring data deductions and interventions behavioural model outputs in the form of qualitative or quantitative feedback elements. See the contact information of the particular interventions user and of the expert physician that monitors her/him. See the scheduled, missed and performed game scenarios of the interventions user. The caregiver can close the profile of the particular interventions user via the i-PROGNOSIS-690494_D2.1.docx p. 128/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
dedicated UI element. The caregiver can also seek for technical support through the interventions platform to help the interventions user with any issues. The process described in BP-62 regarding the interventions platform applies here. At any time the caregiver can log out from the interventions platform via the dedicated UI element. The process described in BP-44 applies here.
BP-67 Reference to scenario: US-3 Title: The expert physician creates/modifies a caregiver account and assigns interventions users via the interventions platform Description: After logging into the interventions platform successfully, the expert physician is presented, amongst others, with the option to add a new caregiver. By selecting this option, the expert physician is presented with a screen to enter the details of the new caregiver (e.g., name, age, contact info), to set the new caregiver account username (e.g. e-mail address) and to generate or set the password. Additionally, s/he can assign an interventions user to the caregiver. After following these steps, the expert physician selects to finish the creation of the new caregiver account that leads to the caregiver being added to the caregivers that s/he collaborates with and the new caregiver account to be created in the interventions platform Cloud-server. The expert physician is then returned to home screen of the interventions platform. The expert physician must communicate the caregiver account credentials to the caregiver securely. The expert physician can modify the profile of a caregiver and to assign her/him new interventions users. S/he does so by selecting the particular caregiver from the list of the caregivers s/he collaborates with, available on the home screen of the interventions application. S/he is then presented with the profile page of the caregiver where s/he can modify the existing entries or add/remove assigned interventions patients. To remove an assigned interventions user, the expert physician selects the respective UI element adjacent to the interventions user entry. To add a new interventions user the expert physician selects the dedicated UI element and s/he presented with a list of the interventions users that s/he monitors. By selecting one of these interventions users, the expert physician assigns her/him to the particular caregiver. The expert physician can then cancel or save the modifications made to the caregiver's profile. When in the profile of a caregiver, the expert physician also has the option to delete the profile of the particular caregiver via a dedicated UI element. By selecting, the expert physician is presented with a confirmation message. By accepting it, the caregiver profile and the respective entry in the interventions platform are deleted. By cancelling, s/he is returned to the caregiver's profile page. i-PROGNOSIS-690494_D2.1.docx p. 129/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
A new caregiver account is created upon request from the caregiver or the interventions user to the expert physician. For a caregiver to be assigned to an interventions user, the expert physician must receive the consent of the interventions user by also validating the ID of the caregiver. The latter can happen by remote communication or by the physical presence of both the caregiver and the interventions user at the office of the expert physician.
7 FIRST VERSION OF IDENTIFIED USER REQUIREMENTS
This section is about the presentation of the first version of user requirements identified via consortium expert meetings (CEM) (Section 4.3), via focus groups observations (FGO#) (Section 5.1), and Web surveys-based observations (WO#) (Section 5.2). User requirements are at first categorised into two general categories, i.e., functional and non-functional requirements. Each of these requirements is then characterised based on the parameters presented in TABLE 1 and relate to the importance, the development priority and risk (if applicable), as well as, the clinical value. All requirements are linked to business processes (BPs) described in Section 6.
TABLE 1 Parameters based on which the identified user requirements are characterised and their respective levels.
Parameter Description Levels Importance How important is for the system to satisfy the Required particular requirement Preferred Optional Development risk How great is the risk for the requirement not High to be satisfied due to the maturity of the Medium technology or restrictions of the available technology Low Development priority How the development needed to satisfy the High requirement is prioritised Medium Low Clinical value If there will be results clinically valuable in case Yes the requirement is satisfied No
7.1 FUNCTIONAL REQUIREMENTS
This section presents a list of the functional user requirements identified. User requirements categorised as functional are those that specify a behaviour or function of the system.
FR-1 Related BPs: BP-1, BP-2, BP-3, BP-36 i-PROGNOSIS-690494_D2.1.docx p. 130/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM Title: First, second stage or interventions users owning smartphones with older OS versions should be able to use the detection application or interventions application Description: By being compatible with older smartphones the detection application or interventions application can target a broader population, hence reach more potential first, second stage or interventions users, since non-compatible applications don not appear in the searches performed in the respective application market.
Importance Preferred Development risk Medium Development priority High Clinical value No
FR-2 Related BPs: BP-6 Identified via: CEM Title: The first stage or second stage or interventions user must be able to view and download the detailed consent form Description: During the first launch of the detection application, the first stage or second stage or interventions user must be able to view and download her/his complete consent form by selecting a provided hyperlink. Furthermore, the processes of reviewing the consent form can be repeated on the first stage or second stage or interventions user's demand by visiting the auxiliary menu in the detection / interventions application home screen. Importance Required Development risk Low Development priority High Clinical value No
FR-3 Related BPs: BP-3 Identified via: CEM, FGO7 Title: When the first stage user launches the detection application for the first time, a first launch tutorial about the usage of the application must be displayed Description: i-PROGNOSIS-690494_D2.1.docx p. 131/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
During the first launch of the detection application the first stage user must be able to watch an interactive first launch tutorial guiding her/him through the various options and screens of the application.
Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-4 Related BPs: BP-4, BP-9, BP-10, BP-11, BP-12, BP-13, BP-14, BP- 15, BP-17, BP-18, BP-19, BP-27, BP-29, BP-30, BP-31 Identified via: CEM Title: The first stage or second stage or interventions user must be able to observe the status of the background services Description: The first stage or second stage or interventions user must be able to easily observe if each one of the background services are currently operating. For this reason, the detection / interventions application must provide an indication about the status of each service.
Importance Required Development risk Low Development priority High Clinical value No
FR-5 Related BPs: BP-2, BP-36 Identified via: CEM Title: The first stage or second stage or interventions user must be able to obtain all the required software by installing the detection / interventions application Description: During the installation of the detection / interventions application all background services must be installed as well, without requiring any further interaction by the user.
Importance Required Development risk Low Development priority High Clinical value No
FR-6 Related BPs: BP-3 i-PROGNOSIS-690494_D2.1.docx p. 132/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM, FGO7 Title: The detection application must provide a series of screens providing information about each captured data source, along with the ability to modify the status individually Description: After the first stage user answers the questionnaire during the first launch, the detection application must provide information about each type of collected data in individual screens. Furthermore, the additional option of activating /deactivating each individual data source collection, in a way that is clear and easy to use, must be provided.
Importance Required Development risk Low Development priority High Clinical value No
FR-7 Related BPs: BP-7 Identified via: CEM Title: Background services and local data must be completely removed if the first stage or second stage or interventions user decides to uninstall the detection / interventions application Description: The uninstall process must remove the main detection / interventions application, any locally stored data and the background services, thus leaving the mobile device in a state similar prior to installing the detection / interventions application. Importance Required Development risk Low Development priority Medium Clinical value No
FR-8 Related BPs: BP-8 Identified via: CEM Title: The first stage or second stage or interventions user shall be able to provide feedback Description: The first stage or second stage or interventions user shall be able to provide feedback by using the detection / interventions application in a way that is user friendly and comprehensive. i-PROGNOSIS-690494_D2.1.docx p. 133/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Importance Preferred Development risk Low Development priority Low Clinical value No
FR-9 Related BPs: BP-8 Identified via: CEM Title: The first stage or second stage or interventions user shall be able to request help Description: The first stage or second stage or interventions user shall be able to request technical support regarding the usage of the detection / interventions application and the background services in a way that is user friendly and comprehensive via the detection / interventions application. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-10 Related BPs: BP-9 Identified via: CEM Title: The voice service must be able to collect and process first stage or second stage or interventions user's voice data unobtrusively Description: The recorded voice data must be collected and processed by the voice service in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority High Clinical value Yes
FR-11 Related BPs: BP-10 Identified via: CEM Title: The typing service must be able to collect and process first stage or second stage or interventions user's keystrokes unobtrusively Description: The keystrokes must be collected and processed by the typing service in an i-PROGNOSIS-690494_D2.1.docx p. 134/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority High Clinical value Yes
FR-12 Related BPs: BP-11 Identified via: CEM Title: The location service must be able to collect and process first stage or second stage or interventions user's location data unobtrusively Description: The location data must be collected, de-identified and processed by the location service in an unobtrusive way and without requiring any interaction. Importance Required Development risk Medium Development priority High Clinical value Yes
FR-13 Related BPs: BP-12 Identified via: CEM Title: The image processing service must be able to collect and process first stage or second stage or interventions user's image data unobtrusively Description: The image data must be collected and processed by the image processing service in an unobtrusive way and without requiring any interaction. Importance Required Development risk Medium Development priority High Clinical value Yes
FR-14 Related BPs: BP-13 Identified via: CEM Title: The text processing service must be able to collect and process first stage or second stage or interventions user's text data unobtrusively Description: The text data must be collected and processed by the text processing service i-PROGNOSIS-690494_D2.1.docx p. 135/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority High Clinical value Yes
FR-15 Related BPs: BP-17 Identified via: CEM Title: The movement service must be able to collect and process first stage or second stage or interventions user's movement data unobtrusively Description: The movement data must be collected and processed by the movement service in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority Low Clinical value Yes
FR-16 Related BPs: BP-14 Identified via: CEM Title: The handling service must be able to collect and process first stage or second stage or interventions user's handling data unobtrusively Description: The IMU (accelerometer and gyroscope) data must be collected and processed by the handling service in an unobtrusive way and without requiring any interaction. Importance Required Development risk Medium Development priority Low Clinical value Yes
FR-17 Related BPs: BP-18 Identified via: CEM Title: The sleep stage service must be able to collect and process first stage or second stage or interventions user's sleep data unobtrusively Description: The sleep stage data must be collected and processed by the sleep stage service i-PROGNOSIS-690494_D2.1.docx p. 136/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority Low Clinical value Yes
FR-18 Related BPs: BP-19 Identified via: CEM Title: The physical activity service must be able to collect and process first stage or second stage or interventions user's physical activity data unobtrusively Description: The physical activity data must be collected and processed by the physical activity service in an unobtrusive way and without requiring any interaction. Importance Required Development risk Medium Development priority Low Clinical value Yes
FR-19 Related BPs: BP-15, BP-16 Identified via: CEM Title: The syncing service must operate unobtrusively Description: The data received from the background services of the detection / interventions application must be stored and communicated with the Cloud server by the syncing service in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority High Clinical value No
FR-20 Related BPs: BP-20, BP-32 Identified via: CEM Title: The decision sub-system must be able to operate unobtrusively Description: The decision sub-system based on the detection behavioural model must i-PROGNOSIS-690494_D2.1.docx p. 137/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
infer about the potential changes in the first and second stage user’s behaviour in an unobtrusive way and without requiring any interaction.
Importance Required Development risk Medium Development priority High Clinical value No
FR-21 Related BPs: BP-21, BP-22, BP-33, BP-34 Identified via: CEM Title: The first and second stage user must be notified in a secure and clear way about the detected behavioural changes Description: The first and second stage user must be notified about the detected behavioural changes, in a secure way, via the detection application. Furthermore, the notification must be recognisable in the home screen of the detection application. The first and second stage user must also be able to dismiss (i.e. minimise) and restore (maximise) the notification at any point.
Importance Required Development risk Medium Development priority High Clinical value No
FR-22 Related BPs: BP-21 Identified via: CEM Title: In case of accepting to contact the expert physician, the first stage user must be provided with detailed contact information Description: If the first stage user agrees to contact an expert physician, s/he must be provided with a list of names, addresses, phone numbers and email address of the contracted expert physicians near her/him, through the detection application. Importance Required Development risk Medium Development priority High Clinical value No
FR-23 Related BPs: BP-21, BP-22, BP-33, BP-34
i-PROGNOSIS-690494_D2.1.docx p. 138/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM Title: The received notification by the first and second stage user, regarding the detected behavioural changes, must include additional details in a comprehensive language Description: The notification must include an epitomised break down of the indicators leading to the result in a language that is comprehensive and informative. This information should also be propagated to the expert physician via the first and second stage user in order to assist her/him during her/his diagnosis. Importance Required Development risk Medium Development priority High Clinical value Yes
FR-24 Related BPs: BP-23 Identified via: CEM Title: The expert physician must have the ability to create an upgrade key Description: The expert physician must have the ability to create an upgrade key for the second stage user / adult to upgrade the detection application. The option must be provided through the interventions platform, when the expert physician logs in. Importance Preferred Development risk Low Development priority Low Clinical value No
FR-25 Related BPs: BP-23 Identified via: CEM Title: The key required to unlock the additional features of the detection application must be generated and provided to the adult and first stage user by the expert physician Description: If the adult and first stage user agrees to continue with the second stage of PD detection, the key required to unlock the additional features must be software generated by the expert physician and provided physically during her/his visit. Importance Required Development risk Medium i-PROGNOSIS-690494_D2.1.docx p. 139/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Development priority High Clinical value No
FR-26 Related BPs: BP-23 Identified via: CEM Title: The detection application must unlock the additional features when the first stage user or adult inputs the provided upgrade key, without requiring additional actions Description: The additional features required for participation during the second stage of PD detection must be unlocked when the first stage user / adult inputs the key in the related field in the detection application. Importance Required Development risk Medium Development priority High Clinical value No
FR-27 Related BPs: BP-24 Identified via: CEM Title: The necessary hardware for the second stage of detection or the interventions phase must be provided to the second stage user or interventions user by the expert physician Description: The expert physician must provide the hardware required for the second stage of detection or the interventions phase to the second stage user or interventions user. Additionally, detailed information about the necessity, operation and connectivity of the hardware will be provided to the second stage user or interventions user by the expert physician. Importance Preferred Development risk - Development priority - Clinical value No
FR-28 Related BPs: BP-25 Identified via: CEM Title: After upgrading the detection application, the second stage user must be presented with a first i-PROGNOSIS-690494_D2.1.docx p. 140/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
launch tutorial about the operation of the new set of features Description: During the first launch of the upgraded detection application, the second stage user must be presented with a short first launch tutorial about the purpose and operation of the new features and the corresponding background services.
Importance Required Development risk Low Development priority Medium Clinical value No
FR-29 Related BPs: BP-28 Identified via: CEM Title: The second stage and interventions user should be able to easily pair (i.e. connect) the smartphone with the Mandometer, smart belt, smart TV remote, and sleep earphones Description: The pairing process of the smartphone with the Mandometer, smart belt, smart TV remote, and sleep earphones should be simple and straightforward. The pairing (except for the first time) should take place automatically when the devices are nearby and their Bluetooth connectivity is turned on.
Importance Preferred Development risk Medium Development priority High Clinical value No
FR-30 Related BPs: BP-29 Identified via: CEM Title: The food intake service must collect the second stage and interventions user's data via the Mandometer Description: The food intake information must be captured simply by the second stage and interventions user placing their meal on the already paired Mandometer. Importance Required Development risk High Development priority High Clinical value Yes
i-PROGNOSIS-690494_D2.1.docx p. 141/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-31 Related BPs: BP-30 Identified via: CEM Title: The bowel sound service must collect the second stage and interventions user's data via the smart belt Description: The bowel movement information must be captured simply by the second stage and interventions user wearing the already paired smart belt. Importance Required Development risk High Development priority High Clinical value Yes
FR-32 Related BPs: BP-31 Identified via: CEM Title: The ECG processing service must collect the second stage and interventions user's data via the smart TV remote Description: The ECG signals must be captured simply by the second stage and interventions user interacting with the already paired smart TV remote. Importance Required Development risk High Development priority High Clinical value Yes
FR-33 Related BPs: BP-4, BP-9, BP-10, BP-11, BP-12, BP-13, BP-14, BP- 15, BP-17, BP-18, BP-19, BP-27, BP-29, BP-30, BP-31 Identified via: CEM, WO11 Title: The first stage user or second stage user must have the option to activate/deactivate background services of the detection application Description: The first and second stage user must be able to easily change the status of background services (food intake service, movement service, physical activity service, sleep stage service, bowel sound service, ECG processing service, voice service, typing pattern service, text processing service, image processing service, handling service, location service) by i-PROGNOSIS-690494_D2.1.docx p. 142/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interacting with the respective UI element next to each service name in the home menu. Importance Required Development risk Low Development priority High Clinical value No
FR-34 Related BPs: BP-31 Identified via: CEM, WO30 Title: The smart TV remote must identify if it is the second stage user s/he who uses it Description: As a remote TV control is usually used by more than one persons at home, the smart TV remote must identify if it is the second stage user s/he who uses it. In case another person is using the smart TV remote when it is connected to the smartphone and transmitting data, the ECG data collected must be disregarded by the ECG processing service. Importance Required Development risk Medium Development priority High Clinical value Yes
FR-35 Related BPs: BP-5 Identified via: CEM, FGO5 Title: The first stage or second stage or interventions user must be able to withdraw her/his consent form at any time and stop any further data collection with the option of deleting any captured data related to her/him Description: At any point, the first stage or second stage or interventions user must be able to withdraw her/his consent form and halt any further data collection. Furthermore, after selecting the withdrawal of the consent, the detection / interventions application requests the first stage or second stage or interventions user to ask whether or not s/he wants to delete all captured data from the Cloud server. Importance Required Development risk Low Development priority High Clinical value No
i-PROGNOSIS-690494_D2.1.docx p. 143/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-36 Related BPs: BP-3, BP-26, BP-39 Identified via: CEM, FGO1, FGO3, FGO4 Title: The consent form presented via the detection / interventions application and the interventions platform must be easy to read and informative Description: The consent form presented via the detection / interventions application and the interventions platform must be carefully structured and clearly state what data will be captured, the reason why and how they will be processed (privacy, anonymisation, data security) and exploited. The first stage or second stage or interventions user must be able to read the consent form comfortably on the screen of the mobile device.
Importance Required Development risk Low Development priority High Clinical value No
FR-37 Related BPs: BP-35, BP-66, BP-67 Identified via: CEM Title: The interventions platform must allow the expert physician to create a new user account or caregiver account Description: The expert physician must be able to create a new user or caregiver account (including the username and the password) and a corresponding profile (containing the respective information for each type of user) for an interventions user or caregiver, via the interventions platform. Importance Required Development risk Low Development priority High Clinical value No
FR-38 Related BPs: BP-65, BP-67 Identified via: CEM Title: The interventions platform must allow the expert physician to modify a user account or caregiver account Description:
i-PROGNOSIS-690494_D2.1.docx p. 144/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The expert physician must be able to modify an existing user or caregiver account profile (not the username and the password) of an interventions user or caregiver, respectively, or delete a user account or caregiver account via the interventions platform. Importance Required Development risk Low Development priority Medium Clinical value No
FR-39 Related BPs: BP-67 Identified via: CEM Title: The interventions platform must allow the expert physician to assign interventions users to a caregiver Description: When creating a new caregiver account or modifying an existing one, the expert physician must be able to assign interventions users to the caregiver. The expert physician must be able to assign only interventions users that s/he monitors.
Importance Required Development risk Low Development priority Medium Clinical value No
FR-40 Related BPs: BP-39 Identified via: CEM Title: The interventions application must have a log-in screen for the interventions user to log in with her/his user account credentials Description: When the interventions user launches the interventions application and if not logged-in already, s/he must be presented with a log-in screen to enter her/his user account credentials. Importance Required Development risk Low Development priority High Clinical value No
FR-41 Related BPs: BP-3, BP-26, BP-39 Identified via: CEM i-PROGNOSIS-690494_D2.1.docx p. 145/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Title: The detection / interventions application must present the first stage or second stage or interventions user with next steps in case s/he does not agree with the consent form Description: If the first stage or second stage or interventions user declines to consent, the detection / interventions application should provide him with a warning message and the options to launch the consent process again or log out.
Importance Required Development risk Low Development priority High Clinical value No
FR-42 Related BPs: BP-3, BP-26, BP-39 Identified via: CEM Title: The detection / interventions application must present the first stage or second stage or interventions user with a first launch tutorial on its first launch Description: When the first stage or second stage or interventions user launches the detection / interventions application for the first time and after s/he has agreed with the consent form, s/he must be presented with a tutorial on the UI elements of the detection / interventions application and their purpose. Importance Required Development risk Low Development priority High Clinical value No
FR-43 Related BPs: BP-40 Identified via: CEM Title: The interventions platform must present the interventions user with next steps in case s/he does not agree with the consent form Description: If the interventions user declines to consent, the interventions platform should provide him with a warning message and the options to launch the consent process again or log out.
Importance Preferred Development risk Low Development priority Medium Clinical value No i-PROGNOSIS-690494_D2.1.docx p. 146/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-44 Related BPs: BP-39, BP-40, BP-41, BP-64 Identified via: CEM Title: The interventions platform or the interventions application must present feedback in case of unsuccessful log-in Description: If the interventions user or expert physician or caregiver enters wrong account credentials, the interventions platform or interventions application must present then with the credential that was wrong by highlighting the respective field (username or password) and display an appropriate message.
Importance Required Development risk Low Development priority High Clinical value No
FR-45 Related BPs: BP-39,BP-40, BP-41, BP-64 Identified via: CEM Title: The interventions platform or the interventions application must have a retrieve password option, on the log-in screen, and a corresponding process of retrieval Description: If the interventions user or expert physician or caregiver cannot remember her/his password, the interventions platform or interventions application must offer the option on the log-in screen to trigger the process of password retrieval.
Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-46 Related BPs: BP-41 Identified via: CEM Title: The interventions application must allow the interventions user to stay logged-in until s/he logs out on demand or uninstalls the interventions application i-PROGNOSIS-690494_D2.1.docx p. 147/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Description: Upon logging into the interventions application, the interventions user must stay logged indefinitely, except if s/he logs out on demand via the log-out option or s/he uninstalls the interventions application from her/his mobile device. The latter process will not affect the log-in status of the interventions user on other mobile devices or the Web-based interventions platform. Importance Required Development risk Low Development priority High Clinical value No
FR-47 Related BPs: BP-41 Identified via: CEM Title: The interventions platform must allow the interventions user to stay logged in for a period even when a session is terminated, except for when the interventions user logs out on demand Description: Upon logging into the interventions platform, the interventions user could stay logged-in even after a session has been terminated, i.e., the interventions user closed the browser oh her/his PC or mobile device. The period for which the interventions user stays logged-in is specified by an authentication cookie. The latter process is bypassed if the interventions user logs out on demand from the interventions platform. The latter process will not affect the log-in status of the interventions user on other mobile devices or the Web-based interventions platform on another PC. Importance Optional Development risk Low Development priority Low Clinical value No
FR-48 Related BPs: BP-3, BP-26, BP-39 Identified via: CEM Title: The detection / interventions application must present the first stage or second stage or interventions user with the consent form on its first launch and not be functional until s/he agrees with it Description: When the first stage or second stage or interventions user launches the detection / interventions application for the first time s/he must be presented with the consent form. Until the first stage or second stage or i-PROGNOSIS-690494_D2.1.docx p. 148/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user agrees with it, the detection / interventions application should not be functional and all background services should be deactivated. If the first stage or second stage or interventions user accepts the consent form the detection / interventions application must be fully functional and all background services activated.
Importance Required Development risk Low Development priority High Clinical value No
FR-49 Related BPs: BP-40, BP-41 Identified via: CEM Title: The interventions platform must have a log-in form for the interventions user to log in with her/his user account credentials Description: When the interventions user visits the intervention platform and if not logged-in already, s/he must be presented with a log-in form to enter her/his user account credentials. Importance Required Development risk Low Development priority High Clinical value No
FR-50 Related BPs: BP-40, BP-41, BP-64 Identified via: CEM Title: The log-in algorithm of the interventions platform must check the validity of the credentials and the account type Description: When the interventions user or expert physician or caregiver attempts to log into the interventions platform, the log-in algorithm must check the validity of the provided credentials against the entries of the intervention platform and if they are correct, the type of the account (user account, caregiver account, expert account) so as for the appropriate interventions platform UI to be presented to her/him.
Importance Required Development risk Low Development priority Medium Clinical value No
i-PROGNOSIS-690494_D2.1.docx p. 149/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-51 Related BPs: BP-40 Identified via: CEM Title: The interventions platform must present the interventions user with the consent form on her/his log-in and not be functional until s/he agrees with it Description: When the interventions user logs into the interventions platform for the first time s/he must be presented with the consent form. Until the interventions user agrees with it, the interventions platform should not be functional. If the interventions user accepts the consent form the interventions platform must be fully functional.
Importance Required Development risk Low Development priority High Clinical value No
FR-52 Related BPs: BP-42 Identified via: CEM Title: Contact information of the caregiver and the expert physician should be available to the interventions user inside the interventions application Description: The interventions user must be able to easily access the contact information (name, address, telephone number, e-mail address) of her/his expert physician or caregiver through the home screen of the interventions application. Importance Optional Development risk Low Development priority Low Clinical value No
FR-53 Related BPs: BP-42, BP-47 Identified via: CEM, WO13, WO27, FGO13 Title: The interventions application must provide feedback to the interventions user regarding monitoring data Description: The interventions application must include feedback elements on key monitoring data on a dedicated section. Feedback elements must be refreshed i-PROGNOSIS-690494_D2.1.docx p. 150/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
based on new monitoring data on a scheduled basis (preferably weekly). Thus, the data-to-feedback service should perform its operations on a scheduled basis, i.e., calculate statistics based on the stored monitoring data stored on the Cloud server and push them to the interventions application feedback elements. Importance Preferred Development risk Medium Development priority Medium Clinical value No
FR-54 Related BPs: BP-43 Identified via: CEM Title: The interventions application must include an option for the interventions user to log out on demand Description: The interventions application must include an option for the interventions user to log-out from the interventions application. By selecting this options, all background services and data upload must halt. The latter process will not affect the interventions user's log-in status on other mobile devices or the Web-based interventions platform. After logging out, the interventions user must be presented with the log-in screen of the interventions application. Importance Required Development risk Low Development priority High Clinical value No
FR-55 Related BPs: BP-44 Identified via: CEM Title: The interventions platform must include an option for the interventions user or expert physician or caregiver to log out on demand Description: The interventions platform must include an option for the interventions user or expert physician or caregiver to log-out from the interventions platform. The latter process will not affect the interventions user's or expert physician's or caregiver's log-in status on other mobile devices or the Web- based interventions platform. After logging out, the interventions user or expert physician or caregiver must be presented with the log-in screen of the interventions platform. Importance Required Development risk Low Development priority High Clinical value No i-PROGNOSIS-690494_D2.1.docx p. 151/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-56 Related BPs: BP-42,BP-45 Identified via: CEM Title: The interventions platform must be accessible through the interventions application Description: The interventions platform UI should be accessible via a dedicated option in the interventions application. When selecting this option, a Web view inside the interventions application must open, i.e., the interventions user will not have to exit the application. Additionally, the interventions user will not be required to log into the interventions platform. A dedicated UI element must allow the interventions user to close the Web view and return to the interventions application. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-57 Related BPs: BP-40, BP-41, BP-44, BP-64 Identified via: CEM Title: The interventions platform must be accessible on the Web Description: The interventions platform must be accessible through a dedicated URL from a browser, provided that the interventions user mobile device (smartphone or tablet) or PC is connected to the internet. Importance Required Development risk Low Development priority High Clinical value No
FR-58 Related BPs: BP-48, BP-49, BP-50 Identified via: CEM Title: Assistive interventions must provide warning messages about the peripheral devices required for them to function properly Description: When the interventions user activates an assistive intervention, s/he must i-PROGNOSIS-690494_D2.1.docx p. 152/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
be provided with a warning message about the peripheral devices required for the intervention to function properly. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-59 Related BPs: BP-42, BP-48, BP-49, BP-50 Identified via: CEM Title: The interventions application must allow access to the assistive interventions Description: The interventions application must allow the interventions user to access via dedicated UI elements and use the assistive interventions. Importance Required Development risk Low Development priority High Clinical value No
FR-60 Related BPs: BP-48, BP-49, BP-50 Identified via: CEM, WO44 Title: The UI of each assistive intervention must allow activation/deactivation and parameterisation Description: The dedicated UI of each assistive intervention must include all the parameters that the interventions user can change in order to affect the functionality of the intervention, as well as the option to activate/deactivate it - including the respective background service.
Importance Required Development risk Low Development priority High Clinical value No
FR-61 Related BPs: BP-48, BP-49, BP-50 Identified via: CEM Title: Background services of each assistive intervention must be deactivated when the assistive intervention is deactivated Description: i-PROGNOSIS-690494_D2.1.docx p. 153/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
When an interventions user deactivates an assistive intervention, the respective services are also terminated, i.e., no data recording, processing or uploading takes place.
Importance Required Development risk Low Development priority High Clinical value No
FR-62 Related BPs: BP-17, BP-18, BP-19, BP-28, BP-29, BP-30, BP-31, BP-48, BP-50 Identified via: CEM Title: The detection / interventions application background services must be capable of identifying the pairing with a device of interest Description: The detection / interventions application background services must be aware of when a successful pairing with a device (smartwatch, Mandometer, smart belt, smart TV remote, sleep earphones) of interest takes place. The background services should activate a dedicated UI element or provide a message within the respective UI (list of detection background services, monitoring services tab or UI of each assistive intervention) that the device is paired with the mobile device (smartphone or tablet), for the second stage or interventions user to be aware of.
Importance Required Development risk Medium Development priority High Clinical value No
FR-63 Related BPs: BP-49 Identified via: CEM Title: The VEI service must detect voice deterioration in real time Description: The VEI service must process the voice of the interventions user when talking during a phone call so as to assess the interventions user's voice quality in real time.
Importance Required Development risk Medium Development priority High Clinical value Yes
i-PROGNOSIS-690494_D2.1.docx p. 154/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-64 Related BPs: BP-49 Identified via: WO49 Title: The VEI service must provide the interventions user with a discreet signal the first time it detects voice deterioration Description: The VEI service must provide the interventions user with a discreet signal the first time it detects voice deterioration so as for the interventions user to try to balance her/his voice. If the VEI service continues to detect voice deterioration after a predefined time interval, it must trigger the voice enhancement process automatically.
Importance Preferred Development risk Medium Development priority Medium Clinical value No
FR-65 Related BPs: BP-49 Identified via: CEM Title: The VEI service must enhance the interventions user's voice with minimum possible lag Description: The VEI service, when it detects voice deterioration, it must process and enhance the voice segments of the interventions user and pass them to the operating system calling service so as to be transferred to the interventions user's listener with minimum possible lag. The process must not affect significantly the synchronicity of the communication between the interventions user and the listener.
Importance Required Development risk High Development priority High Clinical value Yes
FR-66 Related BPs: BP-49 Identified via: CEM Title: The VEI service must be triggered automatically when the interventions user accepts a phone call and be disabled when s/he terminates it. Description: i-PROGNOSIS-690494_D2.1.docx p. 155/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
When the VEI is active, the VEI service must silently wait in the background for the interventions user to accept a phone call. When a phone call is accepted by the interventions user, the VEI service must trigger the voice processing and enhancement (if needed) processes. When the interventions user terminates the phone call, the VEI service must halt all processes and return to its idle status. Importance Required Development risk Medium Development priority High Clinical value No
FR-67 Related BPs: BP-50 Identified via: CEM Title: The GRGI service must recognise the interventions user's gait in real time Description: The GRGI service must process streamed data from the smartwatch or smartphone IMU data in real time in order to recognise the gait rhythm of the interventions user, when s/he is walking. Importance Required Development risk Medium Development priority High Clinical value Yes
FR-68 Related BPs: BP-50 Identified via: CEM, WO47, FGO15 Title: The GRGI service must start/end the playback of the acoustic rhythmic cue automatically Description: The GRGI service based on the assessment of the interventions user's gait, when s/he walks, must trigger automatically the acoustic rhythmic cue when it detects a freezing episode. The GRGI service must also end the playback of the cue when it assess that the interventions user's gait is reinstated. Importance Preferred Development risk Low Development priority High Clinical value No
FR-69 Related BPs: BP-50 Identified via: CEM
i-PROGNOSIS-690494_D2.1.docx p. 156/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Title: The GRGI service must remain active until the interventions user deactivates it Description: When the GRGI is active, the GRGI service must be active and processing data until the interventions user decides to deactivate the GRGI through the interventions application. Importance Optional Development risk Low Development priority Medium Clinical value No
FR-70 Related BPs: BP-48 Identified via: CEM Title: The TNI service must recognise the sleep stage of the interventions user effectively Description: When the TNI is active, the TNI service must process data streamed from the smartwatch (heart rate, accelerometer and skin temperature data) and infer the sleep stage of the interventions user on frequent time intervals. Importance Required Development risk High Development priority High Clinical value Yes
FR-71 Related BPs: BP-48 Identified via: CEM Title: The TNI service must recognise when the interventions user slept or woke up or is awake Description: When the TNI is active, the TNI service based on the data streamed from the smartwatch and the time of day must recognise when the interventions user begins sleeping or has waken up or is awake. Depending on the case, the TNI service must trigger or halt the sleep stage recognition process and the sounds playback.
Importance Preferred Development risk Medium Development priority Medium Clinical value No
FR-72
i-PROGNOSIS-690494_D2.1.docx p. 157/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Related BPs: BP-48 Identified via: WO45 Title: The interventions user must be able to select the type of sounds and adjust the volume of sounds of the TNI Description: Before activating the TNI, the interventions user must be able to predefine the volume of the pacifying sounds, as well as the type of pacifying sounds, that will be play backed if a sleep disturbance episode is detected, through the respective UI element of the TNI UI. Importance Required Development risk High Development priority High Clinical value No
FR-73 Related BPs: BP-48, BP-49, BP-50 Identified via: CEM Title: Assistive interventions must record data about their usage to be uploaded on the Cloud server Description: The background service of each assistive intervention must record data on its usage, i.e., the number of intervention activations by the interventions user and the number of events detected (sleep disturbances per night, freezing episodes per walk, and voice deterioration intervals per phone call). The latter data will be delivered to the syncing service of the interventions application in order to be uploaded on the Cloud server. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-74 Related BPs: BP-46 Identified via: CEM, WO11 Title: The interventions application should allow for activation/deactivation of background services capturing monitoring data Description: The interventions user must be able to activate/deactivate each background service capturing a type of monitoring data (food intake service, movement service, physical activity service, sleep stage service, bowel sound i-PROGNOSIS-690494_D2.1.docx p. 158/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
service, ECG processing service, voice service, typing pattern service, text processing service, image processing service, handling service, location service) on demand via the respective UI element of the monitoring interventions application services tab. Importance Required Development risk Low Development priority High Clinical value No
FR-75 Related BPs: BP-40, BP-51 Identified via: CEM, FGO17 Title: The game types of the PGS must be presented as different sections with representative icons Description: When logging into the interventions platform, the interventions user must be presented with scheduled game scenarios that are illustrated by representative icons, i.e., the icon must denote the activity targeted by each game scenario. Importance Required Development risk Low Development priority High Clinical value No
FR-76 Related BPs: BP-51 Identified via: CEM Title: Games of the PGS should provide warning messages about the devices on which they should be played and the peripherals required Description: When the interventions user selects to play a game scenario, s/he must be provided with a message informing her/him about the appropriate device where the game scenario should be played (e.g., touch-enabled mobile device, monitor) and the peripheral devices needed (e.g., Kinect for the Exergames or stylus for the Handwriting games) Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-77 Related BPs: BP-56
i-PROGNOSIS-690494_D2.1.docx p. 159/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM Title: The game instruction panel must provide clear and easy-to-understand multimodal instructions on how the game scenario should be performed Description: Before each game scenario starts, the interventions user must be presented with a game instruction panel explaining what the interventions user should do during the game scenario. The instructions could include video-based, text-based or oral-based description of the tasks to be performed in natural language and clear visuals in order to be easily understood by the interventions user. Importance Required Development risk Low Development priority High Clinical value No
FR-78 Related BPs: BP-56 Identified via: CEM Title: The interventions user must have time to prepare before playing a game scenario Description: When the interventions user selects to start playing a game scenario (after the presentation of the game instructions panel), s/he must be given time in the form of a count-down in order to get ready to play the game scenario. Importance Required Development risk Low Development priority High Clinical value No
FR-79 Related BPs: BP-51, BP-54 Identified via: CEM Title: Exergames of the PGS involving the Kinect must provide feedback to the interventions user that the device functions properly Description: When the interventions user selects the play an Exergame game scenario, s/he must be aware via a dedicated UI element of the interventions platform, that the Kinect device is connected and functional. Importance Required Development risk Low Development priority High Clinical value No i-PROGNOSIS-690494_D2.1.docx p. 160/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
FR-80 Related BPs: BP-51 Identified via: WO31 Title: Games of the PGS should be accompanied by music and the option for the interventions user to mute it Description: The interventions user should listen to appropriate music during the games of the PGS, especially the Exergames. The interventions user should be able to mute the music before or during a game scenario via a dedicated UI element. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-81 Related BPs: BP-52, BP-65 Identified via: CEM Title: The interventions platform must allow the expert physician to modify or schedule game scenarios Description: When the expert physician is inside the profile of an interventions user, s/he must be able to see and modify the scheduled PGS game scenarios via a dedicated UI element adjacent to each scheduled game scenario. Additionally, the expert physician must be able to schedule a new game scenario via a schedule option that will present him with the dedicated UI to parameterise the new game scenario (type of game scenario, date, add game friends). The expert physician must be presented with the options to cancel or save the modifications and a warning message when s/he closes the UI without selecting one of these two options. If the expert physician saves the modifications, the respective parameters must be updated or new entries must be created by the scheduler service and pushed to the interventions user through the interventions application as notifications. Importance Required Development risk Low Development priority High Clinical value No
FR-82 Related BPs: BP-53, BP-65 Identified via: CEM Title: The interventions platform should allow the expert i-PROGNOSIS-690494_D2.1.docx p. 161/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
physician to add/remove game friends for an interventions user Description: When scheduling a new game scenario or when modifying an existing one, the expert physician must be able to add/remove game friends of whom the performance metrics will be presented along with the interventions user's performance metrics when the particular game scenario ends. Game friends should be interventions users that the expert physician monitors and s/he is aware of their condition.
Importance Optional Development risk Low Development priority Low Clinical value No
FR-83 Related BPs: BP-64, BP-65, BP-66 Identified via: CEM Title: The interventions platform must allow access only to the interventions users that the expert physician or caregiver monitors Description: When logged into the interventions platform, the expert physician or caregiver must have access only to the profiles of the interventions users that s/he monitors, i.e., only data of the corresponding interventions platform entries must be loaded and presented to them.
Importance Required Development risk Low Development priority High Clinical value No
FR-84 Related BPs: BP-65, BP-66 Identified via: CEM, FGO17 Title: Feedback elements of the interventions platform should provide useful feedback to the expert physician or the caregiver Description: The design of and the statistics presented via the feedback elements must provide the expert physician or caregiver with easy-to-understand and useful information. The information must allow the expert physician or caregiver to form an opinion about the interventions user's PGS performance and engagement, lifestyle behaviour (monitoring data) and use of assistive interventions. i-PROGNOSIS-690494_D2.1.docx p. 162/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Importance Preferred Development risk Medium Development priority Medium Clinical value Yes
FR-85 Related BPs: BP-58, BP-62 Identified via: CEM, WO36 Title: The interventions user must receive motivational messages during the performance of a game scenario Description: When the interventions user plays a game scenario, s/he must be presented with motivational (encouraging or reward) messages regarding her/his performance based on the performance metric. Messages must be provided in text or orally in a position on the screen that does not interfere with the main graphics of the game scenario. Importance Preferred Development risk Low Development priority Medium Clinical value No
FR-86 Related BPs: BP-58, BP-62 Identified via: CEM Title: The interventions user must be presented with her/his performance metrics when a game scenario ends Description: When a game scenario ends, the interventions user must be presented with an achievement derived after her/his performance metrics, as feedback. Afterwards, the interventions user must be able to proceed to the next scheduled game scenario. Importance Required Development risk Low Development priority High Clinical value No
FR-87 Related BPs: BP-53, BP-58, BP-59, BP-62 Identified via: CEM, WO34 Title: The interventions user may be presented with her/his performance metrics in comparison to the i-PROGNOSIS-690494_D2.1.docx p. 163/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
performance metrics of her/his game friends Description: If the expert physician has added game friends for a particular game scenario, the respective achievements of the game friends should be loaded and presented in comparison to the interventions user's achievement. The interventions user should be given the option to send her/his achievement as a notification ("poke") to her/his game friends. Importance Optional Development risk Low Development priority Medium Clinical value No
FR-88 Related BPs: BP-58 Identified via: CEM Title: The performance metrics of each game scenario must be stored on the Cloud server of the interventions platform Description: When an interventions user finishes a game scenario, her/his performance metrics must be stored on the Cloud server of the interventions platform. The information that the particular game scenario was completed must be also stored on the interventions platform. It must be possible to retrieve them based on the user account and the game scenario. Importance Required Development risk Low Development priority High Clinical value Yes
FR-89 Related BPs: BP-60 Identified via: CEM Title: The interventions user must be able to pause the progression of a game scenario Description: During a game scenario, the interventions user must be able to pause the scenario via a dedicated UI element or a gesture in the case of the Exergames that require the Kinect device. In the case of Exergames, as the physical exercise protocol must be completed in a specified time interval, the game scenario will restart automatically after a short period of time. If the interventions user does not continue, the game scenario will be considered as missed. The latter information will be stored on the interventions platform.
i-PROGNOSIS-690494_D2.1.docx p. 164/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Importance Required Development risk Low Development priority High Clinical value No
FR-90 Related BPs: BP-60 Identified via: CEM Title: The interventions user must be able to exit a game scenario Description: When the interventions user pauses a game scenario, s/he must be also presented with the option to exit the game scenario. If s/he does, the game scenario will be considered as missed. The latter information will be stored on the interventions platform. Importance Required Development risk Low Development priority High Clinical value No
FR-91 Related BPs: BP-57 Identified via: CEM Title: The PGS must have a personalisation service that will adapt parameters of game scenarios based on the interventions user's previous performance Description: Based on the interventions user's performance metrics regarding a particular game scenario, the personalisation service must adapt certain parameters of the game scenario (e.g. difficulty) for the next time the interventions user plays the particular game scenario. The personalisation service can perform its operations immediately after the game scenario is terminated.
Importance Required Development risk Medium Development priority High Clinical value Yes
FR-92 Related BPs: BP-42, BP-52,BP-59 Identified via: CEM Title: New or modified scheduled game scenarios and game friends' achievements must be pushed to the i-PROGNOSIS-690494_D2.1.docx p. 165/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
interventions user via the interventions application Description: When the expert physician modifies an existing game scenario or adds a new scheduled game scenario, the interventions user must be notified via the interventions application. The interventions user must be able to see the new notification in the notifications tab of the interventions application. The latter also apply in the case a game friend of the interventions user shared her/his achievement and "poked" her/him.
Importance Preferred Development risk Medium Development priority Medium Clinical value No
FR-93 Related BPs: BP-51, BP-54, BP-55 Identified via: CEM Title: The body/gesture recognition service must recognise the interventions user's movements effectively Description: Based on Kinect data, the body/gesture recognition service must recognise as accurately as possible and in an acceptable time frame, the interventions user's movement and gestures during the Exergames, so as not to create significant latency between what the interventions user performs and what it is displayed on the screen.
Importance Required Development risk Medium Development priority High Clinical value Yes
FR-94 Related BPs: BP-53, BP-58, BP-59, BP-62 Identified via: WO35 Title: The performance metrics presented to the interventions user should be in the form of achievement-rank Description: The performance metrics of the interventions user, as well as of her/his game friends, must be in the form or qualitative achievement-rank, not actual quantitative score.
Importance Preferred Development risk Low i-PROGNOSIS-690494_D2.1.docx p. 166/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Development priority Medium Clinical value No
FR-95 Related BPs: BP-62 Identified via: CEM Title: The virtual tutor must have anthropomorphic characteristics Description: The virtual tutor that will guide the interventions user through the PGS of the interventions platform must have anthropomorphic characteristics so as for the interventions user to familiarise with her/him more easily. Importance Optional Development risk Low Development priority Medium Clinical value No
FR-96 Related BPs: BP-62 Identified via: CEM Title: The virtual tutor must provide text-based messages in natural language Description: The virtual tutor must provide text-based feedback, instructions, motivational messages to the interventions user in natural language so as for the interventions user to familiarise with her/him more easily. Importance Required Development risk Low Development priority High Clinical value No
FR-97 Related BPs: BP-62 Identified via: CEM Title: The virtual tutor must provide messages orally in natural language Description: The virtual tutor must provide oral feedback, instructions, motivational messages to the interventions user in natural language so as for the interventions user to familiarise with her/him more easily.
Importance Optional Development risk High i-PROGNOSIS-690494_D2.1.docx p. 167/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Development priority Medium Clinical value No
FR-98 Related BPs: BP-61 Identified via: CEM, FGO9 Title: The interventions user must have access to technical support through the interventions platform Description: An option throughout the UI of the interventions platform must exist that the interventions user can select and be redirected to the page of the interventions platform where s/he can further access a frequently-asked- questions section, a video-based tutorials section and a contact form to request additional support.
Importance Required Development risk Low Development priority High Clinical value No
FR-99 Related BPs: BP-64, BP-65, BP-66 Identified via: CEM Title: The interventions platform must have dedicated UIs for the expert physician and the caregiver. Description: When logging into the interventions platform and based on the type of account (expert account or caregiver account), the expert physician or caregiver must be presented with the dedicated UI. Importance Required Development risk Low Development priority High Clinical value No
FR-100 Related BPs: BP-65, BP-66 Identified via: CEM Title: When a caregiver or expert physician accesses the profile of an interventions user via the interventions platform s/he must see the respective data Description: i-PROGNOSIS-690494_D2.1.docx p. 168/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
When a caregiver or expert physician accesses the profile of an interventions user, the data (contact details, health status, statistics regarding interventions engagement data and monitoring data) corresponding to the respective user account must be loaded and presented to her/him as fields or feedback elements. Importance Required Development risk Low Development priority Medium Clinical value No
FR-101 Related BPs: BP-63 Identified via: CEM Title: The behavioural modelling sub-system must fuse data stored on the interventions platform and produce/update an interventions behavioural model of the interventions user Description: The behavioural modelling sub-system must fuse monitoring data and interventions engagement data generated by the interventions user, stored on the interventions platform, and produce/update an interventions behavioural model of the interventions user. Importance Required Development risk Medium Development priority Medium Clinical value Yes
FR-102 Related BPs: BP-28 Identified via: CEM Title: The paired devices (Mandometer, smart belt, smart TV remote, and sleep earphones) should attempt to reconnect automatically in the event of abrupt loss of connection while communicating with the smartphone Description: If the paired devices lose connection while communicating (e.g. transferring data) with the smartphone, automatic reconnection should be attempted in order to restore the communication between the devices in a way that is transparent for the second stage and interventions user. While disconnected, data capture is halted until successful connection is achieved.
Importance Preferred Development risk Medium Development priority High Clinical value No
i-PROGNOSIS-690494_D2.1.docx p. 169/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
7.2 NON-FUNCTIONAL REQUIREMENTS
This section presents a list of the non-functional user requirements identified. User requirements categorised as non-functional are those that specify quality characteristics of the system.
NFR-1 Related BPs: - Identified via: CEM Title: The system must comply with all the required safety standards Description: The sensors and software must be safe to use. Furthermore, the sensors during the second stage of PD detection or the interventions phase (Mandometer; smart belt; smart TV remote; sleep earphones; Kinect) must comply with safety standards.
Importance Required Development risk Low Development priority High Clinical value No
NFR-2 Related BPs: - Identified via: CEM, FGO6 Title: The system must be compliant with the countries’ laws regarding data transmission and storage Description: If restrictions regarding data transmission and storage in the country i-PROGNOSIS is deployed exist, the system must be designed and operate in a way that conforms to the country’s laws.
Importance Required Development risk Medium Development priority High Clinical value No
NFR-3 Related BPs: BP-1 Identified via: CEM Title: The detection / interventions application must be searchable in the respective application market (Google Play, Microsoft Store, etc.) Description: i-PROGNOSIS-690494_D2.1.docx p. 170/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The first stage or second stage or interventions user's must be able to successfully find the i-PROGNOSIS detection / interventions application by simply searching a relevant quote like “i-prognosis” or “iprognosis”. Furthermore, the detection / interventions application must be compliant to the existing regulations in each market platform in order to be available for search and download.
Importance Required Development risk Low Development priority High Clinical value No
NFR-4 Related BPs: - Identified via: CEM, FGO18 Title: The detection/interventions application and its background services must not have significant impact on the first stage or second stage or interventions user's mobile device battery life Description: The first stage or second stage or interventions user must not need to recharge her/his mobile device significantly more frequently due to the operation of the detection / interventions application running background services. If applicable, heavy tasks of these services must take place when the first stage or second stage or interventions user's mobile device is charging Importance Required Development risk Medium Development priority High Clinical value No
NFR-5 Related BPs: - Identified via: CEM Title: The Cloud server must be able to handle the traffic generated by the simultaneous usage Description: The networking system must be able to cope with the generated traffic and computational load.
Importance Required Development risk Medium Development priority High Clinical value No
NFR-6 Related BPs: BP-37, BP-38 i-PROGNOSIS-690494_D2.1.docx p. 171/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM, WO3, WO4 Title: The cost of additional devices required for capturing monitoring data and for use in PGS and assistive interventions must be as low as possible Description: The cost of additional devices required for capturing monitoring data and for use in PGS and assistive interventions must be as low as possible, so as for the expert physician to provide them to the interventions user without creating significant financial burdens. Nevertheless, the cost of the devices must be second to the accuracy and safety of the devices.
Importance Preferred Development risk Low Development priority Low Clinical value No
NFR-7 Related BPs: BP-2, BP-36 Identified via: CEM, FGO2 Title: The detection / interventions application must be available in different languages Description: The text of the detection / interventions application must be translated in different languages. Based on the location of the first stage or second stage or interventions user, the detection / interventions application will be downloaded and installed in the respective language (automated process handled by the mobile application store) on her/his mobile device (smartphone or tablet). Importance Required Development risk Low Development priority High Clinical value No
NFR-8 Related BPs: BP-39,BP-40, BP-41, BP-64 Identified via: CEM Title: The log-in process of the interventions application or the interventions platform must finish in an acceptable time frame Description: The time interval between the interventions user or expert physician or caregiver entering her/his account credentials until the validation or not of her/his log-in by the intervention platform must be as small as possible. Importance Required Development risk Low i-PROGNOSIS-690494_D2.1.docx p. 172/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Development priority High Clinical value No
NFR-9 Related BPs: - Identified via: CEM Title: The detection / interventions application and the interventions platform must be responsive Description: Given the time an action of the detection / interventions application and the interventions platform takes to complete, the first stage or second stage or interventions user or expert physician or caregiver must be presented with the appropriate indicator (e.g., loading bar).
Importance Required Development risk Low Development priority High Clinical value No
NFR-10 Related BPs: - Identified via: CEM, FGO17 Title: The detection / interventions application UI must be user friendly and offer accessibility by design Description: The UI elements of the detection / interventions application, including sliders, buttons, text, menus, text fields, must be designed so as to be easily accessible by the first stage or second stage or interventions user (high contrast, large enough fonts, distinctive colours). Default UI elements of the operating system must be used where applicable as the first stage or second stage or interventions user may be already familiar with their purpose from her/his interaction with other mobile applications.
Importance Required Development risk Low Development priority High Clinical value No
NFR-11 Related BPs: BP-42, BP-47 Identified via: CEM, FGO17 Title: Feedback elements of the interventions application should be easily understood by the interventions user i-PROGNOSIS-690494_D2.1.docx p. 173/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Description: The design of and the statistics presented via the feedback elements must provide the interventions user with easy-to-understand and useful information that will require minimal additional knowledge from the interventions user to assimilate it. Importance Preferred Development risk Medium Development priority Medium Clinical value No
NFR-12 Related BPs: BP-9, BP-10, BP-11, BP-12, BP-13, BP-14, BP-17, BP- 18, BP-19, BP-29, BP-30, BP-31, BP-48, BP-49, BP-50 Identified via: CEM, WO15 Title: The services targeting PD detection or capturing monitoring data of the detection application or interventions application, respectively, must run in the background Description: The first stage or second stage or interventions user must not have to interact with the services targeting PD detection or capturing monitoring data of the detection application or interventions application, respectively, unless s/he wants to activate/deactivate them.
Importance Preferred Development risk Medium Development priority High Clinical value No
NFR-13 Related BPs: BP-30 Identified via: CEM, FGO11, WO24 Title: The smart belt must be comfortable to wear Description: The smart belt must be thin, light, adjustable in size and comfortable for the second stage or interventions user to wear, with a clear indication of which way the belt should be worn. Its materials must be soft and hypoallergenic in order to be worn directly on the skin.
Importance Required Development risk Medium Development priority High Clinical value Yes
NFR-14 Related BPs: BP-31 i-PROGNOSIS-690494_D2.1.docx p. 174/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Identified via: CEM Title: The smart TV remote should resemble a regular TV remote and not be significantly heavier Description: The smart TV remote should resemble a regular TV remote so as for the second stage user or the interventions user to familiarise with it from the early days of use. Moreover, it should not be significantly heavier for the second stage user or interventions user to hold as much as possible. Importance Preferred Development risk Medium Development priority Medium Clinical value No
NFR-15 Related BPs: BP-48 Identified via: WO43, FGO14 Title: Sleep earphones involved in the TNI must be of the in- ear type, wireless and comfortable to wear Description: Sleep earphones involved in the TNI must of the in-ear type, i.e., they must be worn inside the ear canal. The sleep earphones must also be wireless so as for the interventions user to move freely during her/his sleep and comfortable to wear, i.e., lightweight and soft.
Importance Preferred Development risk - Development priority - Clinical value No
NFR-16 Related BPs: BP-40, BP-65, BP-66 Identified via: CEM, FGO17 Title: The UI of the interventions platform must be user friendly and accessible by design Description: The UI elements of the interventions platform, including sliders, buttons, text, menus, text fields, must be designed so as to be easily accessible by the interventions user or expert physician or caregiver (high contrast, large enough fonts, distinctive colours). Icons or accompanying text of icons must clearly state the functionality they correspond to.
Importance Required Development risk Low Development priority High Clinical value No i-PROGNOSIS-690494_D2.1.docx p. 175/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
NFR-17 Related BPs: BP-56 Identified via: CEM, WO32 Title: Videos included in the game instruction panel must involve actual persons showing the interventions user how s/he must act in a game scenario Description: The video included in the game instruction panel must present actual persons that display the actions the interventions user is required to perform during a particular game scenario, especially in the case of Exergames. Importance Required Development risk Low Development priority High Clinical value No
NFR-18 Related BPs: BP-51 Identified via: WO33 Title: The PGS games graphics should be realistic Description: The graphics and the virtual environment of the PGS games must be realistic and not abstract/animated so as for the interventions user to familiarise with them more easily.
Importance Preferred Development risk Low Development priority Medium Clinical value No
NFR-19 Related BPs: BP-51 Identified via: WO37 Title: The duration of a game session (multiple and consecutive game scenarios) must not exceed 30 minutes Description: The duration of a game session (multiple and consecutive game scenarios) must not exceed 30 minutes so as the engagement of the interventions user is kept at a satisfactory level.
Importance Preferred Development risk Low i-PROGNOSIS-690494_D2.1.docx p. 176/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Development priority High Clinical value No
NFR-20 Related BPs: BP-51 Identified via: CEM, WO39 Title: Exergames must involve physical activity targeting full body exercise Description: The different types of Exergames and their respective game scenarios must allow the interventions user to perform full body exercise during an Exergames session (multiple and consecutive Exergame game scenarios). Importance Preferred Development risk Low Development priority Medium Clinical value Yes
8 DISCUSSION AND CONCLUSIONS
The main goal of this report was to present the systematic approach towards the identification of user requirements of the i-PROGNOSIS project and the identified requirements. As the user is the central pillar of the project, the approach involved a series of actions - certain of them involving the major stakeholders directly - in order to capture detailed requirements and resolve ambiguous issues relating the development of the i-PROGNOSIS components. Moreover, a section of this report was dedicated to the presentation of the state-of-the-art regarding technology- based approaches similar to the i-PROGNOSIS focus areas against PD. The latter background served as a means to highlight the holistic approach of i-PROGNOSIS against PD, as compared to past and current projects and applications.
The basis for the identification of user requirements was set and built upon by the i- PROGNOSIS consortium experts through face-to-face sessions. Requirements derived from this procedure were further refined by the focus groups' observations and the results of the i-PROGNOSIS Web survey. The latter had a triple role: a) to source user requirements directly from a large population belonging to the target groups (healthy older than 40 years old, PD patients and PD experts), b) validate or shape certain technical specifications of the i-PROGNOSIS components, and c) collaterally and early disseminate the project to the target population.
Results of the Web survey were consistent in terms of the answers the different groups of participants gave and no controversies were observed. The latter are based on answers from 877 Web survey participants, received by the beginning of June, 2016. As previously mentioned, at the time of the writing of this report, the number of participants has risen over 1700, due to extensive dissemination efforts by partners, at the end of May and the beginning of June. After a first screening of the updated results, the vast majority of observations are not affected. The small number i-PROGNOSIS-690494_D2.1.docx p. 177/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
of observations affected will be taken into consideration during the first development cycle of the i-PROGNOSIS components and the updated Web survey results and observations will be presented in the second version of the present deliverable (D2.4 "Final version of user requirements analysis") on month 28 of the project.
A crucial section of this report is the one presenting the usage scenarios and the related business processes. The latter are presented with detail in order to cover the vast majority of actions to be performed by the major stakeholders of the project, i.e., potential users of the i-PROGNOSIS detection application and sensors, PD patients using the i-PROGNOSIS interventions, expert physicians, and caregivers. This granular approach from usage scenarios to business processes helped identify user requirements in a more efficient way and it will facilitate the development of the i- PROGNOSIS components.
Ultimately, 102 functional and 20 non-functional user requirements were identified in this first version of the analysis. As i-PROGNOSIS has adopted a spiral development approach, the first set of user requirements is expected to be updated mainly after the first pilots and the first user acceptance evaluation, as well as by the continuous stream of data from the Web surveys. Nevertheless, for the first development cycle, the present deliverable along with the upcoming deliverables D2.2 "Data collection and medical evaluation protocol" and D2.3 "First version of system specification" will constitute the three main pillars on which the systematic development of the i- PROGNOSIS PD detection tests and supportive interventions will be based.
ACKNOWLEDGMENT: i-PROGNOSIS partners would like to thank each and every one of the anonymous participants that have devoted a little of their time for taking the Web survey. Their contribution is of great value to the project.
i-PROGNOSIS-690494_D2.1.docx p. 178/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
REFERENCES
Adame M. R., Al-Jawad A., Romanovas M., Hobert M. A., Maetzler W., Möller K., & Manoli Y. (2012). TUG test instrumentation for Parkinson’s disease patients using inertial sensors and dynamic time warping. Biomedical Engineering/Biomedizinische Technik, 57(SI-1 Track-E), 1071-1074. Adams-Carr, K. L., Bestwick, J. P., Shribman, S., Lees, A., Schrag, A., & Noyce, A. J. (2015). Constipation preceding Parkinson's disease: a systematic review and meta-analysis. Journal of Neurology, Neurosurgery & Psychiatry, 87(7), 710-716. Al-Jawad A., Adame M. R., Romanovas M., Hobert M., Maetzler W., Traechtler M., & Manoli Y. (2012). Using multi-dimensional dynamic time warping for tug test instrumentation with inertial sensors. In Multisensor Fusion and Integration for Intelligent Systems (MFI), 2012 IEEE Conference on (pp. 212-218). IEEE. Alonso A., Huang X., Mosley T.H., Heiss G. and Chen H. (2015) Heart rate variability and the risk of Parkinson disease: The Atherosclerosis Risk in Communities study. http://onlinelibrary.wiley.com/doi/10.1002/ana.24393/abstractAl-Jawad A., Barlit A., Romanovas M., Traechtler M., & Manoli Y. (2013). The use of an orientation Kalman filter for the static postural sway analysis. APCBEE Procedia, 7, 93-102 Aman S., Szpakowicz, S. (2007). Identifying expressions of emotion in text. In Text, Speech and Dialogue (pp. 196-205). Springer Berlin Heidelberg. Arora S., Mayfield E., Penstein-Rosé C., & Nyberg E. (2010). Sentiment classification using automatically extracted subgraph features. In Proceedings of the NAACL HLT 2010 Workshop on Computational Approaches to Analysis and Generation of Emotion in Text (pp. 131-139). Association for Computational Linguistics. Assad, O., Hermann, R., Lilla, D., Mellies, B., Meyer, R., Shevach, L., … Malaka, R. (2011). Motion- Based Games for Parkinson ’ s Disease Patients, 47–58. Bamparopoulos, G., Konstantinidis, E., Bratsas, C., & Bamidis, P. D. (2016). Towards exergaming commons: composing the exergame ontology for publishing open game data. Journal of Biomedical Semantics, 7(1), Article nr 4. http://doi.org/10.1186/s13326-016-0046-4 Bamparopoulos, G., Konstantinidis, E., Bratsas, C., & Bamidis, P. D. (2016). Towards exergaming commons: composing the exergame ontology for publishing open game data. Journal of Biomedical Semantics, 7(1), Article nr 4. http://doi.org/10.1186/s13326-016-0046-4 Barichella M., Cereda E., and Pezzoli G. (2009). Major Nutritional Issues in the Management of Parkinson’s Disease. Movement Disorders: Official Journal of the Movement Disorder Society, 24 (13): 1881–92. doi:10.1002/mds.22705. Barichella M., Marczewska A.M., Mariani C., Landi A., Vairo A., Pezzoli G. (2003). Body weight gain rate in patients with Parkinson's disease and deep brain stimulation. Movement Disorders, 18(11):1337-40. Barry, G., Galna, B., & Rochester, L. (2014). The role of exergaming in Parkinson’s disease rehabilitation: a systematic review of the evidence. Journal of Neuroengineering and Rehabilitation, 11(1), 33. http://doi.org/10.1186/1743-0003-11-33 Bella, S. D., Benoit, C. E., Farrugia, N., Schwartze, M., & Kotz, S. A. (2015). Effects of musically cued gait training in Parkinson's disease: beyond a motor benefit. Annals of the New York Academy of Sciences, 1337(1), 77-85. Bergh C., Callmar M., Danemar S., Holcke M., Isberg S., Leon M., Lindgren J., Lundqvist A., Niinimaa M., Olofsson B., Palmberg K., Pettersson A., Zandian M., Asberg K., Brodin U., i-PROGNOSIS-690494_D2.1.docx p. 179/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Maletz L., Court J., Iafeta I., Björnström M., Glantz C., Kjäll L., Rönnskog P., Sjöberg J., Södersten P. (2013). “Effective Treatment of Eating Disorders: Results at Multiple Sites.” Behavioural Neuroscience, 127 (6): 878–89. doi:10.1037/a0034921 Berke, E. M., Gottlieb, L. M., Moudon, A. V., & Larson, E. B. (2007). Protective association between neighborhood walkability and depression in older men. J Am Geriatr Soc, 55(4), 526-533 Borek, L. L., Kohn, R., & Friedman, J. H. (2006). Mood and sleep in Parkinson’s disease. The Journal of Clinical Psychiatry, 67(6), 958–963. Brace F. and Johns T. (2004) An extensive review of research on guidelines for questionnaire construction. http://www.georgelockhart.net/Questionaires Brusse KJ., Zimdars S., Zalewski KR, et al.(2005) Testing function-al performance in people with Parkinson disease. Phys Ther. 2005; 85:134–141. Buck A.K., Herrmann K., Stargardt T., Dechow T., Krause B.J., Schreyögg J. (2010) Economic Evaluation of PET and PET/CT in Oncology: Evidence and Methodologic Approaches. DOI:10.2967/jnmt.108.059584 Burke R.E (2011). Induction of Axon Re-Growth in Dopamine Neurons: A New Approach to Neurorestoration in Parkinson’s Disease. http://www.parkinsonalliance.org/print- research.php?ID=422 Chaffar S., Inkpen, D. (2011). Using a heterogeneous dataset for emotion analysis in text. In Advances in Artificial Intelligence (pp. 62-67). Springer Berlin Heidelberg Chaudhuri K.R., Fung V.S.C. (2016). The stages of PDL: NMS, non motor symptoms; REM, rapid eye movement. Fast Facts: Parkinson’s Disease, 4th edn. Oxford: Health Press Limited; www.fastfacts.com Chaudhuri K.R., Odin P. (2010). The challenge of non-motor symptoms in Parkinson’s disease. DOI: doi:10.1016/S0079-6123(10)84017-8 Covassin, N., Neikrug, A. B., Liu, L., et al. (2012). Clinical correlates of periodic limb movements in sleep in Parkinson’s disease. Journal of the Neurological Sciences, 316(1-2), 131–136. Csurka G., Perronnin F. (2011). Fisher Vectors: Beyond Bag-of-Visual-Words Image Representations. Computer Vision, Imaging and Computer Graphics. Theory and Applications Communications in Computer and Information Science, 229: 28-42. Dalli J., Kroes N., Geoghegan-Quinn M. (2011) Strategic plan of European commission, on the basis of “Active ageing- a Policy Framework, WHO. http://www.epc.eu/documents/uploads/pub_1426_healthy_and_active_ageing.pdf Darley F.L., Aronson A. E. and Brown J. R. (2011). Differential diagnostic patterns of dysarthria, Journal of Speech and Hearing Research, 12: 246-269. Darmon, A, Azulay, J. P., Pouget, J., Blin, O. (1999). Posture and gait modulation using sensory or attentional cues in Parkinson’s disease. A possible approach to the mechanism of episodic freezing. Rev. Neurol., 155, 1047-1056. Deuschl, G., Raethjen, J., Aron, R., Lindemann, M., Wilms, H., & Krack, P. (2000). The pathophysiology of parkinsonian tremor: a review. Journal of neurology, 247(5), 33-48. Drotár P., Mekyska J., Rektorová I., Masarová L., Smékal Z., Faundez-Zanuy M. (2014). Analysis of in-air movement in handwriting: A novel marker for Parkinson's disease. Computer methods and programs in biomedicine, 117(3), 405-411 Dulski, J., Schinwelski, M., Konkel, A., & Sławek, J. (2015). Sleep disorders in Parkinson's disease. Postępy Psychiatrii i Neurologii, 24(3), 147-155. i-PROGNOSIS-690494_D2.1.docx p. 180/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Eberhart, R. C., & Hu, X. (1999). Human tremor analysis using particle swarm optimization. Proceedings of the 1999 Congress on Evolutionary Computation, 3, doi: 10.1109/CEC.1999.785510. Fan, J. Y., Chang, B. L., & Wu, Y. R. (2016). Relationships among Depression, Anxiety, Sleep, and Quality of Life in Patients with Parkinson’s Disease in Taiwan. Parkinson’s Disease. Available online at http://dx.doi.org/10.1155/2016/4040185 Fereshtehnejad S.M., Ghazi L., Sadeghi M., Khaefpanah D., Shahidi G.A., Delbari A., and Lökk J. (2014). “Prevalence of Malnutrition in Patients with Parkinson’s Disease: A Comparative Study with Healthy Controls Using Mini Nutritional Assessment (MNA) Questionnaire.” Journal of Parkinson’s Disease 4(3): 473–81. doi:10.3233/JPD-130323. Gaig C., and Tolosa E. (2009). When Does Parkinson’s Disease Begin? Movement Disorders: Official Journal of the Movement Disorder Society 24 Suppl 2: S656-664. doi:10.1002/mds.22672. Gallagher R., Donoghue J., Chenoweth L., Stein-Parbury J. (2008). Self-management in older patients with chronic illness. DOI: 10.1111/j.1440-172X.2008.00709. Geman O. (2011) “Data Processing for Parkinson's Disease: Tremor, Speech and Gait Signal Analysis”, Proc. Of 3rd International Conference on E-Health and Bioengineering (EHB), Iasi, Romania Giancardo, L., Sánchez-Ferro, A., Butterworth, I., Mendoza, C. S., & Hooker, J. M. (2015). Psychomotor impairment detection via finger interactions with a computer keyboard during natural typing. Scientific reports, 5. doi:10.1038/srep09678 Giladi, N. (2001). Freezing of gait. Clinical overview. Adv. Neurol., 87, 191-197. Grosset K.A. (2005). Therapy concordance and drug adherence in Parkinson's disease. http://theses.gla.ac.uk/2341/ Guo, P. F., Bhattacharya, P., & Kharma, N. (2010, June). Advances in detecting Parkinson’s disease. In International Conference on Medical Biometrics (pp. 306-314). Springer Berlin Heidelberg. Gustavsson, A., Svensson, M., Jacobi, F., Allgulander, C., Alonso, J., Beghi, E., ... & Gannon, B. (2011). Cost of disorders of the brain in Europe 2010. European Neuropsychopharmacology, 21(10), 718-779. Hadjileontiadis, L. J. (2005a). Wavelet-based enhancement of lung and bowel sounds using fractal dimension thresholding-Part I: Methodology. IEEE Transactions on Biomedical Engineering, 52(6), 1143-1148. Hadjileontiadis, L. J. (2005b). Wavelet-based enhancement of lung and bowel sounds using fractal dimension thresholding-part II: application results. IEEE Transactions on Biomedical Engineering, 52(6), 1050-1064. Hadjileontiadis, L. J. (2015). EEG-based tonic cold pain characterization using wavelet higher order spectral features. IEEE Transactions on Biomedical Engineering, 62(8), 1981-1991. Hadjileontiadis, L. J., & Rekanos, I. T. (2003a). Detection of explosive lung and bowel sounds by means of fractal dimension. IEEE Signal Processing Letters, 10(10), 311-314. Hadjileontiadis, L. J., & Rekanos, I. T. (2003b). Enhancement of explosive bowel sounds using Kurto-sis-based filtering. In Proceedings of the 25th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 2003. (Vol. 3, pp. 2479-2482).
i-PROGNOSIS-690494_D2.1.docx p. 181/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Hadjileontiadis, L. J., Liatsos, C. N., Mavrogiannis, C. C., Rokkas, T. A., & Panas, S. M. (2000). Enhancement of bowel sounds by wavelet-based filtering. IEEE Transactions on Biomedical Engineering, 47(7), 876-886. Ho A., Iansek R., Marigliani C., Bradshaw J., Gates S. (1998). Speech impairment in a large sample of patients with Parkinson's disease. Behavioural Neurology, 11: 131-37. Hoehn, M., & Yahr, M. (1967). Parkinsonism: onset, progression and mortality. Neurology, 17(5), 427-442. Ioakimidis I., Modjtaba Zandian L., Eriksson-Marklund C., Bergh A. G., and Södersten P. (2011). “Description of Chewing and Food Intake over the Course of a Meal.” Physiology & Behaviour 104 (5): 761–69. doi:10.1016/j.physbeh.2011.07.021. J΄auregui-Barrutia, A., Tijero-Merino, B., G΄omez-Esteban, J. C., and Zarranz, J. J. (2010). Sleep disorders in Parkinson’s disease: REM sleep behaviour disorder and restless legs syndrome. Revista de Neurologia, 50, supplement 2, S15–S19. Jain, S., Ton, T. G., Perera, S., Zheng, Y., Stein, P. K., Thacker, E., ... & Longstreth, W. T. (2012). Cardiovascular physiology in premotor Parkinson's disease: a neuroepidemiologic study. Movement Disorders, 27(8), 988-995. Jankovic, J. (2008). Parkinson’s disease: clinical features and diagnosis. Journal of Neurology, Neurosurgery & Psychiatry, 79(4), 368-376. Kistner A., Lhommée E., and Krack P. (2014). “Mechanisms of Body Weight Fluctuations in Parkinson’s Disease.” Frontiers in Neurology 5. doi:10.3389/fneur.2014.00084 Konstantinidis, E. I., Antoniou, P. E., & Bamidis, P. D. (2015). Exergames for Assessment in Active and Healthy Aging - Emerging Trends and Potentialities. In Proceedings of the 1st International Conference on Information and Communication Technologies for Ageing Well and e-Health (pp. 325–330). SCITEPRESS - Science and Technology Publications. http://doi.org/10.5220/0005494503250330 Konstantinidis, E. I., Bamidis, P. D., Billis, A. S., Kartsidis, P., & Papageorgiou, S. G. (2016). Physical training in-game metrics for cognitive assessment: evidence from extended trials with the FitForAll exergame platform. Frontiers in Aging Neuroscience, Submitted. Konstantinidis, E. I., Billis, A. S., Bamparopoulos, G., Papageorgiou, S. G., & Bamidis, P. D. (2016). Can Game Metrics Assist Stealth Assessment? Evidence from FitForAll Exergaming Platform. In 14th International Athens/Springfield Symposium on Advances in Alzheimer Therapy (p. 186). Athens. Konstantinidis, E. I., Billis, A. S., Mouzakidis, C. A., Zilidou, V. I., Antoniou, P. E., & Bamidis, P. D. (2016). Design, Implementation, and Wide Pilot Deployment of FitForAll: An Easy to use Exergaming Platform Improving Physical Fitness and Life Quality of Senior Citizens. IEEE Journal of Biomedical and Health Informatics, 20(1), 189–200. http://doi.org/10.1109/JBHI.2014.2378814 Konstantinidis, E., Bamparopoulos, G., & Bamidis, P. (2016). Moving Real Exergaming Engines on the Web: The webFitForAll case study in an active and healthy ageing living lab environment. IEEE Journal of Biomedical and Health Informatics, 1–1. http://doi.org/10.1109/JBHI.2016.2559787 Korczyn A. D. (1990). Autonomic nervous system disturbances in Parkinson’s disease. Adv Neurol, 53, 463-68. Krishnan A. (2006). Frequency-following response. In: Burkard, R. F., Don, M., & Eggermont, J. J. (Eds). Auditory evoked potentials: basic principles and clinical application. Philadelphia: Lippincott, Williams, and Wilkins (pp. 313-335). i-PROGNOSIS-690494_D2.1.docx p. 182/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Kubzansky, L. D., Subramanian, S. V., Kawachi, I., Fay, M. E., Soobader, M. J., & Berkman, L. F. (2005). Neighborhood contextual influences on depressive symptoms in the elderly. Am J Epidemiol, 162(3), 253-260. Kumru H., Santamaria J., Valldeoriola F., Marti M. J. and Tolosa E. (2006). “Increase in Body Weight after Pramipexole Treatment in Parkinson’s Disease.” Movement Disorders: Official Journal of the Movement Disorder Society, 21 (11): 1972–74. doi:10.1002/mds.2108 Lebouvier T., Chaumette T., Paillusson S., Duyckaerts C., Bruley des Varannes S., Neunlist M., and Derkinderen P. (2009). “The Second Brain and Parkinson’s Disease.” The European Journal of Neuroscience, 30 (5): 735–41. doi:10.1111/j.1460-9568.2009.06873.x. Leow, L. A., Rinchon, C., & Grahn, J. (2015). Familiarity with music increases walking speed in rhythmic auditory cuing. Annals of the New York Academy of Sciences, 1337(1), 53-61. Letanneux A., Danna J., Velay J.-L., Viallet F. and Pinto S. (2014), From micrographia to Parkinson's disease dysgraphia. Mov. Disord., 29: 1467–1475. doi: 10.1002/mds.25990 Lim, I., van Wegen, E., de Goede, C., Deutekom, M., Nieuwboer, A., Willems, A., Jones, D., Rochester, L. and Kwakkel, G. (2005). Effects of external rhythmical cueing on gait in patients with Parkinson's disease: a systematic review. Clinical rehabilitation, 19(7), 695- 713. Lorefält B., Granérus A. K., and Unosson M. (2006). “Avoidance of Solid Food in Weight Losing Older Patients with Parkinson’s Disease.” Journal of Clinical Nursing 15 (11): 1404–12. doi:10.1111/j.1365-2702.2005.01454.x. Lorig K.R., Sobel D.S. , Stewart A.L. , Brown B.W. Jr, Bandura A., Ritter P., Gonzalez V.M., Laurent D.D., Holman H.R. (1999). Evidence suggesting that a chronic disease self- management program can improve health status while reducing hospitalization: a randomized trial. Med care, 37(1):5-14. Macedo, A., Prada, R., & Santos, P. (2014). Serious Game for Motion Disorders Rehabilitation of Parkinson’s Disease Patients. Maetzler W., Domingos J., Srulijes K., Ferreira J. J., Bloem B. R. (2013). Quantitative wearable sensors for objective assessment of Parkinson's disease. Movement Disorders, 28(12), 1628- 1637. Maetzler W., Nieuwhof F., Hasmann S. E., Bloem B. R. (2013). Emerging therapies for gait disability and balance impairment: promises and pitfalls. Movement Disorders, 28(11), 1576- 1586 Mair, C., Diez Roux, A. V., & Galea, S. (2008). Are neighbourhood characteristics associated with depressive symptoms? A review of evidence. J Epidemiol Community Health, 62(11),940-946. Martin, J. P. (1967). The basal ganglia and posture. Lippincott. Maurer, A. H. (2015). Gastrointestinal Motility, Part 2: Small-Bowel and Colon Transit. Journal of Nuclear Medicine, 56(9), 1395-1400. McNaney, R., Olivier, P., Balaam, M., Holden, A., Schofield, G., Jackson, D., … Rochester, L. (2015). Designing for and with People with Parkinson’s : A Focus on Exergaming. Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems - CHI ’15, 501–510. http://doi.org/10.1145/2702123.2702310 Mergl, R., Mavrogiorgou, P., Hegerl, U., & Juckel, G. (2005). Kinematical analysis of emotionally induced facial expressions: a novel tool to investigate hypomimia in patients suffering from depression. Journal of Neurology, Neurosurgery & Psychiatry, 76(1), 138-140.
i-PROGNOSIS-690494_D2.1.docx p. 183/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Metman LV., Myre B., Verwey N., Hassin-Baer S., Arzbaecher J., Sierens D., Bakay R (2004). Test- retest reliability of UPDRS-III, dyskinesia scales, and timed motor tests in patients with advanced Parkinson’s disease: an argument against multiple baseline assessments. Mov Disord 19(9):1079–1084 Morales-Briceño H., Cervantes-Arriaga A., Rodríguez-Violante M., Calleja-Castillo J., and Corona T. (2012). “Overweight Is More Prevalent in Patients with Parkinson’s Disease.” Arquivos De Neuro-Psiquiatria 70 (11): 843–46 Neal, M., & DeLaTorre, A. K. (2016). The Case for Age-Friendly Communities. Institute on Aging Publications. Paper 20, http://pdxscholar.library.pdx.edu/aging_pub/20 Oster, G. (1973). Auditory beAats in the brain. Scientific American, 229, 94–102. Pachoulakis, I., Papadopoulos, N., & Spanaki, C. (2015). Parkinson’s disease patient rehabilitation using gaming platforms: lessons learnt. arXiv Preprint arXiv:1511.02589. Papapanagiotou V., Diou C., Langlet B., Ioakimidis I., and Delopoulos A. (2015). “Automated Extraction of Food Intake Indicators from Continuous Meal Weight Measurements.” In Bioinformatics and Biomedical Engineering, edited by Francisco Ortuño and Ignacio Rojas, 35–46. Lecture Notes in Computer Science 9044. Springer International Publishing. http://link.springer.com/chapter/10.1007/978-3-319-16480-9_4. Paulmann S., Pell M.D. (2010). Dynamic emotion processing in Parkinson’s disease as a function of channel availability. Journal of Clinical and Experimental Neuropsychology 32(8), 822–835 (2010) Pell, M. D., Leonard, C. L. (2005). Facial expression decoding in early Parkinson's disease. Cognitive Brain Research, 23(2), 327-340 Philips J. (1997) The handbook of training evaluation and measurement method. Butterwoth Heinemann index. ISBN–13: 978–0–88415–387–0 ISBN–10:0–88415–387–8 Ricciardi L., Baggio P., Ricciardi D., Morabito B., Pomponi M., Bentivoglio A. R., Volpe D. (2015). Rehabilitation of hypomimia in Parkinson’s disease: a feasibility study of two different approaches. Neurological Sciences, 1-6. Richardson, R. A. (2013). Are canopy cover and walkability associated with depression in low income adults? Scholar Archive. Paper 967-Master’s Thesis, Department of Public Health and Preventative Medicine, Oregon Health & Science University School of Medicine. Robert, P. H., Konig, A., Amieva, H., Hã., C., Andrieu, S., Bremond, F. F., Bullock, R., … König, A. (2014). Recommendations for the use of Serious Games in people with Alzheimer’s Disease, related disorders and frailty. Frontiers in Aging Neuroscience, 6, Article nr 54. http://doi.org/10.3389/fnagi.2014.00054 Rodriguez-Oroz, M. C., Obeso, J. A., Lang, A. E., Houeto, J. L., Pollak, P., Rehncrona, S., ... & Quinn, N. P. (2005). Bilateral deep brain stimulation in Parkinson's disease: a multicentre study with 4 years follow-up. Brain, 128(10), 2240-2249. Rubinstein, T. C., Giladi, N., Hausdorff, J. M. (2002). The power of cueing to circumvent dopamine deficits: a review of physical therapy treatment of gait disturbances in Parkinson's disease. Mov. Disord., 17, 1148-1160. Saarloos, D., Alfonso, H., Giles-Corti, B., Middleton, N., & Almeida, O. P. (2011). The built environment and depression in later life: The health in men study. Am J Geriatr Psychiatry, 19(5), 461-470
i-PROGNOSIS-690494_D2.1.docx p. 184/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Sakar B.E., Isenkul M.E., Sakar C.O., Sertbas A., Gurgen F., Delil S., Apaydin H. and Kursun O. (2013). Collection and Analysis of a Parkinson Speech Dataset With Multiple Types of Sound Recordings. IEEE Journal of Biomedical and Health Informatics, 17(4): 828-834 Salarian, A., Russmann, H., Wider, C., Urkhard, P. R., Vingerhoets, F. J. G., & Aminian, K. (2007). Quantification of tremor and bradykinesia in Parkinson's Disease using a novel ambulatory monitoring system. IEEE Transactions on Biomedical Engineering, 54(2), 313-322. Salarian, A., Zampieri, C., Horak, F. B., Carlson-Kuhta, P., Nutt, J. G. & Aminian, K. (2009). Analyzing 180° turns using an inertial system reveals early signs of progression of Parkinson’s disease. Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 224-227. Schapira A.H., Emre M., Jenner P., Poewe W. (2009). levodopa in the treatment of Parkinson's disease. DOI: 10.1111/j.1468-1331.2009.02697 Scherer S., Morency L.-P., Gratch J., Pestian J.(2015) “Reduced vowel space is a robust indicator of psychological distress: a cross-corpus analysis”, IEEE International Conference on Acoustics and Signal Processing (ICASSP), pp. 4789-4793, South Brisbane, Australia Sheard, J.M., Ash S., Mellick G.D., Silburn P.A., and K. Kerr G. (2013). “Markers of Disease Severity Are Associated with Malnutrition in Parkinson’s Disease.” PloS One 8 (3): e57986. doi:10.1371/journal.pone.0057986 Simons, G., Pasqualini, M. C. S., Reddy, V., & Wood, J. (2004). Emotional and nonemotional facial expressions in people with Parkinson's disease. Journal of the International Neuropsychological Society, 10(04), 521-535.
Skodda S., Groenheit W., Schlegel U. (2012) “Impairment of Vowel Articulation as a Possible Marker of Disease Progression in Parkinson’s Disease,” PLoS ONE 7(2), e32132. doi:10.1371/journal.pone.0032132 Skodda S., Visser W., Schlegel U. (2011) "Vowel articulation in Parkinson’s disease". J Voice 25: 467–472. Smits E. J., Tolonen A. J., Cluitmans L., van Gils M., Conway B. A., Zietsma R. C., Maurits N. M. (2014). Standardized Handwriting to Assess Bradykinesia, Micrographia and Tremor in Parkinson’s Disease. PLoS ONE, 9(5), e97614. http://doi.org/10.1371/journal.pone.0097614 Reboucas, G. M., Lopes, P. F. F., Felipe, T. R., Bezerra, J. C. L., de Albuquerque Filho, N. J. B., de Medeiros, H. J., & Soares, F. H. R. (2013). Measures of Heart Rate Variability in Patients with Idiopathic Parkinson? s Disease. Journal of Alzheimers Disease & Parkinsonism, 2013. Starner T., Auxier J., Ashbrook D., Gandy M. (2000). The gesture pendant: A self-illuminating, wearable, infrared computer vision system for home automation control and medical monitoring. In Wearable computers, the fourth international symposium on (pp. 87-94). IEEE. Staudenmayer, J., Pober, D., Crouter, S., Assett, S., & Freedson, P. (2009). An artificial neural network to estimate physical activity energy expenditure and identify physical activity type from an accelerometer. Journal of Applied Physiology, 107(4), 1300-1307. Tanner C.M., Brandabur M., Dorsey E.R. (2008). Parkinson’s disease: a global view. Parskinson Report, Spring 2008, 9011 Task Force of the European Society of Cardiology and the North American Society of Pacing and Electrophysiology. (1996). Heart rate variability: standards of measurement, physiological interpretation and clinical use. Circulation. 1996 Mar 1;93(5):1043-65.
i-PROGNOSIS-690494_D2.1.docx p. 185/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Tsanas A. (2012). Accurate telemonitoring of Parkinson’s disease symptom severity using nonlinear speech signal processing and statistical machine learning. DPhil Thesis, University of Oxford, St. Cross College. Taplidou, S. A., & Hadjileontiadis, L. J. (2010). Analysis of wheezes using wavelet higher order spectral features. IEEE Transactions on Biomedical Engineering, 57(7), 1596-1610. The Rescue Consortium (2005). Using cueing to improve mobility in Parkinson's disease: a CD- ROM for therapists. Available at http://hces- online.net/websites/rescue/overview/welcome.htm Ünlü A., Brause R., and Krakow K. (2006). Handwriting analysis for diagnosis and prognosis of parkinson's disease. In Proceedings of the 7th international conference on Biological and Medical Data Analysis (ISBMDA'06). Maglaveras N., Chouvarda I., Koutkias V., and Brause R. (Eds.). Springer-Verlag, Berlin, Heidelberg, 441-450. DOI=http://dx.doi.org/10.1007/11946465_40 Valappil, R. A., Black, J. E., Broderick, M. J., Carrillo, O., Frenette, E., Sullivan, S. S., ... & Langston, J. W. (2010). Exploring the electrocardiogram as a potential tool to screen for premotor Parkinson's disease. Movement disorders, 25(14), 2296-2303. Vinokurov, N., Arkadir, D., Linetsky, E., Bergman, H., & Weinshall, D. (2015). Quantifying Hypomimia in Parkinson Patients Using a Depth Camera. In International Symposium on Pervasive Computing Paradigms for Mental Health (pp. 63-71). Springer International Publishing. Wahbeh, H., Calabrese, C., Zwickey, H. (2007). Binaural beat technology in humans: A pilot study to assess psychologic and physiologic effects. The Journal of Alternative and Complementary Medicine, 13(1), 25-32. Wang X., Zhang C., Ji Y., Sun L., Wu L., Bao Z. (2013). A Depression Detection Model Based on Sentiment Analysis in Micro-blog Social Network. Trends and Applications in Knowledge Discovery and Data Mining, Lecture Notes in Computer Science, 7867, 2013, pp 201-213 Weber S. A. T., Santos Filho C. A. D., Shelp A. O., Resende L. A. L., Papa J. P., Hook C. (2014). Classification of handwriting patterns in patients with Parkinson´ s disease, using a biometric sensor. Global Advanced Research Journal of Medicine and Medical Sciences, 362- 366. Wei J., Li Y. (2016) “Stable dysphonia measures selection for Parkinson’s speech rehabilitation via diversity regularized ensemble”, IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), pp. 2264-2268, Shanghai, China. Woods, A. M., Nowostawski, M., Franz, E. A., & Purvis, M. (2014). Parkinson’s disease and essential tremor classification on mobile device. Pervasive and Mobile Computing, 13, 1-12. Zhang, H., Chen, X., Lin, W. Y., Chou, W. C., & Lee, M. Y. (2014). A novel accelerometer-based method for the real-time assessment of Parkinson's tremor. International Conference on Communication Problem-Solving, 97-90. Zhang, H., Hu, Y., Lan, X., Mahadevan, S., & Deng, Y. (2014). Fuzzy fractal dimension of complex net-works. Applied Soft Computing, 25, 514-518. Zhang, L., Dong, J., Liu, W., and Zhang, Y. (2013). Subjective poor sleep quality in Chinese patients with Parkinson’s disease without dementia. Journal of Biomedical Research, 27(4), 291–295.
i-PROGNOSIS-690494_D2.1.docx p. 186/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
APPENDIX I - FOCUS GROUPS QUESTIONNAIRE
The extensive questionnaire provided to the participants of the focus groups: i-PROGNOSIS Questionnaire (Please tick any applicable boxes)
Demographics YES NO Free text
Initials
Male
Age
Occupational status: working
Occupational status: retired
Occupation (current or previous if retired)
Country of birth
Country of residence
PD Patient
No PD Patient
Are you a Health Care Professional?
Do you have help at home?
Do you have any sensory limitation?
Do you have any physical limitation?
Which type of mobile phone do you currently use - is it a traditional phone?
Which type of mobile phone do you currently use - is it a full keyboard phone?
Which type of mobile phone do you currently use - is it a Smartphone?
Do you use your phone for phone calls every day? Do you use your phone for phone calls every week? Do you have internet access via Wi-Fi from your phone?
Do you use your phone for emails every i-PROGNOSIS-690494_D2.1.docx p. 187/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
day?
Do you use your phone for emails every week? Do you use your phone for internet every day? Do you use your phone for internet every week? Do you have internet access via Wi-Fi at home? Do you use a computer for emails every day? Do you use a computer for emails every week? Do you use a computer for internet every day? Do you use a computer for internet every week? Do you use your phone for writing text messages (SMS)? Do you use your phone for taking pictures of yourself (selfies)?
Do you have a Twitter account?
Do you use your phone to write Twitter posts? Do you own a Microsoft Band
(Smartwatch)? Do you have anybody to help you with smartphone, internet or any applications?
Questions about the design of the i-PROGNOSIS project (Please tick any applicable boxes)
Imagine you were a user of the i- PROGNOSIS application on your YES NO Required Preferred Optional smartphone/ device Would you consent to share your health status data and daily routines for research purposes in an anonymous manner? Is data anonymisation important to you? Would you be confident in the anonymisation of your data? Do you consider it important to have the possibility to withdraw your i-PROGNOSIS-690494_D2.1.docx p. 188/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
consent?
Would you give/withdraw your consent to participate (if asked to) through your mobile phone? Would you mind giving/withdrawing informed consent for your participation through an external website Would you like to be informed about the permissions given to the i- PROGNOSIS app (Android, iOS,
Windows) in advance? (Explanation/Justification would be provided) Would you like to have the option to select on which type of networks, Wi- Fi or/and Mobile (2G, 3G, 4G), i- PROGNOSIS will upload collected data? Do you consider the protection of health-related data important? Is the availability of the user interface in your mother tongue important - as opposed to just English? Would you like to know in advance the impact of the i-PROGNOSIS application to the smartphone battery life. Would you like the application to run “silently” in the background without bothering you at all? Would you like to receive feedback about your data (e. g. steps per day, sleep hours per day, average daily/weekly/monthly statistics, comparative figures)? Would you like to receive feedback about the project results (not related to yourself)? Could you imagine participating in such a project? Would your participation be dependent on the duration of the project?
i-PROGNOSIS-690494_D2.1.docx p. 189/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Free text
Do you have any comments about the design of the project?
Free text
For health care professionals: what are your expectations of i-PROGNOSIS?
Questions about the design of the i-PROGNOSIS applications (Please tick any applicable boxes) Imagine you were a user of the i- YES NO Required Preferred Optional PROGNOSIS application Do you think it is important to receive extensive instructions the first time you install the application Would you like to receive the initial information through informational videos inside the application Would you like to receive the initial information through pop-up windows
(windows appearing on the screen during use) inside the application Would you mind providing some more personal information just after you choose to participate in i- PROGNOSIS? Would you like to be able to complete this information through the mobile application? Would you mind connecting to an external website to fill in this information? Should the application interface be black and white? Should the application interface be in colour? Should the application interface be very colourful?
Is the background colour important?
Should the background be dark
(bright text) i-PROGNOSIS-690494_D2.1.docx p. 190/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Should the background be bright
(dark text)
Should the text font be large?
Should you have large buttons?
Should you have adjustable audio feedback? Should the icons/text be spread out
(stacked not too tightly)? Would you mind if the i-PROGNOSIS application was running in the background for more than 3 months? Would you mind if the i-PROGNOIS application was running in the background for more than 6 months? Would you mind if the i-PROGNOIS application was running in the background for more than 1 year? Would you wish to be reminded that the application is recording your data, e. g. every 6 months? (Please note that the application will run in the background, so that you don't notice it) Would you like to have access to technical support for this action throughout the use of the application? Technical support will be provided through an external website - is this ok for you? Technical support will also be provided through emails - is this ok for you? During the trial, technical support by phone will not be provided - is this a problem? Would you mind having to answer a brief questionnaire after you have downloaded the application? Do you think the questionnaire should have maximum 5 questions? Do you think the questionnaire should have maximum 10 questions? Should there be only one question per page? i-PROGNOSIS-690494_D2.1.docx p. 191/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Should there be several questions on the same page?
Is it ok to ask for your gender?
Is it ok to ask for your age group?
Is it ok to ask if you are a Parkinson's
Disease patient? Is it ok to ask if you are related to a
Parkinson's Disease patient? Is it ok to ask if you have any condition which might impact your activities of daily living? Is it ok to ask if what these conditions are (if any)? Free text
Do you have any comments about the design of the application?
Questions about the design of specialised gadgets: Smartwatch (Please tick any applicable boxes) The Smartwatch is comfortable to wear, adjustable in size, light, waterproof, easy to place on your wrist and easy to use. It includes and Accelerometer/ Gyroscope, so that minor tremor can be detected. It also has a heart rate sensor and skin temperature sensor, so that heart rate variability allows conclusions on the general health or its deterioration. With the same sensors, the Smartwatch can detect the quality of sleep, if worn at night, and could give early signals about sleep degradation.
Imagine you were a user of the i- PROGNOSIS Smartwatch YES NO Required Preferred Optional (Microsoft band) Would you mind wearing a
Smartwatch throughout the day? Would you mind wearing the
Smartwatch during a shower? Would you mind wearing a
Smartwatch while sleeping?
i-PROGNOSIS-690494_D2.1.docx p. 192/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Would you need help to synchronise the Smartwatch with your smartphone, if you had detailed instructions? During the trial period, online help will not be available 24/7- is this a problem? Would you like to receive reminders about the need to wear the device? Would you be comfortable wearing a Smartwatch for a week? Would you be comfortable wearing a Smartwatch for a month? Would you be comfortable wearing a Smartwatch for 3 months? Have you used self-monitoring devices before? If you used self-monitoring devices before, have you dropped out? If you dropped out on previous use Free text of devices, why? What features would make you use Free text a Smartwatch regularly? Do you have any comments about Free text the design of the Smartwatch? Questions about the design of specialised gadgets: Smart belt (Please tick any applicable boxes) Smart belt is a belt that will bear microphones to capture sounds from the abdomen and it will be connected to the Smart phone. Bowel sounds can be analysed to detect constipation. The Smart belt is comfortable, easy to place on the abdomen, soft, light and washable. Imagine you were a user of the i- PROGNOSIS abdominal Smart YES NO Required Preferred Optional belt Is it important that the smart belt is available in different size? Would you mind wearing the Smart belt during the day? Would you mind wearing the Smart belt during the night? Would you like to take the Smart belt off during a shower? i-PROGNOSIS-690494_D2.1.docx p. 193/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Should the belt need to be directly on the skin, would you use it? Do you see a potential benefit of the Smart belt to help detecting bowel movement abnormalities? Would you be comfortable wearing a Smart belt for a week? Would you be comfortable wearing a Smart belt for a month? Would you be comfortable wearing a Smart belt for 3 months? During the trial period, online help will not be available 24/7- is this a problem? Do you have any comments about Free text the design of the Smart belt? Questions about the design of specialised gadgets: Mandometer (Please tick any applicable boxes) The Mandometer is a thin and light plate scale, connected with the user's Smart phone and is placed under the user's plate so that it can analyse food intake as well as estimate the fluid consumption. This would help to detect changes in dietary habits or deterioration.
Imagine you were a user of the i- YES NO Required Preferred Optional PROGNOSIS Mandometer Would you mind having to place your plate on a Mandometer for every meal? Would you be comfortable using a Mandometer for each meal for a week? Would you be comfortable using a Mandometer for each meal for a month? Would you be comfortable using a Mandometer for each meal for 3 months? Would you like the Mandometer to give you direct feedback about your eating habits? i-PROGNOSIS-690494_D2.1.docx p. 194/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Do you think there's a potential benefit of the Mandometer to detect any eating abnormalities? Do you have any comments about Free text the use of the Mandometer? Questions about the design of specialised gadgets: Smart TV remote (Please tick any applicable boxes) The Smart TV remote is a TV remote control which bears ECG (electrocardiogram) sensors to capture heart rate and detect heart rate variability. The sensors can be added to your own remote control. The Smart TV remote is connected (wirelessly) with the Smart phone. Imagine you were a user of i- PROGNOSIS Smart TV remote YES NO Required Preferred Optional control Do you have a TV? Are other people using the same remote control you use? If you need to be the only one who uses the remote control, would you need an additional one? Is it important that remote control with the ECG sensors does not feel heavier? Would you prefer the smart TV remote to have a bright colour for identification so you can find it easily and see which one is yours? Do you like the idea of having the remote control capturing ECG signals? Would you like to receive summary information about your ECG on your TV? Do you have any comments about Free text the design of the Smart TV remote? Questions about the design of the i-PROGNOSIS interventions The i-PROGNOSIS project also provides some interventions, in case any abnormalities are detected, which may point to an increased risk of developing Parkinson's Disease. These Interventions include a number of approaches to sustain the quality of life of users based on the stage of the abnormalities. The objective is to provide a holistic and personalised platform of interventions that the user will take advantage of, in collaboration with her/his doctor and caregiver. Questions about the personalised game suite (Please tick any applicable boxes)
i-PROGNOSIS-690494_D2.1.docx p. 195/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
The personalised game suite includes Exergames, physical games to improve muscle tension, walking, posture and general fitness status. These electronic games can be played on TV or on a computer or a tablet or a smartphone. With help of the Microsoft Kinect 2, which captures body and gesture data, it can provide the user with personalised exercise scenarios that will be presented as 3D games on a screen. The user interacts with the games via Kinect, which analyses her/his performance. Performance data are then fed back to the user, who will learn about her/his training progress. Other options of the game suite would be dietary games to improve dietary habit, affective games to fight depression and train emotional facial expressions, handwriting games to sustain the ability of handwriting, or voice games to sustain the quality of voice (these can be played also on a tablet). Depending on the needs of the user, as detected by the smartphone/ Smart watch and the other specialised gadgets and as verified by a clinician, the respective games, tailored to the needs will be offered. Imagine you were a user of the i- YES NO Required Preferred Optional PROGNOSIS game suite Would you like to be able to use the Exergames while standing, sitting or lying, depending on your daily preference? Would you like to listen to music during the Exergames? Would you like to be able to chose the type of music (classical/ rock/ pop/ jazz/etc)?
Should the Exergames be rhythmic?
Should you be able to change the rhythm and volume? Would you like that an actual person on a video shows you what do? Would you like the instructions through animations? Would you be happy for the game to ask you if you have taken your medication (if applicable) before you start exercising? Would you like to receive motivation related messages (e.g. “you are doing very well – please keep up”)? Do you prefer a keyboard for the games which will not employ Kinect? Do you prefer a touchpad for the games which will not employ Kinect? Is it important to you to get feedback from the games?
i-PROGNOSIS-690494_D2.1.docx p. 196/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Would you follow dietary games and suggestions in order to adopt a more balanced diet? Is is important to you to have the social dimension in the game suite (e.g., collaboration, competition)? Can you imagine that an Affective game could help improve your mood
- emotional facial expressions over time? Can you imagine that a Handwriting game could help improve the quality of your handwriting over time? Can you imagine that a Voice game could help improve the quality of your voice over time? Do you see a potential benefit of game suite to help you adopt a healthier lifestyle? Do you have any comments about Free text the design of the Game suite? Questions about the night time intervention with headphones (Please tick any applicable boxes) This intervention requires the user to wear a pair of unobtrusive headphones and a smartwatch during sleep, and to have the targeted nocturnal intervention service enabled on the smartphone. With help of the smartwatch and smartphone, sleep disturbances can be detected by analysing accelerometer data, heart rate data and skin temperature. When a sleep disturbance is detected, sounds embedded with binaural beats are provided via the wireless headphones. These binaural beats are proven to help the user fall into restful sleep and boost energy for daily activities, and the volume is adjustable. Imagine you were a user of the i- PROGNOSIS night time YES NO Required Preferred Optional intervention (headphones) Can you imagine that this night time intervention might help you sleep? Would you accept to try wearing headphones during the night? Is it important that the headphones are fitting well on your ear? Should the headphones have a bright colour, so you can easily find them in case they fall out of your ears after all?
Would you like the headphones to i-PROGNOSIS-690494_D2.1.docx p. 197/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
glow in the dark?
Would you prefer to only have an earphone on one side? Would you prefer the headphones embedded in a headband?
Would you prefer in-ear headphones?
Do you have any comment about the Free text design of the headphones? For health care professionals: Is it important for the system to distinguish disturbed sleep from REM Free text behaviour disorder (acting out dreams), so that sleep is not disturbed by the beats?
Questions about the gait intervention (Please tick any applicable boxes)
This intervention is used to improve gait: By using a gait rhythm guidance service (e. g. a metronome sound) on the smartphone and Smart watch, accelerometer data will be analysed and if a freezing episode (episode when the feet are "glued to the ground") is detected, rhythmic guidance like sound cues a are provided through the Smartphone. The sound can be selected, it is discrete when moving in public, and the volume is adjusted to the background noise level. Imagine you were a user of the i- YES NO Required Preferred Optional PROGNOSIS gait intervention Would you accept trying the gait enhancement intervention? Should the gait intervention give you a signal when it detects a freezing episode, so that you can select if you want the intervention to start? Do you have any comments about Free text the design of the gait intervention?
Questions about voice enhancement
This intervention is designed to improve the user's communication during phone calls. Whenever the user chooses to use the voice enhancement service on her/his smartphone, this service will manipulate the user's voice, if impairment is detected, so that the user sounds natural and easy to understand when talking on the smartphone. This intervention is able to adjust the volume to the background noise level and the voice will still sound natural. Imagine you were a user of the i- YES NO Required Preferred Optional PROGNOSIS gait intervention i-PROGNOSIS-690494_D2.1.docx p. 198/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Would you accept trying the voice enhancement intervention? Is it important to you that you are easy to understand when speaking on the phone? Should the voice enhancement give you a signal when it detects your voice is not loud or clear enough, so that you can try to balance your voice before activating the intervention? Should the voice enhancement system also give you a signal when your voice is not loud enough in relation to the background noise level, when you are not speaking on the phone, e. g. when you are in a face to face conversation? Do you have any comments about the design of the voice Free text enhancement?
i-PROGNOSIS-690494_D2.1.docx p. 199/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
APPENDIX II - WEB QUESTIONNAIRE LINKS
The vast majority of questions included in the Web survey have already been presented in Section 5.2 along with the respective results. Below, the hyperlinks to the full Web survey in six languages are provided. By clicking on a link, the reader will be redirected to the Google Forms environment.
Web survey in:
English French German
Greek Portuguese Swedish
The latter are also include in the project website dedicated page.
i-PROGNOSIS-690494_D2.1.docx p. 200/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
APPENDIX III - GUIDELINES FOR INTERVIEWERS
These guidelines are meant to support structured interviews in focus groups to ensure maximum outcome and alignment of all involved centres.
Main objecitves
Health Care Professional (HCP) Focus groups: Main objective of the interview is to extract from experts clearer ideas and expectations about the i- PROGNOSIS functionalities. The interviews are also aimed at assessing the relevance to Parkinson’s patients and other 40+ users of each question/functionality and to assess phrasing of questions and explanations as to their intelligibility by this age group. Patient/user Focus groups: Main objective of structured interviews is to obtain information about the user needs and relevance of requirements to an application like i-PROGNOSIS, so that the target audience would actually use the application in future. Also the language needs to be tested to be easily understandable even for potential users who may not be familiar with any of the devices or sensors.
Ultimately this information should lead to a Web-based questionnaire, which gathers relevant data on the potential usage of the i-PROGNOSIS application, including any additional devices and interventions.
Methodology
From the methodological point of view, this is supposed to be a ‘guided interview’, namely that the interviewees will be free to talk, guided by some keywords/inputs that are presented in the draft questionnaires.
Each of these tasks requires a series of decisions and activities: Review the information and requirements necessitating a questionnaire. Develop and prioritise a list of potential questions that will satisfy information requirements. Assess each potential question carefully. Determine the types of questions to be asked. Decide on the specific wording of each question to be asked. Determine the structure of the questionnaire. Evaluate the questionnaire.
To do so, the following steps provide guidance through the meeting:
1. Participant selection Selecting the experts with the relevant expertise and experience with PD patients and other subjects of the 40+ age group Selection of PD patients of different age groups and technological knowledge, as well as potential users aged 40+ without PD.
i-PROGNOSIS-690494_D2.1.docx p. 201/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
2. Project presentation A brief summary should be given to introduce a background, methods and final aim of i-PROGNOSIS, possibly using the i-PROGNOSIS information brochure. 3. Carrying out the interview The interviewer is required to go through the questions and give the participants ample opportunity to try and understand the language used, respond and to highlight any concerns about specific questions, subjects or devices: Their expectations of the project (HCP) focus groups Their requirements and needs (patients/users)
4. The data should be gathered in an anonymous manner, regarding demographics an average (e. g. age) or totals (e. g. gender) should be noted. Any comment on relevance of an item, suggestions for additional questions or problems understanding any used phrase should be carefully noted and a suggestion for a solution should be found from within the group. Ample time and opportunity for discussion should be allowed for.
5. Analysing and reporting The data should be analysed, summarised and feed back to the WP leader, who will then collate all responses and take them into account for creation of a Web-based questionnaire.
General guidelines
Useful administrative guidelines for using a questionnaire: Self-completion questionnaires, whether paper-based or electronic, benefit from the absence of an interviewer from the process. This removes a major source of potential bias in the responses and makes it easier for a respondent to be honest about sensitive subjects. A questionnaire can either be delivered by e-mail or be accessed via a Web page. Each form of media provides its own opportunities in terms of questionnaire construction, but equally each has its own drawbacks (Lebouvier et al. 2009) In addition to the elements of a good questionnaire development, there are several helpful administrative guidelines to improve the effectiveness of using questionnaires to collect data in the analysis and evaluation of HRD programs (Brace & Johns, 2004) Useful administrative guidelines for using questionnaires for improving HRD programs can be briefly summarised, based on the suggestions of Phillips (Philips, 1997).
Explain the Purpose of a Questionnaire: Spell out for the respondents the questionnaire’s use as part of an HRD analysis or evaluation project, including how the results will be put to use. This is not always understood by respondents, and it is useful to explain to them who will see the results and how the results will be used in the organisation.
i-PROGNOSIS-690494_D2.1.docx p. 202/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Have a Neutral Person or Third Party Administer the Questionnaire: In some cases, it is important and helpful to have a person other than the analyst or evaluator administering the questionnaire. A program coordinator or study sponsor instead of the analyst or evaluator can be used. This method increases the objectivity of the feedback on the HRD program and decreases the likelihood of the analyst or evaluator being perceived as reacting unfavourably to criticism expressed in feedback. This idea particularly extends to instructors in the administration of course evaluations at the end of a program.
Provide a Copy of the Questionnaire in Advance: For lengthy questionnaires covering HRD programs that span days or weeks, it is helpful to distribute the questionnaire early in the program so that participants can familiarise themselves with questions and statements. Respondents should be cautioned not to reach a final conclusion regarding their input until the end of the HRD program data-gathering activities.
Consider Quantifying Program Ratings for Comparisons: Analysts and evaluators often find it advantageous to attempt to solicit feedback from questionnaires in terms of numerical ratings. Although questionnaire data are still subjective, overall numerical ratings can be useful in monitoring performance and making comparisons with other, similar programs.
Provide Enough Time for Completing the Questionnaire: A “time crunch” can cause problems if participants are asked to complete a questionnaire in a rush at the end of an HRD program or data-gathering activity. To avoid this problem, analysts and evaluators should provide ample time to complete the questionnaire in a scheduled session as feasible. Pre-testing the questionnaire will provide guidance as to how much time will be required. When a questionnaire appears to be clear and logical to the respondents and those that will use the data that the questionnaire provides, this is invariably the result of a long and often complicated process of development and try out. Well-designed questionnaires cannot be developed in a short time or at the last minute. A questionnaire is only as good as the questions it contains. When the design guidelines presented in this chapter are followed, the questionnaire becomes a powerful diagnostic and evaluation tool for the performance-improvement professional.
i-PROGNOSIS-690494_D2.1.docx p. 203/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
APPENDIX IV - FOCUS GROUPS DETAILED OUTCOMES
KCL FOCUS GROUPS
The HCP and user focus groups reviewed all sections of the questionnaire. All questions were assessed for their relevance and any questions considered to be redundant were marked to be taken out. The wording for many questions was rephrased to read positively. The main outcomes of the focus group meetings were as follows:
HCP focus group meetings
General comments:
The HCP’s group suggested to include information about anonymisation in the paragraph explaining the i-PROGNOSIS project, as data protection was felt to be very important for this project. The HCPs were concerned about data protection and anonymisation, particularly if the i-PROGNOSIS team wants to contact users and if photos (selfies) are to be analysed. The HCPs would expect that patient identifiable data will not be compromised and that any data collected will not be used for any other purpose other than that of the project at hand. HCPs requested specific clarification as to how any photographs would be protected/ anonymised.
Comments on questions about the design of the i-PROGNOSIS application
Regarding all application design questions, the HCP group suggested that the technology team delivers 3 designs, which the users/ public can then select as the most attractive and user friendly. However it was recommended that the application comes with a mute button. The HCP group felt strongly about not including reminders to the users, as this could affect the natural usage of their phones, and in turn this could skew any data collected, as it would not reflect natural behaviours. The HCP group didn’t feel it was necessary to include technical support for the application, as most other apps do not include this anyway.
Comments on questions about the design of specialised devices:
Overall feedback from the different devices was considered to be interesting if given as a summary on a weekly/ fortnightly basis
Smartwatch
HCP group suggested replacing “sleep degradation” by “sleep disturbances” to aid intelligibility. The group added the question “Are there any reasons which will prevent you from wearing the smart watch during the day? If yes, please specify e.g. due to wearing a uniform”. The HCPs felt it was important to capture this data, as this might again affect the quality of any data collected. i-PROGNOSIS-690494_D2.1.docx p. 204/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Smart belt
The group added the question “Are there any reasons which will prevent you from wearing the smart watch during the day? If yes, please specify.”
Mandometer
The group recommended distinguishing between use of the Mandometer inside and outside of the user’s home.
TV Smart remote control
The group suggested a few changes to the description of the TV Smart remote so that is became clearer to read.
Patients/users focus group meetings
The focus groups provided comments to both the phrasing and relevance of the questions, and also provided all answers to the questionnaire without any issues.
Comments on questions about the design of the i-PROGNOSIS application:
The user group felt that the best way to design the application would be to see a variety of designs, and then for the public to vote on the favourite. The group were however, very much against the combination of red and blue, as they found this combination harder to see. Comments were made on the frequency of any pop ups, as the group felt that they didn’t want to have to stop and read pop ups frequently, they would rather just get on with using the application. The group preferred support from a real person over the phone, rather than instructions by email or through a website, as many felt that especially for those over 50, they would need more direct guidance than younger generations, particularly with all the extras that this application requires. If this was not available 24/7, it was felt it’s not too much of a problem.
Comments on questions about the design of specialised devices:
The group changed most of the descriptions, as they were felt to be too complicated for an average older person to understand. The wording for many questions was rephrased to read positively and to provide defined yes/no answers. The Smart watch was requested to include basic practical functions for a watch (e.g. alarm), as users may not want to wear the Smart watch in addition to their own watch, and require an alarm, especially if it needs to be worn at night. The Smart belt was specified to be thin, light and comfortable, with a clear indication of which way the belt should be worn. This is from previous experience of patients wearing belts for infusion medications. The Mandometer was discussed in great detail, and the comment was made that this may not be useful in the study, as food consumption slows at later i-PROGNOSIS-690494_D2.1.docx p. 205/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
stages rather than early stages. However to capture early signs of depression and subsequent slowing down of food consumption, it may be useful. No reference to capturing fluid intake should be made, as this is not obvious and had to understand how anything besides the weight and time for food intake can be captured. It was determined that ECG’s read by the TV Smart remote control, should not include a summary feedback as this may distress patients if the report doesn’t come back as “normal” and may prompt them to contact A&E unnecessarily. Overall feedback from the different devices was considered to be interesting if given as a summary on a weekly/fortnightly basis, but no single feedback.
Comments on questions about the design of the i-PROGNOSIS interventions:
The night time intervention headphones were requested to be comfortable and soft. The gait intervention for freezing was requested to include an optional automatic function. The groups were happy with the voice enhancement intervention.
TUD FOCUS GROUPS
HCP focus group meetings
Key points derived from all three focus groups are presented below:
In all three focus groups of healthcare professionals used a smartphone with the smartphone being more important for checking emails and internet usage of the computer. Only few healthcare professionals (especially the younger aged once) had a twitter account and even less are using a smart watch, especially for physical activities. About 75% would be happy to share health status data and daily routines but only if data anonymisation and protection of health-related data is guaranteed. Furthermore the majority requires the possibility to withdraw consent at any point in time. 75% would make their participation dependent of the project duration with a maximum of 6 month was preferred. The majority would like to receive feedback about personal data and project results whereas there were contrary opinion concerning: to be noted on the amount of data being transferred; to know impact on battery life in advance; to have the application „silently“ in the background. 75% of those being happy to provide health status data and daily routines would declare gender, age, if they are or not related to a person with Parkinson`s disease, if they are or not suffering from a condition which might impact activities of daily life but less then half would provide the kind of condition. For the application design it was most important that the application is easy to use, self-explanatory and that no huge information material is needed for i-PROGNOSIS-690494_D2.1.docx p. 206/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
understanding the application. If there is any information material a video was preferred. The application should be colourful with dark text, large font and adjustable audio feedback. There was much interest in the smart watch with most healthcare professionals over all age groups being happy to wear a smart watch at daytime and about 75% at night as well for a maximum of 3 months. As it will be worn during work, it needs to be light, small and unobstrusive. There were only a few younger aged persons having personal experience for physical activities with smart watches. The opinions about the smart belt were more restrictive with most people wearing it only during night and a few also at daytime for maximum 1 month, preferred 1 week. If people were happy to wear it, it was not important whether direct on skin or not. The Mandometer did not find wide acceptance as all interviewed healthcare professionals are working and nobody could imagine using a mandometer at work. In average there is one to maximum two meals per day at home for which the nurses and the physician assistant would be happy to use it but just a few physicians. Maximum usage was 1 month, preferred 1 week and direct feedback was preferred as otherwise no change in eating abnormalities was expected. In contrast most healthcare professionals would use a smart TV remote control, but only about 25% have a smart TV. As most households are shared communities the smart TV remote control needs to be easily distinctive from the normal remote control. The idea of ECG control with direct feedback was welcomed. Through all three groups of healthcare professionals personalised game suites were mostly liked by the younger aged participants and for sport activities also by the older aged participants. It was evaluated as important that the games can be performed in any kind of body position, with or without music and touchpad was preferred. Most of the healthcare professionals could not imagine that a night time intervention with headphones could improve sleep and therefore would not use it. The ones who could imagine would request comfortable headphones whereas it seems not to be important if in-ear or headband and if one or both ears. The headphones should not be glowing as the bed neighbour might be disturbed otherwise. The gait intervention and voice enhancement was evaluated as important and interesting especially if the intervention would self detect episodes of freezing and voice problems and would provide feedback to the participant. The feedback was required to be as unobtrusive for surrounding people as possible and needs to be switched off if needed by one hand movement.
AUTH FOCUS GROUPS
Below you can find the key results of the focus groups organised by AUTH
Medical experts i-PROGNOSIS-690494_D2.1.docx p. 207/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
All participants found that the project is very challenging and promising since it covers a broad range of PD symptom detection and offers interventions as well. The majority of the participants are familiarised with new technologies Exploration of various aspects of the project is necessary. All participants agreed that privacy and data anonymisation issues should be handled with extra caution. Most of the participants stressed the importance of technical help and guidance during the whole study period. Many participants were sceptical about the compliance with a long observation period. There were concerns about the use of the abdominal smart belt regarding night-time usage and skin contact. Motivational messages and feedbacks are more than welcomed. Most of the participants were interested about the mandometer. Disclosing a probable diagnosis of prodromal PD in a subject who has not sought medical attention may have serious phychological consequences (depression, distress, insecurity for the future).
Healthy subjects
Most participants found the project very challenging and promising and were interested in participating. The majority of the participants are familiarised with new technologies. Only one third of the participants take self pictures and have social accounts. It was a consensus that issues of privacy, data anonymisation and possibility of consent withdrawal should be of grave importance. It was highlighted that detailed instructions and technical assistance during the observation period would be of great help. Half of the participants raised concerns about the duration of the observation period. The use of the smart belt during sleep as well as the direct contact to the skin was not welcomed by a small proportion of the participants. The majority of the participants were interested about using the mandometer for their main meals and would like to receive feedback about the eating behaviour.
PD patients
The participants were not familiarised with new technology. Only a small proportion of PD patients uses a smartphone and has Wi-Fi internet access at home. The project would be very helpful and they declaired willing to buy and start using a smartphone. All participants found the project challenging and were particularly interested in interventions, focusing on their disability. The rrivacy and data anonymisation issues were stressed. i-PROGNOSIS-690494_D2.1.docx p. 208/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Technical help and guidance would be important for the majority of the participants. The majority of the participants were willing to try new interventions. A real person is preferred over a cartoon for instructions and the apps should use large text font and large buttons. The majority of the participants were willing to wear a smartwatch and use the mandometer. The targeted nocturnal intervention and the smart belt were not accepted so well for about half of the participants. A large proportion of participants declaired that they do not need a smart belt or that they do not suffer from constipation. All the participants admitted that they need more time and practice to incorporate new knowledge into their everyday routine. Short observation periods are important. Motivational messages and feedback about project results would be nice.
AGE INTERVIEWS
The main points that came back in each interview are:
The use of smartphone by older people should not be overestimated: although the use of a smartphone is quite widely spread among older people, its basic functions are the most important ones (phone, text). Important to be very clear and give explanation to reassure the participants – notably regarding data protection/privacy: this is an issue that is raised by our members for many years, they are sensitive to it and request for clear information. Language is a key element: apart from the very specific situation of Malta, it was clear that an application in their own language is essential to them. And this is actually something that correlates the experience of AGE: language is one of the first barriers. The use of social media is not very high: most of them are aware of the existing social media but do not use them a lot. Only one of the interviewees is using a health application but some were positive in using them. As for the smart watch, none of them has one. One of the interviewees was particularly interested in it. Be careful with ethical question when involving users in project, especially when it comes to health related issues, early diagnosis and prevention. Key for people informed about the developments and results: having feedback about the development of the project and the related results is very important.
In addition to these points, it is important to remind about the key issues that are coming back again and again through the different projects AGE is involved in and where there is a new technology component:
i-PROGNOSIS-690494_D2.1.docx p. 209/210 i-PROGNOSIS 690494 | D2.1 - First version of user requirements analysis
Accessibility is key and should be taken into account while developing the application – keeping in mind the multi-dimension: physical/sensory/cognitive. Reliability is essential: the first experience should be positive to avoid discouraging people. Support/training helps to reassure the users. Robust solutions are needed to ensure that there is no negative impact on the the battery autonomy.
i-PROGNOSIS-690494_D2.1.docx p. 210/210