UX/UI

DaVita

Project Background

DaVita provides dialysis to patients around the globe that suffer from End Stage Kidney Disease. These patients are dependent on dialysis and receive treatment at one of DaVita’s 3,200 dialysis facilities. Any updates, modifications or adjustments made to a patient’s care results in the issuance of an order. This order is typically performed at the time of a patient’s dialysis treatment.

Problem

Orders are given and applied at the time of treatment. If a physician doesn’t sign an order after 90 days, DaVita is no longer able to bill for the service which has already been delivered. DaVita was experiencing a revenue leak of $418,000 per month as a result of orders not being signed by this deadline.

My Role

As the UX designer I was tasked with understanding the problem from a holistic point of view. Understand why the problematic group of physicians continued to procrastinate signing orders. Create a solution that would plug the leak.

Limitations

DaVita’s legal team insisted we only allow physicians to sign 20 orders at a time. This ensured there would be a thorough and relevant review of all orders despite our competitors which allow the bulk signing of orders.

UNDERSTANDING THE PROBLEM

  • 72 of 3500 physicians accounted for 88% of the delinquent unsigned orders
  • These physicians visited the orders queue in our application 60% less than the average physician

I partnered with our UX research to conduct qualitative interviews and determined the large majority of delinquent physicians were categorized as our Dr. Experienced persona.

Avg Doc

72

avg patients

1045

avg orders per month

Delinquent Docs

67

avg patients

956

avg orders per month

Dr. Experienced

PATIENT RELATIONSHIP

  • Sympathetic & Warm
  • Professional
  • Long-term Relationship
  • Confidently coaches patients

FRUSTRATIONS

  • Too many administrative duties that detracts focus from patients
  • Changes to routine
  • Less and less verbal communication
  • Complex technology

“I love my patients but the shear number of administrative duties I’m expected to complete detracts focus from them.”

BRAINSTORMING & WHITEBOARDING

  • If the delinquent physicians refuse to visit the orders queue how can we bring the queue to them
  • Create another way to sign relevant orders
  • Interrupt the encounter (rounding) workflow
  • This ensures they are seeing unsigned orders associated with the patient they just rounded on
  • Relevance and meaningful review (legal requirement)
  • Flexibility and efficiency heuristic (usability)

WIRES

1
2
3
4
5
1

Patient banner with clinical data for physician to document while rounding with the patient

2

Action button to complete the encounter

3

This was the new modal display of current outstanding unsigned orders for the patient

4

One of legal’s requirements was to give the physician the option to multi-select orders to sign

5

The sign orders and finalized button then was able to kick off two calls to complete both tasks without having to input credentials multiple times

RESULTS

  • After 1 month of the solution being implemented, lost revenue decrease from $418,000 to $82,000
  • After 2 months 48% of all orders were being signed in the new encounters workflow
  • After 5 months DaVita saved over 2 million dollars in lost revenue
$ 2,000,000

increase to revenue

ORDERS 2.0 BULK SIGNING

Project Background

Once the legal team saw the results of physicians signing orders in the new workflow, they were more open to discussing the bulk signing of orders. The legal team was still concerned about the “meaningful” review of orders which triggered a discussion about how to define meaningful.  Their concern was that the orders a physician would sign in bulk needed to be relevant and had to be given recently so the order would be easier to recall in the physician’s memory. This would satisfy the requirement of a meaningful review. We proposed the idea of 2 queues, 1 for recent orders; that which had been given in the past 7 days and 2 all orders regardless of how old. In the first queue we would enable to users to sign all orders at once.

Objective

We would be able to launch the bulk signing functionality in our responsive web app OneView. Responsive down to the tablet. I wanted to make sure the UI was updated, simple and familiar enough with how the same task was performed in the previous legacy app as to not create confusion but different in learning from our pitfalls of the past.

  • Multi-select functionality was not intuitive and proved to be a challenge for our users
  • UI was clunky with too many font variations and weights
  • Touch targets and icons for Sign and Dispute created confusion
  • Users requested as many orders to fit on a page as possible

Sketching & Wires

Because I was extremely familiar with the orders research that had been done before in working on the Orders Leak project I was able to start with sketches of the new orders queues. I wanted to think deeply about how many orders could potentially be loaded at one time. In the past we had only needed to load 20 orders at once now we could have hundreds and I wanted to understand the performance implications of this as I started to sketch out ideas.

Hi-FIDELITY ITERATIONS

1
2
3
1

In order to avoid having to display a checkbox for each order inn the initial view I iterated the idea of a toggle to display the checkboxes.

2

Option 2 to avoid the need for the toogle

3

To satisfy the legal requirement of meaningful review of orders the sign all button doesn’t become active until the user scrolls down to the bottom guarenteeing the user has viewed all orders they are signing.

Final Desktop

12345

Tablet

1234

Loading Issue

Performace is always a consideration with our application. The loading of potentially hundreds of orders was a concern when we received the approval for bulk signing. The importance of operational transparency cannot be underestimated. Users find waiting more tolerable when they can see the work being done and they tend to value the service more.

  • I created 3 different version of the progress loader to determine which would be the best solution
  • After a brainstorming exercise I asked our engineers if it would be possible to pre-load orders as soon as the user logged into the application
    • This was not technically feasible
  • I then asked if it would be technically possible to enable the user to navigate away from the page to complete other tasks if the loading were too time consuming
    • This idea was technically feasible
  • We wanted to provide as much system status information as well as flexibility and efficiency
1234

Results

Since the launch of OneView and Bulk Signing

  • The average amount of time a physician spends in the orders queue has gone down from 13.34 minutes per week to 5.25 minutes
  • Support calls related to the orders queue have dropped by 52%
  • We continue to have no related issues with lost revenue around unsigned order
  • Our overall NPS score for OneView is a 6