Thoughts on the June 2023 FDA Software Guidance

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.

A hand reaches toward a futuristic image that says "UPDATE"

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. 


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

The monkeys-to-human evolution chain, but the images are made of technology/hardware symbols

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.



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.

Need help on this topic?
Contact Us
Frances Cohen

Frances Cohen is President of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science and following with Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.  

Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

linkedin logo
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485, and CypherMed Cloud is SOC2 Type II certified.