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.

Both processes are necessary to ensure the product pleases two key stakeholders: the company itself and its customers. Maintaining this distinct difference between them enables specialized processes that cater to the target audience(s).

Putting it together would unlikely be effective. On paper, it sounds great since one can prove & document both the specifications of the design and the customer’s positive feedback in one step. However, it may overcomplicate the amount of inputs required to achieve the same (or better) outputs that the current separate processes deliver. Further, verification and validation rely on one another; the outputs of the design verification become the inputs of the design validation.

As I’ve stated in other responses, to quote Dr. Simon: “Inputs must equal outputs.” The inputs always derive from outputs of the previous step/process, including the effectiveness of the work from inputs preceding it. With the current separate process, it is much simpler to narrow down where a fault may have occurred from a previous process through a root cause analysis. If we were to combine the verification and validation processes, it would bottleneck all of these inputs/outputs to the point where they may become overwhelming to track, even with the most organized document management system. 

For example, the same logic could be applied to the Design planning, input, and output processes. Combining these steps would involve many more variables to maintain (namely, documents such as DDPs, DIDs, and DSDs, as well as coordinating with other departments for the project). Without clear separation, the planning, design, and verification stages could become confused without precise organization. This is the main concern that would arise in combining design verification and validation.

Verification and validation are both essential processes in medical device development, each serving a distinct and critical purpose. Verification ensures that the device has been designed correctly by confirming that design outputs meet the specified design inputs. In contrast, validation confirms that the right device has been developed, one that meets the needs and expectations of the end users in real-world conditions. Skipping either process can result in devices that technically meet design specifications but fail to perform safely or effectively in clinical settings. Verification focuses on accuracy and compliance with design requirements, while validation emphasizes functionality and user satisfaction. Both are required by regulatory bodies like the FDA to ensure product safety and reliability before market release. Ultimately, verification and validation together provide confidence that a medical device is both properly engineered and truly fit for its intended clinical purpose.

I am a proponent for extra precautions being taken no matter how similar the steps may be because it is easy when as a company the goal is to simply meet deadlines to just miss a major flaw, so I personally think that companies are benefitting from having the two stages. I understand that they serve two different purposes and those can easily overlap, but it helps to pinpoint issues and ways to improve the project. For example, a product can function perfectly, but it may be extremely difficult for patients to use alone as it is confusing, so the validation step forces the designers to innovate and create a solution that better aids the users. This can become a big issue because as engineers the goal is to solve the issue, but that can lead to ignoring certain aspects such as ease of use and how complex the solution is, so it is more important to have V&V to help mitigate these problems. It can be difficult for companies to pay and still meet deadlines with these two steps, but I think someone bought up the concept of possibly introducing mini V&V throughout the entire development process, which I think is a much better solution because it forces the designers to quickly address issues as they arise, because it can be much harder to make changes at the very end. Also, I think this will probably make the final product better and allow more time efficiency because designers are not rushing to fix problems at the end, where there is a higher likelihood of missing certain aspects. 

Even though verification and validation may seem similar, they do serve different purposes. Verification is focused on confirming that the design meets the technical and regulatory requirements. Validation makes sure that the product meets the user's needs and performs efficiently and effectively in real word conditions. If these steps were combined, there is a risk of overlooking the needs of the user or missing design flaw that only show during practical use. Keeping both of these things distinct gives a bigger chance that the final product is safe.