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.