Medical Billing System
If you understand medical billing then you know the complexities that are involved. From the various billing codes to the numerous providers and plans and the specific rules that apply from state to state, it is not easy information to digest or present. There was a need for a medical billing solution that would integrate with other healthcare case management-focused products in the company's suite; one they could monetize by bundling with the other products and one that would add process value to the other products.
This case study will describe the design process of how I developed the interoperable enterprise-level billing solution interface to a modern but warm and friendly look that is digestible and user-centered.
Google search of 'medical billing systems'. Interfaces are very tight with information.
*In consideration of a non-disclosure agreement, information on the project may be omitted or obfuscated in this case study. The information in this case study is my own and does not reflect any views of my employer and clients.
My Role: Lead UX/UI Designer
Team: Consists of Product Owner, Business Analysts, Developers, and Director of Product Design
UX/UI Design Lead
I was brought on early of the design of this product when it was considered an MVP. Teaming up with the Product Owner and Business Analysts, I was the point person for communicating with the stakeholders the design decisions that were presented. I also worked closely with the development team to provide guidance on styling specifications such as CSS code for components, pattern standards, and interaction behaviors to name a few.
Design a new data-heavy interoperable solution
Medical billing and claims data consists of many variables including service event and procedure codes, program and provider information, and changing variables such as costs just to name a few. Consider this as a very complex and detailed spreadsheet.
Presenting lots of data in a clean and scannable UI so users can work quickly and more efficiently
Providing visual consistency for integration with our other products in the suite
Designing functionality that would make calls to outside systems for updated data
Product needs to standout in the marketplace
Understanding the Users and Their Needs
Billing Staff from Provider Organizations
Billing Staff from County/State Health Departments
Key External Actors:
Payers (Health Insurers)
Most of the competitive research we did was through online searches and looking at competitor state and county billing solutions as well as how we were currently doing billing in our own systems.
The main business need for this system was to bill providers' healthcare claims to state-funded health insurance and process payments received.
Working with Domain Driven Design and Specific Vocabulary
Working with the architects and the business analysts, many working sessions were held to draw out the work flows using Domain Driven Design. From these working sessions, I were able to understand relationships between the various business requirements and how those relate to each user's needs. We were also able to correctly develop a prototype based on the Vocabulary that was defined. Since some of the patterns needed for this application existed in other products, we were able to carry some components over to create a prototype that could be shared with stakeholders and demoed to potential clients already using our other products.
Examples of the Domain Driven Design workflows the team developed that I referenced in creating the prototype:
Making lots of Data Readable and Actionable
Knowing that there was a lot of data that needed to be scanned easily to provide efficiency for the users, I knew we needed to design with a clean and open UI with more spacing between data elements than what we had seen in other products.
While this product started out as an MVP, it quickly grew much larger once the executive team saw the value and we were gaining interests from clients that had our other products. Currently, we are in a state where we need to understand the nuances from client to client and determine what would go into core product versus a branch of the product.
Some features we implemented included:
Bulk actions such as editing
Making statuses stand out
Global actions versus targeted actions for claims
A filterable Adminstration Screen
Change History/Audit log
I provided a detailed style guide of the pages and the components. Most of these carried over from the Design System but I was able to provide more screen specific guidance.
This project has been a great learning experience for me. Being able to collaborate more closely with the architects and the analysts for the Domain Drive Design has been very eye-opening. Some of the challenges I faced was how to communitcate all the information they need in a easy-to-read format. While we still used a lot of data tables, elements like icons, shaded backgrounds, etc. were added to make more important info stand out. Using tables is how these users are used to working in and so we didn't want to steer away from the users' mental model of how something should look and work. I also made sure the UI was easily readible by adding in enough spacing around the elements as to not feel crowded.
So far this product has received a lot of praise and has already been added to a couple contracts. The account managers and sales team attribute the success to the overall ease of use and the visually appealing user interface.