A patient-centered system in a provider-centered world: challenges of incorporating post-discharge wound data into practice

Abstract

Objective The proposed Meaningful Use Stage 3 recommendations require healthcare providers to accept patient-generated health data (PGHD) by 2017. Yet, we know little about the tensions that arise in supporting the needs of both patients and providers in this context. We sought to examine these tensions when designing a novel, patient-centered technology – mobile Post-Operative Wound Evaluator (mPOWEr) – that uses PGHD for post-discharge surgical wound monitoring.

Materials and Methods As part of the iterative design process of mPOWEr, we conducted semistructured interviews and think-aloud sessions using mockups with surgical patients and providers. We asked participants how mPOWEr could enhance the current post-discharge process for surgical patients, then used grounded theory to develop themes related to conflicts and agreements between patients and providers.

Results We identified four areas of agreement: providing contextual metadata, accessible and actionable data presentation, building on existing sociotechnical systems, and process transparency. We identified six areas of conflict, with patients preferring: more flexibility in data input, frequent data transfer, text-based communication, patient input in provider response prioritization, timely and reliable provider responses, and definitive diagnoses.

Discussion We present design implications and potential solutions to the identified conflicts for each theme, illustrated using our work on mPOWEr. Our experience highlights the importance of bringing a variety of stakeholders, including patients, into the design process for PGHD applications.

Conclusion We have identified critical barriers to integrating PGHD into clinical care and describe design implications to help address these barriers. Our work informs future efforts to ensure the smooth integration of essential PGHD into clinical practice.

BACKGROUND AND SIGNIFICANCE

Patient-Generated Health Data … Coming to an EHR Near You

Patients have always shared health data with their providers, but the means and scale of sharing these data are changing as rapidly as the technology to acquire and transmit novel types of data.^1,2 Although patient-reported data has traditionally lived in the “subjective” section of provider notes, this new type of data is often more granular and more accurate than the patient history elicited by providers during clinic visits.^3,4 Critically, providers participating in Meaningful Use could be obliged to integrate patient-generated health data (PGHD) from at least 15% of their patients into their electronic health record (EHR) by 2017.^5–9

Healthcare is changing as patients become more autonomous and want their providers to value their data as an “integral part of ensuring that providers and patients have adequate information to partner in making clinical care decisions.”^8,10,11 However, providers often do not know how to store, interpret, or act upon this heterogeneous data and have concerns about its potential impact on their time and workflows.¹² Yet, providers recognize that PGHD can improve patients’ self-management of health and engagement between visits, potentially improving clinical outcomes and patient satisfaction – measures for which providers are increasingly held accountable.^13–16

In this context, careful consideration must be paid to the new challenges that emerge when designing patient-centered systems with stakeholders whose goals and expectations might not be aligned – eg, patients and providers.¹² Increasingly tech-savvy patients^17,18 expect healthcare, like every other aspect of their life, to “Uberize”¹⁹ – eg, be accessible via smartphone, user-friendly, on-demand, and transparent. Yet, healthcare has long lagged behind in delivering this experience, even as other industries (eg, banking) have overcome comparable security and privacy concerns.¹³

Herein, we share our experiences with engaging patients and providers to examine stakeholder tensions in the design of mobile Post-Operative Wound Evaluator (mPOWEr), a clinically integrated application that utilizes PGHD for monitoring post-discharge surgical site infection (SSI).

Significance of Surgical Site Infection

SSI is a common occurrence after surgery, affecting at least 500 000 patients per year.²⁰ Due to shorter hospital stays, most SSIs now manifest at home, after hospital discharge.^21,22 Patients often lack knowledge and awareness of SSI and are frequently unable to recognize when an infection develops.^23,24

More than half of the patients who develop post-discharge SSI are readmitted to the hospital, making SSI the overall costliest healthcare-associated infection.^21,25,26 At least a third of these readmissions are considered preventable.²⁷ In both post-acute and chronic care settings, patients are taking on greater responsibility for self-management of their health, yet do not have the right tools to support this effort, impacting costs, quality of life, and outcomes.^23,24,28

Study Context

We chose to focus on post-discharge SSI monitoring because patients and providers both perceive a need for such monitoring and, in many cases, are already using ad hoc systems to capture PGHD – eg, e-mailed wound photos and symptom reports given via telephone. Both stakeholder groups perceive there to be an opportunity for a mobile health application to address concerns with current ad hoc practices, help patients transition home from the hospital, improve patient-provider communication, and identify surgical complications earlier.^29,30 However, this post-acute care setting poses special challenges, because its workflows (eg, triage) exemplify the provider-centric nature of most healthcare systems.

In this paper, we describe the conflicts and agreements that we encountered in the course of designing a patient-centered data collection tool in a provider-centric healthcare setting. We suggest design implications as well as our own solutions from mPOWEr to guide others in integrating PGHD into clinical settings.

MATERIALS AND METHODS

