CMS Claims File Processing–How Long Does it Take?
Kalon Mitchell, president of transactions processing vendor MedTranDirect Inc., walks through the processes of getting paid by Medicare, and how to speed them up. In large measure, the tips in this comprehensive primer also apply to other health insurers.
Kalon Mitchell, president of transactions processing vendor MedTranDirect Inc., walks through the processes of getting paid by Medicare, and how to speed them up. In large measure, the tips in this comprehensive primer also apply to other health insurers.
Many healthcare providers have automated the transfer of CMS claim data and related files between their claims processing systems and CMS. Sometimes this is performed through their claims processing product and sometimes a separate service is used that involves a secure Internet connection or leased lines to conduct the file transfers. Examples include services offered by Ivans or ABILITY Network that specialize in this activity.
These transfer procedures have changed somewhat with the introduction of the HIPAA 5010 transaction sets and it has taken many months for some of the Medicare contractors to work the kinks out of this process on their new systems. Even now, problems occur on a regular basis that involve both vendor and CMS contractor systems that will have a direct impact on how long it takes for you to receive your revenue.
My company also provides this service for healthcare providers and we have accumulated data on the behavior of these contractor systems in order to improve the efficiency of our own processes and to determine when an undocumented failure has occurred that affects our customers.
This information is important because of the money associated with the successful execution of these transactions and the value of the time associated between recognizing that a failure has occurred and taking the proper action to continue the process from the failed point forward.
The file transfer process involves several steps associated with the exchange of information between the provider and their CMS contractor. Each step includes information that communicates the current status of the process to the provider. It is important that each provider understands the relationship of these tasks and how long they should take so that they can recognize when they are “late” and take the appropriate action to correct the situation as soon as they can.
Here are the steps in the order that they occur:
* The provider’s claim processing system creates an 837 file containing Medicare claims
* The file transfer service sends this file to the appropriate Medicare contractor
* The Medicare contractor creates the 999 batch response file
* The file transfer service retrieves the 999 and sends it back to the provider
* The Medicare contractor creates the 277CA claim response file
* The file transfer service retrieves the 277CA and sends it to the provider
* The Medicare contractor makes the 835 available to the provider
* The file transfer service retrieves the 835
These file transfers take place by establishing a connection between the provider and the Medicare contractor either directly or indirectly through a network or modem connection. In most current systems, modem solutions have been replaced with secure network file transfer services.
To completely understand this process, there are some general characteristics of the systems involved that have an impact on when these transactions are executed.
First, vendor systems that transfer these files to CMS do so through processes that execute when a certain event occurs, for most of these services, they are executed on regular time intervals. For example, claim files may be transferred every four hours. If you make a file available for transfer, it would be sent at the next four hour event. It is important that you learn how this process works with your vendor since it affects both when your files are sent and when they are retrieved by them from the CMS contractor.
Second, the CMS systems work like banking systems. They receive and process files during normal “business hours.” Although files can be sent after hours, responses will not be processed until the “next business day.” These hours can vary for the different CMS contractors executing the transactions. During the night, these systems devote their processing time to data communication between the contractor systems and CMS central processing systems (also known as the Common Working File or CWF). It is important that you learn these cutoff times since the successful submission of claim files prior to the cutoff will reduce your AR days for that batch of claims by at least one day.
Finally, it should be understood that this process can break at any of the steps listed above for a variety of different reasons that may never be fully preventable. Although CMS, and hopefully your vendor, provide the tools to determine the current stage of processing for any claim sent, it is up to the provider to follow up on each stage of this process to detect any failures and react to them. This document is intended to help you understand each step and how long they should take so you can determine if the process has failed and take the appropriate course of action.
Claim File Transfer
After you create your claim file, it must be transferred to your CMS contractor system. There are steps in this process that vary based on how your claim files are created, your vendor, and how your file transfer product works.
After you create your ANSI 837 electronic claim file, it must be made available to the transfer process used by your vendor. For some systems, this requires no action by the customer, for others, it requires “uploading” or moving the claim file to the control of the file transfer product you use.
Once the file is available, it will be transferred at the next file transfer event from your file location to CMS. The actual process of connecting these systems and successfully transferring the data only requires a few seconds. The actual time it will take to get the file to CMS for processing can be calculated if the following information is known:
* When the file is made available for transfer
* When the next transfer from your network product to CMS will occur
* If the actual transfer time is prior to the cutoff time for your contractor
Let’s walk through an example. We will assume that you have control over when the 837 claim file is created and/or made available to your transfer process. You have determined that your vendor sends and retrieves files between your system and CMS every four hours (12,4,8,12). Your CMS contractor has a 4:00 pm cutoff time; any files received after this time will not be processed until the following day. If your goal is to have your claims processed the day they are created, you will have to make them available by noon so they will be transferred through the 12 o’clock transfer process, anything later will cause a one day delay.
The 999 Response File
The ANSI 999 response file was developed with the introduction of 5010. Prior to 5010, CMS used the 997 response file which was similar in format and purpose. This file provides two essential pieces of information to the provider. First, it confirms that your contractor received your 837 file. Second, if there are any problems with the formatting of claims in the file, it will contain a detailed description of the errors found. We refer to these as positive and negative 999s. If you receive a positive 999, it confirms that your batch has been accepted and that the claims will be processed individually. You may still have claims that get rejected, but the clean claims in the file will be processed without delay.
If you get a negative 999, the entire batch is rejected, both clean claims and the claims containing non-compliant data. If you get a negative 999, it normally contains information only your claim processing software vendor can correct for you. Simply recreating and resending the batch will normally produce the same results. Until the problem is solved, this batch, and mostly likely other batches as well, will not be processed by CMS.
To determine if you have a positive or negative 999, you will need to be able to view the contents of the 999 in a human readable format. Your vendor should provide you with the tools to do this.
If you send your claims and do not get a 999 back, as far as your CMS contractor is concerned, the batch of claims was never sent. This leads us to our next processing problem, when should you get a 999 after you have sent your claims and when should you assume it is not coming? There are many reasons why a 999 might not be returned by your contractor. Your system may have failed to successfully transfer your claim file, your login information may be incorrect, the contractor system may have been down at the time, and so forth. Most providers have experienced incidents of this nature in the past where entire batches of claims may have “disappeared” and their vendors and CMS cannot provide an adequate explanation of what happened.
The truth is there is no foolproof method of assuring that each file you send is received by the contractor, however, there is a way to verify that it has occurred. This is the 999 response. The act of receiving this file verifies that the claim file was received by the contractor. During our experience with all CMS contractors, we have never encountered an incident where they returned a positive 999, but the associated claim file was never processed. This relationship allows you to create a verification procedure to validate whether or not the file was accepted by CMS without having to wait until claims age due to non-payment to recognize the failure.
There is a one-to-one relationship between the 837 claim file and the 999. Each claim file you send should have a single 999 returned. If it does, it was accepted, if it does not, it was technically never received and can be resubmitted. Based on this assumption, we can act quickly to resubmit these files as soon as the 999 file is considered late. So when is it late? If you ask the CMS contractor, they commonly respond that you should allow 48 hours for the return of the 999. The truth is, the file is available in a matter of minutes from when the claim file is sent to the contractor system. Our data shows that when a claim file is received by a contractor during operational hours (before cutoff time), over 95% of the time they create a 999 file less than five minutes later. This percentage has steadily improved since we began analyzing data back in April of this year. We receive notices regularly by email when these 999s might be interrupted for system maintenance or because of technical issues at the CMS contractor end. It is strongly recommended that you make sure that someone involved in your claims operations or IT subscribes to these email notifications from your contractor and is in a position to convey this information to those involved. The same is true if your vendor provides this service. This would explain delays in the process and prevent you from having to investigate them or unnecessarily resubmit claims.
There is a difference between the 999 file being created and the provider having it in their possession. This file must be transferred from the contractor system back to the provider. This is normally done through the same software that was used to transfer the claim file. The problem with many of these services is that they do not maintain the current network connection long enough to retrieve this file during the same connection when the claim file is transferred. This means that you will need to wait until the next file transfer event. In our previous example, this would be four hours later.
Your contractors have created a system where you can determine very quickly whether or not your claim file was received. If it was not, you can send it again. Whatever the length of this delay might be in determining that a claim file must be resent contributes to the AR days for the dollars associated with the batch of claims. Each facility that does substantial business with Medicare should understand this process and act on this information as quickly as possible. Your CMS connectivity solution should be judged by how quickly and accurately you are given access to this information.
The 277CA Claim Response File
After your claim file is received by the contractor and a positive 999 is created, the batch is deemed acceptable for processing by the contractor system. Claim files received during operational hours are then processed for “front end” edits by the contractor system. Claims that pass these edits are sent to the Common Working File (CWF) during night time processing for additional error checking and are available the following day through direct data entry access to this file. Those claims that fail front end edits are rejected and are not added to the CWF.
To convey this information to the provider, the contractor provides a HIPAA response report designed to convey claim status information called the 277CA. The 277CA documents which claims passed this process, which ones failed, and why. The 277CA is also known as the Claim Acknowledgement File whereas the 999 is known as the Functional Acknowledgeable File.
Like the 999, there is a one to one relationship between the originating claim file and the 277CA. You should expect to receive one and only one 277CA for each 837 sent.
Like the 999, in order to be able to interpret the information in this file, you will have to have a utility that reformats this information in a human readable report. Each claim in the associated 837 file will be identified and the total number of claims will match the number of claims in this file. Each claim that passes will either be paid or can be edited and corrected in the CWF, and the claims that were rejected, need to be corrected and resubmitted through a future 837 claim file. Both types of claims are documented in this file including the reason for rejection.
Unlike the 999, our data shows that it takes longer for the contractor to create this data. The normal range is from one to three hours from the time the claim file is successfully received. This tends to vary much more from contractor to contractor and only about 70% of files are created in this time interval. However, over 98% are available within 24 hours. Unlike the 999, the presence or absence of this file doesn’t correspond to the successful processing of the clean claims. We have monitored several incidents where 277CA files were never created by a contractor while the claims associated with these batches processed successfully and a 999 was received. We suggest that you take the time to analyze this process between your system and your CMS contractor to determine what is “normal” for you.
Unlike late 999s, you should not resend claims if you have received a positive 999, but the 277CA file does not show up on a timely basis. What we recommend to our customers is that if a 277CA file does not arrive on a timely basis; use your DDE functionality to look up one of claims in the batch to see if it made it to the CWF. If it does not show up in the CWF, check a couple more that you feel should have passed all edits. If some of the claims are present, then you should have received the 277CA already since the claims have already gone through front end edits. You can contact you CMS contractor and ask them for an explanation. If the claims are not present in the CWF, but you have a positive 999, ask them why this file has been delayed.
Like the 999, you will not receive your 277CA until your connectivity vendor transfers the file back to you. Like the 999, this will be influenced by the method and frequency of the events in your file transfer process.
Through the 999 and the 277CA, you are given prompt audit trails for the transfer of your batch and claim data. You can respond to failures of complete batches with the 999 event and resubmit invalid individual claims using the 277CA. Although some vendors use this data to produce their own audit reports, we recommend viewing the data actually provided by CMS to avoid the delay and errors that may be introduced through any additional processing.
The 835 Remittance File
The final response file you will receive is the 835. This file contains valuable information on the charges, payments and adjustments associated with a financial transaction between your facility and CMS. Unlike the other response files, there is not a one-to-one relationship to claim files sent. However, it does contain your final audit information from a claims processing standpoint, and denials. Claims that are completely denied can often be resubmitted if they are recreated with the cause of the denial corrected or revised.
It is important that you monitor this file for many reasons, but for the purpose of successful claim processing, it is important that each file is reviewed immediately after it is received for denied claims and that these claims are corrected, if possible, and promptly resubmitted. Make sure that you have the tools to interpret the data in this file for this purpose. Like the other CMS response files, your network connectivity vendor should be transferring this after it is available. These files are created according to the adjudication of the claims, not the processing of the claim data, so they are related to the systems that create payments for providers and their processing frequency. This can be influenced by many factors, but essentially, you need to have accounting controls in place that assure that you get an 835 for every check or EFT processed through CMS. As a general rule, clean claims sent to your CMS contractor should appear in an 835 in about 14 days.
Conclusion
The point of this article is to provide you with the understanding on how your systems communicate with CMS contractor systems, how these systems work, and how long they take to react. Using this information you can retool your efforts to react to these responses in a “serve and volley” strategy where you minimize the amount of time the process is waiting for your response. These efficiency improvements will translate into AR days reductions for all Medicare claims processed.
Although this article provides information specific to the CMS, this process applies to any payer that uses direct claims transmission as a method of processing claims. It is likely available for your Medicaid claims process as well as BCBS and other major commercial payers. Creating similar procedures for these transactions will produce the same benefits.
Many healthcare providers have automated the transfer of CMS claim data and related files between their claims processing systems and CMS. Sometimes this is performed through their claims processing product and sometimes a separate service is used that involves a secure Internet connection or leased lines to conduct the file transfers. Examples include services offered by Ivans or ABILITY Network that specialize in this activity.
These transfer procedures have changed somewhat with the introduction of the HIPAA 5010 transaction sets and it has taken many months for some of the Medicare contractors to work the kinks out of this process on their new systems. Even now, problems occur on a regular basis that involve both vendor and CMS contractor systems that will have a direct impact on how long it takes for you to receive your revenue.
My company also provides this service for healthcare providers and we have accumulated data on the behavior of these contractor systems in order to improve the efficiency of our own processes and to determine when an undocumented failure has occurred that affects our customers.
This information is important because of the money associated with the successful execution of these transactions and the value of the time associated between recognizing that a failure has occurred and taking the proper action to continue the process from the failed point forward.
The file transfer process involves several steps associated with the exchange of information between the provider and their CMS contractor. Each step includes information that communicates the current status of the process to the provider. It is important that each provider understands the relationship of these tasks and how long they should take so that they can recognize when they are “late” and take the appropriate action to correct the situation as soon as they can.
Here are the steps in the order that they occur:
* The provider’s claim processing system creates an 837 file containing Medicare claims
* The file transfer service sends this file to the appropriate Medicare contractor
* The Medicare contractor creates the 999 batch response file
* The file transfer service retrieves the 999 and sends it back to the provider
* The Medicare contractor creates the 277CA claim response file
* The file transfer service retrieves the 277CA and sends it to the provider
* The Medicare contractor makes the 835 available to the provider
* The file transfer service retrieves the 835
These file transfers take place by establishing a connection between the provider and the Medicare contractor either directly or indirectly through a network or modem connection. In most current systems, modem solutions have been replaced with secure network file transfer services.
To completely understand this process, there are some general characteristics of the systems involved that have an impact on when these transactions are executed.
First, vendor systems that transfer these files to CMS do so through processes that execute when a certain event occurs, for most of these services, they are executed on regular time intervals. For example, claim files may be transferred every four hours. If you make a file available for transfer, it would be sent at the next four hour event. It is important that you learn how this process works with your vendor since it affects both when your files are sent and when they are retrieved by them from the CMS contractor.
Second, the CMS systems work like banking systems. They receive and process files during normal “business hours.” Although files can be sent after hours, responses will not be processed until the “next business day.” These hours can vary for the different CMS contractors executing the transactions. During the night, these systems devote their processing time to data communication between the contractor systems and CMS central processing systems (also known as the Common Working File or CWF). It is important that you learn these cutoff times since the successful submission of claim files prior to the cutoff will reduce your AR days for that batch of claims by at least one day.
Finally, it should be understood that this process can break at any of the steps listed above for a variety of different reasons that may never be fully preventable. Although CMS, and hopefully your vendor, provide the tools to determine the current stage of processing for any claim sent, it is up to the provider to follow up on each stage of this process to detect any failures and react to them. This document is intended to help you understand each step and how long they should take so you can determine if the process has failed and take the appropriate course of action.
Claim File Transfer
After you create your claim file, it must be transferred to your CMS contractor system. There are steps in this process that vary based on how your claim files are created, your vendor, and how your file transfer product works.
After you create your ANSI 837 electronic claim file, it must be made available to the transfer process used by your vendor. For some systems, this requires no action by the customer, for others, it requires “uploading” or moving the claim file to the control of the file transfer product you use.
Once the file is available, it will be transferred at the next file transfer event from your file location to CMS. The actual process of connecting these systems and successfully transferring the data only requires a few seconds. The actual time it will take to get the file to CMS for processing can be calculated if the following information is known:
* When the file is made available for transfer
* When the next transfer from your network product to CMS will occur
* If the actual transfer time is prior to the cutoff time for your contractor
Let’s walk through an example. We will assume that you have control over when the 837 claim file is created and/or made available to your transfer process. You have determined that your vendor sends and retrieves files between your system and CMS every four hours (12,4,8,12). Your CMS contractor has a 4:00 pm cutoff time; any files received after this time will not be processed until the following day. If your goal is to have your claims processed the day they are created, you will have to make them available by noon so they will be transferred through the 12 o’clock transfer process, anything later will cause a one day delay.
The 999 Response File
The ANSI 999 response file was developed with the introduction of 5010. Prior to 5010, CMS used the 997 response file which was similar in format and purpose. This file provides two essential pieces of information to the provider. First, it confirms that your contractor received your 837 file. Second, if there are any problems with the formatting of claims in the file, it will contain a detailed description of the errors found. We refer to these as positive and negative 999s. If you receive a positive 999, it confirms that your batch has been accepted and that the claims will be processed individually. You may still have claims that get rejected, but the clean claims in the file will be processed without delay.
If you get a negative 999, the entire batch is rejected, both clean claims and the claims containing non-compliant data. If you get a negative 999, it normally contains information only your claim processing software vendor can correct for you. Simply recreating and resending the batch will normally produce the same results. Until the problem is solved, this batch, and mostly likely other batches as well, will not be processed by CMS.
To determine if you have a positive or negative 999, you will need to be able to view the contents of the 999 in a human readable format. Your vendor should provide you with the tools to do this.
If you send your claims and do not get a 999 back, as far as your CMS contractor is concerned, the batch of claims was never sent. This leads us to our next processing problem, when should you get a 999 after you have sent your claims and when should you assume it is not coming? There are many reasons why a 999 might not be returned by your contractor. Your system may have failed to successfully transfer your claim file, your login information may be incorrect, the contractor system may have been down at the time, and so forth. Most providers have experienced incidents of this nature in the past where entire batches of claims may have “disappeared” and their vendors and CMS cannot provide an adequate explanation of what happened.
The truth is there is no foolproof method of assuring that each file you send is received by the contractor, however, there is a way to verify that it has occurred. This is the 999 response. The act of receiving this file verifies that the claim file was received by the contractor. During our experience with all CMS contractors, we have never encountered an incident where they returned a positive 999, but the associated claim file was never processed. This relationship allows you to create a verification procedure to validate whether or not the file was accepted by CMS without having to wait until claims age due to non-payment to recognize the failure.
There is a one-to-one relationship between the 837 claim file and the 999. Each claim file you send should have a single 999 returned. If it does, it was accepted, if it does not, it was technically never received and can be resubmitted. Based on this assumption, we can act quickly to resubmit these files as soon as the 999 file is considered late. So when is it late? If you ask the CMS contractor, they commonly respond that you should allow 48 hours for the return of the 999. The truth is, the file is available in a matter of minutes from when the claim file is sent to the contractor system. Our data shows that when a claim file is received by a contractor during operational hours (before cutoff time), over 95% of the time they create a 999 file less than five minutes later. This percentage has steadily improved since we began analyzing data back in April of this year. We receive notices regularly by email when these 999s might be interrupted for system maintenance or because of technical issues at the CMS contractor end. It is strongly recommended that you make sure that someone involved in your claims operations or IT subscribes to these email notifications from your contractor and is in a position to convey this information to those involved. The same is true if your vendor provides this service. This would explain delays in the process and prevent you from having to investigate them or unnecessarily resubmit claims.
There is a difference between the 999 file being created and the provider having it in their possession. This file must be transferred from the contractor system back to the provider. This is normally done through the same software that was used to transfer the claim file. The problem with many of these services is that they do not maintain the current network connection long enough to retrieve this file during the same connection when the claim file is transferred. This means that you will need to wait until the next file transfer event. In our previous example, this would be four hours later.
Your contractors have created a system where you can determine very quickly whether or not your claim file was received. If it was not, you can send it again. Whatever the length of this delay might be in determining that a claim file must be resent contributes to the AR days for the dollars associated with the batch of claims. Each facility that does substantial business with Medicare should understand this process and act on this information as quickly as possible. Your CMS connectivity solution should be judged by how quickly and accurately you are given access to this information.
The 277CA Claim Response File
After your claim file is received by the contractor and a positive 999 is created, the batch is deemed acceptable for processing by the contractor system. Claim files received during operational hours are then processed for “front end” edits by the contractor system. Claims that pass these edits are sent to the Common Working File (CWF) during night time processing for additional error checking and are available the following day through direct data entry access to this file. Those claims that fail front end edits are rejected and are not added to the CWF.
To convey this information to the provider, the contractor provides a HIPAA response report designed to convey claim status information called the 277CA. The 277CA documents which claims passed this process, which ones failed, and why. The 277CA is also known as the Claim Acknowledgement File whereas the 999 is known as the Functional Acknowledgeable File.
Like the 999, there is a one to one relationship between the originating claim file and the 277CA. You should expect to receive one and only one 277CA for each 837 sent.
Like the 999, in order to be able to interpret the information in this file, you will have to have a utility that reformats this information in a human readable report. Each claim in the associated 837 file will be identified and the total number of claims will match the number of claims in this file. Each claim that passes will either be paid or can be edited and corrected in the CWF, and the claims that were rejected, need to be corrected and resubmitted through a future 837 claim file. Both types of claims are documented in this file including the reason for rejection.
Unlike the 999, our data shows that it takes longer for the contractor to create this data. The normal range is from one to three hours from the time the claim file is successfully received. This tends to vary much more from contractor to contractor and only about 70% of files are created in this time interval. However, over 98% are available within 24 hours. Unlike the 999, the presence or absence of this file doesn’t correspond to the successful processing of the clean claims. We have monitored several incidents where 277CA files were never created by a contractor while the claims associated with these batches processed successfully and a 999 was received. We suggest that you take the time to analyze this process between your system and your CMS contractor to determine what is “normal” for you.
Unlike late 999s, you should not resend claims if you have received a positive 999, but the 277CA file does not show up on a timely basis. What we recommend to our customers is that if a 277CA file does not arrive on a timely basis; use your DDE functionality to look up one of claims in the batch to see if it made it to the CWF. If it does not show up in the CWF, check a couple more that you feel should have passed all edits. If some of the claims are present, then you should have received the 277CA already since the claims have already gone through front end edits. You can contact you CMS contractor and ask them for an explanation. If the claims are not present in the CWF, but you have a positive 999, ask them why this file has been delayed.
Like the 999, you will not receive your 277CA until your connectivity vendor transfers the file back to you. Like the 999, this will be influenced by the method and frequency of the events in your file transfer process.
Through the 999 and the 277CA, you are given prompt audit trails for the transfer of your batch and claim data. You can respond to failures of complete batches with the 999 event and resubmit invalid individual claims using the 277CA. Although some vendors use this data to produce their own audit reports, we recommend viewing the data actually provided by CMS to avoid the delay and errors that may be introduced through any additional processing.
The 835 Remittance File
The final response file you will receive is the 835. This file contains valuable information on the charges, payments and adjustments associated with a financial transaction between your facility and CMS. Unlike the other response files, there is not a one-to-one relationship to claim files sent. However, it does contain your final audit information from a claims processing standpoint, and denials. Claims that are completely denied can often be resubmitted if they are recreated with the cause of the denial corrected or revised.
It is important that you monitor this file for many reasons, but for the purpose of successful claim processing, it is important that each file is reviewed immediately after it is received for denied claims and that these claims are corrected, if possible, and promptly resubmitted. Make sure that you have the tools to interpret the data in this file for this purpose. Like the other CMS response files, your network connectivity vendor should be transferring this after it is available. These files are created according to the adjudication of the claims, not the processing of the claim data, so they are related to the systems that create payments for providers and their processing frequency. This can be influenced by many factors, but essentially, you need to have accounting controls in place that assure that you get an 835 for every check or EFT processed through CMS. As a general rule, clean claims sent to your CMS contractor should appear in an 835 in about 14 days.
Conclusion
The point of this article is to provide you with the understanding on how your systems communicate with CMS contractor systems, how these systems work, and how long they take to react. Using this information you can retool your efforts to react to these responses in a “serve and volley” strategy where you minimize the amount of time the process is waiting for your response. These efficiency improvements will translate into AR days reductions for all Medicare claims processed.
Although this article provides information specific to the CMS, this process applies to any payer that uses direct claims transmission as a method of processing claims. It is likely available for your Medicaid claims process as well as BCBS and other major commercial payers. Creating similar procedures for these transactions will produce the same benefits.
More for you
Loading data for hdm_tax_topic #care-team-experience...