Remediation and ICD-10
By Sandeep Veeramani
For The Record
Vol. 26 No. 1 P. 27
As the ICD-10 compliance deadline nears, it’s important for payers and providers to choose the right approach to remediation. The method must be robust and capable of handling the large mapping combinations that now can result because of the sharp increase in the number of possible codes. It also must be flexible enough to handle the mapping changes based on context and rules, and be appropriate to the health care organization’s business context.
Updates to the changes applied during the move from ICD-9 to ICD-10 must be documented scrupulously to avoid any pressure of playing catch-up. Tackling the new coding early will save time and eliminate headaches when it’s necessary to provide reports.
Selecting an appropriate mapping approach is one key factor to consider when choosing a remediation strategy. A mapping approach for ICD-10 can be broadly divided into two strategies: code based and range based.
Because it aims to find and map each ICD-9 code being used and its equivalent ICD-10 code, code-based mapping is more granular. This approach is appropriate only when the application of each ICD-9 code must be considered individually and in the context of the business.
However, there are several business rules and processes that do not apply to specific ICD codes. For example, a payer may have benefits that apply in general to all obesity and other hyperalimentation diagnoses. In this scenario, the payer does not need to map to each of the individual codes pertaining to the condition. For example, 278.0, Overweight and obesity; 278.1, Localized adiposity; 278.2, Hypervitaminosis A; 278.3, Hypercarotinemia; 278.4, Hypervitaminosis D; and 278.8, Other hyperalimentation require a range of ICD-10 codes equivalent to the ICD-9 code range of 278.0 to 278.8.
This situation calls for range-based mapping, sometimes referred to as the equivalent aggregation mapping approach. Range-based crosswalks accept a range of ICD-9 codes and output an equivalent range of ICD-10 codes that have the same medical meaning, which then can be used to remediate ICD-9 code group usage scenarios such as the above example.
However, there are three challenges that must be considered when applying a range-based aggregate mapping remediation solution.
• Range explosions: A sequential range of ICD-9 codes will not necessarily map to a single sequential range of ICD-10 codes; it’s more likely to translate into a fragmented series of ICD-10 code ranges. This is because of the exponential increase in the number of codes present in the new standard: a fivefold increase in diagnosis codes and a 20-fold increase in procedure codes.
In the obesity and hyperalimentation example, the range of ICD-9 codes that pertain to obesity (278.0 to 278.8) actually map to more than one ICD-10 range (E65 and E67.0 to E67.8). Such scenarios pose significant problems for users of range-based crosswalks because any automated business process that makes decisions based on range mappings can produce numerous errors.
For the payer in this example, an error in aggregate remediation can result in several claims landing in a manual review queue that otherwise would have been successfully autoadjudicated, thus increasing claim processing costs and decreasing the payer’s competitiveness.
• Category conversion: Developing an equivalent aggregation approach to remediation can be challenging in cases where the source business rules are defined based on ICD-9 categories. It is difficult to translate an ICD-9 range that was based on code categories to ICD-10 because code categories do not contain specific diagnostic information of a patient’s condition.
Ranges based on code categories also are difficult to translate to ICD-10 because the system of grouping diseases into categories has changed between ICD-9 and ICD-10. Therefore, the process of aggregating a range of ICD-9 codes, which was based on an ICD-9 category, into an ICD-9 code range and then developing equivalent ICD-10 code ranges likely will be a tedious, inaccurate exercise.
Continued reliance on categories to drive business rules must be questioned because it implies that the business process does not take advantage of the additional specificity offered by ICD-10 codes, thus defeating the benefits of introducing a better and more scientific coding standard. With this in mind, ICD-10 remediation teams must review the wisdom of using ICD-9 categories as a basis for defining business rules before attempting a range-based conversion to map category-based business rules.
• Data cleanliness: Because they are predominantly numeric, the ICD-9 codes often are treated only as numbers and coded as such. For example, if the last code in a range is 985.9, the code 985.99 is entered into the system. This will make the range appear invalid because the code 985.99 does not exist in the list of ICD-9 codes published by the Centers for Medicare & Medicaid Services. All efforts to map these ranges automatically to the ICD-10 structure using a crosswalk will be futile.
A great deal of manual effort will be required to sift through every range and identify these invalid codes, which then will need to be replaced by valid ICD-9 codes in time for the transition to ICD-10.
A range-based conversion strategy for the remediation of systems from ICD-9 to ICD-10 can effectively decrease the transition’s complexity when dealing with business processes that handle ranges of ICD-9 codes. However, the approach is not without its pitfalls.
Health care organizations, physicians, and industry professionals must evaluate and address system risks now to be fully prepared to prevent disturbances at the October deadline. While many professionals will turn to aggregation or range-based remediation tools to help transition to the newly accepted ICD-10 codes, it’s important to remember that all the codes may not align to provide a seamless solution. Instead, it will mean tackling the new codes early and frequently updating information to ensure that patients, providers, and payers are all receiving what they need.
— Sandeep Veeramani is lead business analyst at Hexaware Technologies.