Validation, to put it plainly is a Quality Assurance documented process that confirms a specification or situation, through providing objective evidence. The Validation process is performed by a testing authority such as Metrocert Validation & Consulting.
Validation is nonetheless a complex concept. In our line of work we mostly deal with something called Retrospective Validation, which is a process for devices and systems already in distribution or use. Consequently, this type of Validation process is performed against the product/item specs, which basically means that we expect certain results based on what the manufacturer tells us, and we test to see if these specifications are actually true. Besides using product documentation, in certain use cases we are able to use historical data and evidence that has been previously recorded. If critical data is missing, the Validation process cannot be fully completed, thus it is important to ensure a smooth collaboration between the testing authority and the client.
As we have been in this field for quite some time, we’ve understood that concepts like Validation and Qualification sometimes overlap. They are often confused, even by the best of QA. So we plan to untangle this confusion in our Validation vs Qualification section, right in the next tab. We say “versus” because we know a good contest between concepts is attractive. But once you get to this section, you will understand that Validation is quite the friend to Qualification.
Retrospective Validation involves Installation Qualification, Operational Qualification and Performance Qualification.In short, IQ/OQ/PQ. More details about Qualification are available in our IQ/OQ/PQ section. An integral part of Prospective Validation worth mentioning, is Design Qualification (DQ), Typically however, this is done by the manufacturer.
As it is becoming clear by now, the concept of Qualification (IQ/OQ/PQ) is an integral part of Validation. While Validation refers to a process, Qualification is all about the equipment.
In order to better understand the hidden meaning of all these concepts, let’s look at it this way: In order to perform a process, we must understand that the process itself has a multitude of components that ultimately contribute to its success. We need equipment, systems, personnel. In certain cases, systems use software. People use systems, equipment and software, thus they require training. Each of these system components need to be qualified, individually or as a complex system. Once we have successfully done the IQ, OQ and PQ for all components that are part of the specific process, implicitly checking the calibration status of certain components, verifying internal and external components, we can consider that specific process validated.
A process can be viewed as a standalone instance, or a part of a bigger, more complex process. There are instances in which, due to certain particular circumstances that can arise, we can validate certain simpler processes that involve a succint number of system components. So, for such instances, we can say that we validate a process that is a simple one, perhaps the exit branch process.
Such an instance is applicable in the case of Passive Cold Boxes, i.e. the Cold Boxes that have passive cooling through cold bricks or bags.
For Passive Cold Boxes a very important part of the Validation process is to determine in a simple and coherent fashion, two base criteria :
a. Determining the optimal number of cooling elements for a ColdBox and how place the passive cooling elements in an optimal fashion.
b. Determine how much time, within the specific configuration and process, the cooling conditions of such a passive system last. Tests are performed under various types of situations, for various external climate conditions.
As opposed to active, electrically powered systems, passive systems will have a progresive increase in temperature from the lower allowed limit to the highest (maximum) allowed temperature.
Electrically powered systems do not have such a limit, except perhaps the MTBF of the system or components of the system, thus it is assumed that they will undergo a more complex validation process.