This article was initially available on our podcast. Click here to listen.

We have a solution for you concerning overwriting data in billing systems and how to deal with that. Before we get to the answer, I think we have to back up and reiterate the problem to understand the problem we’re solving.

Denials for payers

In a previous podcast or article, we had discussed that when running some analysis, we had found that there were no denials for a particular set of payers for a problem that was a known problem. This was a situation where a large number of claims had been submitted. The billing company claimed that there were a massive number of denials. It had made some recommendations to their client, the provider, on changing the billing process, making some changes to the claim submissions to avoid getting those denials in the future.

We did not see any of those denials when we ran the analysis. So we had concluded, “Hey, there’s some faulty method to your analysis here,” because somebody had been taking data manually out of the system and crunching it in Excel. We did not see all that information in the data warehousing and analytics module. 

So we thought somebody had done something wrong.

Resubmitting old claims

When we talked to the billing manager, it turned out that what had happened was they had gone through, and once they determined that a change should be made, they not only changed going forward, but they resubmitted all of the old claims that had been denied with new CPT codes. That overwrote all of the data in the system. Also, that meant that when those charges were then submitted with new CPT codes, they no longer existed from the prior problems. When you run the analysis, when you look at the reporting, it seems as if there are no denials when you look at the data. It seems as if there’s no major problem because it doesn’t keep track of the old charges, the old CPTs, and all of the denials that were associated with those claims.

That means you can’t verify that there even was a problem, much less quantify the problem, much less see, “Okay, what are the claims that we had the problem on, that we then resubmitted? Did they all get fixed? Did that solve the problem?” It becomes challenging, not only from a historical standpoint but even knowing, “Did somebody solve a real problem? Or was somebody chasing a ghost, and they were solving a problem that didn’t exist? Or did they even solve the problem?” Because you can’t identify, “Hey, for this set of claims, these were a problem. Now, they’ve all gotten paid.” Or a very material percentage of them.

Stop the confusion

This is confusing for anybody who wants to look at this stuff. Depending upon how the system is set up, it might even look like you have a massive number of denials and a very high denial rate on a subset of the claims that got resubmitted with the new codes. So it’ll seem like suddenly all of the new codes also got denied because it’s showing denials, and it’s showing it associated with that new CPT code and not the old CPT code because it got overwritten. Until you get far enough away from that problem set that had been resubmitted, it would look like the new claims are getting denied. Again, it depends on what date range you look at and other things like that.

How do we resolve this?

What’s the solution to this? The solution is a short answer: You can’t do anything in your billing system. But there is a solution that involves data warehousing that allows you to identify and figure out, “Hey, did we have a problem? Can we validate what this billing manager had said and then track and see the solution implemented for all of those problem claims? And then, did it solve the problem?”

The solution is this: You can track the changing state. If you have a data warehouse, you can download all ongoing claims. When something changes in the billing system, have it not overwrite those records in the data warehousing but create a new record with dates associated with this.

The process

For example, you would see the original CPT code, the submission dates, and the denials. And then, you would see a new CPT code; you’d be able to track and see the same visit number because there is that key that links them. So you could follow and see, “Ah, okay! For this particular visit number 1234, we have a CPT code and then a different CPT code that effectively was overwritten and submitted on a different date. And then, we have a denial associated with the first CPT code, but not the second CPT code.” As a result, you could see, “The first CPT code was denied and all the dates associated with that. Further, the second CPT code was paid. And yes, it then solved the problem.” 

You can roll that up, aggregate that, and see all of those combined. That’s a great way and great use of data warehousing that allows you to confirm, “Yes, we had a problem. Yes, the solution solved the problem. Here’s how much more money we made.”

In conclusion

We love data warehousing, in case we didn’t mention it before. Go, data warehousing! But that is a little bit more complex setup. Also, the maintenance of that and the analysis has to be done correctly to make sure that you are looking at it precisely and getting good answers. Again, all of that can be managed and handled. So yeah, go, data warehousing! Go, change state!