CASE STUDY
Surprise Billing Negotiation Tracker
Federal mandates creating more work across the company.
Role
User Research / UX Design / UI Design
Team
Project Manager, Business Analyst, Front-End Developer, Back-End Developer, Data Engineer
Discovery
Problem
With the passing of the No Surprises Act (NSA), out-of-network providers could now negotiate services performed with the payers to prevent surprise billing for their patients on individual and group health plans. The operations team within the health plan was receiving an onslaught of requests to negotiate from providers. They were managing these requests with Excel spreadsheets and email, but needed a solution that would help not only their team, but the other teams within the company effected by this new process.
Business Requirements
The business obviously had a focus on the protected health information that would be floating around and wanted to ensure that different security role levels depending on a user’s access level within the company would be implemented.
Contraints
The federal mandate was ever-evolving as feedback to CMS came from hospitals, providers and payers regarding the new requirements. Getting an application out fast was of utmost importance so that enhancements could be made once new stipulations came down from CMS. Additionally, storing the provider request PDFs and spreadsheets would require large data storage space. The application would most likely display multiple data tables and needed to be built on a library that could accommodate a robust data table grid with full features. The development team decided to go with MUI for React and I would need to base my design off of that design library.
Users
There were 4 different departments within the company that would be using the application: Operations, Finance, Legal and Executive. Within those departments were multiple levels of end-users that needed to be accommodated.
Desired Outcome
A web application that will house all of the incoming requests, track individual request’s lifecycle throughout the IDR process and offer reporting for senior leadership. The application should also adhere to each step in the process's fixed timeline of events.
Research
User Interviews
Because there is not a current application to focus on regarding pain points, we focused on what their current process was and those pain points, what their goals were and what was absolutely necessary to complete their work.
Card Sorting
Based on the takeaways from the user interviews, we performed a card sorting exercise to help us narrow down important features and topics. It was determined that in addition to focusing on following the timeline set by the CMS IDR process, we needed to incorporate multiple tracking and reporting features to aid users in their work flow.
Information Architecture
Utlimately, all of the requests also needed to live in a singular database and have new data appended each step of the way. We decided MongoDB would be the best way to go.
Personas and their User Journeys
There were multiple departments with multiple users that were all needing this app to accommodate them. We felt personas and user journeys were appropriate as opposed to specific use cases.
Solution
Behind the Scenes
We wanted to reduce the manual effort as much as possible for all users. We created an upload functionality that would take whatever format of data the providers sent to the Operations department at the onset of the request and place it in our database, removing the need for manual data entry. We also needed scripts that would determine the eligibility of these requests and the reason why.
Reporting
Due to the large scope of reporting across the different departments' needs, we chose to separate the reporting from the application itself. Tableau would provide robust dashboards that would enable savvy analysts to get answers they needed quickly and discover new trends in the data. We could also restrict access to manager and executive level.
Lifecycle of the Negotiation Request
We needed a way to track the negotiation request at a claim level as it traveled from Operations to Negotiation to Legal and back to Operations. There also needed to be aging alerts set up to notify the specific department that it was essentially their turn to get to work.
Conclusion
Takeaways
This application proved to be extremely difficult to approve with stakeholders because of the ever-changing requirements from CMS. As soon as we would complete an update, run through usability testing and move towards stakeholder sign-off, there would be a new document or new way providers were communicating or new way the legal team was managing their side of things. It ultimately took an entire year to lock down a final version of this application design.
Outcomes
Because of this application’s reporting, the company was able to identify two provider groups that were submitting the highest volume of requests and the highest cost of requests. Those groups were then contracted with the company as in-network, greatly reducing the number of new requests and ultimately serving the company’s members better.