Computerised System Validation (CSV) is an activity carried out by Pharmaceutical and Medical Device organisations to ensure that IT infrastructure and applications that impact product quality are operating in a controlled state. Organisations must demonstrate an appropriate level of control of their Computer Systems to regulators such as the US FDA, TGA and EMA. Not only are these activities considered a GMP requirement, but at SeerPharma we believe putting in place plans and executing strategies to demonstrate this level of control, is Good Business Practice.
Although many guidelines, articles, conferences and training courses on CSV have been available for years, the maturity level of many regulated users and software suppliers remains low, with the outcome that CSV is not fully understood or effectively performed by all key stakeholders at many regulated companies.
Solution providers are typically too far from the regulated user's operating environment and regulated users are not able to clearly define requirements or expectations regarding CSV.
In addition, rapidly evolving technology disrupts and challenges the conservative approach to CSV.
To simplify the intent of CSV, the US FDA has drafted new guidance on Computer Software Assurance (CSA), which is set for release in 2020.
Although not yet officially released, people are starting to comment on what will be outlined in the guidance; and the impact this will have on current and future computerised system implementations.
The essence of CSA is for organisations to focus on using common-sense critical thinking to their Validation approach, as opposed to generating more documentation.
Before we look at the proposed changes (which are not as dramatic as some people are writing), let’s look at why the FDA thought there was a need for change.
There are several key concepts and definitions in CSV that are misunderstood. When these are understood, you will see that CSA equals CSV done correctly.
Figure 1: X-Model
Although the above X-model looks very complex, it is a pictorial view of the phases required to specify, design and develop all computerised solutions. The X-model is explained below.
Most purchased solutions will already have the bottom section performed by the vendor and some of the top boxes can be performed together on combined phases.
Important Definitions
Validation is the set of activities performed during each phase to ensure quality during that phase.
Note that for most projects all phases will not be needed.
Testing (red box) is the entire right side of the model. Note that this involves efforts from both vendors and customers.
Qualification (blue box) in the top right quadrant. Note that this is a subset of testing and performed mainly by the customer.
Notice that Documentation is not mentioned anywhere. This is because ‘VALIDATION IS NOT DOCUMENTATION’.
Validation is the set of activities you perform to raise the quality of that phase, and Documentation is the output of those activities.
Also note that Validation does not start at Testing (as the scope of the system, its actual requirements and the design of its operation has already been developed by then).
Just understanding that, and training everyone on your team to understand that, will go a long way to aligning people’s perception of CSV.
Reasons For Change
Although the above definitions may seem obvious when highlighted, they often get muddied when actual computerised systems are being implemented/validated.
In many cases, the software is already purchased, or projects are already being implemented before validation is even considered.
In these cases, unfortunately, validation does equal testing (and this is where the emphasis on test protocols and scripts has been focussed).
In an attempt to try to test quality into the solution, we have all been guilty of going overboard with trying to look like we have ‘fully validated’ a system by producing enough test evidence to justify this.
CSA – Just Like CSV But With Little To No Testing?
NO!
The CSA approach is not necessarily saying to do less testing. Using common sense, testing proves that the entire left side of the model above has been developed correctly. As such, when you apply critical thinking, you may end up with an outcome where less overall testing is required.
It may also dictate, that for some systems, you do more testing – but targeted testing.
In the end, it is saying to do the right level of testing (in fact the right level of requirements gathering and the right level of design specification) for each system.
This has been the intent of CSV from the start.
By taking the existing good principles of CSV:
- Validation must start as early in a project as is possible
- Use risk assessment in all phases of a system
- Document a sufficient level of requirements and design/configuration to enable for test scope and support of the developed system
- Validation (raising quality) is the responsibility of all on a project
And the key principles of CSA:
- Use the skills, experience and prior work form all key stakeholders to minimise current and future work
- Treat vendors as partners and make more use of their previous development and testing efforts
- Use the above risk assessments to justify levels of testing (ie. formal scripts, high-level cases, ad-hoc tests) against requirements and design elements
- Do not repeat verification and testing exercises
- All documentation produced must add value to the project/support of the system
By changing the mindset from simply introducing a ‘software product with some associated validation documentation’ to assuring an ‘automated solution has only enough support documentation to enable it to perform its task reliably and consistently’, you will have moved from performing CSV for an auditor to CSA for you own business.
SeerPharma has successfully used the CSA approach and is helping companies to move towards this less burdensome approach to Computer Software Assurance.
Contact us if you would like to know more about CSA, and how these proposed changes may affect your organisation.
- Interested in reading our thoughts on CSA?
- Article 1 : Computer Software Assurance (this article)
- Article 2: Computer Software Assurance - Risk and Reward
- Article 3: Computer Software Assurance - Use of Critical Thinking
- Article 4: Computer Software Assurance - Configuration / Design and Closing the Loop
