This article originally available on a podcast; click here to listen to the podcast.
This is a follow-up to whether or not insurance companies tell the truth when they send denials. We had shared a couple of pieces of information. In the most recent one, we looked at whether or not the insurance companies forwarded the information to a new payer.
When the claim was submitted to the incorrect insurance company due to incorrect demographics, some insurance companies send a denial back, saying, “Wrong information: you need to forward this to the correct payer.” In contrast, other insurance companies say that they have forwarded it to the correct payer. The question is, “Did they do that, i.e., did they tell the truth or not when they said they forwarded it?”
In trying to answer this question that relates essentially to insurance changes within the patient demographics, we’ve run into a data problem. Specifically, we wanted to know if when a payer says they forwarded it, did they or not? That means you need to know insurance one, meaning primary insurance, and then new primary insurance, a sort of the replacement insurance one.
We’ve run into the problem that most systems overwrite primary insurance when new insurance is entered for that claim. Even if a system can maintain more than one case, it’s sometimes the term, depending upon how the system is set up, you might have one insurance for healthcare and one for workers’ comp or other types of things like that. Or your system may be able to have an insurance that has termed, meaning it’s no longer valid insurance for a particular data service. It could maintain the old and the new call it insurance one prior and insurance one current. The prior would have dates associated with it, ended perhaps three months ago. Claims before that for data service would be submitted to the correct insurance, while the new ones would be submitted to the new insurance.
Maintaining termed insurance
Even if the system can maintain a termed insurance, it still doesn’t show that in a report. When you create a report related to that particular record, so you’ve got a data service on February 1 that got submitted to insurance company BCBS or whatever, it will not show prior insurance and current insurance. It only shows the current insurance in that report.
You can’t easily get state change information. State change information is. Think about it almost like a snapshot in time. Let’s say, for example, with a particular claim, and you submitted a $1,000 charge. It’s currently unpaid, that’s the state right now, and there’s a $1,000 balance. It’s $0 collected, but three weeks from now, the state at that time is $300 collected, a $700 balance. Change is in the state where it moves from one to another within a record. Most systems are not capable of handling that kind of information, certainly not for insurance. It means you can’t see whether the insurance in a report is the new insurance or whether it’s old and it needs to be updated.
Let’s say, for example, we see that there’s a denial in a report, and that report shows BCBS Alabama. We don’t know from that report, from the data we’re provided, whether or not BCBS Alabama is the old insurance that needs to be updated. It is incorrect, or whether that’s the new insurance, and it had been Cigna or Medicare or whatever it was, and it got changed to BCBS Alabama. That’s not evident in that report. There’s no easy way to get a report out that tells you that. The question is, “What do you do in that kind of situation?” because state information is vital. This is just one example of that.
Things related to accounts receivable are crucial as well. For example, what were your accounts receivables at a particular point in time? To see whether or not it’s changing and getting better or worse, you need state information over time to track progress. Otherwise, you’ll only know what it is today or whatever time you export.
Change in accounts receivables
Your options for doing something like that are either something really kind of complex where you manually go in and pull out information. For example, in this report or this system for this client, for this project we’re doing right now, the information exists, the prior insurance. If you go into the individual claim, you can see the prior insurance and the current insurance, but you’d have to manually do that for each one of them, which would involve thousands and thousands and thousands of records. It’s completely infeasible.
Your next option is to have somebody or yourself create software to scrape information from that system. There it goes into each record and copies that information and then deposits it into a database, and then goes into the next, then goes into the next, then goes into the next, and so on. That’s complicated. Most people can’t create something like that.
The last option and probably the best option is to run reports periodically, ideally daily, and export the data and store that information. That means that you can see state information. For example, if three weeks ago, it had Medicare for that claim, you would have an export from the system that’d show that information. Then today, when that information is exported, it would show the same encounter ID or the same visit number, whatever your software calls it. It would have different insurance associated with it in that report. You could see the state change by comparing one to the next.
There are a couple of problems. It’s very complex and cumbersome and very data storage-intensive to store all of that information in a giant database. You can do that, but it means you’re storing information same, same, same, same, or you can set it up so that it only creates a new record when it notes a state change. Again, those are things you can work through, but it’s a little complicated.
The other problem, this is probably a bigger issue, is you can only do that from now on. You can’t do it retroactively. That means if you go in today and pull all kinds of information out of your system, you can only see the status today. You can’t see all of the changes that occurred in the past. You could start exporting daily and track all the changes over time in the future, but you can’t go backward in time. That means no time like the present. We can’t go retro for this particular client because we’re getting a giant dump of data now, and we can’t go back in time. Other clients can do this because we’re getting information in real-time via an interface or periodic daily exports that go into essentially a file-sharing application or something like that. We sweep and pull that information in.
Those are all options that you can have. Still, our suggestion for anyone who is trying to understand their business and changes in their business and answer questions effectively is to get data out daily. Ideally, that would all go into a database, and you set it up so that it is usable instantly. Even if you can’t do that now, worst-case scenario, get it all out and store it. At least, you’ll have the data so that you could reconstruct it if you ever need to. Whether or not somebody like Apache comes in and pulls that information and analyzes it, or whether or not you want to do it yourself, or if you want to look at an individual record, you can go back and do that then and look at that report from three weeks ago and look at that particular encounter.