DIY ICD-10 conversion – Part 5

We’re still talking about converting policies – lists of ICD-9 codes or clusters that mean something that could be stated in English. These lists may be in documents, spreadsheets, the database tables that drive payment or quality assessment, or patient selection systems of any kind. In my last blog post we discussed recoding the policies, understanding what they are for and then re-creating the code lists in ICD-10. We noted some reasons why recoding may not be practical: the original intent of the policies may be obscure, or you may have more policies than your coding resources can handle, or both.

The MS-DRG grouper consists of about 500 interacting policies, APR-DRG has around 4,000, and our other groupers and editors have policy counts in that range. The meaning of each list (e.g. “minor bowel procedures”) is well understood and we have top-flight clinical analysts and physician advisors. However, we went to the trouble to develop and refine translation software for two additional reasons. First, we discovered that a clinical analyst with both an understanding of a policy’s purpose and a machine translation of its ICD-9 representation could produce a recoded policy in about a fifth of the time that it would take without the machine translation to start from. Second, since we were trying to replicate these systems (make them get the same results whether their input was in ICD-9 or ICD-10), we sometimes had to produce an ICD-10 recoding of the policy that seemed a little bizarre in terms of the intent of the policy, but correctly mimicked the behavior of the policy in ICD-9.

Building a policy translation system is not for the faint of heart. Here is where I should say, “Do not try this at home” and advise you to buy software, preferably ours. But the whole premise of this series is that you want to DIY or at least understand how we did it. So take a deep breath, we’re plunging in.

At the heart of any translation system is a table (or tables) of the clinical relationships between ICD-9 and ICD-10. As you can imagine, creating this between ICD-9 (20,000 diagnosis and procedure codes) and ICD-10 (140,000) is no small effort. Fortunately, a good set of translation tables is available for free download from CMS. At www.cms.gov/Medicare/Coding/ICD10 you will find links on the left to “2014 ICD-10-CM and GEMs” and to “2014 ICD-10-PCS and GEMs.” On the ICD-10-CM (diagnosis) download page you will want “2014 Code Descriptions in Tabular Order” and “2014 General Equivalence Mappings …” You will not want “2014 Reimbursement Mappings …” I will explain why in a minute. If you are doing procedures, find the ICD-10-PCS download page. You will want “2014 PCS Long and Abbreviated Titles” and “2014 General Equivalence Mappings …” but not “2014 Reimbursement Mappings …” This is not to say you shouldn’t download all the other files on either page – you should. They contain the official code definitions I’ve been talking about and useful general information – but the building of a translation system only requires the four I mentioned.

Pitfall 4: The so-called Reimbursement Mappings have been developed for a very specific purpose, and it is emphatically not policy conversion. Because they are simple, one-to-one, and have the word “Reimbursement” in the title, people have tried flipping the Reimbursement Mappings around to use them for converting payment systems. I tried that in a little informal study a few years ago: The payment discrepancy rate using flipped Reimbursement Mappings was around 35%, versus the less-than-1% you should get when using the GEMs and the techniques I am about to explain. I’ll discuss the Reimbursement Mappings later in this series, and the conditions under which you might find them useful.

The General Equivalence Mappings (GEMs) are the result of years of work by many people under the aegis of the Cooperating Parties (CMS, CDC, AHIMA and AHA). 3M Health Information Systems was a contractor to that project, so we don’t hesitate to use them where needed, knowing how they were built. Nevertheless, we’ll be the first to admit that they are not perfect. If you see something in your particular area of clinical expertise that you are confident should be different, do not hesitate to modify them for your own translation projects, and please share your insights via the public comment mechanisms that both CDC and CMS provide. The GEMs are updated every year and your input will be appreciated.

Several organizations have adapted the GEMs for their own purposes, removing relationships they feel should not be used in translation, or adding others they feel we left out. I have heard that BCBS has created what they call the “Blue GEMs,” but I have not seen them and have no reason to question their effectiveness. I do not plan to discuss the philosophy behind the GEMs here, concentrating instead on the step-by-step mechanics of using them effectively. However, most of what I say should apply to any translation tables with the same structure. When you unzip the GEMs files you downloaded, you will get some PDF Guides. Read them carefully if you are interested in the thought processes behind the GEMs themselves. Otherwise you can skim them for the technical information you need to use them correctly.

In the discussion that follows, I intend to take the following approach:

  1. Use diagnosis translation and the diagnosis GEMs to illustrate the techniques. Procedures are done the same way unless otherwise noted.
  2. Assume that you will load the GEMs into some kind of database, and that you will want code descriptions to go along with them, so that you can see what the GEMs say when you need to (for example, during clinical review of the translation results). Though I have not tried it, I’m pretty sure that everything I’m going to suggest can be done with a desktop database like Microsoft Access. If you have programmers working on your conversion project, they will have a favorite technology to do all this in and can be allowed to stay in their comfort zone. The GEMs and even the most elaborate policies the GEMs might be applied to are small by the standards of today’s computers, so it would be perfectly reasonable to do everything in memory and read in the raw tables as needed.
  3. Discuss which GEMs content you should use and which you should not.
  4. Explain why the 10-to-9 map is the more important and what can reasonably be done about ICD-9 codes in your policy which are “not translated.”

We start with decoding the GEMs next time.

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

Find the DIY ICD-10 posts 1-5 here.

2 responses to “DIY ICD-10 conversion – Part 5

  1. srivaths srinivasan

    Ron:

    Really love your blog posts. Is it possible to get the DIY posts as a single article. Would really help to read it all at one time.

    thanx

    *———————–Srivaths Srinivasan* *”Kahan Kahan Se Guzar Aaye”*

  2. Pingback: DIY ICD-10 conversion – Part 6 | 3M Health Information Systems

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