This article original available on podcast, click here to listen podcast.
We frequently have to deal with analytical resources. Whether it is a business analyst, an IT person, or somebody from a software standpoint. Sometimes, they go offshore. It is a consultant dealing with all kinds of different things.
One of the challenges that we see and think about is what it takes to be successful in analytics; understanding the rules understands billing. There are technical folks, whether they be software developers or analysts or whoever they might be, and they do not understand the business.
I get stuck in how hard it is to be able to explain those types of things. I’m not exactly sure why it is or why it seems to be more difficult in this industry than in others. I think this is a reasonably complex industry where you have to get a lot of knowledge throughout. An extended period on things that are not intuitive. Whether it is insurance structures or payment systems or other types of things that you accumulate over the years or longer. Being able to communicate all of that information is not easy.
How to understand the complexities of the billing process?
It would not occur to somebody that they need. To know that you should only look at claims to get fully adjudicated. Otherwise, you are going to get wonky things. If a claim got billed yesterday, then obviously, it would not have been paid by today or have been adjudicated. So, you cannot determine whether it was successful or not. That is basic, but then there are so many more nuanced things that the analyst. The IT person, the technical resource would not be able to discern and pick up.
I think finding the person or people or being able to sort of bridge. Those two worlds, where you have billing, and you have the technical resources, who is the person that is in the middle?
How to make adequate communications to the technical team?
That also comes down even to functions like QA. If a series of requirements are written up or communicated from billing to a technical team, who will review that and make sure that there aren’t things missing? I think even, more importantly, who is going to check what comes back? We often find where it seems clear what the requirements were that got communicated to the technical team. There are so many nuances and so many complexities. To the billing processes and the data structures and critical things to know to do this successfully.
Examples we have given in the past, or even structures, are a secondary claim creating a whole separate claim number or a particular encounter? Or patients, are they listed as independent insurance, or are they just patients when there is a balance that rolls over to them?
How do you distinguish between a patient balance where it rolled over after a primary versus a patient balance at your cash pay patient? And bazillions of other things like that, where that sort of things you have to know, and not just how the individual system is structured. You have to understand billing at such an intimate level that you can communicate what the needs are and then. Because those billing resources frequently don’t know the database’s software’s underlying structure. It is almost impossible to know that.
You can know some of those things by digging into them, but those technical resources get communicated to their needs. Spending a lot of time QA’ing that with that sort of middle person or a team is critical.
Need for a person with technical skills
How do you do that? How do you find that person, or how do you make that person? Can you get a technical person up to speed in terms of billing or a billing person up to speed technically? I think it is easier to get a billing person to get details on a sufficient technical level. As the amount of knowledge that would have to get transferred is more complex than technical skills.
- Finding a technically-oriented revenue cycle management person, somebody who’s good with pivot tables or analysis, and so on, finding that person or those people and designating. That person or them to be in that role, I think, is critical for success.
- Find that person or people, even if you have to go outside your organization or your team. There are ways to test for that. Give them some technical tests and then move them a little further up to speed. And spend a little time with the IT and technical folks. Again, it depends on your needs and what the project is, whether it is a workflow analytics tool or software development, or it is in Excel or whatever it might be.
- You have to go back and say to the IT team, “No, you got to revamp this completely. We need a different data table. You have to pull the information from somewhere else.”
That happened on one of these things today, where they were trying. To calculate the number of received versus accepted claims. They were using denial information, and they did not understand the difference between an insurance denial and a clearinghouse rejection and sort of insurance statuses. It would not occur to them because it seems like they had all the information, so they went ahead and had tried. To calculate some stuff, and it was total garbage.
Best of luck on that! Hopefully, you will find that person or those people, which will save you many headaches and many problems where the data misleads you or isn’t able to answer questions for you.