Context and Overall Design Process

We employed an iterative, human-centered process^31,32 to design mPOWEr, a platform for patients to track symptoms of infection after surgery, monitor incisions with photos, and (optionally) communicate with providers. mPOWEr consists of a patient-facing, HTML5 mobile-optimized web-application and a provider-facing web-based dashboard (Figure 1).

Figure 1:

mPOWEr. Left: Patient-facing HTML5 mobile-optimized web-application enables patients to capture and share structured surgical site infection (SSI) signs/symptoms and wound photographs. Right: Provider-facing web-based dashboard allows providers to triage and manage patients and the patient-generated health data (PGHD) they share.

Our multidisciplinary research team consists of providers, health informaticists, interaction designers, computer scientists, and a dedicated patient advisor who previously experienced a post-discharge SSI. The patient advisor represents the patients’ perspective at weekly team meetings and is involved in all aspects of our work, including study design, data analysis, technology development, and manuscript preparation.

Throughout our design process, we engaged diverse stakeholder groups, using a range of human-centered design methods, which are depicted in Figure 2. Briefly, we conducted a needs assessment with surgical patients and providers, which informed our initial prototype, followed by a heuristic evaluation and a further round of interviews and think-aloud sessions with both groups. Finally, we conducted formal usability testing (ongoing) to further refine the design in anticipation of a pilot implementation study.

Figure 2:

The overall, human-centered design process for mPOWEr, with emphasis on the steps (dashed boxes) that contributed substantially to the results reported herein. Person figures (green) denote the patients we engaged, person figures with stethoscope (blue) denote the providers we engaged, and the gear symbol denotes the methods we applied. Boxes with arrows feeding into the “mPOWEr design” represent the components of our process, including the needs assessment, usability inspection, design refinement, and usability testing (left), as well as frequent input from patient and provider team advisors (bottom left) and a prospective survey of the peri-/post-discharge experiences of surgical patients (bottom right). Full color version available online.

This paper is informed by our entire design process but derives most immediately from a contrasting set of similarly structured needs assessment and design refinement interviews with surgical patients and providers, described in detail below (and highlighted by red dashed boxes in Figure 2).

Participants and Setting

We recruited study participants from two stakeholder groups – patients and providers – and conducted interviews with these participants. All participants were associated with one or both of two University of Washington (UW)-affiliated hospitals: a tertiary academic medical center and a county-owned level one trauma center. The study was approved by the UW Institutional Review Board and written consent was obtained from all participants prior to undergoing study procedures.

The first group of patients were interviewed as part of our initial needs assessment. This group consisted of a prospective, consecutive sample of all patients known to have recently experienced post-discharge SSI over a 3-month period (“patient with infection” – PI, n = 13). These patients were recruited at two UW general surgery clinics through direct approach by clinic nurses and waiting-room fliers. Four additional patients were eligible but declined participation due to time constraints (n = 2) or psychiatric illness (n = 2). Providers were surveyed through an anonymous web-based survey, the results of which are described elsewhere.²⁹

The second group of patients and providers were interviewed as part of the design refinement. This group of patients were patient advocates (PAs) who had previously volunteered to advise the hospital on matters affecting patients (PA, n = 6). Patient advisors were recruited via e-mail using convenience sampling from a pre-existing UW surgical patient advisory panel.³³ Providers were identified based on their affiliation with general surgery clinics and having experience routinely managing post-discharge infections (“provider” – S, n = 11). Providers were purposively sampled by role, to ensure representation of MDs, nurse practitioners/physician assistants (ARNP/PAs), and registered nurses (RNs), and were recruited through e-mail. Physician providers may have previously participated in the anonymous needs assessment survey, mentioned above.

Data Collection

The first author (P.C.S.) conducted a one-on-one, semistructured interview with each participant, lasting 45–90 min, as previously described.^30,34 Interview guides can be found online as Supplementary Data. These interviews served as both a needs assessment and a vehicle for feedback on the design of mPOWEr. Because mPOWEr is in an early stage of development, the study participants did not interact with the fully functional mPOWEr application; instead, they used interactive mockups to simulate use of the application. Interviews were recorded and professionally transcribed, and consisted of three parts:

1. We used the critical incident technique³⁵ to guide participants in recounting their most recent experience of managing a post-discharge surgical concern (eg, SSI), including the strengths and weaknesses of that process.

2. We employed a think-aloud approach³⁶ using mockups of the patient-facing application (for PI and PA participants) and provider-facing dashboard (for S participants). While walking through the mPOWEr application, participants were prompted with open-ended questions (eg, “how would you use this feature?”; “how would this feature impact your workflow?”).

3. We used surveys to collect demographics (for all participants) and practice characteristics (for S participants).

Data Analysis

