The US Food and Drug Administration (FDA) recently issued a new guidance document: Content of Premarket Submission for Device Software Functions. The revamp of the FDA’s software guidance for premarket submissions of device software functions, replacing the previous version that was published in 2005, has been a long time coming. As medical device manufacturers and developers know, the premarket submission process can be a daunting task, filled with complicated regulatory requirements. The associated documentation that must be submitted for premarket clearance and approval is significant. The new 2023 FDA software guidance emphasizes a risk-based approach to regulating device software functions, while also adapting to new legislative mandates and guidance documents that have been published since 2005. We will outline the updated FDA guidance for regulated software functions, its implications, and how it affects manufacturers of software functions in medical devices.
What is a Device Software Function?
The newly released FDA software guidance covers software that controls medical devices and accessories. This includes firmware and standalone applications, as well as software within general computing platforms and medical devices with specific hardware and software. The FDA medical device software guidance applies to the device component of combination products as well, including drug-device and biologic-device combinations, if the device component has a device software function.
The FDA has differentiated between two types of software used in the medical industry: “Software in a Medical Device” (SiMD) which is part of a device or controls it, and “Software as a Medical Device” (SaMD) which qualifies as a device but is not part of the hardware. The FDA guidance for software classification categorizes both SiMD and SaMD as “device software functions.” For medical devices, the term “function” is the distinct purpose of the product, which could be the intended use or a subset of the intended use of the medical device.
Overview of the New FDA Software Guidance
The previously released FDA software guidance from 2005 outlined which documents an application would be required to contain based on the device software function’s “level of concern.” However, the new final guidance describes a risk-based approach that must consider the Total Product Lifecycle of the device and the role of the software in the device. Under the new guidance, medical device developers must choose between two levels of documentation, basic or enhanced, and provide a rationale for the choice. The rationale to support the documentation level should include references to other Design History File documentation such as the Risk Management File or Software Description.
The new FDA software guidance document is updated to include legislation like the 21st Century Cures Act (2016), which removed some software functions from the definition of a medical device, and the 2023 bill which allows the FDA to authorize devices that include Predetermined Change Control Plans (PCCPs) for Artificial Intelligence/Machine Learning updates. The guidance lists numerous FDA software guidance documents and internationally recognized standards about digital health, which should be reviewed when preparing a submission. In addition, it notes that the list is not all-inclusive.
Implications of the Revamped FDA Software Guidance
The biggest change in the guidance for the content of premarket submissions for software contained in medical devices is the move to two levels of documentation versus the previous three levels of concern. The level of documentation for the software will be determined based on its risk level.
- Enhanced Documentation should be provided for device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. If a device falls under the category of Class III, has the potential to cause serious injury or death to people involved, is a part of a combination product, or is intended for testing blood donations or determining donor and recipient compatibility, enhanced documentation is required.
- Basic Documentation should be provided for device software functions where Enhanced Documentation does not apply.
Another change from the previous version of the FDA software guidance is the software documentation required. Developers should create both a Software Requirement Specification (SRS) that details what the software will do, and a Software Design Specification (SDS) that outlines how the SRS requirements will be implemented. The submission documentation should include a summary of the significant features and functionality of the software, including details such as the programming language, hardware platforms, operating systems, off-the-shelf software, and release version. The application must document the following information: who will use the device, the intended users, the method of analysis used by the software, whether it helps or replaces actions performed by healthcare providers, and any relevant details about artificial intelligence and machine learning models.
Emphasis on Risk Management in FDA Software Guidance
The final FDA software guidance requires submissions to include procedures for product validation, which includes software validation and risk analysis, as part of their design controls. FDA premarket approval submissions for devices with software meeting the criteria should include a risk assessment that considers all possible software and hardware hazards associated with the device. A risk management plan should also be included, outlining the plan to evaluate the residual risk against the benefits of using the device. Whether a device’s software needs basic or enhanced documentation, medical device development companies can choose to submit a Declaration of Conformity to ANSI/AAMI IEC 62304 (Medical Device Software – Software Life Cycle Processes) or submit a list of their software development and maintenance processes.
The FDA software verification/validation guidance requires that documentation must contain information about all testing activities, pass/fail results, and any software changes made after failed tests. Submissions that require enhanced documentation should provide test protocols, which should include expected results (from software requirements), as well as actual results. The reports should include a justification of why the actual results should be considered substantially equivalent to the expected results. Unit and integration test reports should also be included in the submission package. The reports for the tests at the unit and integration levels should show that the protocols were executed correctly and passed all required testing. Any issues that were not resolved during testing should include documentation that they were adequately mitigated based on a risk assessment.
Sterling can help.
The constantly evolving regulatory landscape can be a significant source of stress for medical device manufacturers. The FDA’s newly released Guidance for the Content of Premarket Submissions for Software Contained in a Medical Device is just one example of how staying up to date on changing FDA software regulations is essential for success. Partnering with an experienced regulatory partner will alleviate the burden of navigating regulatory requirements. At Sterling, our expertise extends from the regulatory team to our engineers who have deep experience in software development and documentation. Our support will allow you to focus on your core business activities. Don’t let shifting regulations hold you back – contact us today and secure your position in the ever-changing world of medical device innovation.
