MEDTranDirect Takes on Late NOEs with the New NOE Tracker

Since October of 2014, timely filing of NOE/NOTRs (Notice of Election/Notice of Termination-Revocation) has been a leading issue for the hospice industry.  As a software company that works on Medicare electronic transaction processing, when these regulations were announced, they caught our attention as a possible opportunity for a new product that might resolve some of the issues that CMS and the hospice industry dealt with regarding the efficiency of these transactions.

Notice of Election Tracker

One of the most difficult tasks you deal with regarding developing new software solutions is understanding the actual issues involved with a process and what the problems really are for the entities involved.  When these regulations were announced, it was clear that CMS felt that it was important to get these transactions submitted within five days.  This told us two things.   First, they were not being processed within this window a substantial portion of the time and second, that this delay presented problems for CMS and the industry.

To learn more, we began by researching the steps involved with processing NOE/NOTR in the current hospice environment.  We discovered that the NOE/NOTR could only be entered through DDE (Direct Data Entry), a 1980’s mainframe computer environment designed to replace the submission of paper claims to Medicare thirty years ago.  In its day, it was a major advancement in the technology used for Medicare revenue cycle processing.  Today, it is an example of archaic technology used to inefficiently process billions of dollars in healthcare revenue, and it is not going well for anyone involved.

Our initial assumption was that the delay in the entry of NOEs must be due to the difficulty of hospices in obtaining the information necessary to enter the transaction within this time frame.  We thought the answer would be to create a system that when informed of these transactions, could monitor their status in the CWF (Common Working File) until they were paid or rejected.  This would allow users to quickly resubmit the NOE/NOTR if they were rejected and would reduce the penalty days by providing faster and more accurate feedback than could be provided by DDE itself.

We interviewed our hospice customers and recorded the process of collecting data, entering it in DDE, and the follow up and processing of the penalties and appeals associated with the NOE.  We found that our initial assumptions about the process were invalid.  Hospices rarely have issues collecting the necessary data for the NOE/NOTR within the five day window.  The problem was with the DDE system itself.

DDE provides access for a healthcare provider, or their agent, through a remote computer terminal to the IBM computer system that allows for the entry of claim data referred to as FISS (Fiscal Intermediary Standard System).  This system was designed to collect claim data, individually, through data entry screens, before the industry developed the technology to send these claims in batches as ANSI 837 claim files over fifteen years ago as part of HIPAA.

Today, hospices use the HIPAA 837 process to submit all the monthly claims adjudicated by Medicare.  This system provides the healthcare provider, through software developed by CMS, MEDTranDirect and our competitors, with the technology to process these claims each day.  Additionally, the process provides immediate feedback regarding the acceptance of these batches and the individual claims they contain.  Through this feedback, providers can correct and resubmit claims every day, even multiple times a day, if they choose to.

These systems are designed to support the ANSI 837 claim file specifications that are a mandated HIPAA industry standard for insurance claims.  Unfortunately, they do not support the processing of NOEs and NOTRs because these transactions contain only a subset of the required data for this standard format.  When the industry began using the 837 process instead of DDE for regular claims processing, these NOE/NOTR transactions were left behind to fend for themselves in FISS.  At some point, the FISS system was altered to accept the limited data entered for the NOE and NOTR and process them as they would claims.  This was the beginning of the problem.

Like the 837 environment, the FISS system initially had problems processing these NOE transactions because they contained limited data that caused them to be rejected as claims.  To solve this problem, they altered their standard claims processing rules in FISS to bypass edits and validation normally applied to all entered claims.  Basically, they eliminated all these edits for the NOE/NOTR.

When the NOE/NOTR is entered through DDE, nothing is immediately validated.  You can enter one without a valid ICD10 code, a valid physician or even a valid patient.  When it is through, a message is displayed that says “record created”, whether it happens or not, and sometimes it doesn’t.  This is bad enough, but the real bad news is that the batch system used to process these transactions each night, unlike regular claims, does not process each NOE/NOTR the night it was entered, but many days later.  Only then, providing feedback regarding the quality of the data initially entered and if the transaction was accepted.

We discovered this about a year ago when we were researching problems with the transition of this NOE data to the Medicare HETS eligibility system from the CWF for another MEDTranDirect product.  We did a study on NOEs entered in DDE and when the data was available in future eligibility inquiries through HETS.  We found significant delays in the transfer of the data.  Initially, we thought this was caused by problems in the transfer of this data from the CWF to HETS.  However, during our research, we fortunately recorded both when the NOE was entered in DDE and when it showed as “Paid” or finalized in DDE or RTP (Returned to Provider) due to an error.  What we found was staggering.