Our data analysis process had three main steps. First, we conducted a qualitative analysis using grounded theory,³⁷ ie, without a predetermined coding scheme. Our process was iterative, using open coding to identify emergent themes in an inductive manner. Initial interview transcripts were coded independently by four team members and discussed collectively, to develop a consensus codebook, which was further refined as additional interviews were analyzed. All remaining transcripts were coded by the first author (P.C.S.) and half of the transcripts were also coded by at least one other coder. Of the four team members involved in coding, three are academic researchers and/or clinicians and one is a patient who has previously experienced post-discharge wound infection. Additionally, three have PhD- or MS-level training in qualitative methods. We accrued participants until thematic saturation³⁷ was achieved (ie, no new themes were identified). The results of this step were two tables of major themes: one for patients and one for providers.

Second, through multiple team discussions about the two tables referenced above, all of the authors (ie, not just those who coded the interviews) collectively identified 18 themes that were shared (either in agreement or conflict) between patients and providers. Through this process, we eliminated many themes that were specific to only patients or only providers. We chose to narrow our scope in this way both to focus our study and to test the underlying hypothesis that the most challenging and persistent obstacles to adoption of PGHD-gathering tools will be related to tensions between needs of patients and providers. The first author subsequently “selectively coded” all of the interview transcripts in greater depth, to look for related subthemes to the 18 previously identified major themes, and condensed related themes as appropriate. The final 10 themes were selected by team consensus to represent the most challenging and/or generalizable issues we faced in our own PGHD application design process. These themes were then grouped according to Shapiro et al.’s framework,³⁸ which provided a helpful way to organize our results, but did not inform our underlying coding or analysis.

Third, for each of the final 10 themes, we created corresponding design implications and recommendations (see the Discussion section). This process was undertaken over months of weekly interdisciplinary team meetings that included providers, a patient advisor, and technical/programming staff. We began by prioritizing each groups’ design requirements with respect to both technical feasibility and acceptability to other stakeholders, to create a development “roadmap.” Design requirements with significant agreement and ease of technical implementation were prioritized first, followed by requirements with reasonable compromise solutions and ease of technical implementation, and, finally, requirements with significant conflict (perceived to be “deal breakers”) and/or technically challenging features. We used this pragmatic approach with the notion that it is easier to get initial buy-in from users with a simpler system and gradually increase the complexity and potential for patient-provider tensions once the system has been adopted into clinical practice. The resulting design recommendations are based on team reflections and discussions in the context of the ongoing clinical implementation of mPOWEr at our institution.

We used the qualitative data analysis software Atlas.ti (Version 7) to support our analysis. We calculated descriptive statistics from surveys using Microsoft Excel.

RESULTS

Participant characteristics (both patients and providers) are shown in Table 1. Supplementary Data provides background on current post-discharge care practices, specifically problems with current post-surgical discharge follow-up and patient/provider experiences with e-mailing wound photos.

Table 1:

Participant Characteristics

Patient characteristics	Patients with infection (PI)	Patient advocates (PA)	Provider characteristics	Providers (S)
N	13	6	N	11
Age, mean (range)	45 (21–71)	58 (33–76)	Years in practice, mean (range)	7.4 (2–16)
Gender, female, n (%)	9 (69)	2 (33)	Gender, female, n (%)	7 (64)
Race/ethnicity, n (%)			Role, n (%)
American Indian	1 (8)	0 (0)	Attending physician	4 (36)
Asian	2 (15)	0 (0)	Resident	1 (9)
Hispanic	0 (0)	1 (17)	Nurse practitioner	3 (27)
White	9 (69)	5 (83)	Physician assistant	1 (9)
Other	1 (8)	0 (0)	Clinic nurse	2 (18)
Education, n (%)			Post-op patients seen per month, mean (range)	73 (2–200)
Less than high school	1 (8)	0 (0)
High school graduate	1 (8)	1 (17)	Patients with SSI seen per month, mean (range)	6.1 (1–20)
Some college	6 (46)	0 (0)
College graduate	5 (38)	2 (33)
Post-graduate	0 (0)	3 (50)

SSI, surgical site infection.

We identified 10 themes related to stakeholder tensions in the design and implementation of mPOWEr. Following Shapiro et al.’s PGHD framework,³⁸ we grouped themes into four major categories: data capture, data transfer, review/documentation, and overall process (Figure 3). Below, we name each theme and indicate whether there was primarily agreement or conflict between patient and provider stakeholders about that theme. Supplementary Data contains additional illustrative quotations from patients and providers regarding each theme. Supplementary Data contains additional themes that were specific to either patients or providers.

Figure 3:

Themes organized by Shapiro et al.'s model of PGHD flow.³⁸ Themes 1, 5, 8, and 9 (green) are areas of agreement between patients and providers, and themes 2–4, 6, 7, and 10 (red) are areas of conflict between patients and providers. Full color version available online.

Data Capture

The following themes, regarding contextual information/metadata and the flexibility of data input, relate to the nature of data created by patients or their designees.

1. Provide Context and “Metadata” to Supplement PGHD (Agreement)

