A ubiquitous characteristic of software is that it often undergoes numerous changes after it is first released for general use. These changes may be to fix things that were never right in the first place, or to provide new features and/or greater security. If the software is a “medical device”, or part of a medical device, or connects medical devices, then changes may come under the FDA's regulatory processes.

New Draft Guidance from FDA

A recurring question for software that is a medical device and which is actively regulated is when do changes to that software require a new 510(k) if Class II or a new PMA or PMA Supplement for Class III. For class II devices this has been addressed in a recent FDA Draft Guidance Document (DGD) entitled "Deciding When to Submit a 510(k) for a Software Change to an Existing Device". Note that when finalized Guidance Documents present FDA's thinking on a matter without officially creating a regulation or in principle an absolute requirement that the guidance be followed. Therefore a DGD presents what the FDA is thinking it is going to be thinking, after comments are reviewed and a final guidance issued.

The key rule covering change for Class II software is that a new 510(k) is required whenever there is a design change or modification that could significantly affect its safety or effectiveness. The FDA notes that no matter what you call a change (eg fix, update, tweak, patch, etc), it is still a design change. Now we just need to figure out  what "could" and and what "significantly affect" mean. Putting aside those questions for a moment, according to the DGD changes that affect only cybersecurity (and presumably positively) do not require a new 510(k). Besides possibly accelerating cybersecurity updates, this would also eliminate the false excuse sometimes heard from manufacturers that they can't fix something because the FDA won't let them.

Cybersecurity Impact

Of course a cybersecurity change raises the inevitable companion issue of unintended consequences which the FDA recommends as a general area of attention. This is also addressed as the need for care in making simultaneous changes. Other general considerations include the need for risk management in design and decision making, proper documentation, and the potential impact of cumulative change which can move the product further and further from what was originally cleared. When a new 510(k) is required that 510(k) should address all changes since the earlier 510(k) including changes that were concluded at the time to not need a new 510(k). In this way if cleared the clearance will catch up to the accumulated changes.

Besides cybersecurity, a software fix that is made to correct a deviation from the original specifications of the most recently cleared version also does not require a new 510(k).  This could be for example a recall fix. A different question occurs when it is desired to update the specifications to match the existing software. This too would not require a new 510(k). However it does reflect some generic problems in software design which has too often involved writing, revising and rewriting code as testing and loose specifications grow and evolve. This is epitomized in practices such as "spiral design" and "just good enough".

Risk Management

The next broad areas of concern are whether or not a change can alter, or create a new, hazardous situation that could result in significant harm and which has not been effectively mitigated. This is in part a risk management question since it is in risk management where the potentials for harm are supposed to be identified, analyzed, rated and where necessary assigned for mitigation. Here changes in mitigation may also trigger a new 510(k). Beyond direct harm, a further consideration is whether a change could significantly affect  clinical functionality or performance specifications that are directly associated with the intended use of the device?

Note here that the regulation of medical devices in general includes consideration of intended and indicated use, i.e., it is the product and how the product is labeled to be used that determine whether or not it is safe and effective. This issue has been the basis for much discussion about the promotion of off -label use, meaning saying a device is good for something other than what it was cleared for. With some clinical advisory software this raises the intended use question of whether software derived "recommendations" are different from "advice" or some other stronger noun. In this regard developers lean toward software output being recommendations, or even "suggestions", and the assertion that it is always up to the user to determine whether the recommendations are applicable. This becomes in effect a "do not rely on this product" instruction. Whether or not this conforms to how the product will actually be used remains an open question. An example here is image analysis software that carries the instruction that the software is not to be used until after a human analyst has made their own evaluation. One might wonder whether or not this is a realistic limitation.

Documenting Your Decision

A decision that a new 510(k) is not required results in a memo to file to that effect and the FDA need not be told of such a conclusion and the associated change. However the FDA may discover these memos during inspections or other regulatory actions, as may other third parties. A companion Draft Guidance Document focused on other than software changes for Class II devices spends some time on the quality and detail expected in a no-new-510(k) decision, emphasizing that it should contain more than yes/no answers to the FDA's suggested internal questions. Curiously that detail is not part of the software DGD.

Software has evolved as a product for which we have been taught to expect rapid change, sometimes to fix things that were never right in the first place, and sometimes to make things better, or at least to sell us something new. We also know that attempts to make things better have a perhaps surprising likelihood of making them worse, or at least of being disliked. In this regard I am fond of the terms "update" meaning to fix something that was never right in the first place, and "rollback upgrade" meaning stop using our new software and go back to the old version.

Software that is a medical device is regulated by the FDA, except when they choose not to. When such software is a Class II device it is subject to the requirements of the 510(k) process for initial marketing and for changes. The DGD discussed here, when and if it is ever finalized, will provide some guidance on when a new 510(k) is required as a result of changes to the software or its intended use.