CR 10064 – A New Way to Process the Hospice NOE
August 10, 2017 03:13 PM
Editor’s Note: Special thanks to Kalon Mitchell, President of MedTranDIrect, Inc., for providing this “vendor perspective” on the Centers for Medicare & Medicaid Services’ plans to allow for electronic submission of hospice Notices of Election. Previous NAHC Report coverage on this issue is available HERE.
On 7/27/17, CMS released CR 10064, “Accepting Hospices Notices of Election via Electronic Data Interchange.” This project was the result of a significant effort by National Association for Home Care & Hospice (NAHC) staff, who worked very hard to develop this concept of using the existing CMS claims processing system to create a new and better way to process the Notice of Election (NOE). The solution put forth in response by CMS in CR 10064 demonstrates creativity and ingenuity by laying the groundwork for a new process that solves real financial and practical problems in the hospice industry.
The negative financial impact that the NOE timely filing requirement has had on the hospice industry has been substantial. A joint NAHC/NHPCO survey conducted in 2015 explored the financial and data processing problems associated with this transaction. The survey covered data from the first half of 2015 and indicated that the non-covered charges from late NOEs averaged over $5000 per month for those hospices that participated in the survey. I am currently working on a project to calculate the actual cost to the industry from 10/1/14 through the end of 2016 using CMS claim data.
Background on the NOE Issue. For the benefit of those not familiar with the NOE transaction, some background on the process and the problems associated with it may be helpful. CMS has long had issues with fitting the model of hospice care into the rest of the reimbursement system for Medicare providers. Hospices are different; unlike other providers, when a patient elects to begin hospice care they must select a particular hospice to be their healthcare provider for all treatment related to their terminal condition. With the exception of an outside attending physician, no other healthcare provider is supposed to be reimbursed for claims related to this condition.
In order for this to work, CMS had to find a way to link the patient with a particular hospice and document this connection so they would know which hospice is to be reimbursed and which other provider claims to reject. In addition, this information needed to be available to all healthcare providers so they would be aware of the status of the patient before services were provided.
The best way to do this was to find a way to store this information in the Common Working File (CWF). The result was development of an NOE (an abbreviated claim) which is submitted to notify the Medicare Administrative Contractor (MAC), and the CWF, of the start date of the beneficiary's election to the hospice benefit.
The problem is that the special bill types like the 8XA for NOEs required the disabling of all the software that edited this data and passed it on for claims processing. Instead, at entry the NOE records are separated and subject to a unique process that takes, according to our data, anywhere from 3 to 25 days before the NOE information ends up in the CWF.
In research conducted as part of its hospice payment reform efforts, CMS found that significant outlays for services outside of hospice are occurring during hospice elections. It is believed that a major contributing factor to these outlays has been that non-hospice providers could not always find accurate information in the CWF related to a patient’s status on hospice care. It was believed that hospices lacked sufficient motivation to file timely NOEs. So, beginning in October 2014, CMS strengthened the incentives by requiring that NOEs be submitted within five days following an admission to hospice.
CMS acknowledged that the NOE could (and would) take longer than that to be processed as “paid” or Returned to Provider (RTP) in FISS, but that the determination of compliance would be the date it was entered and not the date it was processed, provided the NOE did, ultimately, process through. The penalty for non-compliance, a late NOE, was 100% of all revenue from the date of admission to the entered date of the accepted NOE.
From the beginning there were problems. Without the edits making sure the data was correct, any typing error would be recorded with the transaction only to be rejected days later when the NOE transaction was processed. Hospices had problems entering NOEs on a timely basis. Timing issues on processing of discharges and readmissions to service caused them to be in conflict with sequential billing policies and rejected.
The reason that the large penalties reflected in the NAHC/NHPCO survey exist is not that it takes hospices over five days to enter the NOE; it is because there has been a high frequency of errors on NOEs, and many of these errors ultimately led to rejection of the NOE. In many such cases, the NOE has to be reentered. If it is reentered, the new entry date is the date recorded and the date used for determining whether a penalty must be assessed. Since the NOE takes many days before it is determined by CMS to be valid or not, this delay is included in the penalty paid by the hospice when the corrected NOE is entered, assuming it is correct the second time. Without completely correct data the first time, it does not matter when the NOE was originally entered.
When we researched the problem and the process, we came to the same conclusion as NAHC and CMS. The problem was not how to speed up the processing by CMS, but how to make sure that an NOE was not rejected by making sure it was right the first time.
The CMS Solution: Subsequent to the implementation of FISS, CMS developed a new process for claims adjudication. The creation of HIPAA standards for healthcare transactions in 1996 transformed the industry. For the first time, data layouts and code sets were standardized for all payers and vendors. CMS led the way in adopting these standards and deploying new systems that used them. In 2001, they were the first to use the new standard for institutional claims -- the 837i -- and the first health plan to require this standard instead of paper. Since then, they have created automated systems using these files to process these claims the night they are received. They provide even faster validation processes like the 999 which validates claim batches within a couple minutes of receipt and the 277CA which gives the provider a list of claim edits for each claim in the batch, if it was valid and accepted, and a reason code if it is not. This list is provided by the MAC within between five minutes to two hours of receipt of the claims batch. Rejected claims can then be resubmitted the same day. Accepted claims can be found in the CWF the next day.
Through CR 10064, CMS is announcing its intent to use the batch processing and editing functionality of the 837i processing systems already in place to create a mechanism to deliver validated NOE data to the CWF without DDE. This is how it will work.
Software vendors already create the 837i for billing. They will use the data collected by their systems to create the 837i at admission and when the other transactions like NOTR are entered in DDE. The missing data needed by FISS is also a problem for the newer 837i processing systems so with this announcement CMS provided a companion guide. It includes what filler data or hard-coded values to put in each 837i NOE record to represent charges and other data that is normally required for a HIPAA compliant 837i but is not needed for the NOE. It also says what data to leave out. Vendors can use these rules to create the 837i with this filler data and actual NOE data. These batches, which can contain just a single record, can be sent to CMS on a nearly real time basis.
The CR10064 announcement includes the plan for the MACs to provide a 277CA for the NOE 837i batches, as well.
The important thing is that if the vendor is capable of creating the 837i, they have the opportunity to validate the information, as well. As suggested in the guide, they can make sure that the patient data is validated against the HETS eligibility system before it is included in the record. This will prevent a significant number of the current NOE errors that can be directly related to the invalid entry or collection of patient data. In theory, vendor edits should assure their customers that all 837i NOE will pass the MAC 277CA edits just as these edits are intended to prevent claim rejections.
When the 837i is processed by the MAC, they will strip out the filler data and post the data into the FISS system as if it was entered through the DDE screens. This process will eliminate the possibility of keying errors. As long as the data is correct, the NOE will subsequently be processed and accepted by CMS. After the NOE gets into FISS, it will be processed the same as it would be if it were manually entered with the same posting delays. However, the new validation opportunities should decrease rejected NOEs.
This process will be used as a tool to transfer data from one system (837i) to another (FISS). It does not replace the existing method of entering NOEs in DDE. Those providers that do not have the ability to create 837i NOEs or choose not to will not have to. Other existing processes that use hybrid solutions to deal with these issues currently will continue to function as they do now. This option exists if you and your vendor want to take advantage of it, but it is not required.
This new use of the 837i requires that the 837i is created at admission, not as part of the discharge or monthly billing. The special rules in the companion guide apply specifically to NOE transactions that are unique in format and unique to the hospice industry. Through a relatively new concept called API (Application Program Interfaces), vendors purchase licenses to subsystems, like claims processing, that they can insert in their applications. They send these APIs specific data they collect in their systems and the APIs take it from there, interacting with their users until control is passed back to the hostapplication. These API modules, designed for all types of claims processing, would need to be modified for this particular purpose or portions of these systems would have to be redeveloped from scratch. The part that creates the 837i would have to work independently of the other revenue cycle functionality, be attached to admission process and would need to be able to do these transactions one at a time. This would require the cooperation of the vendors on each side of the API. Involvement of more than one vendor can potentially slow the development process.
Another problem is testing and validation of the new process by vendors and the MACs. From what is known so far from CMS, there are no immediate plans for creating a test environment. This means that whoever develops this software will need to wait until it is live (1/2/18) to test it, and then with real NOEs.
Now that this announcement exists, it will take some time for the vendors and the MACs to absorb it. January is only five months away. It may take longer for this happen. In the meantime, there are solutions that address some of these issues already. Some vendor-developed tools to import and validate NOE data and transfer it to FISS in the existing environment are available now.
In any case, this is a big step forward. When the NOE can be processed in the 837i systems, other issues that exist now can eventually be addressed that could never be fixed in FISS. The 277CA and other edits will get better and better as they did with claims. Eventually, CMS can use this system to process NOEs faster and identify more complex errors earlier, giving hospices a second chance at the NOE in the five day window or preventing these errors in the first place.
If any of you have questions about this process, please email me (email@example.com) and I will try to find the answer. For more information on issues related to the NOE, please visit my blog on our company web site, www.medtrandirect.com.