From 3M Health Information Systems
ICD-10-CM/PCS MS-DRG Grouper Part 2
Since Part 1 was posted, our paper with full details of the MS-DRG impact study has been updated and published in the Medicare & Medicaid Research Journal and is available at http://www.cms.gov/MMRR/Downloads/MMRR001_02_A02.pdf.
I want to continue the discussion of grouper architectural changes we started in Part 1, but to justify the biggest innovation – code clusters – I first have to supply some background. We identify four ways to convert an application like MS-DRGs from ICD-9 to ICD-10:
Backward crosswalk. The application stays in ICD-9, but the data it processes, in ICD-10, is mapped back to ICD-9 upstream. We tried this out in the impact study, and discovered that it only works about half as well as replication.
Replication. The application is modeled as lists of ICD-9 codes, manipulated by logic. The lists of ICD-9 codes are replaced, insofar as possible, by lists of “equivalent” ICD-10 codes, but the logic remains the same. The intent (and to within about 1% the achievement) is to make the ICD-10 version of the application behave exactly like the ICD-9 version.
Speculation. Here one could try to make use of the greater specificity and updated structure of ICD-10 to make an application behave “better” (which, of course, means different things to providers than to payers). But this is done in the absence of ICD-10-coded historical data. So clinical and actuarial experts predict how medical records coded in ICD-10 will look, and the organization assumes the risk after 2013 that their experts are correct.
Optimization. Improving the application with data to back up the change decisions. (I would have preferred “refinement” for this option, since “optimum” implies a level of finality we will never achieve in healthcare financing.)
For our IPPS impact study, CMS asked us to replicate the ICD-9 MS-DRG grouper in ICD-10. It is not difficult to see why. Considered at a very high level, IPPS reimbursement depends on:
- The MS-DRG grouper logic which assigns DRGs based on diagnoses, procedures, sex, age and discharge status.
- A set of DRG-specific weights and trim points, based on historical volume and cost data, which characterize the relative resource demands for treating patients in each DRG.
- Rules for computing a reimbursement based on the DRG weights and trims, and hospital characteristics.
Without ICD-10-coded history, there is no low-risk way to compute the weights and trims that depend on distinctions one can make in ICD-10, but not in ICD-9.
Does this mean that the FY2014 MS-DRG grouper (version 31, the first to use ICD-10, effective 10/1/2013 – assuming the dark side remains unable to delay this further) will be a faithful replication of the FY2013 MS-DRG grouper (version 30, the last to use ICD-9)? At this point, I am obligated to remind you that the MS-DRG specification is a public rule-making process. We won’t know for sure what MS-DRGv31 looks like until the final rule is published in the Federal Register in mid-2013. But so far, there has been no talk of anything other than replication.
How long are we going to be stuck in the ICD-9 world? What follows is my answer – not necessarily CMS’s. But the usual process has been to consider changes to the DRGs in the spring, and to use the previous full year’s MedPAR data to estimate impacts and compute weights and trims. For example, whatever changes might be made to create version 29 (FY2012 DRGs, effective 10/1/2011) would be studied using the FY2009 MedPAR data (10/1/2009 through 9/30/2010). If the same lead times continue after 2013, then a full year of ICD-10 data won’t be available for analysis until the changes for FY2016 (effective 10/1/2015) are being considered.
Until then, the conservative approach to grouper construction is replication. And replication means making the ICD-10 grouper behave as much as possible the way the ICD-9 grouper behaves. When the ICD-10 codes for a condition or procedure are more specific than the ICD-9 codes were, this is no problem – you just make the grouper behave like it used to for all those new codes. The trouble occurs when ICD-9 contains information that ICD-10 no longer does and the grouper is accustomed to using that information.
Here are three examples:
- In ICD-9, the fifth digit of a whole lot of obstetrics codes told you whether the patient delivered during her hospital stay. In ICD-10, the last digit is now used to tell you which trimester the patient is in. Was there a delivery? The MDC 14 DRG logic wants to know.
- In ICD-9, there used to be a code (V57.89) for Rehab care. The closest thing in ICD-10 is Z51.89, Aftercare, which is far more general. MDC 23 wants to know if the patient is in for rehab.
In these cases, we had to change the grouper logic to look for procedures, where formerly diagnosis alone would suffice. These examples notwithstanding, the most common difference a replicated grouper has to handle is that between ICD-9 procedures and ICD-10-PCS. The solution – procedure clusters – turns out to have architectural benefits beyond just enabling replication. It will be the topic of Part 3.
Ron Mills is a Software Architect for the Clinical & Economic Research department of 3M Health Information Systems.