Integrating the patient portal into the health management work ecosystem: user acceptance of a novel prototype

Abstract

People with a chronic illness must manage a myriad of tasks to support their health. Online patient portals can provide vital information and support in managing health tasks through notification and reminder features. However, little is known about the efficacy of these features in managing health tasks via the portal. To elicit feedback about reminder and notification features in patient portals, we employed a patient-centered approach to design new features for managing health tasks within an existing portal tool. We tested three iteratively designed prototypes with 19 patients and caregivers. Our findings provide insights into users’ attitudes, behavior, and motivations in portal use. Design implications based on these insights include: (1) building on positive aspects of clinician relationships to enhance engagement with the portal; (2) using face-to-face visits to promote clinician collaboration in portal use; and (3) allowing customization of portal modules to support tasks based on user roles.

Introduction

Patients with chronic illness have a particularly burdensome health task workload, with effective management of chronic conditions potentially requiring thousands of discrete health tasks annually¹. Patients or caregivers managing a chronic illness must juggle often complex medication regimens, comply with routine screening and testing, and attend regular medical visits². Accordingly, patients or caregivers often monitor their health status daily and communicate relevant changes to their clinicians to maintain an appropriate treatment plan.

As part of managing these frequent, important tasks, reminders and notifications can be essential mechanisms for remembering and accomplishing chronic care tasks. In this paper, reminders encompass (electronic) prompts that were generated by the health care information system and pushed to a patient portal to engage patients and caregivers with upcoming recommended care tasks. Notifications are informational updates provided by the healthcare information system for patients or caregivers that enhance communication around health tasks. Because patients are more likely to engage with care tasks if associated reminders and notifications are relevant and actionable³, our study works to incorporate patient preferences with reminders and notifications to enhance engagement with chronic care tasks⁴,⁵,⁶,⁷.

The patient portal offers a powerful platform to customize reminders and notifications. The portal allows patients to view aspects of their electronic health record (EHR) and communicate electronically with clinicians in their health care system. These portals are information systems that could easily incorporate patient-centered approaches, particularly to take into account patient preferences, providing a means to improve illness management by promoting patients’ engagement in their care⁸,⁹ and adherence to care plans¹⁰,¹¹. Research has previously demonstrated the health management benefits from patient engagement with portals for specific populations (e.g., people with diabetes¹², teenagers¹³, and people with multiple sclerosis¹⁴). However, as observed in previous qualitative research on use of the patient portal, patients and caregivers experience common frustrations, such as difficulties in following up with clinicians¹⁵, failures in personal reminder systems¹⁶,¹⁷, and gaps in attitudes between doctors, patients, and caregivers about the use of technology in health management¹⁸.

This study focuses on management of chronic illness in particular. We recruited individuals who manage diabetes for themselves (patients), and mothers who manage asthma for a child dependent (caregivers), to study the use of portal reminder and notification features. We utilize prototype testing to explore patient and caregiver interactions with new features in an existing patient portal that are intended to improve workflow, help users to remember important health tasks, and enhance patient and caregiver engagement and agency in managing chronic illness. This paper provides insights from patients and caregivers from this portal redesign to inform design implications for patient portals. We found that patient portals can best support remembering and accomplishing chronic illness management tasks by: (1) incorporating positive aspects of the clinician relationship; (2) bridging the information worlds of the clinic visit and home-based, self-care tasks; and (3) allowing users to customize patient portal functions based on role and associated tasks.

Participants

Our population of interest consisted of current users of the existing patient portal offered by a regional health care cooperative based in Washington State, U.S.A. The portal is available for patient use and for custodial parents of children 12 and under (i.e., caregivers, who manage health information for a dependent). We chose current users of the patient portal so participants would be familiar with and understand expected functionality of the system. We invited participants from two cohorts: those who manage a chronic illness for themselves (patients with diabetes mellitus), or for at least one minor child (mothers of children with asthma). For mothers of children with asthma (n=7, average age 38.4 years) we identified and invited mothers who were the custodial parent of at least one child under the age of 12 who had an active prescription for a corticosteroid inhaler. For patients with diabetes (n=12, average age 63.4 years), we identified and invited individuals who had a diagnosis of diabetes mellitus. Each cohort received a paper prototype appropriate to their role: the diabetes cohort tested a patient-facing portal, and the asthma cohort tested a portal designed for caregivers of minor children. Detailed demographic information for each cohort is shown in Table 1.

