Creating a Charge Review Workspace

When a patient is treated at a hospital, every aspect of their care is captured in charges. In order to be reimbursed for services, hospitals must list these charges on a claim and send it to the patient’s insurance company. Hospital Charge Review is the process of ensuring that these charges are represented on the claim completely and accurately. Efficient Charge Review is vital to keeping a hospital running, as late charges may not be reimbursed.

In early 2018, Charge Review was taking longer than expected across our hospital base and users were feeling dissatisfied. I discovered that athenahealth’s review paradigm didn’t align with the way our users actually did Charge Review so I set off to create a new workflow that fulfilled user needs.

Problem Discovery

Charge Review workflows were extremely slow and frustrating to use.

While on-site at hospitals researching issues with work management, my design lead and I started to get some unexpected feedback:

My team had considered Charge Review to be a straightforward process, but now we were hearing that it was one of the biggest bottlenecks for hospitals. I looked at data around charges to see if these complaints were reflected in hospital performance.

I found that Hospital Charge Review workflows had been designed for users that didn’t exist.

In ambulatory clinics (athenahealth’s main client base), there is usually a single Charge Reviewer who works in the Billing office, and reviews all charges for each patient.

Designers of the original athenahealth hospital product had assumed that hospital charging worked the same way.

However, hospitals have many different departments and patients often have 5-10 times the number of charges as clinics. It’s very complicated to review this wide range of charges for a single patient. In most cases, therefore, clinical staff are the ones who do Charge Review in hospitals.

I termed these users Ancillary Techs, as they were often technicians.

Ancillary Techs are distributed throughout the hospital and they look at charges on a department-by-department basis (i.e. a lab tech looks at all of the lab charges for a day), rather looking at all charges for a given patient.

The mismatch in paradigms (department-basis v.s. patient-basis) meant that Ancillary Techs had an extremely convoluted Charge Review workflow. I identified several key issues that were preventing these users from doing their jobs effectively.

1. There was no easy way to see all charges for a given department.

Ancillary Techs had to:

• Look up individual patients from their paper records

• Search for each patient and click through many pages to reach the patient’s charge list

• Filter a long list of existing charges to see their specific department

It took around 11 clicks just to find the right charges for the right patient, and Techs had to repeat this process for every patient seen by their department.

2. There was no way to indicate that a specific department was done.

3. Adding and editing charges took users out of context.

In order to fix these problems, I planned to develop an entirely new charge review workflow that allowed Ancillary Techs to add, edit, and review charges in the simplest possible way and in accordance with their own review paradigms.

Design Process

First, we held a Design Sprint to generate ideas.

This problem lay somewhere between our financial product (where I worked) and our clinical product. I realized that it was likely a lack of cooperation between our products that had created this issue in the first place.

My design lead and I held a Design Sprint with other designers and product managers from the clinical product in order to brainstorm solutions across product lines.

The goal of the Design Sprint was to settle on and test a single idea for improved Charge Review.

We decided to make a brand new page for Charge Review rather than redesigning existing pages because:

• The old workflow was inextricably tied to the Billing workflow and Ancillary Techs were not Billing staff.

• We wanted to build this page with a cleaner UI, which would be much more difficult in the context of the old workflow.

We landed on one idea and mocked it up:

We tested this design with 5 users to mixed results:

Despite the many issues with this design, users saw potential in the core concept, so we decided to start building it for real.

We built and released an MVP version.

The team and I knew that building a new Charge Review workspace would be a major time investment, so we decided to start with an MVP. That way, we could ensure users’ foundational needs were being met before investing too much time into the new page.

The first version of the page was as barebones as possible - it only let a user find charges for a given department and date. The user could then mark their department as ‘Reviewed’. To add or edit the charges, users had to go back to their old workflow via the ‘Add Charges’ link.

I knew there was a lot lacking from this page, but it already solved two major problems:

• There was now a way to find and review charges for a single department

• Users could now mark a single department’s charges as complete

