Health Weaver Mobile: Designing a Mobile Tool for Managing Personal Health Information during Cancer Care

Abstract

Cancer patients manage a great deal of information to coordinate their care. Critical aspects of this work take place while patients are away from home or have diminished attention due to symptoms or side effects. We describe the design of HealthWeaver Mobile, a mobile phone application we developed to help patients manage care-related information in such situations. We discuss findings from two participatory design groups with breast cancer patients and the design decisions made to implement functional requirements uncovered in those groups.

Introduction

In our research, we have been investigating the information management needs of cancer patients during treatment.¹ During our formative fieldwork, we found that much of patients’ information management work extends beyond their homes, desks, and desktop computers.² Although many information activities (e.g., researching treatments or managing benefits) take place while patients are at home and have access to their computers and collections of health information, important information management needs often arise when they lack such access. We refer to information activities in these situations as unanchored. For example, a patient might think of a question she wants to ask her oncologist while driving to work and she needs a way to note it before it is forgotten. Or, after a long phone-tag, she gets a call from the clinic while out and about, and needs to quickly refer to her calendar, notes, and recent labs.

Such unanchored information activities span many aspects of cancer care, including scheduling, preparing for appointments, attending clinic visits, and tracking symptoms and side effects. These activities become challenging because of the context in which they often take place: while the patient is away from home or her health information resources, when her attention is diminished due to drugs or side effects, or when she is faced with situations for which she cannot adequately prepare.

Although they are common, unanchored information activities lack adequate support. Most technologies designed to support cancer patients, such as CHESS,³ WebChoice,⁴ and Navigating Cancer,⁵ focus on providing patients with access to health management resources (e.g., articles, symptom tracking tools, discussion forums, and decision guides) from their computers. Similarly, clinic-based tools help patients to prepare as they await appointments,⁶ but these do not support preparation that many patients do in the weeks leading up to a visit. Even mobile tools for cancer management, such as ASyMS⁷ and WHOMS,⁸ only support remote symptom monitoring by care teams, leaving many unanchored information needs of patients unaddressed. Comprehensive solutions for patients’ unanchored activities are currently lacking.

To fill this gap, we used a user-centered approach to design a mobile phone application, HealthWeaver Mobile, to assist cancer patients in managing care-related information in unanchored settings. The application is a component of HealthWeaver, a web application that we are developing to enable cancer patients to manage their health information during treatment. In this paper, we describe HealthWeaver Mobile and the design process that led to its current form. Specifically, we discuss findings from two participatory design groups we used to determine functional requirements for HealthWeaver Mobile and the major design decisions that went into implementing those requirements. We conclude by discussing the implications of our findings for the development of mobile health technologies.

Methods

Informed by our fieldwork on patients’ unanchored activities,² we rapidly prototyped an initial version of HealthWeaver Mobile. Because many problems with mobile technologies are only found when they are used in real-world settings,⁹ we used this prototype to conduct two participatory design groups with cancer patients in order to refine its functional requirements.

Initial design of HealthWeaver Mobile

To provide design group participants with the concrete experience of managing care-related information with a mobile phone application, we developed a simple, questionnaire-based prototype on Windows Mobile 6.1 platform using the open source MyExperience framework¹⁰ (Figure 1). This initial prototype incorporated core modules anticipated from our fieldwork, including (1) daily check-ins to track well-being and symptoms, (2) calendar events (e.g., consultations with clinicians), (3) logs to monitor medications, pain, and surgery drains, and (4) notes (i.e., text, photo, and audio) for quick capture of care-related information. Notes could also be linked with calendar events. Data captured by the prototype was uploaded to the HealthWeaver website, where it could be viewed, edited, printed, and downloaded by the participants from their computers.

Figure 1:

Initial prototype of HealthWeaver Mobile

Design groups

To refine functional requirements for HealthWeaver Mobile, we iterated the design of our prototype across two participatory design groups.¹¹ Each group comprised patients undergoing treatment for breast cancer who used our prototype to manage care-related information for roughly three weeks. During that period, we met with each group three times to discuss participants’ experiences using the prototype. Based on those experiences, participants discussed the functionality that the final design of HealthWeaver Mobile needed to incorporate.

During group sessions, we focused the discussion on two major unanchored activities: (1) tracking cancer-related issues (e.g., symptoms) and (2) preparing for clinic visits. We used whiteboarding and sketching to clarify participants’ ideas and to facilitate discussion. All group sessions were video recorded. Following each session, we used thematic analysis to iteratively identify the emergent themes and concrete design ideas in the data we gathered.

Between sessions, participants were asked to use the prototype to log cancer–related issues and to capture notes for appointments. They could later access this information through the HealthWeaver website. Participants also wrote reflections on usage barriers and design enhancements in a paper journal, which they shared with us during design group sessions.

Three breast cancer patients participated in the first design group (P1, P2, and P3) and two took part in the second design group (P4 and P5). Two participants were diagnosed with stage IV disease and the other participants were between stage 0 and III. Three participants were in chemotherapy and two in radiation therapy. They varied in age (44–77 yrs, median=50) and had a broad range of backgrounds, including an acupuncturist, music business promoter, consultant, executive assistant, and retired teacher.

