Identifying patient risk

RLSolutions, 2018

Business Problem

The Product Manager for our Risk persona approached me to ask if I would be able to validate an idea he had that would allow us to identify patient risk. This was classified as a project that would not require a lot of Design Research assistance, since the PM had already dedicated a lot of time to researching the idea. The problem identified was that in order for nurse managers to understand which patients on their unit are at risk of adverse events, they must manually scan each Electronic Health Record to identify if there are factors that will contribute to an adverse event. The PM wasn’t sure how to translate the conversations he had already had into design recommendations.

Approach

I began by understanding what the PM had already learnt from the research that was completed and learning more about the problem that nurses were facing. Since there were no recordings for conversations he had with clients, I spent several hours picking his brain to understand what he had learnt about the individuals being affected by this workflow.

The knowledge produced from my conversations with the PM lent itself well to empathy maps which would help us better understand how personas affected by patient risk would be impacted by the idea. I created a template on large chart paper and included the categories: thinking, feeling, saying, doing, gains, pains to help the PM apply his findings to an empathy map for each persona involved in the scenario at hand.

From there, the PM and I ran through the “doing” section of the empathy maps to determine the task flow of each persona. We were able to generalize these tasks into 4 steps in the process of identifying a patient’s risk.

Process wall and empathy map points

Next steps

I created a document to reflect our findings and what had been learnt during the research phase. This was presented to the UX Designer who would be working on the project. After onboarding the designer onto the project, we spent some time co-designing an experience on paper that would address the problem we were facing.

The digitized version of the window exercise.

Task flows I created to help communicate the project to the designer.

Continuing the project

In the meantime, a series of collaborative efforts were taking place and it was identified that the Risk project we were working on would be able to interact with another project focused on Quality. The two teams were then tasked with understanding how each project would fit together. We did this by drawing out our proposed workflows on a board and identifying any opportunities for the projects to leverage one another.

At the same time, I assisted the team working on a Quality project with a workshop they were running on-site with a client. It was intended to be a focus group, but up until the day before the meeting, they had not prepared a plan. I helped them to organize a schedule that would bring up conversations points to address both projects. On the day of the workshop, I help guide the group through the discussion.

Once the UX Designer had prepared the initial wireframes, I arranged some initial conversations with Director-level users at client organizations. This was to get a pulse on what this type of persona would perceive from such a feature if it were to be introduced into their organization. After the conversations, it seemed as though the Director personas would be more interested in the reporting capabilities of the feature rather than the day-to-day application. I needed to be speaking to actual users to understand if this was going to help them identify at-risk patient on a daily basis and what they are doing now to learn of patients at risk. I worked with the UX Designer to identify a list of what assumptions we were making and what questions we still had.

I arranged these tasks on a wall to symbolize columns, and placed each empathy map section (thinking, feeling, doing, saying, gains, pains) in a row. From there, each finding from the empathy map was placed on a sticky note (different colours for different personas). Working with the PM, we then discussed each sticky note and found its place on the wall based on which row it belonged to and at which step it was being experienced by the persona.

This allowed for a more visual representation of the problem and current situation. It also allowed us to identify where the most amount of challenges were being experienced and if this aligned with any other step or persona. We found that there was a cluster of stickies happening around specific steps in the process which validated that the PM’s idea had the opportunity to alleviate a lot of stress.

Storyboard

While the UX Designer was preparing wireframes for a solution that would help to surface patients at risk, we encountered another challenge. The PM was having a difficult time explaining the project to stakeholders. Due to the complexity of the problem and the solution being proposed, stakeholders were not able to comprehend the project after a short pitch. I helped the PM translate his pitch into a storyboard. After getting feedback from the UX Designer and the PM, we had a storyboard that was ready to be shared with anyone who wanted to understand the project.

Comparing where we are now to a future state.

A more in-depth view of the idea.

I was able to connect with 3 nurses over the phone. And rather than show them the wireframes, I wanted to have an in-depth conversation to fully understand if our assumptions were correct and if there were any other tools/procedures in place to help with this process. The conversations I had with the nurses were extremely valuable. I was able to communicate the findings to the UX Designer. The most informative finding to come from the conversations was that the proposed solution we were working on would only be useful for clients without a robust Electronic Health Record (EMR) since clients with a more advanced EMR were already successfully identifying at-risk patients.

I presented the findings from my phone interviews with the PM and recommended that the product target users who do not use an EMR that already addresses this problem. The project was ultimately deprioritized and is waiting to be picked back up for a future release.