We were looking at a problem for a client today. I’m trying to advise them on constructing an analysis that would help them solve some of their billing problems. One of the subjects that came up was related to looking at the particular payer. And what they’re paying, what they’re not paying, in particular, what procedures they’re paying, and so on.

This kind of leads, I think, to a slight tangent, which is, “What do we try to accomplish in these podcasts? How are we trying to help you? What sort of tools do we assume that you have available for you?” Under the assumption that these podcasts’ users in much of what we are encountering are relatively adept at mid-level analytical tools. Whether it’s Excel, pivot tables, or Power BI, or some other advanced tools for some organizations, that’s great. We’re assuming that if you have high-level analytical resources within your organization. And highly-developed tools, you’re bringing in outside resources to develop data cubes or other types of solutions. Then again, you probably will want a little bit deeper types than some of these, I think, will be.

Not just financial data analysis

We’re assuming that we’re not talking to the very most basic, where people are just getting into an analysis of their financial data. But something in between the most advanced users, where we sort of meld IT and functional resources somewhere in-between. That could be practice managers. That could be accountants. It could be a CFO or a VP of Finance or something like that, depending on the provider organization’s size.

Going back to that question that came up today, one of the things I think that’s important. In any analysis is making sure that you’re answering the question and articulating that clearly and then saying, “Okay, what do we need to be able to calculate to do that?” We were looking at payers by procedure code. Essentially those types of pivots, and seeing what’s getting paid and what’s not. What’s getting denied, and so on, trying to identify the patterns. Helping them identify patterns of what’s reimbursable and what’s not?

Let’s say a really simple example: most people understand E&M codes. If you’re looking at five levels of the E&M. Again, some have three, I understand. I know there are situations, but let’s take a simple case of five. Payers typically or a particular payer categorically deny a level five, for example.

Revenue Cycle Management

I think multiple things have gone. One is you have to be able to layer in and make sure that there is a functional understanding of revenue cycle management, where somebody knows to group those five codes and see, “Okay, this one is being denied systematically. That means that it’s likely that they have a payer policy where they don’t pay. That even if it’s not an explicit payer policy.” This is sort of a little tangent into a whole conversation we’ll do on another podcast.

Looking for de facto problems with particular procedural codes. And pairing those things, they were looking for groups of denial codes and doing descending order. That didn’t make sense. The pivot should be payer by procedure code, not procedure code. By denial reason codes or denial reasons descriptions and so on because payers tend. To throw out many different reasons why they’ll pay something that may or may not be misleading. Ultimately, it’s really that they’re just not going to pay that code. They don’t think it’s realistic or reasonable to do that, or they’re just going to deny things off the bat for those categorically. Unless you can overcome those hurdles, they’re just not going to do that.

The Pivot Should Be Payer

I think where we came to today was making sure that they were putting together an analysis. That answered the particular question they were looking for, which was “If there is a group of CPT codes for group procedures, whether that’s a group of tests in the laboratory or a group of E&Ms or surgeries, for example, is this code in combination with this?” You have to know that if you’re doing a chondroplasty or something else. This code is similar to this code, or it’s not going to be paid in combination with this, or it’s going to be bundled.

Therefore, you have to put together those analyses and ultimately even link up multiple CPT codes, where if you are looking at an encounter level. You will want to create keys that link the CPT codes together. It’s probably the easiest way to do that if you don’t have a complex database structure. If you’re doing something like Excel.

A Complex Database Structure

That means you might do something like 99. Again, I’m just making up an example, 99233 or something like that 234, where you might hyphenate those two or something. Again, you wouldn’t have two E&Ms like that. I’m just trying to make up an example that you would have multiple CPT codes and hyphenate those to create a key. So that you actually can see, “Oh, if we have these in combination with these, the payer is going to deny. It where they might not deny that code individually.” That’s a little trick that you can use if you’re trying to figure out “does the payer not deny an individual code, but they deny codes in combination with each other?”

The other key takeaway, again, was to make sure that you’re pivoting CPT code by payer and grouping those together effectively. To see with somebody knowledgeable in the billing, not just in terms of their analytical skills, and pairing up those resources. Where you have a business user that says, “Ah, these codes are combined. If they’re denying this one and not this one, it means they have a de facto payer policy. And we might not want to bill X. We need to bill Y.”

Those are tidbits and tips for tonight.

 

For more information from Apachehealth.com. Please subscribe to our blog. Enter the details below and click on "Subscribe" button
Loading