Companies that are regulated by the U.S. Food and Drug Administration (FDA) are required to perform validation to prove their software and systems are performing correctly. That’s why, with relatively few changes, we have been using Computer System Validation (CSV) for over 20 years in the regulated sector. The FDA’s first Principles of Software Validation, and later ISPE GAMP, continue to be the main go-to guidance and principles to help implement CSV.
A Love – Hate Relationship
Those that have been using CSV throughout the years know, love, and hate it. FDA’s and ISPE’s guidances were initially set to make it more effortless. Now we are facing new frontiers in validation, like the cloud, deeper automation, and complex 21 Code of Federal Regulations (CFR) Part 11 compliance solutions.
With this ever-changing technological landscape, ambiguity and inconsistencies are once again introduced. In addition, CSV has become a tool for getting companies into safe waters and providing heaps of documentation just for audit purposes.
Since the FDA is one of the leading auditing agencies, it became apparent to them that, in conjunction with the evolution of technology, the gap in guidance is getting bigger.
This is where Computer Software Assurance (CSA) comes in.
Pain Points of CSV
The industry came up with so-called Pain Points on CSV, which are seen as a hindrance in using technology advancements to their full potential.
These pain points include:
- Automation discouragement
- Audit evidence focus
- Unacknowledged supplier documentation efforts
- Complex risk assessments
- Human error responsible for 80% of deviations
- Post-go-live problems
Drafting Up the Computer Software Assurance (CSA)
Set for release in the fiscal year 2020, the FDA has drafted up a guidance to Computer Software Assurance for Manufacturing, Operations, and Quality System Software to address the pain points in the following ways:
- The FDA’s general view of automation is basically a “green light” for companies. The agency encourages the use of automation, their tools, and underlying IT solutions. Because, at the end of the day, automation provides advantages by reducing errors in testing, optimizing the usage of resources, and ultimately reducing patient risk.
- Since CSV requires a very heavy use of documentation, more often than not it is done without real critical thinking. CSA attempts to shift this paradigm back to a critical thinking approach, focusing on main patient risks with more concise testing and less documentation.
- Even with a trusted or audited vendor/supplier, companies tend to reproduce documentation. Now, with the new CSA guidelines, if the vendor documentation is in place and of good quality, then it should not be reproduced. Efforts are not be used to repeat vendor documents. Instead, the effort should be shifted to make sure that the software works "For the Intended Use" in the customer’s environment.
- The FDA wants companies to focus on the intended use. That means limiting your risk assessments to a clearly-defined system’s usage scenario. A good example is Software as a Service (SaaS): there is no need to validate its out-of-the-box features.
- The use of risk-based testing ties into the focus of the system’s intended use. CSA recommends a streamlined risk assessment process with two variables: potential impact on patient safety/product quality and the implementation method of the functionality. There is no longer a necessity for the burdensome Failure Mode Effect Analysis (FMEA).
- Instead of scripted testing scenarios that focus on documenting the steps and less on testing the system, CSA guides companies to use a more sensitive approach with unscripted testing. The testing is still documented, but now free test objectives can be defined without detailed test steps. The lack of detail is seen as the primary reason in the drop of tester and test script errors.
All of these points are coming together in the upcoming Guidance on CSA and, as you can see, the FDA is on top of the technology evolution in recent years – and so should you.
Start your internal pilot studies, update your standard operating procedures (SOPs), implement the paradigm shift with training sessions, and even better, go completely paperless in the process.
We are looking forward to having the full guidance document on Computer Software Assurance finally in our hands soon. And, of course, we will keep you updated.
Any concerns? Reach out to us! We are here to help answer any questions you may have.