I have been actively involved in computer system validation activities since 1995 and have witnessed the maturity of validation from the early days of “what does validation mean?” to the current standard of GAMP 5. During the industry shift toward Quality risk management (QRM) that was brought front and center with the FDA’s report “PHARMACEUTICAL CGMPS FOR THE 21ST CENTURY — A RISK-BASED APPROACH”, validation activities began to be right-sized based on their risk profile. It was a small adjustment that grew as people became more confident with risk management. GAMP 5’s publication in 2008 further enabled practitioners to adopt risk-management thinking in validation activities.
Yet, I still encounter people who see validation as a check-box exercise; worse yet, as an add-on to a system development project. Most people involved in validation work for any reasonable time period can describe a project (or several) where project managers wanted to take a coded, configured system and “validate it”—preferably in 2-3 weeks, please. Fortunately, the message is slowly getting out and these behaviors are slowly dying.
Today, I see a more subtle issue of the check box: it is the cookie cutter validation process. It is easy to understand how it comes into practice: “we have done this process for years and it worked in the past. We survived inspections with it, so it is good enough”. And in their defense, there are a (narrow) set of circumstances where this approach is valid. But what gets lost in this approach is important to both business and customers: cost effectiveness.
To use our resources in the most effective manner, we must be willing to put our cards on the table—all of them. We have to stop asking the old question, “what is necessary to validate this system?” and answer the most important question: ”what are the risks in using this system?” One of those risks would be, “the system does not work as described by the vendor/development team”. Now, how do we mitigate that risk? Easy—we use this process called validation to assure us that it does work as described in our requirements. With this response, we are prepared to move beyond the checkbox mentality. We have reached a truth worth repeating:
Validation itself IS risk management.
Why does this matter? Don’t we already do risk management as part of validation? Well, yes, we do some risk management—mostly around testing, where we decide what will not be tested due to a lower risk score. But what we miss by starting with validation rather than risk management is the opportunity to place the system in control, knowing the largest risks have been addressed in the most efficient manner. Risk management is the means of identifying and addressing the most pressing situations; in contrast, validation is the vehicle for carrying out activities deemed as necessary. And what activities are necessary? All those risk mitigations needed to reduce high/medium risks to acceptable levels of control (residual risk). So the sequence is more like this:
Business requirements -> Risk identification -> risk evaluation -> risk prioritization ->risk mitigation -> validation planning -> validation activities -> residual risk management
By recognizing that risk is the driver—not validation planning—we will implement validation activities in the most efficient manner, mitigating the largest risks with our validation activities.
References
(2) GAMP 5 Guide: Compliant GxP Computerized Systems. ISPE. February, 2008.
Originally published by Mark Newton (Principal) on 16 May 2018