An Interface for IoT: Feeding Back Health-Related Data to Parkinson’s Disease Patients

Abstract

This paper presents a user-centered design (UCD) process of an interface for Parkinson’s disease (PD) patients for helping them to better manage their symptoms. The interface is designed to visualize symptom and medication information, collected by an Internet of Things (IoT)-based system, which will consist of a smartphone, electronic dosing device, wrist sensor and a bed sensor. In our work, the focus is on measuring data related to some of the main health-related quality of life aspects such as motor function, sleep, medication compliance, meal intake timing in relation to medication intake, and physical exercise. A mock-up demonstrator for the interface was developed using UCD methodology in collaboration with PD patients. The research work was performed as an iterative design and evaluation process based on interviews and observations with 11 PD patients. Additional usability evaluations were conducted with three information visualization experts. Contributions include a list of requirements for the interface, results evaluating the performance of the patients when using the demonstrator during task-based evaluation sessions as well as opinions of the experts. The list of requirements included ability of the patients to track an ideal day, so they could repeat certain activities in the future as well as determine how the scores are related to each other. The patients found the visualizations as clear and easy to understand and could successfully perform the tasks. The evaluation with experts showed that the visualizations are in line with the current standards and guidelines for the intended group of users. In conclusion, the results from this work indicate that the proposed system can be considered as a tool for assisting patients in better management of the disease by giving them insights on their own aggregated symptom and medication information. However, the actual effects of providing such feedback to patients on their health-related quality of life should be investigated in a clinical trial.

1. Introduction

Clinical management of Parkinson’s disease (PD) is traditionally based on clinical visits for a clinical assessment of the health status of the patients. In order to improve the PD care an alternative is to use subjective clinical rating scales as well as Internet of Things (IoT)- and sensor-based systems, as suggested by the International Parkinson and Movement Disorders Society Task Force on Technology [1,2]. This is essential since the disease state fluctuates and varies from patient to patient as well as reduces the need for clinician time and patient travels to the clinics.

Previous research has shown that technology-based measurements provide valid, reliable and treatment-responsive assessments of PD [3,4]. However, there is a lack of evidence showing that such measurements have an influence on health-related quality of life (HRQoL) of the patients [5]. Nevertheless, preliminary results from a study performed by van Uem et al. [6] indicate that providing personalized information to PD patients on their sensor-based assessments of tremor, dyskinesia and gait may have a positive effect on mobility changes over a 12-weeks study period, as measured by a PD Questionnaire-39 (PDQ-39). This shows that there is a potential that HRQoL of PD patients can be enhanced by providing means to patients to self-monitor and help better in managing their disease [7]. Additionally, the data could be shared between patients and clinicians, which could help in improving the clinical management of PD as well as in individualizing symptom and treatment evaluation.

Stamford et al. [7] suggested that IoT-based systems could assist PD management in the following three ways. First, such systems could help patients to monitor their medication by reminding them to take medicine at the planned times and intervals and to record the actual time and dose when medication was taken. Second, systems could be used for recording and analyzing movement patterns and motor function of the patients including bradykinesia (slowness of movements), dyskinesia (involuntary movements that occur due to excess medication), tremor, gait dysfunctions, etc. Third, the use of such systems could help in tracking non-motor symptoms including exercise activity, sleep, and depression, among others. One of the most important aspects when developing IoT-based systems is their ability to improve HRQoL of PD patients and one way to increase the HRQoL of patients is through active patient involvement in managing their disease [5]. From the healthcare providers’ perspective, such technology can help clinicians to monitor more efficiently their patients and to increase their patients’ engagement in self-management process in order to improve HRQoL [1]. However, sustainability of such systems can be impacted by the absence of feedback provided to the patients as users of the monitoring IoT system. Therefore, development of systems that, among other things, can achieve better engagement and self-management among patients is needed [1]. The systems should be designed in close collaboration with the end users (patients) to increase their ability to take an active role during the system development process. Finally, the data should be represented in a meaningful way to the patients and clinicians. Although some work has been done to visualize PD-related data [8,9] there have been no efforts to combine measures from different devices in a single visualization platform.

