ONC EOA Final Rule: ONC Direct Review
This is a blog post in a series on our review of our Enhanced Oversight and Authority (EOA) Final Rule. Check out the others on our blog via the EOA tag.
Summary
The main focus on this Final Rule is the establishment of a regulatory framework to allow ONC to do a “direct review” or surveillance into the functionality of certified health IT. Previously, this was only the bailiwick of the ONC-ACBs, but ONC has now established themselves as an active participant in surveillance
As justification for involvement, ONC sites the Public Health Service Act (PHSA) which requires the ONC to perform specific duties related to the nation’s HIT infrastructure. The duties cover a wide range of health care, and ONC sites PHSA in providing authority for ONC to do direct review on “broad range of circumstances”. However, ONC indicates they will only focus on two sets of circumstances: 1.) when certified health IT causes or contributes to serious risk to public health or safety and 2.) when non-conformities that are beyond the resource or expertise of the ONC-ACB to do a thorough and proper investigation. The first area is outside of the authority of ONC-ACBs and the second area is one that is typically beyond their resources.
Direct review allows for ONC to initiate surveillance activities, and the process has some similarities to how an ONC-ACB currently conducts surveillance. The normal ONC-ACB surveillance process starts with the notification and investigation stage. If a non-compliance is found, the developer must submit its corrective action plan (CAP) identifying how it will remedy and correct the non-compliance. Developers will have a period of time to both submit the CAP and then work to correct the issue. Upon the non-conformity being addressed, the surveillance will be closed. If the non-conformity is not addressed properly, the certified health IT system will have its certification suspended and ultimately withdrawn or terminated. The developer has the right to appeal the withdrawn or terminated certification to the ONC-ACB and can be reinstated pending certain steps.
ONC direct review is very similar and has those same steps. However, they do add some very different and important wrinkles. One is noted above which is scope of surveillance, specifically on areas beyond the expertise or man-power resources of the ONC-ACB or the accreditation scope of the ONC-ACB.
Second is the idea of ONC suspension. Distinct from certification termination, if ONC believes the certified health IT poses a potential risk to public health or safety (e.g., creating unsecured patient health information, increasing medical errors, etc.), it would suspend the certification of the health IT immediately without an advanced issue of a non-conformance finding.
Third, ONC has created a Certification Ban. If an unresolved non-compliance results in a health IT product having its certification suspended, withdrawn, or terminated (by ONC or the ONC-ACB), the developer will be under a Certification Ban preventing any further testing or certification of any of their health IT products until they resolve their non-compliance.
Analysis
This definitely changes the government’s health IT program. ONC interjecting themselves into the program’s application is a major pivot from their previous work.
ONC states several times they expect direct reviews to be “relatively infrequent”, and we should believe them at this point. Looking at their cost projections, they project the high end cost for ONC’s personnel on the work of the inquiry and appeal process of a direct review to be nearly a quarter million dollars. While government certainly has financial resources, ONC’s yearly budget has been around $60 million the last several years. They truly can’t currently afford to do too many of these without major budgetary changes.
However, even the threat of doing one is worth paying attention. As you can tell by the rule, they have carefully considered how this will be done and why it is needed. What is most notable in reading this rule is the depths they go to explain themselves and walk through the problems they see. They reveal issues that can be best resolved through ONC direct review.
In the Scope of Review subsection, ONC goes through nine different examples or scenarios of realistic but complicated real-world health IT problems. You can find it starting at this link. It is about 20 pages with some comments/responses worked in, but this is some of the best regulatory work ONC has ever done. In these very plausible hypotheticals, they show their thinking process and ways they might establish direct review, when they would bring aboard the ONC-ACB for their surveillance, and situations they would determine do not need further surveillance. Their examples (hardware infrastructure limitations, ransomware attacks, etc.) illustrate surveillance problems that do not have the simple answers or straight forward solutions that automatically lend itself to the current surveillance work of an ONC-ACB.
It is hard to leave these examples without believing there is an important need being met by ONC interjecting themselves to do direct review. Beyond this section, they offer several detailed illustrations and vivid examples of what they mean. It is this effort which largely shows they have a solid understanding of the issues affecting health IT and how to engage them.
Of course, identifying a problem is not nearly as difficult as overseeing its resolution. ONC did not put forth examples of the same depth showing how they would be working with the developers on their CAPs to ensure the non-compliances are in fact resolved in a way that is fair to all parties. Coming previously from the world of an ACB, the ACB is very involved with the developer in this resolution stage. While the ACB does not actually do the work of the CAP, it is much more involved than just saying “here is a problem; go fix it and I’ll come back when it is done.” The developer generally wants confirmation of interpretations to ensure the solution they are proposing will suffice, and the ACB must often work in concert with the clinician and developer as issues are resolved. It is a time consuming effort, and one that requires some diplomacy. It will be interesting to see how ONC handles this aspect of surveillance.
The idea of an ONC suspension is probably what worries developers the most, and that is understandable. The chance that you will receive a suspension because your product has been labeled a risk to public health and safety could be crushing from a PR standpoint. We do not believe that is ONC’s intent. However, the reality is that this can be interpreted by the public as a negative comment on your health IT in comparison to other competitors and similar developers.
Their Certification Ban is a huge stick for them to wield. In issuing this ban, it effectively stops all certification and testing for the affected organization and its subsidiaries. It creates a huge ripple effect to that organization at multiple levels.
Going back to my experience as part of an ACB, I nearly always felt the developers took seriously the intention of having a safe and usable health IT solution that met the needs of their customers, and they took customer service seriously including handling of complaints. When a non-compliance was issued from surveillance, they responded quickly to these request and to resolve any problems for their customers. That said, developers should redouble their efforts to ensure their products are working to their customer’s needs and take a 2nd look at any complaints they have received, even if they initially do not believe it is attributed to their product. There is real risk at being identified in an ONC direct review, and the importance of surveillance prevention has increased.
