The Office of the National Coordinator for Health IT’s plans to change the ONC Health IT Certification Program has sparked some important questions. Wouldn’t allowing vendors to now simply say they're in compliance, rather than prove it in an ONC-Authorized Testing Laboratory, pave the way for EHR vendors to essentially flout the rules? And what’s to prevent more certification problems such as the eClinicalWorks $155 million settlement?

Or as Andre Thenot tweeted Thursday, "ONC switches to pinky-swear instead of actual compliance testing. #whatcouldpossiblygowrong."

ONC switches to pinky-swear instead of actual compliance testing. #whatcouldpossiblygowrong #HealthIT #EHR https://t.co/BgFh63AY1d

— André Thénot (@athenot) September 21, 2017

But National Coordinator Donald Rucker, MD, said ONC wasn't sacrificing any of its regulatory oversight but was simply doing what it could to reduce the hoop-jumping required of vendors so they could better allocate their resources to more usable and interoperable products.

"What we're trying to do here is make things as smooth as possible in the regulatory process," Rucker said Thursday during a call with reporters. "We're not changing the certification requirements, per se. We're doing a little bit of streamlining on the process. So that will hopefully, in part, reduce vendors costs – and in a market economy over time some of those savings come down to providers."

With the new rules, compliance requirements remain the same as ever, according to ONC. But now, rather than vendors having to put in the work to demonstrate, for instance, a relatively simple functionality such as CPOE for medications to a test lab, they can simply affirm that their product does that task, while focusing more of their time and energy on innovation.

But didn't the eClinicalWorks case show that sometimes a verbal promise isn't good enough? And that sometimes more stringent testing – showing, not telling – is necessary?

Rucker doesn't think so.

"The reality is that these are very public products," he said. "They have user bases who immediately know if something is working or not working. If a CPOE doesn't go through, these things are known almost instantaneously. So the vast bulk of the oversight is provided by those using the product. This has to be looked at in the broader context of use. That's where the data was coming from in prior enforcement actions."

Actually, he said the eClinicalWorks case is "a perfect example that what we have in place in fact does work."

The discrepancies with eCW's products were first "noted by end-users," he said. That case was ultimately investigated further thanks to reactive surveillance – not the randomized surveillance that would be reduced as part of these new rules.

ONC still fully intends to take an aggressive approach to reactive surveillance. In fact, just this past month it updated its Health IT Feedback Form, making it easier and more intuitive for providers to approach the agency with complaints or concerns about their products.

"Our experience is that people will report if there are issues with their product," said Rucker.

He emphasized that all certification criteria are still in place and enforceable. And he said he didn't see much changing for ONC-Authorized Certification Bodies and ONC-Authorized Testing Laboratories.

The self-declarable criteria are all relatively basic functionalities, after all. Those that require conformance testing to interoperability standards are still being affirmed by ONC-ATLs.

"There are a lot of things that are still being tested," he said. And even for those criteria that are now self-declarable, "you still have to know how to solve the equation. It doesn't change what you have to learn."

In other words, even with the new rules, when a product is certified, the vendor is attesting that it does what it's supposed to do. If that's later found out not to be the case, either by an ACB or through subsequent reactive surveillance, ONC will take action – correcting where there is a non-conformity or even decertifying a given product.

The bulk of certified technologies "do exactly what is asked of them from the certification criteria," said Rucker. "Building medical software is a highly iterative process. And there are many inputs on this. Because these foundations tend to be so heavily used – minute in, minute out – things become obvious relatively rapidly."

The aim here, said Rucker, is to "increase the operational efficiency of the vendors to the extent that we can. Because those (testing) costs are all eventually, sooner or later, borne by the providers purchasing the products."

Twitter: @MikeMiliardHITN
Email the writer: mike.miliard@himssmedia.com