This study is part of a research project called EMPARK, which aims at developing and evaluating a system that combines registration of PD symptoms and medication information for enabling patients to better manage their symptoms by giving them adequate feedback on the state of their disease. The proposed system will gather objective PD measures (sleep and motor function) by sensors and medication information by an electronic dosing device and present those data to patients and their healthcare providers. Besides objective measures, a separate smartphone application will collect input from patients on their subjective symptoms including mood and register physical exercise and meal intake times. One of the most important components of the system will be an interface for providing feedback on aggregated symptom and medication information to patients. Therefore, the aim of this study is to present the development process of the patient interface, using a user-centered design (UCD) approach [9,10,11,12], which regards the system development with user participation and places users’ needs in centrum during the development process. Within the scope of the EMPARK another activity is to develop a system for clinicians to evaluate the complete picture of recorded data over a period in a dialogue meeting with patients. The results from this work will be reported elsewhere.

The rest of the paper is organized in the following way. Section 2 introduced the system architecture of the proposed system and the development process of the interface. Descriptions of the derived visualizations and evaluation results can be found in Section 3 followed by discussion and conclusions in Section 4.

2. Materials and Methods

The study was conducted according to UCD, with consideration of the PD patients’ needs by putting a minimum burden on the participants [9,10,11,12]. A demonstrator of the user interface was developed by an iterative design and evaluation process based on interviews and observations with 11 (6 males and 5 females) PD patients. The patients were all above 60 years old and had lived with PD for more than 5 years. The patients were recruited through the PD patient organization in Örebro, Sweden. Additionally, a usability evaluation was conducted with 3 information visualization experts to ensure that the visualizations are in line with the current standards and guidelines for this group of users.

2.1. Proposed System

The architecture of the proposed system consists of 3 independent layers: devices for data collection from home environment of patients, database server for data processing and storage, and applications for data presentation (Figure 1). The integration of the different devices will enable recording of PD symptoms and feedback to both patients and clinicians.

2.1.1. Devices

Smartphone application: To collect information on physical exercise and meal intake times, a smartphone application will be used. Patients will be asked to report meal intake times before they start eating by pressing a button in the application. Physical activities will be reported by a separate view on the smartphone where patients can enter the duration and physical exercise mode (e.g., mode 1: boxing, dancing, running, swimming, mode 2: bicycling, gym, and mode 3: walking).

Wrist sensor: The wrist sensor-based system is a solution developed by Global Kinetics Corporation [3]. It consists of an accelerometer, which continuously records movement data and algorithms for producing scores (in percentage) on bradykinesia, dyskinesia, and tremor every 2-min epoch when the sensor was worn.

Bed sensor: The bed sensor is developed by Cenvigo [13] and continuously captures information about bed presence. The sensor is placed on the frame of the patient’s bed.

Electronic dosing device: Medication data will be registered by an electronic dosing device, developed by Sensidose [14] for managing flexible and frequent doses using microtablets [15]. The dosing schedule is programmed by healthcare providers and patients are reminded when a medication intake is due.

2.1.2. Data Storage and Processing

The devices will communicate with a central server via mobile networks where the raw data will be stored and summarized into following scores on a daily basis:

Meal timing: For some patients meal intake can interfere with how well medication is absorbed in the body. For this reason, the patients are usually recommended to take medication either 30 min before or one to two hours after a meal [16]. Using the reported times and registered times for the delivered dose intakes from the dosing device, we can calculate a meal timing score by taking the ratio between the number of occasions when meal intakes were within the interval (30 min before and 60 min after medication intake) and the total number of meal intakes during a day and multiplying by 100.

Medication compliance: Using the planned and delivered medication intake times a medication compliance score was calculated as follows. For each recorded delivered medication intake the distance (in minutes) from the closest planned medication intake was calculated and then normalized by the following formula ((90 − distance)/90) × 100) where test occasions with a result greater than 90 were set to 0. This results in a measure on a range from 0 to 100 and for a particular day the mean of all the values were calculated. Using the dosing device patients can take extra doses to either replace the missed an intended dose or take another dose. Extra doses within 30 min before or after the intended dose were considered as replacement and not counted for the compliance whereas for others the value for compliance was set to 100.

Physical exercise: A physical exercise score per day was calculated by multiplying exercise mode with duration (in minutes) for each reported exercise occasion and then taking the mean score per day. Finally, the mean score was normalized by dividing it by an individual patient target ranging from 0 to 100. Resulting scores of greater than 100 were set to 100.

