By JACOB REIDER, MD

UPDATE:  Here are the public records for the case.  More details there about the original complaint.  Excerpt:

What we’re talking about

The purpose of any certification program is to create a method for the purchasers of a product to have confidence that the product safely and reliably does what it is supposed to do.  One example from USDA:

Turning Point for Meat Inspection  In 1905, author Upton Sinclair published the novel titled The Jungle, taking aim at the poor working conditions in a Chicago meatpacking house. However, it was the filthy conditions, described in nauseating detail—and the threat they posed to meat consumers—that caused a public furor. Sinclair urged President Theodore Roosevelt to require federal inspectors in meat-packing houses.The Pure Food and Drug Act and the Federal Meat Inspection Act (FMIA) became law on the same day in 1906. The Pure Food and Drug Act prevented the manufacture, sale, or transportation of adulterated or misbranded foods, drugs, medicines, and liquors. The FMIA prohibited the sale of adulterated or misbranded meat and meat products for food, and ensured that meat and meat products were slaughtered and processed under sanitary conditions.

In this case, the government moved to protect the public because a subset of meat packers was putting profit above public health.  After The Jungle was published, public outcry caused the government to step in and regulate the industry.  Regulation is not, therefore, a four letter word.  It’s there to protect us from evildoers.

Before Health IT Certification

You may not remember this, but I do.  Before there was certification, Health IT development companies (some people call them “vendors”) created software and sold the software with claims of improved provider productivity, improved public health, and (yup) improved billing (among other impressive capabilities). Sometimes these claims were completely valid.  Sometimes they were not.  In the case where the developers’ functional claims were not quite valid, buyers had little recourse.  One might say “well, the markets will take care of that.  Bad actors will lose sales.”  But that’s not the case here for several reasons:

1. The buyer may not be the one using the software.  A hospital buys software for clinicians.  Clinicians complain to hospital.  Hospital may or may not be a strong advocate with developer.
2. It’s very hard to migrate from one system to another.  EHR purchase / deployment / optimization is a multi-year initiative.  If you bought a lemon, you may try to make lemonade as the though of migrating to something else will give you R11.0.
3. Shame.  You don’t want your patients / competitors / peers to know that your EHR doesn’t work as expected.  You made a mistake.  Human nature is to hide our mistakes rather than treasure them as educational opportunities.

After Health IT Certification

The program isn’t perfect.  I was on the developer side of this work from ~2006 – 2010 during the when CCHIT was the only certification path, and then for ONC’s first iteration of certification (2010 – 2011).  Indeed, the imperfection of the program was a motivating factor for me to join the government in 2011.  I wanted to help evolve the program toward perfection.  Certification criteria needed to be less prescriptive (more flexible) but still provide sufficient guidance/ structure so that they could be reliably tested and replicated.  This balance is hard to get right.  Sometimes we got it wrong.

Some have appropriately argued that there remains quite a bit of “check the box” busywork wherein health IT developers need to spend time building and configuring their software just to have it certified.  “Trust us and don’t make us do this busywork” was the persistent message from the developer community.  Recently, there have been renewed calls for scaling back the certification program and its many criteria, citing the maturation of the EHR incentive programs (meaningful use) and the fact that some of the certification criteria define capabilities that are not invoked by the incentive programs.  The argument is that ONC has no place creating certification criteria for capabilities that aren’t part of “meaningful use.”   I disagree.  The ECW case is a great example of why I disagree.

About the eClinicalWorks settlement

What happened?  You’ve read the press release from the Department of Justice by now.  Excerpts (my emphasis added):

In its complaint-in-intervention, the government contends that ECW falsely obtained that certification for its EHR software when it concealed from its certifying entity that its software did not comply with the requirements for certification.For example, in order to pass certification testing without meeting the certification criteria for standardized drug codes, the company modified its software by “hardcoding” only the drug codes required for testing. In other words, rather than programming the capability to retrieve any drug code from a complete database, ECW simply typed the 16 codes necessary for certification testing directly into its software. ECW’s software also did not accurately record user actions in an audit log, and in certain situations did not reliably record diagnostic imaging orders or perform drug interaction checks.In addition, ECW’s software failed to satisfy data portability requirements intended to permit healthcare providers to transfer patient data from ECW’s software to the software of other vendors. As a result of these and other deficiencies in its software, ECW caused the submission of false claims for federal incentive payments based on the use of ECW’s software.As part of the settlement, ECW entered into a Corporate Integrity Agreement (CIA) with the HHS Office of Inspector General (HHS-OIG) covering the company’s EHR software.This innovative 5-year CIA requires, among other things, that ECW retain an Independent Software Quality Oversight Organization to assess ECW’s software quality control systems and provide written semi-annual reports to OIG and ECW documenting its reviews and recommendations. ECW must provide prompt notice to its customers of any safety related issues and maintain on its customer portal a comprehensive list of such issues and any steps users should take to mitigate potential patient safety risks. The CIA also requires ECW to allow customers to obtain updated versions of their software free of charge and to give customers the option to have ECW transfer their data to another EHR software provider without penalties or service charges. ECW must also retain an Independent Review Organization to review ECW’s arrangements with health care providers to ensure compliance with the Anti-Kickback Statute.

Summary:

1. ECW faked their certification testing.  The examples above are just examples.  There are other instances wherein ECW faked the testing and convinced the testing body that the software could do something that it could not do.
2. Since the software was not certified, any physician or hospital who received incentive money and attested to the use of certified software was in fact fraudulently attesting to the meaningful use of certified software.
3. The Corporate Integrity Agreement (CIA) commits ECW to:
   1. Oversight from an independent third party
   2. Notify customers of any safety risks (there are many)
   3. Provide software updates for free
   4. Support migration to other EHRs for free

So what?

Reminder:  The purpose of any certification program is to create a method for the purchasers of a product to confirm that the product safely and reliably does what it is supposed to do.

• ECW is a big company, with ample resources.  Their software is used by tens of thousands of clinicians every day.  The lives of their patients (many of whom are Medicaid beneficiaries – as many federally qualified health centers use ECW) depend on the safety and reliability of this software.
• ECW’s software doesn’t do what they claim.  Now that the government has investigated, and is holding them accountable, the message is clear:  the public’s interest is being protected.
• ECW is not the only organization that cheated on certification.  They may have been the biggest, boldest violator, but they were not the only one.  Others have already started internal reviews of their own performance, and those who have not yet done so are very likely to do so tomorrow.  This case is a wake-up call for the CEOs of all EHR development organizations to dig deep, and have honest direct conversations with the small teams that prepared the software for certification testing, and performed certification testing with the test labs.  My advice to these CEOs:  look these teams in the eye and ask “is the software that was tested exactly the same as the software that is available to all of our customers?”  In many cases, the answer is no.  As Farzad tweeted today, a very common case is in the domain of interoperability:  can the system exchange data as it was certified to do?  All too often, the answer, when we speak with the EHR developers, is “yes, if you pay us $$$ to enable that capability for you.”

Today’s announcement is the culmination of several years of work – all focused on protecting the public and holding a company accountable.   As I’ve asserted both privately and publicly, the regulatory infrastructure of EHR certification is important because sometimes there will be bad actors.  While the “good actors” may be inconvenienced and annoyed by processes that seem unnecessary, for such important elements of our nation’s health infrastructure, we can’t have government abdicate this responsibility.  With or without the incentives programs, or MIPS, or 21st Century Cures, there is a set of capabilities that these systems need to have, and for which they must be certified.  The breadth of this set of requirements, and the depth of certification testing for any criterion are the needles that must be threaded.  I’m confident that Don Rucker and the team at ONC can navigate the balance well.