CMS 837i and NOE Tracker – A Process Comparison

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.

For most vendors, their billing software is the most complex portion of their systems. For many of them, it has become enough of a burden that they have contracted with third parties to process these transactions through software connected to their own as “revenue cycle” solutions. This is referred to as API or Application Program Interfaces. These systems are built for all types of healthcare providers to deal specifically with claims processing. Due to the differences in claim processing and NOE processing, it will not be easy to change these systems to create NOEs or to convince their creators to do so for a single provider type.

If the CMS plan is to be implemented, these subsystems, will have to be modified according to the companion guide produced by CMS to create an entirely new transaction that is not a claim and does not contain charges or other data essential to the 837i process. They will also have to be adapted to run at admission and to be able to create and send these transaction one at a time on a real time basis. This is something they are not currently designed to do. Even vendors who still control this process themselves, will find that it will be a struggle to modify their billing systems for this purpose.

This solution is proposed to be available in less than five months. Before this announcement, it was unknown. From here, the MACs must create the process and test it. The vendor community must assess the problem, develop a plan, and implement it. Each of them separately and with mixed results. This will not be a coordinated effort like ICD10. CMS has no plans to develop a test environment. Every vendor will interpret these specifications differently and will be unable to test their solutions in advance. When they are ready, they will have to test with actual NOEs.

It remains to be seen what data the MACs will check when the 837i files are submitted. How long it will take for the 277CA to be returned so providers can see which NOEs were accepted or rejected? When will these transactions show up in FISS?

For those of you that are already our customers, and those of you that might be thinking about it, as you may have guessed, we have a solution that has addressed these issues and it is available today.

NOE Tracker can collect and verify all NOE data real time using only 30% of the data entered through DDE. Our product has been in production for over one year and has successfully processed over 50,000 NOEs. Once the NOE is verified, it is posted to DDE immediately and tracked daily until it has been paid (processed). This product requires no interfaces to outside systems, but soon, we will be releasing our batch functionality which will be compatible with many major hospice vendor systems.

Whether you want to save time, money, or frustration related to your NOEs. This product can get it done and it is available now. Contact to get started.

By Kalon Mitchell – President, MEDTranDirect