CMS 837i and NOE Tracker – A Process Comparison

NOETracker
CMS 837I vs. NOETracker

On July 27, 2017, CMS issued Change Request 10064 describing a new process for submitting NOEs. This system, to be introduced in January of 2018, will allow hospices to use their billing software to create special claim files in the ANSI 837i format that contain NOE information.

The MACs will then receive these files just as they do actual claims. When they arrive, they will strip out the non-NOE data and post what would normally have been keyed into the FISS system as if it had been done manually through DDE. From this point, the transaction will be processed identically regardless of which method was used to deliver it, the 837i or DDE.

CMS developed this solution with help from NAHC. It is a significant effort to provide a path for providers and their vendors to develop solutions that could reduce the financial impact of keying errors that cause a majority of the rejected NOEs and associated penalties.

The idea of this project is to create a new “front end” to the FISS system, replacing the DDE screens with an industry standard record layout that could be used to submit this data system to system, as is done with claims.

The way the data will be delivered is through the 837i. This specification has been the required standard for all hospice claims (Institutional Provider Claims) for the last twenty years. This process, if implemented as it was intended, would provide two opportunities for validating the NOE data. First, by the vendor when the 837i is created, then by CMS when the claim batch is edited and a 277CA claim status report is returned. The data entry process through DDE has no edits to verify data entered manually.

On the surface, the idea seems simple enough. However, actually implementing it will not be easy.

First, creating the 837i. This transaction is used to send claim data to health plans for payment. It is created by most providers through their patient accounting systems or EMR. For hospices, it is usually processed on a monthly basis or when patients are discharged. The data used in this transaction is normally collected and verified after admission. With the NOE, the transaction must be sent immediately, as soon as the data is ready. If it is not sent within five days of admission, the provider is subject to non-covered services.

Continue reading

Back to Work – Reconnecting with the NOE Processing Problem

Hello everyone. First, I apologize for the long break in blog activity. A year ago, I retired as president of MEDTranDirect. I am grateful for the year off and the opportunity to get some perspective on my life and lower my golf handicap. Now it is time to get back to work.

Now that I am back, I see that there has been significant progress in my absence. CMS no longer depends on ancient computer systems for processing NOEs and claim data. Provider payments and adjustments are made fairly based on logical and actionable data. Attachments can be included in claim data so they no longer have to be re-associated after the fact. All remittances are sent electronically and there is a national database for insurance eligibility verification. Just kidding….

As all of you know, I didn’t really miss much. In reviewing regulatory changes while I was gone, nothing really stands out to me that would change how home care and other providers operate their organizations. However, this article would not prove useful if we did not discuss something relevant, so I would like to talk about CMS policy changes that took effect in December of 2016 regarding the processing of NOE (Notice of Election) transactions.

These changes are described in this MLN Matters article SE1633: here.

In this article, CMS admits that when “inadvertent errors” occur in the entry of the NOE, such as “transposing numbers in the HICN or provider ID”, this is not identified in the system until days later when the transaction is finally processed and classified as RTP (Returned to Provider).

This often, almost always, means that the opportunity to submit a valid NOE within the required five day window is lost.

To address this issue, instead of correcting errors in the DDE system, CMS has created a new procedure for hospices to work around these errors and document them when they occur. Like the original NOE transaction issues, the burden is on the hospice to identify the problem, enter a corrected NOE within two business days of the RTP, and document the issue through the remarks section of the first claim for the patient. If the condition that created the invalid NOE was due to a data entry error that should have been detectable by any adequate computer program, then the burden is on the hospice to prove this fact through this process. If the documentation is deemed accurate and complete after review by the MAC, they can reverse the unbilled days penalty for this claim for this reason.

This document from PGBA describes your options for dealing with each error that could occur during the entry of the NOE and if it falls within these guidelines for 2 day resubmission: read more.

These errors include every single data element keyed in the NOE. In my opinion, the significant aspect of these policy changes is that CMS is finally admitting that their own processing delays and inefficient systems are responsible for a large part of the problems associated with late NOE unbilled days and the labor intensive procedures surrounding the processing of this transaction. Unfortunately, their solution is to expand the procedures dealing with monitoring, correcting and resubmitting these errors instead of preventing them in the first place.

Although this policy change grants some relief financially, it increases the burden on hospices to execute and monitor these NOE transactions by adding new steps to the process that not only delay the processing of NOE’s, but also the first claims submitted for these patients.

If you ever tire of this process as a hospice agency, please check out our NOE Tracker which prevents NOE entry errors and monitors their progress.

Notice of Election Tracker

By Kalon Mitchell – President, MEDTranDirect

Improving the Processing of NOEs and NOTRs for Hospices

As a vendor of eligibility processing services and a NSV (Network Service Vendor) for the Medicare HETS eligibility system, we have a vested interest in the capability of these systems to provide current and valid information. Through the HIPAA transaction for eligibility data (ANSI 270/271), we send requests to these systems for eligibility data for specific patients. Through a real time response, we can provide detailed information about the current status of this patient with the selected payer. This process involves converting the data returned by the payer into a report or entering it into a database.  In this process, we are the “messenger”. The content we provide is completely dependent on the quality of the payer response.

In some cases, these responses can be incomplete or inaccurate.  When this happens, we often get support incidents where providers complain that we are providing incorrect data. Most of the time, they are technically correct, but the issues they present as problems are beyond the ability of these payer systems to accommodate given the way this data is collected.

NOES and NOTRS Continue reading