Both stakeholder groups agreed that putting “objective” patient data into context, as with current “analog” processes, was important, to make sure providers can “get the full picture” (S5), eg, when patients provide ambiguous data. Despite their preference for constraining patient input (see Theme 2, regarding flexibility of data input), providers were eager to collect response-level metadata (such as ambiguity and variability) and patient-level contextual metadata (such as reliability and anxious tendency) to use when making care decisions. For example, knowing that a patient has a “pattern [of] unreliability [eg, no-shows]… I'd probably set [that patient] up [with routine wound monitoring with mPOWEr]” (S7). Patients agreed, and were eager for clinicians to have “all my history and all the data” (PA10), including their contextual metadata – such as their confidence in answers and their level of anxiety. Providers also reported assessing other providers’ confidence, eg, when consulting with other physicians.

2. Patients Want Flexibility of Input, Providers Do Not (Conflict)

Most providers wanted patient data to be limited in quantity and type, ie, “a fixed menu so that they're not free typing in there” (S8). Patients, however, voiced concern about constraints on data input – fearing that they would be faced with “forced choices, no choice for the option that should probably be offered to me” (PA5). Patients often “had other things to say” (PI12) than what is offered on medical forms. Clinic nurses, as opposed to higher-level providers, were more supportive of including a small free-text box for the patient to give “a quick overview of what’s going on” (S10), to help set the care agenda.

Data Transfer

The following themes (both reflecting a conflict between patients and providers) relate to the communication of data between patients and providers, specifically the frequency or trigger for data transfer, as well as the mode of that communication.

3. Patients Prefer Routine Use, Providers Prefer “As Necessary” Use (Conflict)

Patients and providers disagreed over how frequently PGHD should be collected and transmitted to providers, and about the benefits and drawbacks of routine monitoring. In our previous work,³⁰ about a third of patients wanted to use the PGHD tool routinely in the absence of a particular concern, to “bring peace and comfort … that their doctor is looking at [their wound]” (PA4). However, providers preferred to have only their “high risk [patients] use it routinely” (S4), to reduce staffing needs, “information overload” (S1), and their liability for missed diagnoses.

Both groups were concerned that, for many patients, tracking their wound “might increase anxiety” (PA8), and some providers were hesitant to enroll their “super anxious” (S4) patients in monitoring. Providers expressed a desire for an objective “risk score” (S11) to help decide at discharge which patients to enroll and how frequently they should monitor their wound. However, once patients developed a true wound concern, both groups foresaw continued use to “keep an eye on how things are going” (S7) to be beneficial.

Providers were more open to routine use of a wound monitoring tool if the system was “integrated into what we're already currently using [the EHR]… But if it's going to be another application that I've got to monitor, then no, I want it to be on an as-needed basis.” (S10). See also Theme 8, related to building on existing sociotechnical systems.

4. Patients Like Electronic Messaging and (Mistakenly) Think Providers Do Too (Conflict)

For nonurgent concerns, patients expressed a preference for electronic communication (eg, e-mail, texting, EHR messaging), because it is easier (“with a smartphone by the bed” – PA7), more direct, and can be saved for future reference, which is especially important for patients who are “post-surgery, loopy on meds” (PA7). Patients also perceived text-based communication methods to be preferable to providers – a way to not “interrupt them if they’re in the middle of something” (PA4), ie, letting providers respond when it is convenient for them. However, for urgent concerns, most patients still preferred telephone or in-person conversations.

However, many providers felt that texting, even securely, is “totally disruptive … I don't want that kind of access with patients” (S4). Other providers had concerns about texting being “too casual” (PA2), “informal [but] part of their medical record” (S2), and about texting giving patients the expectation of real-time communication when it might not be. Providers wanted patients to have “realistic expectations of how available I am to them” (S11). Both patients and providers also wondered whether texting could match the “immediate gratification [and] making a connection” (S5) from speaking with a provider on the telephone. One positive of text-based communication for providers was the potential for saving time on documentation: one physician noted that texting represents “a whole different ball game … I don't have to repeat everything” (S10). On the other hand, providers were resistant to using an unintegrated communication system, because “everything we do is all in Epic Care [the EHR]” (S10).

Overall, providers thought that communication preferences were a “provider-specific thing” (S2) but had concerns about security, workflow disruption, inefficiency, miscommunication, informality, and exposure of personal contact information that might result from using electronic messaging.

Review/Documentation

The following themes relate to how providers review and respond to incoming PGHD, including the topics of data presentation, patient prioritization, and provider responsibility for timely follow-up.

5. Present Simple, Actionable Data in an Accessible Way (Agreement)

