Computer Software Assurance for Medical Devices: What Does FDA’s Draft Guidance Mean for You?

In September 2022, the FDA issued a draft guidance that marks a significant transition in the MedTech industry's approach to software validation.

The FDA’s goal with the guidance—Computer Software Assurance for Production and Quality System Software—is to promote a risk-based approach to software validation and provide best practices for fulfilling the software validation requirements in 21 CFR Part 820.70(i).

Once the draft guidance is finalized, it will replace Section 6 of the FDA’s guidance on the General Principles of Software Validation. 

This shift from the way the FDA approaches software validation to computer software assurance (CSV to CSA) emphasizes the importance of tailoring validation efforts to a software’s risk profile rather than applying a uniform validation method across all software tools.

Modern medical device companies rely heavily on software to help them produce their devices and meet documentation requirements, so this draft guidance is extremely relevant right now. Though it hasn’t been finalized yet, I want to take some time to explain what’s in the draft and its implications for medical device manufacturers. 

FREE TEMPLATE: Download your copy of our previously confidential risk management plan by clicking here.

What is computer software assurance (CSA) and why is FDA issuing this guidance now?

In section IV of the draft guidance, FDA defines computer software assurance (CSA) as “a risk-based approach for establishing and maintaining confidence that software is fit for its intended use.”

If that sounds a lot like the definition of software validation to you, you’re not wrong. FDA uses both terms—computer software assurance and software validation—throughout the guidance document. Computer software assurance is a form of software validation that FDA is encouraging MedTech companies to use for validating software used as part of production or the quality system.

As for why FDA is releasing this now, it’s pretty simple, really. Software is ubiquitous in MedTech, and FDA is responding to this reality by offering a risk-based approach to validating software used in production and quality systems.

As noted in section II of the draft guidance, “medical device manufacturers have expressed a desire for greater clarity regarding the Agency’s expectations for software validation for computers and automated data processing systems used as part of production or the quality system.”

The agency is emphasizing a risk-based approach because not all production and quality system software poses the same risks. They’re encouraging medical device manufacturers to use more of their resources on validation of high-risk software, rather than taking a blanket approach that puts all software through the same validation activities. 

This is part of the agency’s continued emphasis on the least-burdensome approach, and its goal is to get manufacturers to think critically about where to focus their time and energy in order to develop safe and effective medical devices. 

What is the computer software assurance risk framework laid out by FDA?

The CSA risk framework in FDA’s draft guidance consists of four subsections. To fully understand what the agency expects in each stage of the framework, you should read the guidance in full. However, I’ve listed some of the salient points from each stage here. 

1. Identifying the intended use

In this subsection, FDA has divided software used as part of production or the quality system into two subcategories:

• Software used directly as part of the production or quality system. For example, software used for automating production processes or quality system processes.
• Software used to support production or the quality system. For example, software that tests or monitors or is used for general record-keeping that isn’t part of the quality system.

Both types of software must undergo assurance activities. However, supporting software carries less risk and so will likely not need to undergo the same type of assurance activities as software used directly as part of the production or the quality system. 

2. Determining the risk-based approach

Here, FDA makes another important distinction, this time between process risk and medical device risk.

A process risk refers to the potential to compromise production or the quality system. A medical device risk refers to the potential for a device to harm the patient or user. When discussing medical device risks, this guidance focuses on the medical device risk resulting from a quality problem that compromises safety.

Though the guidance focuses on medical device risk, that doesn’t mean process risk is irrelevant. The guidance goes on to explain the relationship between the two types of risk, stating that,

FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning an increased medical device risk.

In other words, taking process risk into account is essential, as it could result in a higher medical device risk.

3. Determining the appropriate assurance activities

In this subsection, the guidance discusses the choice of software assurance activities. These should be “commensurate with the medical device risk or the process risk”, as determined in the previous stage.

It also includes some of the types of assurance activities (though the list is not exhaustive) that manufacturers may perform, breaking them up into two categories:

• Unscripted testing. Dynamic testing in which the tester’s actions are not prescribed by written instructions in a test case.
• Scripted testing. Dynamic testing in which the tester’s actions are prescribed by written instructions in a test case.

In general, manufacturers may want to use scripted testing for high-risk software features, function, and operations and may choose to use unscripted testing for low-risk software. Just remember that this is a rule of thumb; each manufacturer will need to determine for themselves what activities are appropriate given the intended use of their software and the level of risk it entails. 

4. Establishing the appropriate record

The final step in the FDA’s risk-based framework for computer software assurance is documentation. We all know that if you didn’t document it, it didn’t happen. So don’t forget to document as you go. 

The draft guidance offers a table with examples of assurance activities and their records, along with this advice:

Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified. FDA recommends the record retain sufficient details of the assurance activity to serve as a baseline for improvements or as a reference point if issues occur.

Looking at it from a high level, the CSA risk framework is not breaking new ground. First, establish the intended use of the software. Then determine the risk it poses and choose your software assurance activities based on that risk. And of course, document everything you do. 

It’s likely you’ve already been carrying out these steps to fulfill the software validation requirements in the QSR. This guidance is really about clarifying the FDA’s expectations for manufacturers.

FREE TEMPLATE: Download your copy of our previously confidential risk management plan by clicking here

Greenlight Guru's modern approach to validation lets you spend more time on design and development

At Greenlight Guru, we pride ourselves on staying up to date with the latest developments in the complex and ever-changing field of MedTech. That's why we've adopted an automated, risk-based approach to software validation that's aligned with the FDA's guidance on CSA and best practices of standards like ISO/TR 80002-2:2017 and ISO 13485:2016. Our approach to validation keeps you compliant and ensures you can implement Greenlight Guru quickly and effectively.

If you’re ready to stop worrying about validation and do the work you love, then get your free demo of Greenlight Guru today!