The EHR Revolution
Electronic Health Records (EHRs) originated as an attempt to digitize traditional paper medical records (hence the early moniker “Electronic Medical Record” (EMR), implying the system is an electronic representation of a paper medical record). There were certainly drivers for this shift from paper to electronic records, such as enhanced storage, retrieval, update, availability of patient data, and reduction of paper waste, but the capabilities of first-generation EMRs were not designed to extend the use of patient records significantly beyond similar uses to those met by their paper forebears.
Over the years, other electronic systems for creating and storing patient information came online, such as Laboratory Information Systems (LIS), and EHRs found themselves among an array of independent, isolated departmental health information systems. Converting this array of disconnected systems into a network of interoperable resources became a priority, and, while communications and content standards have helped the process, there are still semantic gaps within the data sourced from these disparate systems.
As technology and the digitization of healthcare data have progressed, EHRs have become an enabling technology for a more holistic, patient-centered, connected method of managing patient and population health. Now, EHRs are expected to be nodes of a healthcare information network connecting patients, providers, and payers in new ways designed to optimize the cost and quality of healthcare delivery and outcomes, the patient experience, and the utilization of human and other provider resources.
To realize the promise of this stage of EHR evolution, it is imperative that the information created in or consumed by EHRs is semantically normalized: that is, that the information in the EHR be an accurate, unambiguous, and portable representation of clinical intent. Semantic normalization is achieved via data normalization, the process of ensuring that meaning is preserved unambiguously across varied terminologies used by the systems in the health information network.
EHR Data and Its Uses
There are primary and secondary uses for EHR data. An example of a primary use could be a problem list used at the point of care during an episode of treatment. This kind of use may or may not benefit data from sources beyond the provider’s walls.
A secondary purpose could involve reimbursement (such as CPT and ICD codes attached to a claim), and clinical research or public health, among many other uses. These uses implicitly span varied clinical and administrative settings. Some examples include:
- Sharing data with other providers in support of a patient-centered, longitudinal approach to care settings.
- Sharing data with payers in support of risk-sharing care delivery and reimbursement models.
- Sharing data with analytics vendors or populating a data warehouse to identify at-risk populations and supply timely alerts to proactively manage their care.
- Sharing data with public health concerns, such as quality measure enforcement bodies or disease repositories, for clinical research.
- Cohort identification for defining population segments for quality measures, risk stratification, or clinical trials.
- Syndromic surveillance for a suspected emergent disease outbreak.
Enter Data Normalization
While the uses identified above are certainly key to the success of the EHR revolution (and, in turn, to healthcare reform in general), the aim of this post is to dig into a few primary uses of structured data within the EHR, and to explain how data normalization is as much a linchpin of these primary uses as it is in the secondary ones. Some of these include:
1. “Clean” data entry: Providers may enter data using familiar terminology, with computer assistance to ensure that this familiar terminology is translated into precise and accurate codes, eliminating ambiguity in the health record. For example, we might normalize data entry for a heart attack patient by mapping a provider friendly term such as “HF” to a specific SNOMED CT code (42343007) for “Heart Failure.” We could then guide the provider through refinement to a post-coordinated expression of the condition: “Acute Right-sided Heart Failure” (80479009). Another example of data normalization within this context is mapping a Computerized Physician Order Entry (CPOE) system’s local catalog of terms familiar to a given hospital’s physicians to standard terminologies, so that providers can use their preferred terminology while still preserving clinical meaning across varied departmental systems and beyond. Clean data entry ensures the accurate capture of clinical detail, which in turn reduces the likelihood of medical errors and supports timely and complete reimbursement and quality measure compliance.
2. “Clean” data integration: Providers host myriad clinical information systems across their venues, each potentially using diverse terminologies. There is also a trend towards consolidation of standalone providers into organizations such as Integrated Delivery Networks (IDNs), requiring the vocabularies at each location to be normalized to ensure intent is preserved and understood across the IDN. Additionally, sometimes procedures must be performed by external entities, such as when a hospital uses a third-party laboratory for a test—these laboratories may not use a provider’s standard structured terminology for laboratory results. Finally, Meaningful Use requirements enforce the use of specific standard vocabularies, such as LOINC for laboratory data and RxNorm for drug data, rewarding compliance in the near term with financial incentives, and punishing non-compliance in the long term with financial penalties. All of these data sources must be understood by the EHR, which requires that the content they submit be normalized in such a way that clinical meaning is transacted precisely with the data.
3. Problem lists: A linchpin of coordinated care is the problem list, as defined by Centers for Medicare & Medicaid Services (CMS): “A list of current and active diagnoses as well as past diagnoses relevant to the current care of the patient.” The problem list is crucial information that a team of providers rallies around to treat the patient in a multidisciplinary, cross-functional way. While these have historically been codified in ICD-9, a classification system designed for secondary purposes such as reimbursement and population analytics (thus requiring the physician to think like a coder), Meaningful Use requirements are shifting problem lists to SNOMED CT, an ontology modeled for recording and representing clinical data, and thus much easier for providers to use for documentation purposes. However, claims require that problems be represented in ICD-10 (as of October, 2015). For SNOMED CT problem lists to meet both clinical and administrative needs, their terminologies must be harmonized so that a problem list is clinically accurate and supportive of reimbursable claims and quality measure compliance.
4. Clinical Decision Support: Clinical Decision Support (CDS) refers to a number of ways of presenting information intended to assist in the treatment of a patient. Some of the more compelling CDS systems can inspect a patient’s medical record and offer suggestions for care, including an evidence base justifying the suggestion. As the state of medical knowledge and the standard of care advances, so do CDS recommendations, always offering timely, evidence-based CDS (and even Continuing Education credits). Other forms of CDS could include evidence-based protocols such as Clinical Pathways, Order Sets, or Care Plans. Still other CDS could simply render a drug-condition, drug-drug, or drug-allergy alert when a provider is attempting to enter a contraindicated drug prescription in CPOE, requiring normalized active medication and allergy lists. A similar alert scenario could remind a provider to include Deep Venous Thrombosis (DVT) prophylactic measures such as prescription of blood thinners for a surgical admission (this is also a Clinical Quality Measure (CQM) to be reported, a secondary use benefitting from data normalization), and to document exclusions when there is a reason to diverge from the protocol. If the EHR has unambiguous and accurate information about the condition of a patient (thanks to semantically normalized data), then it can trigger treatment advice to assist the provider. Such intervention recommendations promise improved provider performance, outcomes, patient experience, cost, and CQM compliance.
We have surveyed a number of ways in which normalized data can have a significant impact on the value brought by EHRs. If EHRs are to meet their full potential, these and other use cases require semantically normalized data—and these examples are by no means exhaustive.
What are some of the pressing data normalization challenges within your EHR?