<img src="https://ws.zoominfo.com/pixel/OJkQgdjSvoid2NFoB5Qs" width="1" height="1" style="display: none;">

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

October 7, 2022

Computer Software Assurance for Medical Devices What Does FDA’s Draft Guidance Mean for You-1

On September 12th, 2022, FDA issued its latest draft guidance, which offers new recommendations for computer software assurance. 

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

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” and why is FDA issuing this guidance now?

In section IV of the draft guidance, FDA defines computer software assurance 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. But it’s clear from the title and the text that “computer software assurance” is now the preferred nomenclature for the activities described in the guidance. 

So, when you see “computer software assurance” in the future, know that it’s referring to the steps you take to fulfill the regulatory requirement for software validation found in 21 CFR Part 820.70(i).

As for why FDA is releasing this now, it’s pretty simple, really. Software is ubiquitous in medical device manufacturing and FDA is responding to this reality by offering best practices for a risk-based approach to computer software assurance. 

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 software assurance for high-risk software, rather than taking a blanket approach that puts all software through the same assurance 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 computer software assurance 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, this computer software assurance 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.

NOTE: You have until November 14th, 2022 to comment on the guidance before FDA begins work on the final version.

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

Greenlight Guru comes fully validated so you can spend more time on design and development

Software validation is critical to developing safe and effective medical devices, but as you can see, it’s not necessarily a simple process—especially if you’re using a number of software solutions in your production and quality system. 

At Greenlight Guru, we understand that your time is limited and you’d rather spend it working on the design and development of your device. That’s why our eQMS comes with a comprehensive software validation package at no additional cost.

So if you’re ready to stop constructing complex validation protocols and start focusing on developing life-saving medical devices, then get your free demo of Greenlight Guru today.

Tom Rish is a Medical Device Guru at Greenlight Guru who works with customers to utilize their QMS software to build safer products on expedited timelines. He is a Biomedical Engineer who began his career developing implant and instrument systems in the orthopedic industry. He enjoys helping customers successfully...

FREE TEMPLATE:
Risk Management Plan
Download Now
risk-management-template