This article is initially available on our podcast. Click here to listen.

Fields that you can’t report. Why is it that there are so many fields in billing systems that you can’t report on? 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 of the examples 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.

Determine the fields you need

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 really that you can’t get it all in one report. That’s not quite as extreme.

Frequently, you can’t get primary fields that are important in doing some analysis to export out. Insurance is one of those examples where you may not be able to get the insurance information, plan, or plan type. It may be that it lists the insurance, but it doesn’t list the method or the plan type in the reports. Therefore, you can’t do any analysis of those fields.

Tons of systems operate that way. That means everything isn’t the same. 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.

Do fields report issues?

In some systems like Office Ally, you can’t get basic information like submitting a 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. You have to go hunting around and try to go into the individual patient record. It’s crazy.

There are other situations where some required 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, whatever it might be, and 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.

How much can you customize?

We’ve seen really bizarre and quite astonishing situations where end-users requested an order 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?

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 they transcribe something into Excel. Then, they do like a manual countdown or something offline in that system.

It’s crucial to segment

Many 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. 

You need to access the right tables

Frequently, systems are closed. They won’t allow you to do an interface, so you can’t get that information out. Even if you can build an interface from the billing system to some repository that you can report off of, that doesn’t mean that you can access all of the data that you want. 

Even if it dumps data, it doesn’t mean that you want to leave all of the information you want. Perhaps, they’re not the fields you like. You’re in all kinds of challenges with the structure of those tables, the database, and more. How can you convert that into something that you’re going to use? What if they don’t give you access to those tables or schema for how their database is laid out.

The net effect is that you really can’t answer many questions that you want to know about data in a system. That’s a considerable distinction. There are pieces of information that are not captured.

How would you retrieve data?

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, 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?

Upgrade outdated systems

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. We’re astonished at how poorly some of these databases are set up.

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 so that you can figure something out because that data is valuable. It will help you answer questions to reduce workload and even save on cost, or it will help you identify opportunities to make more money. That shouldn’t be limited ever.