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.

Examining the specific example of the ANSI 835, this transaction predates HIPAA by several years.  In the early 1990s, Medicare dealt with the tremendous costs associated with remittance processing.  As the country’s largest payer, they had to print and mail millions of paper remittances a year to document the payments and adjustments associated with a check.  Each document was sent to all health care providers, large and small.  When these documents were received, the transactions were manually posted to individual patient accounts and cross-checked using adding machines or calculators.

To defray the costs associated with paper, printing and postage, they worked with industry representatives and standards organizations to develop the 835 as an alternative to paper remittances.  When the file was available, they gave healthcare providers a free program that allowed them to view these remittances and print the data on their own.  Now, instead of printing these remittances and mailing them, they could produce the ANSI 835 and make it available for download so that providers could print the data themselves.

The road was bumpy in the beginning, but eventually the electronic process worked efficiently and provided some additional benefits beyond just saving money for the government.  Because remittances could be delivered directly to providers from the Medicare claim adjudication systems, remittance data was transferred to providers faster compared to the previous print/mail processing solution.  Forward thinking patient accounting system vendors developed software capable of automatically posting these transactions from the ANSI 835 directly into patient accounts.  This single advancement alone had a dramatic impact on provider cost and efficiency of posting of payments and adjustments from Medicare.  Larger healthcare institutions often had many individuals whose entire career was dedicated to the never-ending posting of these transactions all day, every day.

Not only was the cost of this labor eliminated, the accuracy associated with these transactions increased and the ability of revenue cycle managers to take the next step in billing and collections for these accounts was accelerated by days due to the mutual efficiencies gained from this transaction.

I believe that it was the financial gains achieved by both parties in this specific transaction that inspired the development of HIPAA Administrative Simplification standards in the late 1990s.  If these types of gains could be achieved with claims processing, eligibility, and claim status reporting, the administrative costs and efficiency for the entire industry could be significantly improved.

When HIPAA implemented the 835 as a mandatory industry standard for electronic remittances, the impact was minimal since CMS already adopted this standard and most other payers still sent paper remittances.  The problem with HIPAA was that although it required that everyone sending electronic remittances use the 835 standard, it did not include any requirements or standards for paper remittances or require the use of the 835 instead of paper.  Consequently, providers who were benefitting from the efficiencies of this transaction for Medicare could not expand these benefits to most other payers.

The operating rules are designed to coerce the remaining stakeholders into participating in the electronic transaction standards.  This applies almost exclusively to payers since most providers have had this capability for quite some time.

On 1/1/14, all payers are required to provide an 835 to any provider that wants one.  If a provider would prefer paper remittances, they are supposed to provide them as well.  It is the provider’s choice.  The same is true for check verses EFT.

When this happens, it should have a similar impact on remittance processing that occurred in the 1990s.  Now, each provider, especially large ones, can build revenue cycle management processes built around the assumption that each remittance will be available as an 835.  This means that with the proper vendor system updates, it will no longer be necessary to manually post ANY insurance payments.

In addition, the 835 contains a wealth of revenue information that can be used for data mining and profitability reporting.  Each account paid through the 835 transaction contains the charges as well as payments and adjustments.  With the proper reporting tools, this data can be used to identify denied claims, determine the payment/charge ratios by department or specific services, and to verify data in cost reports and payer contracts.  If you need a tool to analyze this data, you might want to check out our 835Direct database reporting tools.

Our next article will discuss some additional benefits associated with the 1/1/14 operating rule deadline and what they might mean for your organization.

By Kalon Mitchell – President, MEDTranDirect, Inc.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s