An Overview of the FDA Draft of CSA Guidance for Quality Systems

Article title
logo

In September 2022, the (FDA) released draft computer systems assurance (CSA) guidance clarifying software validation requirements for medical device manufacturers. The guidance significantly reduces the validation burden on manufacturers and creates greater potential to accelerate the adoption of digital technologies.

CSA guidance builds on 21 CFR Part 820, which broadly regulates software used in production and quality systems. For this reason, we’re taking a look at how CSA differs from computer software validation (CSV), and what’s in the new guidance.

What Is Computer Software Assurance (CSA)?

By FDA definition, CSA is “a risk-based approach for establishing and maintaining confidence that software is fit for its intended use.”

Moreover, the CSA approach considers risks to device safety and/or quality if the software fails to perform as intended. Therefore, the level of assurance and related activities used to establish confidence in the software is based on such risks. Taking a least-burdensome approach, assurance activities are the minimum amount of information necessary to address the risk.

Ultimately, CSA guidance for quality systems aims to reduce unnecessary obstacles that would delay the marketing of medical devices to ensure patients have timely access to products.

Where the New Guidance Fits In

Currently, Quality System Regulation 21 CFR 820.70(i) requires manufacturers to validate software used as part of the production or quality system. This includes quality management system (QMS) software.

Since the publication of 21 CFR 820.70(i), the FDA has participated in several different guidance documents related to software validation. These include the agency’s General Principles of Software Validation (GPSV) and the International Society for Pharmaceutical Engineering (ISPE) Risk-Based Approach to Compliant GxP Computerized Systems (GAMP 5).

CSA guidance supplements GPSV, only superseding Section 6. It’s based on the GAMP 5 framework, which acknowledges differing levels of risk associated with different types of software.

Understanding the CSA Guidance for Quality Systems Approach

For decades, manufacturers have applied software validation principles to every piece of software used, regardless of risk to safety. However, GPSV recommends software quality assurance to prevent defects in software development, including a risk-based approach for showing that software works correctly.

The new CSA guidance for software assurance covers recommendations for computers or software used in production or quality systems. As such, the guidance is applicable to QMS software.

Fortunately, CSA allows more flexibility in complying with 21 CFR 820.70(i) by allowing manufacturers to leverage activities such as:

  • Risk-based testing – analyzing risk based on software complexity, business criticality, frequency of use, and probable defect areas
  • Unscripted testing –less time-consuming than traditional test scripts; reserved for low- to medium-risk features and systems
  • Continuous performance monitoring – the process of continually evaluating how software performs according to expectations
  • Data monitoring – clearly identifying how the quality of data will meet its stated objectives
  • Validation activities – as completed by other parties such as software vendors

The CSA Guidance Risk Framework

The CSA risk framework focuses on four distinct steps:

  1. Identifying the intended use of the software feature or function
  2. Determining the risk-based approach
  3. Determining the corresponding assurance activities that need to be performed
  4. Creating the appropriate record documenting WHAT

1. Identifying the Intended Use

21 CFR 820.70(i) requires manufactures to validate software that is part of production or quality systems for its intended use. This includes software for automating quality processes, collecting and processing quality data or maintaining quality records.

Sometimes, software used in production or quality systems may have several features, functions and operations with one or more intended uses. In this case, the FDA recommends looking at intended uses of each feature and function to determine the appropriate assurance activities.

For example, a commercial off-the-shelf (COTS) software is used to document time and temperature data for a curing process. Because the software supports maintaining quality records, maintaining a validated state may not require assurance activities beyond:

  • What the developer has already done in terms of validation
  • Conducting a vendor assessment
  • Software installation and configuration

Conversely, if a custom formula calculates statistics for monitoring the curing process, additional validation might be needed.

2. Determining the Risk-Based Approach

After determining that software is part of production or quality systems, the next step is a risk-based analysis to determine assurance activities. This risk-based approach includes:

  • Identifying reasonably foreseeable software failures
  • Determining whether each failure poses a high process risk
  • Selecting and performing assurance activities commensurate with medical device or process risk, as applicable

