The most important overall finding in the September report may be that the FDA’s current statutory authorities do not allow it to implement a program based on the working model of the precertification pilot. The FDA stated that the required new statutory authorities would supplement rather than replace the established regulatory pathways, although no further details were offered. This question of statutory authorities was raised by three members of the U.S. Senate in 2018, who also asked whether the precertification concept would have led to an impermissible reduction in user fees collected by the agency.
Lack of Regulatory Firewall an Issue
Two other issues with the pilot were that the FDA was able to enlist only nine participants, and that the use of the de novo program as a model for review of the pilot devices had unintended consequences. Chief among these is that the special controls created by the de novo review process would have applied to devices outside the pilot due to the absence of a legal and regulatory barrier. As a result of these two sets of limitations, the pilot was limited to a narrow group of devices that do not reflect the range of devices that would by regulated under a fully implemented precertification program.
The software precertification program is designed to leverage a demonstrated culture of quality and organizational excellence, which consist of five elements. These are demonstrations of:
- Excellence in product quality, including sustained quality;
- The ability to provide a safe experience for patients;
- Clinical responsibility, including clinical evaluations, labeling, and human factors engineering;
- Cybersecurity excellence; and
- A culture of proactivity with regard to product surveillance, user needs, and continuous learning.
The program would employ a total product life cycle (TPLC) approach, which would commence with the demonstration points listed above. This would be followed by a review determination, a streamlined review and a demonstration of the continued safety and effectiveness of the device by collection of data on real-world performance. A specific software device or version of a software device would not necessarily be subject to FDA review under this paradigm, a determination that would be made by the developer.
There are two levels of certification, one of which allows only low-risk products to market without review and the second allowing the developer to put low- and moderate-risk software to market without review. However, the pilot’s mechanisms for evaluating the organization’s commitment to the principles might not have provided the needed assurance that even relatively low-risk devices could have been safely placed on the market without direct FDA review. Both clinical performance and cybersecurity were central to the agency’s concerns in this context. The solution to this issue could be the application of an adaptation of quality management system (QMS) principles along with the application of general and/or special controls that would allow some, but not all, of the developer’s products to market without a formal review. Again, however, details were sketchy.
Analytics Plan Required to Assess Real-world Performance
The working model of the precertification program describes the postmarket surveillance activities that would be necessary to implement the plan, consisting of three categories of real-world performance analytics (RWPAs). These analytics could draw on data generated by the devices themselves and by device registries, data commons, and other sources of electronic health information. We will leave aside the question of the cost of collecting and analyzing these data other than to state that those costs might be prohibitive for a small developer, who may be better off going through the 510(k) or de novo program. In any case, the three primary components of an RWPA toolkit are:
- Real-world health analytics (RWHA), which would track device performance for clinical performance and use errors;
- User experience analytics (UXA), which may include passive monitoring of use patterns, download rates, and user retention rates; and
- Product performance analytics (PPAs), which may require proactive surveillance to address issues such as cybersecurity problems.
The emphasis on the TPLC in the software precertification concept is found in other programs at the FDA, such as the TPLC advisory program (TAP), which was incorporated into the new medical device user fee program, MDUFA V. There seems to be little immediate interest in Congress on the kinds of statutory authorities the agency would need to implement the software precertification program, so it may be safe to assume that the concept is out of play for the time being.
The problem that drove this pilot program has not gone away, however. The FDA still needs a more efficient method to deal with the volume of SaMD applications it receives annually, including 510(k) submissions for SaMD that represent only a modest change from the predicate device. The predicament is even more onerous for SaMD that incorporates machine learning, although a guidance on change control would provide some relief for these products.
Unfortunately, a draft guidance for software change control is listed as a B draft guidance priority for fiscal year 2023, which when combined with the outcome of the precertification pilot suggests that both developers and the FDA will be stuck for the foreseeable future with a regulatory framework that forces an iterative and cumbersome review of adaptations to SaMD.
