This article is initially available on a podcast; click here to listen.

Fields that you can’t report – why is it that you can’t report on so many fields in billing systems? We’ve seen extreme versions of this where you can’t get the data out at all, meaning there’s no export function. You can’t hit a button and get an Excel or CSV file out. LIS 365 or something like that was one example we ran into a few months ago last year. There are other versions of this where you can, in theory, get something that looks like an Excel, but it’s completely unusable. It’s not usable data.

There are other versions of this where the fields that you want you can’t get in one report. That’s not you can’t report on it. It’s that you can’t get it all in one report. That’s not quite as extreme.

Examine primary fields

Often, you can’t get the primary fields necessary in doing some analysis to export out at all. Insurance is one example where you may not get the insurance information, plan, or plan type. It may be that it lists the insurance, but it doesn’t list the program or the plan type in the reports. Therefore, you can’t do any analysis off of those fields.

Many systems operate that way. That means everything isn’t the same. Also, all your HC plans are not the same. You care more if that’s a Medicaid plan than you do if that’s UHC in some respects. If you can’t distinguish between that in a report, it’s pretty much garbage.

In some systems like Office Ally, you can’t get basic information like a submit date, which astonishes me. I don’t even understand how you can operate that way. Not only can you not export it, but you can’t even see it online in a report. Moreover, you have to go hunting around and try to go into the individual patient record. It’s crazy.

Extend reporting capabilities

There are other situations where some important field like the number of OS remaining for that patient is not reportable. Athenahealth is a good example where they don’t have that capability. Those fields, again, exist somewhere in the database, and you can hunt around and find that information in the system, but you cannot report upon it. This is critical if the system doesn’t have some capacity to count down the number of OS for the encounters or the procedure. In addition, there isn’t anything automatic. You need to be able to run reports to identify, “Hey, who has a problem with this?” If you can’t run that report, then you’re really in trouble.

We’ve seen really bizarre and quite astonishing situations where they requested to customize a system and add a field to capture some piece of data in a system. They did the customization. The data now exists in the system, and you can’t report off of it. That’s nuts. Why did you create that whole new field and not be able to report off of it? What do you do with this?

Use effective solutions

What do you do when you run into these types of problems? Some people do manual workarounds. They do a ton of manual labor, where they go into each chart or each record and transcribe something into Excel. Then, they do like a manual countdown or something offline in that system.

A lot of organizations do this. They may even do things like this for accounts receivable. We’ve seen many companies manage their accounts receivable like this, where they can’t slice and dice how they want to prioritize working on receivables: which accounts to work, which claims to work, and so on. Therefore, they dump things out into Excel and then manipulate them in Excel. That’s how they prioritize and work claims. They even make notes in Excel for what they did to work that claim.

This is not only inefficient, but it’s completely infeasible for some things. Part of it is because there’s so much work where going into each record and pulling out that information individually would be way, way, way too much work. Also, it’s prone to tons of errors and all kinds of problems. Sometimes, you can do an interface from the billing system to data warehousing or reporting solutions. Often, systems are closed. They won’t allow you to do an interface, so you can’t get that information out.

Capture all data

Even if you can build an interface from the billing system to some repository that you can report off, that doesn’t mean that you can access all of the data you want. For instance if it dumps data, it doesn’t mean that it leaves every piece or field. You face multiple challenges with the structure of those tables and the database, and so on. How to convert that into something you’re going to use, especially if they don’t give you access to those tables or schema for how their database is laid out.

Also, the net effect is that you really can’t answer many questions that you want to know for data in a system. Further, it’s a considerable distinction. There are pieces of information that are not captured.

Keep your patients satisfied

I’m going to make something up for just fantastic exploration. Patient satisfaction isn’t stored in a billing system. Reporting off of that isn’t going to come out of the financial system. There is information that isn’t captured in a financial system. Maybe, some clinical information, for example, isn’t stored in that financial information. This isn’t that problem. This is that data exists, it is stored in the billing system, and you can’t get it out. Now, if someone said, “Hey, we’ve got this giant financial system like Oracle,” or pick whoever for the ERP, and the fields in that system weren’t reportable, they would look at you completely perplexed. They’d say, “I don’t even understand what you’re saying.” Why would it be in the ERP if we’re not going to report off of it?

Consider the databases

That’s what happens in healthcare. We accept all of that. I think it’s because many databases for billing systems just weren’t designed with reporting in mind. That’s because data and analytics haven’t driven this business. It’s been coming along or behind it slowly. Many of these systems were designed with old-school thought processes about billing workflow and not reporting or analysis. Often, I think the databases weren’t even designed with anything in mind, it seems. In addition, astonished at how poorly some of these databases are configured.

Part of that is because the databases were set up many years ago, sometimes decades ago. They are just old systems. Some of it is because you had engineers or database people who set it up and didn’t focus on, “Are you going to use this from a clinical workflow standpoint, or a financial workflow standpoint, or even from a reporting standpoint?”

In summary

You should be able to answer questions in your business. It shouldn’t matter what the question is. You should be able to access any data in your system, whatever it may be, to figure something out because that data is valuable. It will help you answer questions to reduce workload and even save in cost or help you identify opportunities to make more money. That shouldn’t be limited ever.

 

 

 

 

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