On October 25, 2017 the FDA released its guidance on "Deciding When to Submit a 510(k) for a Software Change to an
Existing Device". A draft of this guidance was released in August 2016 and I commented on that draft here. The scope of what was changed is not easy to discern, especially since the draft is no longer directly available and the URL for the final guidance is the same as that for the previous draft. No doubt there are many people who have a copy of the draft and the Wayback Machine might also be explored. But such a comparison might be moot anyway with respect to what the FDA is now telling us it expects manufacturers to do when changing software, but doesn't quite require them to do because guidance documents can't set requirements, except when they do.

This software guidance is a special case of the more general guidance on "Deciding When to Submit a 510(k) for a Change to an Existing Device"   which was also released on October 25th.   For this discussion I will focus on the decision making flow chart of the software guidance, which has been changed from the draft, at least in its more streamlined appearance.

The first question in the flow chart is whether the change is for cybersecurity only without any other impact on the performance of the software, and for embedded software the performance of the device. If the answer is "yes" then the change can be made without a new 510(k), and documented accordingly. If the answer is "no" then the next set of questions are triggered. Of course a "yes" answer might be wrong as was recently reported with respect to a pacemaker "update" aimed at correcting a security flaw that had actually not caused any incidents. It then turned out that the update itself could cause malfunctions, something that the manufacturer had noted with the updates release, and which subsequently came to pass. Thus the fix here was possibly worse than the original problem, causing some to question whether they should even undertake the upgrade.

The second question in the flow chart is whether the change is being made solely to return the system to the specifications of the most recently cleared device? In other words, the system doesn't do what it was supposed to do so now we are fixing it to make it do what it is supposed to do. If the answer is "yes", then again a new 510(k) is generally not required but, again, the decision needs to be documented beyond just recording a yes. The discussion of this matter also addresses missing, incomplete, ambiguous, or conflicting software requirements that may lead to updating specifications rather than changing the software itself. In other words, sometimes it is necessary to change the specification to match the software you have.

If the change is not solely for cybersecurity, or to restore the system to specifications, then a two part question follows. First, does the change introduce a new risk or modify an existing risk that could result in significant harm and that is not effectively mitigated in the most recently cleared device? Second, does the change create or necessitate a new risk control measure or a modification of an existing risk control measure for a hazardous situation that could result in significant harm? These questions are both steeped in risk management which inherently means not that risk is eliminated but that it is managed to an "acceptable" level, putting aside for another day the issue of acceptable to who. If either of these questions is answered "yes", then a new 510(k) is required. If the answer is "no" we move to question 4.

Question 4 asks if the change could significantly affect clinical functionality or performance specifications that are directly associated with the intended use of the device? Here the focus is on what the system is supposed to do which is different from the previous issue of what risks may exist in using the system for what it is intended to do. Examples given are attributes such as speed, strength, response times, throughput, limits of operation, reliability, delivery rate, or assay performance.  A "yes" here indicates that a new 510(k) is required. A "no" leads to the consideration of other "gray area" software factors with respect to determining the need for a new 510(k).

Change has always been challenging, and change in a regulated environment is even more challenging. Software is a technology for which we expect ongoing changes to be necessary and which we call "updates" rather than "repairs". The degree to which such frequent change is a result of sloppy design practices is not clear, but the consequences effect us every day.