Design Input & Output in Stages - Overkill?

M

mr.mike

#1
Hi Everyone,

I've been browsing some of the posted templates for documenting design inputs and outputs, and it seems to me that they are all too simplistic and don't really give a clear picture of how various inputs feed into outputs.

The reason being that design & product realization (at least our process) occurs in stages, with the output of one feeding into the inputs of another.

So, I'm wondering if a "stage-by-stage" input/output document might make the product-realization process more clear. Below is an example, any feedback appreciated.

******
Stage 1: Planning
Inputs (examples): International Standards, Public-domain market research...
Outputs (example): Development Plan document, System Requirements Document...

Stage 2: Design
Inputs: Outputs of stage 1
Outputs (examples): Validation Plan, Risk Management File, Component specifications, Assembly instructions...

Stage 3: Prototype
Inputs: Outputs of stage 2
Outputs: Test reports & Device history records
*****

The above is obviously just an outline, and the actual document would be much more detailed. What I want to know, is if this is overkill? ...or maybe I'm totally missing the point of what a design input/ouput document is supposed to contain?

Feeback much appreciated,
MM.
 
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#2
Please note that the "regulatory" design input and output "control" requirements are only related to the design input of your initial stage and the last design output of your final stage.

For example, if your design process has a "conecpt" stage where you decide between more than one concept on detailed design, your design input "control" would be the design inputs for ther chosen concept. Before that, you didn´t have a device, but different concepts.
 
A

arios

#3
The model you are proposing looks to me like a design plan rather than input-output information.

It does not mean you can't break your input vs. output verification by stages, but is important IMHO to prevent possible confusion in terminologies. For example a test reports could probably relate more to a section of a validation phase, which is meant to happen towards the end of a design project while inputs vs. output are more likely to be part of the initial stages.

You could consider the following scenario:

Risk Management:
Inputs: identification of characteristics (e.g. Annex C of ISO 14971) & Preliminary hazard analysis, known post market information of similar products. Acceptance Criteria for residual risks.
Output: DFMEA, Risk-benefit analysis for risk which may not be further reduced.
Verification: confirm that identified hazards were addressed in the DFMEA

Device Intended Performance:
Inputs: Competitors' product information, Description of additional intended features expressed in terms of volume, size, capacity, materials.
Outputs: Approved product specification for new product
Verification: confirm that every identified intended requirement is addressed in the product specification

Raw materials:
Input: intended material characteristics based on intended product performance, biocompatibility requirements as per intended use.
Output: Procurement specs, identification of qualified vendors, ASL, Biocompatibility analysis repports for new materials, special storage requirements.
Verification: confirm that every identified characterictic for raw materials are addressed. document results of verification.

Regulatory:
Input: identification of applicable harmonized standards as per intended market. Identification of labeling requirements.
Outputs: Matrix identififying stadards deemed fully or partially applicable, Specifications for label content, translated IFU's.
Verification: confirm that every identified characterictic are addressed. document verification result

I hope this helps :2cents:
 
Last edited by a moderator:
M

mr.mike

#4
Thanks for your prompt reply mmantunes.

...but forgive me, I'm not sure I completely understand. Are you saying that the only inputs and outputs required in a design input/output document would be the inputs in "Stage 1", and the outputs of "Stage 3".

(I'm pretty sure I'm not understanding correctly).

It seems to me that the whole purpose of such a document would be to trace design decisions, no? In this case, the document should present a FLOW of inputs and outputs, rather than simply the initial and final stages.

For example:

International Standard (e.g 60601-1) -> System Requirements -> Prototype Design Docs -> Protoype Test Reports

apologize for the confusion.... perhaps if you could clarify (or provide reference) as to what the intended purpose of a design input/outputs document is...

Thanks,
MM.
 

Marcelo

Inactive Registered Visitor
#5
Thanks for your prompt reply mmantunes.

...but forgive me, I'm not sure I completely understand. Are you saying that the only inputs and outputs required in a design input/output document would be the inputs in "Stage 1", and the outputs of "Stage 3".

(I'm pretty sure I'm not understanding correctly).

It seems to me that the whole purpose of such a document would be to trace design decisions, no? In this case, the document should present a FLOW of inputs and outputs, rather than simply the initial and final stages.

For example:

International Standard (e.g 60601-1) -> System Requirements -> Prototype Design Docs -> Protoype Test Reports

apologize for the confusion.... perhaps if you could clarify (or provide reference) as to what the intended purpose of a design input/outputs document is...

Thanks,
MM.
You are quite correct when you say that the design controls would be to trace design decisions.

What i said is that generally the main worry is with initial design input and final design output. That´s what is clearly defined in the regulations. Any other "phase" or "gate" control should be obviosly performed, but decided by the manufacturer depending on his design process. Something like the attached image.

This was just a theoretical comment. Sorry if that confused you.
 

Attachments

Marcelo

Inactive Registered Visitor
#6
Also, as you mentioned IEC 60601, please note that using standards are design inputs are very problematic if you are aware of known device development models and risk management.

