Process Validation
I have always liked the saying “with all this kit we are bound to catch a fish”, and for me, it epitomizes all that is wrong with process validation. Simply translated it would read “but look how thick the validation file is, it must be ok”. This is a little superficial so let me cut to the chase, validation is not an exercise in documentation, it should be the pursuit of process understanding. This endeavor being undertaken to answer the primary question: -
What process variables are critical and what effect therefore do they have on product performance?
Now, let me jump back in time to when I was a young, cocky development engineer. I, along with some colleagues, had just had some great training on process validation from Pfizer. At the same time, we happened to take on a mathematics intern. Also, we were working on a very tricky device requiring a lot of process steps, like thermoforming, gluing, welding, coatings etc. So, we had an intersection of complex processes, validation requirements and mathematics capability.
As a result of this convergence, we elected to scrap the Operation Qualification stage of validation, I know, shocking! We did however replace it with Evolutionary Operation (EVOP), which is an optimization methodology dating back to the 50s. It basically is a structure design of experiments which ultimately establishes which process variables have an effect; by how much and their interrelationship. Tip – its value is proportional to the quality of the experimental response, so take time to decide what to measure and importantly make sure you can trust that measurement (true cause and effect). And no, we didn’t have the luxury of Minitab then.
So, one of the processes we validated was spin welding a container lid made from high density polyethylene. I was convinced I knew which variables were important, but we ran EVOP and of course I got it completely wrong! This was a great day for me as I now understood the value of structure process optimization and that data should be used to make decisions. Don’t get me wrong, I didn’t drop all intuition there and then, it was simply improved in that one moment with a desire for proof.
Now, not wanting to be contradictory, of course Validation must be well documented. Trust me, you don’t want to defend a poor validation pack relying on misdirection. But what I see too often is validation being overly dominated by unnecessary paperwork. I have no idea why documentation held within the QMS must be fully copied into a pack or why it can’t contain deviations within the process itself etc.
Recommended by LinkedIn
Another primary issue I see is the lack of critical thinking when developing the Validation Master Plan (VMP). If you are doing something standard, then following a traditional approach is OK. Let’s now take retrospective validation, which really should be rare these days, as an example. Remember good validation should be risk based so it may not even make sense to start retrospective validation with IQ of the processes, particularly if you are hopefully using verification. Where would I start in this instance? I would review the verification methodology validation. Yes, believe it or not I have seen verification conducted with a non-validated method.
So, what’s my point? Well, it’s a reminder that validation should: -
· Be given the resources and time to be conducted well, irrespective of commercial pressures. The better the optimisation the less risk to product performance out in the field.
· Start with a VMP that is designed for purpose, not just cut and paste.
· Be documented well, with good evidence, but with quality assisting this to be lean.
This should in turn ensure Engineers do not lose that inquisitiveness that they had when they used to take their toys apart.
Well writen that Chris👌🖖
Hi Chris, agree with you no nonsense approach, the value is in the quality of the learning and the results. Enjoyed reading your article.
Nice one boss, I enjoyed reading that.
Fantastic Chris. Was literally talking about something similar to this last week.