GETTING ANSWERS FROM YOUR ORGANIZATION’S DATA

GETTING ANSWERS FROM YOUR ORGANIZATION’S DATA – SUCCESSFULLY

Health care organizations often find themselves with “Data, data everywhere” yet unable to get the answers to critical business questions. Common problems include:

Inconsistent answers to the same question
Delays in decision-making due to difficulties in obtaining answers from the data.
Data that just doesn’t “feel” right.
Errors due to misinterpretation of the question by the data analyst
Having to ask questions (or getting answers) in computer-speak rather than in healthcare business terminology

This article summarizes a more effective approach to getting answers from your organization’s data.

CREATE A STABLE REPORTING PLATFORM

The core requirement for using your data to get reliable, consistent answers for decision-making is to create a stable platform for reporting. Billing and claims systems don’t provide such a platform. The data in these systems changes constantly and so will any answers you get directly from them. What’s needed is an analytical data warehouse, specifically designed for reporting. While transaction systems are designed for speed in getting information into them, data warehouses are designed for efficiency in getting data out. The data warehouse is loaded with a series of data snapshots, usually taken monthly. Because all analyses are performed on the same data, what you learn from your analyses will be internally consistent. Data warehouses can be structured to allow users to access the central data through an internal website, and to work with it using familiar desktop tools like Excel or Access. Once this is done, you can eliminate the many data “fiefdoms” and duplicative databases set up by individual users, and with them, the difficulties caused by multiple versions of “the truth.” The warehouse should become the only accepted source for obtaining data for the variables included in it.

USE THE RIGHT TOOLS FOR BUILDING THE DATA WAREHOUSE

Data warehouses need to be constructed using a real database system, such as SQL Server or Oracle. While Excel is tremendously useful, it is not a database. It can’t enforce data consistency and its 65,000 rows are not nearly large enough to handle the kind of data volume you can import from a transactional database. Microsoft Access also has limitations with very large databases, such as limited security across multiple users. Using Excel as a database can create real problems in the long term. When DGA has been asked to convert physician “databases” in Excel into other formats, data clean-up (eliminating duplicates, editing impossible birth dates, aligning elements in addresses) has taken more time than designing the new application. Use your “industrial-strength” database software to create an OLAP (On-line Analytic Processing) database. This lets you build true business intelligence applications by structuring the data into your own business concepts. It pre-summarizes the data for fast response when you ask a question. Users can drill-down into the data, following their own thought processes, without requiring complex software or being able to program. OLAP databases can be constructed from multi-million record databases, and yet give response times measured in seconds to most queries. Some database products include the OLAP component for free.

PRACTICE PREVENTIVE DATA MANAGEMENT

Data “hygiene” is serious business. You can prevent confusion and save huge amounts of time and energy by investing the effort to create consistent business-based data labels and a coherent data structure. The quality of the data you use to populate the data warehouse is equally critical. Use business terms for data elements rather than geek-speak. Label your fields with full words that will be understood by all users, e.g. Cardiology rather than CRDY. Create a data structure that defines your terms, rather than allowing analysts to define them (usually slightly differently) each time. The decision on how to group patients by diagnosis should be made once by clinicians, not multiple times by data analysts. Even “simple” definitions like patient days need thorough definition. (Is rehabilitation subacute or acute? Is “nursery days” part of “total patient days” or a separate category? What about skilled nursing days?) We sometimes find that clients have only one person who can assemble the dozens of data fields (with names like BZRFT) into a real query. No one can check their work, and all analysis stops when they go on vacation. By building that knowledge into the data structure, the organization gains flexibility and empowers managers to make better use of available data. Be sure that data is cleaned before it is used to populate the data warehouse. Make sure users know how many records in each field contain data, to avoid the potential for serious distortion of totals or averages. Some important fields need to be calculated. You may need a multi-step, multi-field process to calculate the number of admissions. Define validity checks for each important field. Create an easily-identifiable value to indicate where the original data is incorrect, so you can exclude those records in doing calculations. Having timely and accurate data is tremendously empowering to any business. Spending the time to properly design and build the analytical data warehouse provides an unmatched advantage in today’s healthcare market.