Design verification checks if we built the product right, while validation checks if we built the right product for the user. Both are required, but they often overlap in testing and documentation.
Is it really necessary to have both processes separately, or could a more efficient combined system achieve the same confidence in safety and performance?
Thanks for your participation!
That’s a great question — it’s true that design verification and validation (V&V) can seem redundant at times, especially when tests or documentation overlap. However, they serve distinct purposes that complement each other. Verification ensures the device meets its design specifications — that all components function as intended and match the engineering requirements. Validation, on the other hand, confirms that the final product actually meets the user’s needs and performs safely and effectively in real-world conditions. Combining them could seem efficient, but it can also blur accountability and make it harder to identify where a failure occurs — whether in design execution or in meeting user needs. Regulatory bodies like the FDA require them separately for this reason. That said, a more integrated approach can streamline the process — for example, using shared test data or concurrent documentation — as long as each process maintains its distinct objectives and traceability. So, while total merging might risk compliance and clarity, structured integration can improve efficiency without sacrificing confidence in safety or performance.
An interesting perspective is how emerging development models (e.g., human-factors-driven design) are reshaping the distinction between verification and validation. In traditional systems, V&V has been more linear to align with regulatory expectations. However, in new iterative development cycles, teams now conduct multiple runs of mini-verification and mini-validation repeatedly throughout the design process. Thus, the questions "did we build it right?" and "did we build the right thing?" become far more intertwined much earlier in the process than they are treated as disparate topics.
In my opinion, this actually strengthens safety and performance, as it enables issues concerning usability, risk, or even specification gaps to surface at a much faster rate. Thus, maybe a salient future direction would be integrating V&V into a continuous, integrated loop rather than merging them into one step.
Based on the current direction of regulatory policy, do you think regulatory frameworks will evolve to support such a more flexible V&V model?
Since they are two distinct aspects of the product development process, it is important that both are still completed. Although they do overlap, sometimes more significantly than in other cases, it is important to perform both because they both still have individual aspects that the other does not test/check for. From a regulatory and technical perspective, they stand for different purposes. However, you can make it so that the V&V process is more efficient by trying to minimize the repetitive aspects while keeping it the evidence from each of the processes clear and easy to check if needed.
One thing to consider with these two processes is that due to FDA regulations, it often takes lots of time for products to get out on market. Sometimes, verification and validation are too extensive so being able to perform one test for the overlapping portions of the V&V process rather than 2 would make it significantly easier and waste less time. Although this could create some unforeseen errors in some cases, in the case of medical devices this should not be a huge problem for the most part. Finding the most efficient balance between the two and figuring out a way to somewhat expedite one or the other by using one to replace the other in certain cases could help to increase the production capabilities and improve overall process of product development and getting a device out on the market.
I agree that verification and validation have distinct purposes that keep the design controls objective and therefore reliable. Verification makes sure the device gets the technical specifications down, and validation makes sure that those specifications are actually solving the user’s problem. Something that no one else has mentioned is how digital systems are starting to blur the boundary between the two.
In Dr. Simon's lecture, he mentioned how design controls are a feedback system. Traditionally, these loops happen separately, but with new technology like AI, verification and validation can now happen almost simultaneously. For example, engineers can start using simulated human environments to verify the performance of prototypes and validate the usability before the prototype is even manufactured. This would reduce cost and time without removing either step. Then, traditional verification and validation can occur on the prototype that has already been virtually tested. This adds a second layer that combines both verification and validation. However, keeping a separate layer for the testing after the virtual one that I have mentioned makes sure that all bases are covered multiple times. This would allow for a system that combines both verification and validation, but also keeps them separate to ensure a triple-check system. The first step would be to test a larger variety of products quickly, and the best would be tested with the current system. This would boost output and efficiency.
I think a future challenge with this would be data management. When digital validation and verification become continuous, there can be issues with regulatory systems that expect discrete validation and verification reports instead of dynamic data. To fix this, the algorithms can perform both verification and validation at the same time and then sort data into the respective components that are required.
Do you think the FDA and ISO should start implementing changes to their requirements with the changing digital analysis times? Additionally, with the implementation of AI, how do we ensure that faulty training data doesn’t influence the initial verification and validation step? Should there be a verification of verification for AI-based systems?
FDA and ISO should begin to change their requirements. All of their requirements were written where the submissions were done in concrete steps. Many AI models have algorithms that can change after their initial training and these changes are most likely not accounted for in current regulations. Adaptive frameworks for validation where monitoring is utilized instead of a single submission is a possible path to go down. Regulatory bodies can develop requirements related to AI systems after a product makes it to market. Since AI is evolving daily, regulations related to how often AI systems should be retrained, if at all, are necessary to making sure AI based systems are safe and reliable. Verification of verification for AI systems can also be important for managing verification and validation. By evaluating metrics like bias and auditing data produced by the AI, a system can be made which helps verify the design of an AI system before AI can be used for verification and validation.
Having both design verification and validation as separate processes is necessary because they address fundamentally different questions in product development. Verification ensures that the design outputs meet the design inputs — it’s about technical accuracy, consistency, and compliance with specifications like dimensions, tolerances, software logic. Validation, on the other hand, ensures that the final product fulfills the actual user needs and intended use in real-world conditions. While combining them might seem efficient, merging them risks missing critical errors: a product could pass all technical checks yet fail to satisfy the user or perform safely in its intended environment. However, efficiency can be improved by integrating verification and validation planning early in development — for instance, by designing shared test protocols or leveraging simulation and user feedback loops — without compromising the distinct purpose each serves.