Chances are if you are reading this, you have been directly involved in your organization’s ICD-10 compliance effort —  and are both looking forward to October 1, and a bit nervous. Your team is probably working on last-minute items such as final testing, physician training reinforcement, coding “practice…practice…practice, ” and much more.

October 1 is not, however, the end of ICD-10 implementation, despite common misconceptions.  It is merely the date of an important transition, which, per the sage Merriam Webster, is the “passage from one state or stage to another.” October 1 represents the end of the first phase of ICD-10 work — focused on a single goal of implementing systems, processes, and procedures that support the generation of ICD-10 coded claims. What happens after October 1? Very possibly, a path that is slow and not automatically smooth.

The second phase of ICD-10 is real-world ICD-10 operations — and likely will start out with rocky periods.  ICD-10 operational processes, like all new processes, will have higher error rates until your teams become familiar with the ICD-10 data elements and what they mean.   These error rates will be most pronounced in the next few months. In order to drive quality improvement,  it will be critical to your organization’s work (and revenue) flow to provide frequent and robust data feedback to your affected departmental teams.

This operational phase of ICD-10 will begin for most hospitals some time around October 5^, depending on how quickly the first claims are coded and ready to be billed. That’s when everything changes! At that point, ICD-10 becomes an operational problem, and the primary tool for managing operational processes will be actionable data.

There are three major types of data that will be especially significant in your quality improvement effort: inventory data, grouping data, and denial data.

Inventory data

• DNFC
• DNFB (which usually includes DNFC that can be netted out)
• Charts returned to the provider for clarification
• Bills placed on hold
• Claims held by the claim editor
• Claims out to payer with no response
• Unworked front end rejections inventory
• ICD-10 code related rejections received
• ICD-10 code related rejection inventory

Grouping data

We’ve discussed the relationship of DRG issues and potential impacts to revenue extensively.   By examining the grouping of your submitted claims, you can identify areas of DRG shift, and then investigate them to determine the causes of the shift.   Don’t forget that the total number of claims may drop if there are coding backlogs, so it’s probably more useful to look at percentages.

It may be helpful to examine this claims grouping both as an overall percentage of DRGs, and also as a percentage of particular DRG triads and diads, since those are likely to be easy places to spot trends where documentation and or coding might present financial issues.

Example: The Major Chest Procedure triad

Remittance data

One obvious way to identify ICD-10 related process failures and coding issues will be by analyzing rejections issued by your payers. Unfortunately, simply looking at the number of rejections presents a number of problems:

• Rejections for multiple causes will be mixed together with the same rejection reason code. Rejections do not indicate root cause.
• Patterns may exist at the payer level or across payers.
• ICD-9 and ICD-10 payments and rejections will overlap in the billing system, obscuring patterns.

Despite these issues, such an analysis has value; just make sure you do not rely on rejections as your sole source of feedback.  Apparent patterns will need to be investigated, probably by a multi-disciplinary team such as the one we proposed in our post last week on setting up an ICD-10 ICD-10 War Room. 

Many providers with reasonably modern billing systems already will have access to a capable suite of rejection analysis and reporting tools.   Some providers’ older systems lack such tools, but those providers may have access to similar tools from a clearinghouse.   Another approach to your analysis would be to load all your claims and remittances into a stand-alone database, which can be used as a source for data and pattern analysis.

Whichever way you choose to access the data, the entire set of claims and rejections received at your facility is almost certainly too large to permit you to look at every item individually.   To make the most of your limited analysis time, consider the following:

• Focus only on denials specifically related to ICD-10 diagnosis and procedure codes, e.g. “Procedure not appropriate for diagnosis.”   Demographic denials are not likely to hide significant ICD-10 problems.
• Look at patterns of denials across payers (because documentation and coding should be fairly payer-independent). Look for the same within single payers as rejections may relate to a single payer’s business rules or mapping, and including multiple payers in your query may hide these single payer issues.
• As above, a percentage of claims denied will be more useful in most cases than raw numbers, because the total number of claims may vary.
• Don’t forget to provide a clear way for your insurance collectors to refer specific items to you for further research. One example may represent a single claim, or it might be the tip of a much larger iceberg.

Finally, make sure that your organization has adequate dedicated resources to manage this analytical work. Identifying patterns and correcting them early is the most cost effective approach to speeding your return to normal revenue patterns.

Phoenix consultants have extensive experience managing and analyzing revenue cycle data, in association with billing system installs and optimizations — augmented by our ICD-10 expertise.   If you’d to discuss how we might assist you with this critical ICD-10 related revenue cycle analysis, contact us!