Copyright © 2012 by John Wiley & Sons, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Madsen, Laura B., 1973–
Healthcare business intelligence : a guide to empowering successful data reporting and analytics / Laura B. Madsen.
p. cm.
Includes index.
ISBN 978-1-118-21780-1 (hardback); ISBN 978-1-118-28233-5 (ebk);
ISBN 978-1-118-28394-3 (ebk); ISBN 978-1-118-28490-2 (ebk)
1. Medical records--Management. 2. Business intelligence. I. Title.
RA976.M24 2012
651.5′04261–dc23
2012012398
A year ago, senior managers at my hospital asked me a simple question in anticipation of healthcare reform:
Can you create the omnibus platform for coordination, population health, and care management that integrates heterogeneous data from large and small affiliated provider organizations, supplying retrospective and prospective analytics to improve quality, safety and efficiency?
No problem.
Everyone wants to be an accountable care organization, but no one knows how to do it.
I believe there are five tactics necessary for success in a world where reimbursement for quality rather than quantity is our future:
This book is about how to achieve number 3.
Analyzing data requires much more than technology—it requires an understanding of the very nature of the data and its intended uses. What do I mean?
A few years ago I hired an analyst who looked at one of our data marts and concluded that the average length of stay in the operating room was 127 days! They did not know that length of stay in hospitals is measured in days but in operating rooms it is in minutes.
Another analyst noted that no inpatients over the age of 65 had ever visited our emergency department. They did not realize that Medicare creates a bundled payment for all care delivered in an encounter—there is no separate emergency department charge.
This book provides all the tools necessary to implement successful analytics from an understanding of data quality to getting the project done via appropriate governance. Tactics discussed include the right scope of analytics projects to maximize value while reducing costs and time to deliver useful results. Managing data security, ensuring data integrity, and managing the impact of analytics on culture are key topics that I’m focused on every day. This book shares the details from trenches.
I know you’ll find this book to be a helpful reference for your business intelligence journey. It nicely summarizes all the lessons I’ve learned over the past decade, so you’ll have the benefit of best practices without having to repeat our mistakes!
Dr. John Halamka
Twenty years ago, I sat in a doctor's office and received a diagnosis that would change my life forever. Although I was fortunate that my diagnosis was chronic but not life-threatening, it took years of suffering before someone could tell me what was wrong. Each doctor I went to see requested the same information, the same replay of history and symptoms, and after three years of begging for relief the paper copy of my medical record came to rival Webster's unabridged dictionary. I didn't know or understand then that most of the inefficiencies within the healthcare system had nothing to do with the capabilities of the care team—and everything to do with sharing data.
Fast-forward to 2006, when my nearly two-year-old nephew sat in the emergency room of Children's Hospital in Minneapolis. He had been sick on and off for about a month, not terribly unusual for a two-year-old, but his regular doctor was concerned enough to send him and his parents to Children's. It was the Tuesday afternoon before Thanksgiving. I had just walked in the door at home when my sister called me and told me that a blood test revealed that my nephew had leukemia. In less than 36 hours, on a holiday week, he received his first treatment. We sat Thanksgiving morning in the waiting room staring at a TV screen that looked more like a report. It had the patient name, location (e.g., prep, recovery) with a green/red symbol to help identify whether he was passing between them. I was struck with the level, ease, and sophistication of the data that Children's Hospital uses every day to keep their patients and families healthy and well informed. Today, my nephew is a thriving seven-year-old.
There's no doubt that healthcare is deeply personal. The work that I do assists providers in taking better care of people like me and you. Sometimes that means a direct impact to patient care, and sometimes it means that it makes it easier for them to run the business side of providing care. But every day I recognize that the value that data provides means more efficiency, better outcomes, and improved transparency. And we all benefit in the end.
Today, as the arguments for and against universal healthcare continue, we all recognize that the fundamental structure of the U.S. healthcare system is broken. I don't claim that better use and management of data is the panacea, but I do strongly believe that it's as close to a magic bullet as anything else we have in our arsenal.
There is no better time, as data volumes increase due to regulatory pressures, to take advantage of all we have learned to create strong data management programs in every healthcare organization. The result of this will be a stronger and better health information exchange; a better understanding of members, patients, and behaviors; payment transparency; easier transitions between providers (inpatient to outpatient, or just moving geographically); improved data on drug-drug interactions; the list goes on and on.
In the information technology (IT) industry terminology the term for this type of data management work is business intelligence (BI).
This book was born out of my work in healthcare business intelligence, more specifically, my work in creating healthcare BI programs. Almost every organization I have worked with has asked the same questions and expressed similar concerns. Business intelligence is a top-10 trend for just about every chief information officer (CIO) in the country. Healthcare as an industry is behind in adopting BI, yet no other industry needs it more. The demand for data management expertise in healthcare is increasing at a rapid rate, but the resource pool is limited, especially if you are looking for someone who has built BI programs specifically for healthcare. The lack of industry knowledge and experience jeopardizes healthcare organizations' chances of success in implementing and adopting BI. As a result, many programs fail at things that they shouldn't fail at, or focus on things that are not important.
This book was written with the business leader in mind. You will not find in these pages a detailed method for building out data models (that book has been written well by others). What you will find is a guidebook for creating a BI program that will become a sustaining capability and will provide your organization with significant value. This book differs from the others written about BI. First, it focuses on healthcare, and second, it focuses on the business leader interested in BI.
The following chapters are what I consider the tenets of successful healthcare BI programs. A healthcare BI program can exist without some or all of these, but it may be on shaky ground. The challenges with healthcare BI programs are significant, from the technical to the process. The statistics continue to be disturbing: more than 70 percent of BI programs fail on their first attempt. Many factors are associated with failure for BI programs, but these tenets have been built based on my years of experience in building healthcare BI programs. I know what happens to healthcare BI programs without these tenets; they're on a fast track to disappointment.
So, how can you avoid becoming just another statistic? Use this book as your guide, your cookbook if you will, for creating your program. Why a cookbook? I have been cooking since I could reach a countertop (that's a completely different book) and what I have learned in cooking is that two cooks can follow the same recipe and have the dish turn out quite differently. That's okay, as long as they have all the right ingredients and a step-by-step process for completion. The same must be true for a healthcare BI program. Your conditions will vary. Your hospital or health plan is not just like any other organization; in order for your healthcare BI program to succeed it must (repeat, must) be created, molded, and formed to your organization. The things that work for one hospital may not work for the hospital across the street. That's okay, as long as we all have the same ingredients.
This book gives you the ingredients and, where appropriate, step-by-step process for including key factors. In addition, you will see throughout the book key points highlighted, mini case studies that are meant to provide you with an understanding of what healthcare organizations can achieve when they manage their data as an asset, and sections on how to put all the pieces together.
After reading this book, you will be able to:
It is December 2011 and I am about halfway through the content for this book. I am pausing here, at this time and place, to remind myself why I am doing this. I have found it easy in this process to get wrapped up in the length of the chapters or the tone of a sentence. I have found that the more lost I get in these details the less I remember what drives me.
My intention for this book is relatively simple: to start a conversation, to ask why the industry is what it is (or isn't). I do this because of the laser-like focus and incredibly idealist proposition that starting this conversation, pushing the envelope, can drive changes in healthcare. Although I am an idealist, I am also a realistic, so I recognize that this one book about data and reporting will likely not change healthcare in any measureable way. People much smarter than me have been trying to fix the situation for years and haven't been successful, but I am proud to be part of the group that has tried.
In August 2008 I sat down with Tom Niccum, president of Lancet. We had discussed the possibility of my joining Lancet. During this conversation we first discussed the idea of a book. In 2008 the idea of a healthcare BI book was questionable. Healthcare had not adopted BI, and although the elections were looming, none of us knew the degree to which the administration would impact healthcare BI. In other words, in 2008 we didn't have an audience. Fast-forward three years later and our healthcare practice was booming. Healthcare had leap-frogged ahead in its BI adoption and in a matter of months, a book on healthcare BI seemed like the next right thing to do.
A big thanks to Tom for starting the conversation and revisiting it until the timing was right. I owe a debt of gratitude to Nancy Dowling, my editor-on-the-side, who kept the quality of my work high. Diane Fiderlein, dear friend and colleague, whose thoroughness and knowledge guided the book from good to great. So many others at Lancet participated in their own time (and some company time) to help make this book a reality. Big thanks go to Paul Sorenson for adding intellectual vigor, and Michael Reid and Neil Schafer for great conversations about architecture and the resultant graphics. I also have to thank all the founders of Lancet for their support and faith: Chris Holtan, Jaime Plante, Rick Thorp, and particularly Randy Mattran, who continues to always expect the absolute best from me; damn that's frustrating! I would be remiss if I didn't mention the Lancet DesignHaus, a team of wildly talented artists who have dedicated themselves to the cause of visualizing data. In their free time they designed all the graphics for this book; Jennifer Maanhardt, Chris Peters, and Mike Erickson—thanks for making my notes and bad sketches look great.
I owe a debt of gratitude to the organizations that agreed to include their case studies in this book. These organizations, and the work that they do in healthcare BI, have continued to inspire not only me but all of our peers too. It's incredibly exciting to be in this industry, and I have these pioneering organizations to thank.
Finally, I have to acknowledge my family. My parents and grandmother, who constantly encouraged me in my incessant need for information and understanding, even at age five. My siblings, whose struggles and experiences with healthcare are detailed in these pages, and most of all, my husband and son. There are no words to thank them for the support that they provide and the patience that they exhibit after my endless hours on the road learning the ins and outs of my industry and then the hours locked in my office writing this book. My appreciation is diminished only by my love for you both.
No matter whose name appears as the “author” it takes a team of people to get a book to its finished state. I am humbled and incredibly fortunate to be able to work with all of you, so I thank you.
When I tell people what I do for a living they respond one of two ways. First, “Business intelligence, isn't that an oxymoron?” Oh, first time I have heard that! So funny. The second response is: “What?” Complete with a blank stare on their face.
I almost always qualify it with something like “You know, reporting and analytics.” That usually seals the deal. It's not completely accurate but in these instances I am okay with good enough.
Many definitions of business intelligence (BI) exist; the most well-known is “The right information to the right person at the right time in the right way.” This is my least favorite because it implies a factor of luck. Perhaps the oldest was written by H. P. Luhn in 1958: “The objective of the system is to supply suitable information to support specific activities carried out by individuals, groups, departments, divisions, or even larger units.…To that end, the system concerns itself with the admission of acquisition of new information, its dissemination, storage, retrieval, and transmittal to the action points it serves.” The one I use most often is: BI is the integration of data from disparate source systems to optimize business usage and understanding through a user-friendly interface.
Data warehousing is a companion phrase to BI. The well-documented best practice for BI is to create a data warehouse. A data warehouse is exactly what it sounds like, a place where a lot of data resides. Good data warehouses have a strong organization system, like the card catalogs from libraries of the past. Without that strong organization system, healthcare companies find themselves digging through their data warehouse for data, not an optimized method for certain. To be clear, business intelligence is not an IT (information technology) activity. But it does require support from your IT group for the more technical aspects of data warehousing. We address more of these in Chapter 5.
The truth is that simple definitions don't really do business intelligence justice. True BI, good BI, is an enablement mechanism to provide IT leaders and hospital executives the best information possible to improve their ability to make informed decisions. BI helps organizations go from management by instinct to management by data. BI isn't just a capability, although certainly it provides capabilities; when done well BI can become the life-blood of your organization, providing your organization with key performance indicators that help manage revenue cycle management, quality and safety indicators, or outcomes associated with diabetes management, to name a few. Few healthcare organizations treat BI as life-blood. But as you will see throughout these pages, when they do, the results are nothing short of stellar.
BI isn't reporting, it isn't analytics, it isn't data warehousing, and it isn't dashboards. All of these things individually do not make a BI program, but put them together and that is exactly what BI is. Business intelligence enables all of these. BI is greater than the sum of its parts. You may question why BI enables data warehousing, but the truth is that you don't need a data warehouse if you don't intend to analyze data or report from it. BI is an industry and a skill set, but BI isn't the group you go to that will provide you the knowledge or intelligence about your organization. Good BI means putting valuable information at the fingertips of many businesspeople, not just a lucky few.
If your organization uses data to make decisions then the answer is yes. If your organization wants to use data to make decisions then the answer is yes. If your plan is to hire a team of really smart analysts then the answer is no, because BI is meant to deliver information to a broad audience. The degree to which you have to invest and create your BI program is what should vary.
“Do you need BI?” is a great question, and one every person who is in charge of a BI initiative should ask themselves often, and here's why:
Ask yourself these questions at least twice a year, and depending on how your organization is structured, have a prepared statement or a PowerPoint ready when these questions are posed to you by someone else.
To “do BI” you will have to organize your data for usage. Odds are, as you read this, your hospital or clinic has data stored somewhere. That data comes from a transactional system like an electronic health record (EHR) or a financial system. The data on its own is not user-friendly for the majority of businesspeople. If the goal of BI is to put better information into many businesspeople's hands you must take the time to organize your data to ensure that it's easy to use and provides the most value. That is where a traditional data warehouse comes in.
When working in healthcare I do make a few modifications to the traditional data structures you see in other books on the topic. For example, the analytics sandbox and audit control sections are critical to healthcare organizations, but maybe not as necessary for retail. Each of them provides a method to allow your more sophisticated analysts access to the data that is granular. The analytic sandbox provides your analysts a “play space” to create predictive models that can help you adjust staffing in your emergency department without an impact to regulatory reporting. The audit control environment (ACE) provides a one-stop-shop for both internal and external auditors to see the data and the path the data took to validate your approach for anything from JCAHO (the Joint Commission for the Accreditation of Healthcare Organizations) reviews to medical records reviews for public health documentation.
The first thing you should know about your data environment is that it is unique to your organization and should be created based on the needs and wants of your hospital or health plan. As you construct your information environment, important key criteria need to be kept in mind. These environments are built to optimize stability and data usage for your organization. Some methods of shortcutting the process exist, but few deliver the capabilities that are promised during the sales cycle. We review these methods in Chapter 5, but for now let's look at the baseline healthcare information environment that I recommend.
Let's start at the beginning, or in this case, on the left side of Figure 1.1. The source systems in healthcare do vary, but they generally follow two categories: Clinical and Financial. In theory, anything that has data can be a source (e.g., Excel), but as you consider what you bring into your data warehouse you need to ask yourself a basic question: “Yes, you can, but should you?” Every industry is buckling under the weight of data, prompting interest in “the Cloud.” But not all data is equal, only data that provide valuable insights should be stored in your data warehouse.
FIGURE 1.1 Healthcare Information Environment
The next step in the environment is the staging area, often referred to as the operational data store. Named for the type of data that generally appears, for healthcare we find that the staging area provides an important two-stage function. The first is to isolate activity against your transactional system. In other words, you don't want your EHR performance to slow down so that you can run a report, and staging areas help provide that buffer. The second function is to maintain a completely untouched version of the data that can be used if there is a data load failure. This prevents the need to go back to your transactional systems (EHR or financial system) to pull the data again. This also protects the transactional system. We take a copy of this data and store it, untouched, in the audit control tables. These tables enable support for the internal and external audits that are routinely done in healthcare. Although not necessary, these control tables make audits much easier to manage because all of the required data and supporting documentation needed for audits (e.g., transformation scripts that outline the changes that were made to the data) are included.
The next section is the extract, transform, and load, or ETL, portion of the healthcare information environment. ETL is absolutely critical for healthcare. In its raw form most healthcare data is unusable for the average businessperson. The “transformation” part of ETL is the application of business rules so we can aggregate things like encounters and deduplicate provider and patient records. Once the business rules are applied we place this data into an organized set of data tables within the data warehouse itself where the most granular level of data exists, such as the claim level or patient level. The function of a data warehouse is to aggregate the most granular data up into summary level data to improve the ability to use the data. For example, in its most granular form a claims record can have many rows (think about this in the context of Excel). Each row may represent a different status of the same claim, such as submitted, paid, reversed, or rejected. Most claims go through many different statuses before it's considered a “final paid” claim. If the average businessperson is only interested in the percentage of rejected claims, then having to go through this granular data is time consuming. The organization of your data warehouse removes the need for a businessperson to have to do that by aggregating (in this case summing) the number of rejected claims for a specific time period or place based on business rules.
Within this environment an analytic sandbox can also exist. These sandboxes are the “play space” for your analysts and they should not allow the average businessperson access. These sandboxes give analysts a chance to test models and create new business rules or functionality without exposing the activity to everyone. This allows for innovation using data. As we move right in Figure 1.1 you see the data mart section. Data marts represent logical subject areas, such as claims or encounters, any subject area that you report on frequently; data marts are created to improve performance (response time of reports). In other words, most of your standard reports will access data contained in these data marts. This is not a required method, but if you know that you will have a high degree of usage of reports, these logical subject areas are quite helpful in managing the overall performance of the system.
Finally, we have the BI presentation layer. This presentation layer represents the BI products that you have bought (e.g., MicroStrategy, Cognos, Tableau, SAS) to allow your businesspeople access to the data. This would include products that provide reports, dashboards, or even ad hoc analysis to all users of the data. I will make a somewhat controversial statement and say that your BI presentation layer will likely have multiple tools. Some tools are better at certain things than others, and if you have a strong analytic component of your BI program, your standard BI product will likely not meet all of your needs.
Every BI program is different because every organization is different—this is not a one size fits all. If you've seen one BI program you have seen one BI program. Critical similarities, such as the need for a data warehouse, ETL (in some form), and a method of report distribution exist, but the rest is the art of good BI.
The art of BI is probably the most difficult thing to master. It is often the function most overlooked by organizations. I have seen hundreds of BI programs, and each one is different, but the ones that have considered the “softer” side of delivering valuable information to their businesspeople are successful. They have considered what it takes, who it takes, and haven't compromised on quality, or backed down on the need for good architectural standards. They are a testament to what good BI programs do. Good programs have strong BI leadership that is aligned and empowered. They have a strong and dedicated staff, they don't go for the “easy” button, and they understand that the foundation of everything starts with data modeling.
I have struggled many times to explain or define data modeling to a businessperson. When business leaders are trying to decide whether they should invest in this thing called a data model, where the deliverable, at least from their perspective, is a drawing, it isn't that complicated. But when they get down to what data modeling can do for their BI deployment and how it does it, it gets tougher.
Most people understand the concept of data hierarchies, and the idea that some data cannot be summed. Much of that understanding is the foundation of data modeling. When you do data modeling right, you define the hierarchal nature of the data. A great example is time: Year, Quarter, Month, Week, Day, Hour. For most healthcare organizations you have some type of organizational hierarchy such as Department, Unit, and Floor. The other part of data modeling is identifying the “facts” and “dimensions.” Simply, the things that can be summed and the dimensions are attributes of the facts. For example: A dimension of a patient or member is their unique identifier, so you can't sum that. You can sum the total number of patients or members, which is a fact. The vast majority of data modeling is simply organizing your data in the appropriate hierarchies, facts, and dimensions.
The art of data modeling is to know when to do what, and how to create the relationships between these. In healthcare the relationships in our data are complex; in data warehousing we call it a many-to-many, which happens over and over again (think about the relationship between a patient, physician, diagnostic code, member, address, etc.).
I will stop here, at the risk of getting too much into the detail to confuse the point. The point is, data modeling for healthcare is complex and requires a special skill set. We discuss this further in Chapter 5.
Much of this book focuses on what you should do, but here are four things you absolutely should not, under any circumstances, do:
If you have decided that you need BI and are ready to start on this journey, here are the hallmarks of good BI programs. They:
If you do these things, you are well on your way. The rest of this book is dedicated to each of these hallmarks of BI programs, referred to as the Tenets of Healthcare BI. If you have started your program and already have some of these, you can skip to the chapters that will be most helpful to you. If you are starting from scratch, you'll benefit from reading this book from cover to cover and joining our online collaborative community for further discussions.