CareManager: Benefit Predictor
The Problem:
Benefit Predictor was created in order to integrate HealthEdge's Payor and CareManager products. Payor deals with health insurance companies' benefit plans and financials, while CareManager is for users who are in charge of managing care for patients.
The user we focused on was the Utilization Management nurses. A UM nurse is in charge of approving or denying requests for services that come in from providers with the patient's benefits. Prior to Benefit Predictor, a UM Nurse would need to exit the CareManager program and open Payor in order to find this information. Any solution would call for the two programs to be integrated, so that data would be pulled from Payor into CareManager without the user needing to open the program themselves.
Additional challenges included the vast amount of information that would come in from Payor. Health Insurance has complex benefit rules, and therefore, a large amount of information was needed for the UM nurse to make an informed decision. This includes member responsibility information, the lifetime maximum for the member, annual maximum, etc. It was extremely important to show that information in a clear concise manner. The data came in a tree format, which was difficult to read.
First Concepts
The first concepts were quick ideas of how the data might be split in order to make it easier to scan. The drawing to the left includes tabs that divide the benefits information by In Network, Out of Network, and Global services/providers.
The overall limits are at the top, so that users can easily rule out procedures that are blocked by them. Then benefit exclusions are shown and then the individual benefits information.
Second Concept
Keeping the idea of having benefit limits at the top of the page, our later ideas put all the benefits types (In Network, Out of Network, and Global) in the same table. In addition, the results would return both matches and partial matches by the same benefit type. Meaning, for example, that complete matches for physical therapy would be always followed by the partial matches for the same benefit.
The idea was that the benefits would be quickly scannable and that UM nurses could then help patients make the best decision about their care. In addition, users could search the benefits list in order to quickly filter the information for the benefits that they were seeking. They were able to search using plain English phrases, but also by using ICD 10 codes.
When I showed this concept to potential users, they really responded well to the idea of the information all being in one place, instead of being hidden behind tabs.
Final Concept
Users preferred having all the information in one table. However, the more I communicated with engineers and Payor experts within our company, the clearer it became that this wasn't a feasible idea. Not only was it difficult to achieve, but benefits matches and partial matches wouldn't match up neatly from each category, turning an easily scannable table into a disorganized one.
Therefore when it came to the final concept, matches and partial matches were split into multiple sections. Each was given its own table, which could be collapsed in order to save space.
The results could be further filtered by using tags. Users could jump to a position within the page by clicking on the pinned links at the top of the screen. This allowed for users to quickly navigate the page and easily get the information that they need.