New Year’s Resolution: No More Harping

By: Ron Mills

A well-understood maxim among software developers states that there is generally a difference between:

  • what users say they want
  • what users want
  • what users need

The difference between the first two is one of communication and is easily solved by quickly prototyping what they say they want, so they can say “that isn’t what I want” and start pointing.

The chasm between want and need is much harder to bridge. In the short term, you can make plenty of money giving people what they want, but if you are in the game for the long haul, you ignore the difference at some peril to your reputation. When the system you build fails to solve their problem, are they more likely to come back and say “let’s try again” or will they go somewhere else?

Knowing what the user needs isn’t so easy, of course.

Generally what you have to do is walk a mile in his moccasins – which is why, IMHO, the best software is often built by folks with only modest computer skills but a deep understanding of the problem to be solved, rather than the other way around. And if you do (or think you do) know that the user needs, telling him often makes you one of those bringers of bad tidings, and we both know what happens to them. Which RFP response gets more traction?

  • “You really don’t want to do that.”
  • “Sure, we can, ahem, do that for you.”

Plus, if the so-called competition is producing a lot of number 2, endlessly repeating the first response starts to sound like sour grapes. Users wonder if what it really means is “we have no clue how to build that”.

I’ve been guilty in this space and elsewhere, much to the annoyance of my colleagues in marketing, of harping about notions of how to get ready for ICD-10 that I perceive as folly. Here, for the last time, are the four biggest ones:

Using the GEMs for coding. Users want to code in ICD-10 and have the GEMs pick an ICD-9 code for them, or worse, the other way around. They don’t like me pointing out that the GEMs were not built for that and whereas the GEMs can provide a good starting point, there is an enormous amount of additional clinical work that would have to go into constructing airtight relationships between the ICD versions with respect to coding.

Translation substituting for understanding. Users get hot under the collar when the tools I build for translating lists of codes to ICD-10 don’t “do something” with each ICD-9 code. RFPs are full of elaborate schemes to ensure every code is scrutinized by a battalion of workflow-regulated automatons, bent on ensuring that every list in the organization is treated exactly the same way. My advice to review each list in the context of what each list is used for, then apply some common sense, perhaps even eschewing translation altogether, is not welcome.

DRG impact analysis. I keep asserting that by far the best estimate of the probable financial impact to DRG-mediated reimbursement systems of the switch to ICD-10 is zero. DRG grouper designers intend for the impact to be zero, and all the analyses we have done so far end up so close to zero that I have to make up locutions like “a penny per $100 of income” to express how close to zero they are. Nevertheless, people are spending time and money trying to estimate their own financial impact. OK, but when the results come out not zero, are they willing to do the meticulous methodological debugging to discover why? And will they acknowledge that the uncertainty of not knowing how coders are initially going to code ICD-10 will anyway swamp any systemic difference their estimates show?

ICD-9-to-ICD-10 data conversion. What IT guy is going to go to his boss and say, “Ron Mills says it is pointless and dangerous to convert our ICD-9 historical databases to ICD-10, so I’m going to do nothing (other than get tools to help translate ICD-10 data back to ICD-9 and operate at some safe aggregate level) and stay in the ICD-9 world for a couple of years, until we have enough real ICD-10 experience to report on.”

So, for 2012, I’m going to give up banging my head against these walls. Besides, I have some interesting new statistics and details to report about ICD-10 MS-DRGv29 as soon as CMS releases it to the public, and similarly about ICD-10 APR DRGs when I’m allowed to. Meanwhile I have one request:

Since we allegedly learn from our mistakes, I would love to be proven wrong about any of the positions taken above. So if you know about (a) an institution that coded in ICD-10, used the GEMs to produce ICD-9 for billing and survived an audit, or (b) an enterprise-wide translation standard that clinical experts judged effective in all areas of importance, or (c) a methodologically impeccable DRG impact analysis yielding a significant difference from zero, or (d) an ICD-10 database mechanically derived from ICD-9 data that gives more accurate, more insightful or more nuanced results than the original – please post a rejoinder.

Finally, Happy New 2012. In the coding and reimbursement world it is going to be a doozy.

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

2 responses to “New Year’s Resolution: No More Harping

  1. If an organization does a financial impact study and finds that the mapping to ICD9-10 includes codes that are not mapped, or map to many codes, that would make an impact on DRG reimbursement. So, why is that a waste of time? Isn’t it prudent for an organization to take steps to understand potential impacts to cash? Of course the DRG 9 to 10 is reimbursement neutral, but if an organization’s coding will possibly change the DRG and their cash – shouldn’t they take steps to discover that?

  2. I’m confused by the phrase “the mapping to ICD9-10″ in your question. I’m not sure how that applies in the context of DRG reimbursement.

    Do you mean the choices we made in defining an ICD-10 grouper that is a replication of the ICD-9 grouper? If so, I can say we’ve done everything we can to use every ICD-10 code on the patient record to get you to the same DRG that you would have gotten to if the record were coded in ICD-9. Studies with version 29 show about a 1% DRG difference rate, which when priced yields an average change of only a few pennies per $100.

    Or do you mean the choices your coders will make in using ICD-10 to code inpatient discharges after October 2013? Use of the word “mapping” in this context is concerning — surely your coders will code directly and correctly in ICD-10. Coding in ICD-9 and using the GEMs to get ICD-10 codes is emphatically not recommended — the GEMs were not designed for that, nor will any mapping be able to provide the information ICD-10 needs that ICD-9 codes do not have. If your question is “what if my hospital is so different from the average that I’ve got an unusual number of those patients who fall into the expected 1% DRG difference?” then yes, you can do an impact analysis with your DRG mix and see how far away you are from the expected overall revenue neutrality.

    If your question is “what impact will my coders introduce by not coding ICD-10 correctly?” then I wish I had an answer. 3M and other organizations have documentation improvement services that will help you to determine if your clinicians are documenting what they do well enough for effective coding. Those folks tell me that organizations that are going to have challenges with ICD-10 will already be having those challenges with ICD-9, so such a study may be justified now. But beyond that, all I can say is ensure your coders are properly trained, don’t use a map to code, keep an eye on those DRGs which aren’t as easily identified in ICD-10 as in ICD-9 (which detail I’ll be providing in this space as the year goes on) and we’ll make sure the DRG grouper is as overall revenue neutral as possible.

Leave a Reply

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

You are commenting using your 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