Less than a year to go. Probably. I’m hearing fewer, “It isn’t really going to happen, is it?” and more, “What must I do?” How to answer?
I’ve spent the better part of the last seven years working on tools to help ease the transition, some of which have been made into 3M products. I’m not the only one – there is plenty of good, healthy, competition in that marketplace. With papers, presentations, and especially these blogs, I’ve also been fighting (not very successfully) misinformation, misunderstanding, mistrust, and misdirection.
So I’m tempted to answer with “Buy our tools and read my old blogs.” But I find people I admire wanting to do it themselves. I can appreciate their motivation: The conviction that one doesn’t truly understand a process unless one works through the details oneself. Control. The suspicion that there must be shortcuts – there almost always are. The hope that, having put off the problem for so long, they’ll find it wasn’t as difficult as they were led to believe.
I’d like to help. In this and the next few blogs, I’m going to offer up what we see as the benefits of our experience in summary form. Most of it will repeat things written in earlier posts– sometimes from years ago – but many of you were still in the “ain’t gonna happen” phase then.
I plan to focus on the things you now do using ICD-9-CM that you will have to do after October 1, 2014 using ICD-10-CM/PCS. There are zillions of articles and seminars out there (from AHIMA, HFMA, WEDI, CMS, and many others) to help you get organized, build teams, draw up road maps, set timelines, involve stakeholders, etc.. By following those recommendations you can find the gopher holes in your organization where ICD-10 is likely to pop out. What we have found – and what we expect you to find – is that ICD-10 is used in about five basic ways:
Claims: This for most organizations is the biggest worry and the one I’ll have the least to say about. Coders must be re-trained in ICD-10. Their professional organizations, like AHIMA, are geared up to train them. Coding and reimbursement software must be upgraded or replaced and, I suspect, the salespeople are queuing outside your door. Practices only using a handful of codes should see Rhonda Butler’s 2012 series in this space: “ICD-10 Essentials for Busy Physicians”.
Policies: By “policy” I mean any designation of a set of patients that was made precise by using ICD-9 codes. It may be in a document: “These patients should be case management.” It may be part of a computer program: “Claims for patients with these procedures are automatically pended unless there is a prior authorization on file.” It may be part of a database query: “Graph the cost of patients showing up in the E.D. with back pain.” It may be a “problem” in an EHR’s problem list. Policies, so defined, are much more common than you might think. All of the DRG groupers, medical necessity editors, quality-of-care estimators, etc. that we in Clinical Research are responsible for were converted to ICD-10 by modeling each as a set of interacting policies, then converting the policies. Chances are, any place you find ICD-9 codes outside of a claim, they are defining a policy.
Analytics: You may have databases of patient records, coded in ICD-9, going back years. You do year-to-year comparisons, or multi-year trend analyses. After October 1, 2014, new records will contain ICD-10 codes instead of ICD-9. How do you make those comparisons then?
Financial impact estimation: Interest in this is far higher than I expected, given the level of uncertainty that should accompany any statistically honest estimation. Still, it can be done. Once you have a proposed ICD-10 reimbursement system to work with (as, for example, the ICD-10 MS-DRG grouper defined by CMS for each of the past five years) you can compare its performance to the ICD-9 system you now have if – a big if – you can come up with claims coded in both ICD-9 and ICD-10 to compare with.
Mapping: This is a technique that is often employed in dealing with some of the code-use scenarios classified above. In the short term, some computer systems (payment and otherwise) which use ICD-9 may not be converted to ICD-10; instead their ICD-10 inputs will be mapped back to ICD-9 so they can continue to run. Creating dual-coded claims for financial impact estimation involves mapping if you don’t have coders doing it. Some groups are also establishing their own mappings for policy conversion to ensure that it is done consistently across all documents and systems in their organization.
The plan for this series is to outline the techniques and strategies that have worked for us, and especially to identify pitfalls to avoid. The next post will start with policies – conquering those gets you 80% of the way there.
Ron Mills is a Software Architect for the Clinical & Economic Research department of 3M Health Information Systems.