In the past, during software validation, companies put the main focus on testing and documentation. FDA's CSA draft guidance published on Sep 13, 2022, outlines the importance of a risk-based approach to shift the focus to preventing defects in the software development process. Companies embarking on a digital transformation journey can use this approach to determine the level of assurance needed for the software.
The purpose of this guide is to provide suggestions for CSA in regard to computers or automated data processing systems used as part of production quality control. It is not intended as an entire guide on all software validation principles outlined in FDA's guidance, "General Principles of Software Validation" ("Software Validation guidance"). This CSA guide covers specific risk analysis, testing methods, and the generation of acceptable objective evidence for production or quality system software.
Old Way vs. New Way
The life sciences industry has rapidly changed and advanced in the last decade due to newly developed technology, such as artificial intelligence, machine learning, big data and analytics, cloud systems, 3D printing, virtual and augmented reality, and IoT (the internet of things). By bringing Industry 4.0 into play with intelligent manufacturing and automation, we have seen a massive shift towards Pharma 4.0.
- CSA is a method to establish and keep confidence that software can do what it says it will do. To decide if the software meets this standard, we consider how poorly it would perform (should the software not work as intended) and weigh that against its importance.
- Compared to traditional software validation, this way of looking at things lets us use the least resources while still ensuring the software works correctly.
- CSA provides flexibility and agility in assuring the software remains validated by leveraging vendor QMS documentation.
Principles of the CSA Framework
- Focus on the intended use:
Identify the intended use of the software and determine if it is used directly for or to support the production or the quality system and use it to manage different risks with validation.
- Risk-based approach:
Once the software's intended use is identified, FDA recommends using a risk-based analysis to determine appropriate assurance activities.
- Determine validation activities:
For a software feature that poses a high risk(a quality problem that may compromise safety), greater rigor and objective evidence collection are recommended. An effort with less rigor and less objective evidence is acceptable for software with less risk.
- Capture sufficient objective evidence:
Collect objective evidence during software testing to demonstrate that the software functionality performs as intended. Maintain traceability of testing documentation to the requirements specification.
Key drivers for CSA
The main driver for CSA is that companies can execute robust testing with the right-sized documentation. The extent of documentation depends on the risk of the system and the maturity of the software supplier's quality management system (QMS).
Why CSA?
- CSA defines a risk-based approach to software validation with a focus on preventing the introduction of defects into the software development lifecycle (SDLC).
- CSA promotes using automation tools and other digital capabilities as they allow companies to reduce human error, better utilize resources and maximize value across the software development lifecycle.
- CSA provides examples of risk considerations, acceptable testing methodologies, and tips for capturing objective evidence for various software quality assurance use cases in the life sciences industry.
CSA adoption framework
The following step-by-step approach is intended to help companies establish a risk-based framework for computer software assurance throughout the software’s lifecycle.
- Draft an up-to-date listing of all relevant systems (inventory) with their intended use.
- Add context to the system inventory with information such as impact on production or quality system (direct/indirect), system risk level (high/medium/low/none), and other details such as vendor name, version no., system ownership, and implementation date.
- Determine system categorization and methods to implement the requirements.
- Determine functionality risk level (high/medium/low/none) for each requirement based on impact on product quality, patient safety, and data integrity.
- Use system categorization from step 4 and functionality risk from step 5 in a matrix to develop a risk rating (scale 1-5) for testing each requirement.
- Use the scale 1-5 from the above step to plan your validation process. Example: level 5 = scripted testing to validate requirements, and level 1 = relies on vendor audit and testing for system assurance.
- Conduct a periodic review of the computer system to ensure the system remains validated. Use the system risk level to determine the frequency and extent of the periodic review.
How Qualtivate can help
Qualtivate's right-sized approach and technology expertise has helped companies adopt the CSA model in weeks, not months.
Our team brings speed and agility in all GxP areas with an understanding of automation tools, software supplier management best practices, and regulatory compliance.
So now that you know the background of CSA and the step-by-step framework for implementation, the real question is, what changes are you making to your software validation practices to align with the CSA guidance?
/w=3840,quality=80)
/w=3840,quality=80)
/w=3840,quality=80)
/w=3840,quality=80)
/w=3840,quality=80)
