The FDA has published a draft guidance describing the Agency’s expectations for the content of premarket submissions for medical devices that contain software functions. The new guidance, when finalized, will replace the current guidance, which was published in 2005. In summary, the new guidance is largely consistent with the current guidance with the exception of the following:
Given that the new guidance will have a significant impact across the medical device industry—from traditional devices with embedded firmware to digital health and digital therapeutics technologies to AI/ML-enabled software algorithms—below is a detailed description and my assessment of the salient points and the significant changes that have been proposed.
The scope of the new guidance largely remains the same as the current guidance. The new guidance applies to any “device software function”, including standalone software as a medical device (“SaMD”), software in a medical device (“SiMD”), software that are accessories to medical devices, and software that is or is part of the device constituent part of a combination product. The new guidance does not apply to automated manufacturing and Quality System software. The types of premarket submissions to which the new guidance applies include: 510(k)s, De Novo Reclassification Requests, PMAs, IDEs, HDEs, and BLAs.
In the current guidance, the FDA describes a “Level of Concern” (or “LoC”) analysis that “estimate[s] . . . the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use.” For each device software function, the LoC is categorized as follows:
The LoC analysis is unnecessarily complex and has several flaws. For example, the use of the term “could” in the definition of the LoC categories and the focus only on the severity of injury leave no room for considering the probability of a specific risk event occurring. Hence, if death or serious injury was even theoretically possible, the software should technically be categorized as a Major LoC. Likewise, rare is the occasion (if it would occur at all) that the FDA would regulate software that falls into the Minor category because software that is unlikely to cause any injury (even the most minor) if it were to fail is so low-risk that either the product would not meet the legal definition of a medical device or the Agency would not actively regulate it under its ever-growing enforcement discretion policy.
The new guidance replaces the LoC analysis with a Documentation Level analysis that simplifies the categorization of the software. The FDA proposes to effectively eliminate the Minor LoC category by identifying software device functions as “Basic” unless it meets any of the following “Enhanced” level criteria:
This new approach allows for consideration of probability such that only “reasonably foreseeable software and hardware risks associated with the device, including those risks resulting from intentional or reasonably foreseeable misuse” should be considered in the analysis. In other words, “purely hypothetical risks” or risks where the probability is remote should not be considered. The FDA notes that “reasonably foreseeable risks” include those related to the intentional or unintentional compromise of the device functionality due to inadequate cybersecurity. Based on this new approach, the vast majority of submissions involving software will land in the Basic level, and, hence, will be subject to the least burdensome documentation expectations.
Ultimately, under both the current (LoC analysis) and the new (Documentation Level analysis) approach, the category in which a software device function falls determines the type and depth of documentation that must be submitted as part of the premarket submission. The following describes the major changes in the new guidance relative to the current requirements for Major or Moderate LoC software:
Keep in mind that the Quality System Regulation (21 C.F.R. Part 820) as well as ISO 13485:2016, IEC 62304:2006/A1:2016, and ISO 14971:2019 require a significant amount of documentation that must be created and maintained as part of the Quality System for all software despite only a subset of the documentation being required as part of a premarket submission. Neither the current guidance nor the new guidance suggests that manufacturers do not need to generate the full set of documentation; rather, the new guidance simply identifies what documentation must be submitted to the FDA for premarket review.
Of all the documents required as part of the premarket submission, the FDA dedicates a considerable amount of the new guidance to describe the System and Software Architecture Diagram, signifying the importance of this document among the submission materials. As the new guidance indicates, System and Software Architecture Diagram serves as:
[A] roadmap to facilitate a clear understanding of 1) the modules and layers that make up the system and software, 2) the relationships among the modules and layers, 3) the data inputs/outputs and flow of data among the modules and layers, and 4) how users or external products, including IT infrastructure and peripherals (e.g., wirelessly connected medical devices) interact with the system and software.
Clarity in the communication of the information in the System and Software Architecture Diagram is critical to serving this purpose. The diagram needs to contain an “appropriate level of detail . . . to convey the information in a manner that can facilitate an efficient premarket review” and avoid unnecessary confusion and questions during the review process. The new guidance offers the following considerations to facilitate the creation of an effective System and Software Architecture Diagram.
For multiple-function device products, the System and Software Architecture Diagram should clearly convey whether and to what extent each module is related to the intended use of the product’s identified functions and whether such functions are believed to be a device function-under-review. Below is the FDA’s example of a System and Software Architecture Diagram that employs the principles articulated in the new guidance to convey an overview of the various modules, their purpose, how they interact, and how to find out more information within the premarket submission materials.
Manufacturers should maintain the System and Software Architecture Diagram within their Quality System so that changes to the product design are traceable throughout the product lifecycle and to facilitate evaluation of the need for future premarket submissions and the impact of such changes on product risk.
One of the key aspects of the new guidance is the alignment of the content to IEC 62304:2006/A1:2016. As noted above, manufacturers who conform to this international standard can simply declare conformity as opposed to submitting to the FDA documentation related to the software development and maintenance activities. Those who do not declare conformity are required to submit documentation containing the following information:
For Enhanced level software (for which a Declaration of Conformity to IEC 62304:2006/A1:2016 is not provided), the new guidance requires all of the above documents plus a complete configuration management and maintenance plan.
One important area where the new guidance does not align with IEC 62304:2006/A1:2016 is the international standard’s Software Safety Classification, which uses a three-tier system (i.e., Class A, B, and C) and aligns closely with the LoC approach in the current guidance. The new guidance will effectively put Class A and B software in the Basic level, and Class C will be subject to the requirements at the Enhanced level.
The documentation related to risk management is one in which the new guidance increases the expectation relative to the current guidance. This may be due, in part, to the age of the current guidance and the evolution of industry standards since its publication. Specifically, the current guidance requests merely the Device Hazard Analysis, which “can be in the form of an extract . . . from a comprehensive risk management document” developed according to ISO 14971. The new guidance goes further and recommends the submission of the Risk Management Plan, the Risk Assessment, and the Risk Management Report. These documents should be developed in conformity to ISO 14971:2019 (or any future FDA-recognized version) and cover the comprehensive risk management process across the software development lifecycle, including risk related to cybersecurity, production, and post-production activities.
Overall, the new guidance largely aligns with the current guidance but provides greater detail for manufacturers to better understand the Agency's expectations and simplifies the analysis for determining what documentation must be included in a premarket submission. While in some areas the documentation requirements have increased (e.g., software description, system and software architecture diagram, and risk management), other aspects of the documentation requirements have been reduced (e.g., software design specification, software development and maintenance practices, and traceability analysis). For both the System and Software Architecture Diagram and the Risk Management File, greater attention must be paid to ensure the submission materials meet the FDA’s expectations. The ability to leverage conformity to IEC 62304:2006/A1:2016 significantly reduces the burden on manufacturers and the Agency, streamlining the regulatory review process. Ultimately, the new guidance will likely result in the vast majority of software-based devices requiring the least burdensome documentation expectations, which should lead to faster reviews and shortened timelines to market for innovative software-based devices.
Stay in the loop with exclusive insights and valuable updates about the medical device industry and FDA approval!