Role
Lead Product Designer
Overview
Remote Patient Monitoring (RPM) is a type of telehealth service that allows healthcare providers to monitor patients outside of a clinical setting using digital devices. For patients with chronic conditions like hypertension or diabetes, RPM can use digital technologies to collect health data from patients and securely transmit that information to providers in a different location.
When MDLIVE initially rolled out its RPM programs in 2021, patient adoption was lower than anticipated, which implied that patients weren't tracking their vitals. By not tracking their health vitals, their healthcare providers then don't have enough data to analyze and are left unable to make recommendations that might lead to more positive health outcomes.
What we're working with
The first rollout of MDLIVE's RPM programs included only manual entry-tracking: logging in and manually typing in the day's systolic and diastolic readings, as an example. This method stood in the way of even the most committed patients from being able to consistently report their vitals.
In this day and age, smart health devices are not obscenely expensive and can drastically improve adherence to RPM programs. How might we leverage this technology to increase patient utilization of these RPM programs?
What we're working towards
By allowing patients to connect smart health devices (blood pressure monitors, glucose monitors, smart weight scales, and the like), and creating an engaging health vital tracking experience, patients with chronic conditions will feel supported as they work towards positive health outcomes.
Revisiting v1.0
At the end of 2021, MDLIVE launched their first Remote Patient Monitoring programs for three vitals:
• Blood Glucose
• Blood Pressure
• Weight
The initial launch included a highly manual process, wherein a patient would login to the platform and type in some vitals using their keyboard - similar to filling out a short form.
Their program assignment also might recommend that they do this up to 4 times a day (depending on the vital being tracked).
This experience and the lack of patient adoption resulted in one of the main project objectives coming down to making this a generally delightful patient experience. There were so many opportunities for improvement from the initial interface. How might we make this process as smart and technically seamless as possible?
Understanding the technology
Connecting smart health devices to web or mobile-based applications is no walk in the park. Before identifying user requirements for how patients would connect a smart health device to the application, the team first needed to define and understand the technology available in the market.
After a thorough vetting process, the team landed on a technology vendor that allowed Cloud-based and Bluetooth-enabled connections. That's more or less jargon for saying: the selected vendor would allow patients to connect a smart health device, regardless of whether they were connecting via our iOS, Android, or web application.
Telling the story
This project moved on a very quick timeline due to contractual obligations, but before any design work could start, it was important I identified a reasonable user flow so I could get a sense of who these patients were.
Enter: Chronic Carl.
Chronic Carl became our user persona to describe a patient with hypertension, a chronic condition that is eligible for device connectivity through an RPM program.
User Flow: Connecting a Device (Web + Mobile)
In the user flows above, there are a few scenarios where a patient might encounter a technical error, ranging from an unsuccessful Bluetooth pairing (the worst!) or a successful pairing but data isn't syncing properly from the device. How would we support them if this happened?
Even if the device connection process doesn't encounter any hiccups, the goal of our connection process was to be as smooth as possible, so that all patients can easily get their device connected to start tracking their vitals.
Designing from the start
After mapping out the user flow and understanding the technology, it became apparent very quickly that the best way to help patients connect a device would be through a guided onboarding experience.
Such a technical process can be incredibly confusing even for the most tech-savvy individual, and a guided flow would help address any errors or pitfalls a patient might run into. Why not hold their hands a bit?
In order to connect an eligible device, patients will have to first purchase it themselves (a "Bring Your Own Device" model, if you will). Brands like iHealth, Qardio, A&D, Omron, and WelchAllyn are leaders in smart health devices that can be used in these programs.
Once the patient has the device in-hand, they're just about ready to get up and running.
Working somewhere between lo- and mid-fidelity, I identified a few possible interface layouts and steps. It was a challenge to work in lower fidelity due to the technical nature of these flows.
Fine-tuning flows
Given the number of user flows involved in this project (e.g. is the patient on our web app, or the IOS or Android app? Are they connecting a Blood Pressure monitor, or a smart scale?), it took quite a while to move from low-fidelity to high-fidelity.
There were several considerations relevant for our iOS and Android users that weren't relevant for our web users, and vice-versa, which caused some last-minute requirement shifting.
Putting it all together
Here's a video of the realized, end-to-end experience of connecting a Bluetooth device on our iOS mobile app.
Device Connectivity Flow (iOS)
It doesn't stop here
Guiding patients to connect smart health devices definitely led to an increase in program adoption (mission: accomplished).
But there was also an unexpected benefit of users being able to easily connect devices: more vital data than what our existing program screen layout could support.
I started working towards an updated UI to better allow patients to see trends and progress. While out of scope for this project, the goal is for this to be a roadmap item in 2025.
Findings & Reflections
This project was highly technical, involving close collaboration with Engineering partners throughout the project's lifecycle. Staying close allowed me to iterate more quickly because I was able to remain up-to-date on technical constraints that would impact the patient experience.
While utilization of the RPM programs increased by over 30%, and the majority of patients were tracking their vitals using connected devices, there was still a lack of awareness and understanding about these programs and their purpose. There's an opportunity to partner with cross-functional teams (hi, Marketing!) to spread the word about how these programs can help patients improve their health.
