The Moving Target of Working with Claims Data

Have you ever watched your claims metrics change over time?  Right before a big meeting you revisit some claim metrics—last week you calculated $100 dollars, but today you see $125.  Why oh why?!  Sometimes it seems like you are a cartoon cat chasing a mouse that always finds ways to escape.

In Part One of this blog series, I discussed claim completeness and a tool to help identify gaps in your claims universe.  Rather than focus on what is missing, today we will talk about the data that is present.  Every time you look at your data, the picture may change. 

So why does it seem like these claims add up differently depending on when you look at them?  Let us drill into a single patient first.  Consider our patient, Jerry, who has had a single visit during June. 

We can conclude that Jerry costs $100 in June of 2023, right?  Keep in mind that our claims data is transactional in nature.  Therefore, our conclusion is based on a snapshot in time.  In this table, I included a “data received” date, which represents when we received the claim record.  I added this because we are about to make things complicated.  Are you excited?! 

So now the story has changed a bit.  When we looked at the data as of October 2023, we saw $100.  If we move forward a month, a new transaction has arrived, and we suddenly see two transactions which zero each other out.  We call the negative transaction a reversal.  I am going to call the process of resolving these reversals “adjudication” logic.  In this case, our adjudication logic is simple. We are just summing our dollar amounts for a given patient across the date of service.  Once we apply our basic adjudication logic, should we conclude that Jerry did not cost anything?

If we wait another month, suddenly we have another transaction in the data. The new transaction is for a more complex CPT code with a higher dollar amount; we call this a rebilled claim.  We can use the same adjudication logic here, and just sum our claim transactions across this date of service for Jerry.  In doing so, can we conclude that Jerry cost $125 as of December 1^st 2023?  I will not take this any further, but I will point out that this is the simplest scenario.  For illustrative purposes, we assumed that the health plan shared reversal transactions with us, but this is not always the case.  If we did not receive those reversal transactions, we would have data that looks like this:

Without a keen eye, you might conclude that Jerry now costs $225 for this visit in June.  However, that is not quite right.  Those of you who are familiar with CPT codes know that it is unusual to see 99214 and 99215 billed on the same day for the same patient.  There must have been some kind of reversal that we did not receive.  Now we must update our adjudication logic a bit and resolve these two transactions.  If we do this correctly, we will conclude that we have a single visit on 6/1/2023 with a 99215 CPT code for $125.  Did we catch the mouse yet?  Let’s dig a bit deeper.

Let’s add another dimension to this example.  Some claims transactions we receive will be tagged with denial indicators.  Denials add a bit of a wrinkle to our adjudication engine.  Here is an example:

So, we could say that just the $125 claim was denied and the prior transaction should be left alone.  Following those rules, our results change a bit and we are back to $100 for Jerry’s 6/1/2023 encounter.  But wait, is it possible that the $100 transaction was reversed and we just cannot see the negative transaction?  Uh oh…

I will address this cliffhanger below, but for now let’s assume we have adjudication logic that works for Jerry.  Now we just have to apply it for our entire population.  For those of you that work with claims data from multiple health plans, you are going to need slightly different adjudication logic for each source of claims data.

The natural next question is, “Why does this happen?!”.  The answer is that each health plan has its own way of managing their claims transactions and each health plan is going to store each of these transaction types slightly differently.  By transaction type, I am referring to initial claims, reversals, rebills, denials, appeals, and many more!   The data we receive at Azara is downstream of their own claim adjudication engines.  In the first blog of this series, I likened the flow of this data to a game of telephone.  As with any game of telephone, information gets lost along the way.

This is where I get to plug Azara’s process a bit.  At Azara, we are already considering the transactional nuances I covered here, as well as some that I did not.  We work with health plans to figure out how to design our adjudication logic for their claims to minimize this kind of information loss.  In the Jerry cliff hanger above, the truth is that the data alone does not reveal the truth.  We would only be able to resolve this by working with the health plan and devising a set of rules to properly resolve these types of transactions.  We may require the health plan to add negative transactions to the data, or perhaps flagging those transactions that have been reversed.  

Although important, this work does not change the fact that claims metrics are moving targets, but what it can do is dampen the noise and give us all the edge that we need to catch that mouse!