This article is initially available on our podcast. Click here to listen.
We recently did a podcast about contract compliance or essentially trying to determine whether or not insurance companies have paid you correctly or identified underpayments from insurance companies. If you’ve heard that last podcast, you’ve heard us talk about how often this happens. It does happen quite frequently, and we see some patterns in that particular payers are worse than others. Certain types of procedures and specialties tend to get underpaid a lot more. But then, this is frequent and significant.
Build rules for contract compliance
We talked that some of the options included buying off the shelf from someone like a software company, MPV, Medical Practice Valley. It was acquired by Experian. They had a software package like this. If you are going to build it yourself in Excel, this can be challenging. So what we want to talk about today is not just how to put together those rules, how to calculate, and stuff like that, but what you’re going to go through in dealing with what you have built will be much more challenging than you anticipate.
Once you built something (it doesn’t matter whether it’s in Excel or anything else), that’s more the technology side of it in terms of how you come about with something that has rules to identify, “Hey, did they pay this particular procedure, this in combination with all these other things correctly?” You’re going to have an output that flags payments and says, “This is underpaid or overpaid,” in some cases, but not paid correctly. We’ll call that a hit.
Consider the number of conditions
You’re going to get many hits for incorrect payments. It may be hundreds or thousands, depending upon your sample size and how you’ve calculated this. It will also depend upon how many factors you’ve taken into account. In other words, CPT codes in combination with other CPT codes like bundling or modifiers, or “Do you include the place of service codes and other things that impact how much reimbursement you get?”
The question, though, then is, “When you get those hits for underpayments, can you figure out which problem is driving that?” In other words, it could be that you have an analytical problem. You miscalculated something. I don’t mean you individually, but you, as an organization, miscalculated something. It could be that something is screwed up in the Excel file, and that’s very likely and very possible. It could be that there is a rules problem like you don’t have all the rules loaded correctly.
Even if you have all of the rules, you may not be aware of a specific rule that impacts reimbursements, or you may be aware of it, but it didn’t get set up and loaded into the system. It could be that you have a data problem. The data output is garbage, and, therefore, it’s producing an anomaly and giving you an inaccurate result.
Despite correctly identifying the rules, you’re not technically screwing something up in terms of calculating something; it could be that there’s some problem with the data. There are many different reasons why that might be the case. Or it could be something else entirely.
I can tell you from personal experience. We built this colossal contract compliance engine. We didn’t do it in Excel. We built it in software several years ago. When we first flipped the switch, we got tons of errors. I mean, like tons and tons of mistakes, meaning massive numbers of claims were flagged as being underpaid and incorrectly paid. Not just all underpaid. There were also overpayments on things. Some of them were off by a couple of cents. Some were off by thousands of dollars. Just massive numbers of claims that hit and said, “Okay, these are incorrect.”
Test your rules
For some, as we started to QA and went through those, it was clear that we had missed some rules. For example, sequestration takes a couple of percent off, although we had done that one. That was a pretty easy one, but as an example, like if you missed a rule. We went and found a particular payer policy that either changed or updated somehow, and we hadn’t kept track of those, or there were rules unknown to us. So some of them fell into that category.
We ran into the most prominent issue because we had to dive deeply into our operational processes like crazy suddenly. That meant our payment posting processes, in particular. Well, there’s a lot of Ps. Quite the alliteration in payment posting processes, in particular. I wish I planned that. We found that we had problems in payment posting, and we didn’t even know that we had these problems in payment posting.
When I say “payment posting problems,” by definition, what I mean is that if you are trying to use the data that is in the system from payment posting to perform these types of analyses, that’s a very different requirement than you want to make sure that the payment got loaded so that you, as a billing company, got paid. The client knows that you got paid. Essentially, it gets taken out of accounts receivable, so you’re not chasing it any longer.
Manage your CPT codes
The issues revolved around things like allocation of payments when it didn’t specify something. For example, was the cost spread evenly across? Let’s say there are three different CPT codes. You got $100 in payment, and the payer didn’t specify how much of $100 went to each of those three CPT codes. So do you spread it proportionally: each gets 33 and 33 cents? Or one of them gets 34 cents? Or do you somehow have some proportionate something where it says, “Okay, charges were $100? This one had charges of $50. Therefore, we’re going to apply double the amount of reimbursement to CPT A versus CPT code B”? Or are you going to do it based on some other lookup table or something else entirely?
That was a huge issue that we ran into for a lot of those. There isn’t information. It’s not that somehow somebody screwed something up in payment postings. It doesn’t matter, in some respects, how you post those things when you’re just posting the payment for a client. They don’t care whether one gets allocated 20 bucks or 80 bucks so much. They’re not going to run that kind of level of analysis. If you’re trying to figure out if the payment is correct, suddenly, it does matter.
Do you go off and reverse engineer that where you say, “Okay, these three payments total $100. The expected payment from these three equaled $100. Therefore, they’re all correct, or the total should have been $110. Therefore, were all three of them off or just two of them? We don’t know.
Check for data entry inconsistencies
We also found tons of data entry errors. We found out that there were different ways to enter payments into the system that we didn’t even know existed. Therefore, it was not consistent on where to find the data in terms of how to calculate, “Had the payment been made correctly by the insurance company?” and unbeknownst to us. Therefore, when we ran the analysis off specific fields in the database, it produced unexpected results and incorrect results. There were many other problems as well.
The point of this, though, is, if you assume whatever amount of work you have to do to identify all of the payer rules that impact reimbursement, and put all of those together, and transform them into rules, and do all the work to put it into Excel or some other format, whether it’s software or whatever it might be, that’s half the fight. Most people think that is the fight, but the reality is, that’s only like half.
The other half is diving in and queueing your operational processes to figure out, “Do you even fully understand what’s going on in your business?” because one arm may not even know what the other arm is doing. Are some of them doing things incorrectly? Is data not loading correctly? Are there problems that you didn’t anticipate?
In summary: Add time to address unexpected issues
There’s just going to be a massive amount of work to dive in, to doing quality control, and more. In addition, there is the process of updating and changing and potentially cleaning up your operational processes to have good clean data so that you can actually analyze it effectively and then identify what’s going well and what isn’t going well.
The moral of the story is, whatever work you plan on, double it because there’s going to be so much other work on that side that you didn’t anticipate.