Results

Using the mobile prototype over three weeks gave our participants concrete insights about how the HealthWeaver Mobile application should work. In this section, we describe four functional requirements that emerged from the design groups.

Calendar Integration

A central finding was the importance of integrating the mobile application with the user’s calendar. Calendars were a primary tool our participants used to manage care-related information in their everyday lives. Thus, they expected our mobile application to integrate with their current system without disrupting it or making it more complicated. For P2, this meant our mobile application needed to integrate with the native calendar on her mobile phone, rather than requiring her to manage a separate health calendar specific to our application. As she expressed it: “It would have to be integrated. The whole idea of managing multiple calendars, it just adds more complexity.” Other participants reacted similarly. P4 noted twice in her journal that appointments she entered into the mobile prototype did not show up in the native Windows Mobile calendar as she expected. In a group session, she made it clear that calendar integration would be crucial for her.

Yet, participants wanted limits on integration. The two participants who worked in corporate environments both synchronized their work calendars to their mobile phones. Although they wanted to be able to see health-related appointments alongside work appointments, they did not want the two to mix. As P2 explained, “I don’t want my colleagues to read I am going to an oncologist.” Thus, while the health calendar needs to integrate with the work calendar, health events need to remain separate from other events. The default sharing settings used by many corporate calendaring systems make this separation paramount. The ideal solution, P3 explained, would be to have calendar layers, like those supported by Google Calendar (www.google.com/calendar), where events of different types can appear side by side, but the actual data stores are kept separate.

Quick capture and linking

One of the prototype features most positively received by participants was quick capture with text, photo, and audio notes. P1, for example, already used a digital recorder to capture dialogue during clinic visits. She liked the idea of using the mobile prototype to integrate audio-recorded notes with her other care-related data. Similarly, P4 thought that audio notes provided a convenient way to capture questions for her clinicians. Every time a question occurred to her she could simply speak it into the phone. She found audio recording to be much easier than typing text notes on the phone’s small keyboard.

What made quick capture particularly useful, however, was linking: the ability to immediately connect a note with a calendar appointment. P1 provided us with a particularly illustrative example of this need. While at a supplement store, she used the prototype to take a picture of a supplement she planned to ask her naturopath about. She thought it would be extremely convenient to later pull up that image directly from the calendar appointment entry during her next naturopath visit.

Other participants also wanted linking to tie captured information to calendar events. For example, P2 thought that directly linking notes she takes during appointments with calendar entries for those appointments would make the notes much easier to find later. Similarly, P4 wanted all the questions she audio-recorded for her clinician linked to the appropriate appointment so that she could review them on the phone before the appointment. She also wanted to attach additional audio notes during appointments to capture important information shared by the clinician. Thus, our participants saw the mobile prototype not only as a valuable way to capture information quickly, but as a means to access information as well. Linking—especially through calendar events—was seen as a key facilitator for quick capture and retrieval.

Supporting reflection

Although we initially did not plan on the mobile application serving this role, the participants indicated the prototype could be a helpful means for fostering reflection. After using the prototype for one week, P2 was surprised to find the daily check-in the most useful feature for her. Through its use, she realized that she was much more stressed than she thought, having entered “moderately stressed,” or worse, every preceding day. Similarly, P3, who at the time of the study was experiencing a great deal of physical pain, used the prototype to log when she took her various pain medications so she could manage her pain more effectively. She noted that she already used her personal calendar to reflect on these kinds of patterns, and she wanted to do the same with the mobile prototype. Other participants agreed that it would be useful to use the prototype to understand how various tracked issues (e.g., how they feel) relate to one another. They explored how to represent such patterns graphically. As a result, we incorporated graphing capabilities into HealthWeaver Mobile to enable users to explore such patterns.

Customization and cross-platform support

It was clear, even from our small groups of participants, that different people have very different needs for mobile functionality. For example, medication management was completely unnecessary for P1, but was the single most useful feature for P3. Similarly, the majority of participants found the calendaring features of the prototype essential, but P5 had an effective paper system that she did not intend to replace with any kind of electronic calendar. Further, since none of our participants had recent surgery, drain logs were not applicable to any of them. For such reasons, the participants were unanimous about the need for the mobile application to be customizable to the user’s current needs and for settings to be easily modified for changing needs.

Finally, two participants already had smartphones prior to the study, one a Blackberry and the other an iPhone. For these participants, our mobile application would be useful only if it could run on their own phones. Carrying an additional device just for health was unacceptable. As the smartphone market is divided among a number of incompatible platforms, cross-platform support is critical for broad adoption.

Redesigning HealthWeaver Mobile

Findings from the design groups raised several major design decisions. We review these implementation considerations and the reasons for our choices next.

Native vs. web application