Table 1.

Demographics of participant sample, by cohort and overall

	Diabetes n	Asthma n	Overall n	Overall n
Total	12	7	19	100
Female	5	7	12	63
Male	7	0	7	37
Average age (years)	63.4	38.4	54.2
Education
High school	1	0	1	5
Some college/AA	5	1	6	32
4-year college	1	1	2	10
>4-year college	5	5	10	53
Race
Asian	0	1	1	5
Black	0	2	2	10
Native Hawai’ian or Pacific Islander	1	1	2	10
More than one race reported	1	0	1	5
White	10	3	13	70

Methods

We tested paper prototypes¹⁹ designed specifically for the tasks included in the study. Low-fidelity paper designs represented features in the portal interface, with the study facilitator acting as a computer receiving input and simulating output. We chose such low-fidelity prototypes because participants would be less likely to think of such a prototype as “finished,” and therefore would be more likely to suggest changes. In addition, paper prototypes facilitate rapid iteration and require less “polish” to deploy when testing over short periods of time²⁰. We observed participant interactions and behavior with the new features through the prototype, and audiotaped participants using a “think aloud” protocol²¹ that gave us additional data to understand how they were thinking about system interactions. The process of our prototype development is discussed in greater detail below.

Procedures

Each session was conducted individually with a participant. We used a set of four tasks to test prototype reminder and notification features that remained consistent between prototype iterations. Test sessions were audio recorded to verify participant quotes and settle disputes between researcher notes, if necessary. To maximize reliability of data collection among participants²², we used a session checklist and a structured questionnaire, which was used at the end of the session to elicit additional, unstructured feedback after the task-based activities; we quote participant feedback from the questionnaire in the results. Individual sessions lasted between 30 and 45 minutes, facilitated by one or two research assistants. The three prototypes were tested with 19 individuals: seven participants tested the first prototype (P1), six participants tested the second prototype (P2), and six participants tested third prototype (P3). Most sessions were hosted in clinic conference rooms; however, some participants (n=3 mothers of children with asthma) preferred to participate in their own homes, in which case only one of the authors facilitated the session in their homes. We reached saturation in discovering design flaws after approximately six users, meaning we received similar feedback from multiple participants, which proved sufficient to iterate on the prototype²³. Each participant was compensated $25.

We recorded data about participant engagement with tasks in two ways. First, tasks were noted as either complete (meaning the participant followed through with the task using the prototype) or incomplete (meaning the prototype had shortcomings that prevented the participant from following through with the task). Second, we recorded other qualitative feedback from the questionnaire and think-aloud audio data to assess whether the participant accepted the task or not. Specifically, when a patient accepted the task, they made remarks that the task would be helpful or useful; when a patient rejected a task, they made remarks about why the task was inappropriate or inapplicable to them. We articulated these two dimensions to help determine (1) how tasks related to participants’ preferences (accepted/rejected tasks) and (2) when the prototype performance failed (complete/incomplete tasks). That is, it was possible for a participant to reject a task, but complete it, or to accept a task, but fail to complete it.

Description of tasks

In each session, the participant was presented with the home screen of the prototype and asked to talk about what s/he observed and which features s/he noticed, etc. From there, a researcher would move into facilitating four tasks, in the following order: The Lab Result Task, The Urgent Care Task, The Flu Shot Task, and The Custom Reminder Task. The tasks required an increasing amount of “work” as the user learned the system through interaction. The tasks were also designed to represent various levels of task familiarity and different information behaviors (e.g., retrieving, updating). See Table 2 for a detailed description of each of these task dimensions.

Table 2.

Dimensions of Four Prototype Tasks

