Avoiding Penalty Problems by Ensuring Data Accuracy

With CMS (Centers for Medicare and Medicaid Services) penalties on the horizon, we’ve been exploring how RREs (Responsible Reporting Entities) can be proactive in avoiding fines. We covered timely reporting in our previous post; now we’ll focus on the importance of submitting accurate data to CMS. A variety of errors  can occur when incorrect information is submitted, and we’ll review some of the most common errors and occurrences.

Using specific, valid ICD codes to avoid errors

ICD (International Classification of Diseases) code errors are among the most prevalent issues encountered by RREs. It’s critical that RREs report valid ICD codes that are as specific as possible for CMS to appropriately determine if an RRE is responsible for particular medical claims. Lack of specificity in ICD reporting may also lead to claim denial issues for the associated Medicare beneficiary.

Every reportable claim must have, at minimum, one valid ICD code; however, up to 19 codes may be reported on each claim.[i] RREs are expected to report codes for all injuries or ailments for which the RRE is responsible. That said, RREs should take care to avoid sending any ancillary codes not directly related to the incident at hand. Even though an ICD code may be included in an explanation of benefits (EOB) for a date of service linked to the reported incident, it doesn’t necessarily mean that the code is directly linked to that incident. For example, an individual with hypertension may receive treatment for a broken arm after an auto accident.  The EOB for that date of service may include an ICD code related to hypertension even though the condition is not directly related to the injury sustained in the auto accident. For this reason, the hypertension code should not be reported via Section 111.

It’s important to remember that if the CMS date of incident is before October 1, 2015, the code reported may be either ICD-9 or ICD-10. However, if the CMS date of incident is October 1, 2015 or later, only ICD-10 codes will be accepted.i

If a claim is reported without at least one valid ICD code, CMS will return and error. Without the ICD code 1 field populated, the RRE will receive at least a CI05 error on its response file. Other CI errors will also be triggered when invalid codes are reported in the subsequent ICD code fields 2–19. When claims receive these errors— and they’re not corrected on subsequent submissions— the RRE may be at risk of noncompliance. Repeated submission of the same claims with invalid or missing ICD code values may receive the highest scrutiny due to increased visibility. That’s why correcting all ICD- related errors and then resubmitting the claims is imperative to remain in compliance.

Avoiding thorny TIN Reference File errors

Errors related to a TIN (Taxpayer Identification Number) or TIN Reference File will trigger TN99 errors. While these are common, they can be difficult to remediate because these codes may be triggered in many ways. TIN Detail Records, submitted via the TIN Reference File, are subject to review for completeness of information, syntax errors, and both TIN and address validation. Deficiencies in any will result in TN errors being returned on the TIN Reference Response File. The specific error code returned should reference the element of the TIN Detail Record that’s causing the problem. In turn, any Claim Detail Record, within a Claim Input File, that cross-references any TIN Reference File Detail Record that generated an error will receive a TN99 error on the Claim Response File. Furthermore, TN99 errors may be triggered if the TIN or TIN Office Code/Site ID are not appropriately populated within the Claim Input File Detail Record. Be aware that you’ll also be in error if the TIN Office Code/Site ID fields on the Claim Input File do not appropriately cross-reference corresponding values previously reported within a TIN Reference File. Data entry accuracy is vital from the start to avoid these problems.

Don’t forget to populate the ORM indicator

CJ01 errors are also quite prevalent. However, this is a relatively straightforward error that should be easy to avoid. All Claim Detail Records must contain a valid ORM (Ongoing Responsibility for Medicals) indicator of either “Y” to indicate ORM or “N” to indicate no ORM. If this field is left unpopulated or is populated with any other value, it will be rejected. Also, it’s important to note that the ORM indicator does not function as an “on/off switch” for ORM. In other words, if an RRE assumes ORM on a claim, the ORM indicator must be reported with a value of “Y” and that value should remain as “Y” even after ORM terminates. When ORM terminates, an ORM termination date must simply be submitted as an update transaction, or if ORM has already terminated by the time of the initial report, the ORM termination date should be populated within the original add transaction. 

Watch those ORM termination dates

CJ06 errors are generated when an RRE submits an ORM termination date that’s greater than six months after the submission date of the file. Although state statutory provisions and insurance policy guidelines may dictate that ORM will terminate after a certain period of time, an RRE may not simply plug in that statutory date from inception of the claim’s reporting.

RREs are expected to continue to monitor their claims through ORM termination in the event that any changes occur that may affect the statutory termination date. ORM could obviously terminate before that point in time if a monetary cap is reached and benefits are exhausted. Alternatively, it may be possible, under certain circumstances, for ORM to continue past an initially anticipated statutory termination date. 

While continuous monitoring of ORM status on all clams may be burdensome, this is a very straight forward error that’s quite avoidable. In some cases, where an open-ended ORM record is initially accepted and a subsequent update is rejected with a CJ06 error due to a future ORM termination date, CMS would actually have appropriate and accurate ORM coverage on file despite that error. This is less problematic. However, if a future ORM termination date is included within an initial add transaction and a CJ06 error is generated, that will prevent CMS from appropriate acceptance of the required data and would certainly be a compliance concern. 

Complete and careful input will help avoid penalties

Avoiding CMS errors and subsequent penalties will require RREs to step up their vigilance in how they record claim information. While some mistakes are easily avoided, such as ORM indicators, others will require greater scrutiny of the claim to ensure that the right injury codes are attributed to the incident. With careful oversight, RREs can ensure their claims are compliant and steer clear of CMS trouble. For guidance on CMS compliance issues, feel free to reach out to us at ISO Claims Partners.

By Shawn Deane and Jeremy Farquhar

Courtesy of ISO Claims Partners Blog

Share This Article: