Computer Software Assurance

What FDA's newest draft guidance means for the future of regulated software companies

Erez Kaminski

6 minutes read

The FDA’s new guidance is the catalyst for a generational shift in software development for manufacturing systems and products in medical devices, pharmaceuticals, and biotechnology. But what exactly does the new Computer Software Assurance (CSA) guidance mean and what will its effect on manufacturing systems be? In the words of the FDA:

“FDA envisions a future state where the medical device ecosystem is inherently focused on device features and manufacturing practices that promote product quality and patient safety.”

Manufacturers must be prepared for this latest shift in software development. Companies need to re-think their approach to software, cloud, and data-driven applications by examining their software assurance, objective evidence, testing methods, and overall approach to risk management.

What is this CSA guidance all about?

As industry has been well aware for years, Computerized System Validation, the act of rigorously testing computer systems to ensure they perform precisely as intended, is a tedious, complex, and error-prone process. The need to fully validate computer systems has resulted in significant slowdowns and high costs for Healthcare and Life Science (HLS) manufacturers. In recent years, the ever-growing complexity of data-driven, cloud-based computer systems has exacerbated these issues. These increasing difficulties create an immense barrier for software innovation to transform the regulated medical field.

The FDA, agreeing with the HLS industry (i.e. GAMP 5), has decided to formally empower software teams to develop and test software using a risk-based approach. While the “risk-based approach” has been talked about for quite some time, this guidance provides a needed framework to understand how risk-based systems can be developed and applied by the broader FDA ecosystem. The risk-based approach, in contrast to the classical approach (involving complete system validation), allows software developers to focus on the riskiest part of their software ecosystem, focusing limited resources on the major elements that can affect patient safety.

While some of this sounds obvious, it is not how HLS manufacturers have developed software for the past decades. Instead, most of the industry has focused on rigorous and complete validation, similar to how safety-critical avionics systems are developed (and not the onboard video streaming service).

Why is this a big deal?

Firstly, this guidance considerably simplifies the way software is developed in FDA-regulated industries, mainly regarding the ability of companies to create automated systems for design, manufacturing, distribution, and production. This modification would enable companies to focus on assuring quality on the pieces that are safety-critical, not everything in between. This change assumes that the company has a framework to introduce a risk-based approach into its software development practices.

Secondly, it signifies the beginning of a new era. It is the first in a wave of related guidances that will help reduce the time, cost, and complexity of creating FDA-regulated software. The goal of this is to improve public health outcomes, and allow rapid innovation by lowering cost barriers while ensuring patient safety.

What does the new guidance mean?

The new draft guidance means that manufacturers should be able to move faster and develop their automated manufacturing systems and quality systems more efficiently. This improvement will have a substantial impact on the time it takes to changeover a manufacturing line and to develop and integrate new systems that can reduce complexity and cost of building medical products (for example Amgen’s AI Assisted Packaging inspection).

Changeover time and the validation needed to re-start a production line has long been discussed as a major friction point for product development. Some manufacturing leaders have shared with us that computer system validation is the number one bottleneck to their processes.

As we know from existing software validation guidances, medical device software and manufacturing system software tend to be re-used across FDA guidances relating to software in other domains. It is clear that this guidance will be a building block to many other software-related assurance guidances in the future. We should all start preparing.

A two-phase approach to risk

For almost a century, there have been ongoing discussions on the “right” multi-tier approach to risk. Some companies have decided on a three-tier approach (high, medium, low), others on a five-tier, seven-tier, or even an eleven-tier approach. The number of tiers is arbitrary; the main point is teams need to have a way to understand what to focus their limited capacity on.

In this new guidance, the FDA has decided to take a more practical approach, involving a high-tier and a low-tier. What they are describing is the critical items teams should focus on and separating them from the non-critical items. While this distinction will be discussed for many decades to come, a two-tier approach does simplify the risk-based approach and will make it easier to interact with regulations in a meaningful, effective way.

The guidance also separates between two types of risk:

  1. Medical Device Risk (i.e. Product risk)
  2. Process risk (i.e. process risk that can lead to Medical Device risk)

Product risk refers to the potential for a product/device to harm the patient or user. This guidance focuses on the product risk resulting from a quality problem that compromises safety.

Process risk is focused on the parts of the design, product, and distribution process that can cause a critical quality event that results in patient harm. The FDA wants to ensure manufacturers focus on risks that can foreseeably cause patient harm.

These two types of risk are critical for development teams to understand and organize their work accordingly.

How to start planning for a risk-based future

While many manufacturers have already been developing methods, procedures, and systems designs to embed a risk-based approach into their processes, the reach of the new guidance will be considerable. HLS manufacturers engaged in building custom software will need to create a completely new approach to software development, one focused on utilizing modern developer tools integrated with risk management, with the goal of streamlining the development process.

Validated application lifecycle diagram
Validated Application Lifecycle

Such tooling could significantly reduce the complexity and time it takes to create validated and assured systems built using modern methods. The Ketryx Platform represents the fastest way teams can integrate a risk-based approach and start moving faster.

We at Ketryx believe that this draft will have a major effect on the future of regulatory development, and this blog presents our current opinions and provides a short overview of the guidance. Nothing in this blog should be taken as regulatory, quality, or validation advice. For those interested in a more complete understanding, we recommend reading the entire guidance.