Case Study: Patient Messaging

Helping patients message smart, not more

Breaking silos

Data-driven design

📚 5-8 min read

2 years after the telehealth surge of the pandemic, and patients were still texting providers at unsustainably high rates.

Provider burnout would be front and center issue for MyChart's Patient experience team for the next few years. A permanent behavioral shift towards digital and asynchronous healthcare meant that clinicians were now receiving up to 157% of their pre-pandemic volume of patient messages.

Our team's primary goal was to make messaging more efficient and manageable for the recipients, not just the senders.

This data was gathered internally through Epic's feature-tracking.

Problem statement

Providers are burnt out by an overhwelming volume of messages due to a shift in patient behavior towards messaging their care team as their first step in seeking care.

The Outcomes

We've saved clinical responders 175,000 clicks per week

Previously around ~10% of new message chains could've been replies instead. We've since reduced that number to ~4%. This means fewer messages go through the routing workflow.

We've saved each org millions of dollars per year

We're still crunching this final number, but we know it's millions. After all, it costs a health organiation approzimately 2.78 every time a patient sends a message.

24% of patients now choose a self-service option

The triage menu has redirected patient behavior from sending a message to more appropriate avenues such as the "Refill Meds" form.

Quantitative data & talking to providers

We spent a lot of time feature tracking, but to understand the full story, I sat down and talked to a bunch of providers among different specialties at different organizations.

💡 We found that patients were sending duplicative messaging, and in some cases bypassing more appropriate or efficient channels like phone triage or appointment based on the medical situation.

Providers had been managing these innefficiencies for years, but the sheer increase in volume made these issues go from an annoying to unmanageable.

What were customer health orgs doing?

Before getting too deep into the solution space, our 400 healthcare organization customers were already strategizing plans to tackle this problem at lightning speed. For example, NYU Langone Health conducted their own study on how physicians interacted with volume and types of messages received, along with time spent after-hours and on weekends logging into the system. Read more

The football analogy may have been lost on me, but the message was loud and clear: patients aren't really messaging their providers anymore.They're messaging a group of receivers. Our internal messaging system definitely wasn't designed for this. There was no visibility of system status to patients that their message had been rerouted.

Understanding what we were starting with.

A few years prior, our patient messaging portal had undergone a full redesign. When MyChart's design system was restructured for a mobile-first experience, so the team had looked towards short-from modes of communication, like iMessage, for design inspiration.

💡 Here's the problem: Messaging your doctor isn't like texting. But our previous UI had oversimplified the experience to the point where that's exactly what it felt like.

I can't show you the details on my public site, but all you need to know is that the previous UI felt like iMessage and this was the behavioral impact.

I can't show you the details on my public site, but all you need to know is that the previous UI Message a this was the behavioral impact.

Meanwhile, this is what a provider would see (abstracted but realistic enough)

Imagine if the people you worked with emailed you like they texted. Providers were getting a clutter of inefficient messages in their inbox. I led a competitive analysis brainstorm with our team to analyze mobile emailing applications and professional short-form communication methods like Slack and Teams.

We relied on our early adopter customers to understand our user and user test ideas

With little to no avenues at the company for talking a patient directly for feedback (this is loaded topic separate from a case study), I continuously had to get scrappy.

💡 When there's no research budget, what do you do? I worked with 3 separate customer healthcare organizations' UX teams to setup various user testing strategies including surveys, interviews, and live usability testing.

This really became a two-pronged approach: understand the patients, and understand the customer org needs. Becuase often, the patients' and providers' goals were at odds.

Here are a few examples of how I collaborated with our customers:

We coopted a survey with NYU to answer broader attitudinal questions about AI intervention in messaging from patients and providers.
AdventHealth hosted us onsite to conduct in-person patient interviews and live usability testing of messaging UI changes.
We met with Ochsner Health's UX team to see the changes they had made to their out-of-the-box MyChart and see their patient research studies behind it.

Here are a few abstracted UI solutions I designed