Sleep: The bed sensor records times when a patient is in and outside of a bed. Based on this information we have calculated a sleep score based on 3 components of the Pittsburgh Sleep Quality Index (PSQI) and the work performed by Williams and Cook [17] on modelling a sleep score using information from a smart home system. The first component that could be calculated with the bed sensor data is sleep duration. Since from the bed sensor we will not get sufficient information to determine the time when an individual has fallen asleep we use the cumulative time recorded by the sensor when an individual was in the bed. Based on PSQI, a modified sleep duration score can be quantified as following: >7 h, score = 0; 6–7 h, score = 1; 5–6 h, score = 2; and <5 h; score = 3. The second component that could be calculated is habitual sleep efficiency score and based on the information gathered by the sensor we can calculate it by taking the ratio between total sleep duration without interruptions and total sleep duration including interruptions and multiplying the result by 100. According to PSQI, the final habitual sleep efficiency score can be quantified as following: >85%, score = 0; 75–84%, score = 1; 65–74%, score = 2; and <65%, score = 3. The third component that could be calculated is sleep disturbances and was calculated first by counting the number of interruptions recorded by the sensor and assigning scores based on the PSQI as following: 0 interruptions, score = 0; 1 interruption, score = 1; 2 interruptions, score = 2; and 3 or more interruptions, score = 3. The final sleep score per day was then calculated by summing up the component scores (sleep duration, habitual sleep efficiency, and sleep disturbances) and normalizing the score into a scale 0–100 using the following equation 100 − (100/9 × sleep score).

Motor function: Since the wrist sensor-based system produces scores every 2 min for bradykinesia, dyskinesia, and tremor initially their means per hour were calculated. Next, the mean of the three averaged scores was calculated per hour to form a motor function score for a particular hour. To calculate motor function score per day mean was taken for the whole day.

An overall day score during a day could be calculated by taking the average of the 5 measures [5,7,18].

2.1.3. Data Presentation

The interface for patients, which is the subject of this paper, is planned to be implemented in a tablet and include easy-to-understand visualizations of the data.

2.2. Development of Patient Interface

2.2.1. Requirement Elicitation

To collect requirements for the interface from patients, a three-hour workshop with 7 PD patients was organized. The design team consisted of researchers and representatives from the industry as well as a PD nurse. The protocol followed the usual steps during UCD including presentation of the research project, its goals and the proposed system architecture followed by interviews and focus group discussions.

In the first part of the workshop, the patients were divided into groups of two and were interviewed by a researcher to understand their patient profiles. The focus of the interviews was on explaining a typical day with PD, common problems/symptoms patients experience, treatments, and technical tools (smartphone, tablets, etc.) they use often. The feedback from the patients were noted down by each of the researchers for further analysis. We included this part to be able to better understand the patients’ needs without focusing on the technical details of the system. This knowledge helped us to ask right questions when identifying the requirements and planning evaluations.

In the second part of the workshop, patients and researchers had a group discussion where patients were asked questions with the aim of gathering information on how the system could help them to better understand their symptoms and improve their treatment. Some of the questions posed to patients were: “How the data from the system could be of any help to you?”, “Which information would you like to see?”, “How the information would be presented/visualized?”, and “What could motivate you to keep measuring?”. The session was audio recorded, transcribed and analyzed to identify common themes. The analysis was done by each of the team researchers separately and then discussed by the team in order to reduce the probability for individual selection bias in terms of data analysis. This resulted into 19 user stories, which were then transformed into 8 requirements for the patient interface. Based on the analysis we also identified the non-motor symptoms that were important for the patients to better manage their disease. The identified symptoms included physical activity, sleep, and time for meal intake, among others.

2.2.2. Development of Mock-Up Demonstrator

After defining the main requirements of the interface with the users, a mock-up demonstrator was developed to visualize symptom and medication information. The demonstrator was developed based on a three-tiered level of abstraction i.e., starting from a simple, general overview of the data to a more detailed data representation. The demonstrator was developed using Adobe Experience Design CC (Beta, Adobe^®, San Jose, CA, USA) for an Android tablet with a 1024 × 768 screen resolution.

2.2.3. Evaluation of the Mock-Up Demonstrator

In total, four evaluations were conducted using the development process. Feedback from these evaluations lead to re-design and improvement of the demonstrator, as shown in

Table 1. Four-stage evaluation of the mock-up demonstrator.

