Rearchitecting Claim Preparation Work

In order for hospitals to get paid for their services, they must send claims to insurance companies for reimbursement. Efficiently preparing and billing those claims is vital to keeping hospitals afloat. athenahealth’s software was meant to help hospitals create claims as quickly and accurately as possible, but, in 2017, a confusing organization of work was slowing Claim Preparation staff down.

My team was tasked with changing the way Claim Preparation work was organized and defined so that our clients could bill claims faster and get paid on time.

A little background on Hospital Claim Preparation

Problem Discovery

Hospital Claim Preparation work was poorly defined and organized.

In late 2017, it was taking our hospital clients too long to create and bill claims.

Industry best practices dictate that it should take 5-6 days for hospitals to bill a claim, but our clients were taking 11 days. This was a serious problem, especially for our smaller hospital clients who needed consistent cash flow just to keep their doors open.

Looking at the data, we saw that Claim Preparation was a major contributor to slow billing. It took 5.1 days for a visit to get from Chart Review to Coding, accounting for almost half of that 11-day window.

We had to figure out why Claim Preparation was taking so long.

My design lead and I conducted a series of field studies and interviews in which we asked Chart Reviewers and Coders to describe their processes and pain points. Most clients reported frustration with the way their work was organized.

They had trouble finding the right visits to work on and struggled to track their in-progress tasks.

This feedback didn’t come as a total surprise. At the time, Chart Reviewers and Coders were tracking their work on a page called the Hospital Activity Summary, which was an outdated page with many known limitations.

Looking through data, user feedback, and the pages themselves, I identified three key problems with athenahealth’s organization of Claim Preparation work that were causing slowdowns.

1. Key tasks couldn’t be done in parallel.

Chart Review has two steps: reviewing for completeness and reviewing for compliance.

In order to maximize efficiency, Chart Reviewers would typically let Coders start working on a visit once they had ensured the chart was complete.

However, existing functionality was forcing Chart Reviewers to finish their entire review before sending a visit to coding, as they only had one action available to them - ‘Done with Chart Review’.

This often led to massive delays in visits reaching Coders, or Chart Reviewers adopting inefficient workarounds.

2. Buckets of work were too broad and didn’t align with user mental models.

Each type of user had been assigned a single bucket that contained all possible work, but users thought of their work as containing multiple steps with different levels of urgency or difficulty.

They were frustrated that the Hospital Activity Summary gave them no sense of how much work there was to be done in each step.

With no easy way of telling how much or what type of work they had to do, users often turned to slower, offline methods to track more specific buckets of work.

3. Worklists didn’t show information about work status or actionability.

The display of visits in worklists provided no information about whether a visit was new or recently updated.

As a result, users were often clicking on every visit in a worklist to see which had outstanding tasks. This created a sense of fear among Claim Preparation staff, as they were constantly worried about missing something important.

My team made a plan to completely change the way work was organized.

I knew that just updating the UI of the Hospital Activity Summary and visit workspace wouldn’t be enough - we had to redesign the entire architecture of Claim Preparation tasks so that work matched user models.

1. We planned to start by defining new buckets of work. Engineering could then change backend task structures to match.

2. Once we successfully rearchitected work, we would redesign the UI of Claim Preparation pages to make tasks easier to find and work on.

We decided to start with primarily backend updates before majorly changing the UI because we were nervous about making too many changes at once and wanted to limit project scope.

Design Process

Start by mapping out the universe of work.

Before we could re-organize work, we had to thoroughly understand what tasks our users performed and how they thought about them. My product manager and I extensively interviewed users and stakeholders to put together a detailed journey map of all Claim Preparation tasks and handoffs:

PDF of full map

Next, categorize work according to user mental models.

I led an open card sorting workshop with our whole team, including engineering. The goal of this workshop was to come up with important characteristics that separated types of work from each other.

I asked the team to sort the tasks from our journey map into potential groupings of work. The team eventually settled on three key groupings that we felt most impacted user decision-making:

• Role

  • Am I the right person to work on this visit?

• Stage of Review

  • What degree/type of work has been done on this visit?

• Actionability

  • Can I work on this visit right now, or am I still waiting for a physician to get back to me?

Then, establish a hierarchy of information.