No NOEs were processed the day they were submitted.   Over 50% of all NOEs entered were not even processed within the five day window that CMS demanded of the hospice providers.  We had many examples of NOEs processed as Paid or RTP over twenty days after entry.  There was no apparent logic regarding a link between this delay and the content of the NOE or which MAC (Medicare Administrative Contractor) was processing it.

Initially, we questioned our data and looked for some explanation.  While searching on the internet last fall, we discovered a survey conducted by two hospice associations, NAHC and NHPCO, that was intended to gather data on the growing problem of late fees associated with these transactions.  This survey included data collected from about 400 hospices that documented the actual impact of these regulations on the hospice industry for the first time.  This study included data that confirmed our data regarding the delay in NOE/NOTR transactions in the FISS system.   In addition, it included data on actual penalties reported by hospices related to these transactions when they were processed outside of the five day window.  The survey data can be obtained through these organizations, but here are some conclusions from this data relevant to this issue:

  • The hospices responding to the survey reported an average of 37 unbilled patient days per month due to late NOEs.
  • Using the current base daily rate for 2016 for the first 60 days of service ($186.84), this comes to an average of $6945 per month.
  • If spread the cost out to all admissions, regardless of NOE status, this comes to $89.61 per admission.
  • If you apply this expense to all hospices, this projects to $508,374,000 for the industry for 2016, assuming 6100 current hospices.

CMS has acknowledged this processing delay and their response is that the five day window is not calculated based on the date the NOE is processed, but when it is entered in the DDE system.  This is correct.  As long as you enter the transaction within five days of the admission of the patient, you have met the criteria for submission within the window and no penalty will be assessed.  But here is the catch, if the NOE is rejected, the penalty is the number of days from the original admission date until the corrected NOE is entered.  

This means that for NOEs that are rejected, the inherent DDE processing delay exaggerates the penalties paid by the hospice for reasons beyond their control.  Even the corrected NOE can be subsequently rejected and continue to add 100% of the billed revenue from admission to the new submission date as unbilled revenue for the hospice.  We have documented examples where penalties have been assessed for months of billed days for a specific patient.  In many of these cases, the provider has had only one opportunity to correct the transaction during this time frame.  

This survey data clearly pointed out the true issue with the process.  The problem was not the collection of data needed to enter the NOE within five days of admission.  It is not even really related to the delay of the processing of the NOE in DDE.  The problem is that the data can be incorrectly entered.  If we could make sure that the data was correct the first time it was submitted, the problem would be solved.  Even if the transaction was delayed in DDE processing, we would know that it would ultimately be accepted by FISS and no penalty would be assessed by the provider.

So, the challenge was to make sure the NOE was not entered incorrectly to begin with.  Since we could not depend on the FISS system to validate the data, we developed a the ability to provide modern real time validation logic on the data as it is entered through a web-based user interface.  Any problems with the data are corrected before we allow the transaction to be submitted to FISS.  This includes all the data entered in the NOE like the ICD10 code and physician data. Even patient data is validated against the CWF to make sure the NOE transaction content is clean and will be considered valid when it is ultimately processed.

Next, since any human being can make mistakes, we made our servers responsible for the entry of this record in the FISS system.  Our research showed that many rejected NOEs contained simple keying errors that would have been prevented by even the most basic claims processing applications purchased by hospice providers.  We also found that by validating this data and using the CWF, we could reduce data entry to less than half of what is entered manually in DDE.

While researching the issues involved with NOE/NOTR penalties, we found that many problems were directly related to provider training and understanding how these transactions were entered in DDE and the data requirements.  We found that many errors were created by staff replacing experienced personnel who were sick, on vacation, or who had left the organization.  To these people, the “green screen” environment was foreign and intimidating.  Even worse, the FISS system is supported by the MACs who are more interested in complying with their CMS responsibilities than providing quality customer support and satisfaction.

As we refined the product during development, we added other features absent in the DDE process.  Each pending NOE is checked automatically each night to see if and when the status is changed.  Any NOE subject to RTP is immediately reported to the provider when they log in to the application and by email.  There is no way for a rejected NOE to slip through the cracks.  In addition, we maintain a history and log of each NOE where detailed records are kept of who entered and edited the information, when it was submitted and when the status changed through our automated process.  Each NOE processed in FISS through our product is verified real time after entry to make sure that the record was actually created and is present in the CWF.

Finally, by creating a new web-based product that could “hide” DDE from hospice staff, we created a product that was easier to learn and use than the FISS system and supported by a company with 30 years’ experience in healthcare software support.  

The product is called “NOE Tracker”.  NOE Tracker has now processed hundreds of NOEs successfully through our beta sites and is now ready to take on this issue for your hospice.  If you want to avoid the penalties that your organization pays related to late NOEs and you want to try a product that provides a modern user interface and automated transaction monitoring for NOEs, contact MEDTranDirect (855) 855 6637, for more information.


By Kalon Mitchell, President MEDTranDirect