Healthcare providers collect an extensive amount of data regarding their patient’s medical history. Most providers understand the importance of maintaining accurate and complete health records. Collectively, this data tells a story of the medical history of the patient and can provide insight into new conditions or symptoms that might develop in the future. If you can combine the data from many patients into a database and examine it, new trends can be identified that can lead to new treatments, more efficient healthcare delivery, and better outcomes.
Provider organizations understand the value of this data. They would not think of discarding the medical record after a patient encounter or transferring the only existing copy of this data to a third party for processing, paying for a copy of the data if it was ever needed in the future or losing the data entirely if the third party goes out of business.
Unfortunately, healthcare providers do not associate the same value to the financial transaction data they create and use to collect payment for their services. Like patient encounter data, this data not only represents the data associated with a specific billing event, but when combined with other billing data, it can be used to provide new and valuable information about the provider’s business and the industry as a whole.
In fact, patient financial data is much more valuable for this purpose than patient medical records. Unlike medical record information, billing data adheres to a national standard that assures that every transaction contains the same information in the same format, regardless of the parties involved and what software they might be using. This characteristic of the data presents opportunities to the industry that will not be available using clinical encounter data until this data also conforms to a uniform standard, which is many years away. For financial transactions, these standards have existed for over a decade creating a rich resource of potential information waiting to be uncovered by forward-thinking healthcare organizations and their partners.
Using modern analytics systems, this data can be used to provide useful models of new payment methodologies, new ways to deliver healthcare effectively and accurate measurement of outcomes. The value of these new systems are only limited by the imagination of their users and the data provided. It is here that the opportunity erodes due to the lack of respect for this data compared to its clinical counterpart.
There are two basic transactions conducted electronically by all healthcare providers regardless of size or services, as long as they interact with health plans. They insurance claim (ANSI 837) and the electronic remittance (ANSI 835). The 837 provides a record of the services provided to the patient and 835 provides a record of the payments and adjustments of these claims, associated with a check or EFT.
In order to get paid, each provider must create the 837 to document their encounters and use the 835 to document which claims were paid and how much. For too long, these files have been considered valuable only for these purposes. Most providers do not take the care to preserve this data, like they do clinical information, because they consider them only for their current value. Once the bill is processed, paid and posted, these transactions have served their purpose. Like other seemingly unimportant receipts, they are discarded or tossed in an electronic shoebox where they can be difficult to find or organize in the future.
These new systems, and ones developed in the future, will be able to convert this data into valuable information. Because of this, the data itself is valuable. Some day in the future, some vendor or consultant will show your organization how this data can used to solve an important problem, recover lost revenue, or provide valuable insights to your operation. When this day comes, if it hasn’t already, you will wish you had as much of this data as possible at your disposal. You may spend significant money or time collecting this data that could have been avoided and you may find that some of this data is forever lost due to circumstances that are now beyond your control.
The tragedy is that for most healthcare providers, these problems can easily be avoided with very little effort or cost. By adding simple steps to existing processes, you can be sure that you are prepared when these opportunities present themselves.
Like other new procedures involving existing processes, your first concern should be to correct the problems that exist with current transactions. As quickly as you can, you need to make sure that no future transactions will be lost.
Every provider creates 837 files that are submitted to health plans for payment. Most systems create these files on local computers owned by the providers and then transfer them to payer systems. You should find out when these files are created and where they are located. Do as little as you can to disturb the current processes, but find a way to copy these files to a location that is within your control. A server that will always belong to you and your organization, for instance. Make sure that it is secure, available, and backed up regularly. Claim files often contain claims for many health plans in a single file so it is often not possible to organize them by insurance, however, if they are created for separate organizations, store them in separate folders by the same criteria. For claims, the most important organization method is to preserve them by the date they are created and submitted to insurance. If you need to reassemble this data, you will most likely need data for a specific period of time. This organization method will allow you to pull only the data you need.
For remittances, you should organize the data by payer. The payment dates are included with the files and this data is more reliable than the file creation date since it is common to obtain historical data for these transaction types. Again, when you need this data, it will often be for selected payers only. This organization method will reduce the workload for assembling the data in a new application.
Once you have created your processes for collecting this data and you feel comfortable that new files will be preserved and organized properly, you need to begin the process of collecting as much history as you can for these transactions. As you move backward in time, you will encounter problems obtaining all the available information. Make sure that any problems are documented so that you are aware of any limitations in the data collected. For example, if your vendor processes these transactions for you, or if they have done this in the past, you will need to obtain these transactions from them. Many vendors will charge you to provide you with your own data or present other obstacles in obtaining your information. You will need to deal with this issue.
You need to make sure that this never happens again in future agreements. Your 837’s and 835’s belong to you, not your vendor. If your software process includes the collection of this data without the data ever arriving on your own servers, the vendor may present this as a “convenience” or benefit to your organization, but they are not doing you a favor. They understand the value of this data while you do not and they understand the future opportunity to sell you this data when you realize the value yourself. Never put yourself in this position. Make sure that any HIPAA standard transaction created by any system you use or purchase is made available to you as soon as it is created or received. This data belongs to you, you should not have to pay for it again.
Once you have finished, you will have the data representing all the claims and payments processed by your organization for quite some time. This data goes back to 2003 for Medicare and almost as far back for Medicaid and most other major payers. Someday in the future, you will be glad you took the time and effort to find and organize this data and you will realize the value you never knew it had.
By: Kalon Mitchell, President MEDTranDirect