Not All Healthcare Data Is Created Equal

Not all healthcare data is created equal. Data collected to satisfy different requirements benefit from a storage strategy that has been tailored to ensure that the original reasons for collecting the data are not subverted. I alluded to this last week when I described how the early distinction between a computer-stored chart and attempts to computerize the process of healthcare processes blurred. Today's EHRs approach the chart as an afterthought - after putting a lot of effort into developing computerized processes it was apparently realized that there should be some way to store the chart, so each developer has concocted one.

Warning: The following is going to get a bit technical but the concepts are straightforward. Understanding the distinctions and the jargon may help you to understand the profound difference between an external, application-neutral, long-term archive of medical records and the databases that are an integral part of today's EHRs.

In the healthcare setting there are four broad categories of data: application-specific, transactional (sometimes called operational), data that has been transformed and aggregated to answer specific questions, and the medical chart. Each category has different requirements for retention, security/access control, what purpose the data is expected to fulfill, and the breadth of the spectrum of potential creators and consumers of the data.

Every application uses some kind of internal storage to keep track of configuration options, settings, preferences, profiles, and the like. When the application is no longer needed, the data is no longer needed. Developers may engage in hot debate about the best way to store this data but nobody else really cares. Applications that have chosen to use a database server often find it convenient to store application-specific data there as well.

Many things that an EHR is expected to do such as track orders, record vital signs, admit/discharge/transfer patients, send bills etc., can be accomplished using a transactional or operational data store (TDS, ODS) - essentially a log of all the transactions that have been conducted. The ODS is typically implemented using whatever database server the developer has already adopted. Being part of the application suite, the data in the ODS is readily accessible to the developers, who use it to generate lists, reminders, and administrative reports. The definitions of the data elements and the structure of the database are often proprietary and poorly documented making it difficult or impossible for external systems to use the data in a meaningful way. Data in the ODS is subject to highly variable retention requirements.

The 2 a.m. I/O numbers on Mr. Jones are of little interest once morning rounds are completed. An order for an inpatient medication is less likely to be looked at a year from now than an outpatient prescription. Were the ODS and the medical record implemented as distinct entities, the EHR developer and the institution could have considerable latitude in how long they choose to retain various items. Unfortunately many developers and customers mistake the ODS for the medical record forcing them to retain ODS data, much of which is merely clutter, essentially forever.

Data warehousing is a set of techniques used to answer specific, recurring questions about aggregated data. That's a mouthful. It just means that if you want a report every month describing your admissions by diagnosis-related group (DRG),  the admission transactions for the month can be extracted from the ODS, grouped by DRG and a single set of numbers - the monthly totals of the number of patients in each DRG - can be written into the warehouse. Producing trends and year-to-date reports from this aggregated data is faster and simpler than running each report against the ODS and it keeps the reporting load off of the production system. Data warehouses are run separately from whatever computers are running the production applications. While they may be built using the database technology adopted by the developer other software may be chosen that is optimized for data warehousing. There is no such thing as a generic data warehouse that will take scattered data and turn it into meaningful information.

So far we have been considering applications that are relatively pedestrian and data-centric. They have more in common with e-commerce (think Amazon. com) than they do with a medical record or the practice of medicine. As I’ve mentioned before, the information that makes up (or should make up) the medical record is unlike the simple, discrete data required to process or track an order. Next time I’ll discuss the medical record in this context.