Follow-Ups


Customizing medical program workflows

Problem


How might we accommodate unique workflows and program-specific tasks within a recommended workflow of program-agnostic tasks?

Summary

Patient management consists of common and readably definable tasks but individual workflows unsurprisingly vary with open ended tasks. With this initiative, I reconceived tasks to accommodate both paradigms.

  • Paradigm shift
  • New functionality
  • 6-month timeline

We successfully shifted from a paradigm of individual tasks to a relatively open-ended follow-up model, providing new functionality within a short period of time.

Background


Product Description

This work sample is about optimization of workflow management software in digital health.

Hawkeye  is a web-based product whose customers manage the patient journey from post-referral through post-procedure milestones.

The product’s primary users are nurses who coordinate AFib therapies within cardiovascular programs.

Core Team

As lead designer, I collaborate with my peers and conduct design activities in pursuit of viable solutions.

  • Product Manager
  • Product Owner
  • Lead Engineer
  • Senior Product Designer
  • Associate Product Designer

Process

We operate on a balanced team model (à la the product trio) with continuous discovery and regular user check-ins.

Tasks, Compliance and the NCDR

Hawkeye consists of a set of recommended tasks to ensure program integrity and adherence to National Cardiovascular Data Registry (NCDR) guidelines

...

Tasks completed by users are mapped to NCDR guidelines and generally presented sequentially, though subsets may be completed in any order.

Program-Specific Tasks

Some programs require unique tasks in management of the patient’s journey.

...

Program-specific tasks were upon request added to the set of recommended tasks.

Burden and Annoyance

Tasks could be hidden at the program level upon request but the addition of any task was program-wide by default and, thus, visible to all users.

Consequently, the Hawkeye admin burden was excessive given the number of (a) unique tasks requests and (b) hidden tasks requests—the interface was cluttered with unwanted tasks for most customers.

...

Program-specific tasks in the set of recommended tasks were relevant to some programs but an annoyance to other programs

Strategy


Summary

  1. User interviews
  2. Tasks audit and analysis
  3. Low-fidelity prototypes
  4. User testing
  5. Final definition

Description

My intuition was to empower the end user with follow-up definition—user authored tasks—which would 1) eliminate unique tasks requests and 2) establish the product as customizable, which is a long term goal of the business.

To confirm the desirability, feasibly, and viability of what became known as Follow-Ups, I 1) conducted user research around unique tasks needs, 2) oversaw a task audit to define tasks characteristics, and 3) aligned design direction with business goals.

Tasks Audit

Every task consists of input elements with at least one required element. For example, the task Schedule 1-Year Follow-Up consists of a date and follow-up type that the user must provide to complete the task.

Accounting for the attributes for every task was essential to preserving program and system integrity while allowing for custom follow-ups.

...

As part of my audit, I wrote an account of the problem to clarify objectives and requirements.

Prototpe

As with any project, I created a prototype to assess the viability of our proposed solution.

...

Low-fidelity wireframes and prototype to assess custom follow-up flow and interaction.

User Testing

I arranged user testing with an external researcher who found general concerns around form completion, which we subsequently triaged and addressed.

...
...

Key insights from user testing.

Challenges


Description

What if users define follow-ups that satisfy requirements of a recommended that is, predefined, task?

Given user authored tasks, tasks redundancy and gaps in completion was a possibility in that such a task could consist of attributes equivalent to a recommended task.

For purposes of program integrity, it was imperative that recommended tasks in the above scenario be marked as complete upon completion of the user authored task.

...

Program-specific tasks are mapped (or not) to recommended tasks and marked as complete if appropriate.

Solution


End-User Task Definition

The solution on the front-end is a follow-up form with optional attributes, allowing for customers to define tasks specific to their workflows.

Automated Task Mapping

On the back end, the solution maps user authored tasks to predefined tasks. If the attributes of a follow-up map to a recommended task, then that task is automatically marked as done once the follow-up is completed.

Product Customization

The solution was the first step towards user customization of the product, specifically means to define follow-ups in the patient’s journey.

Results


Description

Customers embraced the new functionality, which received positive, qualitative feedback:

"Creating my own follow-ups for patient management has truly been a game-changer. It streamlines my workflow by allowing me to tailor each follow-up to the patient's unique needs. This flexibility not only improves efficiency but also enhances patient management by making it more personalized."

—Nurse Coordinator

Quantitatively, we reduced novel tasks requests by 100%.

Let's Connect


Whether to advise, mentor or talk shop, I'm happy to connect.