Evaluation Type	Participants	Focus	Test
Heuristic evaluation	Research team	Usability	Usability heuristic adapted from W3C [17] (Appendix A)
User evaluation 1 (UE1)	6 PD patients (Workshop 2)	Validate requirements and user interface Validate adequacy of visualizations	Requirements were met through a set of tasks, interaction and navigation. Understanding and adequacy of visualizations was evaluated through series of tasks (Appendix B)
User evaluation 2 (UE2)	4 PD patients (Workshop 3)	Validate requirements and user interface Validate adequacy of visualizations	Requirements were met through a set of tasks, interaction and navigation. Understanding and adequacy of visualizations was evaluated through series of tasks (Appendix C)
Expert evaluation	3 visualization experts	Validate interface Validate adequacy of visualizations	Requirements were met through a set of tasks, interaction and navigation. Understanding and adequacy of visualizations was evaluated through series of tasks (Appendix D)

. The aim with the user evaluations (UE) was to validate requirements of the user interface as well as the adequacy of the visualizations. These evaluations drove the design process of the interface functionalities i.e., what measurements to be collected, and what data to visualize and how. Heuristic and expert evaluations focused on how the data should be visualized.

The heuristic evaluation was initially conducted by the researchers using the adapted usability heuristic for elderly from W3C [19] and design recommendations for PD patients [20] (Appendix A). The evaluation was summarized and the demonstrator was improved according to the feedback received.

The improved demonstrator was then evaluated during a second two-hour workshop with the same group of patients who attended the first workshop (UE1). There were 6 patients who attended this workshop since one of the patients was not available. Initially, the patients were introduced to the main views of the demonstrator and given a walkthrough the structure of the demonstrator followed by a structured task-based evaluation session where the patients were divided into groups of two and were asked to perform a set of tasks using the demonstrator, which was implemented in a tablet (Figure 2). There were 25 tasks the patients were asked to perform (Appendix B). The tasks were related to the 8 requirements and focused on usability of the demonstrator and clarity of the visualizations. For instance, the patients were asked to navigate from the main menu by selecting a variable (e.g., Medicine, Figure 3), to choose a good day from a two-week view (Figure 4), to explain visualization on a current-day view (Figure 5). The objective was to assess the patients’ understanding and feedback on adequacy of visualizations. The feedback from the patients were noted down by the researchers.

In a third workshop, 4 patients that were not involved in the development process during the first two workshops and 1 patient who was involved before participated (UE2). Similarly, as in the previous workshops, patients were given a walkthrough the demonstrator followed by a task-based evaluation. During this workshop the patients were asked to perform in total 30 tasks. In addition to the 25 tasks (Appendix B) the patients did 5 more as shown in Appendix C. The feedback from the patients were noted down by the researchers and analyzed later.

Finally, an evaluation of the demonstrator was performed with 3 experts in the field of information visualization. Similarly, as with patients, experts were given a walkthrough the main functionalities of the demonstrator followed by task-based evaluation and a semi-structured interview (Appendix D). The feedback from the experts was audio recorded, transcribed and analyzed by two of the researchers.

3. Results

3.1. User Stories and Requirements of the Interface

During the interview session with the patients, 19 user stories were defined, each of which focused on different components of the proposed system including social aspects such as symptom information sharing with peers and caregivers. One of the patients told us: “I think it will be helpful for my closest relatives to see it (interface) also. Usually they notice the changes, but they do not understand the reasons for the changes, so they get stressed and worried. The system will help them to understand better our condition.” The patients also emphasized the need for measuring more symptoms that were not captured by the system. They argued that in this way they could have a clearer and more holistic picture of the symptoms. Finally, the patients emphasized that the system should be able to individualize their preferences and needs. One of the patients explained: “It is difficult for outsiders to understand how different our symptoms and our needs are. We can only hope that it will be possible to find optimal solutions for each of us… I want to know when I am supposed to take my medication in relation to meals and how much am I supposed to exercise and sleep in order to feel as good as possible.” In total 8 requirements were identified that related to the patient interface, as following:

• Track the routine of an ideal day so they could repeat such behavior in the future
• Analyze the effect of meal timing on medication
• Analyze the status during a single day based on sleep, medication intake, physical exercise, motor function, and meal intake
• Analyze the effect of motor function in relation to overall day score
• Analyze the effect of motor function in relation to medicine compliance
• Analyze the effect of motor function in relation to physical exercise
• Analyze the effect of motor function in relation to sleep
• Analyze the effect of motor function in relation to meal intake timing

