ISO 9001 Design Process Flow Chart

[dave-o]

Hi all. I'm attempting to verify the completeness of a design control procedure and identify the resulting documentation with regards to the requirements of ISO 9001.

I'm a little more familiar with medical device design requirements, and I'm trying to follow the least burdensome approach by not including anything that's not necessary, while also not ignoring anything that would provide obvious advantages to manufacturing, safety, and support.
Care to take a look and see if I'm obviously missing anything, or including too much? Or if I'm absolutely mental?

Also I realize some of the abbreviations may be cryptic.

Key
DHF - Design History File
DMR - Device Master Record
D+D Plan - Design & Development Plan
FMEA - Failure mode and effects analysis form
I/O - Input / Output
DRF - Design Review Form
DTP - Design Transfer Plan
PM - Preventative Maintenance

I'm whiteboarding right now, so please excuse the non-digitized nature of this image. Thanks in advance!

 

[kgott]

It appears to me that you have the design review functions going and at the right places so it looks to me that it complies with design requirements of ISO 9001.

As a general point, you might like to take your pic to those people who work in the process and get their feedback on it. They will tell you if its OK or what changes need to be made. More importantly, take it to the person who is accountable for the outcomes of the process. They are the ones who have to answer for outcomes and ensure that any corrections or corrective actions that are later identified, are implemented.

It makes it a whole lot harder for them if the procedure does not accurately reflect the way things are actually done.

 

[Alpine]

I agree with Kgott, when I started at my current company I had to revise our Design procedure and key to that process was the consultation with the R&D team and the R&D Manager. That way the process they carry out is captured and key requirements in the ISO standard are identified and understood by the team. At the end of the day it they who have to live it and will be the ones audited to it.

 

[John Broomfield]

Hi all. I'm attempting to verify the completeness of a design control procedure and identify the resulting documentation with regards to the requirements of ISO 9001.

I'm a little more familiar with medical device design requirements, and I'm trying to follow the least burdensome approach by not including anything that's not necessary, while also not ignoring anything that would provide obvious advantages to manufacturing, safety, and support.
Care to take a look and see if I'm obviously missing anything, or including too much? Or if I'm absolutely mental?

Also I realize some of the abbreviations may be cryptic.

Key
DHF - Design History File
DMR - Device Master Record
D+D Plan - Design & Development Plan
FMEA - Failure mode and effects analysis form
I/O - Input / Output
DRF - Design Review Form
DTP - Design Transfer Plan
PM - Preventative Maintenance

I'm whiteboarding right now, so please excuse the non-digitized nature of this image. Thanks in advance!

Dave,

I could not see design inputs to conceptual design.

John

 

[dave-o]

Agreed, good input on making this a collaborative effort. I will certainly be involving other team members, but as it turns out, I'm the R&D team and primarily responsible for the end to end process in this scenario. We're a small company = fun & challenging.

 

[dave-o]

Dave,

I could not see design inputs to conceptual design.

John

Thanks John - I have to admit, the concept phase is a little vague for me. Do you suggest creating design inputs for a concept and performing verification before moving to the design phase? Keep in mind that I'm asking out of ignorance, and not challenging your suggestion.

 

[yodon]

Several things jump out at me. First, DHFs and such are terms from the medical device world (exclusively, I think). The concepts are solid but as others have pointed out, acceptance comes from within so be sensitive to the company's terminology, culture, etc.

The title of the post is design process yet the bulk of the flow is on V&V and production. Maybe that's your intent? Otherwise, you may want to flesh out the design 'phase' a bit more. Where do all your requirements come from? How are they accepted and resolved (conflicts, incompleteness, inconsistency, etc.)? How do the requirements get translated into the next level of decomposition? Do you have separate functional areas contributing to the design (electrical, mechanical, software)? How is the design allocated to the functional area; i.e., what is the system architecture / how is it defined? How is it the design (per functional area) and system architecture stay in sync as the design evolves? How do functional areas communicate between each other to ensure the design is cohesive?

Maybe that level of detail is not what you're after but since you specifically said "design process" I thought I'd throw it out.

 

[John Broomfield]