Both groups wanted the application interface to be “simple, obvious” (PA8), “quick, easy, and better than what we have now” (S9). Patients and providers both want “at a glance” (S6) data that has already been condensed or interpreted into actionable information, eg, that “[I can use] to make decisions based on” (S1). Both worried that “repeated assessment … may [yield] too much information” (S1) to easily understand. Alongside PGHD, providers also wanted to have summarized contextual information, eg, “how complicated this patient is” (S6) that could be pulled from the EHR (see Theme 8, on existing sociotechnical systems). Both groups were interested in trends and summary measures, eg, “It’s green or it’s yellow or it’s red … things are getting better or worse” (PA10), “It all boils down to is it getting better or is it the same?” (S1).

Despite this shared preference for highly summarized data, both groups were skeptical of automated decision support, with the exception of “worst-case scenarios” (PA6), when patients could be in immediate danger. Despite the potential for broader use of PGHD to save time, both groups worried about basing automatic recommendations on subjective symptoms, and providers were concerned about their liability for unreviewed data.

Both groups wanted the data system to be accessible on any device, both to ensure a timely response from attending surgeons who are “down in surgery” and do not “have [EHR messages] on [their] phone” (S10) and to provide accessibility for recovering patients with a “smartphone by the bed” (PA7).

6. Prioritization and Response Times (Conflict)

Patients and providers disagreed about how patients should be prioritized and how quickly providers should respond to patient messages. Although both groups thought that patients should be prioritized based primarily on providers’ judgment, patients saw a greater role for their own level of concern. Some providers were dismissive of patients’ concerns (“some patients are overly concerned about everything” – S1), while others valued it highly (“the more concerned they are, the more concern I feel” – S5).

Most providers wanted to assess the level of patients’ concern as part of data collection; however, they did not want to imply that a high level patient concern would necessarily lead to a quick response. Both agreed, in principle, that patients judged to be higher priority should receive quicker review and further communication as necessary, and that provider response times should ideally be based on consideration of the patient’s next step, ie, to give them “enough time that they could get to the clinic if they needed to” (S5), to avoid a scenario in which, while the patient is waiting for a response, their condition is “getting worse and the next morning [they’ve] got a 102 fever” (PI8).

But, in practice, providers did not want to guarantee a response time quicker than 24 h (the institutional default), while patients felt a 1- to 4-h response time was needed when they were particularly concerned, “Because sometimes you're just sitting there waiting … and it’s like God, what am I supposed to do?” (PI10). Patients wanted to have a good estimate of a provider’s response time, and some even wanted to have direct or indirect input into that determination.

7. Power, Responsibility, and Reliability (Conflict)

Providers worried that giving patients too much say to patients may “take [away] the ability for us to manage this triage process” (S5), causing other patients or provider responsibilities to suffer. Although providers thought that giving patients more control over their care would be “great for patient satisfaction” (S5), providers were concerned about patients’ “unrealistic expectations” (S1) about provider workflow. Fundamentally, providers see a “total information asymmetry” (S1) between themselves and patients, with their job being to use their clinical judgment to determine “whether or not it’s a true problem” (S11). In most cases, patients are willing to let providers “use their best judgment” (PA7), provided they trust the reliability of the triage process and are kept informed (see also Theme 9, regarding process transparency).

Patients felt that after, communicating their PGHD, the next step “is in the hands of the physicians, the provider system. I’ve done what you’ve told me to do” (PA5), leaving responsibility “on the provider” (PA4). Once they have sent in their data, patients want providers to take responsibility for reliably reviewing that data, making an assessment, and guiding patients to care in a timely way. Yet, providers want the burden to continue to remain on patients, eg, “You should have some sort of disclaimer … if you do not hear back … please go to the emergency room” (S9). Patients had low expectations for improvement of provider response times: “knowing how the system works now, I don’t think [I’d get a timely response even if it was needed]” (PA8).

Overall Process

The following themes relate to the overall process of handling PGHD, namely, building on existing sociotechnical systems, providing transparency throughout the process, and considering misalignment of patient and provider goals.

8. Build on Existing Sociotechnical Systems (Agreement)

Patients and providers agreed that enhancing existing team-based workflows – as well as associated health information technology (HIT) systems and processes – was critical. As a case in point, both groups quickly identified a significant workflow challenge: “‘Who’s responsible for [monitoring] it’ [PGHD] is the biggest question” (S7). Broad consensus was that existing clinic nurses who currently handle patient calls are “the natural person to do the screening” (S1), because these nurses are accustomed to such a role and have “procedure-specific, specialty-specific knowledge” (S1). There should be a “dedicated nurse or team [but] they’re overworked as it is” (S7). Nurses expressed a preference to “touch base [frequently] with the patient” (S10), both before and after their discharge, to maintain rapport and identify potential post-discharge difficulties early. Patients like interacting with the clinic nurse because they often already have a rapport with that nurse and trust that the nurse “knows my case” (PI12), providing care continuity.

Reflecting current team-based workflows, surgeons wanted “tiers of people [nurses/residents]” (S6) screening patients, so they do not “get alerted when I'm doing a case for something that's not real” (S2). Providers considered efficiently facilitating within-team communication and consultation to be a key element of mPOWEr.

