Where does process validation fit within design & development?

[joylc]

I'm working on drafting a design control procedure that conforms to ISO 13485:2016, and I'm having difficulty figuring out how process & software validations (section 7.5.6) fit within design and development (section 7.3). Does anyone have any insight?

Thanks

 

[yodon]

A few thoughts:

Most everyone uses software-based issue tracking systems. Those generally create electronic records that support the d/d process.

Verification may use test fixtures that have to be qualified and test methods that may need to be validated.

Both Verification and Validation may need some statistically sound techniques.

 

[Jane_S]

Hello!
I don't have much experience on this matter yet, as I myself am working on a similar task at the moment, but the way I see process/software validation is the "transfer to production activity". When the initial risk assessment is finished you decide if there are any processes which have to be validated and perform a validation.

I may be wrong, but I'd be very interested to see how this discussion evolves further.

 

[rob73]

Device validation and process validation should be kept separate, make reference to 7.5.6 in the D & D procedure but do not try and encompass it all. I know it all seems a bit chicken and egg " but how can i validate the device if i have not validated the process" but, the aim of device validation is to ensure the DESIGN meets the intended specification/user needs/intended use etc. Once you have a design that works, you can design,verify and validate the process to make it.
I don't generally deal with software, but i would hazard a guess that software embedded in the device falls under 7.3, software used in manufacturing (cnc programs etc) would be in 7.5.6.

 

[Ronen E]

Device validation and process validation should be kept separate, make reference to 7.5.6 in the D & D procedure but do not try and encompass it all. I know it all seems a bit chicken and egg " but how can i validate the device if i have not validated the process" but, the aim of device validation is to ensure the DESIGN meets the intended specification/user needs/intended use etc. Once you have a design that works, you can design,verify and validate the process to make it.
I don't generally deal with software, but i would hazard a guess that software embedded in the device falls under 7.3, software used in manufacturing (cnc programs etc) would be in 7.5.6.

Devices used in Design Validation must be from the commercial production process, or at least from a process closely representing it. Therefore I think that the process should be pretty much set-up before design validation begins, preferably validated if necessary. The exception might be a process that doesn't have to be validated (outputs can be subsequently verified in the product) but is being validated due to practical or economical reasons - in that case the Design Validation specimens can be 100% verified instead of the process being validated first.

I've seen the practice of combining the two. It's not required and indeed these are two separate topics, but it makes some sense. You run IQ, OQ & PQ and continue to validate the design on the same production run.

Cheers,
Ronen.

 

[rob73]

Devices used in Design Validation must be from the commercial production process, or at least from a process closely representing it.

I totally agree, like i said it can be a bit of a chicken and egg situation, but if your design is not validated and proven to meet expectations, is there any point in validating the process that made it?
Using IQ, OQ & PQ during your validation is the way to go

 

[Ronen E]

if your design is not validated and proven to meet expectations, is there any point in validating the process that made it?

Yes, it's a bit of a bet, but if you got the user needs right and worked your (engineering) design input properly out of the identified user needs, and design verification is OK (lots of ifs ) - it's a safe bet to a large extent.

 

[joylc]

Thanks everyone for the input. I was thinking along the same lines as some of your replies but then kept getting caught up in the chicken/egg debate with myself.