The FDA has released a draft guidance for the contents of premarket submissions for device software, and the industry should take heed of the prospect of more extensive documentation requirements. The agency also stated that it may request additional information from the sponsor to process the application, however, a rare public acknowledgment that these requests could become more routine.
When finalized, the draft guidance will update a 2005 guidance that has been on the FDA’s guidance agenda for several years. The agency acknowledged that this update was part of the Medical Device User Fee Amendments IV (MDUFA IV), which was signed five years ago, but developers may have seen the 2005 guidance as obsolete long before 2016.
The FDA said in the public notice that the information required by the draft guidance would typically be generated and documented during software development, verification and validation, an observation also found in the 2005 guidance. However, the agency also flatly stated that it may request additional information to evaluate the submission. That sort of declaration is not routinely appended to these notices, as the notice for the OTC hearing aids draft guidance and the notice for clinical decision support software confirm. This would seem to suggest that reviewers at the FDA will not be reluctant to press applicants for additional documentation of their software design and validation efforts going forward.
The scope of the 2005 guidance includes software that serves as an accessory to medical devices or is part of a device accessory. The guidance also referred to ISO 14971 and AAMI SW68 as applicable consensus standards, a list that has expanded considerably in the past 16 years. Of particular interest is ANSI/AAMI/IEC 62304, which the FDA added to its list of recognized standards in 2019. The FDA retroactively included it as a reference for the 2005 guidance as the standard did not arise until 2006, although 62304 was amended a decade later.
This standard’s emphasis on total product life cycle (TPLC) considerations meshes well with the agency’s overall push for more extensive life cycle product management. However, the FDA indicated in the 2021 draft that it will place more emphasis on IEC 62304 Edition 1.1 in the future, although this emphasis will be limited to the section for software development and maintenance practices. This will suffice to establish a declaration of conformity (DoC) with 62304, and the FDA explained that this will allow reviewers to assess the software’s function without the distraction of superfluous information.
Two-Level Documentation System May Prove More Burdensome
One of the key features of the 2005 guidance is its use of a levels-of-concern approach to determine the documentation needed for a premarket filing. This three-level approach (major, moderate, and minor levels of concern) is determined by the results of a hazard analysis conducted prior to any risk mitigation activities. A major concern is one in which a failure or latent flaw could directly or indirectly result in death or serious injury to the patient or operator, while a moderate concern is one in which that failure or flaw could result in a minor injury to patient or operator. A minor concern is when injury of any sort is unlikely.
The 2021 draft guidance replaces this three-tiered framework with a two-level framework, the basic and enhanced documentation levels. The enhanced documentation level would be required for premarket submissions for class III products, combination products, and systems used in blood and other tissue donation/transfusion processes. Enhanced documentation would also be required if a failure or latent flaw of the software could present a probable risk of death or serious injury. The term “probable risk” is presumed to include deliberate or incidental device misuse, and compromised device function due to cybersecurity problems. Absent one or more of these conditions, basic documentation requirements will suffice.
These two tiers of documentation levels are applied to three considerations. These are:
- Software design specification (SDS);
- Software development and maintenance practices; and
- Software testing as part of verification and validation.
The difference between the two guidances’ approaches to SDS, for example, is considerable. The 2005 guidance states that SDS information should ensure that the work done by software engineers was clear and unambiguous, and incurred a minimal number of ad hoc design decisions. The documentation should allow FDA staff to review the implementation plan for intended use, functionality, and safety and effectiveness, but the description of SDS in the 2005 guidance essentially stops there.
In contrast, the 2021 draft adds several requirements in the enhanced documentation level. These include that SDS documents provide exhaustive details as to how the software design traces to software requirements specifications (SRS). The SDS would also have to trace back to the SRS regarding intended use, functionality, and safety and effectiveness, as is the case with the 2005 guidance, but the draft requires a description of how software modules interface with each other as well.
We would point out to the readers of our blog that much of this seems to reflect the existing regulation, such as Part 820.30(f) for design verification. This portion of the Quality System Regulation (QSR) requires development of procedures for verification, consisting in part of ensuring that design outputs meet design input requirements. However, the tenor and specificity of the draft guidance would seem to suggest that the FDA does not believe that software developers have always been particularly keen to come into compliance with the QSR. Alternatively, the message might be that the agency believes that software developers who are unfamiliar with FDA regulation struggle to incorporate the QSR into their quality management practices.
The demands on software testing seem destined to increase under the 2021 draft guidance, given that the 2005 guidance mentions testing only in the context of verification and validation. In the 2005 guidance, testing is only one of several verification activities, such as integration and module-level testing.
For the basic documentation level, the 2021 draft would require that submissions include a list of the software versions tested and the overall pass-fail test results for all test protocols. Other requirements include that the sponsor/developer document:
- Any changes undertaken intentionally to respond to failed tests, along with documentation that those changes were correctly implemented;
- All system-level test protocols, including both expected and actual results, along with documentation that unresolved anomalies are appropriately deferred on the basis of a risk assessment for the anomaly; and
- Regression analyses and pass/fail test results to track the unintended consequences of a change to the software.
In addition to these requirements, the requirements for any software that falls into the enhanced documentation level include unit and integration-level test protocols and reports, which should indicate that the test protocols have been properly executed and have led to passing results.
All in all, the draft seems to indicate that developers of software as a medical device (SaMD) and software in a medical device (SiMD) should brace themselves for a much more extensive series of documentary demands going forward. This is probably a safe assumption for all such filings, but may be a particularly pertinent assumption due to the FDA’s promise that it will not hesitate to ask for additional information if it finds a premarket application lacks in any of these critical details.