Next, we had to decide which of these attributes was the most vital to user decision-making and make a hierarchy accordingly. I decided to first split work by Role, as Coders would have no interested in seeing Chart Review work, and vice versa.

I created then several options for how we might split work along the lines of Actionability and Stage of Review:

I decided that Option B (splitting tasks by Stage of Review first and then Actionability) was best for several reasons:

• The Waiting and Done groups in Option A would be almost useless, as users would not want to regularly check them.

• While Option C would be the most simple, research indicated that users were anxious about any outstanding work being hidden from them, even if it wasn’t immediately actionable.

• Option B was the most balanced. It would allow users to see how much work was outstanding, and then drill down into the visits they could actually tackle.

I created wireframes to show how this model would translate to existing pages:

Finally, start testing.

I realized that the main issue with these designs was that I hadn’t put serious thought into copy. The wording I had chosen was confusing to users and did not properly convey the meaning of the new statuses and buttons. 

Iterate on copy and try again.

I had been too concrete in my original wording. For example, many Chart Reviewers didn’t use documents and signatures as a way to distinguish between the two stages of Chart Review, and many coders wanted to pend visits for reasons beyond having outstanding queries.  

Now more confident in both the copy and the concept of my designs, I finalized front-end changes to the page in a series of mock-ups:

Despite many continuing usability issues with these pages, UI changes to the Hospital Activity Summary and visit workspace were limited at this stage because our priority was rearchitecting work management on the back-end (per our original plan). We also didn’t want to overwhelm users by introducing too many changes at once.

A beta release of these updates produced good results.

Our team built and released these updates in beta to a group of 8 hospital clients in February 2018. Results after several weeks were promising.

1. Feedback in interviews indicated that users preferred the new statuses and worklists to their old model.

2. Pre-beta and beta survey comparisons indicated that users felt they were working faster and better able to find their work.

3. Early data showed that visits were reaching Coders sooner.

We released these changes to all clients and saw work speed up.

Next Steps: There were still many usability improvements to be made.

Though we had successfully rearchitected work management to create major workflow changes for our users, we hadn’t made any real UI changes and users were still suffering from a poor experience. For example:

• Visits weren’t clear units of work

  • Rather than showing individual tasks (e.g. respond to a physician; add codes), worklists showed whole visits. Users would still have to click into a visit to get a sense of the specific work to be done.

• The Hospital Activity Summary wasn’t customized

  • The page still showed a lot of unrelated work that wasn’t specific to users (i.e. Coders saw a lot of Chart Review work).

• UI patterns were outdated

  • These pages were still designed with athenahealth’s old UI patterns, which used a wide variety of colors that did not necessarily communicate any meaning. Tables were thus difficult to read and looked unprofessional.

In response to these issues, we started to redesign the UI of these pages (the second phase of our plan).

My design lead and I held a workshop with the rest of our team to figure out how we might make individual tasks easier to find and more customized to user roles.

As a result of this workshop, a new team was created and charged with creating a backend task engine that would allow our team to easily break hospital work out into distinct actions, e.g. Validate a Document.

My design lead and I also mocked up a potential future task dashboard and new visit workspaces. The dashboard would only show work that users needed to see and would make use of athenahealth’s new design system:

The team plans to begin iterating on and developing these designs in 2019, ideally once the backend task engine has been completed.

Key Takeaways

• Roll out UI changes with backend-focused updates so that good interface design isn’t left behind.

  • I was initially comfortable with our plan to prioritize larger workflow changes over a UI redesign for Claim Preparation work. However, once we had successfully rearchitected work management, it was difficult to then influence the team and leadership to continue to work on UI changes.

  • If I were to do this project again, I would push for regular UI updates to be rolled out alongside our workflow changes. That way, major UI changes could be tested at the same time as workflow changes, and UI improvements wouldn’t be saved for last. I was able to successfully push for this strategy in future work, e.g. making a new Charge Review page.

• Know your users’ language.

  • When initially developing new statuses and actions, I had been extremely focused on user mental models when it came to how users categorized their work. However, I forgot to pay attention to the words they used to describe that work. As a result, the team lost a lot of time testing new versions of copy when we could have incorporated questions and observations about language into our earlier research.

  • In future projects, I made a greater effort to listen out for users’ words and terminology so that my designs would reflect their language.