Getting to Know Your Encounter Data Submission Responses

As a thought experiment, let’s track a hypothetical electronic data interchange (EDI) file through submission to the Centers for Medicare & Medicaid Services (CMS). As of this writing, there are still two parallel systems involved in the processing of files. The two systems are the Encounter Data System (EDS) and Risk Adjustment Suite of Systems (RASS, which is more commonly referred to with the catch-all RAPS).

Notably, RAPS and its corresponding systems require a less complicated file type than EDS. Though the information comes from the same source, the formatting and editing responses are different, with EDS responses clearly calling for more detail and involvement in reconciliation. EDS responses are largely what we will focus on and account for in this post.

999 Acknowledgement Reports

Your 5,000 encounter data records are neatly organized into a single file and are on their way through the various processing systems. For the initial review process, the file will be evaluated by the Encounter Data Front-End System (EDFES). An initial 999 report is returned from CMS. Any syntactical errors are populated in this response. When explaining the review and editing process, CMS’s Encounter Data Submission and Processing Guide reads, “a single edit can result in the rejection of more than one record.”

When a functional group of data receives a rejection in this stage, all of the data enveloped within that functional group gets the capital-R rejected response in your 999 report. The rejection applies to your transaction set as well. This sort of rejection can vary in its impact. If a functional group includes several transaction sets, then only the transaction sets with errors will be rejected.

However, many Medicare Advantage Organizations (MAOs) will submit the full 5,000 claims within a single transaction set. Because a single error within the transaction set causes the whole set to be rejected, a simple element error within the transaction set (e.g. not populating the Patient Gender in the form) will cause a complete rejection of the file.

At this point, there is bad news. Despite populating the 837 file diligently, all of the claims in the file were contained within a single transaction set, which contains syntactical errors. This causes your entire file and all 5,000 claims to be rejected. Within those claims, there are diagnoses that can be estimated to result in the capture of around 1,000 Hierarchical Condition Categories (HCCs). The errors will need to be identified and reconciled before resubmission. You will lose time, but by making the necessary changes, ultimately, the file can be submitted and accepted at the 999 level.

CCEM and the 277CA Report

Once the corrections at the 999 level have been made and the file is resubmitted, it moves forward. The next stage includes the Combined Common Edits Module (CCEM) where transaction set edits are made. Shortly after submission, you receive a 277CA Acknowledgment Report. The 277CA provides the status of each Encounter Data Record (EDR) or Chart Review Record (CRR) as either accepted or rejected due to CCEM edits. In the report, you still have a majority of claims being accepted, but there are rejections, notably error code A7:189 with the description “Facility admission date.”

The facility admission date error is most often associated with inpatient claims that are missing an admission date from the final 837 file, possibly due to the logic used to generate and format the file. When reconciling these, you can try to identify underlying trends as well. If it is an issue of logic, there could be signs like certain institutional claims showing the admission date, but not ER admissions. The implication here could be that whatever system being used to generate the 837 doesn’t require an admission date when populating fields for an ER encounter. It may be an easy enough reconciliation, but it’s obviously best to trace the errors back to their source to correct systemic causes, as these issues can lead to other errors you are commonly receiving.

This particular error proves to be pervasive in the logic underlying your file population. Because of it, 1,000 claims within the file are rejected. Of the original 5,000 claims that completed the file, 4,000 accepted claims are moving forward into the back-end edits of EDPS. However, due to the loss of those claims, we will estimate that diagnoses leading to the capture of 120 HCCs will go unreported and reimbursement will be impacted from the loss.

MAO-001 and MAO-002

The home stretch has been reached. The Encounter Data Processing System is now reviewing your file. The first thing identified within that review is whether or not the file contains duplicate encounter data. There are many reasons a duplicate record could be identified (i.e. Member ID, date of service, procedure code, provider ID, etc.), but fortunately for your organization, the claims were reviewed to make sure no duplicates were submitted, so you do not receive the MAO-001 report.

The second report generated is the aptly named, MAO-002. In this subsequent report from the back-end system, your file receives an error code MA02256 with the description “Beneficiary Not Part C Eligible for DOS.” The error is caused by the “from” and “to” dates not falling within the active enrollment dates for the members represented in the claims. There are a total of 400 claims that fail as a result. The claims had around 80 diagnoses mapping to an HCC that are lost with the rejections. By this point, your file still contains 3,600 accepted claims with hundreds of diagnoses that will map to a corresponding HCC. Conversely, with the claims lost at the 277 level added to these new rejections, around 200 HCCs will go unrecorded until reconciliation occurs.

The MA02256 error can be a sign of an enrollment issue. When reconciling, check if CMS does not recognize that the member was enrolled in your plan, or if this is a problem of paying a claim when the member was not enrolled with your plan. By identifying the sources and making corrections, your files will lead to more accurate data capture for CMS and a more accurate reimbursement for your plan.

Reimbursement from record submission is connected to the topic of unlinked chart review records. If a chart review is the sole source of a diagnosis, it will prove to be a red flag after submission. CRRs have been under scrutiny by both CMS and the Office of the Inspector General, with CMS stating clearly, “a CRR should not be the only record with information about a healthcare item or service provided to a plan enrollee.” The objective of focusing on these unlinked CRRs is to rout out fraud, waste, and abuse. Though unlinked CRRs are technically allowed, they are not advisable due to the association with data submission solely for reimbursement.

The usefulness of a CRR is dependent on the need. If capture is taking place cleanly at the source and being recorded accurately before final submission, chart reviews of huge amounts of claims won’t be as necessary and your organization will save money on conducting them. Taking guidance from CMS’s responses will help build a strategy of better data capture at the source by informing you of the systemic issues contributing to the failure of claims at various levels. Reconciliation of errors will contribute to better coordination of care for members and improvement in revenue cycle management for your organization.

For overburdened payers and providers, Episource helps close gaps in healthcare by marrying expert guidance with an end-to-end risk adjustment platform. Learn more about Episource Analyst and other solutions at Episource.com.