Task	Familiarity of task*	Information behavior facilitated by task	Change to current system
Lab Result Task: Retrieve laboratory test results and message doctor to follow up with questions and concerns	High; essentially builds on existing secure messaging function	Open a thread of communication with the doctor via the portal to assess a specific issue	Reduces cognitive load in transferring information to a blank message by autocompleting text to specify issue
Urgent Care Task: Retrieve information about a prescription from an urgent care visit	High; introduces new view of existing, provided medication information	Retrieve information from the portal about medication instructions	Digitizes information retrieval about medication
Flu Shot Task: Dismiss a reminder about getting a flu shot by submitting up-to-date information from outside the system	Medium; allows participants to interact with existing flu shot reminders from portal	Add information to the medical record to dismiss a reminder from the portal	Allows patients to directly update medical record information, rather than requiring a clinician to update
Custom Reminder Task: Add custom, systemgenerated reminders for a planned clinic visit directed by the physician	Low; applies patient preferences to deploy more relevant and actionable system reminders	Add information to customize reminders issued by the portal	Empowers patients to set custom reminders for completing tasks related to personal goals

^*Tasks are deemed more familiar if they are similar to current portfolio functionality and less familiar if they introduce new or significantly revised functionality to the portal.

The Lab Result Task asked the user to look up a recent medical test result, and initiate a follow-up with their doctor to discuss. Patients have indicated in previous research¹⁵ that they did not always understand the content of test result notifications and were compelled to use secure messaging or a phone call to request further information²⁴. We refer to this patient preference as a desire to “close the loop” in communication. This task presented a common scenario with an expanded, customized feature that expedited requesting clinician commentary on a given test result, and facilitated extended “tracking” of the issue if necessary.

The Urgent Care Task presented a task as follows: verify instructions for a medication prescribed during a recent urgent care visit. For the diabetes patients, users looked up medication instructions for themselves. For the mothers, users looked up instructions on behalf of their child with asthma. Here, we are assessing patients’ acceptance of managing comprehensive medication information online (a feature that is not available on the current patient portal), as well as exploring the type of information that would be most useful to support patient and caregiver management of medication information between clinic visits. This task adds new functionality to the portal, essentially increasing the number of ways to view medical record information about medication history.

The Flu Shot Task presented a scenario where the portal presented a reminder to get a flu shot for the patient or child, but that individual had already received a flu shot outside of the health care cooperative (and therefore the medical record had missing information). The task then requested that the patient or caregiver dismiss a flu vaccination reminder in the system by inputting information about the flu shot that was already received. This task facilitated two new user abilities: dismissing reminders, and inputting or correcting information in the EHR through the patient portal.

The Custom Reminder Task asked users to add to the portal their own custom reminder that would help them to follow through on completing a task with their doctor. The task was presented as follows: your doctor told you/your child to return every six months to manage a health concern; determine when you/your child should go back to the doctor and set a reminder for yourself in the patient portal. Patients and caregivers often manage these reminders in their own calendar/notification ecosystem¹⁶, and with this task we tested participants’ acceptance of a feature that would assist them in integrating the portal system into their personal ecosystem of reminders.

In summary, the Lab Test Result and Urgent Care tasks introduced new ways to complete familiar patient portal tasks, while the Flu Shot and Custom Reminder tasks introduced new functionality and expanded participants’ abilities in the system. In the following section, we describe the prototype iterations.

Iterative stages of the prototype

