The FDA draft guidance on Computer Software Assurance is a paradigm shift from document focused computer system validation to critical thinking assurance practices. The Guidance is on FDA’s list for release in September 2020 and applies to non-product quality system software solutions. The principles and approaches will apply to all regulated organizations.
How it all started
The concept of validation was derived from engineering validation principles that have been extended to the software industry. Feeling the necessity to validate computer systems, the FDA published the ‘bluebook’ (1983) this was a guide to the inspection of computerized systems in pharmaceutical processing.
These regulations on the use of electronic records and electronic signatures are formalized in 1997 in 21 CFR part 11 the FDA and revised in 2003, for Eudralex (EU GMP regulations) this is Annex 11 (EME 1998).
According to both computer system validation is defined as: “Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled”
Purpose and initial need for CSV
The purpose of the validation process is to provide a high degree of assurance that a computer system will consistently produce electronic records which meets predetermined specifications and quality attributes.
FDA regulations mandate the need to perform Computer System Validation and these regulations have the impact of the law. Having the evidence that computer systems are serving their intended purpose and operating properly represents a good business practice.
Failure to take corrective action immediately can result in shutting down manufacturing facilities, consent decrees, and stiff financial penalties.
Why we need a new approach
The Guidance on computer system validation is already dating back to 2003 in a rapidly changing digital landscape and is no longer aligned with new technologies. This makes it unclear on how much testing is enough and where to focus that testing.
FDA believes the use of automation, information technology and data solutions throughout the life cycle can provide significant benefits to enhance quality and patient safety. This substantial benefit in enhancing quality is shown in other industries utilizing thorough automation.
At this moment CSV is an obstacle in the process to move to a more automated environment, this due to the required extensive testing and comprehensive documentation that demonstrate the validation of computer software.
To support the use of this new technologies FDA is drafting new guidelines “Computer Software Assurance for Manufacturing, Operations, and Quality System Software”, CSA will tackle the issues we have at this moment with CSV.
Additionally, FDA intends to focus on direct impact systems and not on the indirect systems (support tools).
The paradigm shift of CSA
The new paradigm will focus on critical thinking (risk-based), assurance needs, testing activities and documentation in that order.
Risk determination should focus on:
Does the software impact patient safety?
Does this software impact product quality?
How does this software impact your quality system integrity?
Comparison CSV VS CSA
Focus on creating documentary records for compliance VS Focus on testing for higher confidence in system performance
Validating everything with the risk to miss higher risk functionality VS Risk-based assurance, applying the right level of risk to patient safety and/or product quality
Ignoring previous assurance activity or related risk controls VS Taking prior assurance activities into account and upstream / downstream risk controls
Thus flipping the paradigm right-side up:
Example of a risk-based approach
It is important to have a structured way of assessing the risk involved in the software applications you use. The risk assessment will include the risk to patient or product, the impact of the application on the QMS. This information in combination with how the software is implemented can define the risk rating and determines
There will be more flexibility when it comes to assurance approach and acceptable records of result and this based on the risk level. This varies from ad-hoc testing (only a summary document is required) up to robust scripted testing like we used today.
CSA path through a critical thinking process
Identify the intended use
The new CSA approach starts with identifying the intended use.
Moreover, formal change control is essential. Any change to automation features, functions or operations should follow the CSA process to ensure a system is maintained in its appropriate state.
Determine the risk-based approach
Identify the automation features, operations, or functions that directly impact product safety, product quality, or quality system integrity.
Determine when a failure of these identified automation features, operations, or functions to reliably perform as intended will result in a direct patient safety risk.
Establish appropriate risk-based assurance activities that are designed to ensure that the identified high-risk features, operations, or functions of the automation reliably perform as intended.
Methods and activities
Where CSA value begins to shine is in leveraging other's activities (e.g. supplier documentation and tests). The biggest payoff is with medium and low-risk features where little or no rigorous effort is required.
Leverage existing activities and supplier data.
Leverage the use of process controls to mitigate risk.
Use of computer system validation tools to automate assurance activities.
Use Agile testing methods and unscripted testing as appropriate.
Use electronic data capture and record creation.
Leverage continuous data and information for monitoring and assurance.
Develop a least-burdensome record of assurance activities that considers the intended use (what needs to be assured).
Determination of the features, operations or functions impact and risk level; the identified assurance needs, and the evidence captured to demonstrate acceptance of the results.
The record needs to be of value to the organization, not the auditor.
A look ahead to the transition of CSV to CSA
The guidelines are haven’t been released yet and also the implementation will take some time.
Meanwhile, you don’t have to sit still and you can start with:
Change the culture from a compliance-centric mindset to quality-focused culture.
Know your suppliers (perform supplier audits).
Know the intended use of your computer system.
Know the high-risk features, operations and functions of the computer application.
Know the existing gaps in your current validations.
Have a plan to close the gaps.
As a final conclusion we can state that the riskier a computer application, the more documentation and testing is required. The release of the CSA guidelines will support companies who have taken the path to automation, this will definitely lead to lower patient risks and higher quality medicine.
Blog by Bart Degroote