Using HIPAA Transactions for Revenue Cycle Management

HIPAA transactions were developed with the intent to reduce overall administrative costs for the healthcare industry.  This is accomplished in two ways, by developing a standard that can be used to conduct these transactions consistently under all similar conditions and trading partners to create transactions that automate previously manual or semi-manual processes.

This article will discuss how these transactions can be used to support the processing and follow up of claims.

The first step in claims processing is the creation of the claim file itself, the 837i (institutional) and the 837p (professional).  These files must contain all recently produced claims of each type that are destined for a specific entity.  At our company, we use the term receiver to represent the target of these files.  Receiver is distinguished from payer in that a receiver may receive claims for multiple payers in a single file.  For example, a clearinghouse like Emdeon or Availity.  In other cases, the receiver may represent a single payer, or even a sub-classification of a payer, like Medicare Part A and Medicare Part B.

For this process to work effectively, it is in the interest of the healthcare provider, or the entity that must monitor the status of claims, to transmit directly to payers whenever possible.  This means that it is better to make the receiver and the payer the same entity than to group payers into a single file and process them through a clearinghouse.  When you send multiple payers to the same receiver, steps are added to the process that cannot be monitored through standard HIPAA transactions.  I will explain as we go through the steps in monitoring claim status.

Even though these processes are HIPAA standards, they are not universally used in all transactions.  HIPAA says that when you conduct a covered transaction electronically, you must use these standard file formats.  HIPAA does not say that they have to be used instead of other processes like telephone based systems.  This is changing with the Operating Rules portion of the Affordable Care Act.  These operating rules are requiring all parties (typically non-compliant payers) to use these transactions as part of their processes, if they were not doing so already, by deadlines established in the ACA.

http://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/Affordable-Care-Act/OperatingRulesforHIPAATransactions.html

For example, the 270/271 eligibility transactions and the 276/277 claim status transactions were required of all payers beginning 1/1/13 and at the end of this year, all payers will be required to provide 835 electronic remittances and EFT (electronic funds transfers).  This legislation, along with the existing standards, will allow healthcare providers and their software vendors to create standardized systems that will automate many of these manual processes and provide new information that can help manage the revenue cycle.  Instead of these processes involving just Medicare, they will eventually apply to all insurance transactions.

Excluding checking patient eligibility, the process begins with the act of sending a file of claims to a receiver for adjudication.  There are no standards or operating rules that apply to the process for exchanging this data other than the fact that this process must be secure.  When the receiver obtains the file from the provider or provider representative, they run a process to check the validity of the data to see if the file is HIPAA compliant and contains all the necessary data at the batch level to process the claims contained in the file.  They then produce a file called the ANSI 999 and make it available to the provider.  This file shows that the batch was accepted or describes the errors contained in the batch that caused it to fail.  Typically, these errors, if they are present, are not caused by errors in creating or editing these claims by the provider, but in the software used to create these files or interpret the validity of the batch.  For this reason, these errors can only be reported by the provider to their software vendor.  They normally can do nothing to correct them without their assistance.

With Medicare contractors, 999 files are typically created within two or three minutes from when the claim file is received.  Other receiver’s response times can vary.  The delivery of this data back to the provider is dependent on the provider’s software that connects with the receiver to obtain these files.  The 999 and other files created by the receiver are referred to as “response files”.  These files are made available through some type of delivery system.  The most typical configuration is the “mailbox” approach where there is an “inbox” and “outbox” that is used by the receiver to collect files and make files available to the provider.  With our Medicare connectivity product, PayerLink, we remain connected with the receiver system for 10 minutes after the delivery of a claim file so that we can obtain the 999 response file during the same connection cycle used for the delivery of claims.

The 999 actually tells you two things.  In addition to letting you know if a batch is valid or not, receiving a 999 lets you know that the receiver system received your claim batch and recognized that it belongs to you.  This may seem simple, but it is significant.  It is not uncommon for a provider to “send” a batch of claims and assume it has been received by the payer only to find out much later that none of the claims were processed.  This step in claims follow up is very important since no claims contained in a batch can be processed if the receiver never actually receives the batch.  This means that your first step in claims follow up is to verify that a 999 is received for every batch of 837 claims that you send.  If a 999 does not arrive, you need to contact the receiver and find out if the batch ever made it to their system.  If they say it did not, you can resend the batch and again watch for the 999 response.  You will need to learn how long it should typically take for each receiver to send you the 999 based on their procedures and how your connectivity software works.  Using this information, you will need to determine when this 999 should be considered “late”.  Our rule of thumb for Medicare transactions is 24 hours.

When you get the 999, you know that the batch was received, but you don’t necessarily know if it was accepted.  To determine this, you must be able to examine the contents of this file.  These ANSI files are not designed to be readable through a text editor or other tools that allow you to examine the contents of a file any more that you can determine the details of an insurance claim by viewing your ANSI 837 claim file.  They contain loops and segments intended to be parsed by applications into a human readable format or updated into a database.  In order to find out if your batch was accepted, you need some sort of application from your vendor that allows you to view the contents of this file.  If no errors are reported, you can assume the batch was accepted.  If there are any errors of any kind, you can assume that the batch was rejected and no claims contained in the batch will be processed.  If this occurs, you must work with your claims producing software vendor to determine why the error occurred, correct it, and resubmit the batch.

