Predetermined change control plans (PCCPs) may be the way of the future for 510(k) medical device software, but the vast majority of both hardware and software device products still do not incorporate a PCCP. As a consequence, the FDA’s existing policies for when to file a new 510(k) are still in effect, and this blog will provide a closer look at the related guidances.
The FDA has completed two related guidances, one of which governs changes to device software, regardless of whether the product is software as a medical device (SaMD) or software in a medical device (SiMD). The second is a parallel guidance for non-software device products, and there is a substantial degree of overlap between the two.
Failure to File Potentially Costly
Both guidances call for a new 510(k) filing when the indication for use has undergone a major modification or change, which is also the case for any other changes or modifications that could significantly affect the device’s safety or effectiveness. This is required by the regulation, but there are bound to be disagreements as to whether a change is meaningful enough to cross the threshold to a significant change. Regardless of whether one of these changes prompts a need for a new regulatory filing, the developer or manufacturer must document any and all such changes. Those changes must also be verified and validated if one wishes to avoid a warning letter on the following FDA inspection.
A failure to file a new 510(k) in these circumstances causes the product to be misbranded, a problem that has been cited in the three most recent FDA warning letters to device manufacturers (here, here and here). The potential consequences are very serious, including seizure and criminal prosecution.
The Unintended Consequence is a Regulatory Hazard
Both guidances list a series of activities that must be undertaken whenever a device is modified to help determine whether a new regulatory filing is necessary. These include:
- An initial risk-based assessment prior to implementation of the change;
- A consideration of potential unintended consequences;
- A consideration of whether a series of simultaneous changes might work in the aggregate to induce a need for a new regulatory filing; and
- An evaluation of whether the intended change combines with other changes undertaken since the FDA cleared the previous version of the device to suggest a need for a new regulatory filing.
Both guidances make reference to the need to use risk management principles to determine whether a new regulatory filing is necessary. Both guidances direct the manufacturer to ISO 14971 in this regard, but the software guidance also directs the manufacturer/developer to IEC TR 80002-1 as an additional source of both risk management information and risk terminology. The FDA states that software failures tend to be systematic in nature, which reduces the utility of traditional statistical methods in determining the probability of a software failure. If the overall probability of the occurrence of harm cannot be estimated, the software developer will have to base its estimate of risk solely on the severity of harm.
The initial determination that a new 510(k) is unnecessary should be verified and validated, but this outcome should be reconsidered if the results of verification and validation generate any unexpected results. Another point of some importance is that if a series of changes is contemplated, but only one of those changes would prompt a need for a new 510(k), the balance of the changes can be immediately acted upon. However, each of these other changes should be described in the filing for the change that requires a new 510(k).
New Filing Typically Not Needed for Cybersecurity Updates
There are several key differences between the two guidances, one of which pertains to cybersecurity features. This and other software-specific issues are depicted in a flowchart to ease the process of determining whether a new regulatory filing is required.
For example, if a change to a device is undertaken strictly to strengthen the software’s cybersecurity features, no new 510(k) is required, but the change must be documented. The same holds true if the change is made for the sole purpose of returning the system to the specifications found in the most recently cleared version of the device.
Conversely, a change that forces the adoption of a new risk control measure – or the modification of an existing risk control measure – would require a new 510(k) if the associated hazard could result in significant harm. It might also be helpful at this point to highlight a feature of both guidances that some in industry would find counterintuitive. Both guidances state that a new filing is likely to be required even if the change is intended to improve device safety or performance.
It is critical for software engineers to communicate with regulatory affairs staff about any planned changes.
This applies with the understanding that the improvement would have to significantly affect safety or performance, but software improvement programs could inadvertently cross this particular line. Consequently, it is critical for software engineers to communicate with regulatory affairs staff about any planned changes, as something as seemingly innocuous as code maintenance activities could prove problematic. There is also the scenario in which a device or device software was changed to enhance device performance rather than as part of a device recall. This predicament is the subject of a guidance that provides insight into the difference between actions undertaken in response to recalls as opposed to actions undertaken for the purpose of enhancing device functionality.
It is important to understand the difference between an improvement and a response to a safety or performance problem, as a failure to appreciate that difference is another source of compliance and/or enforcement action by the FDA. Granted, there is a substantial degree of ambiguity as the FDA’s recall-versus-enhancement guidance points out that neither the Food, Drug and Cosmetic Act nor the regulation provides a helpful definition of device enhancement. Although the term “enhancement” does not cover actions undertaken to remedy a violation of the statute or the regulation, it is not always clear when an enhancement to a user interface might constitute a significant change to the device’s performance.
Firmware, Hardware Changes Are Also a Source of Software Risk
In that vein, the software version of the 510(k) changes guidance states that a significant change could be related to performance specifications that may not seem directly related to the device’s intended use, such as speed of operation, throughput, and reliability. Consequently, it may be relevant to ask whether a change of firmware or hardware could impose a need to file a new 510(k) for the software product if that change has a significant effect on device performance. The software version of the guidance lists several types of changes that could trigger a need for a new regulatory filing, such as:
- Infrastructure changes (e.g., change of compiler, programming language, or software drivers/libraries);
- Architecture changes (porting software to a new operating system, extension of the operating environment of the device); and
- Changes to the core of an algorithm, such as may be used to trigger an alarm on an infusion pump.
Devices that incorporate both hardware and software are subject to what might seem a regulatory minefield when it comes to modifications, a perception that is not entirely incorrect. However, it is quite easy to go astray in this regard even if a device is composed solely of hardware or software, and the frequency with which this results in a warning letter underscores those hazards. If you and your team could use some expert support in how to navigate these decisions, be sure to reach out to our in-house consulting team, who can help ensure you’re on the right path.
