by Mag Corduff (QA & Compliance Lead) & Mairane Costa (QA Associate)
The traditional approach to Computer System Validation (CSV) has been around since the introduction of FDA 21 CFR Part 11, 1997. Since then, CSV has often been described as a burdensome exercise for audit proofing, an exercise which results in large paper-based documentation packs with large volumes of screenshot or printout attachments.
Delays to validation exercises are often due to rigid test structures or documentation issues, either through creation of burdensome testing, test script generation errors or as a result of misplaced screenshots / printouts, and/or incomplete screengrabs. Many of these “issues” have little or no impact on the actual use of the system or on its validated state.
Now more than ever it is time to rethink our traditional CSV approach. An approach that aligns with Computers Software Assurance (CSA) will result in the implementation of computer system software in an efficient and innovative manner while remaining in compliance with regulatory requirements & GAMP 5.
The draft upcoming FDA guidance on “Computer Software Assurance for Manufacturing, Operations, and Quality System Software” is listed by the FDA for publication in 2021 and is eagerly awaited by many in the Life Sciences industry. Computer Software Assurance (CSA) is a new way of looking at the traditional Computer System Validation (CSV) approach through application of critical thinking and consideration of risk whereby the focus is on what matters – patient safety, product quality and data integrity. CSA applies to non-product systems only.
“With the move from Computer Systems Validation (CSV) to Computer Software Assurance (CSA), it is time for us to rethink our traditional CSV approach.”
A system must be validated for its intended use. However, the validation should be commensurate to the level of risk to patient safety and product quality. The upcoming CSA guidance document brings no change to the current governing regulations or to GAMP 5; the requirements remain the same.
Following the CSA approach, however, means that validation activities are designed around testing the critical aspects in an efficient way. Avoiding unnecessary activities and bureaucracy, critical thinking and a risk-based approach are used to ensure that testing focuses on the features or actions that pose a medium / high risk to the patient safety, product quality and/or data integrity, with less focus on the lower risk features of the system.
The current indication is that the shift towards CSA should be considered for the validation of those non-product, manufacturing, operations and quality system software solutions, e.g.
- Electronic Quality Management Systems (eQMS)
- Electronic Document Management Systems (eDMS)
- Electronic Drawing Management Systems
- Learning Management Systems (LMS)
- Laboratory Information Management Systems (LIMS)
- Enterprise Resource Planning (ERP) systems
A good CSA program can be easily implemented and will benefit from a strong Quality Management System.
Consider the following:
- A strong supplier assessment program will ensure that the user is satisfied as to the quality of the software / computer system being purchased. A thorough supplier audit may provide justification to allow the user to leverage some supplier testing, i.e., do not repeat testing already performed by the vendor (get value for your money), e.g. for Software as a Service (SaaS) if the vendor has a strong QMS in place and has already validated the system, then there may be no requirement for the user to re-validate the out-of-the-box features.
- Use a risk-based approach, or your in-house risk management process to define what functions, features or aspects of the computerized system are high-risk to patient safety, product quality and/or data integrity. These high-risk areas require scripted testing, but it may be possible to justify ad hoc / non-scripted testing to challenge the other aspects that cannot be leveraged, or also, per above, it may be possible (dependent on the quality of your supplier, their QMS and their internal processes) to leverage testing performed by the supplier so that repeat testing is not required.
- A strong internal change control process will ensure that only those aspects of a system that have changed require consideration for validation testing. Consider verification activities for anything that hasn’t changed.
- Strong internal processes and procedures along with adequately trained and competent personnel will reduce the need for detailed test scripts. If possible, reference detailed procedures for instructions rather than repeating the information within test scripts. Be critical about what evidence is required. Is evidence (e.g. screenshots) required for each test step, or is it appropriate to only include evidence for test steps that fail to meet acceptance criteria or for any deviations to test requirements?
- Where possible, use testing tools for automated assurance activities instead of manual testing. Automated tools provide the advantage of reduced errors in testing, maximizing the use of resources and can reduce risk. Follow an Agile approach for development and consider unscripted testing as part of the validation approach for low risk testing.
- Finally, ensure you know the intended use of the system. Keep that in mind when defining what is required.
To reiterate, with the advance of the CSA Guidance from the FDA there is no change to the current governing regulations or to GAMP 5. A validation approach defined using critical thinking with a focus on risk and collaboration between the computerized system process owner, the validation team and Quality Assurance will ensure that the system is validated for its intended use, with emphasis on testing those high-risk features; testing should bring value without undue burden of paperwork.