Earlier I mentioned that using clearinghouses added steps to this process that cannot be confirmed by the provider with HIPAA transactions.  This is the step in the process where we are presented with this problem.  Let’s say that we create a file for a clearinghouse that has claims for 50 different payers.  When we send the file to the clearinghouse, we receive a 999 that shows that the claim file was received and was valid.  This acknowledgement confirms that the batch was received by the clearinghouse, but not by the payer.

The clearinghouse normally has a batch process that they run at night that takes all the provider batches received that day and combines them into one large file.  They then divide this file up by payer and then transfer the claim files to these payers.  These transactions occur between the clearinghouse and the payer and the provider is unaware if and when they occur and receives no response transactions that can confirm if they occurred successfully for their specific transactions.

Clearinghouses are normally very efficient in conducting the processes, but most providers can describe historical cases where they have failed for their organization in the past.  If you want to process claims for all payers electronically, and you should, there is no way to avoid using clearinghouses since it is still the only way to get claims electronically to a majority of commercial payers.  However, if you can transmit directly, through the 999 transaction between you and the payer, you can avoid the “black hole” of clearinghouse reprocessing procedures whose success or failure cannot be immediately confirmed.

After the file has been received and successfully processed, the receiver normally provides a confirmation of the results at the claim level.  Prior to HIPAA, many payers, including Medicare, provided a proprietary confirmation report that was normally a text report with detailed information on each claim in a batch and whether or not these claims passed “front end” or initial edits.  Front end edits normally include basic errors like duplicate claims, missing or invalid essential data like policy numbers and birth dates.  It does not include more complex errors that may later determine that a claim is suspended like missing modifiers or attached documentation.  An organization that obtains and acts quickly on this information can significantly improve their days in receivables over an organization that does not since this information is normally provided very quickly by the receiver.

Since HIPAA was implemented, Medicare and Medicaid replaced their proprietary reports with the 277 claim status response transaction.  Normally, these transactions are sent as a response to the HIPAA 276 transactions created by the provider systems to inquire on the status of specific claims.  However, the confirmation report assumes that the claims the provider is interested in are the claims sent in the last successfully received batch.  The response file created by the receiver is called the 277CA or the unsolicited claims status response since the provider did not have to ask for it.

If 50 claims are sent in a file, the 277CA will list all 50 claims along with some basic data on each claim including total charges, patient data, etc.  It will also contain a status code that will show if the claim was accepted or rejected and the reason for this determination.  If 50 claims are sent and 45 are accepted and 5 are rejected, the 45 accepted claims will be adjudicated and paid if no other errors are found.  The 5 claims with errors, will not be included with the valid claims and must be fixed and resubmitted by the provider.  As with other aspects of revenue cycle management, the sooner you can determine that a claim has been rejected, and why, the sooner you can correct it, send it out again, and collect your payment.

Medicare contractor systems typically create the 277CA two to four business hours after the claims have been received.  Like the 999, you must retrieve the file from your mailbox using a connectivity vendor and interpret the results.  Again, this is not in a readable format so you must have some sort of reporting software that can display the contents of this file in a readable format.  You must also have procedures in place to make sure that these files are delivered by your receiver within a reasonable time period after the claims are sent and a 999 is received.  This should normally be one business day.

After the initial transmission of the claims and the follow up of the claim confirmation report (277CA), the accepted claim will be “pending” in the receiver system for a certain period of time until it is adjudicated.  During this time, most systems examine the claims for additional requirements that are not verified in the confirmation report like “awaiting additional documentation” or insurance authorization.  These conditions can cause claims that were shown to be accepted in the 277CA to remain suspended indefinitely until the condition is corrected or the additional information is submitted by the provider.  A proactive provider should have a system in place to identify these claims as soon as possible so that they can take action to get them flowing through the system again.  There can be many unique processes for this in receiver systems, like DDE for Medicare, that allow you to view the status of pending claims individually, but if you deal with large volumes of claims, these methods are inefficient since you must first identify that a claim is suspended to correct it and if you cannot, you must examine all submitted claims.

HIPAA has developed the claims status transaction (276/277) to optimize this process.  Through this procedure, the provider can create a file of all claims they wish to examine for their current status (276 – claim status request).  Typically this would be all claims that have been submitted, but not paid or denied.  This file can be submitted to a receiver and you will then get a file (277- claim status response). You can then sort this information by status codes to separate the claims awaiting some action from the provider from those that are pending payment.  You can also group the claims by types of errors to make the process of correcting these claims more efficient.  If you have large numbers of claims, this should be a daily process so that new suspended claims are identified as quickly as possible and so that corrected claims can either be reclassified as pending or show up needing additional action.

After a pending claim is adjudicated, it is either paid (with adjustments) or denied (adjusted to zero).  The payer generates a check for the claims paid together for a specific time period.  In addition to the check (or EFT).  An 835 will be created and made available to the provider showing the detail of payments and adjustments that make up the total of that check.  Included in this data are the claims that were denied.  Beginning 1/1/14, the operating rules for 835s go into effect and one of them states that the 835 and the EFT will occur within three days of each other.

The 835 is a response file made available through the same process used to submit claims and retrieve your batch response files.  It is important that you obtain this file on a timely basis and apply these transactions to the effected accounts.  Only then can you accurately bill secondary insurance payers or collect on remaining self-pay balances.  The denial data can be used to attempt to correct, document, and resubmit these rejected claims, if possible.

Through the proper management of these transactions through your software solutions, you can make significant improvements in your AR days and more efficiently process these tasks with less labor and mistakes.

 

By Kalon Mitchell – President, MEDTranDirect

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s