Patient Reported Outcome Measure Tracking

Tool designed to track PROMs for the rehabilitation therapy industry

Summary

Medbridge was looking to expand their portfolio of products to include a tool to aid in the collection and reporting of patient reported outcome measures (PROM) as it could lead to higher reimbursement rates. Most PROM tools on the market were geared toward surgical practices and were far too expensive and cumbersome for the rehabilitation therapy industry to use.

My Role

As design lead, I developed the patient and provider experiences of the PROM platform. Responsibilities included generative research around the opportunity space, developing personas, journey mapping, writing context scenarios, wireframing, creating interactive prototypes, user testing, and delivering final comps.

The use of PROMs is not widespread... in part because of the challenges of collecting and using this information in a way that does not disrupt the workflow of clinicians.

— Martha Hostetter and Sarah Klein, The Commonwealth Fund

Research and Strategy

Understanding QPP, MIPS, and PROMs

MedBridge's Sales team began hearing from many of our Rehabilitation Therapy customers that they needed a way to track and submit patient reported outcomes to the Centers for Medicare and Medicaid (CMS) for reimbursement under the Quality Payment Program (QPP).

This was a new product area for Medbridge, so I dove into understanding what the QPP was and how we could help our customers would turn these patient reported outcomes into higher reimbursements through the Merit Based Incentive Payment System (MIPS)

Illustration the relationships of how the QPP is replacing older payment models based on Sustainable Growth Rate and Fee for Service.
QPP Timeline, we began work on this effort in Fall 2016, four months before MIPS reporting would begin.

Defining the Opportunity for Medbridge

Getting into the documentation submission aspect was decided to be a follow on to an initial launch of a tool to enable PROM collection and tracking. Once the major functionality had been decided on for MVP. I set about defining our user base.

Outcome Measure Structure

Our customers typically broke into two segments when it came to utilization of outcome measures, they either were organizationally driven (e.g. "It's our organizational policy that for all x injuries, our PTs must use the x outcome measure."), or they were clinician driven (e.g. "PTs can use whatever outcome measure they deem best for their patients."). Finding the common ground between both was crucial for a successful product launch.

Personas

To aide in concept development and team alignment, I created personas based on interviews with our users. Outlining the personas' individual expectations for the product enabled the sales and PM team to scope the launch.

Journey Mapping

Post the creation of the personas, and user interviews, I lead a mapping exercise with our stakeholders to visualize the key points and interactions between the users and the future system.

Context Scenarios ---> Epics ---> User Stories

As the engineering team would be an overseas org, who would not be part of the initial design work, I created concrete context scenarios that could be turned into Epics and then User Stories to guide the engineering build.

Concepting

User Driven Feature Design

For this project I used a design process that employed short sprints of design work followed by user testing that validated the new concepts. Because this tool was designed to be used by physical therapists, I needed to gather a large enough panel of users to able to test each concept with at least 5 people, all on short notice. The panel was built among 10 different clinics spread out across the US. I conducted six rounds of concepting, testing, adjusting, and retesting.

Initial wireframes

These were built primarily based on input from internal stakeholders, it was a great opportunity for sales, marketing, PM, and leadership folks to feel ownership of the product and feel they had a say in what was developed.

Initial user testing

From the internally driven wireframes the first user test was focused on gathering input and testing assumptions. This test confirmed a general design direction and understanding how clinicians and front office staff utilize outcome measures, but challenged many details and features.

Prototype facilitated user testing

The next four test cycles was moderated using a clickable Invision prototype. Participants were given tasks to complete while giving feedback on the ease of use, potential integration into their current workflows, and detailed level feedback on the designs.

User insights leading to changes in the hi-fidelity comps

Phase two of user testing was a moderated test using a clickable Invision document. Participants were given tasks to complete while giving feedback on the ease of use, potential integration into their current workflows, and detailed level feedback on the designs.

Final Comps