Del Sol

Portfolio/Work/MedImpact MIDAS Pre-Pay

2022 · Case study

MedImpact MIDAS Pre-Pay

Case study: a pharmacy claims review redesigned from three applications into two screens, with a 50% throughput gain.

Project Overview

So what are we talking about here?

MedImpact is a PBM (pharmacuetical benefits management company). One of the key deliverables MedImpact offers its clients is the ability to review pharmacy claims prior to payment through their MIDAS application. For this Case Study we will look into the Pre-Pay flow. Pre-pay (prospective) reviews the claim in a 3 day period prior to a pharmacy payment thus preventing pay-and-chase scenarios. These pay-and-chase scenarios are typically this: a pharmacy is paid, an audit is completed, discrepancies are found and then we have to go back and chase the pharmacy for payment.

What's the problem with the current MIDAS Pre-Pay flow?

Users have voiced the identification, selection and review of claims is inefficient, including working within multiple disparate systems to complete a review. The current flow is convoluted and working back and forth from multiple systems to complete a review is cumbersome and slow.

Time for a redesign - for a more intuitive and engaging workflow solution!

We are currently able to process 30 claim reviews a day on average. Our goal is to provide the ability for a user to process significantly more quality claim reviews through increased automation and integration of required data from external applications. This will be established with the redesign of the Pre-Pay flow which will provide the users a more intuitive and engaging model and workflow. This effort will help auditors find claims that have a higher client savings from ingredient costs and provide significant time savings completing claims. This reduction in clicks as well as an intuitive and easy-to-use interface will also reduce user input error.

Context around this case study

This case study revolves around the e2e ideal-state contextual flow of Pre-Pay vs its current state and user pain points.

How UX Helped

As lead UX for this initiative I scoped out this initiative and prioritized the UX deliverables based off business needs given a tight timeframe. Not all elements of UX analysis and design were budgeted for the project so I leveraged what I could within the time constraints. So that being said...

What did I provide?

  1. Contextual inquiry around current user interaction outlining several pain points
  2. Defined user personas and roles. Pre-Pay Auditors, Clinical Analysts, Credentialling Analyst
  3. Huerestic analysis of current system helped me provide current user flow vs target flow diagram
  4. User Journey mapping scenarios
  5. Conceptual modal via iterative wireframing
  6. Highly interactive and high-fidelity Axure RP prototype used for usability testing and stakeholder demos

Research & Analysis

Contextual Inquiry / Pain Points

I interviewed 4 users: 3 auditors and a MIDAS supervisor. I asked the supervisor to create a common task scenario within Pre-Pay to walk through with the other users. Both roles needed access points to multiple applications to complete their scenario. It was very disjointed and to move from one application to another (MedAccess to Drug Search and back to MIDAS) continually took the user out of their workflow. The scenarios were realistic and the users stepped through the paces. Even with all the given data needed and no blockers, the process still took argueably too long with so many touch points and back-and-forth clicks. Upon asking the users how they feel with the process within the given common scenario, there were several responses:

  • "UI is not easy for me to keep track of what I have audited and where I left off - so very easy to lose track and time-consuming"
  • Takes a long time to train
  • Lack of automation
  • The screen format is not intuitive vs improved and better formatting of screen on UI.
  • "Too much information on the page that I don't need, and some stuff i need isn't there"

Huerestic analysis of current screens

Take a look! Click those images below for a quick glance to show you how convoluted and visually confusing this process can be. These are just three screen shots. Download the document that outlines the process, because sadly... there are just too many clicks and too many confusing screens to fit on this webpage that outlines completing a review.

Current-state claims review screen
Pre-Pay landing page
Current-state claims review screen
Pre-Pay details page
Current-state claims review screen
Pre-Pay details / edit screen

Current Flow

The current flow touches 3 different applications to complete one review. It is also missing some key features that users of MIDAS have long sought after. It was designed by developers and UX was not part of the process which captures the business requirements, but skipped on the user and their needs.

Download Current Flow

Current-state process flow diagram
Current FlowDownload Visio

Target Flow

The target flow will be an intuitive wizard-based UI user experience that will greatly reduce touchpoints. This will get claim completion out faster to foster user and client delight as well as greatly reduce input errors. Instead of 3 applications to work within, this will comprise of a single access point for the entire Pre-Pay flow. This new redesign will also incorporate a few new features that will enhance usability and still keep everything tidy onto ONE screen in the UI!

Download Target Flow

Target-state process flow diagram
Target FlowDownload Visio

Iterative Wireframing & Collaboration

We've spoken with the users and have a list of theirs and the business requirements. The flow model has been created and we've collaborated with the Voice of the Client. With this, we began wireframing out the Pre-Pay review process. The UI will consist of only two pages. One landing page/queue page and one details/edit page.

These were whiteboarded in Miro Board and sketched in Axure RP for rapid review, then iterated. Once we had something we feel was baked enough to place in front of the users, we moved on to the next step... Interactive Prototyping.

