ICD-10 Translation Breadcrumbs

March 15th, 2013 / By Ron Mills, PhD

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.