This article was initially available on our podcast. Click here to listen.
This is a follow-up podcast to the one about “Don’t build a data warehouse.” To reiterate, we do data warehousing for healthcare providers and billing companies. You can certainly cut us a check, and we will build you a data warehouse. We’ll do all of the integrations with HSM interfaces or other types of files, pull them in from various locations, make you out reporting, business intelligence solution, a layer on top, whatever you need. That is a core part of our business. When an organization that sells those types of services says, “Don’t do a data warehouse,” it’s probably worth listening to why.
Start with preparation
I said a little bit in the previous podcast that, to some degree, data warehousing is a solution looking for a problem. In the late 90s, I was at GE Medical (what’s now GE Healthcare). We were in the middle of the Internet bubble, so everything had to be web-based. They didn’t call it web-based. I don’t remember what words they used at that time.
We were trying to figure out how to take orders for MRIs online, which made no sense at all. It wasn’t brilliant. You had to have this solution of being online with everything. We were running around trying to make everything be web-based that didn’t make sense to be web-based. We were looking for problems to solve because we had to be online to justify a stock price for GE.
That’s pretty much the case here, I think, where everybody’s all hot for data analytics and data warehousing. Yet, the problem is, most organizations just really aren’t prepared to deal with it. We’ll offer a solution here. I have a suggestion to make on what you should do.
Define the fundamental issue
It depends on what the goals for the organization are. I think the root cause of many of these problems is. There isn’t a clearly defined problem that is trying to be solved. Further, it’s this giant amorphous bucket that everything gets dropped into, like, “We want to do 36 different things, and data warehousing is going to do all of them.” The problem with that is, it becomes the thing that has far too many heads: it’s uncontrollable, and it just doesn’t work.
Would a data warehouse solve most, if not all, of those things people are all trying to dump in there? Yeah, it can. It’s just that we don’t think that it’s the best place to start—the reason why is this. The short version is, your team isn’t ready. That doesn’t mean you’re not prepared. It means your team isn’t ready. Whether you’re the CEO of a billing company or the practice manager or practice director of a 100-physician group, there’s a very, very high chance that your team is not ready to handle this.
Determine your requirements
One of the core problems is, they don’t know what they need, and they don’t know how to implement a solution that would work for them. The problem is, if you have technology people that don’t understand the clinical, the workflow, the revenue cycle management, and billing issues coming in and offering a solution, you’re going to have many problems. Ultimately, you’re going to have an implementation that fails. Even if technically it works, it’s not going to succeed.
We’ve talked about other things related to training, the motivation of team members, their willingness to adopt something, their fears, and resistance. These all get rolled up to the fact that it’s a massive mountain to try to go up. And it remains valid if you’re going to do data warehousing.
Understand the data sets
Data warehousing, by definition, is really where you’re taking data feeds from multiple different sources, dropping them all into one database, and then, presumably, reporting off of that using a business intelligence layer. So it’s not reporting off of a single database but off of many coming into one.
If you don’t have a situation where people are mechanically torquing this thing, you’ve got a bunch of people in the organization who are doing things in pivot tables regularly right now to analyze and solve problems. Let’s take denials, for example.
Let’s say, for example. You think that this is going to help you solve this problem. For instance, you’re going to have reporting across all of the different systems you have, or it will help you do charge reconciliation, bank reconciliation, or all these other kinds of things that you want to have happened. Perhaps, you’re a billing company with three, four, or five different practice management or billing systems that you have to use. You want to see data across all of them. Data warehousing can solve that problem. But it’s a lot to bite off.
Ensure team members understand the situation
We suggest finding a place where there is a clearly defined problem, where people understand the situation well, and they have tried to solve the problem already. They have effectively either solved it entirely or partially solved it by using things like pivot tables or doing things in Excel regularly to have something implemented that is working. Then, use that as the foundation.
For example, we would say, “Go and do something like denials management.”
Take the data, drop it into a database, implement denials management workflow and analytics in a little narrow part of the business, and make that work well. Automate that process, add in some things that don’t already exist to make it work better, and work through all the kinks of the team members.
It’s also about learning how to use something, learning how to learn, learning how to change their workflow processes, learning how to articulate their needs clearly, learning how to solve problems, and making that work. That will be the building block that you can use to get to full-blown data warehousing. If you have a very narrow focus and a very narrow objective, you can start with a minor team.
Create clear objectives for your data warehouse
Set very clearly defined goals, and get buy-in from that team. For example, denials management: Again, I go back because it’s straightforward. This is part of why we’ve spent much time on denials management because everybody understands that it is a problem, and pretty much everybody wants to improve it.
Get agreement on what they want to track, that they want to track things and that they want to reduce denials. Get it in writing and write up the objectives, the goals, who the stakeholders are, who will do what in the organization, and who will have what responsibilities. Talk about what specific steps they would need to do to achieve what they want to do, for example, what kind of KPIs, count of denials, percentage of denials, things like that.
Focus on necessary problem-solving
What kind of problem-solving steps would they go through to improve denials? Then, prototype it a little bit in Excel within your organization before you engage somebody like ourselves or anybody else to implement that and then implement a very narrow solution around something like denials management. Then, you have a beautiful building block for full-blown data warehousing because you have effectively set up a data warehouse but with a single source dropping into it at this time. On the other hand, potentially a smaller number (maybe two or something like that) dropping in and having a narrow focus, running analysis, and you’ll have people starting to use it.
The biggest thing of all is, you’ll have a feather in your cap that is a success. All of the management books and management theory say you need a minor victory to get people to be willing to commit all the resources, the time, and all kinds of stuff to do the giant projects and keep moving forward. Get a win! Get a win on the books, get people using something, track and see some improvement that you can use as an internal case study within the organization to tell everybody about, and use that to champion building off of this and making it much more extensive. Add in and build. Eventually, you can get to full-blown data warehousing across the entire enterprise. That’s our advice.