Image of MDLIVE's messaging interface
Role
Lead Product Designer
Overview
After building a robust suite of virtual care services, telehealth service provider MDLIVE saw an opportunity to provide care to patients outside of an appointment. 
I led the research and design of a new messaging service that would allow patients to submit a request to a nurse or provider to get care via message for specific types of inquiries (referred to as a "Non-Visit Encounter"), which led to either resolved encounters or converting the inquiry to a new appointment. 
Realizing the expectations
In traditional brick-and-mortar doctors' offices, if a patient has a question for their doctor after they leave the appointment, the patient can typically give their doctor's office a phone call and get in touch with someone. 
Within the MDLIVE experience, patients don't have an easy way to follow-up with their healthcare provider(s) with questions or clarifications after a telehealth appointment has ended. This results in a pretty isolating patient experience and drives high call volume to the Customer Support center. 
The vision + its business impact
Create a messaging service, allowing patients to get back in touch with their healthcare provider(s) to ask non-urgent medical questions. With this new service, allow patients to easily schedule follow-up appointments for inquiries that can't be resolved via message.
This service may also serve as an add-on for interested clients; meaning that the out-of-the-box product would not allow for getting care via message.
Image depicting a person's hands texting on a smartphone
Understanding the problem
The ability to send a message is everywhere the digital world. From social platforms like Instagram and Facebook, to property management applications, to submitting customer support inquiries, there are patterns everywhere to pull from. 
Nowadays, with widely-used healthcare platforms like myChart, patients expect to be able to get in touch with their doctor or nurse team in between appointments. The goal of the project was to both resolve patient inquiries that didn't need an appointment, but also to convert some of these inquiries to appointments if a back-and-forth message exchange wasn't enough to resolve the issue.
While there is an existing messaging interface in the patient experience, its primary purpose was to send patients system alerts (e.g. "Your consultation summary is ready!"). 
The previous interface:
Image of a previous MDLIVE messaging interface
Overall, the goals were to allow for back-and-forth messaging between a patient and their provider, increase frequency of follow-up appointments, and to increase product sales with this add-on feature.
Meeting the demand 
First, the team needed to identify what some of the biggest drivers of existing patient call volume were to our internal Customer Support team. After all, those would primarily be the inquiries that would be solved through this updated messaging interface.
Through partnering with our amazing Customer Support team, and after a brief mapping exercise, we'd organized some of the highest drivers of call volume:
A group of sticky notes that indicates the types of customer support requests that the messaging feature will support
With the primary categories of request types, it became a little clearer how a patient might get some of these issues resolved via a message.
Rather than free-typing an open-ended message to a provider, how might we guide the patient down the right path, getting the right information from them so that the operations and provider team has everything they need to quickly send the patient a helpful response?
I worked closely with our Product Management and Clinical stakeholders to identify the different types of follow-up questions a patient might be asked: for example, if a patient needed a medication refilled, which medication needed to be refilled? If they have a question about lab test results, which recent lab test is the question regarding?
In parallel, I started working on initial UI for this messaging capability. 
Keeping patient safety at the forefront
In the context of providing patients with quality care, it's important that there are specific guards in place to make sure that patients don't need emergent medical attention when they're sending a message to their provider. 
If a patient is experiencing a medical emergency of any kind, while it's not the most likely for them to send a message to a previously-seen MDLIVE provider regarding the emergency, it is still important that proper expectations are set, and that they're directed to the appropriate type of care.
Image detailing MDLIVE's patient safety disclaimer during messaging experience
There are multiple points within the messaging triage flow that direct the patient to either call the appropriate resource (e.g. 911 or 988, based on the condition or type of health need). In the event of a medical emergency, the assumption is that these triggers will help to redirect the patient to the right type of care (e.g. the emergency room!).
Wrap it up, ship it out
Over the course of a few months, I designed the messaging service across the MDLIVE web application (both mobile responsive and desktop width), in addition to the iOS and Android applications. 
The messaging UI and functionality will scale well as new messaging flows are introduced, and patients have reported higher satisfaction with the service as they are not forced to call or email the Customer Support team to have an inquiry resolved (yay!).
Images of the MDLIVE app's messaging feature
End-to-end messaging flow
Looking ahead
By building these messaging capabilities between patients and their team of providers, the product now has an infrastructure that can scale to support new types of questions or issues as new patient (or provider) needs arise. 
As an example, shortly after this feature was launched to production, an unrelated feature was added to the Product Roadmap, allowing patients to request their medical records to send to other healthcare providers. While this would be a self-service tool, this messaging feature ended up being the perfect triage engine to get them to the self-service tool to download their medical records. Mission accomplished 😎  (for now).

Check out some related projects

Back to Top