Verification vs Validation – Why do we still get them confused?

21 CFR 820 defines verification and validation as the following:
“(z)Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

(1)Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.

(2)Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).

(aa)Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.”

A wise mentor once explained the difference in plain English terms:

·      Verification – verify the product works as designed in the specification.

·      Validation – confirm the product works as stated in the intended use statement.

The best way to describe this is through an example: A hemodialysis machine is designed to clear the blood of toxins and other impurities at a certain rate per minute. The system is designed with a motor, tubing and pumps to move the fluid through the system. The motor was specified to run at 45 rpm and move a specified amount of fluid through the system.

·      Verification requires confirmation that the motor at 45 rpm moves the fluid through the system at the specified rate.

·      Validation is required to confirm the fluid moving through the system at the specified rate clears the patient’s blood to the level identified in the intended use or user needs. The system should be fully functional when this testing is performed. Some of this validation can be done in house. It is very likely that external studies and/or clinical trials would be required as part of the validation.

As you can see, verification and validation activities are two very different, specific activities within the development process.  Verification activities can be performed by the design team – preferably someone independent from the design of the function or feature. Validation (both internal and external) should be performed by a function that is independent and has no reporting accountability to the design development team.    

Regardless of the simplicity or complexity of the product, it is critical to understand the difference between verification and validation. If the user needs and design requirements are well documented and testable, it will be much easier to determine whether verification, validation or both are required.  

NOTE:  Process validation was intentionally not addressed in this blog. That topic deserves a blog of its own.

About the Author
B. Christine Park is a quality systems consultant with expertise in the implementation and remediation of sustainable and regulatory compliant quality systems. She has led the successful implementation of quality systems in large corporations, as well as small startup companies. Her industry experience and background supports compliant yet practical, pragmatic quality systems. She can be contacted at 678-480-5411 and cpark928@mindspring.com a href="http://www.enkap.com/profiles/blog/cpark928@mindspring.com">http://www.enkap.com/profiles/blog/cpark928@mindspring.com>
 
MORE THAN JUST SOPs! Christine Park will be conducting enKap’s upcoming webinar, September 8th, “Defining The Documentation Lifecycle That Best FitsYour Organization”  - Click Here
 
Related Content Package Available from the FDA Compliance Learning Community of enKap
Process Validation Content Power Package
 http://www.enkap.com/page/process-validation-content