This article original available on podcast, click here to listen podcast.
Are you having challenges with your family intruding when you’re trying to work? It is probably the sixth time I’ve been attempting to record this podcast. I’ve had children screaming and coming into the office and all kinds of fun stuff. Seven times they say is a charm. I wanted to share an example of a situation we had with eligibility problems when we were billing and how we needed some not traditional data to solve the problem.
We were billing for a pretty large provider. In our agreement with them, we had distinguished between who was going to do what services. They were contractually obligated to be doing eligibility verification. We had done eligibility verification for some of the clients, but they said they were doing it.
We were getting tons of denials where the patients’ insurance had termed, or it was incorrect insurance or whatever it might be. It was evident that they weren’t doing it. Happened to be that this large volume was for Minnesota state Medicaid patients and Medicaid MCOs.
It was a referral-based provider like radiology, anesthesia, laboratory emergency, where you don’t get to turn the patient away. If you check eligibility ahead of time, you’re checking eligibility. To get as many of them paid as possible. You are taking whatever comes to you and trying to get them paid and then cleaning up the mess after.
Importance of eligibility verification
Eligibility is an integral part of that. If you don’t check it, you’re going to submit the claim, you’re not going to get it done, and then you’re going to miss timely filing limits, and so on. You’re not going to be able to prove them. You’ll never get those claims paid because you couldn’t follow up.
It is possible to go back to the ordering physician or provider and get that information frequently or chase it down yourself.
In this case, it was clear that the provider was not doing it because we found so many problems. We ran the data we showed it to him. It was apparent they weren’t doing eligibility checking. We came back and said, “Hey! Your team’s not doing eligibility checking because there’s just a sea of these things. It’s a massive amount.” They assured us they were doing it. We said, “Okay!” Well, then it’s probably that they’re not doing it right or something like that. They went away, came back to “No.” They were doing it and so on and confirmed. We said, “Okay, we’ll wait and see.”
Time passes, and the problem persists. It takes another month or two to collect more data and see if they solved the problem. We went back and said, “Okay, it’s clear they’re not doing it right. Can we provide them training, documentation, or write-up on how to do eligibility checking correctly for Minnesota Medicaid?” You can’t do it through the standard systems.
We did this giant write-up for them and trained their people and, again, month or two passes collecting more data. It’s still the problem. They haven’t solved it. Of course, the client’s getting upset. We go back to them and say, “We’re not doing our jobs because there are so many claims that aren’t getting paid.” We keep showing them the data, saying, “Hey! Your people are not doing their job correctly.” There is a lot of finger-pointing going on. Everybody’s upset. We told them they got to solve the problem. They got to fix it. Of course, at this point, we’re saying, “Well, we don’t know what’s going on because they’re telling us they’re doing it, and it’s clear they’re not doing it.”
Identifying the problem
At this point, the decline was so upsetting. We were having so many problems and finger-pointing and all that kind of stuff. We were overwhelmed with all the backend work, so we decided to do eligibility checking on all of this class of claims ourselves. Obviously, there was a cost, but we figured it was better than the cost of fixing all the problems with the broken claims in the back-end after the fact.
Plus, the client was angry and not particularly rational. We needed to get them off our backs and solve the problem, and we figured once we cleaned it up and we showed them, “Hey! We’ve taken it over, we’ve done it ourselves, and you can see a dramatic improvement in the data and claims payment,” all that kind of stuff. We would go back to them and say, “Hey! Now, you’ve got to pay us to do it because your team wasn’t doing it.”
We took it over. Fast-forward another month or two or something like that, we had done this, and we submitted the claims. We are collecting some data, and we see denials keep on coming for the same problems. It didn’t work.
Scrutinized Our Eligibility Checking Group
We had some questions to turn in, like, “Is our team incompetent? Are they not doing their jobs, aren’t doing what they’re supposed to be?” We scrutinized our eligibility checking group, and they swore they were doing it correctly. I even got involved in the process. We were making massive payments for like six or eight months at this point. Every time you sort of thing you’ve changed something. You have to wait a month or two to collect some data to see whether or not it’s affected some change. Because it’s not instantaneous, especially since a lot of these payers pay on a slow cycle.
They don’t pay in three weeks. They pay in six weeks or eight weeks or something like that. If you contact them in four weeks, have them submitted the claim. Not only is it not paid, but they don’t even say that they’ve got the claim on file. They will say like, “We don’t know what you’re talking about.” You have to wait often a month for them. Even to say they’ve received the claim, much less whether it is adjudicated successfully or not.
We were six or eight months in. There are still tons of payments, and clients are angry. We started looking more closely at the data, and we tried to implement a process. We were in the snaffle for a horrendous amount of time. Some of these claims that were now 6-8 months old, we were rebilling, and they were getting paid. We didn’t understand, “Why?”
We started to collect more data. Had data service already, but we started collecting things like the eligibility date we checked. Went through our notes and sorted those date fields or those text fields to find out when we’d gone back and resubmitted the claim. We had resubmitted dates that were discrete in the system. When had we checked the eligibility, we rechecked it a second or third time. What information did you derive in there; when did it change, and so on? What were patient coverage dates listed; when was it changed? Was it going back, something like that?
And what we saw was when we got them paid much later, six months later or something like that, we checked eligibility a few days after the data service. It showed one insurance, and it didn’t get paid. That was incorrect. Then six months later, we showed different insurance, but the patient’s actual eligibility date was retroactive back like six months or nine months to that date.
Pattern In The Data
We saw that pattern in the data. Anything that was Medicaid or Medicaid MCOs for those massive percentage denials, something in the three to six months later, the eligibility started working better. We were like, “Wait! What? How?” We didn’t understand why eligibility was working now. Of course, the new ones still weren’t getting paid, so it wasn’t that something had suddenly shifted. There was a time-lapse going on that we were trying to figure out.
What it turned out was we saw basically after about three months, about 50% of the ones that had shown termed or incorrect insurance was now showing the correct eligibility and getting paid. We just had a sort of random distribution of when we were checking eligibility because we hadn’t implemented a new process for this. Every time a denial came back, somebody would do something about it. That gave us a nice, smooth amount of data, spread out over time.
It turned out that the online system was three to six months behind. A massive amount of turnover where a patient was dropped. By one managed care provider or something like that or switched. To straight Medicaid and back, dropped out or got termed or whatever it was, and the system wasn’t keeping up. It was way, way, way months and months and months behind.
When you checked eligibility, you couldn’t trust it. What that meant was then we had to do something very different. Implement an extraordinary process. Once we had that data and we could show something, we went back to the client and said, “Okay, we’re now getting some of these paid.”
Of course, we had to make sure we didn’t miss a timely filing limit. It got tricky there because some of them were six months, some of them were other dates, and so on because some of these were MCOs, and the state didn’t govern them.
Stuff In Addition To Data
We went back to the client. We had screenshots to show all the stuff in addition to data to show them examples of, “Hey, here’s why!” Three days after, it showed X, and I was wrong. Six months later, we got it paid with new insurance, the date when we checked in, and so on.
We created a whole new process for them, where we checked them after a couple of days, submitted them. Some got paid, but we didn’t work anything for that class of payer. At a trigger point, months later, we checked again and then updated insurance and resubmitted those a second time. We got sort of a second wave of them completed. And we had a trigger in the system to make sure that we didn’t miss timely filing limits.
Again, it was more work, but it was worth the dramatic amount of improvement in payments. We didn’t waste tons of resources, just always fighting on individual claims that weren’t correct. Batched all of them in doing this kind of thing.
We then got payment for the additional work. We made more money, and the client made more money. The client was satisfied because we solved the problems.
It was rocky for eight or nine months. Everybody was angry and pointing fingers. However, ultimately, the data indicates that with some new data fields, what was going on allowed everybody to make a lot more money.
Wish you the best of luck in solving some of these kinds of problems!