3.2. Visualizations

3.2.1. Show Overall Status

The home screen of the demonstrator is shown in Figure 3. In this view a representation of the six scores: (i) medication compliance, (ii) motor function, (iii) derived overall day, (iv) physical exercise, (v) sleep, and (vi) meal intake for the last 2-week period is shown. The scores are depicted in tiled layout with each having an icon. The icons are placed on a colored ring, which can have one of the three colors (green meaning good, gray meaning neutral, and orange meaning not good). The color gives an insight into the current state of the patient with regard to the corresponding score. The three categories are formed after applying the following rules for each of the six scores:

• IF Score ≤ 30 THEN Category = Bad
• IF Score > 30 AND Score ≤ 70 THEN Category = Neutral
• IF Score > 70 THEN Category = Good

3.2.2. Comparisons over 2-Week Period

Figure 4 depicts a calendar-based visualization for showing a value of a single score over two weeks. Each box represents a day where the values for the day are the derived scores as described in Section 2.2.2. The users can either see further details for each week separately by taping the corresponding week label or each day by tapping the corresponding day tile.

3.2.3. Comparisons for a Single Day

For this purpose, a view as shown in Figure 5 is proposed where the timeline approach uses the horizontal space to show time. The time of the day starts from the moment the patient went to bed the night before, as it is important to analyze the complete night sleep pattern and not just the calendar day data. The time is divided into hour slots as seen from the scale on top. The blue rectangles show the time of bed occupancy as recorded by the bed sensor. The vertical purple lines show the planned dose intakes as pre-programmed in the dosing device while the capsule icon shows the time when the medication was actually delivered. The timing for the reported meal intakes is shown with the red meal intake icon. The brown icon shows the reported times of physical exercise. The motor function score is shown in forms of green, gray, or orange boxes for each hour. The user can add or remove different components into the graph by selecting components using the radio buttons at the bottom of the screen. This allows the user to filter out uninteresting components if the view becomes too cluttered and allow for investigating patterns of selected variables separately. The vertical green bar at the rightest part of the visualization represents the overall day score. The patients can also see a textual log of these data by tapping the button “View details”.

3.2.4. Comparisons for a 1-Week Period

From the view in Figure 4 the users can click on a certain week to see 1-week data as shown in Figure 6. In this view the users can identify trends on their data over a week. For instance, at what time of the day, on average their motor function was optimal or worse.

3.2.5. Relationships between Scores

Using a scatterplot metaphor, a correlation view between the scores is shown as in Figure 7. This view was added based on the feedback from the patients during the first two workshops and experts in the field of information visualization. It was further evaluated during the third workshop with the patients. The users can select one of the given scores against the motor function score. Each circle represents a day and is colored with the same metaphor as described in other examples. The color map can be seen in the lower left side of the view. Additionally, the scatterplot is divided into quadrants where the days that positioned in the green quadrant represent a group of relatively good/bad days with respect to the selected scores. The radio buttons on the right side allow selection of one of the attributes to compare against the motor function score. Each circle represents a day. Clicking on a circle would redirect the user to the view shown in Figure 5.

3.3. Evaluation

3.3.1. Heuristic Evaluation

The heuristic evaluation resulted in several improvements of the demonstrator. The evaluation showed that the demonstrator should incorporate a possibility to magnify text size, the colors used should be neutral to improve contrast, and the links should be more obvious and clearly labelled. Moreover, the consistency of navigation and placement of the icons should be improved. Finally, the pages should be in a landscape format and text should be better coupled with the visualizations. The demonstrator was improved according to the received feedback.

3.3.2. Evaluation with Patients

In general, the majority of the patients during UE1 and UE2 could successfully perform the tasks using the demonstrator. Patients did not have problems with navigation and stated that the demonstrator was clear, intuitive and easy to use. The summary of the two user evaluations was categorized into three areas, as described below.

