This article is initially available on our podcast. Click here to listen.
We’ve spoken recently about the reporting lag with many systems. Many times, because of certain cycle aspects of things, whether it’s accounts receivable, we tend to look at not the current period, but we set some cutoff. The end of a period might be three or four weeks, so that’s the point in which we say, “Okay, we’ve closed that period, and we can now look at that period.” Or we might say, “Hey, the data that we are confident is reasonably good.
Start with a review
The most recent period is five, six months ago, or something like that. Hence, that’s the most recent period we can consider. Everything more recent than that, we have to discount or not include because we can’t trust that data: it’s not fully formed, it hasn’t fully been executed, we haven’t collected all the data, and everything has happened, or something else.”
Let’s take a particular example: Denials reporting lag. Frequently, this is many, many months. It’s not uncommon for it to be five or six months. That means that when people look at denials data and say, “Okay, how are we performing over time?” For example, if we’re in the month of August, you might say that the most recent month that we can look at might be January or February. After all, it’s considered that we basically can’t look at the data more recent than that, like July, because it will be misleading as we haven’t gotten all the denials yet from that period.
What about real-time data?
We can reasonably assume that we’ve gotten all the denials we’re going to get at the stuff from January. Why can’t we use real-time data? That’s an excellent question. The answer that most people found.
We’re going to have a slightly different twist on this, as we usually do. I’m not saying we’re always contrarians, but it seems that we’re frequently contrarians. I’m also not sure whether that makes us crazy, or it makes us brilliant, or maybe both. Invariably, that doesn’t sound good to say that. In addition, it sounds like I’m arrogant. Still, I hope it doesn’t sound too arrogant. But we do find ourselves going against the flow on so many things that we do have to ask ourselves occasionally, like, “Are we nutballs?”
Waiting on denials
Concerning denials reporting lag, the challenge is that denials aren’t instantaneous. If you submitted a claim yesterday, in the month of August, you’re not going to see today what the result of that is. You won’t receive a denial for a significant period. It might take days, weeks, months.
When you’re considering, “Okay, we want to look at a particular period in time,” let’s say we’re going to look at the month of January. By February, have we gotten all the denials for January patient encounters? Well, no, there’s still a ton coming in. What about by April? Concerning April, have we gotten all the denials we’re going to get for January visits? Well, there is still some trickling in. Again, depending on your payer mix, maybe even a significant number are coming in because some are pretty slow.
How many denials are too many?
At what point can you “cut it off” and say that we’ve effectively gotten all the denials that we’re going to get for a given period? Everybody struggles with this issue. What most people do is they pick something relatively far out (five, six months). At this point, we can consider that reasonably closed.
One of the questions then is, “How do you consider a period?” It depends on the frame that you’re using for the concept of a period. For example, we’ve just arbitrarily said January. But what in January? In other words, is this a service date or data service, which means that it’s many, many months before the denials come in for that? January, or a period, could be a submission date for those claims.
To be clear, that could be a first submission or the last submission because claims are often submitted more than once if there’s a problem with it. Thus, if we’re talking about the first submitted date, then again, it’s many months. If it’s the most recent submit date, it’s a little shorter in time, but it’s still likely months.
For instance, in sort of the hierarchy of worst, worst would be data service. The second worst would be the first submit. Moreover, the third worst would be the last submission date. Still, we’re talking about months before you are confident you’ve gotten pretty far up that Pareto with the denials.
The other option to consider is the receipt date for denials. The receipt date is effectively instantaneous. At least, it’s closest to that in the sense that it’s the most recent data that we have.
Let’s discuss service date
I think the reason why people stick with something like a service date is because, especially in accrual accounting, it becomes the foundation for all of this, which is, “When did we perform the service, and therefore, we’re going to accrue for everything, and everything is going to tie back to that time?” If you revolve all of your reporting and financials around the service date as the “period” and you don’t vary that concept, then you don’t have many options. I think there’s frequently a strict adherence to the idea of a period like a service month, and I think that’s the reason why.
As a result, what we should consider is, really, “What’s the question that we’re trying to answer in looking at particular reporting?” I understand if, for gap reasons, for publicly traded accounting reasons, you’ve got to roll up and send information, and it’s going to be announced to the public, and that’s all in massive legal requirements or all those kinds of things. I get that, but that doesn’t mean that we can’t also look at something in a different way.
We don’t ever see this in reporting if we think about what question we’re trying to answer. We see the report. It just says, “Oh, 26 days and 14.9,000,005-month lag time. Nobody says, “Well, here’s the question we’re trying to answer in this report, or this chart, or this table.” It’s just presumed that everybody knows and agrees what that is, but that’s not likely.
So we’re left presuming what the authors were trying to communicate and why they’re doing it and then trying to figure out like, “Oh, was this a good report or not?” Well, you don’t know if it’s a good report or not if you don’t know what question they’re trying to answer. There’s no way to evaluate that. It’s arbitrary.
The question that we would want to answer when we’re looking at denials reporting, in particular, is, “How are we performing over time with denials?” Not “How is the entire organization performing financially?”, but specifically, “How are we performing over time with denials?” Presumably, there will be action plans and programs associated with reducing the number of denials and then overturning more of those denials. Are we getting better or worse with denials over time?
Denial receipt date
Of the choices that we listed earlier, one of those gives you the most current data: Denial receipt date. Why? Well, because some of the denials received in January would be from data service in January, there will be some claims you get out the door, and they deny fast, or they pay quickly. So you may have to obtain a chunk.
The overwhelming majority of the claims will be from the current month and the prior month because, for the most part, most of your denials will come in in the first 60 days. That means most of the denials by receipt date will be the current month or prior month with an extended tail distribution going back over time, out four, five, six months. But that means the oldest stuff represents the smallest percent, a small part of that tail.
However, if you do it by data service, it’s the reverse, which is the overwhelming majority is four, five, six months old, and the long tail comes out to the current period in time today, which is a tiny percentage of the total. So it’s backward.
If we’re trying to look at, “Hey, how are we performing?”, and we want to see, “Is it getting better or worse?”, we might as well look at the most recent stuff if we can, understanding that there’s some mixed in there that’s older. But it’s a lot better than looking at mostly older data. If our options are bad or worse, let’s go with evil. That’s our general philosophy.