This article is initially available on our podcast. Click here to listen.
Defining a Problem
I think it’s worth taking a step back and considering what the definition of a denial is. The reason why I believe this is so relevant is, if you are trying to analyze and determine how well you’re performing, or even whether things are getting better or worse, or you’re comparing one practice to another practice, it becomes tough to do that if you’re comparing apples to oranges. One organization considers one thing to be a denial, and the other one does not. They look radically different.
I’m going to make something up. One has a 5% denial rate, and one has a 20% denial rate. But one of them is fudging the numbers effectively. I don’t necessarily mean that there is hostile intent all the time. There’s a legitimate question on what constitutes a denial. There’s no governing body that says, “This is a denial” or “Here’s our legal definition of a denial.”
One of the most prominent places we see this is Clearinghouse notifications that are frequently considered a “rejection”, and therefore not a denial. So if you submit a claim, and it doesn’t get through the clearinghouse, and it gets kicked back, that’s not a denial – that’s a rejection. But if our software caught it before it even gets out the door, maybe that’s not a rejection. That’s just a “system edit” or something like that. Who knows what kind of definition people are using?
What is a denial, anyway?
A denial is usually considered a notification from the payer instead of from the clearinghouse or your software system. That’s a generally accepted convention. Yet, not all payer notifications are denials. Some, of course, are notifications of payment. Some are contractual obligations. In addition, some even come in a much more nuanced version where perhaps it’s none of the above.
Even requests for documentation or clinical records are technically not a denial. Medical necessity types of notifications could fall in the camp of, “Hey, we’re not going to pay that because it’s not medically necessary” because maybe, they consider that the diagnosis doesn’t justify it. That is a denial. However, if they’re asking for clinical records to back up the diagnosis, technically, that’s not a denial. That’s just a delay. They’re saying, “Hey, give us more information to allow us to pay this or adjudicate it.” We’ll ignore here for a moment that many payers put up straw men like this when they will never actually pay it. It’s a hurdle you cannot overcome.
The Goal
If we look at the goal of measuring denials (and a lot of the purpose here comes down to that), then our goal in defining what a denial entails is to measure the denials rates, maybe track performance over time, and see if what we’re doing is improving things. That means that essentially what we want to know is, “How often are you not getting paid?” That seems like a relatively simple definition. How often is something not getting paid?
I don’t want to get into something like, “Oh, well, the balance went to a patient” or “It got adjudicated, accepted, but got consumed by somebody’s deductible.” I don’t mean that. I mean, have we gotten a communication back from a payer, effectively saying we’ve adjudicated this positively, or it’s approved for payment?
How are you getting paid?
Our definition of “denial” is probably more encompassing than in most organizations. Really, it’s because of that definition or that goal that we talked about, which is measuring how often you’re not getting paid. If we can get copies of this communication, whether any rejections that come in electronically from the clearinghouse, actual remittance of any denials from a payer, or even from a billing system we want to capture and analyze these data. This includes things like requests for medical records, which we talked about is not technically a denial in the literal English language sense.
However, it also includes other categories of things like “no claim on file”. That is not getting paid, but it is definitely not a denial, especially if we never got any communication back from the payer. It’s saying when we ping them that they’ve never received the claim. So they’ve neither denied nor accepted it nor adjudicated it positively. We would include those types of communications in there as well if we can get the data.
Ideally you might put a flag or additional data tag to indicate where in the process these “denials” came from, whether manually gathered, from the billing system edits, from clearinghouse rejections, payer denials, etc. so that you can drill down later to see where problems are greatest and to effect change.
Performance Monitoring
What definition have you chosen or will you choose to use internally? In some ways, it doesn’t matter that much. The most important thing is that you document clearly what is included and what your assumptions are. This is the list of all of the locations we are tracking communications or nonpayment, whether it’s only system files, clearinghouse, etc. Consider whatever those types of files are, what codes you’re using. Okay, CO 45 – yes/no, CO 109 – yes/no, PR, 253, or something else.
It is really important that you have that list, “These are the things that we’re considering to be denials” so that that way you can track performance over time because a year down the road someone may say, “Oh, no, no, no, that’s not a denial” or “Yes, that’s a denial. You should have included that.” Suddenly, your definition changes, and it looks like your denials went through the roof or tanked. That’s not going to tell anybody anything. It leaves you subject to manipulation intentionally or otherwise.
Having a consistent definition is good, but having it documented is even more important than consistency so that you can say, “If there was a spike suddenly last summer, it’s because we changed the definition of what constitutes a denial.”
Benchmarking
If you want to compare to another practice and you want to do benchmarking, then you will need that definition clearly articulated. Then you have the list and can say, “Hey, here’s what we’re considering to be a denial. Let’s compare what you’re using to define denials so that we’re not comparing apples and oranges.” This is the only way you will be able to benchmark against others.
Recent Comments