Thanks John - I have to admit, the concept phase is a little vague for me. Do you suggest creating design inputs for a concept and performing verification before moving to the design phase? Keep in mind that I'm asking out of ignorance, and not challenging your suggestion.

Dave,

Conceptual design comes up with ideas for solving the customer's problem. Therefore, the nature of the problem has to be an input as does any constraints.

John

 

[dave-o]

Several things jump out at me. First, DHFs and such are terms from the medical device world (exclusively, I think). The concepts are solid but as others have pointed out, acceptance comes from within so be sensitive to the company's terminology, culture, etc.

The title of the post is design process yet the bulk of the flow is on V&V and production. Maybe that's your intent? Otherwise, you may want to flesh out the design 'phase' a bit more. Where do all your requirements come from? How are they accepted and resolved (conflicts, incompleteness, inconsistency, etc.)? How do the requirements get translated into the next level of decomposition? Do you have separate functional areas contributing to the design (electrical, mechanical, software)? How is the design allocated to the functional area; i.e., what is the system architecture / how is it defined? How is it the design (per functional area) and system architecture stay in sync as the design evolves? How do functional areas communicate between each other to ensure the design is cohesive?

Maybe that level of detail is not what you're after but since you specifically said "design process" I thought I'd throw it out.

Thanks for your input! We've had some discussions on whether or not to carry over the additional concepts required for medical, and determined that since many of us are familiar with them anyway and they meet the documentation requirements for ISO 9001 (in excess, perhaps, but better safe than sorry).

I appreciate the level of detail regarding the actual design process. The specific design control procedure that I'm adopting is laid out according to my whiteboard drawing - that is, when you look at what's done in each phase and the expected outputs, the drawing illustrates what you generate. I'm with you, it seems a little lacking on the actual 'design' phase. I suppose it's left vague on purpose, with the steps you're describing left up to the project lead on a project-by-project basis, but I wouldn't mind having that cemented a little more. I'd love to see an example of a working system, though this product line doesn't have the complexity of, say, an implantable device. This is more of an automated backup appliance, and will be comprised primarily of off-the-shelf components with a minimum of assembly and configuration. The main need is to define requirements and generate specifications for the primary supplier to adhere to, and then ensure that requirements are met and specifications satisfy intent - hence the focus on V&V.

What I'm running into is that these appliances have already been designed and manufactured, and the primary reason for establishing design controls at this point is to begin adhering to ISO standards moving forward. Because of this, I don't have a lot of initial design records, but need to create procedures to be followed and forms to be populated for new designs and design changes. I'm also trying to keep things simple for two reasons: small design team and ease of adoption.

 

[John Broomfield]

Hi all. I'm attempting to verify the completeness of a design control procedure and identify the resulting documentation with regards to the requirements of ISO 9001.

I'm a little more familiar with medical device design requirements, and I'm trying to follow the least burdensome approach by not including anything that's not necessary, while also not ignoring anything that would provide obvious advantages to manufacturing, safety, and support.
Care to take a look and see if I'm obviously missing anything, or including too much? Or if I'm absolutely mental?

Also I realize some of the abbreviations may be cryptic.

Key
DHF - Design History File
DMR - Device Master Record
D+D Plan - Design & Development Plan
FMEA - Failure mode and effects analysis form
I/O - Input / Output
DRF - Design Review Form
DTP - Design Transfer Plan
PM - Preventative Maintenance

I'm whiteboarding right now, so please excuse the non-digitized nature of this image. Thanks in advance!

Dave,

Instead of white-boarding the perfect design process with us, why not work with your process owner and the process team to analyze your current design process?

Capture how customer needs are translated into product specifications via planning, assigning responsibilities, gathering inputs, reviewing inputs, conceptual design, reviewing concepts to choose the one most likely to satisfy customer needs with your contraints (another input), detailed design with reviews at the 30, 70, 100% stages, verification per the plan and then validation per the plan to authorize production.

You may also apply this design process to the design of production, delivery, use and maintenance of the product.

You may find it already conforms to the requirements of ISO 9001, with or without a few tweaks.

Best regards,

John