RAC Audits and EHR Software – Who Bears the Burden of Non-compliance?

A False Claims Act case pits a prominent health system against its EHR software provider.

Over the last many years, healthcare providers have been financially incentivized to purchase electronic health records (EHR) software. These programs can cost upwards of $25,000 to $50,000, and, sometimes are renewable every year. In other words, these programs are extremely expensive.

So shouldn’t these programs be compliant with all applicable federal and state regulations? The truth is, most programs are not created by physicians or attorneys. Many companies producing the programs do not even have attorneys review the software for regulatory compliance. Yet healthcare providers rely on these EHR systems to submit their billings to Medicare and Medicaid – and guess what? Complying with state and federal regulations as well.

This poses a huge risk for healthcare providers, because the next regulatory audit, such as one from a Recovery Audit Contractor (RAC), is as sure as death and taxes. One hundred percent of provider’s service notes or healthcare records could be noncompliant, based on the underlying software, and the provider would never know. If the provider is accused of failing to report a $1 million overpayment based on a flaw in the software, who bears the burden? The provider? Or the noncompliant software company?

Currently, the answer is this: whichever national provider identification (NPI) number is used is the “captain of the ship,” and thus is liable for any noncompliance issues. However, with providers getting smarter and more comfortable navigating the EHR world, many have begun to negotiate indemnification clauses in their contracts with the software companies and/or sue on the back end for indemnification, regardless of the contract terms and based on multiple legal causes of action.

Common compliance issues found with using EHR software include the following:

1. Electronic signatures

Simply typing the healthcare provider’s name at the bottom of a service note does not mean compliance with Medicare criteria has been achieved. You can look at the Medicare Program Integrity Manual, Chapter 3, for more guidance.

2. Self-populating entries

These are the “time-savers.” And they are indeed that. However, I have seen that some software programs default to the pronoun “he,” and without the healthcare provider going back and revising the note to say “she,” there will be gender pronouns that clash. These are red flags for auditors. Internal inconsistencies within notes or other medical records also present liability issues to auditors. The same is true of massive amounts of cutting and pasting.

An example of internal inconsistencies is the following: some computer software programs default to “patient presents without pain.” Then, later on in the service note, the healthcare provider writes “patient c/o of severe pain.” An auditor may deny payment with respect to that service because of inconsistent documentation.

3. Retrospective self-populating entries

Some EHR software is programmed to populate information not only prospectively, but retrospectively, which creates significant risk for providers. In one case, a provider did not realize that each time a diagnostic test result was entered, this information was auto-populated prospectively as well as retrospectively. Results from a February 2010 test were included, not only in subsequent notes, but in notes dating prior to the test.

4. Customization to a specialty

In some instances, the software template may include information that would rarely be relevant to a particular provider. For example, a software program may include a review of the gastrointestinal system when the provider is a hand specialist. As ridiculous as it sounds, regardless of the specialty, blanks – or the absence of information that could be perceived to be needed – can lead to denials in an audit.

Legal Liability

In a very recently initiated and ongoing qui tam action under the federal False Claims Act, a relator alleges that Bon Secours Health System, Inc., fraudulently billed Medicare and Medicaid by millions of dollars.

The allegations derive from the installation and use of a billing system known as “McKesson billing software.” McKesson billing software, according to the complaint, “from the very start … was deliberately programmed not to do split-billing.”

“’Split-billing,’ otherwise known as ‘Medicare maximization,’ involves ‘identif(ying) and bill(ing) any liable third party prior to … Medicaid,” The filing reads. 

Billing such parties prior to billing Medicaid is a requirement of participation in the Medicaid program. For patients eligible for both Medicare and Medicaid, or “dual-eligible patients,” this means billing Medicare before billing Medicaid.

The impetus for this requirement is that Medicaid typically reimburses providers for the full cost of a patient’s treatment, whereas Medicare reimburses at a flat rate lower than the actual cost of treatment. Thus, the government saves money when a provider bills Medicare first. If a provider bills Medicaid first for services provided to a dual-eligible patient, it violates the split-billing requirement. 

Again, the allegation in Bon Secours was that the billing system or computer program for the EHR was purposefully unable to split-bill, which violates Medicaid regulations. Notice, however, that the billing company in Bon Secours was not a named defendant. Why not? Even if the plaintiff did not name the billing company as a party in the complaint, Bon Secours could have filed a third-party complaint bringing in the billing company as a party to indemnify it.

The law is not clear on the issue of who bears the burden of liability for regulatory noncompliance when the noncompliance is caused by the billing software company and not the provider. Certainly, the billing software company will argue that it is the burden of a healthcare provider to follow all rules and regulations pertaining to Medicare and Medicaid when the providers signs the Medicare/Medicaid contact. Obviously, the billing software companies do not sign a contract with Medicare or Medicaid.

Going forward, we will keep an eye on the outcome of Bon Secours. Until then, I am of the opinion that there is a strong legal argument for indemnification of the provider by the billing software company.

To be safe, I recommend demanding an indemnification clause in contracts with billing software companies. They may buck, but if that is the case, then maybe that software company is not the right choice for you.