Verification and validation (V&V) are two distinct activities in the development of a product, but are not technically phases of development. This may seem like mere semantics, but bear with me for a moment, as I learned this lesson during an FDA audit myself.
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/build what I intended, based on the design input requirements?"
Design input consists of requirements that are related to either function, performance, constraints of the product or a combination of these. Most of the design output for a product is a document of one sort or another that indicates how these were achieved. Design outputs illustrate how to make, test, store, transport, use or service the designed product. Examples of these are:
- A drawing that specifies how subsystems comes together (functional)
- A manufacturing specification that explains how to connect the subassembly together for a pump or how to formulate a reagent (functional and contraint, cost of goods)
- A package insert that tells the customer how to use the product (functional, and constraint)
In addition to functional outputs, there are also performance outputs, such as:
- Mean time between failure measurements of how well a component works (performance)
- A service manual for a field service engineer (functional and performance)
- Reliability data on a sensor,
- How well a system works: accuracy, precision, linearity, etc data (just to name a few)
When most people think of verification, they think of the items in the last bullet point, and as a consequence of that they think of verification only as the actual collecting of that data. You will hear people say they are working on "verification protocols" or a "verification report" when in reality there are no such thing as verification protocol and the verification report would not be about accuracy or precision, or reliability, it would be about whether the output information matches the input information. That last bullet point is a system evaluation.
Why bring this up? It goes back to the fact that I learned this lesson during an FDA audit. There is more to verification, Horatio, than is dreamt of in your system evaluation! Many companies forget to look at all the "other stuff" in a comprehensive process that documents how the output meets the input. An auditor can ask for evidence that you met a requirement that had to do with labeling, for instance, and that won't be in the "verification report". What is worse is to show documentation that indicated that verficiation was done on one date and the labeling in question was actually finished a day or several weeks later. Zing! You have a nice observation in your 483 letter.
I now refer to certain activities as "collecting system data" for verification or validation. it may sound like sematics, but understanding that all of design output falls into verification may just save you from learning this lesson during an audit too.