We released this page to our entire hospital base in March 2018.

The first release showed we were on the right track with a long way to go.

Outcomes of this first release were, at first glance, not very good.

• 17% page adoption

• 1.6 out of 4 usability score (indicating major usability issues)

  • This score was determined via heuristic analysis by our DesignOps team

• No measurable shift in overall time to complete Charge Review.

However, we had anticipated results like this and now had a good jumping-off point for continuing to develop the page.

I created athenahealth’s first pattern for inline editing in table rows.

athenahealth had very few consistent patterns for adding and editing. Generally, users had to add and edit content in modals or on separate pages, as with the existing Charge Review workflows.

I decided that this was unacceptable for our page, as users needed the context of their full charge list, so I designed an inline editing and adding feature instead.

I mocked up a many different ideas and got feedback from my team, as well as from the research panel.

I settled on a design shown in the prototype to the right.

• I made the lines on editable rows blue to draw attention to them and prevent users from losing track of their work.

• When adding a row, another charge line would appear once the user filled out all required fields. This would make adding multiple charges more seamless.

I also included a secondary department filter to allow for more flexibility.

We had assumed that when users thought about ‘their’ department, they were thinking about the type of charges administered, e.g. an ibuprofen tablet is a pharmacy charge. However, some charges weren’t so easily classified. We found that in some cases, what mattered was where the charge was administered.

I interviewed panel members extensively about which charges fell into which category for their hospital. There was a fair amount of variation in their answers so I made a second filter for ‘Service Department’ (where the charge happened) so that users could choose the right filter for their needs.

We released these changes in a beta and saw very positive results.

In late May 2018, we released the inline editing/adding and the new department filters to our research panel in beta, and then gradually expanded the beta to include clients who were not part of the panel in order to get new feedback.

Within a month or so, we had met our beta goals:

Client feedback was also very positive:

The page now solved all three of the old workflow’s initial problems:

• There was a way to find and review charges for a single department

• Users could mark a single department’s charges as complete

• And now, users could add and edit charges seamlessly without losing context

The second release showed we had made Charge Review more efficient.

We released the newest version of the page to all hospital clients in July 2018.

Next Steps: Expand the research panel and keep iterating.

Despite these successes, I knew the page could still be improved to make Charge Review even easier and faster.

We added more users to our research panel and continued holding fortnightly feedback sessions.

In order to manage this large amount of feedback, I stored ideas for improvements in a prioritized backlog of feature updates and UX Debt.

I consistently updated this backlog with feedback, including stakeholder suggestions and takeaways from our own analyses, e.g. cognitive walkthroughs.

Based on feedback, I decided that the next major update to this page should be improved flexibility and customization:

Due to other business needs taking priority, these designs haven’t been fully built yet, but concepts tested well with the research panel. The team has begun developing new filtering and sorting with plans to implement the full design in 2019.

Key Takeaways

Respect Conway’s Law.

Initially, I couldn’t understand how issues with Charge Review had escaped my team’s notice for so long. I soon realized it was because the problem was financial in nature but clinical users were the ones affected. Since our products were split along clinical/financial lines, members of each product had ignored the issue because it “wasn’t our problem”.

• Even though my team took on the development of this page, we worked extensively with designers and product managers from the clinical side, often getting their feedback on designs, seeking their insights, and sharing our learnings.

• Working cross-product allowed us to develop a page for an unfamiliar set of users and taught me to watch our for problems that might be overlooked due to ownership conflicts.

Treat your users as partners.

One of the most rewarding aspects of this project was getting to work so collaboratively with users.

• Beyond just testing designs with our research panel, I regularly showed them how their feedback was being used to make updates. When we couldn’t implement users’ suggestions, I gave them clear reasons as to why and then worked with them to brainstorm alternatives.

• I learned that when I was candid with users and treated them as stakeholders, they were grateful and gave more enthusiastic feedback as a result. We received many emails like the one on the right that expressed the happiness users felt at being heard.