Design Verification - Is testing required?

[DamienL]

Hi all,
I've been in Medical Devices quite a while and am a bit embarassed to admit I still don't know what's actually required for a design verification. I have always worked with companies that would verify through extenstve testing that the design output meets a pre-determined design input specification. An example might be that a device "must be able to withstand pressure of up to 20atm". So in order to verify that the desigin output meets this specification, I would have a pre-approved protocol/plan which states the test methodology and equipment to be used, along with the sample size and acceptance criteria (both of which would be determined by the FMEA risk for the associated failuire mode).

However, I come across frequent situations where a product might have a design input specification that, in my opinion, doesn't warrant any testing whatsoever (but the companies I've worked for will still test for it). Some examples might be as follows:

EXAMPLE 1:
USER NEED: Device must be long enough to reach the target treatment area
DESIGN INPUT SPECIFICATION: Top-to-toe length must be at least 30cm
DESIGN OUTPUT: Assembly drawings with allowable top-to-toe length 35-40cm
For this one, would it make sense for Design Verification to simply be a documented verification that 35-40cm is specified on the assembly drawing? Therefore design output meets design input.

EXAMPLE 2:
USER NEED: Device must be visually appealing to the user
DESIGN INPUT SPECIFICATION: Handle on the finished Device must be white (this would just be a partial spec, it would take a lot more to define an appropraite design input for this user need)
DESIGN OUTPUT: Handle component drawings with white specified as the colour

This is probably a controversial example but if we pretend that the spec is based on a user 'need' (rather than a user 'want'), could Design Verification simply be a documented verification that all of the individual drawigns for the handle components specify they be made in white? Therefore the finished device has to end up white.

So my question is in two parts: Firstly, can Design Verification be done like I've suggested in these 2 examples - a paperwork check? Or is testing always needed?

Secondly, if testing is not always needed, then how would you go about satisfying 7.3.6 of ISO 13485 (planning for DV). Would you need to write a protocol/plan up front to state that you're going to take out the approved drawing and compare it to the design input spec?

I understand there are loads of holes in the examples I've picked, but I'm more interested in the concept of Design Verification without testing. Whether that is a common approach that I should be using instead of testing wherever possible? Thanks

 

[yodon]

Design Verification can take multiple forms. Physical properties may be verified through means other than (functional type) testing. The focus is providing objective evidence that the requirement is met. Design verification should be very cut-and-dried as to what constitutes pass criteria.

Your second example would be part of design validation (does it meet the users' needs). Design validation can be a little more squishy than clear-cut pass/fail (e.g., your criteria might be 4 out of 5 users must agree that it is visually appealing). Such a requirement would necessitate that you involve intended users.

 

[John Broomfield]

Verification = does it conform
Validation = does it satisfy user needs

...and we always verify before we validate.

 

[Ronen E]

Hi all,
I've been in Medical Devices quite a while and am a bit embarassed to admit I still don't know what's actually required for a design verification. I have always worked with companies that would verify through extenstve testing that the design output meets a pre-determined design input specification. An example might be that a device "must be able to withstand pressure of up to 20atm". So in order to verify that the desigin output meets this specification, I would have a pre-approved protocol/plan which states the test methodology and equipment to be used, along with the sample size and acceptance criteria (both of which would be determined by the FMEA risk for the associated failuire mode).

However, I come across frequent situations where a product might have a design input specification that, in my opinion, doesn't warrant any testing whatsoever (but the companies I've worked for will still test for it). Some examples might be as follows:

EXAMPLE 1:
USER NEED: Device must be long enough to reach the target treatment area
DESIGN INPUT SPECIFICATION: Top-to-toe length must be at least 30cm
DESIGN OUTPUT: Assembly drawings with allowable top-to-toe length 35-40cm
For this one, would it make sense for Design Verification to simply be a documented verification that 35-40cm is specified on the assembly drawing? Therefore design output meets design input.

EXAMPLE 2:
USER NEED: Device must be visually appealing to the user
DESIGN INPUT SPECIFICATION: Handle on the finished Device must be white (this would just be a partial spec, it would take a lot more to define an appropraite design input for this user need)
DESIGN OUTPUT: Handle component drawings with white specified as the colour

This is probably a controversial example but if we pretend that the spec is based on a user 'need' (rather than a user 'want'), could Design Verification simply be a documented verification that all of the individual drawigns for the handle components specify they be made in white? Therefore the finished device has to end up white.

So my question is in two parts: Firstly, can Design Verification be done like I've suggested in these 2 examples - a paperwork check? Or is testing always needed?

Secondly, if testing is not always needed, then how would you go about satisfying 7.3.6 of ISO 13485 (planning for DV). Would you need to write a protocol/plan up front to state that you're going to take out the approved drawing and compare it to the design input spec?

I understand there are loads of holes in the examples I've picked, but I'm more interested in the concept of Design Verification without testing. Whether that is a common approach that I should be using instead of testing wherever possible? Thanks

Hi Damien,

Don't be embarrassed at all, you are thinking perfectly straight! (IMO)
I also think that many, many professionals in this field haven't got their thoughts properly sorted about that matter. Sadly, a lot don't even care and just go about with their happy test-everything business.

Yes, I'd go for a protocol that details your verification method for all design input items, whether it involves testing (last resort) or not.

Please have a look at my article on design verification (I tried to address that issue in it).

Cheers,
Ronen.

 

[Ronen E]

Your second example would be part of design validation (does it meet the users' needs). Design validation can be a little more squishy than clear-cut pass/fail (e.g., your criteria might be 4 out of 5 users must agree that it is visually appealing). Such a requirement would necessitate that you involve intended users.

I partly agree.

I think that that particular example calls for a 2-tier approach.

1. User Needs level: The device needs to be appealing to the user blah blah blah. "Appealing to the user" is quite subjective and obviously involves the user, so that should be addressed in design validation as you've described.

2. Design Input level: As Damien described, the (subjective) User Need is "translated" to an (objective) engineering requirement - The <x> needs to be white (maybe even specifying Pantone, RAL or the like, etc.), and probably a bunch of other requirements at a similar specificity level. This kind of requirement can and should be verified in design verification as Damien has described.

So you are both right.

 

[DamienL]

Thanks all for helping me see the light on this. You'd be surprised how many organisations out there, when they see a design specification, knee jerk into developing a test method to measure it, then find out they can't measure it reliably, then end up in a spiral of test method development!! That might be absolutely appropriate for a high risk design control, but I don't think testing should be a first resort for everything. Thanks all for your input, and an excellent article Ronen.