Feedback on visualizations: Patients generally found the visualizations clear and easy to understand. Nevertheless, they suggested some improvements in order to make the visualizations even clearer. One of the patients had red-green color blindness and therefore faced difficulties in understanding the visualizations and carrying out most of the tasks outlined in visualizations. Except for icons visualizing medicine intake compliance and overall day score, which were experienced as unclear, the rest of the icons were found to be easy to understand. Therefore, the visualizations will be changed to satisfy the users’ needs. The color palette will also be changed to adjust the interface for color-blinded users. The scatterplot metaphor that shows relationship view between the scores (Figure 7) was added to the demonstrator after the first two evaluations with the users and based on the suggestions of experts. Since, according to UCD, users’ opinions are the driving force for the development, the new part of the visualization was evaluated during the third workshop with the PD patients (UE2, see Section 2.2.3). The patients generally had difficulties to understand if the scores were related or not, but they could understand if the relationship was good or bad, based on the color coding. They did not either have any problem with selection of the scores using the radio buttons or viewing details for the chosen day by clicking on the data points on the graph. In general, the visualizations will undergo one more round of adjustments before the system will be tested in a clinical trial.

Use of the demonstrator: One major problem detected with the demonstrator was due to an implementation error where smaller bounding boxes for tapping were defined for the interactive screen elements although the elements were larger. This problem led to unresponsive tapping on buttons that created insecurity among the patients testing the demonstrator. The demonstrator has been improved regarding this aspect after the second workshop (UE1) and the patients did not experience this problem during the third workshop (UE2, see Section 2.2.3). Another problem was the tremor of the patients when touching the screen making the navigation difficult. This means that the sensitivity of the screen needs to be adjusted to the individual patients’ needs, as suggested by Nunes et al. [20]. This will be improved in the next version of the working prototype. Besides these two problems the patients did not experience any other problem with navigation. On the contrary, they experienced the navigation as clear, intuitive and easy to use.

Changes of the requirements: A few new requirements and suggestions to improvement were also identified during the evaluation process. The patients would like to have possibility to measure other factors such as stress, depression, and indicators of social activity. The research team discussed this issue and it was decided to not meet this requirement, at least during the scope of this project. The rationale for this decision was based on the results from the first workshop with the patients where they emphasized the importance of not being overwhelmed with measurement devices. As one of the participants during the workshop stated “our life should not only be about Parkinson. We cannot take measures and answer questions about our disease too often. We want to have a normal life also”. Going further, the patients would also like to see a visualization of a suggested interval (30 min before and 60 min after meal intake) for medicine intake in Figure 5. Some of the patients suggested that the interface should suggest them web links to relevant material about PD in general, new research, and to pharmacies where they could login with their electronic identification. This requirement will be met in the final working prototype of the interface and the choice of material to be displayed will be discussed with clinical domain experts.

The research team carefully discussed the need of adjustment of the system to patients’ individual needs since this was specifically emphasized by the patients. As one of the patients stressed “You can only hope that this system could help you to find what the optimal solution is for yourself since nothing works the same for everyone. Some people exercise a lot and that works for them but for others exercise just makes them feel worse. It would be nice to get reminders when you should take your medication, when you should eat and how much exercise and sleep are the best for you, as an individual.” The patients stressed that lack of understanding of their needs is a serious problem. In relation to this issue one of the patients said “They (caregivers) often group our needs and generalize our treatments but we have very different needs.” In the system, the interface retrieves subjective and objective symptom information from the central database where sensor and dosage data are stored. This enables individualized evaluation of symptoms. So far, the system does not provide adjustment of subjective measurements. This feature needs to be included during the trial when data from each individual patient will be available.

3.3.3. Evaluation with Experts

An expert evaluation was employed using the approach as suggested by Tory and Moller [21], based on comments from two visualization experts and a user experience designer from industry. Overall, the experts were satisfied with the design choices of the visualizations. One of them noted the following: “Overall I think it seems to be well designed for this audience”. Another expert added that he could accomplish the tasks related to Figure 4 “very easily”. There were suggestions for improvements such as the use of the pushbuttons instead of radio buttons by two of the experts for the visualization presented in Figure 5. Most of these comments were minor and the experts were very positive in their assessment.

4. Discussion and Conclusions

This paper presented an IoT-based concept for addressing the needs for better management of PD by giving patients insights into symptom and medication information. The proposed system consists of a range of measurement devices, which will be used in home environments of patients, and interfaces for patients and clinicians. The main focus of this paper was to present the development process of a mock-up for the patient interface, using an UCD approach. The contributions of the paper are two-fold. First, the lessons learned from applying an UCD approach with PD patients and secondly the interface design together with a list of requirements for the interface. Moreover, the paper summarizes results evaluating the performance of the patients when using the demonstrator during task-based evaluation sessions as well as opinions of the experts.

