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.
One recent example was a provider who contacted us about the validity of the Medicare HETS eligibility report we provided. This report includes the identity of any Medicare secondary insurance. He had a patient who had provided an insurance card identifying their secondary insurance, this payer was not listed on the HETS eligibility report. After contacting the payer by phone, they determined that the secondary insurance was valid. We were confronted about the invalid data we provided explained why this was the case.
HETS, and most eligibility systems, are updated by the processing of claims by payers. As such, the information they provide for a specific individual is only as valid as the last claim successfully processed by the payer. Whenever someone signs up for new insurance, this data is not recognized by any shared systems until a patient actually receives healthcare services, the payer is billed, and the claim is successfully processed and paid. There can be significant delays between these two events since an individual may go months without any interaction with healthcare providers. In this specific example, the consequences of this data lag are inconvenient for the provider in that they must take steps beyond the HETS eligibility check to verify the validity of the secondary insurance. There are other situations where this issue presents more serious problems regarding the validity of the HETS eligibility response.
Patients identified as hospice patients under the Medicare program are associated with a single Medicare licensed hospice provider. This hospice is responsible for all treatment for these patients related to the clinical condition leading to their admission to the hospice. This means that although these patients may have active Medicare coverage, healthcare services obtained by providers outside of the assigned hospice may not be reimbursed. Other related issues are that a patient may not be covered by two different hospices, meaning that a hospice may not admit a patient who is already associated with another hospice or until the transaction that ends this previous relationship is processed.
As I discussed in a previous article, CMS created a new regulation in October of 2014 requiring hospices to process the transaction that assigns the patient to a hospice within five calendar days of the admission. If this does not occur, the hospice is penalized 100% of their reimbursement every day between the admission date and the date the accepted transaction is entered. My guess is that this regulation was an attempt to make their eligibility data more current by making sure that this data was processed promptly after the decision to assign a patient to the hospice.
This transaction is called the NOE (Notice of Election). There is only one method of creating this transaction and that is by entering it manually in the Medicare DDE system. This is a Medicare mainframe computer that runs software developed in the early 1980s to enter and update claim data for CMS processing. This system was developed before batch electronic claims processing systems were available for healthcare providers, which began in the early 1990s.
The claims entered through this system are processed in batch each night. If the claim data is valid, the claim is entered in the CWF (Common Working File) and is listed as pending until it is processed for payment. If there are errors, it is placed in a queue called the RTP (Returned to Provider) file where the provider can see why it was rejected. These claims must then be reentered manually.
The NOE is entered in this system as if it was a claim, but it is not a claim. It contains no charges for payment. Unlike other claims entered in DDE, it cannot alternatively be sent and processed in an 837 claim file, it must be entered manually.
This presents serious problems with the ability of the provider to track these transactions. When claims are sent to MACs (Medicare Contractor) through the 837 claim file, the MAC system processes these transactions much more efficiently. Instead of waiting until the next day for validation of the transaction, providers are capable of getting more immediate feedback. Once transferred to a MAC, each 837 file is examined for validity as a batch. This happens in a matter of minutes. Our process provides this file (ANSI 999 batch status) back to providers normally within three to five minutes after the submission of the 837 claim file.
After the batch is accepted, the MAC system verifies the validity of the data in each claim individually. We access the MAC systems every 30 minutes and retrieve these files when they are available. Currently, these files (the 277CA) are normally returned to providers within two hours of the submission of the claims. They list each claim in the batch and whether or not it was accepted or rejected. Rejected claims are listed with a reason code. Rejected claims will not be included in the CWF and must be corrected and resubmitted in a future batch.
Through this process, providers can often correct rejected claims and resubmit them to Medicare the same business day. Since hospice providers cannot submit the NOE or NOTR (Notice of Termination/Revocation) through this process, the best they can hope for is next day acknowledgement of the NOE status in DDE.
Unlike the 837 process, where Medicare initiates the claim status data sent to each provider, the provider must follow up on each NOE entered manually each day until they can confirm that it has been accepted. Checking each NOE individually and going through several screens to determine whether or not it was accepted or rejected. Rejected NOEs must be manually reentered once again from scratch with a minimum of two days already eliminated from their five day window.
This not only presents a problem for hospices to be compliant with this five day window, which may soon be changed to three days, but it also presents problems for the entire healthcare industry. Without current and accurate NOEs in the HETS response, providers may provide services that will never be reimbursed. In addition, hospices may admit patients and enter their NOEs only to have them rejected later because the NOTR for the previous hospice has not been processed and does not appear in the eligibility report.
The solution to this problem is that CMS must provide the option of submitting NOEs and NOTRs as ANSI 837 claims. Not only would this allow most providers and their vendors to automate the process without manual entry, as they do standard claims, but it would allow the NOE and the NOTR to be verified the same day it was submitted. If the transaction was rejected, the 277CA could contain error codes listing rejections specific to these transactions like “already assigned to another hospice”.
I have asked CMS why this option was not available, their response was that the MAC systems were not designed to process these transactions since they are not claims. In my opinion, this is a pretty lame excuse given the importance of these transactions being reflected in the eligibility system and the time frame they are placing on providers for processing them. The only significant difference I can see in these transactions from other claims is that they do not have charges.
As a programmer myself, it seems hard to believe that this difference in the NOE from actual claims would be difficult to overcome. These transactions can have specific characteristics like unique TOB (Type of Bill) codes that can be used to process them differently from other claims. The data currently required for the NOE is enough to create a HIPAA compliant claim. Anything missing can be included with hard coded information needed to create a compliant transaction.
By solving this problem through accepting NOEs in the claims processing system, providers can use the existing processes for claim verification to identify errors and to resubmit them easily within the time frame assigned. Through DDE, you have at most two chances to submit a valid NOE within the five day window. With the 837 claims processing cycle, you would have at least twenty. With the increased efficiency of the NOE processing, less penalties would be imposed by CMS to hospices for late filing saving the industry millions each year. CMS could reduce the window from five days to three and hospices would at least be technically capable of compliance and HETS eligibility data needed to identify these patients to other healthcare providers would be timely and accurate.
As a vendor, these issues are frustrating to deal with since they seem so simple to correct. As a provider, the expenses and lost revenue related to these inefficiently processed transactions may mean the difference between survival and profitability. CMS must change this process. It is not difficult and the benefit obviously outweighs the cost of any effort required to deal with the problem.
By Kalon Mitchell, President MEDTranDirect