ICD-10 provides many needed attributes, but some of the data being collected seems way too excessive for practices.
Unless you have been living in a cave, you are no doubt aware that ICD-10 is coming on October 1, 2014. And although that sounds like a long way off, if you haven’t already begun the process of assessing all your systems and processes, you are now officially behind schedule. The deadline has been moved several times, but virtually no one expects it to be moved again.
I was recently asked to participate in a national webinar for the American Academy of Orthopaedic Surgeons. They have developed a large knowledge base of experts, and have several model practices that are well down the road in terms of planning and readiness. I was asked to participate in a panel on the impact of ICD-10 from an IT systems point of view.
There are plenty of articles about ICD-10 readiness, so I won’t go into much detail here. Suffice it to say that with the code set going from about 14,000 under ICD-9 to more than 60,000 with ICD-10, the impact will be dramatic to say the least.
There are several very good things about the ICD-10 code set, the primary one being laterality. For an ankle sprain, for example, ICD-9 provides no information about which side of the body is affected. That’s pretty basic information, and obviously critical to proper treatment and patient outcomes.
Another seemingly good component is the incident component - under ICD-9, there was apparently no easy way to track whether this was a first-time or subsequent episode of a specific condition. Like laterality, it’s important to track and capture first-time, second-time, and subsequent incidents of a medical condition or episode.
Impact of ICD-10 on IT Systems
The expanded ICD-10 code set is not going to have much impact on IT infrastructure, at least not in and of itself. Data-storage systems are cheap and getting cheaper, so the increased amount of data associated with the larger code set will have minimal impact overall.
However, when software vendors roll out new systems that support ICD-10, those systems will no doubt also include ever-expanded features and bug fixes, and whenever significant software changes occur, you have to look at your IT infrastructure for compatibility issues. Will the new EHR and practice-management software versions that are ICD-10-ready be able to run on your existing hardware, for example? We have mentioned several times in this column that Windows XP and Server 2003 are soon going to be completely phased out (See my "Growing HIPAA Threat: Ignore Windows XP at Your Own Peril" blog). It may well be that ICD-10-ready software will no longer run on Windows XP and other older systems.
So now is a good time to look at your overall IT infrastructure, in light of not only ICD-10 but also HIPAA security, mobility, BYOD (bring your own device) policies, meaningful use Stage 2 requirements, and other issues. Cloud services that are focused on and designed for healthcare are becoming more attractive, provided they are designed and implemented properly.
ICD-10: Too much data, too much detail?
Back to ICD-10 itself. From my research and from talking to those who know a lot more about coding than I do, it seems like some aspects of ICD-10 get way “into the weeds” as far as data collection is concerned. Everyone, from providers to payers to healthcare experts, seems to like the idea of additional granularity, but some of the data elements seem to border on the ridiculous.
For example, I attended another ICD-10 seminar recently led by a highly respected national coding expert, and she used the example of a woman cooking in her kitchen who drops a frying pan, bangs her knee, and spills hot grease on her lower leg. Of course there are two medical conditions here, the knee contusion and the lower leg burn. And it’s important to capture whether it is the right or left leg, and in this case it’s the first incident rather than a repeat or follow-up episode.
But then, according to the example presented, the data collection exercise goes well beyond the obvious level for patient care - at least to me.
Apparently as a caregiver, under ICD-10 you must also determine (and code) some or all of the following conditions associated with this incident:
1. Did the incident occur in a single-family or multi-family dwelling?
2. Did it occur in the kitchen or another room within the dwelling?
3. Was the person injured while working for hire or were they doing this as a hobby?
4. Is the person in the military?
This led someone in the audience to ask if it was necessary to determine - and to code - what was cooking in the frying pan.
Under another set of examples concerning sports injury caused by a thrown, batted, or kicked ball, there seemed to be myriad examples of the type of injury a person might receive - from a golf ball, tennis ball, baseball, football, soccer ball, basketball, unspecified ball, etc. It appears that a single ICD-9 code for sports injury expands into potentially 24 possible codes under ICD-10.
I can imagine two serious ramifications, depending on the point of view - for the provider and the patient.
Providers, who are already stretched to the limit complying with all kinds of administrative rules, not to mention keeping up on the latest medical tests and procedures, will now have to become data collection experts that make the U.S. Census’ data-gathering exercise look like child’s play.
Patients, who might be suffering from intense pain and just want to get treated so they can back to their normal activities, are now going to have to endure even more questions before they can get any relief. And given the natural aversion to supplying ever more personal data - especially when it’s already been collected before - one can easily see a potentially high level of patient annoyance.
I hope I’m wrong. I hope ICD-10 will improve individual patient care, reduce system costs, and improve the health of all of the population as a whole.