Health IT Certification: When It Goes Wrong

This post will discuss what constitutes a product’s nonconformity with the Office of the National Coordinator’s (“ONC”) Health IT Certification Program, and what the consequences look like. Certification covers product capabilities that include data capture, structuring charts, e-prescribing, information exchange, analytics and reporting. The certification criteria for any specific capability may include requirements or required functions, implementation guidelines, and technical specifications. It also includes certain corporate behaviors: specifically certain transparency obligations and a commitment to abstain from information blocking.

The ONC defines a nonconformity as the “failure of certified health IT or of a certified health IT developer to conform to a requirement of the Program.” In its guidance to certifiers, ONC provided a host of factors to include when considering whether a product contains a nonconformity, starting with a gap analysis between the criterion’s requirements and the product’s capabilities, customer expectations, deployment settings, among more. It is a very fact-based inquiry, and you can find more information from the ONC’s program policy guidance entitled Post-certification Assessment of Program Requirements, which is accessible at the following link:

https://www.healthit.gov/topic/certification-ehrs/onc-health-it-certification-program-guidance

In the event you discover a potential nonconformity as a developer, there are several paths you might take. The first is to make sure that what you are looking at really is a nonconformity, and have the work crosschecked (please do not rely on just one SME). This is tricky stuff because the certification program can be confusing. By way of example, Medicaid and Medicare use different measurement periods to capture when a patient receives patient education. Requirements also change annually. You’ll research each issue a little differently because the universe of materials that control are different from capability to capability.

When starting, nail down exactly which criteria are implicated, what different standards and implementation guides support the criteria, what is called for, and what your product delivers. It is also important to confirm whether a single issue may affect multiple criteria. For example, an issue with C-CDAs will affect your interoperability criteria, as well as several of the “automated measures” that providers report on in Promoting Interoperability. When thinking about “do I have a certification problem,” here some helpful resources:

1. Code of Federal Regulations. I’m a lawyer and this is where I start. The certification criteria are codified here.
2. Federal Register. The proposed and final rules contain a ton of relevant commentary that can shed light on vague terms.
3. Measure specifications. These are 5-6 page documents that the Centers for Medicare and Medicaid Services (“CMS”) publishes which spell out exactly how to calculate a quality or Promoting Interoperability measure. You can find them at qpp.cms.gov, ecqi.healthit.gov, or at https://www.cms.gov/regulations-guidance/promoting-interoperability/20202021-program-requirements-medicaid.
4. The Quality Data Model governs how to calculate quality measures in general. https://ecqi.healthit.gov/qdm
5. The ONC Certification Companion Guide. https://www.healthit.gov/topic/certification-ehrs/2015-edition-test-method
6. The eCQI Resource Center. https://ecqi.healthit.gov/tool/onc-project-tracking-system-jira
7. ONC Program Policy Guidance. https://www.healthit.gov/topic/certification-ehrs/onc-health-it-certification-program-guidance
8. The criteria’s test procedure or test tool, which you can find for any product at https://chpl.healthit.gov.

If you do have a certification issue on your hands, there are several things that will play through. You must report it to your certifier essentially as a limitation of the product. From there, the certifier will determine: 1) whether there actually is a nonconformity, and if so, 2) what the appropriate remedy is. In the vast majority of circumstances, the certifier will place the developer under a corrective action plan (“CAP”) through which the developer commits to fixing the problem. While under a CAP, a product can still be sold and marketed as certified EHR technology. During the remediation process, the developer reports on progress to its certifier, who in return reports to the ONC.

If the issue is severe enough the certifier (or ONC for that matter) may suspend the product’s certification, which means that it remains classified as certified EHR technology but cannot be sold. In really bad cases, the product’s certification will be terminated. The very last penalty is a certification ban where the implicated corporation can longer certify any product under the ONC’s program.

There are two other big considerations when addressing a certification issue: your customers and the federal government. As a matter of course during the CAP, you will notify your customers of the issue. But if the certification issue presents limitations that impact something that is time-sensitive, like patient care, then you have a need to move ahead of the CAP process and contact your customers very quickly (think 24 hours when dealing with patient safety issues). If it is something that clearly impacts their ability to report reliable data to the Government as part of a physician payment program like MIPS, you need to notify your customers of the limitations before they start reporting (or immediately if they already have). If your product’s data is wrong, and you know it’s wrong, and you fail to tell your customers it is wrong and they give it to the government, don’t be surprised when the False Claims Act comes knocking.