Addressing the Confusion Related to CMS’s Encounter Data Mandate
Whether it is the various industry calls, conferences or even CMS’s own meetings, the question about what to do with paper claims keeps coming up. This is a short look at the issue including background, unknowns and an attempt to surmise what is most likely to happen.
Background
CMS has decided to replace the current method of reporting risk adjustment information called RAPS with a new process called the Encounter Data Processing System (EDPS). This process requires plans to submit EDI transactions that contain much more information about members, providers, dates of service, diagnosis, treatments and amounts. The EDPS mandate also requires every encounter to be submitted, even if denied. When compared to the 7 or so fields required under RAPS, EDPS means that plans have to submit somewhere around 500 times as much data as they did before.
Many MAOs are frustrated with various areas of the effort from slipping deadlines to changing requirements, but this article will focus on unique problems associated with paper claims.
EDPS calls for data post adjudication
Perhaps this is the most important thing to remember when trying to figure out any problem relating to the paper claims issue. The data that CMS has asked for is not simply a forwarded copy of whatever the provider submitted to the MAO. Instead, CMS is asking for not only the “claim” data, but also the results of the claim through the adjudication process. One simple way to look at the EDPS requirements is as a combination of the originally submitted claim combined with the explanation of benefits / payments. CMS wants to see what lines were accepted, for how much, as well as what lines were denied. Even in a best case, the claim – paper or electronic – only tells half the story.
Paper claims typically get into the claims system in one of two ways:
- Paper Claims are entered directly into the system.
- Paper claims are scanned, OCRed and typically converted to EDI.
The “paper” EDI is injected into the same EDI stream or a parallel EDI stream to be processed in much the same way as any other inbound electronic claim. Either way, the claims are paid using the same system and rules after the data is entered. This means that to comply with CMS’s Encounter Data Mandate, the data for the outbound file should be pulled from a common pool (usually the plan’s claims system), regardless of submission type. When paper claims are done being processed (paid or denied) they are hard to distinguish from claims that were entered electronically. As such we need to ask ourselves what is so different about a paper claim? To do this we should look at three things:
- Identify what data cannot be put on a paper claim form
- Examine what data can be put on a form but generally is NOT by the submitter
- Find out if any information is present on the paper claim, but not entered into the system for any reason.
After looking at these three areas, we can see what situations a valid 5010 which will comply with the CMS requirements can NOT be created from a claim that originally came in on paper. For area one, it usually turns out that the paper claim has the ability to contain all the information needed. Most of the cases where there are deltas reflect the fact that the paper claims can make a valid but DATA POOR transaction when submitted. For example, there are only 4 spaces available for diagnosis codes. This is an example of a limitation of the paper form when conducting business with a MAO plan, but certainly there is no requirement that there has to be MORE than 4 codes when submitting 5010. While all the data needed by CMS is not available on the form to make a valid transaction, most of that can be added such as the submitter and receiver information. One good example of data that really doesn’t have a place on a professional claim is a Coordination of Benefits (COB) claim.
As it turns out, areas 2 and 3 are where the real problems come up. To make a valid submission, plans need to submit NPI numbers for billing and rendering providers. If p
roviders are not accustomed to providing things like NPI over the years, they may not give it to the plan. In this case, the data CAN be put on the form, but the MAO has never complained about it not being there and so it is skipped. In very much the same way, even when data is put on the form, it might not be entered. On the UB-04, there is actually a place to note an ambulance pick up and drop off location for institutional claims. This field is rarely if ever filled out on an ambulance claim, but even if it were, there may be no place to put that data in the claim system. If the plan doesn’t require it of the ambulance company to get payment and the data is not tracked, it simply won’t be keyed in.
Enforcement of missing data on a paper claim is much tougher than with electronic claims. With an EDI claim, rules can be put in to reject the claim at the EDI gateway. Paper claims are already in the door and rejecting it for something like a missing NPI is most likely more work than simply looking it up. NPI can many times be populated with internal provider tables already integrated into the claims process. If claims tables still don’t have the data, integrating an NPI look up from the NPPES database would certainly help.
Most of the required data for EDPS would be required by the claim system to begin with – paper or EDI. For example, EDPS requires treatment codes where RAPS did not. This has no impact though since every claim system on the planet requires treatment codes anyway at this point. The areas that are required under EDPS that are often not available on the paper claim (for any of the three reasons listed) happen to be areas that are not required or provided in the EDI file. This means that the problems from paper claims may not be unique to paper claims. Instead they are issues with the EDPS requirements as a whole.
Could CMS Offer Eased Requirements for Paper Claims if They Wanted To?
While anything is possible, it is highly unlikely. First off, CMS vastly underestimates the amount of paper being submitted to plans today. Medicare FFS sees very little if any paper and so they can’t seem to imagine why would it be any different at a commercial plan. As such, the fix to them is less important than all the other areas that are making noise in Encounter Data Processing. Second, if we assumed that CMS was interested in doing something about paper claims, the issue is that there isn’t really a reliable way for CMS to know the claim was originally paper in the first place. This is due to:
- CMS EDPS / EDI 837 v5010 does not have a paper claims indicator
- Even if there were an indicator, most plans claims systems would not be able to populate it reliably
If these two issues were ever worked out though, the resulting requirements should be a very reasonable bar to hit. Paper claims contain all the fields to report risk, show utilization and price the claims – the stated goals of collecting encounter data in the first place. If paper claim data requirements are ever defined by CMS, treating them as defacto standards for other data types would likely yield a comprehensive, reasonable set of requirements for EDPS as a whole instead of the reach that many requirements are.
What should plans do?
In almost every case, claims that were submitted on paper to the MAO can be turned into a valid, submittable EDPS transaction for CMS. At worst, these transactions may be “data poor” due to less ability to submit diagnosis codes, however that would be true of both RAPS and EDPS. The claims that are truly unsubmittable to CMS due to a missing data element such as COB data or Ambulance Pick Up address are very likely also problems for the native EDI claims as well.
Perhaps instead of trying to work out every possible scenario where a paper claim would present a problem, plans should push back at CMS on the requirements that don’t directly relate to the purpose of EDPS.
Paper_Inbox 