Why Healthcare and Well-being Researchers should Become Developers: A Case Study Using Co-Creation Methodology

1. Introduction

Wearable technologies increase the ability to track different parameters related to health and well-being. Mobile applications such as Gyroscope [1], Apple Health [2], and Google Fit [3] aggregate health data to provide a better personal insight or a collected overview of data. Individual vendors of wearable trackers, such as Fitbit and Beddit, provide mobile applications specific to their devices. These vendors often provide Application Programming Interfaces (APIs) to collect data for analysis or visualization. The objective of Vire and Synergy is to design a mobile health application that applies data fusion and data visualization techniques to create additional value for the users besides the vendor-specific applications. Existing research and design methodologies to evaluate the value of these visualizations for potential users are limited. Questionnaires can provide insights into specific topics such as the comfort of using trackers [4]. Text messaging can be used to test the efficacy of a system intended to improve blood pressure control and treatment adherence compared with usual care [5]. The co-creation method described combines these methods (questionnaires/text) and uses the infrastructure. The infrastructure developed (Vire and Synergy) enables to use these methods real-time for continuous observation and responsiveness to events within the scope of the research objectives.

2. Methodology

The methodology, being developed through this case study, is based on the Experiential Design Landscapes (EDL). EDL follow a research-through-design approach where the design process is positioned in the social context by creating infrastructures that enable designers and other stakeholders to develop Experiential Probes that evolve over time [6]. The EDL methodology solves the dilemma of ecological validity versus control, by enabling measurements to be taken in the actual context previously only possible in a controlled environment. Also, the EDL methodology solves the complication in generalizing the findings from a controlled environment to a real-life setting. The real-life setting, in case of an EDL, is an open environment accessible to the general public. Our methodology is applied to the individual participant’s context instead of the open environment, so it extends the probes to Personal Experiential Probes (PEPs). As visualized in Figure 1, each participant independently interacts with the mobile application and related devices. Feedbacks from participants are collected throughout the study, and changes to the mobile health application are pushed to the participants in an iterative fashion. The advantage of this approach is that suggestions for new features, or other changes, are evaluated independently by other participants. In comparison with the EDL methodology, our methodology is restricted to software possibly extended with connected devices.

2.3. Environment

Figure 2 depicts the ecosystem utilized in the study. Specific for the aggregation of Fitbit, Beddit, and Moves data, the services preceding Synergy are used to facilitate the availability of personal data in Vire. Figure 2 also shows two versions, alpha and beta, of Vire that are used to evaluate a new Vire version within the research team before deploying to the participants. The illustrations used in Figure 2 are the logos of the platform or framework used by the services.

Synergy is built using the Meteor (open-source) platform, developed by the Meteor Development Group (MDG). Synergy functions as the backend for Vire and serves the back office for the research team. Meteor was chosen for its use of the distributed data protocol (DDP)—a publication/subscription mechanism through websockets—that enables “real-time” applications. Vire is built using the React Native framework, developed by Facebook [10]. React Native enables the development of native, iOS and Android mobile applications using JavaScript and React. React Native was chosen for its crossplatform compatibility and performance in comparison with its alternatives. The uses of Meteor and React Native require researchers to only have experience in JavaScript for the development of the backend, back office, and mobile applications. The use of one programming language throughout enables a lower threshold for new researchers to become skilled in the tools used.

2.4. Interfaces

The interfaces presented in Figures 3 and 4 are specific to the implementation of Vire and Synergy but can be stripped to be reused for other researches. Throughout the design of these interfaces, the intent of creating a boilerplate for future research is kept in mind.

Figure 3 shows the interface for the members of the research team. On the left pane is a list of all users with a notification label that shows a counter of unread messages sent by the participants. In the center pane, top left is the chat module to communicate with the participants. Participants do not know to which researchers they are talking to. On the top right, a list of current DOs for the participants and the completion state is listed. New DOs can be added there as well. On the bottom pane, there is room for notes from the researchers about the participants. Researchers share notes on the homepage and have a single page for notifications.

Figure 4 shows four screenshots of the MVP of Vire containing the homepage, where the visualization work will be done; the messenger, where participants can communicate with the research team; the list of DOs, where participants can see and mark their DOs complete; and the profile page where participants can link their devices and change language. The primary focus is on the development of the homepage.

3. Results

After six months of running the study, the results on user requirements can be categorized as macro- and microfeatures concerning the MVP or for the implementation of Vire and Synergy.

Table 2 shows the division between MVP and Vire- and Synergy-specific requirements found during the study. For Vire and Synergy, the new MVP requirements are built in during the study. Future studies will include these before the involvement of participants. The requirements for Vire and Synergy are meant to be obtained while performing the research and are planned to be implemented and evaluated during the duration of the study. The outcome of this methodology is a back-office and crossplatform mobile application, ready for further research. The final results provide new requirements for the definition of the MVP. Future studies can reuse the boilerplate—template code for the MVP—with the improvements from previous experiences. Also, as stated in Table 2, the structure of the methodology can be redefined to clarify expectations from participants and increase efficiency in the iterative process.

Figure 5 depicts the final version of Vire. In relation to Figure 4, a two-weekly overview and food record is added to provide better information to the users. Other notable differences include the refinement of general styling and markup. Throughout the study, the focus lies on the definition and development of core functionalities of the app and test that the app works both on low- and high-end mobile phones. To the end of the study, the requirements become saturated and more concrete; this enables to focus on improving the visual experiences.

Vire, for Android and iOS, will be used for a clinical trial of 150 cardiac rehabilitation patients in the Netherlands, Spain, and Taiwan. The methodology and study itself have contributed to the clinical trial by evaluating the functionality and usability of Vire outside the scope of the trial within an open environment. Without this process, issues or additional requirements not considered on forehand could affect the experience of the clinical trial.

4. Discussion

The methodology described in this chapter provides a rich feedback mechanism for the design and development of a research-based mobile application and accompanying back office. The reasons why well-being researchers should become developers are evident. The ability to define the MVP and the flexibility to implement features based on user feedback on the spot are the two main reasons we have found. By being involved in the development of a mobile health application as a researcher, the quality of the research increases. The effectivity of an intended interaction can be compromised by an esthetic mistake or incompatibility on certain devices. Using our methodology, the design and development artifacts that influence the user experience are already tackled. The experience, or the ability to gain experience, in defining prerequisites for the development of a mobile health application is gained through the hands-on approach. Within this process, the researchers are confronted with real-life development issues that give insight into the feasibility of a proposed or requested feature from participants or from within the research team itself. These learnings will provide the experience to prevent working on over-ambitious features and trigger creativity by discovering the limitations of used software and hardware. The use of JavaScript-based frameworks (React-Native) or platforms (Meteor) eases the learning curve for researchers, without in-depth programming experience, to tackle issues and develop iteratively by responding to feedback from participants. This approach enforces careful consideration of design and development decisions to (re)define the chosen direction of the study and offers a method to strengthen the qualities of the mobile health application and thereby the research itself.

Acknowledgments

This work is supported by the European Commission Horizon2020 which funded Do Cardiac Health: Advanced New Generation Ecosystem (Do CHANGE) project.