Further, risk-based analysis should look at factors that can impact the software from working as intended, including:

  • System configuration or management
  • System security
  • Data storage and transfer
  • Operator error

For reasonably foreseeable failures, this analysis should examine the resulting risk, including (1) process risk and (2) medical device risk. The FDA defines these risks as follows:

  • Process risk: Potential to compromise production or the quality system
  • Medical device risk: Potential to harm the patient

High process risk occurs when a software failure may result in a quality problem that could increase medical device risk. Alternatively, if software failure doesn’t pose a medical device risk, it is not considered a high process risk. Therefore, QMS functions such as complaint management, change control and document management are not considered high risk.

The FDA guidance says the agency is “primarily concerned with the review and assurance for those software features, functions, and operations that are high process risk because a failure also poses a medical device risk.”

In practice, many manufacturers use risk management tools that cover a range of intermediate risks. In this case, since the FDA only looks at high risk / not high risk, intermediate risks are considered not high risk as well. For those that fall under high process risk, the next logical step is to evaluate the medical device risk.

3. Determining the Appropriate Assurance Activities

CSA guidance recommends that for quality problems that are high process risk, assurance activities should correlate with medical device risk. On the other hand, where a quality problem is considered not high process risk, the level of assurance activities should correspond to the process risk.

As an example, the FDA uses a feature that records process data for review, which is a lower process risk. However, the risk is higher when process data will help determine product acceptability prior to review.

High-risk software features typically demand more rigorous assurance activities such as scripted testing or limited scripted testing. Not high process risk, on the other hand, typically means generating less objective evidence. For example, not high process risk assurance activities may include unscripted testing methods (as ad-hoc testing, error-guessing, or exploratory testing).

In addition to software features, device manufacturers should review other controls within the quality system, leveraging work such as:

  • Production control activities, including data integrity procedures
  • Vendor selection processes
  • Validation work already done by the software vendor
  • Continuous monitoring data for detecting software performance issues
  • CSV tools like bug tracking and automated testing

While the tools used may vary, what’s important is that the manufacturer ensures the software maintains a validated state.

4. Creating the Record

The FDA guidance states that manufacturers should create a record of assurance activities. For each software featured, the record should include the intended use, the risk determination and documentation of the assurance activities performed, including:

  • Description of the testing
  • Any issues found and what was done to resolve the issues
  • Conclusion stating the acceptability of results
  • Testing date and person who conducted it
  • Signature and date of the person reviewing the record

The Quality Management System Connection to CSV Guidance

QMS software typically falls into category 4 or category 5 software under GAMP 5 guidance, depending on whether custom features are added. Category 4 is the most common industry software used. Compared with using software out-of-the-box, it provides validated tools for configuring the software without coding to meet business requirements. This is in comparison with category 5 software, which has added levels of customization requiring changes to code.

The CSA approach significantly reduces validation needs where the software vendor has already performed full validation. For some features, companies can just leverage vendor documentation, demonstrating the software works in an end-to-end use case test scenario. Companies should evaluate the vendor’s technical documentation, as well as validation templates for configured QMS features.

Conclusion

The shift from computer systems validation to CSA can dramatically cut the time and costs associated with implementing automated software. In fact, the 2020 Medical Device Innovation Consortium (MDIC) Case for Quality Forum notes a 50% or more reduction in validation time with this approach.

Building on existing regulations and guidance, CSA represents a simplified pathway for maintaining software in a validated state. For manufacturers, it reduces the barriers to adopting new technologies that can improve patient safety, including QMS software. With the change, companies can save time and money while increasing productivity and efficiency.

About the Author

Stephanie Ojeda is Director of Product Management for the Life Sciences industry at AssurX. Stephanie brings more than 15 years of leading quality assurance functions in a variety of industries, including pharmaceutical, biotech, medical device, food & beverage, and manufacturing.

 

 

Quality + Compliance Management Software
AssurX Quality + ComplianceA single versatile software system can improve quality, compliance and streamline workflow.
Don’t Miss A Post

Subscribe to our blog to receive an email when we publish new content.

Quality + Compliance Management Software
AssurX Quality + ComplianceA single versatile software system can improve quality, compliance and streamline workflow.