Now That You Have “Big Data,” What Do You Do With it?

There is a widespread belief in many circles that if you have enough data, you should be able to derive some meaningful knowledge from it. The healthcare industry has struggled for years trying to get meaningful cross-enterprise information that provides consistent, shareable, and actionable knowledge to guide improvement. This has always been a difficulty, and there is no amount of “big data” or level of technology that will address this challenge adequately without first addressing two basic matters: the quality of the data and the aggregation of that data once it has been captured. 

Data quality and aggregation have been two areas where there has historically been surprisingly little focus in healthcare. If these areas are not addressed, then the cliché of “garbage in = garbage out” will not only be realized, it will be magnified as we acquire more data. Two prior papers published in HIMSS newsletter touched on some of requirements and considerations related to assessing and improving data quality. This article will focus primarily on the area of data aggregation, making the (rather presumptive) assumption that data quality has been addressed.

Data Aggregation

Data aggregation refers to the process of grouping data based on some categorical parameters for the purpose of analysis. Aggregation can be performed for a variety of purposes, and each may result in different rules that drive the selection of the data to be grouped. Aggregation should always be based on a consensus that results in:

• The definition of the category. This definition must define:
  • Discrete concepts to be included in the category
  • Discrete concepts to be excluded from the category
• The data values or codes that meet the included concepts in order to provide the basis or rules for aggregating the data.

A major challenge with current categorical schemes is that there is rarely a full definition of what the category represents or what it is intended to include or exclude. There is rarely a clearly defined and documented set of data values or codes that would constitute the basis for aggregating the data. When most users see analytics about a healthcare condition such as diabetes, there is an assumption that the category of diabetes is accurately reported, but how the data is categorized is rarely questioned. Are all types of diabetes, including secondary diabetes and gestational diabetes, included in the results? Since most information is reported at some level of categorization, without clear definitions of how data is aggregated, it will be impossible to understand the meaning of the results, let alone compare categories across different entities.

For example, it would be impossible to compare the volume or cost of services related to “radiologic services” if one entity includes ultrasounds, MRIs, and nuclear scans in its aggregation while another entity excludes these services and only includes X-ray-based imaging services.

Aggregation can occur using any type of parameter: provider, patient demographic, payer, service type, or virtually any other healthcare data metric. Historically, aggregation of claims data focused on services rather than diseases or health conditions. As we move to an era of value-based purchasing, however, concepts such as population health, provider risk, outcomes measures, and episodes of care are becoming a bigger factor. To address this focus, healthcare information needs to center not only on what was done, but why it was done and the patient’s condition before and after care delivery (outcomes).  This means that disease-based aggregation now is becoming much more of a critical component of health policy and healthcare payment. Disease aggregation is especially challenging because it is clinical, at its core.  Without clinical knowledge, it is impossible to accurately and consistently define aggregation categories or determine which coded values (diagnostic codes) are needed to consistently include and/or exclude data that meets the categorical definition. The following examples illustrate the definition of several different categories of patient conditions:

Burns

• Proposed definition:

Burns refer to the clinical disorder of tissue damage caused by some form of thermal energy.

• Includes:
  • Heat-related burns of all degrees
  • Electrical burns
• Excludes:
  • Friction burns
  • Chemical burns
  • Cold-related burns or tissue damage
  • Sunburns
  • Radiation burns

The above definition is simply an example of how the category “burns” could be defined. Other entities might wish to include some of the excluded concepts or exclude some of the included concepts in their definition. It is critical that any comparisons or analyses of burns, in terms of costs, outcomes, or any other analytic focus, are done with a clear understanding of what is or is not included in this category, based on the category definition. The coded data and the resulting analysis may be markedly different, depending on the intent of this definition.

Down Syndrome

• Proposed definition:

Down syndrome is a condition associated with a chromosomal abnormality that results in an extra chromosome 21 (trisomy).

• Includes:
  • All conditions described as Down syndrome
  • Trisomy 21
• Excludes:
  • All other trisomys or other genetic conditions

Figure 1 illustrates that a search for the term “Down syndrome” alone would leave out codes for “trisomy 21,” which by definition is Down syndrome.

Fig. 2

As shown, sometimes the term “kidney failure” is used instead of “renal failure” Chronic kidney disease at stage 4 or stage 5 is generally considered renal failure, where stages 1, 2 and 3 are not included as renal failure. End-stage renal disease is also renal failure. All 20 codes associated with these types of descriptions would need to be included in order to accurately report on “renal failure.”

Drug-Induced Condition

• Proposed definition:

Those conditions that are the result of use of some pharmacologic agent.

• Includes:
  • Conditions described as “drug-induced”
  • Conditions described as “caused by” drugs
  • Conditions described as “secondary to” drug use
  • Conditions that are described as a “response” to drugs
  • Conditions that are described as a “poisoning” or “toxicity” to drugs
  • Conditions that are described as “withdrawal” or other manifestation of drug use
• Excludes:
  • Underdosing of drugs
  • Intentional self-harm by drugs

Identifying the codes that should be categorized to the concept of “drug-induced” is especially complex. Based on this definition, there are 3,104 codes that could be included.

Fig. 4

As shown in figure 4, if the intent was to identify all data related to drug-induced conditions; these codes would be needed as part of the data set. There is no easy way to identify all codes without recognizing how these codes are described in the data.

Getting to Comparable and Reproducible Disease-Based Aggregation

Consistent and reliable reporting of disease-based categories of data requires that categories are clearly defined and medical concepts that should be included or excluded from the category are part of the definition. Identification of the coded values that appropriately represent the intent of the category requires that codes that include or exclude the defined concepts for this defined category are properly enumerated so that they can be referenced in the grouping or categorization analytic logic. 

There is a considerable amount of research required to identify all of the codes that represent each intended medical concept to be included or excluded for any category. If, however, all of the codes that represent some granular medical concept are mapped by a defined ontology, then it facilitates the ability to rapidly and consistently identify required code values that meet any combination of medical concepts to be included or excluded, based on the intent of the category definition. A separate Health Data Consulting white paper speaks to the use of ontologies to facilitate data aggregation in greater detail.