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