In a recent article I discussed how the Centers for Medicare and Medicaid Services (CMS) are mandating the use of the International Classification of Disease's code set upgrade from the current ICD9 version to the ICD10 version. Here are some key elements of achieving success in the ICD10 project:

1) First and foremost, there should be a significant amount of time where there is parallel processing of using both ICD9 versus ICD10. By maintaining an implementation timeline of Oct 1 2013, processing in parallel for a year should not be considered a long extended project warranty phase, but time for direct comparison. The sooner that the ICD10 version is evaluated from a change management and semantics in analytics, operation and financial reporting, the sooner the issues can be spotted and corrected before a distinct cutover is made. Doing so before the compliance date allows an understanding of how ICD10 an expensive mistake can be avoided, either with the time to resubmit or adjust claims or deal with the financial fallout of incorrect code translations, either from claims or analytical and operation decisions.

2) Decide what needs to run in parallel because new logic and business rules are being implemented and what can use just a crosswalk without implementing new business rules. Not all system changes will require the need for new business rules processing, and not all system changes can be accomplished with the same semantic outcome using a crosswalk. By evaluating the differences in results of the implementation of the new business rules, providers and insurers gain the benefit of the ICD10 medical and financial objectives more quickly without bearing the cost of some expensive mistakes.

3) Partnerships between insurers and providers should be established to process claims in parallel together in order to agree on the outcomes. How ICD10 will be used and translated will have significant impacts to the revenue cycle streams and cash flows on both sides of the equation. When it comes down to it, the largest single impact ICD10 will have across the industry is how the money is managed.

4) The decision regarding what to do with past history of data needs to be made and a strategy should be in place. The ability to look at past history as it was coded is different from the ability to reprocess past history, and this should be used as a major criteria when determining if past historical data should be either maintained in its original form or if the new code set should be applied to it. When the data is used for analytics this will make a difference in the trending that was possible and the granularity to be used within reporting, predictive modeling and other business intelligence efforts. Hospitals may also look at clinical trials and research projects differently as well.

5) Medical Coders should already be trained on ICD10 and be certified as appropriate. Claim coders, medical review staff, and other "back-office" positions should also be key resources and considered subject matter experts (SMEs) in projects for review of the changes and impacts made to systems to support the ICD10 code set. They should be responsible for contributing and reviewing the changes to workflow and reporting, before those changes are fully implemented on Oct 1, 2014.

6) Don't expect reports and analytics to remain the same. Consider throwing the old stuff out and plan on a significant amount of time to understand the ICD10 changes from a semantic and relevance point of view in your reports. What one code meant before, now means more than one thing now, or a more specific level of detail that was not previously available. (Links to examples were provided in the previous article.) Categorization may be the best way to start by looking at how the changes should be managed and how it will influence the flow of information itself.

7) There should be a business plan which includes training, communications, workflow and process evaluations, and partnerships most impacted by the conversion to the ICD10 code. The IT systems plan should be created with rolling waves of changes to each system, several times before the compliance date and several times afterwards. The business plan should constantly be reviewed and revised as needed to handle the changes that the IT plan brings about. The two must be in lockstep together for a given organization.