Perspectives
June 17, 2022
A few years ago, I was a part of a team that worked on designing a software tool specifically to file and track managed care claims in the US. The business goals identified were to:
Reduce the rejection rate of the claims
Increase the efficiency and the capacity of the billing team
Minimize the cycle time for claims processing
Read More..
A few years ago, I was a part of a team that worked on designing a software tool specifically to file and track managed care claims in the US. The business goals identified were to:
Since mimicking what the established software was doing would need a lot of time and money, we had to think of an innovative approach. We had to deliver the needed functionality within the allotted budget and we had to deliver it quickly (build the software in a minimal timeframe).
As a team that had experience in both medical billing/coding and building software, it brought the best of both worlds together. After a lot of deliberations and brainstorming sessions, the following key design aspects were considered to achieve the above-mentioned goals:
I came across a very interesting concept that permanently changed the way I look at the world (for good). Our team was obviously supposed to minimize the rejection of claims by the insurance plan during the adjudication process and there were two ways we could do this:
An example of this is to validate the member(patient) demographics information before using it in the claim form. In many scenarios, the member might have moved addresses and forgotten to update the new address with the plan. Now in such scenarios, if we use the new address of the member, the claim will get rejected since the address in the claim won’t match with that in the plan database.
Hence the primary source of member demographics information needs to be the demographics files, or the monthly rosters as shared by the plan. We can use the member demographics information directly from these sources while creating a claim. The same thing can also be applied to the physician information that goes into the claims form.
The next learning came from accepting that human errors are inevitable. Knowing that medical billing is predominantly data entry, auto-populating would help in the following ways:
It is equally important to identify the information which can and should be auto populated. The information which is comparatively stable information (i.e., doesn’t change very frequently with every claim filed) should be preferred.
After some analysis, we figured out that both member information and physician information looked promising options as neither was dependent on the medical condition of a person and hence was less likely to change with every visit. This information was also straightforward with no intelligent processing needed, we simply could fetch this information (already available in our database from member files and credentialing forms).
We designed the system in such a way that the user would only identify the member and the provider/physician, the rest of the information would be automatically populated by the system itself. The user could edit this information if required, providing them with the needed power to ensure only clean claims go out.
Even after figuring out the primary source for the information and auto-populating what could be, one of the biggest challenges was to figure out a way to validate the claims before sending them out. Rejections while adjudication causes damage in multiple ways:
This could be minimized by designing a cost-effective and efficient validation process. The traditional approach would be to either build or buy a robust comprehensive rule engine and then feed it with a never-ending list of checks. On evaluating the option to buy an already existing rule engine we found it to be very expensive. So, we moved towards the evaluation of building a traditional rule engine ourselves, here again, we were challenged by longer timelines.
It was the Pareto Principle that came to our rescue. We used the data to identify 20% of the reasons responsible for 80% of the rejections. (The insurance plans provide this data for each claim very judiciously and sincerely). These reasons were then converted into rules. We thus implemented a lean rule engine with only these 20% rules and ran multiple iterations to iron out any glitches. This helped us create maximum impact at minimum time and cost. We could repeat the same approach again with a new list of 20% reasons responsible for 80% of the rejections.
Another big challenge was to solve the issue of leakages in terms of claims slipping through the gaps in the entire cycle. Even for a medium-scale healthcare provider, tracking each claim becomes a nightmare. Erroneous claims leading to multiple iterations made tracking even more difficult and time-consuming.
In order to solve this issue, we decided to build a comprehensive tracking feature in our software. The tracking of claims would be achieved in the software through the following two ways to make it more wholistic:
The system was designed to track each claim from its creation to acceptance by the plan, including iterations in case of re-submissions. The system was also designed to flag any claims which needed manual intervention and/or were stuck in the process for a while.
These 4 major innovative ideas were incorporated into the billing software. We were eager to know the impact this software would have and on measuring the results, we found out what none of us had speculated. The software
This project is one of those that are closest to my heart sheerly because of the mesmerizing learning experience it has provided me. I tend to generalize the learning and reuse them in all the projects I work on. There were numerous other techniques and implementations utilized in this project, which I would love to pen down in detail sometime in the future.
Let’s build transformative solutions together.