Just as both groups wanted to build on existing care team hierarchies, they also wanted to build on existing technical systems. Both groups agreed that existing communication systems were fragmented and “roundabout” (PI6), and did not want to add “another layer” (S4) of complexity. Providers stressed that “playing within the same system” (S4) to “streamline the triage process” (S8), supplementing the existing system with richer data, was critical.

Providers stressed that mPOWEr should either be accessed within or synchronized with existing EHRs, otherwise “it might create more complexity than it was helping” address (S8) or would not be monitored regularly (“I can’t remember to check that” – S11). Integrating mPOWEr with EHRs would allow appropriate and efficient documentation (“The information’s already there so why not use it?” – S1); auto-population of the dashboard (otherwise, “who’s inputting all this information?” – S11); reduce the “risk of misinformation [that] might be greater than the actual benefit of having that information come up” (S4); facilitate “quickly look[ing] at background information, [like] op-notes” (S6); and generally centralize provider workflows, which “always go through Epic [the EHR] anyways” (S8). Integration could also make more frequent data submissions feasible (see Theme 3, regarding routine vs “as necessary” use).

9. Process Transparency Allows Better Decision Making (Agreement)

In different ways, both patients and providers wanted the system to be transparent. For example, patients have experienced “frustration … think[ing] they’re talking [e-mailing] directly to their doctor, but they’re not” (S11). Patients wanted to “see a log, has the doctor looked at [my wound photos]?” (PI4), making it clear when their data have been reviewed and/or acted upon and by whom. Providers wanted similar functionality, to see if other providers have reviewed their consult, because “it leaves us [nurses] responsible until they have” (S11).

With better knowledge of the care process, patients and providers could both make better decisions about next steps. For example, both groups mostly agreed that communicating “Some kind of a [response] timeline” (PI6) or “commitment” (S4) to patients was important, even if it was “too long,” so that patients could seek further care with less uncertainty. Patients imagined being less anxious and more willing to give providers leeway in terms of their response times if they could see their data was under review (see also Theme 7, about reliability). Clinic nurses currently try to be transparent with patients, to help set reasonable expectations: “I try to explain in simple terms that I’m going to prioritize who I'm calling [back]…  people with infection concerns [are high priority]” (S11).

10. Provider Goal for Data Collection Is Triage, Patient Goal for Data Collection Is Diagnosis (Conflict)

Mirroring their current practice, providers stressed that their goal for using mPOWEr, at least initially, would be triage, not diagnosis, ie, mPOWEr would help providers screen patients to determine which ones needed come into the clinic (or emergency department) for definitive management. Providers shied away from diagnosing patients using only the PGHD transmitted to them, due to concerns about accuracy (especially false negatives) and that definitive diagnosis “would take a lot of time … [and is] not feasible … for every patient that calls.” (S1); in addition, diagnosing patients in this way is “not built into our day” (S4), in terms of time or reimbursement. In contrast, patients expect that providing more data will lead to more definitive determinations, eg, “you could save a visit or they could see right away, you better come in” (PA9).

Both groups saw potential for better triage/efficiency, ie, earlier identification of problems and preventing unnecessary visits, but many providers had concerns about both under-triage (fewer visits could compromise care quality) and over-triage, because patients “would have more triggers to call. One concern is do we end up intervening on more patients than we should” (S5). Patients tended to see only the upside of using the data collection tool.

DISCUSSION

In this section, we first provide context for our work, noting that related work has tended to focus on one stakeholder group or another, rather than both. Next, based on our results, we offer implications for the design of systems to facilitate the incorporation of PGHD into clinical environments, illustrated using our own solutions for mPOWEr. Then, we provide some practical suggestions to engage stakeholders, particularly patients, in the design of PGHD tools. Finally, we discuss the limitations of this study and future work.

Relation to Other Work

Many other researchers have described excellent examples of human-centered design³² in a variety of contexts, from EHRs to mobile health applications.^31,39–42 However, due to the nature of their domains, these researchers generally engaged only one stakeholder group (patients or providers) in these designs. For example, most personal health records have been designed mainly with input from immediate users (ie, patients),^43,44 although some authors have engaged or advocated for the involvement of multiple stakeholders in the design process.^45–47 Patient portals are another domain that includes the implicit involvement of multiple stakeholders. However, many patient portals have been designed with input from only patients or providers,^48–50 although several notable examples have engaged both groups in the design process.^51–53 The best examples described in the literature are those that explicitly identify conflicts between different stakeholders,^52–54 especially in the context of a formative evaluation of an HIT system.⁴⁶ However, beyond the identification of conflicts, we suggest that more work is needed to identify design principles to resolve potential conflicts.

Design Implications

