Contract renewals are a slow process that involve multiple stakeholders, signoffs and can take several years of back-and-forth with the client. To come up with an accurate estimate of how providers are affecting our cash flow positively or negatively, Contractors will go through an audit of the providers services and spend - alternatively, the providers internal bookkeeping might reach out to say they're losing money.
In any case, the provider and insurer go through the arduous process known as contract modeling to estimate the current spend and determine if the insurer should raise rates, maintain current rates, or give money back to the provider.
The Contractor maintains contact with the providers and, following a series of negotiations and internal review with market leads, will bring in the Contract Underwriter to model the provider's spend.
The contracts are usually formed at the system level - meaning they model for multiple facilities and professionals at once. When the system and its providers have been identified, the contract underwriter will open their modeling tool. The current process looks like this:
What the tool does is compare the trajectory of the provider's current claims, charges and reimbursement to a new modeled contract with our estimate of the provider's increase in charges, and our theoretical rates for the modeled period. Here is a simple explanation below:
Now, we currently have a tool that does most of this. However, the accuracy is low because we bundle the data for several products (line of business) that need to be separate in order to read the data correctly.
To solve for the problem, Evernorth had to design a whole new application and model to sort the data, provider a better user experience and improve our business.
When I joined this project, it was already several years in the making and had no designers. They had outdated wireframes the engineers loosely based their front-end on, but it was a disaster to say the least.
Working with the product team and engineering and beta users, we identified some key areas where the design needed to be improved for the users experience then went through a major overhaul of the architecture.
Some of the issues identified by the users were as follows:
Non-existent navigation
Users were brought to this page that would populate after a provider system and dates were selected. Everything else they had to figure out on their own.
Timeline miscommunication
Users did not understand how to properly fill out the timeline and progress to results. There was no indication of what tasks were required or that all their providers were tied to one timeline.
Rate sheet edit / copy / save
The rate sheets are the backbone of repricing and users could not figure out how to work them.
Reports unorganized / missing
The final output was difficult to read and lacked key information to form a new contract.
I came up with a new solution to address the users needs. The design went through multiple iterations in attempts to make the UI as simple and elegant as possible. I've included some iterations below:
The design we settled on incorporated a sidebar that housed the current contracts and their providers. The user would go in sequential order to update each contract and key information. The emphasis was on guiding the user and making the UI scalable for the addition of professionals as well - this incorporation is still TBD.
After our initial hypothesis of the design, we separated the design into multiple features and started user testing to determine accuracy of content and usability.
The backbone of the new design was the sidebar. Users would use this to navigate and manage providers within their scenario.
The feedbackfeedback was mixed: the design was embraced but there was a problem with grouping by current rate sheet. The legacy tool uses this method but it was still confusing and lacked functionality to collect data at a provider level.
As a team, we collectively decided to change the process, breaking the groups up into individual providers. The users would get more flexibility but still needed a way to edit multiple providers at once. The tradeoff for more flexibility was to incorporate a bulk editing function where users could add rate sheets to multiple providers or update their charge increases.
Giving back to the design system
When we had final approval for the design, I created specs to give to our team and back to our internal design system: this was a new UI component we wanted to leverage for other teams as well.
The architecture of the tool was step one, then came the rest of the features. We sorted the experience into the most crucial for the user and split them up by development cycle. I would then design and test the feature, handoff to development then followup with design QA in 2-week sprints.
Feature: Rate sheets
The final output was difficult to read and lacked key information to form a new contract.
Inefficient process
Hand-keying codes was miserable. Most rate sheets contain several hundred codes which equated to hours of work.
Service Categories
The biggest issue was this method of data entry and storage did not capture the category of spend by contract. We might accurately collect the data, but there would be no way to analyze and understand where the client was spending the most.
Working with the users and subject matter experts, we implemented a new system by which users could edit seamlessly without opening each line. Additionally, the services were bundled by category and preloaded on the back-end, meaning the contract underwriter wouldn't have to waste time searching for codes.
The project has a ton of features and a lot of thinking went into every part. As the lone designer on the team, I designed everything shown and am still working to finish all the features required to make contract modeling a great experience.
