You say validation and I say verification….lets call the whole thing off?

Validation and verification are frequently mentioned in tandem.  They're often called V&V, but what is the difference, what do they have to do with design control and how do they relate to process validation?  These are some of the most-asked questions that we get just about each day.

To get a good understanding of this, we need to start with who defines these terms.  Most folks have gone to the dictionary where validation can mean:

“the process of checking that something satisfies a certain criterion,”

and verification can mean:

“additional proof that something that was believed is correct”

It doesn't help that "verify" means:

"confirm the truth of", or "check or regulate by conducting a parallel experiment or comparing with another standard"

or that in software, validation means,

"the process of evaluating software at the end of the development process to ensure compliance with software requirements"

These are perfectly good definitions, and if all you were doing was creating a software product that was not an IVD, then the validation definition for the software would be sufficient, but when dealing with in-vitro diagnostics, you need to go to the FDA’s Design Control Guidance for Medical Device Manufacturers to make sure that you are on the right page.   In the guidance you will find what is referred to as the “Waterfall Diagram of Development”.  Understanding this diagram will help you keep these terms straight.  The figure on the right above illustrates the distinct phases of development:

• Generation of input requirements
• Design itself
• Generation of design output
• Transfer to Operations / Production

Verification in its most simple terms is the actual comparison of design output with design input.

When doing verification you ask yourself the question, “Did I design what I intended based on the design input requirements?”  When all the developers are done designing or have “frozen the design”, then the output generated can be compared to the input created at the start of the project.  If they are in agreement, then verification passes and design is done.  The project can move on to transferring the design to Operations.

So what about validation?  Again, using the definition from the design control guidance, validation is determining that the product developed meets the customer’s needs. 

In other words, “Did I design what the customer wanted?”  While you might be asking this question in order to understand what happens in validation, this is not the first time your customer is seeing your product.  Customers should be in-loop, at a minimum, while you are generating the design input requirements, and depending on how complex the product is, at various points throughout the design phase.  When the design has been frozen, the product is put into the hands of the customer (known as a "clinical trial") to collect objective evidence in order to demonstrate that they can achieve the same performance as the manufacturer can in house (with assumed “experts”).  Some companies will wait until verification is completely done before starting validation, while others will collected limited data in house before starting a clinical trial, which approach you take depends on how much project risk the company is willing to accept.

The conclusions of either action, verification or validation typically warrant a design review and a report.  The reports as well as the documentation from the design reviews are stored in the design history file. 

How does process validation fit into all of this?  It is related only in terms that you have designed processes that will be transferred to Operations in order to manufacture the product.  Before you can do this, each process must be validated or shown to be in control.  The FDA has a guideline for process validation, and in it states:

"Process validation is establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product  meeting its pre-determined specifications and quality characteristics."

So while verification and validation about the product itself, process validation is about making sure that you can build the product consistently.  I like to think of it in terms of, "If you can't build it, they won't come!", no matter how cool the product design is.

Tags: Design Control, Documentation, FDA 101, IVD, Software Validation, V & V