When verification tests fail, the first step would be to distinguish between a test design issue and a device design issue. For example, a medical device might be designed to operate within specific temperature ranges, but if it overheats during use, the failure stems from a flaw in the device’s design, such as insufficient heat dissipation. Similarly, a wearable medical sensor could fail because its adhesive doesn’t stick to various skin types, or a surgical tool might break under expected stress due to a material defect. These examples show that the device, not the test, is the root cause.

As a project manager, addressing such failures starts with gathering a cross-functional team (engineers, quality assurance, and regulatory experts, etc) to perform a root cause analysis. If the issue lies in the device, collaboration with the specifications team is essential to explore feasible modifications without compromising safety, performance, or compliance.

If a redesign is unavoidable, updating the project timeline may be necessary, but incorporating buffer periods for unexpected failures in the initial plan can help absorb delays. Additionally, progressing unaffected aspects of the project alongside the redesign can mitigate disruptions. Another thing to look at would be risk assessment tools to identify potential design vulnerabilities early.

If there is a failure the manager and team have to diagnose the problem whether it is the failed design verification test, the actual device failure, or both. A detailed analysis of failure should be done, to determine the problem and troubleshoot. Determine the failure impact, the safety, functioning, or acceptance. 

The first thing of success of any product depends on how end-to-end flow is designed. It includes thorough testing such as alpha and beta testing. This gives the team to properly test the actual device and a leeway period before the project timeline to manage any last-minute changes or modifications.

Failure in the design verification test means all the test scenarios and parameters are not correctly defined. As a project manager, I will first consult with analysts and developers from my team so that none of the test scenarios are missed. Specifications are very important in the product definition for example bone drills used in dentistry are monoangled. It cannot be used for the posterior teeth. So for this device, the success case scenario is anterior teeth and the failure case scenario is posterior teeth. So predefining of specifications of any product is important. 

In case of malfunctioning of the device, the machine needs to be reconstructed. It needs to repeat all the steps. For example, if a new apparatus was designed to measure blood pressure, it should have a cuff that can snugly fit the arm of an athletic, muscular, stocky, and thin person. And also we need to test the apparatus to function optimally in cold weather and hot weather. So the manager and team must plan about all the parameters that can affect the functioning of the apparatus. In this case, the deadline should be extended with a reasonable margin. To make the device perfect as a team we should have short-term and long-term solutions. Discussing with other team members is the best way to make the device near perfect.

As a manager, I will try to balance between extending the deadline to the customer and also not overburdening the team.

If the cause of failure was with the device design, then verification will take longer, and the timeline should be anticipated to be pushed back. As a project manager, I would confer with the Engineering team to conduct a root cause analysis alongside with Quality Management, and discuss how long a new design would be ready for re-verification. If the timeline can be adjusted to accommodate a new design test, then a new design should be made and Test should be redesigned to test if the new specification will achieve Design Outputs.

In this week's simulation, we were given a failed design verification test and tasked with redesigning the test to find out why it failed and how to fix the test. In the scenario given, there was a single factor that impacted the results of the test and modifying that factor was feasible within the device specifications and allowed for the test to be run successfully. However this is an ideal scenario that does not always occur. Sometimes verification tests fail not due to the test design but due to the actual device being tested. How, as a project manager, do you deal with that type of failure? Do you have to push the project timeline back if a redesign of the device is needed? Do you confer with the team developing specifications and see if the specs can be modified? How do you balance keeping the project on track and passing verification?

From my experience in the med tech field, I've learned that companies take measures so that devices don't have to be redesigned. The device is made taking everything in consideration. It is very rare that the entire device needs to be redesgined. In thie first simulation, it was a componenet of the device. Usually modifications need to be reevaluated to ensure they meet complications which can push back the timeline and cost money. Usually projects and stakeholders are prepared if anything doesn't meet specifications. There is usually a FMEA chart and actions to take is any risk arises. The key to making sure to not fall back in a timeline is to be prepared for any failures but also make the device so that the specifications are met.

Design verification is one of the phases in medical device development that serves the purpose of ensuring that the device has achieved all of the design specifications, performance capabilities, and regulatory expectations set for it prior to moving forward with validation and commercialization. Unfortunately, project delays, overspending, and regulatory issues on account of verification failures can and do happen. This is the primary reason why it is important to identify and mitigate issues while they are still manageable.

As noted above, one of the most common reasons behind design verification failures rest on poor test planning. When there is misalignment between the adopted test protocols and the expected regulatory frameworks, verification tests might be conducted but fail to capture critical performance problems. For instance, a new diagnostic device meant to function in extreme environments would need to be tested under the worst conditions, otherwise, it's bound to face challenges when deployed into the market, resulting in recalls.

Incomplete requirements definition is another major concern. Defining design inputs that do not lay down well-defined and quantifiable, measurable boundaries, creates a burden for a device with regard to meeting its specifications, verification, and validation. The likely consequence of that scenario is failure, as well as increased expenditure on retesting and design adjustments.

What do you think organizations should to do facing unexpected worst-case verification failures? Would there be a possibility of allowing some design alterations, so as not to totally change the entire verification framework, or they risk everything and rethink the entire strategy?