FDA Issues a Draft Guidance for Content of Premarket Submissions for Device Software Functions
Sixteen years after the publication of the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued May 11, 2005, FDA issued a new draft guidance document on November 4, 2021 that describes the recommended documentation that a sponsor should include in their premarket submissions. To put the age of the existing guidance into perspective, it was published two years before the first iPhone was released. Over the past 16 years, there have been numerous advances in healthcare technology, particularly with respect to the use of software in and as a medical device. Please see our previous blog postings on various software regulatory developments (here, here, and here).
This new draft guidance document applies to “device software functions” that meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C 17 Act).
If you’re interested in software products that do not enjoy any of the 21st Century Cures exemptions and require premarket submissions, please continue to read this blog. Summaries of the impact of the 21st Century Cures Acts on software and the definition of a medical device are available here, here, here, and here.
The new draft guidance applies to both Software in a Medical Device (SiMD) which would be your traditional hardware with embedded software and Software as a Medical Device (SaMD). The scope of the new draft guidance is basically the same as the 2005 guidance which includes:
(1) firmware and other means for software-based control of medical devices, (2) stand-alone software applications, (3) software intended to be operated on general-purpose computing platforms, (4) dedicated hardware/software medical devices, and (5) accessories to medical devices when those accessories contain or are composed of software. It does not apply to software-related documentation that may be needed to evaluate post market software device issues (e.g., corrections and removals). Like the 2005 guidance, this new draft guidance applies to all types of premarket submissions, but now the Agency has specifically added De Novo Classification Requests and Biologics License Applications (BLA).
The most obvious update to the new draft guidance is the shift from three to two categories for determining what software documentation to include in a premarket submission. According to the 2005 software guidance document, FDA used Major, Moderate, or Minor Level of Concern to determine the recommended documentation for software. In the new draft guidance document, FDA introduced four risk-based factors to help determine the device’s documentation level—either Basic Documentation level or Enhanced Documentation level.
Basic Documentation is necessary for all device premarket submissions that include software functions. But if the device (i) is a constituent part of a combination product, (ii) is intended to test blood donations, or to determine donor and recipient compatibility, or a blood establishment computer software, (iii) is categorized as a Class III device, or (iv) presents a probable risk of death or serious injury upon failure, then such device software functions are categorized as Enhanced Documentation level. Note that, unlike the 2005 software guidance, the new guidance only references serious injury, which is an injury or illness that is life threatening, results in
permanent impairment of a body function or permanent damage to a body structure, or necessitates medical or surgical intervention to preclude permanent impairment of a body function or permanent damage to a body structure. Both the draft guidance and the 2005 guidance require the assessment of the risk to be evaluated prior to the implementation of risk control measures. Interesting to note, FDA specifically called out the use of the word “probable” versus purely hypothetical, when determining the risk of death or serious injury. However, “probable” risks also include the likelihood that the device could be compromised due to cybersecurity risks.
Below is an overview of the software documentation sponsors would need to provide for Basic and Enhanced levels:
Software Documentation | Basic Documentation Level | Enhanced Documentation Level |
Documentation Level Evaluation | √ | √ |
Software Description | √ | √ |
System and Software Architecture Design Chart | √ | √ |
Risk Management File | √ | √ |
Software Requirements Specification (SRS) | √ | √ |
Software Design Specification (SDS) | × | √ |
Software Development and Maintenance Practices | √ | √ |
Software Testing as Part of Verification and Validation | √ | √ |
Revision Level History | √ | √ |
Unresolved Anomalies | √ | √ |
The major difference between the two is that Basic Documentation Level does not need to submit the Software Design Specification. However, there are differences in the level of detail expected for some of the deliverables. For example, Software Development and Maintenance Practices allows a declaration of conformity to IEC 62304 to work for both categories.
However, if the sponsor does not provide a declaration of conformity, Basic level devices would only need to provide a summary of configuration management and maintenance activities while sponsors of devices in the Enhanced level would need to provide the summary as well as complete configuration management and maintenance plan documents.
For software testing as part of verification and validation, only a summary description of the testing activities at the unit, integration, and system levels is required for devices categorized as Basic level, but for sponsors of devices in the Enhanced level, they need to also provide unit and integration level test protocols and results. The Agency added details that clarify their expectations around test results, specifically that it would not only include the pass/fail determinations, but additionally include expected results and observed results.
Under the proposed framework, the amount and type of software documentation may increase or decrease for existing software devices when a sponsor files its next premarket submission.
“Minor” level of concern software devices, under the 2005 guidance, were defined as failures or latent design flaws that were unlikely to cause any injury to the patient or operator. If the draft guidance is finalized, the next time a sponsor submits for a formerly “Minor” level of concern software, it will need to provide documentation similar to what had been previously required of a “Moderate” level of concern device. “Moderate” level of concern was defined as failures, malfunctions or latent design flaws in the software that could directly or indirectly likely lead to minor injury to the patient or operator. (Refer to Table below).
Software Documentation | 2005 Guidance Minor Level of Concern | 2021 Draft Guidance Basic Documentation Level |
Documentation Level Evaluation | √ | √ |
Software Description | √ | √ |
System and Software Architecture Design Chart | × | √ |
Risk Management File | √ | √ |
Software Requirements Specification (SRS) | √ | √ Now you need to provide the complete SRS that was previously required for Moderate level of concern device |
Software Design Specification (SDS) | × | × |
Software Development and Maintenance Practices | × | √ |
Software Testing as Part of Verification and Validation | √ | √ Now you need to provide the level of V&V that was previously required for Moderate level of concern device |
Revision Level History | √ | √ |
Unresolved Anomalies | × | √ |
Under the 2005 guidance, if a sponsor’s software was a “Moderate” level of concern device the required documentation would decrease under the draft guidance. The software device would now be categorized as Basic Documentation Level and the Software Design Specification would not need to be submitted.
Other significant changes include the FDA’s details around what is expected for System and Software Architecture and Risk Management. FDA has devoted an entire Appendix to providing sponsor’s examples of architecture charts. With respect to Risk Management, now in addition to submitting your Risk Analysis (previously referred to as a hazard analysis), sponsors also need to
submit their Risk Management Plan and Risk Management Report, which should address methods for collection of relevant production and post-production information. For those of you who thought Traceability Analysis went away, it did not. Traceability was simply included in the description of the Software Requirement Specification document.
FDA has also taken steps to update the guidance for Artificial Intelligence/Machine Learning software devices. This is a welcome change given that AI/ML software is becoming much more widely used in medical devices, as evidenced by the list of AI/ML-enabled medical devices recently published by FDA (here). For AI/ML software, specifically, the draft guidance indicates that the software description should include the populations or samples informed your model(s) and what steps were taken to identify and address potential biases and limitations of your model(s). Interestingly, the draft guidance does not reference other AI/ML-specific considerations, like, Predetermined Change Control Plan, which has been contemplated in FDA’s AI/ML action plan (see our prior post on the action plan here). We would encourage FDA to consider aligning the final guidance with the AI/ML action plan so the expectations for AI/ML software documentation is clear and comprehensive.
When final, this new document will replace the 2005 guidance document. Interested parties have until February 22, 2022 to comment on the new guidance at this link.