Back in March, I reported at the CMS ICD-10 Coordination and Maintenance meeting that the expected financial impact of the conversion to ICD-10 for a typical Medicare inpatient case mix was -0.04% — that is, about $4 less on each $10,000 of reimbursement. I reminded the audience several times that such a tiny amount is statistically zero, since the study’s sampling error is at least 0.10%.
The report was based on several things particular to the Medicare setting in which I gave the talk: Continue reading
In Part 12 we looked up unused ICD-9 codes in your policy in the 9-to-10 GEMs cluster table. If we found a code in there, it would lead us to one or more translation alternatives, each of which consists of two or more ICD-10 codes which have to appear on the patient’s record together in order to convey the same meaning as the ICD-9 code.
Here again is one of the examples we looked at:
806.00 Closed fracture of C1-C4 level with unspecified spinal cord injury
for which the GEMs provides four alternative translates, all clusters. Here is the first one: Continue reading
To summarize policy translation using the GEMs so far:
Phase 1: Use the 10-to-9 singles GEM with reverse lookup to find all the ICD-10 codes that select patients currently selected by the ICD-9 codes in the policy.
Phase 2: For any unused ICD-9 codes, use the 9-to-10 singles GEMs to find other ICD-10 codes which may, after clinical review, be worth including
Phase 3: Look up all the ICD-9 codes in the 10-to-9 cluster GEM with reverse lookup. ICD-10 codes you find there will have a narrower definition than the ICD-9 code you find them with, so you must review them to ensure they contribute to the intent of your policy. Continue reading
At the end of Part 9, we were translating a list of ICD-9 codes – a policy – into ICD-10. We used the 10-to-9 single GEMs with reverse lookup to find ICD-10 codes that should be in your ICD-10 version of the policy. We had some ICD-9 codes left over that no ICD-10 code translated to. You tried to look them up in the 9-to-10 single GEMs. You found some translated to ICD-10 codes already in your ICD-10 policy list, so you could feel assured that their meaning was taken care of. A few may have translated to single ICD-10 codes not already on your list. Those ICD-10 codes (“pink” in CTT) might be appropriate for your policy, but a clinical review of them was recommended.
Finding all the ICD-10 codes that might be on a patient’s record, and that might imply the patient satisfies the policy, is the objective of our process. Have we now found them all? Consider this case from Part 10: Continue reading
The time has come to talk about clusters. Back in Part 3 we defined them and in Part 7 we separated the GEMs into single-code and cluster tables. But we haven’t yet looked at them closely. We can’t put it off any longer.
Clusters come into play when something that you can say with one code in one system requires more than one code to say the same thing in the other system. A couple of examples will get us started.
Example 1: One ICD-9 diagnosis
073.0, Ornithosis with pneumonia Continue reading
In Part 8 we translated a policy by looking up each ICD-9 code in the policy in the “10-to-9 singles map with reverse index” and entered into our ICD-10 version of the policy the ICD-10 codes that were found there. We discovered that not all of our ICD-9 codes were found, and we put them on an “ICD-9 Orphan” list. Now we consider what to do with those ICD-9 codes.
Start by looking them up in the 9-to-10 singles table. If there are one or more entries for the ICD-9 code, it means one or more ICD-10 codes might be appropriate for the policy, given the definition of the ICD-9 code. The emphasis is on “might be” because the GEMs do not know the information in a patient’s chart used to assign the ICD-9 code. Those ICD-10 codes could contain additional meaning that may have been true for a patient, or not, and the ICD-9 code doesn’t specify either way. Continue reading
In Part 7 you started with an ICD-9 policy list, and using the “10-to-9 singles map with reverse index” you found all the single ICD-10 codes whose meaning is included in one or more of the ICD-9 codes on your list. In other words, you found all the single codes in ICD-10 that can say what the codes on your ICD-9 policy list say. You wrote those down as a new ICD-10 version of your policy.
In the process, you may have come across … Wait. Is there a hand raised in the back of the class? Yes?
“When you had us write down each ICD-10 code we found using the reverse index, you did not have us write down the ICD-9 code it came from.” Continue reading
We are ready to start translating policies. The first step is easy to do, but difficult to believe in. When I “got it,” it was like one of those optical illusions where the cube suddenly turns inside out. I’ve watched other people see the light. I’m going to try to make that happen for you.
Reminding us of our objective: You have a list of ICD-9 codes we are calling a “policy.” This list means something. Whether or not you can express the meaning in English, there is a scientific way of inferring its meaning. If you take a large set of patient records, and you find each record which has one or more codes on the policy list, then the set of patients you have found defines the meaning of the policy. For example, if the list is a complete set of ICD-9 diabetes diagnoses, then the patients it finds are, insofar as possible with ICD-9, all those with diabetes. Your objective is to re-write the policy list in ICD-10 so that, if the same set of patients were to be coded in ICD-10, application of the list to those records would find the same set of patients. This is not always possible, but the recipe I’m advocating generally keeps the discrepancy rate below 1%. Continue reading
Having defined a list of ICD-9 codes with a collective meaning as a “policy,” we are now embarking on using the GEMs (downloaded from CMS.gov in part 5) to help build a policy translation system. The GEMs, by the way, can be used to underpin types of code translations other than policy translations, so be warned that we are not talking about any sort of GEM-based code translation now – only policy translation. We will get to other types later.
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. Continue reading