I think a very thorough, thoughtful, pragmatic approach, that maintains a lot of agility, that's what I've seen work. So for example, I've worked with a provider organization in Louisiana, and what we did was build out a program - a series of dashboards for them - in the first six months. And those dashboards were very specific to the key performance indicators they used to run their organizations. That meant integrating a lot of data, including financial data. And once they got that part started and they got their users to understand what this could be, then they started doing little things to continue. So they began adding more data, they added traditional ETL scripts (Extract Transform and Load, a concept of data integration that brings the data together from a financial perspective as well as clinical perspective). Those very short sprint projects that deliver value to your end users as quickly as possible, those things are what are really successful.

DMBN: Are there common failure points that organizations should watch out for when starting up BI?

Madsen: That's a hot-button topic in the BI industry - lots of argument about that, and some heated ones too.

It's like the show on National Geographic, "Anatomy of a Crash." The idea there is there's never one thing that brings down a building or a bridge or an airplane. It's always a series of mistakes that in and of themselves seem really minor, but in connection with all the other things that we do, tend to bring down bridges. So for example, in a BI deployment, there are a couple of what I consider keystones, really critical things you have to build out for a BI program to work. And if you skip those, it could lead to the "Anatomy of a Crash" - from a BI perspective.

For instance, I personally believe that from a programmatic perspective, you need executive sponsorship. Your executives need to at least buy into the idea, and give you a little bit of leeway to get the job done.

You also need to build a really solid foundation, and that is both data modeling and this idea of ETL capabilities. A data model is, if you think about it, a blueprint for how data relate to each other. And for health care, that's incredibly important because of the nature of the relationship between a patient, a physician and all the corresponding things to go with that: procedures, lab reports, claims, prescriptions. All these things are related. If you don't have that blueprint that shows you how they relate, the hallway going to your bedroom and bathroom, so to speak, you're going to build a house or data model that won't allow you to gain access to your bedroom. You need to build that infrastructure, that data model, early in your stages to build the right foundation. You have to build in good ETL scripts to provide the right kind of translation from the raw data to usable data, and that's the primary function of ETL. Health care data in its raw form is pretty unusable.

More Industry Headlines