Requirements from product safety standards are nothing more than possible solutions to risk control (they are risk control measures), so using them as design input means that you are already choosing a design implementation, intead of defining a design requirement.

This use of standards as input is what companies usually do, but it´s a real problem with the risk management requirements that exists or are coming (for example, due to IEC 60601 3 ed).
 
A

Al Dyer

#7
Document designs and templates are just that, basic designs and templates that may also be available in a book. The good thing with the documents here is that they are usually able to be personalized to your own situation. Only you know what you need in a specific situation and documents here are well thought out and topical to the required situation.

Use what we have as a starting point and revise as required to fit your needed use.

Thank you for the input!

Al...
 
K

Ka Pilo

#8
It can be is organized/simplied into three sections:

- Inputs (information to collect from your suppliers)
- Production/Processing (information generated during production that you keep within the facility)
- Outputs (information you share with your customers)

These three sections are further divided into subsections based on the typical operational areas associated with your control and traceability.
 
A

Al Dyer

#9
Ka,

Is that the only/preferred method or do you subscribe to the view that there are multiple methods to receive the preferred outcome? Could you expand on your response?

Thanks for your input.

Al...
 
K

Ka Pilo

#10
Ka,

Is that the only/preferred method or do you subscribe to the view that there are multiple methods to receive the preferred outcome? Could you expand on your response?

Thanks for your input.

Al...
No, there are multiple methods to receive the preferred outcome. As Muslims and Jaws saaid "If you slaughter, then slaughter in the best way". The best practice is always starting with design planning. This is a basic description/concept of how you're going to address what you want to do. Through planning you wouldn't be going through the unnecessary steps.
The next step is Design Input e.g. customer specs, statutory and regulatory requirements, product history, educated guesses, surveys, etc. You will notice that the Design Output, at any stage, can become Design Input for the next stage.
The final output is the finished engineered solution.
 
Last edited by a moderator:
Thread starter Similar threads Forum Replies Date
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
shimonv Design input/output traceability for mechanical parts ISO 13485:2016 - Medical Device Quality Management Systems 13
D Design Input/Output and Design V&V (Verification and Validation) Interpretations 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 14
sagai Are some Design Input elements part of the Design Output? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
R Design Input/Output Form - Your feedback appreciated ISO 13485:2016 - Medical Device Quality Management Systems 3
T Design Input vs. Design Output - What constitutes Design Input? Design and Development of Products and Processes 11
L Looking for ISO 13485 Design Input and Output Files - Templates/Examples Design and Development of Products and Processes 2
S Design Input and Output Documents - Seeking specific examples - Medical Devices Design and Development of Products and Processes 7
T Design Input detail & specificity ISO 13485:2016 - Medical Device Quality Management Systems 4
L IATF 16949 Cl. 8.3.3.2 Manufacturing process design input - Process capability IATF 16949 - Automotive Quality Systems Standard 1
B IATF 16949 Section Clause 8.3.4.1 - Monitoring - Design and Development Input(s) IATF 16949 - Automotive Quality Systems Standard 3
S Referencing International Standards as Design Input Design and Development of Products and Processes 5
D Any Product Design Input sample for Colonoscope devices 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
Q When is a Design Input Good Enough? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
A Are Software Requirements Specifications part of Design Input? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
A Implementation of Design Input Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
L ISO 9001 Clause 7.3.2 Design & Development Input - Adequacy, Complete, Unambiguous ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
A Formal Way for Documenting Design Input Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
S Revise or to Not Design Input Document for On-Market Cleared Class II Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
D Design & Development Input Records Requirements - ISO 9001 Clause 7.3.2 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
Sidney Vianna Looking for input on the design/syllabus of a 2-day AS9100 Transition Course AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 7
W What is "Design Input" by QSR, 21 CFR Part 820 ? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
J Preparation of Documents defining Design Input ISO 13485:2016 - Medical Device Quality Management Systems 10
GStough Risk Management Has to Begin Prior to Design Input, But... Design and Development of Products and Processes 10
P Design Input Proposal and Design Control Checklist Formats wanted ISO 13485:2016 - Medical Device Quality Management Systems 1
R Product Design Input as per TS 16949 clause 7.3.2.1 Design and Development of Products and Processes 9
D Design Input - Question on Specific Performance Criteria for Medical Devices Design and Development of Products and Processes 3
S Design Input class 3 device Design and Development of Products and Processes 5
K Design Input document example format/template needed Design and Development of Products and Processes 12
C Home made gage examples - Input to design new home made gages General Measurement Device and Calibration Topics 9
R Checklist for Design Input items for Medical Devices wanted Design and Development of Products and Processes 4
A Manufacturing process design input vs Design information checklist Design and Development of Products and Processes 1
M Design Input - 820.30(c) - Addressing incomplete, ambiguous... requirements Design and Development of Products and Processes 1
DuncanGibbons Section 8.3 relevant for design organisations AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
P DFMEA - Machinery Design Best Practices FMEA and Control Plans 0
R Is a FAIR required on parts that we design? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
J Significant change related to design and intended use EU Medical Device Regulations 3
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 6

Similar threads

Top Bottom