We love NDAs. Sadly I can't show you the final product here. But on a high level, here are some of the bigger changes I made to our messaging platform and the reasoning behind it.

Small UI tweak with one goal: Place existing messages closer to reach and the new message button farther.

Small UI tweak with one goal: Place existing messages closer to reach and the new message button farther.

Display average response times for each care option to set expectations and encourage seeking faster forms of care.

New triage menu shows patients different care options.

New triage menu shows patients different care options.
‍
Display average response times for each care option to set expectations and encourage seeking faster forms of care.

Problem #1: Some patients should be seeking a faster or more appropriate form of care rather than sending a message. Simply put, we were making it too easy.

Role: UX researcher and designer

How I solved it: I built a triage menu that shows patients their options for different forms of care before a message can be typed.

A large chunk of messages are medication refill requests - patients are now directed to our dedicated workflow for that and skip messaging altogether.

Rather than trying to diagnose, it suggests the patient gets a human in the loop immediately.

Urgency model detects a potential emergency in the patient's message

Urgency model detects a potential emergency in the patient's message.

Rather than trying to diagnose, it suggests the patient gets a human in the loop immediately.

Problem #2: Patients send emergency messages after hours. After talking to providers, this is one of the most devastating experiences that many recall: Coming into work on a Monday and seeing a patient message containing stroke symptoms and not knowing if they got the care they needed.

Role: UX designer and AI ethics advocate

How I solved it: I worked with our cognitive computing team to translate our provider-facing urgency model into patient contexts

Don't want to get too much into the weeds here, but ask me more about some of the changes we made to the model and patient safety storyboarding I did!

Inbox menu and subject lines - rather than recipient names - orients communication around purpose

New messaging hub interactions designed for mobile gestures such as tapping and swiping.

New messaging hub interactions designed for mobile gestures such as tapping and swiping.
‍
Inbox menu and subject lines - rather than recipient names - orients communication around purpose.

Problem #3: The messaging hub was outdated - patients continously were failing task based usability studies on how to find other folders in their inbox and basic interactions such as selecting or archiving messages.

Role: UX designer

How I solved it: I worked with our cognitive computing team to translate our provider-facing urgency model into patient contexts

Don't want to get too much into the weeds here, but ask me more about some of the changes we made to the model and patient safety storyboarding I did!

New contextual badges and details page so that patients can see the same important info as providers.

Adding a healthy level of complexity back to the patient side.

Adding a healthy level of complexity back to the patient side.
‍
New contextual badges and details page so that patients can see the same important info as providers.

Problem #4: If a patient is being messaged about the test result, they previously were not given contextual access to that test result - despite this being supported by our system and displayed on the provider's end. This led to patients asking preventable clarifying questions.

Role: UI builder, Design system builder

How I solved it: This issue had been well researched, so my main task was finding a way to fit all this info into a clunked up UI. I built a north star with all these incrememntally developed features beforehand to avoid the issue of realizing later we had run out of space. This also led to some rad design system updates and quality of life improvements across MyChart that our foundations team developed, freeing up my team's budget to work on backlog projects.

The team tackling things on the other side

One of our teams had been exploring another solution. Clinicians told our developers that they wanted to show patients when they were out of office, and we had taken the solution at face value without understanding the core problem. Uh oh.

💡 The patient and provider experience were two sides of the same coin, but our product teams were completely siloed. I pushed to get all of us in the same room weekly, which saved us from disaster.

What our developers didn't know is that the siloed provider-facing team was already building a super efficient routing model that would redirect patient messages to the right person.

Patients seeing this might not realize that even though their recipient is OOO, that their message will be seen by the care team.

Problem #5: We wanted to show patients when providers were out of office.

Role: Bridging together sioled teams

How I solved it: Connect the leaders of both teams and align both of our roadmaps

Show that the initially proposed feature wasn't telling the full story of what our end users needed, and where both of our products were heading in the future. We were able to merge efforts, and planned development of this feature was rerouted towards other high priority projects.