The Double Standard for Healthcare Data

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.

Continue reading

Preparing for the Transition to Value-Based Payments

One thing I have learned over my 30 years in healthcare IT is that our industry will fight against change with its last breath, regardless of the logic or benefits of any new process that might be under consideration. ICD10 is the most recent example. It is simply a technical change in how one data element in healthcare patient information is recorded and processed.

Despite how it may impact the industry financially due to implementation costs and delays, it is a significant improvement in the quality of clinical data collected and a necessary step in the evolution of healthcare IT systems. The clinical and financial decisions that depend on the accuracy of diagnoses will benefit from the ability to establish new relationships regarding the effectiveness and cost benefits of different treatments plans. Once this new code set is established, new insights will be gained through this data that would not have been possible with the more general ICD9 codes.

Value-Based Payments

Continue reading

Last Minute ICD10 Testing Opportunities

CMS has finished the third and final round of end-to-end testing for claims containing ICD10 codes.  The tests results included an 87% acceptance rate of the claims submitted.  Only 1.8% of the claims were rejected because of the new codes, 2.6% were rejected because of invalid ICD9 codes.  These rejection rates are about normal for the current production claims processing environment.

The minor problems discovered by CMS in their system after round two of tests in April appear to be corrected.  On the surface it would appear that the industry, or at least CMS, is ready to process these claims, however, these statistics are deceiving.


Continue reading

Stagnation in HIPAA Adoption Rates

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 ( 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:

Claim Submission 2012 90.2% 2013 91.8% Change +1.46%
Eligibility 2012 64.7% 2013 65.3% Change +0.6%
Remittance Advice 2013 42.7% 2013 46.4% Change +3.7%

Continue reading

CMS Report Card on ICD10 End-to-End Testing

Medicare held a conference call yesterday (2/26/15) regarding the status of testing between Medicare provider systems, clearinghouses, and the CMS adjudication systems that will be used for processing claims with ICD10 codes in October.

Medicare has been ready for ICD10 for several years. Each quarter, they have updated their systems to prepare for the transition. Early this year, they ran their first live test that involved the processing of test claims submitted by volunteers through the entire adjudication process, including providing remittances.


This is referred to by CMS as “end-to-end” testing. This process allows the providers to test their processes including coding with ICD10, the validity of their claim files, and the payments and adjustments returned for the services. It also allows CMS to fine tune their systems to make sure they are ready in October.

There were 661 participating submitters that represented about 1400 NPIs. The tests were performed from 1/26 – 2/3. 14,929 claims were processed and about 81% were accepted. 6% had errors related to ICD9 or ICD10 codes, 13% had other errors not related to ICD10. Of these claims, 56% were professional, 38% institutional and the others suppliers, like DME. Continue reading

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.


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. Continue reading

Calculating the Potential Savings of Automating Administrative Transactions


The cost of processing administrative transactions associated with health insurance claims is part of doing business as a healthcare provider and a health plan.  During the last fifteen years, HIPAA has established standards for conducting many of these transactions electronically.  The Affordable Care Act introduced Operating Rules that are making these transactions mandatory for health plans when providers request them.  In 2013, the claim status transactions (276/277) and the eligibility transaction (270/271) became mandatory standards.  In 2014, the 835 electronic remittance and the EFT became available to any provider requesting them from a health plan.  In addition, the ACA requires that these payment transactions occur within three days of each other and that standardized codes are used for certain types of adjustments and remarks. Continue reading

Implementing the ERA and EFT Operating Rules

In earlier articles, we talked about the upcoming implementation of the ACA-mandated EFT and ERA Operating rules that will require payers to make available to providers ANSI 835 electronic remittances and EFT procedures for payment processing.  We talked about the benefits of implementing these processes into your revenue cycle workflow to address the problems associated with paper remittances and checks.

Now that this deadline is approaching, providers should be developing a strategy for implementing these processes with payers who currently conduct these transactions on paper.  This begins with getting a list all health plans you do business with and importing this data into a spreadsheet.  Record which ones use paper or electronic remittances and which ones use EFT or checks.  Your goal should be to get everyone switched to the electronic alternative for each transaction. Continue reading

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. Continue reading

Leveraging Operating Rules to Improve the Remittance Posting Process

As I discussed briefly in a previous article, the Affordable Care Act (ACA) includes regulations to implement operating rules for transactions previously defined as industry standards.

These include the HIPAA transaction used by CMS and other major payers to provide detailed payment and adjustment information associated with checks or Electronic Funds Transfers (EFT). This electronic remittance standard is referred to as the ANSI 835.

The ACA defines “operating rules” as “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications.”  In other words, the standards, like the ANSI 835, regulate the structure and content of the data being exchanged between two healthcare industry stakeholders, typically a payer and provider.  These operating rules deal with enforcing the use of these standards among all covered entities so that benefits can be achieved by building administrative systems depending on the universal existence of these transactions, delivered in a standardized manner. Continue reading