Breaking It Down Before Building Up: What CIOs Need to Know About EDWs

My name is Yiscah Bracha, and I am a healthcare analytics professional. I have an MS in Statistics, and a Ph.D. in Health Services Research, with more than 20 years of experience deploying analytic methods to help physicians understand how to improve their patients’ health outcomes and care.

You may be thinking about implementing an enterprise data warehouse (EDW) as the logical next step after attaining EHR maturity. Yet, you might be daunted by a recent Gartner study, which reviews 25 years of data warehousing mistakes and summarizes the salient ones for healthcare CIOs. The study found that the first fatal flaw is to treat the EDW as an IT project with the belief that if you build it, they will come. Gartner says that this was a common approach in the late 1990s and early 2000s, when more than 80 percent of IT-directed warehouses took three years to fail, replaced by purposeful data marts built by individual business units.

By contributing to this site, I hope to help you avoid this mistake. Analytic professionals are the primary customers of an EDW. We translate business concepts into measures. We translate business problems into questions and hypotheses. We populate the measures with available data. We answer the questions and test the hypotheses by applying analytic methods to the data. The data are our raw material; we can do nothing without them. So we have a deeply vested interest in the EDW, and we’d love to help you succeed. Your success translates into ours.

Analytic professionals are typically not experts in data management. Although data are our raw material, when we studied statistics, or business analytics, or industrial engineering, or applied mathematics, or epidemiology, we typically didn’t learn about Kimball models or late-binding data warehouse architectures. We may have come to learn about it if, like me, we’ve been frustrated by not having access to the data we need, and thus, we’ve taught ourselves your language so we can speak with those who stock our data supply chain.

But we don’t want to manage the data supply chain; we just want the final product. We’d like to have the data delivered to us in analytically-friendly format, because we get frustrated when we have to wrestle with them. The wrestling distracts us from our core analytic tasks. We need your help, which means that we need to show you what “analytically-friendly” means.

We’re also not necessarily experts in information technology. To be sure, we use IT, perhaps more intensively than others. In the QI department at my hospital, for example, my group of analytic professionals has a software budget about 20 times higher than any other group, and we are the only ones who budget for server space. Some of us definitely are HIT geeks. But it’s quite possible to be a very talented, productive and insightful analytic professional with only a cursory knowledge of technology. For this, we rely on you. We need you to take care of the “T” in the HIT endeavor, so we can deploy our talents effectively. But again, we need to show you which technologies meet our needs.

If we’re not data architects, and we don’t “do” technology, what do we do? We work directly with our clinical and operational customers to turn meaningless bits of data into meaningful measures. This is always an iterative process, because meaning becomes revealed over time as we share interim results with the subject matter experts. We track these measures over time and use statistical methods to differentiate between random fluctuation and genuine change. We apply analytic methods to answer questions: If we increase our patient volume in this sub-specialty, what impact will it have on beds available for more routine care? Why did our bloodstream infection rate spike last month? How can we improve patient satisfaction with our ambulatory surgical services? Can we improve care coordination if we partner with other departments that serve the same patients that we do?

If the EDW contains the data we need in a form that is easy for us to analyze, we will flock to it. And the best way to know what content we need and what structure is easy to analyze is to collaborate with us as you build. We’ll also help you find that exquisite balance point between fixed content and fluid flexibility, because we crave fixed answers for only some things; for others we crave ultimate flexibility.

For commonly used institutional terms, such as length of stay, readmission rate, payer type, we want the results baked into the EDW, so that everyone is using the same thing. It makes us crazy when every one of us has to define these things on our own, and then waste time reconciling the inevitably conflicting results. If we are required to split out results by “division”, we need the EDW to identify what a “division” is, and we want that baked in as well.

But we also need the flexibility to respond to unanticipated needs. For example, to pursue a customer’s interest in reducing infant mortality, we developed a measure for the average number of days from birth until the first newborn visit, but we exclude babies who spent more than 8 days in the pediatric intensive care unit, and with gestational age less than 37 weeks. A typical data model that includes information about outpatient clinic visits will not include information about PICU days; a typical data model about patients will not necessarily include gestational age. We need those fields, and if we can’t get them easily, and if the data architects insist that it’s too difficult to go back the beginning and add them into the model later, this EDW will not meet our needs. In healthcare, this sort of required flexibility is unexceptional. We can help you find the right balance between structure and flexibility; there is a good chance we will know where it should be placed.

In conclusion, as you embark on your data warehouse journeys, consult with your analytic professionals who grapple with business questions every day. Allow them to lead you, rather than the other way around.