Insurance Errors
Solving Every Issue Ever
Over 600 issues can come up when filling a prescription, just how would you go about solving every one of them?
Process: User Research, Usability Testing, Interaction Design


Billing Exceptions

Title: Insurance Error Queue and Reconciliation Process – UX

Client: Walgreens Boots Alliance

Process: Research with Users and Subject Matter Experts, Task Analysis, Experience Map, High Fidelity Prototypes

Solution: Ability to prioritize cases with additional  and capability to fix over 500 different errors.


You’re at the pharmacy waiting desperately to pick up your prescription, you’ve been feeling god-awful for far too long and your doctor feels like some antibiotics will help you get back on your feet.

Your nose is leaking and there’s a pounding coming from somewhere in the vicinity of your left eye.  The pharmacist looks saddened when you approach the counter, “Sorry, I’m having trouble with your insurance, can you come back in 15 min.”

You say yes because it is all you can say but you wonder, ‘How hard can this be?’

Exploring Layouts
One Page or Multiple?
Interaction Explorations
Individual Subsections

It is the hardest thing for the pharmacy system to do.  A prescription can be rejected for over 600 different reasons.  Some could be considered simple like an incorrect birthday; others might be more difficult when your prescription has been flagged for fatal interactions with a drug you took recently or years ago.  Secondly, the reason shown is only the most important reason; it is likely there are secondary or tertiary reasons.  Thirdly, fixing reason A might cause a rejection for a new reason.  Finally, while some issues can be fixed in minutes, so issues can persist for months.  I was told this was more common with exotic drugs (cancer medications).

A pharmacy might have 100 of these rejections or exceptions as they’re called.  My work on this project focused on two main areas.  Displaying the Exceptions in a manner which allowed Pharmacists and Technicians to be able to triage Exceptions quickly and giving those same employees the methods they need to fix the issue and dispense your cold medication.


The Queue

The biggest improvement I was able to make to this process was the inclusion of a Status column in the list of exceptions.  This allowed Technicians to easily see unaddressed items or items that had been languishing.  This quality of life improvement decreased unproductive time opening and closing exceptions and gave more control to the employee on how they wanted to work through their Queue.


Now, we’ve established that there are a lot of reasons something might be rejected.  There is an equal amount of ways to solve rejections and those ways touch every corner of the system.  To maintain a source of truth and incorporate strong security measures, all changes to Patient, Prescription, or Insurance information would need to be made within the Exception module.

This made the module, essentially, the heart of the software.  There were many iterations, constant revisions, and a couple complete overhauls of the interaction model to ensure that the page mirrored how users would complete these tasks in the singular fashion (like changing a birth date) and still incorporate all the freedom they needed to change the prescription as well or any other piece of information contained within the system.

Landing Page for Resolutions
Editing Information
Historical Information

This project was a great experience.  I learned a lot about multi-system design and the restrictions of such (information parity had to be ensured with the older legacy system), being able to pivot quickly when requirements change, and how building towards the future always gives today room to work.