Great article I thought I’d share on ICD-10 conversions. Much thanks to Rhonda Butler, CCS, CCS-P, Ron Mills, PhD, and Rich Averill, MS

Reading the Fine Print on ICD-10 Conversions

Even Highly Automated Conversions Require Review

Automation is a major help in converting to the ICD-10 code set, but it is not a magical solution. In fact, skipping a human review of converted systems exposes an organization to legal and financial risk.

By Rhonda Butler, CCS, CCS-P; Ron Mills, PhD; and Rich Averill, MS

People who are secondary users of coded medical records—who see only the results of data analysis—may be quick to believe that converting to ICD-10 is easier than it is. They usually don’t have knowledge of ICD-9 codes and coding, and they are typically interested in codes only as a means to an end. So when they are shopping for software or services and hear that ICD-10 conversion can be fully automated using the General Equivalence Mappings, or GEMs, they have no reason to question it.

Tom Waits reminded us in his song “Step Right Up” that “the large print giveth / And the small print taketh away.” In approaching an ICD-10 conversion, the large print is alluring, but the small print is essential reading.

The large print is this: ICD-10 conversion can be highly automated.

The small print is this: ICD-10 conversions cannot be fully automated, and they cannot be finalized without review and evaluation by a person familiar with each system being converted.

Autoconverted ICD-10 systems may not work as intended, and skipping a human review can expose an organization to legal and financial risk once the converted systems go live.

The reasons conversions cannot be fully automated are not technical. They come from significant differences in language and structure between ICD-9 and ICD-10.

These unavoidable differences must be evaluated by a technical subject matter expert who has a solid understanding of the system being converted in tandem with an HIM professional familiar with both code sets. It is these subject matter experts from both the systems and HIM realms who must resolve issues exposed by a GEMs-based translation in the context of a particular system to ensure the converted ICD-10 system works as intended.

The good news, however, is that by using the GEMs, more than 90 percent of the code translation effort in applications, databases, policies, and contracts can be automated.

Poor Conversion in a Care Management Program

Any system containing ICD-9 codes has a distinct purpose: to find patients who share similar characteristics or meet specific criteria. For example, a care management program can use ICD-9 codes to identify patients with poorly controlled diabetes so it can optimize early intervention and preventive maintenance, thereby reducing ER visits and inpatient admissions.

ICD-9 is an imperfect means of finding patients who share similar characteristics. It may require casting a wider net than needed to ensure all possible patients are identified.

In the case of poorly controlled diabetes, ICD-9 adds the words “uncontrolled” to many diabetes codes, each specifying a diabetic complication. ICD-9 creates “combination codes,” where each code title conveys two things about a patient. For example, code 250.42 indicates “this patient has diabetic renal manifestations” and “this patient’s diabetes is uncontrolled.” Thus the need to cast a wide net. No harm in that…yet.

However, say that an organization wants to use ICD-10 to find all its patients with poorly controlled diabetes. The organization reads only the large print and autoconverts its systems, taking each ICD-9 code on its list and translating it to its corresponding ICD-10 equivalent.

Because of structural differences between ICD-9 and ICD-10, what was one code in ICD-9 is two separate codes in ICD-10. For each ICD-9 combination code on the organization’s list, the GEMs autoconversion adds two ICD-10 codes to the list—one code indicating “this patient has diabetes with renal manifestations” and one code indicating “this patient has poorly controlled diabetes.”

The GEMs cannot infer the purpose of the conversion; they can only translate the original ICD-9 codes. So in its effort to fully translate each individual ICD-9 code, the autoconversion has added a whole bundle of separate codes for diabetes to the ICD-10 “poorly controlled diabetes” list without any mention of poor control.

Fast forward to the care management program in the world of ICD-10.

A patient with one ICD-10 code on his health record that indicates “this patient has diabetes with renal manifestations” has been placed in the poorly controlled diabetes care management program. So have the patients with circulatory manifestations, ophthalmic manifestations, and peripheral neuropathy—in fact, almost all diabetes patients are being referred to the care management program.

Clearly this was not a correct conversion result for this system. A subject matter expert who understands the purpose of the system would have tailored the results of the conversion to produce an ICD-10 version consistent with the system’s purpose.

Four Truths in the Conversion Fine Print

1. Conversions cannot be fully automated, and they require the active involvement of a team that has a solid understanding of both the system being converted and the code sets.

2. A conversion is not a single event with a well-defined end, but a multiphase process that will span several years.

3. It is not possible to create a valid “all-purpose” translation of ICD-9 data to ICD-10 data for general use in impact analysis.

