Preserving Your HIPAA Transaction Files

A few days ago I had a call from a current customer.  They needed help with a project to find claim data that met a certain criteria for additional action.  In this case, a major commercial payer had paid claims late over an extended period of time to healthcare providers all over the country.  This particular hospital had learned at a conference that they could collect the substantial interest on these claims by simply creating a list of the claims that qualified and submitting this list and supporting documentation to the payer.  They had contacted a consultant that was going to assist them with this process.  All they needed was a way to identify these claims and create this list.

savehipaa1

One of our products (835Direct) is capable of loading electronic remittances (835s) into a database and mining the data back out in a variety of formats.  It could have been used to examine the remittance data from this payer and produce a spreadsheet of all claims where the difference in the bill date and the payment date was greater than x. However, the software they use to obtain their remittances imported the remittances into a proprietary product for printing EOBs, posting to AR and such, but did not provide the capability of producing this list.  Furthermore, this vendor does not forward the 835 remittances they receive on behalf of the customer on to the customer.  After they are imported, they are archived by the vendor and the customer must pay service fees to obtain their own information in the original 835 format.  This customer is exploring this option, but even if it is worth the expense, it will take additional time to obtain this information.

Over the years, I have experienced many variations of this problem.  There are other scenarios where the inability to locate and produce your own HIPAA transaction data can be very detrimental to the provider organization that owns and originally created this data.  For example, 837 files are used to send claim data from the provider to payers in order to get paid.  In addition to this purpose, these files also represent the only valid documentation of what data was exchanged between the provider and the payer for reimbursement for these encounters.  If you are audited by the payer or if these claims become the focus of some other type of dispute, these files are the best evidence of what was sent by the provider and received by the payer.

In many claims processing systems, once these claims are sent and received by the payer, they are archived by the vendor (hopefully) and are not accessible directly by the provider since the perception is that they are no longer needed. I have heard of many circumstances where providers either had to pay to obtain this data after it was processed, or found that it was unavailable.

Another common issue is the transition from one claims processing vendor to another.  Many systems are now web-based so data is stored on remote servers and is only accessible to the provider while the relationship exists between the provider and their vendor.  When this relationship is terminated, access to this claim data is usually lost.  If the provider still had copies of the 837 files produced by this system, they could possibly be imported into the new vendors system and their claim history could be transferred and reproduced.  I believe that some vendors intentionally develop processes that deny access to these original HIPAA transaction files in order to create these type of transition barriers for their customers. These barriers are unnecessary and users should be able to access their own data at any time.

As I explained at the beginning of this article, this also applies to the remittance data or the 835 transaction.  Many organizations focus on this data as being a simple tool to avoid the manual process of posting payments and adjustments.   However, it contains detailed information that can not only provide revenue information at the charge and department level, but profit as well.  Since this file contains payments and adjustments as well as charges, it can be used to produce any information you might need regarding the relationship between claims, charges, payments and adjustments.  In addition to cases like I described where you can identify payments that are late, you can also uncover claims that were not paid according to contractual criteria and claims that were improperly denied or could be refiled to recover revenue.

Most importantly, it is very likely that claim and remittance data files could provide you with valuable information in the future that you might not anticipate now.

Beginning 1/1/14, payers were required to provide 835s and EFT services for any provider that requested these transactions as part of the Affordable Care Act.  Every provider organization should be working toward taking advantage of this process in their own revenue cycle management reviews.  CAQH CORE, the organization defining these payer requirements, has created an excellent free tool that can be used to enroll with many payers at once for implementing this process.

Payer Enrollment Tool: http://www.caqh.org/eft_enrollment.php

Payers are more than willing to replace paper remits and checks with the 835 and EFT since it is to their benefit as well, but it is the responsibility of the provider to initiate the request.

The lesson to be learned from this is that every provider should make sure that their revenue cycle process includes obtaining copies of every 837 file that is created for payers and every 835 that is produced by payers for the provider.  If you use software that sends and receives these files, you need to make sure that you have included procedures to archive these files when they are produced.  Do not depend on your vendor for this.  This process needs to be independent of any system you may be using now.  It may not always be your method of processing these transactions in the future.

You should create a file and folder structure on a secure server that is owned and operated by your provider organization, not a third party, for the retention of this data.  You should develop a process to make sure that these files make it to this server, without exception, and you should work toward enlarging the list of payers that contribute data to this process through 835 enrollment.  You should already be creating 837 claim files for almost all outbound claims and retaining them as well.

This server should be organized by year and possibly payer or financial class so that it will be easy in the future to locate this data by this criteria.  Keep your 835 and 837 files separate from each other if you can.

If you have some way of getting this data now, get it as soon as you can before the situation changes.  We have a saying in my organization when we develop new software and features for our existing HIPAA transaction systems, the cost of storing this data will always be less than the future value of the data itself.  These files should never be deleted or lost if it can be avoided.  Make sure they are backed up and duplicated, if possible.  These steps are not expensive or time consuming and I assure all of you that someday you will be glad you established these procedures.

 

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