How to consider worst-case device in design validation if using production-equivalent device?

Bev D

Heretical Statistician
Super Moderator
Ugh we are tripping over words and a generic example that is very vague. Requirements not are changed based on validation testing. You either met your requirements or you didn’t. You can exceed requirements in your actual design bu tyou don’t change the requirement itself. You may change the design or process specifications to meet the better than requirements performance. You have to validate the product at the max and min of all specs.
Last edited:


Involved In Discussions
I think this is my problem, the design validation does not validate the spec limits. It just validates the product that was made at that time. But the product, of course, will always be built to a range.

True, and maybe this is a piece of the puzzle I'm overlooking. But I can still imagine instances where we have a design spec based on a clinical requirement that is far exceeded by the actual performance. Even if we set the manufacturing spec around the actual performance we would still have this lingering requirement that is much lower than what was validated and theoretically tells us the product is good if it exceeds this. Would you go back and update your requirements to all the measured limits from DV testing?

I don't mean to beat a dead horse here and I appreciate both of you taking the time to provide your inputs and expand my thinking on this.
it seems you're missing a bit on how customer needs, use cases, and product requirements should be determined.

The user need is not a 10ft. cable, the user need is being able to connect device A to device B (or for the cable to reach the patient without moving the control module). Based on this stated need, you now need to determine the specific use conditions necessary to meet this customer need. In a case like this presumably you would have surveyed (in person or by customer self-reporting) 10 sites (or some reasonable number) what is the maximum distance between the two points in their workspace. Using that use case data (distances) you set the product requirement (length) to ensure all products will meet the customer need (make the connection). You incorporate your desired worst case or design margin based on how you translate the use conditions to the product requirements (highest distance reported, average length + some number of standard deviations, highest distance + some 'safety factor').

So testing worst case process outputs to meet customer needs is addressed by building in design margin into the product requirements so that there is no gaps between the defined user needs/use cases and the product requirements. Since all the design outputs (process variability) must meet the product requirements, I don't need to explicitly test the worst-case product requirement meets the customer need since the product requirements should be set to cover all the use cases. If 'all use cases' is too broad, you control this by stating in your IFU, the devices must be within X ft of each other or 'control module should be set up no more than X ft from the patient'.
Top Bottom