ICD-10 Translation Breadcrumbs

Some of our CTT (Code Translation Tool) users are especially fond of the way it creates audit trails. Every move they make—removing codes from lists, adding codes to lists, making notes about codes that need further research—is time-stamped and supplied, if they wish, with a comment giving the reason for the action. It makes sense—whenever I venture into territory I’m uncertain about, I like to leave a trail of breadcrumbs so I can get back if I get into trouble. Furthermore, some CTT users are consultants doing ICD-10 conversions for others, so they need to be able to show their clients how the codes on a client’s ICD-10 list got there.

CTT also has a feature that automates the update of a code list from one Fiscal Year to the next. If you have a list of ICD-10 codes that was created using the codes current in FY2011, you can have CTT automatically convert it to a list consistent with FY2013 codes, telling you about new codes, deleted codes, and GEMs changes when it does so.

These two features collide when the list to be converted is a translation.  A “translation” in CTT starts out as a list of ICD-9 codes, then the GEMs are applied to it and it becomes a list of ICD-10 codes with linkages back to the ICD-9 codes that caused each ICD-10 code to appear. The user then typically reviews the resulting ICD-10 list and may remove codes, run the CTT Analyzer for broader ICD-10 suggestions, add ICD-10 codes, etc. Of course, all of these actions are tracked by the audit trail.

Now suppose you have an ICD-10 translation from FY2011 that you wish to update for FY2013. CTT refuses. Why? The problem is: too many moving parts. Your original list of FY2011 ICD-9 codes might change. The FY2011 GEMs used to make the translation might change. The target ICD-10 codes might change. CTT would have to guess what you’d want to do when. For example: ICD-9 code A translated to ICD-10 code B in FY2011 but now code A has become code AA and code B has become four different codes, and the FY2013 GEMs translate code AA into yet something else.

Instead, there are two approaches you can take. One, you can extract the FY2011 ICD-9 codes from the translation and update them to FY2013. Then you would re-translate (using FY2013 GEMs) and get a list of FY2013 ICD-10 codes. This might be the preferred approach if you did not do much fiddling with the list back in FY2011. But if you did, you would now have to repeat all those thought processes, and re-enter all those notes, to bring the FY2013 result into line with your intentions for the list. It might be a lot of work.

The second approach is the one I prefer. It is based on the expectation that your ultimate objective is to create a list of ICD-10 codes that means the same thing (insofar as possible) as your original list of ICD-9 codes. Translation is only one way to get there—and sometimes not even the best way. Often, coming from an understanding of what the list is for, a user can create an ICD-10 list just as easily and perhaps more accurately, by using CTT’s list warehouse, the CTT Analyzer, and her own coding expertise. All that work you did back in FY2011 presumably created a list of ICD-10 codes that satisfied the intended use for the list. Now all you have to do is make that current with FY2013.

So here’s how I’d do it. First, leave the FY2011 translation alone. Copy its ICD-10 codes to a new list. Put a note in the new list referring back to the original translation. This keeps the audit trail from being broken. Apply the FY2013 update to the copied list. Adjust as necessary.

The important point here is:  translation is about preserving meaning.  I am reminded of an urban myth about English-to-Russian machine translation back in the 60s. Given, “The spirit is willing but the flesh is weak,” the computer came back with, “The vodka is agreeable but the meat has gone bad.” Machine translation is the starting point; the human brain takes you rest of the way. Why go back to the starting point if you don’t need to?

Ron Mills is a Software Architect for the Clinical & Economic Research department of 3M Health Information Systems.

2 responses to “ICD-10 Translation Breadcrumbs

  1. How do the DRG version 28, 29, and 30 compare to each other?

    What are their differences and similarities?

  2. Version 29 split v28 MS-DRG 15, Autologous bone marrow transplant, into MS-DRGs 16 and 17, and added MS-DRGs 570-572 for Skin debridement. Since then there have been no new MS-DRGs. Of course, each version incorporates new ICD-9 codes introduced that year and may make minor code-to-DRG adjustments. CMS also updates the MS-DRG weights each year. If you put “CMS Acute Inpatient PPS” in your browser search window it should take you to a cms.gov page, on the left side of which are links to “FY 20xx IPPS Final Rule Home Page.” If you go to one of them, and select the Final Rule Tables, you can get that year’s weights in table 5 and the details of the grouper changes in the table 6s.

    For ICD-10, the grouper released each year was generated from that year’s ICD-9 grouper, incorporating any new ICD-9 codes, changes to the GEMs, new ICD-10 codes, and ongoing improvements in our efforts to make the ICD-10 grouper replicate the ICD-9 grouper. Since the ICD-10 groupers are not used for payment and have not gone through a formal rule-making process (until version 32, which will), there does not yet exist the same audit trail of their changes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s