Software as a medical device (SaMD) has evolved rapidly in the past 20 years, and the FDA has responded with a new final guidance for the content of premarket submissions for device software functions. This guidance calls for a substantially greater amount of documentation than was required by the 2005 version — an especially important point for companies that file infrequently with the FDA.
The 2005 version of the guidance applied to PMAs, 510(k)s, investigational device exemptions, and humanitarian device exemptions. However, the scope of the new guidance has expanded to include De Novos. Despite their omission in the 2005 guidance, we suspect de novo applications have been informally subject to these software policies. However, the scope now includes some products reviewed as biologics license applications (BLAs) as well. These include products such as blood establishment computers and automated blood cell separators, one of which was cleared in December 2022.
Levels of Concern Rejected for Levels of Documentation
The 2005 guidance used a three-tiered levels of concern (major, moderate, and minor) approach to documentation requirements, an approach the agency disposed of in the November 2021 overhaul. The November 2021 draft and the June 14 final guidance use a two-tiered approach to documentation — the basic and enhanced levels of documentation (LoDs). These two levels are applied across several areas, such as software design specifications. Perhaps the most helpful part of this final guidance is the series of examples that gives applicants a better understanding of what will be expected in these applications going forward.
The content of the draft guidance is somewhat reorganized in the final guidance, such as in the discussion of the LoD requirements. The draft guidance states that a basic LoD is appropriate unless one or more of the conditions in the enhanced level apply with little additional detail. The draft’s requirements for an enhanced LoD are that the device:
- Is part of a combination product;
- Is used in connection with blood and tissue donations;
- Is a class III device, typically requiring a PMA filing; or
- Presents a probable risk of serious injury or death to the patient, the user, or others in the environment of use due to a failure or latent flaw of the device software function(s).
The final guidance is less explicit about the scenarios in which an enhanced LoD would be required, and instead offers several guiding principles. The primary principle that elevates the LoD to enhanced is when the sponsor determines that a device software function would create a hazardous situation with a probable risk of death or serious injury in the event of a failure or flaw of that software function or functions.
Details Regarding Software Architecture Now Compulsory
In both the basic and enhanced LoD, the application should include a thorough description of the system and software architecture. This would include a detailed diagram of modules, layers, and interfaces; a description of the relationships between these features; the data inputs/outputs; and how users or external products interact with the software. Both versions of the guidance exclude hypothetical risk from the definition of probable risk, but the final version oddly relegates this observation to a footnote.
While these two versions of the guidance largely mirror each other, there are several crucial differences other than those previously mentioned. For instance, the final guidance makes reference to predetermined change control plans (PCCPs) while the draft did not for obvious reasons (we recently explored the FDA’s thinking about PCCPs here). Another change is that the draft lists software to be operated on general-purpose computing platforms as within the scope while the final does not. Both the draft and the final cite other means for software-based control of medical devices, which may be presumed to include general-purpose computing platforms.
IMDRF Software Risk Framework Disappears Again
Another interesting element of the final guidance is that it omits the draft guidance’s mention of the software risk categorization framework by the International Medical Device Regulators Forum (IMDRF). This IMDRF framework was also removed from the FDA’s final guidance for clinical decision support products as well, as we described last year. The IMDRF risk framework was released in 2014, and so might be seen as obsolete, a possibility that seems confirmed by the IMDRF strategic plan for 2021-2025. The plan refers to risk on numerous occasions, including a statement of the need to manage new and evolving risks for devices of all types. The rapid development of artificial intelligence (AI) and machine learning (ML) software in recent years is likely one of the drivers of the IMDRF interest in a fresh examination of risk categories and risk management for software.
Both versions mention a benefit-risk analysis in their respective discussions of risk assessment, but the final guidance suggests that this be done “where applicable,” leaving a lot of leeway for interpretation. The draft seemed to suggest that a benefit-risk analysis is needed only to address residual risk, and only when these residual risks are deemed unacceptable in the risk management plan. This assumes that further risk control is not practicable, but the problem for developers is that the final guidance’s ambiguity on this point could prove troublesome.
Final Guidance Expands Definition of ‘Reasonably Foreseeable Misuse’
In both documents, the section on risk assessment offers recommendations for foreseeable risks, but the phrasing is different in ways that may be meaningful. The draft describes a need to identify and document all reasonably foreseeable software and hardware hazards associated with the device. This would account for both intentional and reasonably foreseeable misuse of the device.
The final guidance states that a risk analysis section of an application should identify known or foreseeable hazards and their causes. The manufacturer should also document reasonably foreseeable misuse whether intentional or unintentional, the latter of which is not discussed in the draft guidance. Also of interest for industry is that the sponsor is expected to document the reasonably foreseeable sequences or combinations of events that would result in a hazardous situation. This portion of the final guidance is replicated nowhere in the draft, and thus represents a substantial departure.
There are several examples of the LoD question in this final guidance, such as that a basic level of documentation is all that might be required for a commercial, off-axis, three-mirror, head-mounted display that superimposes pre-surgical images on a patient’s body. This would require only a basic level of documentation because the display would not be used by the lead surgeon and because the device is not intended to directly guide surgical planning or surgical procedures.
The key takeaway is to document everything, even if you believe your product will require only a basic LoD when you file with FDA.
Conversely, an enhanced LoD would be required for a retinal diagnostic software device because a failure or latent flaw could provide a false result that could present a risk of serious injury or death. The FDA’s concerns in this example probably revolve as much around false positives as on false negatives given the risks with the associated treatments.
The FDA will hold a webinar July 20 to explain how it arrived at some of the features of the guidance. While there are a number of other important details about this final guidance that we have not discussed here, the key takeaway is to document everything, even if you believe your product will require only a basic LoD when you file with FDA. Adverse events often trigger FDA inspections, and the last thing a manufacturer needs is a warning letter to add onto the bad news of patient harms associated with a device’s use.
