We’ve been taking a look at some of the ways RREs can attempt to achieve full CMS compliance and avoid potential penalties that may be coming soon. One area to consider more closely is file thresholds. Upon submission of a Claim Input File, before processing, CMS performs numerous file-level threshold checks. Two of the most common triggers that can lead to further CMS review are the 20% error and 5% delete thresholds.
Scenario 1: 20% or more of records failed record level edits
Claim files submitted are subject to CMS’ careful review. If CMS determines that more than 20% of a Claim Input File’s Claim Detail Records will generate errors, the agency will place the file on hold and email a notification to the RRE’s Account Manager.[1] That notification will contain a list of the different error types identified within the RRE’s file. The RRE will then be required to follow up with their assigned EDI Representative at the BCRC.
If the RRE is able to sufficiently identify the issues with their file, they may ask their EDI Representative to delete the submission so they may make corrections and resubmit. However, more often than not, an RRE will require a response file to appropriately identify all of the problem records within their file. If that’s the case, the EDI Representative will release the file for processing upon request. The exception to that rule would be a situation in which every, or nearly every, record in the file triggers an error. If the BCRC is able to sufficiently explain the issues that require attention, then the RRE can make appropriate corrections without a response file. In that case, the EDI Representative may delete the file and provide instructions for how the RRE can correct and resubmit it.
Scenario 2: 5% or more of records are delete transactions
If more than 5% of the Claim Detail Records within a Claim Input File consist of delete transactions, CMS will also place the RRE’s file on hold.[2] As in the 20% threshold error case, an email notification will be sent to the RRE’s Account Manager, and the RRE will be required to reach out to the assigned EDI Representative. CMS monitors delete transactions very closely. When the 5% delete threshold is triggered, the RRE is required to provide a high-level explanation of these delete transactions before the file is allowed to be processed.
The submission of a delete transaction is only considered appropriate in two scenarios. The first is when the claim in question is deleted because its initial submission was entirely erroneous. For example, ORM coverage or a TPOC was reported when the RRE did not actually assume ORM or no TPOC event occurred. The other is a situation in which one of the data elements that CMS considers a key field (CMS Date of Incident, Plan Insurance Type, ORM Indicator) must be corrected. In this case, the delete transaction must be coupled with an add transaction for a new Claim Detail Record with the corrected key field(s). If the RRE can provide one or a combination of both of these reasons to the assigned EDI Representative, the file should be released for processing. If not, the EDI Representative may delete the RRE’s file and instruct them to make corrections and resubmit.
Significance of file level thresholds in terms of compliance
Both of the aforementioned file-level thresholds may often point to issues with the accuracy and validity of an RRE’s data. While occasional triggering of these file-level thresholds is not problematic, frequent or repeated triggering of these same threshold errors raises significant red flags. RREs should aim for a level of data quality that ensures that these threshold errors do not become a persistent problem. Those RREs that consistently trigger such file-level thresholds expose themselves to increased scrutiny—and will likely be among those most at risk of being assessed civil money penalties.
Conclusion
RREs clearly need to be concerned about error thresholds. This trigger is just another example of how Section 111 reporting is technical, complex, and full of possible pitfalls. Given that there is potential for fines related to non-compliance and that CMS is going to focus on possibly levying penalties, it’s vital for RREs to ensure that their reporting house is in order.
[1] “The BCRC has in place certain threshold checks that will suspend files from processing temporarily until an EDI Representative investigates the situation with the RRE, and makes a determination to reject the file or allow it to process normally… The threshold restrictions are in place to catch files that are suspected to be erroneous before the BCRC completes processing and updates Medicare’s databases. These threshold checks include looking for a file that has an unusually larger number of deletes, a large number of records in error, or the submission of more than one required file per quarter.” See Sec. 111 COB Secure Website (COBSW) User Guide, Version 9.2. Ch. 14, sec. 14.3.
[2] See Sec. 111 COB Secure Website (COBSW) User Guide, Version 9.2. Ch. 14, sec. 14.3.