Queue Page

  • The queue allow the will and view their Pool of claims for review
  • Ablility to move the claims from the Pool to their Selected Claims working queue
  • Allow the user to re-assign claims
  • Allows the user to remove claims from Pool
  • Tabs the user between Pool and Selected Items
  • Users can select claims from Selected Queue to commence work
Wireframe of the redesigned claims queue and detail page
Wireframe SnippetPre-Pay landing page / Queue

Details Page

  • View Associated Claims directly in UI. No more bouncing back and forth from MedAccess
  • Displays only relevant claim info. Info top down in heirarchal order
  • Allows data entry adjacent to data view fields
  • Contact History is combined within data entry area
  • Content area for generating letters to pharmacies and uploading additional documents
  • Global notes entry
  • Can mark as completed once edits are saved
  • Claim exclusion section for alerts
Wireframe of the redesigned claims queue and detail page
Wireframe SnippetPre-Pay Details & Work Area

Wireframe Walkthrough

Here is the wireframe stage as an actual walkthrough. Worth stressing: this is not a slideshow of static images. These wireframes were built and clicked through in Axure RP — grayscale, annotated, and already navigable, with the layout intent written directly on the page. You can see the callouts for the alerts region, the claim exclusion area, the two-column split, and the expander that pulls in external data that previously required a second application.

Getting structure clickable this early is the point. Users could move through the flow and tell me it was wrong while it still cost minutes to change, rather than after it had been designed in full.

Interactive Prototype & Usability Testing

This interactive Axure RP prototype steps through the e2e Pre-Pay flow. The link takes you to the Axure Share site where you can view the iteration process from wireframing to final prototype. There were a few more iterations, but for this demo, I kept it concise.

PW: Demo01

Prototype Walkthrough

This is the same flow at production fidelity, and it genuinely functions. Queue filtering, row selection, moving claims between the pool and my working queue, opening a claim, entering review data beside the data being reviewed, logging contact history, uploading a document through a real file dialog, and saving a claim to Pending with a confirmation. All of it built in Axure RP.

That level of interactivity is exactly why the usability sessions worked. I could hand a user a scenario and watch them attempt it, rather than walking them through screens and asking them to imagine what a control would do. Behavior, not opinions.

A note on the visual design. This was delivered in 2022 against the design system the company used at the time — an older system than the one they run today. The work was done inside it rather than around it. A redesign that quietly ignores the existing design system produces a screen that cannot ship, and tends to get rejected for reasons that have nothing to do with whether the workflow was right.

Interactive claims review prototype
View the Axure Wireframe & PrototypePW: Demo01

Usability Testing

Testing was conducted online with scenarios for both supervisor and claim entry roles. Each session was recorded via webex allowing us to review user behavior. I notated areas of user delight and concern and acquired qualatative user feedback that was prioritized and made into action items.

Usability Script 1 | Usability Script 2 | Testing Results

On Axure RP

Why I am calling out the tool

Both walkthroughs above came out of one environment. The wireframes were not thrown away to start the prototype — they were raised into it. That continuity matters: the structure users validated at grayscale is demonstrably the same structure they tested at full fidelity, and nothing got quietly redesigned in a handoff between two tools.

Interactivity is what makes testing honest

Axure RP let me build conditional logic, real data sets, and state that persists as a user moves through the flow. Select claims in the pool and they are in your working queue when you get there. Save a claim and it moves to Pending and tells you so. That is the difference between running a usability scenario and narrating one.

Both rounds of testing on this project ran against that prototype, before engineering wrote anything. Every defect found in those sessions cost an afternoon of my time instead of a sprint of somebody else’s.

And it is still a live skill

Figma is where I work now, and my recent projects reflect that — including prototyping with Figma Agents against a governed design system. But regulated and enterprise environments still run on Axure, and plenty of teams have years of interaction specifications sitting in it. Being able to read, extend and test in a legacy tool is worth more than pretending the whole industry moved on at once. The BD Inventory Optimization Analytics case study in this portfolio is the same approach applied to a different product.

Results & Lessons Learned

Real Quantitative Results!

  • Prior to the launch, users were processing approximately 30 reviews per day. Post launch, they are now processing 45 quality reviews a day on average. This large increase of throughput has exceeded expectations!
  • The redesign is helping auditors find claims easier that have a higher client savings from ingredient costs
  • There is recorded savings from 12 minutes to 7 minutes to complete a claim. This translates to a 2.5hr time savings per day per auditor!
  • User error has been greatly reduced due to more automation and reduction of clicks to complete a review
  • The time it takes for training new employees has been in half

Message from the the MIDAS supervisor and SME

“This redesign has exceeded our teams' expectations. There were some metrics around reduced clicks and improved workflow, but the ease at which the users can now complete tasks is very impressive. In addition, onboarding new trainees will be much easier with this new process. Thanks to everyone who took part in this endeavor!”

So what's next?

The development team has built and launched this application and all the upfront collaboration with the users and usability testing has paid off with an engaging and delighful product for our clients and users. Next up... refining the application with some additional features that were not part of the MVP. Then rinse/repeat the design process!

Next case study — Simply Rest