We explored the tensions that arise when designing a novel, patient-centered post-discharge wound-monitoring tool with both patient and provider stakeholders. Although patients and providers agreed on a broad range of design specifications for mPOWEr, several key issues emerged that have significant implications for the design of patient-centered technology in the era of PGHD. Table 2 shows those design implications that are most pertinent to clinically integrated PGHD, which are informed by both conflicts and agreements between stakeholders. We give examples of how we addressed design implications in mPOWEr’s patient-facing application (Figure 4) and provider-facing dashboard (Figure 5). In Figure 6, we illustrate an offline “wound diary” mode in mPOWEr, which addresses Design Implication 3 (consideration of routine vs on-demand use) to enable routine use by low-risk patients while minimizing the burden on providers.

Table 2:

Design Implications for Clinically Integrated PGHD Applications

Design implication	Challenges	Recommendations (See Figures 4–6 for illustrations)
1. Include metadata	Existing “analog” processes and interactions, both patient-provider and provider-provider, are rich with metadata that can be used to aid decision making, eg, answer uncertainty or patient reliability.	Developers should incorporate human-centered design methods (eg, observations and interviews) to identify and capture metadata currently used in decision making. Consider incorporating explicit measures of uncertainty, reliability (adherence, no-shows), and/or anxiety (patient-reported or provider-assessed).
2. Balance flexibility of input data	Patients can feel frustrated by needing to fit their concerns into a box and worried about checking the “wrong” box, whereas providers often want to constrain patient input as much as possible to minimize review time, standardize decision making, and reduce liability for overlooking “needles in a free-text haystack.”	Provide thoughtful answer choices, tested with users. Provide help (including concrete examples) and “nudge” patients toward discrete choices, but leave the option for free-text input.
3. Consider routine vs on-demand use	Patients may want to track their wound frequently, while providers may only want to receive routine data from high-risk patients, without being burdened by the time and liability associated with submissions of data from low-risk patients. Yet, historical serial data on ostensibly low-risk patients becomes useful if there are concerns about complications.	Create templates for different use cases, and help providers decide appropriate use cases. Allow patients to use data collection tool as often as they wish in “offline” mode, and forward data when it becomes clinically useful.
4. Make communication preferences explicit	Patients often prefer to communicate by e-mail/text message, but providers may find such methods disruptive, inefficient, or prone to miscommunication.53 Text-based communication methods do not facilitate rapport-building and may obscure who is communicating with the patient.	Flexibly incorporate user preferences into the application, ie, enable opt-out of particular communication modes. Establish/publicize guidelines about appropriate content and timeliness of provider responses. Be transparent about who is communicating with the patient and encourage rapport-building by using photographs of patients’ and providers’ faces.
5. Simple, actionable presentation of data	Impaired patients and busy providers both want data to be condensed into simple, actionable elements. Measuring many symptoms over many time points generated too much data to be comprehended at once. Patients and surgeons need easy smartphone access (eg, in the operating room or at the bedside).	Understand clinical reasoning, ie, how providers think about these data and present them to support that reasoning. Provide high-level summary views of data and flag complex or contradictory presentations for deeper review.
6. Flexible prioritization schemes to support timely response	Patients and providers have varying views on how to prioritize patients for review and response (with or without incorporating patients’ concerns). Most patients do not want to “bother the doctor,” (PA4) but, when they do have concern, they want faster response times than providers want to guarantee. Both groups want to avoid significant worsening of the SSI while the patient is waiting for a provider response.55	Encourage patients to voice concerns and collect patients’ level of concern, but clarify to patients how that information is used. Allow prioritization (flagging, sorting) based on a range of factors (eg, level of patient concern, symptom trends). Advise patients under what circumstances they should seek care while waiting for a provider response.
7. Clarify responsibility and enhance reliability	Patients and providers noted that system reliability is critical, yet is unlikely to be achieved. Patients want providers to take responsibility for reliably reviewing their data, making an assessment, and guiding them to care in a timely way; providers want patients to continue to bear this burden. Providers were hesitant to allow patients to have input into setting provider response timeframes and were worried about losing power to manage the process or causing other patients or responsibilities to suffer.	Create clear and shared general expectations between patients and providers about the timeliness of providers’ responses; once data has been submitted for review, estimated response time should be clearly visible to both patients and providers and updated in real time by providers. Consider giving patients the ability to escalate their request if the provider’s response is not meeting expectations. Track provider response times and escalations and take a continuous quality improvement approach to improving these measures (institutional barrier).
8. Enhance existing workflows	Both patients and providers were most comfortable building on existing, clinic nurse-centered processes and workflows, while recognizing that these processes had significant problems, eg, fragmentation. Providers were most excited about incorporating mPOWEr if it could help address these problems, rather than adding another layer of complexity to existing processes.	Understanding existing processes, team roles, and inefficiencies; seek to minimize disruption by introducing system incrementally. Facilitate intrateam communication and consultation. Integrate with existing HIT systems (institutional barrier).
9. Strive for radical transparency	Patients and providers want transparency (cf, OpenNotes56), which is not typical in healthcare, about who is viewing their data, what decisions are being made about it, and when they can expect a response from their provider.	Make an “audit trail” available to both patients and providers in real time, showing who has viewed data and how they have acted on it. Provide patients with a “road map” of typical provider processes, to help them gauge progress. Use historical data to set expectations for provider response times.
10. Align goals of data use	Provider goal is triage; patients’ goal is getting a definitive diagnosis. Providers are concerned about time requirements for PGHD review and about both under- and over-triage (ie, too few or too many patient visits). Patients only see the upside of providing more data (eg, fewer visits to their providers).	Create shared expectations about potential for fewer or more patient visits. Create institutional structures for systematic screening with dedicated provider time for monitoring (institutional barrier).

