This article originally available on a podcast; click here to listen to the podcast.
Data Problem for Denials
This is a follow-up to whether or not insurance companies tell the truth when they send denials. In the most recent article, we looked at whether or not the insurance companies forwarded the appropriate information to a new payer as they claimed they had done.
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, aka the replacement insurance.
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, depending upon how the system is set up, you might have one insurance for healthcare and one for workers’ comp or other types of categories of 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 date of service. It could maintain the old and the new insurance insurance all at once. The prior insurance would have dates associated with it, perhaps it termed 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.
Even if the system can maintain a termed insurance, it still doesn’t show that in a report associated with a claim. When you create a report related to that particular record, for example if you have a date of service on February 1 that got submitted to insurance company BCBS, 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 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, and $0 collected. However, three weeks from now after a payment comes in the state at that time is $300 collected and a $700 balance. These are change states where it moves from one to another for a given claim. Most systems are not capable of handling that kind of information, certainly not for insurance for a patient. 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.
Why This Matters
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 and is incorrect, or whether that’s the new insurance, and it had been Cigna or Medicare or whatever it was prior, 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.
State change information related to accounts receivable is 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. If you didn’t export religiously every month over the last few years you might never see that you AR is getting worse. You would only see your current AR.
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 with 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, where 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. And it’s expensive and requires major economies of scale to reward pulling it off.
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 that particular claim had Medicare for its insurance, 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), and 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.
There is one other option that we use to deal with this issue when it comes to AR, but is extremely complex. If you want to know what we use, please contact us and we can discuss it.
The reason this came up specifically for a denials analysis was that if you want to track and see how many denials you receive for incorrect payer (demographic information), that is generally not that hard. However, if you want to see whether or not those problems were resolved by finding new insurance and submitted the claim to a new payer, now you have a real data problem that prevents knowing whether you were successful. It also means you can’t easily tell whether the payer was honest in telling whether they forwarded the claim, or which payers were lying systematically because they got overwritten with the correct insurance. So it looks incorrectly like the good payers denied it when they are the new insurance on file. (Confusing? – message us and we’ll explain)
Those are all the primary 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. Worst-case scenario, even if you can’t do that now, 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.