Our experiences with applying UCD together with PD patients are similar to findings in earlier studies [9]. We found this approach very useful for identifying the requirements and engage the users in the design process of the system, which is in line with the European Commission’s recommendations [22] for involving the end-users in the design process. During the process we learned it is important to consider special, individual characteristics of this user group. PD patients experience motor and non-motor symptoms that may impact their interaction with the system and devices such as smartphones and tablets. Therefore, testing the system may be stressful and exhausting for them. Additionally, the group usually consists of elderly users, who may not be familiar with modern technology. For these reasons, the evaluations need to be prepared in a way so that to not put extensive burden on the participants. The patients in our study recognized the need for objective measurement of symptoms and infrequent registration of symptoms using IoT-based systems. In contrast to a similar system presented by Baros et al. [9], our proposed system measures multiple symptom information and automatically records medication information, which are then visually presented to patients via an interface. Existing systems (e.g., [9]) often focus on visualizing correlations between medication and motor functions. In our work, we found that medication is only one of the many aspects influencing the patients’ HRQoL thus focusing solely on medication may be misleading. Using the mock-up demonstrator, it was found that the patients could successfully perform the tasks and found the visualizations clear and easy to understand. Similarly, the experts gave a largely positive feedback for the overall approach of the mock-up. As found from the user stories, patients had different symptom profiles and their symptoms varied over time, which calls for individualized visualization of data depending on the needs of the patients [20]. One of the patients experienced tremors during the task-based evaluation and this impacted the interaction with the demonstrator.

PD is a complex neurological disorder that significantly affects the HRQoL of patients. Since patients have different symptom profiles and their symptoms vary from day to day or even hour to hour there is a need for a multimodal data collection scheme that would enable individualized symptom evaluation and assessment of relations between different symptoms [1]. In our work we focus on measuring some of the main HRQoL aspects [7] such as sleep, motor function, physical exercise, medication compliance, and meal intake timing in relation to medication intake, using an IoT-based system consisting of a smartphone, wrist sensor, bed sensor and an electronic dosing device. The proposed system addresses two of the three areas where IoT-based systems could provide assistance in managing HRQoL problems of PD patients which are medication monitoring and symptom logging [7]. In our case, physical exercise score will be calculated based on the self-reported data. One alternative could be to employ sensor technology to quantify physical activity intensity and frequency and these data could be used for calculating the physical exercise score, which could be fed back to patients and clinicians [23]. Using the sleep score derived from the timestamp measurements of the bed sensor it would be interesting to investigate the “sleep benefit” among the PD patients i.e., whether the restful sleep improves symptoms next day. This analysis could be possible by applying time series and machine learning methods on the data and determining the population and individual patterns as well as relationships between sleep and other scores. The derived overall day score could be further optimized to an individual level using data-driven modelling approaches given the fact that there is an inter- and intra-patient variation in symptoms. Results from a separate study aiming to determine factors that influence the acceptance of the application by PD patients indicate that 70% of the patients (out of total of 50) would use the application if offered in the future. The two factors that predicted intention to use the application were performance expectancy and social influence. These results indicate that the application would be beneficial to them and their use and acceptance of the application can be influenced by important people in their social circles. These results will be published in a separate publication elsewhere.

Future versions of the interface could include following improvements. Including audio augmentation techniques for improving navigation and to tackle the problem with the inability of color-blinded patients to understand the visualizations. More specifically, selecting color blind-friendly palettes could further improve the interpretation of the information in visualizations and tackle the multiple varieties of colorblindness. It would be interesting to investigate differences in design requirements of the interface among patients on normal functioning (On phase) and severely impaired (Off phase) states. The work of the project continues with refinement of the subjective symptom recording, which will also include mood and overall assessment of HRQoL. The ultimate goal of our research is to investigate effects of the system’s feedback to HRQoL and empowerment of the patients. In addition to patient interface the plan is to develop an interface for clinicians, which will use the same data but with more specialized and detailed views such as the association between motor function and physical exercise and other scores as well as analysis of physical exercise in relation to disease progression to improve HRQoL outcomes of patients. When all the software for the interfaces and server-side functions are ready, there will be a clinical trial and evaluation that will be reported.