HIT, health information technology; PGHD, patient-generated health data; SSI, surgical site infection.

Figure 4:

Patient-facing mPOWEr application. Callouts (orange) highlight design implications from Table 2 (corresponding to the number in the circle). Dotted lines (red) indicate screen changes due to clicking or tapping. Full color version available online.

Figure 5:

Provider-facing mPOWEr dashboard. Lower right portion of the figure shows the mobile version of the provider dashboard (depicting a consult request sent from a clinic nurse to a surgeon). Callouts (orange) highlight design implications from Table 2 (corresponding to the number in the circle). Dotted lines (red) indicate screen changes due to clicking or tapping. Full color version available online.

Figure 6:

Diagram of offline “wound diary” mode, illustrating Design Implication 3. Due to benign symptoms, wound photos from days 1, 3, and 5 are stored but unmonitored; worsening symptoms from day 7 trigger an alert that pushes previously unmonitored photos for provider review to help distinguish between potential pattern #1 (problem) vs #2 (normal). See legend at top right.

An Increased Need for Stakeholder Engagement, Especially with Patients

We identified a number of areas of conflict between patients and providers in the design of a novel system incorporating PGHD (mPOWEr). Our experience highlights the importance of bringing a variety of stakeholders, including patients, into the design process for PGHD applications at an early stage, before any code has been written. Based on our experience, we recommend employing strategies such as including patient advisors directly on the research team and/or seeking feedback from patient advisory groups maintained by healthcare organizations. We suggest engaging stakeholder groups iteratively during the design process, to ensure ongoing input from key groups, rather than, for example, a “patient engagement phase” followed by a “provider engagement phase,” which could allow one group’s input to overshadow the other’s.

Limitations and Future Work

Our work has several limitations, including a relatively small sample size (based on reaching thematic saturation), and being conducted within a single healthcare system, although across diverse care settings, including a county hospital trauma center and university hospital. Due to sequential sampling, patients were representative of the underlying population at our institution, but unfortunately did not include patients with dark skin coloring, who may have a different experience with photographing wounds. By recruiting PAs who have already elected to advise our institution, we could have introduced a potential source of “self-selection bias,” although we believe that the value of these “expert patients” outweighs any potential bias introduced. We focused on a unique post-acute surgical use case that may not perfectly generalize to medical or chronic care settings. However, we believe that this use case represents an illuminating extreme in terms of patient acuity, time criticality, the heterogeneity of potential PGHD (eg, photos, subjective symptoms, sensed vital signs), and the provider-centricity of post-discharge triage workflows.

In addition to the design challenges that derive from patient-provider conflicts, we uncovered several issues that are challenging because they require broad, institutional changes, eg, ensuring dedicated time and funding for providers to review incoming PGHD, or integrating PGHD collection systems with existing HIT systems. In future work, we plan to address these issues as well as evaluate the impact of mPOWEr on clinical outcomes, utilization, and patient engagement.

CONCLUSION

Despite a use case with significant buy-in from all stakeholders (post-discharge wound monitoring), we encountered patient-provider conflicts that impede the design and adoption of mPOWEr and similar patient-centered tools. Herein, we identified and described a number of design implications that can inform the development of similar tools, but patient and provider engagement remains critical to working through these tensions, in order to ensure smooth integration of PGHD into routine clinical use.

CONTRIBUTORS

P.C.S., A.H., W.B.L., H.L.E., W.P.; Recruitment and data collection: P.C.S.; Data analysis and interpretation: P.C.S., A.H., R.J.L., C.A.L.A., W.B.L., H.L.E., W.P.; Manuscript writing: P.C.S., A.H., R.J.L., C.A.L.A., W.B.L., H.L.E., W.P.

FUNDING

Research reported in this publication was supported by the National Center for Advancing Translational Sciences of the National Institutes of Health (UL1TR000423), the Surgical Infection Society Foundation for Education and Research, the University of Washington (UW) Medical Center’s Department of Surgery Research Reinvestment Fund, the UW CoMotion Commercialization Gap Fund, and the UW Magnuson Scholarship. The content is solely the responsibility of the authors and does not necessarily represent the official views of any of the sponsors above.

COMPETING INTERESTS

None.