V&V deep dive Part 1: The fundamentals
The first part in a series on one of the more slippery concepts in design controls
For such a central concept in medical device design controls, verification and validation is not very well understood by many med device professionals (nor well explained by the med device standards). In the first part of this series, I’d like to lay the groundwork for a clear definition of each of these terms. In later parts, I will address related areas that are subject to variation or controversy in the industry.
Background
Since verification and validation are terms describing the testing of a medical device, it will be helpful to first understand the general design and development method required in clause 7.3 of ISO 13485. ISO considers design and development in terms of inputs and outputs.
Design inputs are all of the requirements of the product design. If I want to design anything, I need to define the intended use first. For example, if I am designing a syringe used for delivering medication, I first need to define who the device’s intended user is, what environment/context the device is intended to be used, upon which patients with which conditions, what kinds of liquids it should be used with, etc… This intended use is what many call a high-level design input; it gives you vital information on the requirements of the device but has not yet been translated into detailed technical requirements related to the specific components, functions, technology, and operating parameters of the device. There are other high-level design inputs outside of the intended use: regulatory requirements, safety/risk-related requirements, usability heuristics, marketing/aesthetic requirements, etc… ISO requires documentation of all of these inputs. Although it does not explicitly require translation of these inputs into more detailed technical requirements, it does say that “requirements shall be complete (and) unambiguous”, so most med device designers will add a second layer of requirements that are more detailed and technical.
Design outputs are the items created using the design inputs, specifically the product and its accompanying specifications and packaging/labelling materials. So in the syringe example, the device design itself is an output, along with the engineering prints, bills of materials, assembly instructions, quality specifications, packaging, user guide, device labels, etc… Anything that fulfills a design input is considered a design output.
Verification and validation
Even though the terms are used extensively in ISO 13485, the actual definitions of verification and validation are housed in ISO 9000:
3.8.12 verification: confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
3.8.13 validation: confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled
Here’s an example related to our syringe:
Looking at the “matrix” above, you can see that the verification steps are designed to ensure that the technical requirements are met by the syringe design. But verification does not tell us whether those requirements were specified correctly - whether they can satisfy the intended use. For example, as a product manager for the syringe product, I might surmise that printing the scale gradations in black will allow the clinician to easily determine the volume of liquid inside the syringe. After all, the types of liquids used in the syringe are all bright or translucent colors that would contrast well with black, allowing good visibility of the scale. Verification will ensure that the design as implemented did indeed make the scale gradations black. But it does not tell me whether black was the right choice.
That’s where validation comes in. The validation steps are designed to evaluate the final product in a realistic use environment to ensure that the device, and by extension its technical requirements, are actually meeting the high-level design inputs (or in other words, user needs) related to the intended use. Generally this is accomplished through clinical studies and moderated usability studies, where real potential users can attempt to use the device for its intended purpose. In the case of the scale gradation color, as a validation engineer, I would design a moderated usability study where a real clinician is tasked with reading the volume of liquid in the syringe inside of a real (or simulated) hospital room with typical lighting conditions. This will tell me whether the color specified in the requirement can meet the needs of the intended use. If users have trouble accomplishing the core tasks related to the intended use, this gives the design team feedback that the implemented design, and possibly the requirements specified, need to be updated.
Keep in mind that validation only applies for high-level design inputs related to the intended use of the device. Other high-level design inputs, such as regulatory requirements related to labelling, do not require validation; verification of the related technical requirements is sufficient for these design inputs.
In the next part of the series, we’ll go into the concept of requirements traceability and some of the best methods for demonstrating it.
See the other parts of this V&V series:
