A few weeks ago I wrote a short blog about the recently released statistics on the adoption rate of HIPAA transactions compiled by CAQH for the calendar year of 2013. This report is called the 2014 CAQH index and is available through the CAQH web site (http://www.caqh.org/) or directly through this link:
This study is actually the second year in a row where they collected this data so in addition to providing adoption rates for 2013, the data for 2012 is available as well along with a measurement of change in the adoption rate of these transactions over a year.
Here are the adoption rates for the two years for the three most common standardized healthcare electronic transactions:
I recently attended a webinar held by CAQH where they went over these results and answered questions. One point that I was not originally aware of is that these statistics do not reflect all such transactions in the healthcare industry. CAQH only used data from commercial health plans, Medicare and Medicaid transactions were not included. These makes these percentages a little more encouraging since they are not padded by the large volume of Medicare transactions that are close to 100% compliant for all three transaction types.
As I have discussed in recent blogs, the Affordable Care Act (ACA) includes legislation designed to eventually enforce the use of these transactions by health plans. But like with other aspects of the ACA, nothing is certain to happen and anything can be undone.
Since Medicare will only conduct these transactions through a fully HIPAA compliant process using only the associated HIPAA transactions to exchange this data, it stands to reason that any healthcare provider that must conduct these transactions with Medicare, is already prepared to process these transactions with any other health plan.
The eligibility (mandated in 2013) and remittance transactions (mandated in 2014) are already required transactions under this legislation. This makes these numbers very confusing to someone not familiar with the history and underlying business processes associated with these transactions. If claims submission is the only transaction listed that is not mandated, why is it the one most widely accepted? Why is the growth so insignificant between these two years for all transaction types?
Here are my opinions on why these numbers are what they are and why.
Claims submission under the HIPAA standard (ANSI 837) began for all practical purposes in 2003 when CMS, after two delays, finally required this format for all claims submitted for payment. Since then, the only way to get Medicare claims paid was through electronic batch submission through this format or direct entry in the Part A portal, referred to Direct Data Entry or DDE. At the time, other health plans still heavily depended on paper and the legacy electronic standard referred to as the National Standard Format or NSF.
Providers with any significant claim volume obtained new systems capable of collecting claim data and exporting it as an 837 file in order to maintain Medicare cash flow. For most other payers, they continued to create and process paper claims. This created a situation where providers were capable of creating these transactions electronically, but a majority of health plans still either required paper only or were still built around the NSF electronic standard for data collection and claim adjudication.
This created a market for businesses to provide the service of taking the claim data a provider could produce (the ANSI 837) and providing the data a health plan could process (paper or NSF electronic). We refer to these businesses as clearinghouses. Companies like Emdeon and Availity, and others that remarket these services, created new pipelines of claim data from providers to health plans that altered the data so that both the provider and the payer could leverage their existing systems without the health plan taking the step of developing, deploying and supporting the direct transmission of a HIPAA complaint transactions with providers.
These clearinghouses made it easy for health plans to perpetuate their complex legacy adjudication systems using the same data they were used to, avoiding rebuilding these systems from scratch. From a legal standpoint, the electronic claim transaction is considered legal and compliant as long as it is in the 837 format at some point during the process. It is not required that it be delivered to the health plan in the same format that is created by the provider. For this reason, these transactions, although they may support legacy processes and formats, are considered to be HIPAA compliant.
Over the last ten years, clearinghouses have been able to accommodate and convert more health plans dependent on paper processing to this electronic process that replaces their paper front end with an electronic alternative that allows the payer to extend the life of these legacy systems.
It is also true that during this time, large health plans like the Blues, Cigna, and Aetna, have developed true HIPAA compliant systems capable of accepting these claims directly and interacting with provider systems. This was the natural result of large health plans determining that the investment required to replace their legacy systems with new compliant systems was less than paying the ongoing service fees associated with the clearinghouse alternative.
The main driver for compliance for claims submission has been the healthcare provider. Without being able to produce a claim that will be paid insurance, specifically large health plans, they would not be able to collect their revenue. This meant that almost any investment toward this purpose was worth the cost. However, it has been the efforts of the clearinghouse industry deploying payer solutions for this HIPAA compliant provider claim pipeline that has pushed the adoption rate for claims transactions far above the rates for the other transaction types. The adoption rate for claims is high, but the growth rate is low, suggesting that we will probably never hit 100%, but we may get up around 95% over the next few years. I, for one, could live with that.
Like claims, Medicare leads the way in HIPAA compliant transactions of this type. Medicare maintains the HETS (HIPAA Eligibility Transaction System) that allows any CMS authorized submitter to conduct eligibility transactions through the HIPAA 270/271 format:
Unlike the claims transaction, eligibility checking is not required to get paid. This transaction only improves the revenue collection process by verifying coverage of the patient. It is still optional.
This partly explains the adoption rate of this transaction being well below that of claims. Although this information is important, neither the provider nor the health plan consider it to be as essential as claims processing. For this reason, clearinghouses have been less successful in bridging the gap between provider and payer IT systems since this service is less valuable to both parties and there is not a common provider HIPAA compliant solution interface that they can build on.
The other issue holding back the adoption rate of this transaction type is a loophole exploited by health plans. If a health plan provides a portal (usually a secure web site) where they collect patient data and display eligibility information, this process is considered to be HIPAA compliant as long as the data they collect and display includes the required elements. This allows them to cheaply create a new front end to their systems that solves their problem of automation, but for the provider, the process is still completely manual and unique by health plan. During 2012 and 2013, according to this CAQH index, about 95% of health plans provided a standardized web portal to provide eligibility results. This means that under these circumstances any cost savings associated with the full automation of this transaction would benefit the provider only.
Although this transaction was mandated at the beginning of 2013, we see less than a 1% growth in the percentage of commercial health plans supporting this transaction in a HIPAA complaint manner between 2012 and 2013. If health plans actually planned to become compliant by that deadline, we should have seen a rise in this percentage as we approached the beginning of 2013 in 2012 data, as well as in the 2013 data included in this report. As long as the health plan’s automation problems are solved through their portal solutions, they have no motivation to make this additional investment.
This leads me to believe that without this process being mandated for all partners with some consequence for non-compliance, there is no reason to expect any significant growth in adoption rates for this transaction in the near future. This is confirmed by these statistics.
Like the other transactions, you would assume that both parties would be motivated to adopt this standard when compared to the alternative process of printing and mailing paper Explanation of Benefits (EOBs). Like claims, Medicare was the initial adopter of this technology. In fact, well before HIPAA was passed, Medicare provided electronic remittances using the ANSI 835 standard in an effort to reduce the expense associated with the paper process. Along with the file, they delivered free software to print these files at the provider site. The ANSI 835 was mandated as the only method of obtaining payment and adjustment data associated with a check, even before claims were mandated in the 837 format by CMS in 2003. So the mystery is why is the compliance rate for remittances so far behind claims?
Once again, it is the investment cost of retooling IT systems by health plans that is holding up this advancement. In addition to already having the tools to convert the 835 to paper, most provider patient accounting systems include the ability to import the 835 and convert the data into payments and adjustments against the individual accounts in the receivables. This eliminates the cost and inaccuracy of manual entry. The existing technology to process Medicare remits is identical to the process for any other health plan also using this technology. This means that like claims processing, existing provider tools can be easily used for processing the same transactions for other health plans besides Medicare.
From the perspective of the health plan, this is not data they have to read from a standardized format (the 837 claim file), this is a file that they have to produce and deliver to providers. There are no standards for paper EOBs. You can use any codes, descriptions or format you like. With claim data, clearinghouses were able to provide the service to health plans of converting standardized 837 data into a format compatible with their previous method of input. This was normally the previous NSF format or the image of the paper form. The technology to provide this service could be easily copied and modified to accommodate the specific needs of different health plan and their systems.
The remittance is very different. Each health plan’s remittance is unique with unique codes sets and layouts. There is no way to easily map this data into an 835. Any process developed for this purpose would not be reusable and portable to other health plans with different EOBs. This makes this process much more expensive and less attractive for the clearinghouse industry and other vendors that attempt to convert these paper documents to electronic transactions. This means that unlike claims, the HIPAA compliant solutions will need to come from the health plan IT systems themselves and are less likely to be provided through some type of “bridge” between the paper and electronic solution. This is what is keeping the adoption rate low.
The encouraging aspect of this transaction is that the adoption rate grew much more for this transaction than the others (3.7% from 2012 to 2013). This indicates that the ceiling for adoption rate for remittance transactions may be much higher than eligibility. A key factor contributing to this growth is the presence of the CAQH EnrollHub service. This utility collects enrollment information from providers and simultaneously enrolls them with many health plans at once.
Many of the issues related to the lack of adoption of these transactions is that health plans and providers have no way to reach out to each other and get these connections established. Medicare has the Medicare Contractor administration system that distributes information to providers and supports and implements their IT services. Health plans need to invest in the distribution and support of these services to providers. In most cases, they do not have the volume and experience to support these efforts.
Through utilities like EnrollHub, other services could be distributed and supported by networks outside of the scope of providers and health plans. Some clearinghouses are trying to fill this niche by establishing and marketing these connections similar to their claims processing model, but there may be other opportunities to connect these systems directly or support them as these transaction standards become more common.
By Kalon Mitchell – President, MEDTranDirect