We created the initial prototype designs specifically for this study based our previous qualitative research focusing on patient and caregiver management of reminders and notifications and related patient portal use¹⁵,¹⁶,¹⁷,¹⁸. Prototype design and iteration is described in more detail below. For all three prototypes, we increased the level of personalization on every screen by displaying the user’s name and photo on the home screen. For mothers of children with asthma, this personalization component also served as the method to toggle from one user to another. By selecting the mother’s picture, or the child’s picture, the user could navigate between profiles, and receive system feedback about which profile was “activated” depending on which name was displayed. Both patients and caregivers were very accepting of these touches of personalization, though opinions about uploading a picture— “like on Facebook, “ as several of our participants noted—varied quite a bit. Mothers tended to indicate they would use the pictures (“I'd love to see my kids’ faces, “ per A02), though others indicated they would prefer to use an avatar. Patients with diabetes were similarly mixed about their preference to use a picture. Because the patient/caregiver picture feature was generally well received, we retained that feature for all three prototypes. However, other features changed according to participant feedback.

Finally, although the participants interacted with paper “screens” using all three prototypes, using their fingers to complete tasks, the screens themselves were laid out digitally and were of a fairly high-fidelity layout. Feedback detailed in the below sections is from mothers of children with asthma (A# identifiers) or patients with diabetes (D# identifiers). The following sections detail the features of prototypes one through three.

Prototype 1 (P1)

We built the prototype’s functionality to facilitate completion of the tasks, allowing users to learn the system. The functionality of these prototypes was not very “deep,” but it gave us a chance to test a much simpler interface than presented by the current patient portal site. The primary features of P1 (see Figure 1 ) that differed from the current patient portal are as follows:

Figure 1.

P1 Child’s home screen placed reminders and notifications in the center of the screen

• Reminders and notifications were centered on the home screen and new items were highlighted in red;

• The menu taxonomy was simplified from the current patient portal menu options;

• The large buttons to navigate through the site were optimized for touch-screen use, rather than a desktop layout (most of our participants use their phones or tablets to interact with the current patient portal application); and

• The “Goals” feature was displayed, but not built out, to start a conversation with participants about what that portion of a portal might entail, and how it might benefit them.

The most common criticism of P1 was that the secure messaging option was now buried in other features. For example, when completing the Medication Task, the participant needed to navigate to previous test results and then select “Message my care team” to use that feature. However, both cohort’s participants indicated that secure messaging should always be one click away, on every screen, because it was a “top-level” task - i.e., a primary reason for visiting the portal in the first place. Thus, access to the secure message was prioritized in the next two prototypes.

Other feedback about the prototype praised the “simple layout,” which was contrasted against the current portal’s “busy” interface. We retained a relatively simple, touch-friendly layout in subsequent prototypes, but noted that incomplete tasks with P1 stemmed from poor navigation taxonomy. For example, “Tests and care” was too vague for participants to use efficiently. Thus, we overhauled the navigation menu in P2.

Prototype 2 (P2)

We re-organized the menu options (see Figure 2 ) to

Figure 2.

P2 Child’s home screen showed reminder and notification “pings” as numbers in red circles

respond to the criticisms of P1 that (1) secure messaging should be available at the top level of navigation and (2) that navigation taxonomy needed to use clearer categories. We also added redundant navigation to a side menu, which participants liked because it conveyed “consistency.” One other major change to P2 from P1 was changing the “push” notification indicators. The participants did not understand the list of notifications being front and center on the home screen, as it was in P1: participants preferred for less obtrusive notifications and reminders. We changed the design accordingly, appending relevant push notification indicators to corresponding menu options. Here, we used an iOS-like red number notification to draw the participant’s attention to that area, informed by participant input that they liked the notification styles of their phones and tablets. Participants regularly showed us their own devices during testing, and many used smartphones.

Criticisms of P2 stemmed mainly from the mothers’ use of the system: these participants indicated that they needed more information on the screen. Specifically, mothers stated that they frequently called the clinic while using the portal, particularly when they “hit a wall” in completing a task on the portal. For this reason, mothers wanted their child’s member number and the clinic phone number displayed on every screen. We made this change in P3.

Prototype 3 (P3)

The iteration from P2 to P3 was subtler than the previous redesign (see Figure 3 ). Most of the changes were made to accommodate mothers’ information needs and behavior, e.g., adding the health cooperative member number and clinic phone number to all screens in the patient’s profile. Another subtle change from P2 was that of using “active” language in the navigation menu to help participants understand how they would use the menu options, which had proved a shortcoming of P2. To remedy this confusion, we changed the wording of menu options to facilitate understand of the tasks supported in each of the site areas. For example, “Upcoming Care” became “Plan a Visit,” to help patients understand that they could still make appointments in the portal. “Care History” also became “View Care History,” to convey that this portion of the site served the “information archive” function that we had heard was a vital part of using the site, particularly for mothers.

Figure 3.

P3 Child’s home screen highlighted additional relevant information for caregiver tasks

Results: Task Outcomes

The following results express the outcomes by each of the tasks, which are summarized in Figure 4 . When participants accepted a task, they indicated that being able to carry out the task on the portal was useful in managing health care, and they would be likely to complete the task in the manner presented in the prototype. Sometimes, though, participants did not accept tasks, saying that they would never use the portal for the task as described, or that they preferred to use whatever current solution they had in place, rather than the portal. We had numerous instances where a participant would complete the task but not accept it. In reporting on each of the tasks below, we report on both aspects of the participant feedback to maximize the analysis of the qualitative data collected during the testing sessions. All participant feedback is attributed to asthma mothers (A# identifiers) or patients with diabetes (D# identifiers).

Figure 4.

Acceptance and completion outcomes for each of the four prototype test tasks

The Lab Results Task

The user acceptance of this task was mixed, in that most of the participants saw the value of the enhanced messaging functionality, but some were reluctant to use the new feature over other communication approaches (in person or by phone). Incomplete tasks using P1 overwhelmingly stemmed from navigation issues. This led to clearer menu options in the second and third prototypes. Participants who succeeded in completing this task using P2 and P3 reviewed the test result, and then messaged the doctor using a new feature that populated a message with a subject heading and some text. A07 stated, “I like the fact that it automatically gives you an option to message your care team based on something really specific…I usually end up copying and pasting [text]. “ This function reduces patients’ need to remember details about the test to compose (from scratch) a message to their doctor.

Incomplete task attempts in P2 and P3 resulted from the participants skipping the step to review test results and instead message the doctor their inbox in the portal. When asked about making this choice, participants stated that they mostly used the patient portal for messaging, and generally headed directly for the inbox. There, they would compose a message that would refer to the test in question, but not integrate details from the test results; instead, they would ask the doctor to interpret the result in prose in a reply. Despite incomplete attempts at the task, overall feedback from this feature was positive. Many participants said they would add some personal text to the message, to carry out the conventions of their offline relationship and to “warm up” the asynchronous communication mode.

The Urgent Care Task

Acceptance for this task was high, as many participants indicated they used the portal as an information archive (e.g., D09, who printed out archived information from the portal as needed). Patients with diabetes tended to like the medication view immediately; many of our participants managed many prescriptions, and drug interactions were a serious concern for them. These patients indicated that they would like to be able to view and edit their medications: “If it were my system, ” D05 stated, she would work to “clean up ” the medications list and make sure all of the information was accurate. Most existing research excludes patients as stakeholders to medication modules in health information technology²⁵,²⁶, but detailed research about offering medication management tools directly to patients is lacking.

Mothers indicated they preferred a digital After Visit Summary (which is a paper artifact already used in the health care cooperative system) to manage medications. To increase acceptance of this task, we built redundant navigation in the design iteration to P3. This satisfied both the participants with diabetes, who wanted a medication view, and the mothers managing asthma, who wanted contextual information around prescription medication in the form of the After Visit Summary. In sum, successful completion of this task was relatively high, with factors resulting in incomplete tasks resolved once the redesign for P3 incorporated the mothers’ preferences in navigation.

The Flu Shot Task

This task was not well accepted. Participants declined to accept the task based on their rejection of the flu shot as an important task (e.g., one participant, D07, refused one every year as a matter of course; “[the nurse] made a note of it that I didn’t want one and so they don’t do that…I just ignore [flu vaccine reminders]”). In P1, most incomplete tasks resulted from navigation errors. In general, we found, participants had a hard time figuring out where flu shots – or vaccinations in general – “fit” in the patient portal relative to other types of care.

P2’s design was much more successful, due to improved menu options, although most of the participants rejected the task itself, primarily due to rejection of the flu shot in general (as stated above) or an established habit of messaging with the care team to update information on the patient or caregiver’s behalf. In the last case, two of the six participants pointedly refused to add information directly to the medical record, and elected instead to message the doctor directly.

Participants in P3 who did not complete the task overwhelmingly opted to message with their doctor, rather than update flu shot information or dismiss the reminder. Participants stated a preference to have clinic staff update medical record information on their behalf. The primary takeaway is that participants did not necessarily make the connection between having updated medical information at hand and inputting that information into their record, and in fact saw the direct input of information as a “bypass” of the official information channel (clinic staff).

The Custom Reminder Task

This task was different from the first three for two reasons: (1) the functionality the system presented in completing the task was new and more unfamiliar to the participants than the first three tasks and (2) patients have existing— and sometimes complex—personal reminder systems, that they might be reluctant to integrate with what they view as an outside system. In the test of P1, most of the incomplete tasks were navigation-related. In P2, participants were more enthusiastic about using the design and chose to send themselves redundant reminders over multiple communication approaches (e-mail and text) to assist in remembering future care tasks. The results in P3 were similar to P2, with the exception that the diabetes patients testing P3 stated they would not use such a feature because they had frequent phone contact with a diabetes nurse from their clinic, and did not require extra reminders.

In the following section, we discuss themes identified from the qualitative data gathered during the testing sessions, and list design implications for patient-centered interventions in patient- and caregiver-facing health information systems.

Discussion: Themes in Participant Feedback

The information we elicited from prototype testing not only assisted us in iterating on the portal feature prototypes, but also provided rich qualitative data around the attitudes, beliefs, and behaviors of patients and caregivers as they integrate the use of the portal tool into their day-to-day health management routines. Lim et al.²⁷ describe prototypes as “a tangible attempt to view a design’s future impact so that we can predict and evaluate certain effects before we unleash it on the world. ” The authors go on to outline two purposes for prototyping with users: (1) exploring possible design decisions to manifest iterative simplifications toward a finalized design, and (2) to help designers determine what design dimensions are relevant or irrelevant. Our use of paper prototypes focused primarily on the latter purpose. Below, we elaborate on observed themes during participant interactions with the prototypes.

The clinician relationship affected portal use

Sometimes, tasks didn’t resonate with participants due to their strategies for maintaining (or avoiding) communication with clinicians they liked or disliked. D05 stated, “If you have a good relationship with your doctor you can work out goals that are reasonable. “ For example, patients who had frequent communication with their doctors (these participants tended to describe their diabetes as “not well-controlled”) trusted their doctors to explain test results in each notification. D10 described using secure messaging: “Even if I ask maybe a dumb question [via secure message], [my doctor] answers it still. He’s very understanding. ”

On the other end of the clinician-patient relationship spectrum, one mother (A04) had had a particularly poor experience with her doctors and care team. For this reason, she stated she would never attempt to message about a test result. Instead, she preferred to use an Internet search (“I would Google something like, ‘when do I start worrying about…’”) to educate herself about the test, rather than initiate an exchange with her doctor over the portal. Previous research upholds the influence of clinician-patient relationships on the use of communication systems²⁸.

Design implications for the patient portal related to this finding call for patient portal features that can amplify the positive aspects of the patient-clinician or caregiver-clinician relationship. Portal features that could potentially benefit patients who like their doctors and/or care teams potentially include: clinician pictures accompanying secure messages, to put a face to the words in secure messages; or a dedicated resource on the portal to view individual clinician or care team profiles. To accommodate those users with varying levels of rapport with their clinicians, the patient portal could incorporate user preferences to these suggested features (i.e., a caregiver with a poor relationship with clinicians could choose to hide or de-prioritize the care team profiles).

Context of portal use differed between cohorts

Although it is easy to assume that participants with diabetes were not technologically savvy because they were older than the mothers of children with asthma, many participants in the diabetes cohort used touch screen devices to use the existing patient portal. One participant (D10) indicated that she “liked to explore” new websites. However, some participants were particularly security conscious: “Security and whatnot… I keep no passwords on my phone whatsoever” (D08). At least one participant in the diabetes cohort used a third-party application for managing medications and remembering dosages and timing (D03).

This participant, and many of the diabetes cohort participants, proudly demonstrated use of personal devices during the course of the testing session, which we found to be helpful information, rather than a consequence of topic drift²⁹. Most participants in the diabetes cohort were eager to interact with a redesigned patient portal. We found that although the patient portal can incorporate health tasks more easily, and many patients use the technology perfectly well, it might not be the patient’s preference to do so, due to factors surrounding use. Health literacy, digital literacy, and tool use have a complicated relationship in this sense, as supported by previous research¹⁸,³⁰,³¹ .

Mothers managing asthma on behalf of a child indicated they were busy and totally focused on the child, often prioritizing their children’s health needs over their own health tasks. Diabetes patients, however, tended to be older, and many had retired. These patients were most focused on their own health, and had numerous points of contact with the medical system (pharmacy, laboratory for regular blood tests, nurses, and often multiple physicians managing comorbid conditions accompanying diabetes). While mothers needed to plan ahead for clinic visits, diabetes patients expressed contentment with the social aspects of completing health tasks at the clinic. D12 stated, “I'm more the old school and I'll call people up on the health team… primarily I find it works better based on my upbringing. ”

Patients also felt as though they do not have a relevant ownership stake in portal information, or essentially that the doctor or other clinical staff is “in charge” of that information. Thus, as a consequence of the use context, patient portal use is subject to the power dynamics of the traditional doctor/patient dyad³². It is important to recognize that this clinician/patient or clinician/caregiver collaborative stance will probably not be fostered solely through the patient portal approach, but instead requires integration of multiple approaches to encourage patient portal use to benefit both patient or caregiver, and the clinician³³,³⁴.

The most enlightening of our findings with regard to context of use was that participants tended to trust their existing reminder systems, and expressed wariness about integrating yet another tool (e.g., the portal) into these systems. Here, we suggest, the design implication for patient portals may be offering a function that assists clinicians in encouraging patients to investigate the patient portal, to bridge the information worlds of the clinic and the home. For example, at the close of a clinic visit, a clinician could suggest that the patient use the portal to track visit follow-up tasks. At this point in the face-to-face visit, if the clinician had access to a module in the EMR to walk a patient or caregiver through portal reminder and notification features, this may prompt the user to re-engage at home.

Using such a module, the clinician could offer to set up a recurring reminder through the portal for the patient to engage with a follow-up task. By offering a visible demonstration of collaboration with a clinician (e.g., a medical assistant) during an in-person encounter, the patient or caregiver may be better able to see the relevance of portal functionality in managing care tasks, and therefore more willing to integrate the portal into their existing reminder ecosystems.

Workflows depended on role and illness managed

Our participants were not all simply “patients” or “caregivers.” Mothers were, of course, patients themselves and could use the portals for their own health needs. In some cases, diabetes patients were also caregivers themselves. One participant (D09) looked after her parents, in their 80’s, and did not drive. Most of her electronic calendar was used to track their appointments, and she often neglected herself to look after them: “[Taking care of them] makes me less conscientious about myself, because I'm so focused on making sure they ‘re taken care of. I feel like a mom. ”

In contrasting workflows among users in different roles, it seems insufficient to simply modify the patient portal for caregiver use, although this is the prevailing model for offering custodial parents access to a child’s portal. Design implications of this finding might entail offering a level of customization to the patient portal. For example, users could select frequently used “modules” to highlight on the front page of the portal. Diabetes patients might prioritize modules for (1) alerts about standing orders for blood tests coming up, to keep the patient on schedule; and (2) medications management view. A caregiver of a child with asthma may prioritize (1) the asthma management plan assigned by the doctor, which assigns medication instructions to control asthma symptoms; and (2) archived information, such as summaries of emergency room visits, that the patient could easily share with the doctor to follow up with emergent asthma attacks. Allowing all users to prioritize functions of the patient portal that they use most would maximize flexibility of the patient portal.

Limitations

This research was conducted with patients in a single regional health-care system, with participants who had familiarity with the use of patient portal technology. We suggest future work related to patient portal redesign or implementation should incorporate contextual and social aspects of in situ tool use³⁵, which our lab-based paper prototype testing did not include.

Conclusion

Health management tasks are particularly important and time-consuming for patients and caregivers who are managing a chronic illness. To support these tasks, we designed and tested three prototypes for a new patient portal that incorporates patient-centered reminders and notifications. The information we elicited from prototype testing with our participants helped us to identify participant attitudes, beliefs, and behavior that affect design dimensions for patient-centered reminders and notifications to manage health tasks. First, patient portal design should incorporate features to amplify positive aspects of the clinician relationship, which will benefit those users who feel a personal connection at the clinic and can carry over to the feelings of responsibility and accomplishment related to small, everyday tasks. Second, clinicians should be provided with an easy way to gauge interest in portal use, and encourage patients and caregivers to use the portal to bridge the information worlds of the clinic and the home, where many complicated care tasks occur. Finally, customization of the patient portal modules can provide a flexible platform that supports the roles of both patients and caregivers, offering better solutions for both. These design implications contribute evidence-based insight as to the needs of patient and caregiver stakeholders in patient portal tools. This study gives rich user feedback to inform design opportunities in patient portal systems that can effectively support the sometimes overwhelming tasks of patients and caregivers who manage chronic illness every day.