4. Stakeholders negotiating proposed ICD-10–based changes to contractual arrangements will try to estimate financial impact with little or no actual ICD-10 data, finding themselves forced into a contest of expert opinions rather than a discussion of reliable, empirical results.

Replicated versus Optimized Conversions

Recognizing that there is formidable short-term financial risk and long-term legal risk in the ICD-10 conversion, many organizations are carefully converting their systems and policies so that they will behave the same using ICD-10 as they behave using ICD-9. This conservative strategy can be called replication. For a correctly coded record in ICD-10, a replicated ICD-10 system should yield the same result as the original ICD-9 system applied to the same record coded in ICD-9.

Since conversion errors may produce unintended payment gains and losses, the draft ICD-10 MS-DRGs published by the Centers for Medicare and Medicaid Services were converted to replicate the ICD-9 MS-DRGs so that unintended payment gains and losses are minimized. The MS-DRG conversion involved extensive review and evaluation by subject matter experts.

Some organizations may attempt to optimize a system for ICD-10 from the outset—that is, make use of the increased precision and specificity of ICD-10. An optimized ICD-10 system will intentionally not yield the same result as the original ICD-9 system. Because ICD-10 coded data are not readily available, estimating the actual impact of a prospectively optimized ICD-10 conversion is necessarily an exercise in guessing the future. For payment systems, ICD-10 optimization without sufficient actual ICD-10 data risks unintentional payment gains and losses.

For systems that do not relate to historical prices or norms, it may in fact be desirable to optimize for ICD-10. For example, claims-editing systems that identify clinical and other inconsistencies may need to be optimized for ICD-10 from the outset. Although a valid optimization of systems like claims editing can be done, the precise efficacy of ICD-10 optimized edits cannot be predicted without significant actual ICD-10 coded data.

Because many systems will first be replicated and then optimized, ICD-10 conversion will be a multiphase process spanning several years surrounding ICD-10 implementation. Even systems that can be directly optimized will need refinement as ICD-10 use and coding practices evolve.

Estimating Financial Impact

Many organizations are already feeling pressed to make ICD-10 decisions without ICD-10 data. This is especially true in the interplay between providers and private sector payers, where multiyear contracts up for renewal have much of their financial impact occurring in an ICD-10 world. The temptation will be great for stakeholders to speculatively propose and counter-propose ICD-10–based changes in the hope of benefitting their organization or at least neutralizing a change perceived as a disadvantage. During negotiations, each side will be desperate to answer the question, “What will be the actual impact of the ICD-10 portion of this contract?”

This question is difficult to answer reliably without actual data coded in ICD-10. Ideally, an organization could obtain a dual-coded record set for estimating financial impact by having coders code complete medical records in both ICD-9 and ICD-10 at the point of coding. Records coded directly in both code sets will accurately reflect the detail available in the medical record while working within the constraints of each classification.

If this option is not possible, the alternative is to convert historical ICD-9 data to ICD-10 data. However, to convert ICD-9 data usefully to ICD-10, the process must be sophisticated enough so it is sensitive to both the whole ICD-9 coded record and the logic of the system being converted.

ICD-9 data conversion for estimating ICD-10 impact should create a plausible ICD-10 version of the ICD-9 patient record. For example, many codes in ICD-9 do not specify anatomic site or gender and their ICD-10 counterparts do. By evaluating the codes on the patient record as a whole, a context-sensitive conversion from ICD-9 to ICD-10 can ensure that appropriate anatomic site or gender-specific codes are selected for the ICD-10 version of the record.

Further, in order to create a correctly coded ICD-10 version of the ICD-9 patient record, the ICD-9 to ICD-10 conversion process must accurately manage complex one-to-many and many-to-one relationships between ICD-9 and ICD-10 as well as adjust for differences in coding guidelines.

ICD-9 data conversion for estimating ICD-10 impact should be done in the context of the system being converted. The appropriate ICD-10 translation of a patient record depends on the system being analyzed. A one-size-fits-all ICD-9 to ICD-10 data conversion to create “all-purpose” ICD-10 records for general use in impact analysis is a risky proposition at best.

Mapping ICD-9 data indiscriminately to ICD-10 without system-specific rules for selecting ICD-10 codes injects a whole new level of uncertainty into the original data. It decreases the validity of the original ICD-9 data and its reliability in impact analyses. Generic database conversion programs will no doubt be made available, and the big print will claim they can do it all. However, it is just as important to read the small print for database conversions as for system conversions.

