Integrated behavioral health care for patients and their care team
Overview
Project Loop addresses the pain points of two primary customers: patients and primary care teams. For care teams, Projct Loop is a care-enablement platform designed to support care providers and behavioral health clinicians to deliver integrated behavioral and physical care. For patients, it focuses specifically on supporting those whose chronic diseases, such as diabetes, are affected and aggravated by behavioral conditions.
Project Loop combines digital signlas from everyday technologies (smartphones and wearables) with traditional health care data and translates them into actionable insights that improve clinical outcomes.
Preparation
This project was a precursor pilot for gauging the effectiveness of various methods of data capture, measures, analysis, and insight delivery to participating parties - with the ultimate goal of increasing health outcomes impacted by the combination of chronic disease and behavioral health. Multiple vendors were researched and partnered with for data capture and patient interaction for capabilities in:
- Passive data collection from mobile device sensors
- AI-driven conversational chatbot
- AI voice analysis
- Prioritized insight display for clinician care coordination
Challenges
#1
The app needed to be built from scratch, taking into consideration ineraction patterns that enabled capabilities brought by various vendors. The hypothesis was that each of the individual partners and their technologies solved one piece of the broader picture Optum was seeking to encompass into Project Loop. However, their individual products were already in-market and tuned to specific interactions that drove user behavior they needed for their technologies to work.
#2
One overarching issue was multiple vendors using their own survey for patient reported outcomes (PRO). Specific questions in one vendors survey helped train it's AI for patient conversation. Another's survey informed insights delivered to clinicians. And another vendor used the standard PHQ-9 survey and had developed their analytics backend to work with that. Adjusting verbiage or adding/removing questions or order of questions required technical debt for one or multiple parties.
#3
A final consideration was that a few of the capabilities required permission to capture and send sensor data to a central data warehouse, owned by Optum, that was then disseminated to appropriate parties for analysis and learning before sending back to Optum for sharing out to partners or the in-app experience. Vendors were leery of data getting altered or changed in this back-and-forth. Ultimately, users could choose to either not allow sensors to be used on their device, or they could turn off permissions at any time.
I began by building out service blueprints for primary features and vendor integration, then wiring presumptive screens aligned to each scenario. As refinements and decisions brought more clarity, I then moved to wiring possible flows for patient and provider use cases.
Version 1
Once we felt clear on specifics I began translating the experience into an Optum-branded experience. At this time, Optum had begun work to evolve its external brand to include consumer-centric offerings, where historically it was mostly focused on clinic-facing experiences. In projects like ours, it was desired that we follow newer brand standards to support this brand transition.
I put together a future-state set of screen mockups that aligned to product and tech decisions we had been gaining clarity on. These were prepared for an offsite meeting with key vendors, showing how their capabilities might be integrated into the app.
But… there was a storm brewing.
Houston… we've got a problem
At the offsite meeting, we learned that one of the vendor partners was not keen on us relegating their capability to simply a key feature of the product. They expected to be the main method of user interaction; for users to communicate with their chatbot as the primary form of interaction. This, of course, didn't sit well with other vendors, nor did it make sense from a brand perspective for Optum. But I wasn't part of earlier discussions with vendors nor was I privy to promises or agreements offered to attain partnership.
We provided our argument to the group on possible confusion for patients thinking they are interacting with our brand when they get into the experience and it feels driven by another entity. We provided our perspective of brand dilution to the product team and the disparate experiences our consumers would have with another company driving one of our apps. And we brought up the complexity of merging another vendor's capability into the chat experience. At the end of the day, to keep this key vendor engaged (they threatened to walk if they didn't get more prominence in the app) the decision was to acquiesce and change the direction of consumer interaction in the app.
Version 2
With that decision made, I set to mapping who owned stages of the consumer journey through the app, along with where handoffs would need to be made between entities. This included who captured what data, where it was sent, and who was driving interaction with the consumer in the app.
Players included Optum (O), the clinical provider involved in the pilot (CP), the chatbot partner (CB), voice analysis partner (VA), device sensor partner (DS), and the clinical interface partner (CI). For the app, this broke down into the following for the patient app:
- User awareness - O, CP
- eConsent - O
- App acquisition - O, CP
- App setup - O
- Onboarding - CB
- Initial and standard experience - CP
- Voice capture - O, CP, VA
- Settings - O
- Program end - O, CP
Clinician experience
Our work on the clinical side was a little less complicated. The partner already had a product in-market and we would be modifying their experience to include additional sensor, chat, and voice analysis feedback for them to integrate into their UI. It needed to provide clinicians an overview of their patient panel, along with patient-specific data to help guide their treatment plans.
There was a decent amount of negotiation around patient health surveys. The chatbot partner, who was now driving the patient app experience, had built their own version of survey that fit best with their AI models. It was not industry-standard in all of it's questions, so didn't slot in nicely with how the clinical partner (and our own in-house research team) needed to measure patient survey data. After rounds of back and forth, they got it sorted in a manner that allowed for everyone to get what they needed while not undermining the validity of the data.
We were able to pull it all together into a seamless, cohesive patient experience.
Figma prototype
