This book includes a plain text version that is designed for high accessibility. To use this version please follow this link.
Figure 6

Figure 7

Any business rules for mappings would need to be entered and stored in at least fi ve systems, plus any analytics systems that source data from the applications. With 252,752 GEMS mappings, 148,885 reimbursement mappings, and 162,685 ICD-9/ICD-10 codes to manage (564,322 records in total) and potentially tens of thousands of overrides in addition to the GEMS and reimbursement maps, the potential for errors and rework is huge.

Trending and analytics with historical data Most payers and providers require at least three years of historical data for trending and analysis purposes. On Sept. 30, 2013, all of this history will be encoded in ICD-9 nomenclature. On the following day and going forward, the “neo history” will start to be encoded in ICD-10. Any type of trending will either require a migration of all of the history to ICD-10 or some mechanism for stepping up ICD-9 codes to ICD-10 or stepping back ICD-10 codes to ICD-9 for analysis (and maybe both). Migrating or stepping up from ICD-9 to ICD-10 is non-trivial and will require a standard, business rule-driven approach to avoid really skewed analytics.

The solution: master data management A master data management approach will resolve many of the aforementioned challenges, both conceptually and practi- cally. The MDM Institute defi nes master data management as an “authoritative, reliable foundation for data used across many applications and constituencies with the goal to provide a single view of the truth no matter where it lies.” Applied to ICD-10, a master data management approach would provide a central, managed storage and access point for processes and systems that need to consume ICD-9 or ICD-10 codes, mappings and translations (GEMS, reimburse- ment, overrides and any other desired mappings or hierarchies). Figure 7 illustrates how the fi ctional (but realistic) payer A ecosystem could look with an MDM solution providing a centralized storage point for disease and procedure codes and mappings, accessible via a business process management/services layer. In this context, a single set of business rules, mappings and translations can be applied uniformly to all processes and supporting applications.

The benefi ts of implementing a master data management approach are widespread: • Applies consistent business rules uniformly to all processes and supporting applications without having to maintain the rules in multiple places with redundant maintenance pro- cesses.

• Facilitates consistency in approach and rules when major applications are sourced from multiple software vendors and integrated with homegrown applications.

• Lets fi rms select which systems to remediate without sacri- fi cing compliance or analytic excellence.

• Supports standard CMS mappings (GEMS and reimburse- ment), but permits the organization to override or extend the standard mappings based upon customer/trading partner, business process or function.

• Makes it easy to update systems with future changes in mappings (ICD-11 or other future code sets) or additional value-added mappings (diseases to procedures or DRG mappings).

• Promotes analytic excellence by ensuring consistent results when transactions across multiple systems are aggregated for analysis.


Healthcare organizations burdened with meaningful use, healthcare reform and HIPAA 5010 requirements may lack the time, resources and budget to remediate all of their systems to ICD-10 by the Oct. 1, 2013 deadline. The common approach to implementation – allowing vendors to remediate core systems while using crosswalks for in-house, legacy systems – is rife with challenges. These problems include divergent approaches to crosswalking, diffi culties in obtaining meaningful analytics with data in ICD-9 and/or ICD-10 codes, and the inability to deal with overrides and exceptions to the standard government mappings.

A master data management approach solves these challenges by centralizing and controlling rules, mappings and translations that can be applied uniformly to all applications. This facilitates a consistent approach, enables selective remediation without sacrifi cing best practices, allows for overrides and can be easily updated with future mapping changes.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38