Two years after the FDA promised to release a draft guidance for change control for artificial intelligence (AI) software, the agency finally came through with a document that, at a minimum, gives developers a window into the agency’s thinking about this class of software as a medical device (SaMD). Several features of this draft suggest companies will have to do a significant amount of work in the premarket phase for development of a predetermined change control protocol (PCCP), making the development process potentially lengthier and more expensive.
Our goal here is to provide a high-level overview of the draft guidance, and we’ll follow-up with a more in-depth analysis in a subsequent blog post. To start, the draft guidance focuses principally on machine learning (ML) device software functions (DSFs), or ML-DSFs. Algorithms that are manually and automatically updated are both within the scope, as are applications under the 510(k), PMA, and De Novo premarket programs. An application for a 510(k) device that is covered by a PCCP can recite a predicate with a PCCP, but only the original version of the device and not any versions that were modified under the PCCP.
Improved Device Safety or Effectiveness May Not Require New Submission
A PCCP allows the developer to make changes or allow changes to the function of the algorithm without a new regulatory submission, even changes that could affect the device’s safety and effectiveness, so long as those modifications were included in the PCCP. This is a significant difference from the typical expectations of SaMD, as any changes that could affect the safety and/or efficacy are often enough to force a new regulatory filing. Without a PCCP, the developer would have to consider the need for a new filing per the 2017 FDA guidance for software 510(k) changes, which stipulates that even a change intended to improve the safety and/or performance of the device would require a new 510(k).
There are three types of acceptable planned modifications to an AI or ML product, which are modifications that are:
- Related to quantitative measurements of the ML-DSF performance specifications (such as would improve analytical/clinical performance);
- Related to device inputs (such as new data sources from a given signal type); and
- Related to device use and performance, such as would allow for use within a specific subpopulation (although this would be only a limited set of modifications).
All modifications must retain the device’s original intended use, which applies to the indication for use as well for the time being. There is little discussion of risk management, and it is not clear whether the FDA believes that any risks that are associated with a self-modifying PCCP follow a probabilistic model, which may determine the applicability of ISO 14971.
Social Harm a Concern for Risk Mitigation
The developer should document its controls for risks related to algorithm update procedures, including the potential for new, unmitigated risks. One of the more unusual passages regarding risk states that the impact assessment for a PCCP should discuss the risk of social harm, a term which is not defined in the draft.
The documentation requirements for a PCCP should include a section that traces the impact of modifications to the four components of a modification protocol, which are data management practices, algorithm retraining practices, update procedures, and performance evaluations. Another critical section of the draft is the section listing the goals of the modification protocol, which include:
- Identification of the methods and data used to develop, validate, and implement all proposed modifications;
- Identification of the test methods, data, statistical analyses, and acceptance criteria for the proposed modifications;
- Assurances that the manufacturer will generate and retain any information that would be disclosed to the FDA in a new regulatory submission for each potential modification had that modification been undertaken without a PCCP; and
- Ensure that the application be least burdensome for FDA reviewers to evaluate by ensuring the traceability of the modifications to the four components of a modification protocol as listed above.
The draft states that the four listed components of a modification protocol may not be sufficient for all applications, but any proposed modifications that are not adequately supported by the modification protocol may be removed from the PCCP. We assume the sponsor would be afforded the opportunity to amend the filing to address any related concerns on the FDA’s part, but we would advise our clients that this is a potentially ripe area for first review cycle refusals.
Given the agency’s emphasis on how these impact assessments affect risk management, it seems likely that FDA reviewers will closely scrutinize these assessments during application reviews.
The impact assessment for a PCCP is another area in which the sponsor will be required to extensively document its activities, and the draft states that this should be conducted under the manufacturer’s existing quality system. Obviously, any failure to document the impact assessment activities may raise a red flag for FDA staff during an inspection or virtual audit.
The impact assessment should compare the modified version of the device with the unmodified version, but there appears to be a need to account for the accumulated effect of multiple modifications. The assessment should also account for the impact of each modification on the implementation of other modifications, and for the net impact of all the planned modifications.
Given the agency’s emphasis on how these impact assessments affect risk management, it seems likely that FDA reviewers will closely scrutinize these assessments during application reviews, particularly given that the assessment exercise should also examine the impact of modifications on overall device functionality, including any hardware components. The task grows yet more complicated if the ML-DSF is only one of several device software functions, in which case, the manufacturer/developer is advised to consult with the July 2020 guidance on multiple device functions.
In our first look at this draft guidance, it’s clear that development of a PCCP will be quite demanding. We’ll follow-up with a more in-depth analysis shortly, in which we’ll take a closer look at some of the more critical details of how a development process can move forward with this draft guidance in mind.
