Design Input & Output in Stages - Overkill?

M

mr.mike

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.
 

Marcelo

Inactive Registered Visitor
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

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

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
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

  • waterfall_model_design_control.gif
    waterfall_model_design_control.gif
    6.6 KB · Views: 1,103

Marcelo

Inactive Registered Visitor
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

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

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

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

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:
Top Bottom