Focus on the ICD-10 code sets has been growing ever sharper in recent months. Not surprisingly, much of the current attention is devoted to updating health information technology (HIT) and workflow processes to accommodate the new codes by the rapidly approaching Oct. 1, 2013, implementation date.
The problem, however, is that too many healthcare organizations view the ICD-10 transition as a one-time event. They plan to go live with the new codes in 2013, but most have given little thought to ongoing maintenance and support issues. Getting to ICD-10 is only the tip of the iceberg; the real challenge is ensuring the ability to evolve along with it.
As coders, billers and other HIM professionals are well aware, all coding is a continual progression. It doesnt matter whether youre working with CPT, ICD-9 (CM or PCS), SNOMED or ICD-10 (CM or PCS). As the saying goes: The only "constant" in coding is change itself.
Think for a moment about all the changes now associated with ICD-9-CM. Codes are added, deleted or revised at least once a year (potentially twice a year for codes involving emerging diseases or technology). In addition to this annual overhaul of the entire code set, healthcare organizations must contend with ongoing payer policy modifications associated with diagnosis codes. Medicares quarterly Correct Coding Initiative (CCI) updates are another example. Each one requires revisions to IT systems and policies to comply with new bundling edits; failure to do so opens organizations to the risk of potentially severe fines and penalties.
These changes will not disappear once ICD-10 is in place. The truth is that all of the effort now associated with maintaining the ICD-9 codes and standards will continue-and likely be magnified by the vastly larger and more complex ICD-10. That is why it is critical for healthcare organizations to include ongoing maintenance and support in their implementation planning. Without the right tools and partnerships upfront, the long-term effects of ICD-10 may be even more overwhelming than the initial transition.
Dynamic approach
ICD-10 is not a "quick-fix" IT issue. Converting to-and maintaining-this new code set involves more than expanding databases to accommodate seven-digit ICD-10 codes instead of five-digit ICD-9 codes. Electronic health record (EHR) and other vendors can shoulder only a small portion of burden.
In reality, ICD-10 is an issue that centers on business processes. This is partly due to the fact that diagnosis codes permeate nearly every aspect of healthcare-clinical, financial and administrative. It is also due to the granularity of the ICD-10 codes themselves.
Look at the current ICD-9 codes. Essentially, they are a set of digits that numerically represent diseases and conditions. ICD-10 codes do the same thing, but with a longer string of both letters and digits that allow the capture of an exponentially larger amount of anatomic information. While this granularity makes ICD-10 incredibly valuable, it also prevents technology from providing an easy implementation and maintenance solution.
For the most part, ICD-9 and ICD-10 codes do not correlate neatly one-to-one. Because of their many differences, there is no simple crosswalk between ICD-9 and ICD-10.
The General Equivalence Mappings (GEMs) developed by the National Center for Health Statistics (NCHS), the Centers for Medicare and Medicaid Services (CMS) and other organizations attempt to provide some structure for the differences between the two code sets. However, they are available only as flat files that require a lot of user-specific context to be helpful. In other words, they are fairly static documents.
While static code and terminology mappings will get you part of the way down the path to ICD-10 conversion, they will hold little value as the code set continues to advance. To get the most benefit out of the transition, healthcare organizations must encourage more dynamic, long-term solutions.
Scalable solutions
In most cases, the current processes used to maintain ICD-9 are not scalable to ICD-10 because of the many unique complexities inherent in the new codes. Compounding this issue is the fact that ICD-10 will only get more complex over time. Taken together, these points clearly illustrate why organizations must have a way to adopt the ICD-10 standards without continually asking users to alter their workflow practices.
Maintaining ICD-10 content ultimately requires tools that embrace and support current localized practices on the front end, while mapping to the code standards on the back end. To be successful, these solutions must be simple and transparent to the end-user.
Take, as an example, a clinician accustomed to documenting "DM" in the medical record for patients suffering diabetes mellitus. Rather than asking the clinician to use a different term or memorize an exhaustive new list of ICD-10 codes pertaining to diabetes, the provider can continue documenting "DM" at the point of care while a language engine works behind the scenes to accurately correlate the term to the correct ICD-9 or ICD-10 codes as desired.
Robust language engines contain a few hundred thousand synonyms so that clinicians at the point of care can continue documenting as they always have-yet still arrive at the right codes even as they change over time. The best language engines allow additional local customizations.
Perhaps, for example, a hospital recognizes that its clinicians commonly use six phrases, special abbreviations or colloquial expressions that are not already included on the synonym list for a particular condition. The hospital should be able to add those terms into the language engine and maintain them as the code standards change.
Sophisticated rules engines can help by prompting clinicians for more information when necessary. In many cases, ICD-10 will require much more granular documentation than clinicians are used to providing-laterality or condition severity, for example. An engine can be used to ask the questions needed to arrive at the right code.
Terminology tools such as the LEAP I-10 take such language engines a step further by allowing organizations to import ICD-9 codes and convert them to ICD-10, taking into account the possible variances that might arise from a given patient population. The ability to do this before actual ICD-10 implementation provides a way to proactively model the potential financial ramifications of ICD-10, as well as pinpoint specific clinical or administrative training needs.
Easing standardization now-and in the future
There is no question that ICD-10 is part of a broader movement toward the use of standardized data to drive care quality and cost containment. Standardization is being encouraged as a way to bridge existing data silos to help strengthen patient care, and will be most successful when it: 1) is dynamic and flexible enough to change and grow over time, 2) easily accommodates familiar codes and terminology, and 3) is simple and transparent to the end-user.
It is not realistic to expect clinicians and healthcare administrators to completely get rid of all their familiar terminologies, homemade expressions, languages and vocabularies just to accommodate the ICD-10 standard. Old habits are hard to break. Fortunately, through technology, we can work around those habits rather than try to break them. We can keep moving forward, supporting ever-changing code sets without creating obstacles. Technology solutions can be used to embrace-on the front end-all of the coding and documentation nuances that enhance healthcare at the local level, while still providing the standardization designed to enhance healthcare globally.
George T. Schwend is the co-founder, president and chief executive officer of Health Language Inc. (HLI), a global provider of software for managing and updating standard and localized healthcare terminology. With decades of leadership experience at innovative healthcare and IT companies, Schwend oversees the development of solutions and services that enable healthcare organizations to achieve interoperability, ICD-10 conversion, web-based terminology mapping and Meaningful Use compliance.
