Any computer system (or automated data processing system, for that matter), used to automate any part of the quality or production system, must be validated for its intended use with an established protocol, as required by the U.S. Food and Drug Administration's General Principles of Software Validation guidance.1
However, in September of 2022, the Agency issued a new draft guidance, Computer Software Assurance for Production and Quality System Software, that will supersede section 6 ("Validation of Automated Process Equipment and Quality System Software").
This blog post will explore how transitioning from traditional Computer System Validation (CSV) to the new Computer Software Assurance (CSA) approach can save you time and resources.
What do we have now?
Currently, any software used in manufacturing, operations, and quality systems activities following 21 CFR Part 820 must undergo CSV. The focus of the process is to document any validation activity and result.
The FDA's definition of validation is a good place to start if we want to understand the challenges:
"Validation" means establishing documented evidence that provides a high degree of assurance that a system will consistently produce a product meeting its predetermined specifications and quality characteristics."
We can establish the following conclusions from the FDA’s definition:
- The system functionalities must be completely and thoroughly specified (the predetermined specifications and quality attributes).
- The testing will verify the quality acceptance criteria (the assurance that a system will (...) produce).
- The testing is thorough and rigorous (a high degree of assurance).
- The validation is maintained throughout the system's lifecycle (consistently produce).
By creating documentation, the auditors have a detailed overview of each aspect of the software used in the manufacturing process. This guarantees the fitness for intended use.
A problem of scale
The FDA demands the testing and documentation of computer systems and automated equipment used in design, laboratory testing and analysis, product inspection and acceptance, production and process control, environmental controls, packaging, labeling, traceability, document control, complaint management, and many other aspects of the quality system.
We're referring to systems such as:
- Programmable logic controllers
- Digital function controllers
- Statistical process control
- Supervisory control and data acquisition
- Robotics
- Human-machine interfaces
- Input/output devices
- Computer operating systems
As you can imagine, the CSV team spends significant time and effort creating the protocols and documenting the processes and activities.
Somehow, the goal of ensuring the system’s quality has shifted to ensuring manufacturers can generate and make evidence available to auditors. And it's a lot of evidence, from a lot of testing.
The worst part is that, even if the computer system is thoroughly tested, it doesn’t actually prove that it will be fit for intended use. This becomes an obstacle toward Pharma 4.0 and the extended usage of automation for testing and document generation. So, if we had to state the problem, we would say that we must validate everything and extensively document everything that we validate.
How can we transform CSV from a time- and resource-expensive activity into a competitive advantage?
Transition from CSV to CSA
The FDA took notice of the situation and issued the CSA draft guidance. While the traditional CSV approach focuses on testing and verifying each software aspect throughout its lifecycle, the "software assurance" method aims to prevent introducing defects into the software development process.
And this is the main difference: Instead of exhaustively testing the software, manufacturers should use this risk-based approach for establishing and maintaining confidence that the software is fit for its intended use.
Because the goal is to optimize overall system performance, only components essential to the product and the patient’s safety must be validated and subjected to scripted tests. And the identification of which components are critical should be performed using a risk-based assessment, where you only need to perform CSV-level validation and testing for higher-risk components. This means more efficient use of your team's time and resources — critical thinking-based! This is why transitioning from CSV to CSA should be high on your priority agenda.
To learn more about transitioning from CSV to CSA, read ValGenesis' Guide to Computer Software Assurance (CSA).It covers topics such as:
- Critical thinking and its role in CSA
- What are assurance needs in CSA?
- Why CSA wants us to focus on records, not documentation
Ready to make the transition?
ValGenesis is ready to support you in applying critical thinking and only test what is necessary with a least-burdensome, risk-based approach to validation. Our CSA-ready solution provides risk assessment at the requirement level to reduce the over-testing common in CSV.
Get in touch with our CSV/CSA implementation experts to learn more.
