All too often, I see development teams get stuck when it comes to correctly defining design verification and validation requirements. They don’t know how to correctly define design verification and design validation requirements.
It’s not for lack of clarity from U.S. FDA. In 21 CFR 820.30(f)(g) Design Controls, FDA states, “Design verification shall confirm that the design output meets the design input requirements…Design validation shall ensure that devices conform to defined user needs and intended uses.”
It’s relatively simple; just go back and confirm that your design outputs meet all the design inputs and that the design conforms to user needs. The problem is that teams often fail to clearly define and document these important criteria during the product development process. When they reach the design verification and validation stage, they get confused because they didn’t do the work upfront. Not only are user needs and design inputs undefined, they are not linked to design outputs.
Defining design inputs has a long history going back to ISO 9001 requirements for quality management systems. It’s absolutely required for medical devices as well in 820.30(c), which reads, “The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s).” It also says, “Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.”
However, too many teams work through these phases just to check off a box. Rather than simply completing a checklist, there is value in establishing well-thought-out user needs and design inputs which will make design verification and validation easier. It also ensures you’re developing a product that will meet the needs of the customer.
To better understand this, let’s think backwards through the design process.
Design Outputs > Design Inputs > User Needs
Design outputs are any details on drawings or in specifications that define the product. FDA requires, “Design output procedures shall contain or make reference to acceptance criteria and shall ensure that those design outputs that are essential for the proper functioning of the device are identified.” How do you ensure that your design outputs contain or make reference to acceptance criteria?
Let’s look at an example. A drawing for a screw requires blue anodizing. Another screw in the same family requires red anodizing, while yet another requires yellow. These colors are design outputs. There is likely a design input that is driving these outputs. The input could be “color coding will be used for diameter identification.” The user need driving the need for color coding is probably something like, “The screw diameter needs to be easily identifiable.” The acceptance criteria for the color anodizing output for these screws would be, “It must provide the function of using color coding to identify the screw’s diameter.”
Design validation then becomes straightforward. The validation test needs to determine whether the user can successfully identify the diameter of the screw based on its color. Can the user distinguish among blue, red and yellow? Design verification is also clear. One only needs to verify that the output of “blue anodizing” meets the input requirement of “color coding will be used for diameter identification.” When you think backwards like this, the steps become certain.
Design inputs drive design features and product performance. User needs are the basis for design inputs. Successful design validation testing stems from understanding intended uses and user needs and documenting them clearly. When user needs and intended uses are documented, consider how these will be validated.
In the example, the user need, “The screw diameter needs to be easily identifiable,” using “easily” could be troublesome. How do you define easy? How do you validate that it’s easy? A better definition of the need would be, “The screw diameter needs to be visually identifiable without removal from the tray.” There is no longer the ambiguity of “easy” and validation is straightforward. It’s important that the user need defines the true essence of the need. During voice of the customer activities, it’s important that the need be defined at the most basic level.
It’s important to note that user needs are not limited to the needs of the patient or surgeon. I gave some real-life examples in a previous webinar about how failing to meet legal or business needs can be detrimental to companies. Designers must capture complete and accurate user needs for successful product development.
Circling back around to design verification and validation, design verification answers the question, “Did I make my design correctly?” Design validation answers the question, “Did I make the correct design?” Both of these questions are really difficult to answer unless you can trace design outputs to clearly defined design inputs and user needs.
Properly Document Your Steps
When people don’t take the time to fully develop obvious and unambiguous user needs and inputs, they trip all over themselves later in the new product development process. Poorly defined and documented user needs and design inputs not only affect the introduction of new product but also affect the evaluation of future design changes.
FDA requires that all design changes be verified. Design changes must also be validated unless the performance of verification can justify that validation is not necessary. If user needs, intended uses, design inputs and outputs were not clearly documented during initial product development, the change process evaluation, design verification and design validation can be very difficult.
While FDA requires that you document user needs and design inputs/outputs, it doesn’t specify exactly how you should do it. I think including them in the design failure mode and effects analysis (dFMEA) works well because it ties everything together. Consider creating one large spreadsheet with all your user needs driving inputs, features and outputs. Consider even including the voice of the customer. Having everything together will be helpful when documenting that design outputs meet the input requirements and as a reference for testing requirements.
If you have had problems with design verification testing and design validation in the past, think backwards. The most likely cause probably lies in the fact that something was not defined clearly or there was no clear link to design outputs. Thinking backwards will help you avoid these pitfalls in your next project.
Dale Tempco is a medical device consultant specializing in product development, operations, quality, design for manufacturability, supply chain, M&A and finance. He has expertise in low-cost sourcing, design transfer, special process validation, cleaning validation, QMS, additive manufacturing, failure analysis and cost accounting, and has extensive global experience in China, Costa Rica, Europe.