.png)
Last month, the FDA released a new guidance: Content of Premarket Submission for Device Software Functions. The last guidance of this type was in 2005 for software contained in medical devices. Needless to say, a lot has changed in the last 23 years in the field of software, and this guidance begins to address some of these changes. In this post I will discuss some of the more significant changes in regards to three specific areas: New Documentation Levels, Specificity, and Keeping with the Times, as well as some of my own personal thoughts.
New Documentation Levels
The most significant change is in establishing the level of documentation required. Prior to this guidance, the FDA established 3 risk-based levels called “Levels of Concern”: Minor, Moderate, and Major. IEC 62304 also has 3 levels, referred to as software safety classes: A, B, and C. Both conventions correspond to the possibility of a software flaw causing no injury, non-serious injury, or serious injury or death, respectively.
The new guidance removes the above software levels and instead establishes 2 documentation levels: Basic and Enhanced. Enhanced documentation is required for a “system where a software flaw or failure would present a hazardous situation with a probable risk of death or serious injury to either a patient, user of the device, or others in the environment of use, prior to the implementation of risk control measures.” Everything else falls into the Basic documentation.
I have emphasized the word “probable” above. Before, possible hazards were considered in establishing the documentation level required; but now, the hazard must be probable for the Enhanced Documentation Level. When working with clients, a lot of very hypothetical risks come up, for which sometimes choosing the most appropriate classification can be difficult. For example, with a COVID test, it is possible for a false negative to result in lack of treatment that could ultimately result in death. While possible, death in this case is not probable, therefore a COVID test analysis software would not require Enhanced Documentation.
I personally like the simplification into 2 levels. The Enhanced Documentation Level correlates to the previous Major Level of Concern. Likewise, the Basic Documentation Level now correlates to the prior Moderate and Minor Levels of Concern. I like that detailed software design and its traceability to requirements is only required in the Enhanced Documentation Level. Tracing software design to requirements is a chore that does not yield much benefit because design includes infrastructure, task management, and OS interfacing which are not directly mapable to requirements.
Specificity
While this guidance does not appear to converge more with the international standard IEC 62304, it provides an important step in that direction - specificity. For example, for the required Software Description, the prior guidance had a paragraph to describe what was needed. The new guidance provides 2.5 pages of description, with questions that should be answered. The same applies for Risk Management and Software Architecture – both sections have elaborated on what the submission needs to include. This elaboration removes ambiguity, allowing the submitter to be confident that, when following the guidance, they have provided what is expected. I presume that the new specificity comes from 23 years of audits in which the auditor could not fully understand the system. Specificity is good for both sides of the fence.
Keeping with the Times
Along with more specificity, the guidance incorporates a few concepts that were not around 23 years ago. For example, the guidance accepts different life cycle models, including Agile. Additional forms of software requirements can be included in the submission such as Agile Stories and use cases. The guidance also discusses what information needs to be provided when using AI, including what training method is used and how biases are addressed.
Summary
Overall, this guidance update was long overdue. I believe it provides much-needed clarity for specific expectations and simplifies the documentation requirements for Class II devices. At Promenade, we are working on updating our templates to satisfy this new guidance. Please let us know if you would like to discuss further or need assistance with your software development documentation.