In addition to using a context-sensitive conversion process, conversion of ICD-9 data to ICD-10 data can be used to evaluate only replicated ICD-10 systems. It is not possible to estimate the impact of systems that have been optimized for ICD-10. No ICD-9 to ICD-10 conversion process can accurately infer specificity that is absent from an ICD-9 coded record, but is available in ICD-10 and required by the optimized ICD-10 system.

Financial Impact: An MS-DRG Case Study

A thorough and rigorous ICD-10 financial impact requires five conditions:

1. The system as it now operates using ICD-9-CM codes

2. A large, representative sample of ICD-9 patient records

3. The same system converted to operate using ICD-10 codes

4. The same sample of records converted to ICD-10 by one of two methods:

1. Records coded in both ICD-9 and ICD-10 by trained coders

2. ICD-9 records translated to ICD-10 by computer, using a context-sensitive process

5. A program that yields the differences between the ICD-9 and ICD-10 systems in dollars

Note that the ICD-10 version of the system must replicate the ICD-9 version for the impact analysis to be valid.

Using the above process, an impact analysis of MS-DRGs was performed as follows. First, using the ICD-9 inpatient records, MS-DRGs were assigned using the ICD-9 MS-DRG grouper and the pricer was used to compute expected payment. Second, using the same inpatient records translated to ICD-10 using a context-sensitive conversion process, MS-DRGs were assigned using the ICD-10 MS-DRG grouper and the pricer was used to compute expected payment. Third, the two payment results were compared. The impact analysis concluded that replicated ICD-10 MS-DRGs will result in a negligible overall change in hospital Medicare payments.

Challenges and Opportunities

There is no escaping that ICD-10 conversions must be done. They require a lot of work, and they take planning, attention to detail, persistence, and cooperation. But first they require that organizations read the fine print about automation and commit to doing the necessary review and validation.

To successfully transition to ICD-10, organizations must understand where differences between ICD-9 and ICD-10 matter to them—from contract negotiations to documentation requirements. HIM departments can use GEMs-based tools to efficiently and effectively assist other departments organization-wide in their conversion efforts. By automating much of the conversion effort, organizations can focus HIM resources on resolving conversion issues such as the diabetes example previously discussed.

Beyond the immediate challenge of converting the wide array of ICD-9–based systems to ICD-10, there are the longer-term opportunities afforded by ICD-10.

With the detail available in ICD-10, demand to express clinical concepts in ICD-10 codes will grow dramatically. Departments such as utilization review and quality assurance will want to use ICD-10 to create operational systems that monitor utilization and quality at a level of precision not possible under ICD-9.

Contract negotiations with payers will inevitably evolve to more precise coverage, guidelines, reporting, and other rules based on ICD-10. ICD-10 will also require more complete, precise, and accurate documentation. Developing and maintaining systems and improvement programs that benefit from the detail of ICD-10 will require the expertise of HIM professionals for their long-term success.

The implementation of ICD-10 is the most significant event for the HIM profession since the adoption of DRGs for Medicare payment in 1983. Healthcare reform, pay-for-performance, and public comparisons of efficiency and quality will create increasing demand for accurate and complete data. The additional specificity of ICD-10 is essential for achieving these objectives. For HIM professionals, ICD-10 represents both an immediate challenge and a long-term opportunity.

References

AHIMA. “Putting the ICD-10-CM/PCS GEMs into Practice.” Journal of AHIMA 81, no. 3 (Mar. 2010): 46–52.

Centers for Medicare and Medicaid Services (CMS). “Converting MS-DRGs to ICD-10-CM and ICD-10-PCS.” www.cms.gov/ICD10/17_ICD10_MS_DRG_Conversion_Project.asp.

CMS. “General Equivalence Mappings.” www.cms.gov/ICD10.asp.

CMS. “General Equivalence Mappings: Technical Documentation for Users.” www.cms.gov/ICD10/11b1_2011_ICD10CM_and_GEMs.asp.

Mills, Ronald E., et al. “Impact of the Transition to ICD-10 on Medicare Inpatient Hospital Payments.” www.cms.gov/ICD10/17_ICD10_MS_DRG_Conversion_Project.asp.

Rhonda Butler (rrbutler@mmm.com) is a research analyst and software development specialist in the department of clinical and economic research; Ron Mills is a software architect and division scientist for health information systems; and Rich Averill is senior vice president of the department clinical and economic research at 3M Health Information Systems.

Article citation:

Butler, Rhonda; Mills, Ron; Averill, Rich. “Reading the Fine Print on ICD-10 Conversions: Even Highly Automated Conversions Require Review.” Journal of AHIMA 82, no.6 (June 2011): 28-31.

Denial Management Survival Kit

with Denial Management Policy Template

You have Successfully Subscribed!