Risk Adjustment Deletes Are Hard

Risk Adjustment Deletes Are Hard

 

08eaftvA lot of questions are being asked about Medicare Advantage and Risk Adjustment lately, very likely due to the news on UnitedHealth  and alleged over-billing.  While there are great conversations to be had about the proper nature of comprehensive chart reviews and best practices surrounding them, there has also been a renewed focus on  the current state of the Encounter Data Processing System (EDPS) and the difficulties involved with deleting diagnosis codes.

The process is ugly due to a very complicated submission process, difficulties in identifying what should and shouldn’t be deleted as well as the chaotic matching process health plans have to go through to mirror deletes from RAPS and EDPS submissions.

A delete by any other name. . .

A CMS delete isn’t really a delete per se.  It is removing a code that is correct from consideration for risk adjustment.  One might say, “well hold on, isn’t CMS in charge of determining what is risk adjustable in the EDPS process?”  You’d be right, except for the fact that CMS will still penalize the plan if a code is accepted by THEM that shouldn’t have been.  How would this happen – a million different ways, but consider:

  • Member has a sniffle and goes to the doctor.
  • Plan gets claim for an office visit and a full health evaluation is done.
  • In addition to diagnosing the cold, one of the diagnosis submitted is “Acute Myocardial Infarction” because the member had a stroke two years ago.  This coding mistake should have been the code for “history of AMI” instead.
  • Plan’s claims process pays the claim because office visits can be paid for just about any diagnosis and a valid one is there for the cold.  Even if the plan asks the doctor to correct and resubmit, it is unlikely to happen (super busy, already paid, resubmission rejected for duplicate etc.).
  • CMS accepts the code through the EDPS system even though the plan had a filter in place to make sure it was not submitted through the RAPS process.  EDPS does not allow the plan to “edit” the submission or filter results.
  • The submitted code then needs to be deleted from EDPS (but not until after it was submitted  and accepted).

So basically, plans are responsible even though CMS is determining what is risk adjustable in the EDPS process.

How Did We Get Here?

Many health plans and vendors took a “store and forward” approach to implementing Encounter Data submissions.  Basically, the store and forward approach takes data from a source system (e.g. claims) and forwards the formatted message to CMS.  This might be fine if there were no other encounter sources (like charts, supplemental data, etc.) and no other submission methods.  However, the plans are also getting data into their RAPS process and sending RAPS submissions to CMS.  The majority of the plans kept their legacy RAPS process in place as a separate system assuming it was going away as CMS claimed.  The extract used in the RAPS process only asked for the data it needed from the source system.  This leads to two very different data stores doing a similar job.

There are a lot of problems that will manifest if two separate systems for submitting risk data to CMS are used long term.  They include having to correct problems in data twice (a missing NPI in one encounter now must be addressed twice – likely be separate teams), differences when data makes it to one system and not another (charts didn’t make it into the EDPS data store, but are in the RAPS data store) and general differences due to the content of the data (limited data set in RAPS vs. rich data set in EDPS).  While we could spend a lot of time on each of those areas and others, the challenges related to ensuring the exact same risk data is reflected in both submissions to CMS is one of the most complicated and the worst of it might be the delete process.

Technical Hurdles

rvboklrFor the purpose of this discussion, we’ll put aside the fact that CMS took an overly complicated and non-standard approach to submitting deletes via EDI.  However, the store and forward approach makes things a lot harder even if you know exactly what to delete.  The store and forward approach in a nutshell is get stuff (encounter data), and forward that stuff on once it is formatted as a message to CMS.  Following this flow, what “stuff” is the system to “get” so that it is to be forwarded as a message letting CMS know it should delete that code?  A new process needs to be created to look through existing submissions for things to delete.  This process is needs to do complex matching and status queries to even have a chance to send a delete.  But even if all that can be pulled off, what should be deleted?

Risk Adjustment Delete Sources (EDPS)

There are many sources of deletes and each of them is difficult to perform for the reasons above as well as unique challenges for each source.  Here are a few but not all sources to consider:

Mirror your RAPS deletes – seems like the most obvious one. If a plan saw fit to delete a code from their RAPS submission for whatever reason, it should also be deleted in the EDPS data.  Tough to do in practice.

If I were to hand a store and forward system the RAPS deletes, it would have no idea what to do with it.  The Diagnosis Cluster from RAPS does not equal the encounter from EDPS.  So just the process of finding these things involves complicated queries.  It is not like there is a claim number in the RAPS data.  Plus, if you miss even one, it is just as bad as missing ten in most cases.  When are you done?  Not sure because one RAPS delete might be many EDPS submissions that need to have deletes resent.

Delete all codes that were filtered out by RAPS and never sent. How far should a plan go with this is a tough question.  In theory, CMS’s risk filter should have a heavy overlap with a plan’s own filter so there is no need to delete all codes that CMS is not using for risk adjustment.  Then again, CMS has had a lot of problems with processing encounters and returning MAO-004 reports showing what is risk adjustable.  Plans certainly shouldn’t rely on CMS being able to follow their own process.

Ongoing loop back to check for corrected submissions needing deletions. There are a LOT more errors and rejections introduced by the switch to EDPS compared to RAPS.  It is not unheard of for health plans to have error queues containing 100k errors.  The good news is that plans are addressing these errors.  The bad news is that the potential to introduce previously deleted codes is now a real problem.

RAF Score comparison differences MAO-004 results vs. RAPS results scores. Even after doing all that work, doubling back to the risk scores will yield differences.  Comparing the calculated Risk Adjustment Factor (RAF) score from one submission process to the other will uncover differences.  This is a difficult place to operate however due to the unreasonable lag time between submission of EDPS data to CMS and the return of the MAO-004.

Day-forward deletes. When plans consolidate to a single data store for both submission types, any filters, delete code logic or chart review data that are present should be reflected on an ongoing basis in the outbound data.  It simply takes the appropriate action based on submission source.  RAPS filter says don’t send?  EDPS should mark the code for subsequent delete after submission automatically (especially if the MAO-004 comes back as risk adjustable) without all the matching and running around it takes to track these down after the fact.

The worst news?

Yes, deleting diagnosis from encounter data for Medicare Advantage plans is time consuming, complicated and error prone . . . it is also mandatory.  Due to the issues above, many insurers are putting themselves at risk right when the government has renewed their focus on MAOs  alleged over-reporting of risk.

Need more help or want to discuss this further?  Drop me a note.  I’d love to talk about your specific experiences, insights or challenges.