One critical decision was whether to develop HealthWeaver Mobile as a native application or as a set of mobile optimized views of the HealthWeaver website. Each strategy presented a set of trade-offs. Native applications’ biggest advantage is their ability to access the phone’s hardware features (e.g., camera and microphone) and to integrate with other applications on the device. Both of these characteristics were critical for HealthWeaver Mobile. The ability to take photos and audio notes was highly valued by design group participants for enabling quick information capture in situations where taking text notes was burdensome or impractical (e.g., while driving). Similarly, all our participants thought that integration with the native calendar was crucial. This kind of integration could only be achieved through a native application. Downsides were that developing a native application would involve building intricate data synchronization and the need to replicate many of the features already implemented on the website. Further, it would make it extremely labor-intensive to support multiple mobile platforms, especially given the limited development resources of a research project.

Web applications present a different set of trade-offs. To their credit, mobile web applications do not require any data synchronization since they are fundamentally just web pages optimized for mobile viewing. Web applications are also cross-platform by their very nature and make securing users’ data easier because all data is stored on secure, professionally managed servers. On the downside, web applications require an Internet connection and do not provide the kind of hardware and operating system integration that is possible with a native application.

We eventually decided to combine positive aspects of both these alternatives. HealthWeaver Mobile is a native application on the Android operating system that leverages native code to enable photo and audio notes and the integration with the system calendar. For all other features, the application embeds a web browser that displays mobile optimized views of the HealthWeaver website (Figure 2). Because these web views are embedded within the native application, the interaction is virtually seamless. All application features are accessed from the same menu of modules and the user is never forced to switch context and use a separate web browser. This approach enables us to easily support other mobile platforms because developing a thin native wrapper around web functionality is quicker than developing a complete native application.

Figure 2:

Mobile optimized web view of HealthWeaver

Calendar integration

Integration with the phone’s native calendar was a high priority for our participants. However, using the native calendar presented a significant challenge. Some unique features of our system, including the much-desired ability to link calendar events to other information from the HealthWeaver website, were not available in the native calendar. We did not want to compromise on these aspects of the design.

We worked around this problem in a twofold manner. First, we used Google Calendar as an intermediary tool to synchronize events from the HealthWeaver website with the native calendar on the mobile phone. This system gave us an encrypted, real-time synchronization between HealthWeaver and all major platforms we planned to support, including Android. Also, because Android supports multiple calendar accounts, HealthWeaver events could be displayed alongside events from the user’s other calendars but not be synchronized with those other calendars, thus preserving privacy of health information.

Second, to get advanced calendaring features (e.g., linking notes to events), we customized the synchronization mechanism between the phone calendar and the HealthWeaver website. Events synchronized to the phone contain a URL for the same event on the HealthWeaver website. By tapping this URL while viewing an event in the native Android calendar, the user is taken to the HealthWeaver version of the event in the HealthWeaver Mobile application. From this view, the user can examine and edit linked notes, review linked photos, audio notes, and documents, and use all other features supported by HealthWeaver Mobile.

Customization

Finally, we addressed the need for customization through a combination of native and web features. Users are able to select which modules of the application they want to use through a settings page in the mobile application. If, for example, drain management is not needed, they can simply hide it. In addition, the web nature of much of the application means that any customizations made on the website apply to the phone as well. For example, on the HealthWeaver website users can select which symptoms and wellbeing metrics they want to track. The daily check-in module on the mobile phone automatically reflects these selections. Similarly, any medications entered on the website are automatically available in auto-complete lists on the phone, too. This feature provides both a consistent experience between the phone and the web and decreases user effort by eliminating the need for the same kinds of customizations to be done in two different places.

Conclusions

The result of our design process is a flexible mobile tool that provides patients with functionality needed to manage care-related information in unanchored settings. The current system extends the functionality of the initial prototype to include both retrieving and capturing of all information types, seamless integration with phone’s native calendar, and customization. In addition, our hybrid native-web architecture enabled us to add several features based on participant feedback. These include graphing of daily check-in metrics to support reflection on patterns, search, and four other HealthWeaver modules: (1) web bookmarks to access care-related web pages, (2) documents & files to access images, audio notes, and files stored on HealthWeaver (e.g., PDFs), (3) prescriptions for a list of current medications, and (4) collections to access information bundled by the user for a particular purpose, such as researching a treatment decision. The application also provides access to all information linked from a particular item. For example, if a note is linked to an image and an event, the user can jump to both directly from the note, making it easy to access related information quickly.

Our results should prove interesting to other researchers working on mobile health technologies. Our findings about calendar integration provide evidence that adoption of health technologies by health consumers depends on how well the technology integrates with their current practices, particularly those related to time and work management. Second, the unique native-web hybrid approach we adopted for HealthWeaver Mobile could offer a cost-effective way to provide cross-platform support in mobile health tools while maintaining robust hardware integration of native applications. In addition, using secure web servers for data storage and encryption for all connections can increase security of mobile health applications and ease integration with other systems, such as provider-hosted or third-party personal health records. Finally, the positive reaction of design group participants to our prototype suggests that there is an unmet need for tools that help individuals manage the full range of information required for effective personal health management. Such tools could greatly reduce the stress of managing demanding health conditions, leaving individuals with more time, energy, and attention to focus on getting well.