Health Language Blog

Why You Should Normalize Your Clinical and Claims-Based Data

Posted on 05/27/15


Health IT systems housing administrative/claims and clinical data operate in isolation and the data is encoded via conflicting terminologies. Clinical information exchanges that want to aggregate data from those two sources are in a tough spot: the lack of semantic interoperability between claims and clinical data makes it nearly impossible to derive anything meaningful.

Unfortunately, the integration of claims data and clinically sourced data ranks among the most daunting challenges in data sharing. Claims-based data offers information on the services provided to a patient, maintained by payers often over a period of many years. The clinical side, meanwhile, provides information on the outcome of services and procedures like clinical notes, patient related problems, vital signs, allergies, etc. While claims data will list medical tests administered to a patient, it’s the clinical data that provides the results of those tests. Combining the two datasets enables organizations embarking on population health initiatives and analytics to begin to connect the dots.

Data normalization, however, maps between these two data sources.  This allowing teams to rationalizes the differences between claims and clinical data, providing the ability to match vastly different terminology and coding schemas to a system of shared meaning.  In contrast, the task of manually cleaning, organization and combining clinically sourced data and claims-based data could take months to pull off - one prominent health plan once told me that this approach to normalizing data saved their organization over 500 hours of manual work when attempting to aggregate procedure codes to LOINC(R) in order to measure what portion of the population was actually getting their tests administered.

Successful terminology mapping can provide a number of benefits in the context of clinical and claims-based data. Here’s why you should normalize your clinical and and claims data:

Facilitate Emerging Care Delivery Models

New care delivery models such as Accountable Care Organizations (ACOs) and Patient- Centered Medical Homes rely on data sharing among care providers. In addition, ACOs, often have payer participants as well as representatives from the provider side. When such organizations are able to leverage clinical data, often encoded in SNOMED CT, LOINC, RxNorm and others, they can provide a more accurate picture of health across the patient populations they manage. The ability to map between clinical and claims-based data provides that holistic perspective.

As an example, a healthcare system we worked with recently had an inpatient EMR that adopted SNOMED CT for problem list entry and an ambulatory EMR that used ICD-9 for problem list entry.  Further, they were receiving claims files based on ICD-9 from several payers they were working with. They found themselves struggling to match-up data encoded in the two terminology standards. Here’s why: SNOMED CT is a reference terminology that is most suitable for clinical documentation. It allows clinicians to make positive assertions about a patient’s diagnosis.So a clinician might initially diagnose “Cardiac arrest”, then “Cardiac arrest due to a respiratory disorder”. In contrast, ICD categorizes diseases. Grouping diseases into mutually exclusive categories is for billing. But to accomplish this, ICD codes are expressed in “coding language” rather than “clinician language”. “Cardiac arrest” becomes “Unspecified cardiac arrest”, and “Calcification of lung” becomes “Other disorders of lung.” The two standards have entirely different orientations and were never designed for interoperability. Semantic mapping, however, will let organizations walk between ICD-9/ICD-10 and SNOMED CT for disease and diagnoses stratification efforts or let them compute quality measures based on a data set containing SNOMED CT- and ICD-encoded data, for example.

Improve Quality Measures

Population health management, a component of the nation’s healthcare reform initiative, requires a robust data analysis infrastructure that can pull in anonymized patient data from myriad healthcare systems. Health systems can make the data analytics job much easier if they can map between claims-based data and the clinical variety.  Mapping serves as a foundational process that lets healthcare organizations answer critical questions, improve quality measure reporting and boost their analysis of patient care.

A healthcare system, for example, may want to identify all of its patients who had heart blocks. If that’s the case, the system would want to pull the ICD-10 CM claims code of “Other specified heart block” (I45.5) and the SNOMED CT clinical code for sinoauricular block, along with many other SNOMED CT codes. By not including patients that were identified to have sinoauricular blocks (represented by SNOMED codes), health organizations will end up creating quality measures that don’t represent the entirety of the patient populations they hope to study. As a consequence, those organizations will fail to identify at-risk patients.What’s worse, is if those quality measures are used for attesting for Meaningful Use or used in a pay-for-performance arrangement, it could mean lost revenue.

Bridge The Gap

Clinical and claims-based data have historically existed in isolation, but data that isn’t normalized can’t be readily integrated. Without integration, health systems will struggle to obtain a holistic view of patients. Data normalization, on the other hand, lets health systems cut through the differences and unify claims and clinical data that would normally remain trapped in their respective information islands.

How are you addressing the normalization of clinical and claims data? Leave your comments below.

data normalization

Topics: claims-based data

About the Author

Brian Diaz is the Senior Director of Strategy, Health Language, part of Wolters Kluwer, Health. Brian has over 17+ years of leading product and marketing teams for SaaS-based healthcare companies focused on interoperability, data quality, and diagnostic imaging. Brian has a computer engineering degree with the University of Minnesota.