The past of Computer Systems Validation has served us well and provided us with the foundation of where we are today. But at some point, the past can become a burden. This is exactly the point in time where we have arrived.
Computer system validation has been around for a while, certainly since the introduction of the FDA regulation 21 CFR part 11 in 1997. The related Guidance for Industry is already dating back to 2003. Since then the digital world has evolved at an ever-increasing speed. The regulations and the way validation is considered however did not change significantly. Today, we are faced with incompatibility between CSV and for example AI, automation systems and other emerging digital technology solutions. While all this technology enhances support of Manufacturing, Operations and Quality, CSV remains an obstacle in this progress due to the extensive structured testing and documentation that is required to demonstrate the validation of computer software. This is where Computer System Assurance could do better. CSA is expected to focus on what matters: system quality instead of documenting for the sake of creating documentation. The FDA, recognizing industries CSV challenges, has announced new guidance on “Computer Software Assurance for Manufacturing, Operations, and Quality System Software.” This new guidance which is expected to be released in the coming months is much awaited.
Computer System Validation
CSV is ‘’a confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that particular requirements implemented through software can be consistently fulfilled’’. This implies that in the industry, a validation approach results in an extensive set of test and other documents.
Computer System Assurance
CSA proposes “a set of activities or actions to be performed to give confidence that the software functions as intended and meets the organization’s needs’’. These activities can include solution selection analysis, vendor history and data (which can be reused!), market performance data, installation activities, factory acceptance and risk-based testing.
What’s the difference already?
Stated shortly: less compulsory paper work. Why?
In traditional CSV, documentation is key to demonstrate compliance. Detailed scripted testing activities have to cover every click and function of the system. Critical thinking is in this approach almost completely subdued by the pressure of Good Documentation Practices and strict validation testing activities.
In CSA on the other hand, critical thinking is key. This approach leads to a more commensurate amount of evidence and documentation.
How to CSA?
The risk-based approach of CSA can be divided in four main steps:
- Identifying your intended use
- Determining a risk-based approach
- Deciding on methods and activities
- Documenting the appropriate records
Regarding the intended use it is important to assess whether specific features impact patient safety, quality or data integrity. This assessment drives the entire risk-based approach leading to assurance and evidence were it matters. Testing tools for automated assurance activities should be encouraged over manual testing. Both Agile development and unscripted testing can become part of the validation approach as appropriate.
What the future will give will remain a mystery for quite some time. The CSA guidelines haven’t been released officially yet and implementing them will certainly take some time.
As a conclusion: ‘’Do not reinvent the wheel every time you implement a new piece of software or every time you upgrade your software. Utilize the appropriate combination of CSA activities to drive enhanced quality and safety resulting in reduced patient risk’’.