Congress is once again toying with the notion of pushing back the new diagnostic coding requirement.

Deborah Graham, Programmer/Analyst

December 4, 2014

4 Min Read
(Image: <a href="http://pixabay.com/en/stopwatch-time-treadmill-race-259375/" target="_blank">jarmoluk</a>/Pixabay)

Easy-to-Mock ICD-10 Diagnosis Codes...

Easy-to-Mock ICD-10 Diagnosis Codes...


Easy-to-Mock ICD-10 Diagnosis Codes... (Click image for larger view and slideshow.)

Having postponed the implementation of ICD-10 from October 2014 until at least October 2015, some in Congress are now pushing for another two-year delay. The proposal is an addition to the Labor-HHS-Education appropriations bill that is scheduled to be voted on in early December. Even if that bill doesn't contain the delay or isn't passed, there are other healthcare bills coming up where the delay could be added.

I have one thing to say about that: Don't do it.

ICD-10 is a more comprehensive set of diagnostic and insurance billing codes, which the Centers for Medicare and Medicaid Services (CMS) wants to make the new standard. But switching to it involves both data system conversions and training for healthcare providers, leading to political pressure for delay.

[Hard lessons: What Healthcare Can Learn From CHS Data Breach.]

Giving providers and payers another two years is NOT going to make compliance any easier. It will set in place a sense that ICD-10 will never come to be, and all progress will come to an abrupt halt. This will not be perceived as getting more time to implement ICD-10. The last delay proved that. WEDI's readiness survey found that the same percentage of payers and providers were ready this year as were ready a year prior. No progress was made, as the delay basically halted conversion and training projects -- to be picked up a year later, maybe. Even knowing that there is a real possibility of another delay has ripples on funding and projects in place. Where I work, we have started testing with payers again, and this possibility has caused us to rethink whether we have the resources to string this out two more years (answer: no).

People are procrastinators. We put off the unpleasant until it affects us personally or financially. Maybe a compromise is needed. Allow dual-coding to be used. Providers could send either ICD-9 or ICD-10. If the payers paid ICD-10 claims at a higher rate, it wouldn't take long for providers to switch over. And those that choose not to switch could save money and just not get reimbursed as well until they switch over to ICD-10.

Maybe a phased approach could be incorporated? After each year, the ICD-9 reimbursement goes down by 10% until it just isn't worth it to send claims with ICD-9 codes. Once it impacts providers' bottom lines, they'll make the switch. Dual coding would require the payers to accept both ICD-9 and ICD-10 claims no matter the date of service, but that shouldn't be as hard to do (just remove the date-of-service restriction) as making all the providers switch over to ICD-10 on the same date. If you tie the switch to reimbursement, I would bet more providers would be getting ready and there would be no need for another delay. And those providers who don't have the resources and are pushing for the delay could continue to send ICD-9 until they feel the reimbursement reduction hurting their bottom line.

So, please, No more delays! Let's work together and get dual-coding with different reimbursements for ICD-10 use versus ICD-9 use. And we'll all be pleased at how quickly providers can switch over when they want to.

I would like to suggest to CMS to put a loophole in the wording that says compliance cannot be mandated. So, don't mandate it. Ask nicely. Allow dual coding and reimburse providers who use ICD-10 with an incentive that increases over time (or penalize those who continue to use ICD-9). And then we can all be surprised at how quickly providers convert over to ICD-10 even though it is not "mandated."

Just 30% of respondents to our new Big Data and Analytics Survey say their companies are very or extremely effective at identifying critical data and analyzing it to make decisions, down from 42% in 2013. What gives? Get the The Trouble With Big Data issue of InformationWeek Tech Digest today. (Free registration required.)

About the Author(s)

Deborah Graham

Programmer/Analyst

Deborah Graham is a senior programmer/analyst at a large hospital system in Massachusetts working in the IT department on the provider practice side of the organization. She has more than 14 years of healthcare IT experience and over 25 years of programming experience in a variety of languages and market segments, including healthcare, high-tech, and desktop publishing. Deborah's current language of choice is Cache ObjectScript (formerly known as M or MUMPS). Her favorite language is LISP. Her future plans include getting an app on Apple's App Store. In her spare time, she serves as the webmaster for her local garden club's site.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights