Episode 2: Deciphering New FDA Guidance on Software Submissions

Episode 2: Deciphering New FDA Guidance on Software Submissions

Episode 2: Deciphering New FDA Guidance on Software Submissions

  • Posted by Jimmy Townsend and Nathan Viehmann
  • On March 24, 2022

At Engenious, we help medical device R&D leaders create reliable systems quickly. As a result, we develop and test medical device software while navigating regulations and standards that affect software development practices. We are keenly aware that misundestanding FDA’s new guidance on software could cause delays in gaining FDA clearance for new devices. This article is written for medical device R&D leaders and others involved in software development to provide an overview of how the new guidance could affect their projects, and steps that will help avoid unnecessary delays or wasted work. In this article we describe the impact of the new guidance.

In November 2021, FDA released draft guidance on software submissions[1] that is expected to replace previous guidance issued on May 11, 2005. FDA guidance for software submissions has previously been based upon the risk classification of that software, with lower risk software requiring less documentation than higher risk software. The new guidance telegraphs FDA’s philosophy shift away from accepting minor level of concern for medical device software.

FDA Guidance Change from 2005-2021

A key difference in the draft guidance is an update to the levels of software documentation. Documentation levels have been based on the level of concern, or the safety impact of device software. In the presently-adopted FDA Guidance on software from 2005[2], safety classifications were defined as minor, moderate and major. The new levels are: basic and enhanced. The new guidance proposes to remove the prior categories and map to the new basic and enhanced classifications. The minor and moderate classifications translate to the basic documentation level while the enhanced documentation level will replace major level of concern. In the guidance, FDA indicated that in rare occasions that moderate could map to the enhanced level of concern.

In a recent FDA webinar on the new guidance, a heavy emphasis was put on defining what the new basic documentation level is for FDA submissions. FDA reviewed 510(k) submissions and found that very few products submitted were truly minor level of concern software.

According to FDA participants in the webinar, the goal of this new guidance is to simplify the submission process with only two documentation levels and only one list of criteria to establish levels. The prior guidance contained long lists of questions which the proposed guidance would replaced with four categories for the enhanced level of concern. All projects that fall outside of those four categories would be considered basic.

During the webinar, FDA provided an example of a non-contact forehead thermometer which would be classified at the new basic documentation level. FDA considers that a non-contact temperature reading is something that would not cause serious harm or death in the event of reasonably foreseeable software failures. FDA conveyed that extreme worse-case scenarios are not the focus of classification. FDA presenters emphasized that they are not looking for theoretical situations that could cause unrealistic outcomes. FDA presenters frequently used the term “probable” to explain this example and the new draft guidance. FDA presenters indicated the focus is on capturing risks inherent to a system and not the purely hypothetical risks that while possible, are unlikely to occur.

FDA Enhanced Concern Categories

In the case of a ventilator controlled by software, it is appropriate for enhanced level of documentation. A failure of software controlling the ventilator could present a probable risk of death or serious injury to a patient. As a result of these risks, the core functionality of a ventilator controlled by software should be submitted under the enhanced documentation level.

In our work developing medical device software for clients, we regularly develop software in all of the existing and new categories. Our work includes the documentation that supports FDA submissions, and helps our clients satisfy FDA and international standards for medical device software. Our involvement in these activities makes the new FDA guidance an important part of our planning for new projects, and we hope that the new guidance is a welcome change for other R&D teams.

In summary, the new FDA guidance has been drafted and released to the public for comments and inputs from the public. The focus of the changes was on the documentation level that software should be submitted under. The existing minor, moderate and major levels of concern are being changed to map to the new basic and enhanced documentation level. The draft guidance updates focus on eliminating minor submissions and to add guidance describing the probable risks of the device. The FDA guidance is intended to help FDA focus their review on systems that have higher risks, with less FDA scrutiny on lower-risk systems.


Jimmy Townsend Website Bio - Software Engineering Team Lead
Jimmy Townsend
Software Engineer Group Lead at Engenious Design

Jimmy is an embedded software expert, with nearly two decades of experience. He is a primary contributor to 62304 based software and excels at quality procedures with an emphasis on creating outputs that are compliant in a minimally burdensome way. He has broad technical exposure from bare-metal hardware to Android 8, rapid development consumer devices to class III medical devices, and everything in between.

Nathan Viehmann
Software Engineer at Engenious Design

Nathan is an experienced software engineer; bringing well-crafted software to a variety of medical devices and high technology systems. His role at Engenious often means taking science fiction and bringing it to reality utilizing his skills in multiple programming languages, PCB Board Design and Software Management.