CMS will be moving over to an ICD 10 based version of its MS-DRGs 26.0 by 2014, and has already completed the Drg Conversion effort a while back. This was preceeded by a pilot conversion for MDC 6 - which in essence validated the approach taken for this conversion effort. DRG grouping, as we know, relies heavily on ICD CM / Procedures codes, and would be a good reflection on the possible approaches as well as issues involved in movement to the ICD 10 CM / PCS standard. There are some good lessons which can be taken out of this conversion effort into most of the payer processes impacted by the movement to ICD 10.
The migration to ICD 10 will result in a myriad of challenges to payer business processes and systems. Impact on payer systems and applications will be felt more in some of the bigger payers which use homegrown systems for most of their processes. For most other mid sized and smaller plans, the dependence on vendors will be higher and most of their conversion efforts would be focussed on re - defining their processes in the ICD 10 vocabulary. Right now, going by the strategies of some of the major players in the market, it wouldn't be unsafe to assume most payers are currently looking at limited remediation solutions, while very few of them are looking at crosswalk solutions (A deadline focussed quick fix, but my guess is, there has to be complete migration at some point in time). Not many payers are looking at this opportunity as a transformational opportunity at the moment, what with a lot of attention diverted at the impact of healthcare reform .
For payers using either of these approaches, the MS-DRG conversion project, gives some valuable pointers for the migration effort, particularly the restatement of their businesses and processes in the ICD 10 CM / PCS language. First, it is a clear validation of the accuracy of the backward and forward GEMs published as a reference document by the CMS to assist stakeholders in their migration effort. In this project, the GEMs were successful in producing mappings which didn't need reviews for about 95% of the cases - which validates the mapping accuracy of the GEMs. (This is not lost on many vendors, who have already come out with automated forward and backward mapping solutions for ICD 10). Second, it provides simple and useful pointers, for payer SMEs to redefine business, as well as processes, while preserving the logic embedded in the processes - for example, redefinition of rules of medical necessity, or restatement of coverage in ICD 10 and so on - easily a majority of the rules can be restated in ICD 10 terms using mapping approaches suggested below, with minimal tweaking of the rules themselves.
Here are few of the basic pointers from the DRG conversion project:
- The most apparent and seemingly intuitive way to start would be to pick up all ICD 9 codes, find out their counterparts in ICD 10. The project did just the opposite, they finalized all ICD 10 codes instead, and reverse mapped it to ICD 9. While this approach would be slightly more time consuming initially, it will save far more time in redefining process logic. Forward mapping - will may not completely ensure preservation of embedded process logic - given the fact that ICD 10 is a more comprehensive list, and in a majority of cases, more specific. Also, since the migration is being done to handle an ICD 10 world, it would be far more intuitive to have the ICD 10 codes and then assign them to positions where their ICD 9 counterparts would exist currently. This kind of reverse mapping was used in the DRG conversion project.
- Definition of mutually exclusive lists for diagnosis codes - essentially segregation of the MANY to ONE kind of mappings from ICD 10 - ICD 9. This is the easiest part and can be handled by standard mapping tools available in the market (based on the GEMs). Also there could be some possibilities of MANY to MANY mappings, but may not have an impact - since they may belong to a same logical category (for instance, an MDC category for a DRG code). This part also refers to independent mappings, meaning each of the codes in ICD 10 had no dependence on another in the list. For cases where there was a dependence, clustering (mentioned below) was used
- ONE to MANY mappings (one ICD 10 code mapped to more than one ICD 9 code) could result in more difficult situations than the one mentioned before. This can potentially be handled using conditional rules - just like the ones used for clustering (mentioned below).
- Resolution of conflict situations for diagnosis codes - a frequency based mapping resolution could sufficiently handle most of the situations. Exceptional scenarios may be handled using rules based mappings. The DRG conversion project, predominantly used the frequency based maps, based on medPAR data
- Clustering - in some places, a group of codes (diagnosis / procedure) used in combination. There is no issue, if the mappings are unique (code 1 + code 2 in ICD 10 always representing code x in ICD 9). Trouble arises, if any of the codes are shared. For example, if code 2 in ICD 10 is used in clustering for Code X and Code Y in ICD 9. Both these situations could theoretically be handled using conditional rules.
- ICD procedure codes will present the maximum issues, since the largest change has happened in the ICD procedure category. PCS codes are not merely more specific, and include additional codes, but are also specific by anatomical sites. This resulted in OVERTLY broad ICD 9 code assignments in the DRG conversion project. To handle this, the assignments were done based not just by reverse maps, but also by MDC associations (rough indicator of anatomical system involved). For payers, a combination of frequency based and rules based maps may be needed, in additional to logical categories - like anatomical sites, to produce accurate mappings.
