Design Input detail & specificity

ThatSinc

Involved In Discussions
#1
Hi All,

Not sure whether this should go in this forum as relating to 7.3.3. of 13485 or in the Development forum - apologies if I've chosen incorrectly.
I've been struggling to figure out how to word the question I want to ask so apologies for that too.

Where design specifications (outputs) are developed from the design input requirements, how specific should the design inputs be when taking into consideration product standards and explicit customer requirements?
Is it normal to directly map a customer requirement to a design input?

Should, as an example, the design input requirement for visual identification of devices include any specific colour coding that might be a part of a standard?

To put that into a design flow
Customer Requirement: Must be able to visually distinguish between different needle gauges
Design Input: Devices shall be colour coded in accordance with ISO 6009:2016 (Determined from applicable standards as per 7.3.3.b)
Design Output: Material specifications / component drawings including relevant RAL colours
Verification: Are RAL colours as in ISO 6009:2016
Validation: Can customer visually distinguish between colours.

Lets say the customer explicitly references that the devices must be colour coded in accordance with the standard in their requirements, should the design input document distil that requirement further into the colours that should be included, in which case the design input is essentially a design specification summary, or is it appropriate to copy the same requirement over to the design inputs?

Should a design input ever be an engineering specification?

Any examples to support the discussion would be really helpful.

M.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
The "ideal" approach we take is that, as your example shows, customer requirements / user needs map into engineering specifications (which may comprise a system-level spec which then is further elaborated in and trace to mechanical, electrical, software, ... requirements). We consider all these as Design Inputs although I've seen companies draw the line at customer requirements (and the rest are design outputs).

In parallel, is your risk management activities. The outputs of risk management (controls) are also considered design inputs. We generally trace controls from the Hazard Analysis into System Requirements and controls from the various FMEAs (use, design, software, etc.) into relevant lower level specifications (e.g., software controls into software requirements).

In your example above, you're very much on track but I would generally consider the verification to be an inspection of the drawing specifying the color. There are probably also relevant production controls to ensure the right colors but those are outside of design inputs. Your validation is correct and would be driven by the usability considerations (summative study).
 

Tidge

Involved In Discussions
#3
Should a design input ever be an engineering specification?.
My general answer to this specific question is "No." Specifications can be verified, whereas design inputs are not specifically verified. Design inputs are mapped to design outputs (including specifications) which are then verified.

In your 'color coding' example, I would recommend that the design input be 'compliance with a particular standard' rather than the design input being the specific color.

I am familiar with design efforts which included a rather large degree of specificity in the design inputs. This is often the case when the 'design inputs' were developed after the design was more-or-less done. One problem with having engineering specifications in the design inputs is that should you change the engineering specification you are making a design change much earlier in the design and development process which involves more work and has larger implications for the project (whether this is recognized or not).
 

ThatSinc

Involved In Discussions
#4
Thanks for the quick feedback, really appreciated.

I picked a relatively easy example to lead with, however am more curious regarding when customer requirements are essentially design inputs themselves rather than information that would be taken and elaborated on to prepare design inputs. would you simply map them directly across?

We generally trace controls from the Hazard Analysis into System Requirements
With this in mind; where, for example, you've determined through risk management that connections must be unique to prevent erroneous connections between inputs/ouputs - would your design inputs be updated to be as vague as "input and output connections must not be interchangeable" or would you be explicit in "input 1 must be compliant with ISO XYZ" and "Output 1 must be compliant with XYZ"?

In your 'color coding' example, I would recommend that the design input be 'compliance with a particular standard' rather than the design input being the specific color
Is that in respect to both examples where the customer requirements are high level and more explicit? In which case mapping the explicit customer requirement directly to the design inputs.

At the moment the "design specification" document I'm looking at has a mishmash of both bulleted requirements, bulleted specifications, and other "relevant information" included in paragraph form regarding how the device will function. It also includes a full section that simply lists all relevant standards.

It appears that it's trying to be both a design requirements document and a summary of the design outputs.

I'm trying to ensure consistency with requirement formats, level of detail, and allow for very clear linkages between the inputs and outputs. When there is inconsistency it just throws the whole thing off.

I'm unsure whether it's necessary to extract the relevant parts of each standard that relate to each section of the design inputs document, such as connections, colour coding, labelling etc.
 

indubioush

Quite Involved in Discussions
#5
With this in mind; where, for example, you've determined through risk management that connections must be unique to prevent erroneous connections between inputs/ouputs - would your design inputs be updated to be as vague as "input and output connections must not be interchangeable" or would you be explicit in "input 1 must be compliant with ISO XYZ" and "Output 1 must be compliant with XYZ"?
I see your design input as, "Device input and output connections must not be interchangeable. Connections must be compliant with ISO XYZ." Then your specification would be the connection type requirements, and your design output would be the design specification document (usually a drawing) that defines the connections requirements for that device.

I'm unsure whether it's necessary to extract the relevant parts of each standard that relate to each section of the design inputs document, such as connections, colour coding, labelling etc.
You should document the source of the design input so you can more easily check your compliance to the standard. I like having a design input/output matrix that has the following columns:

Design Input Device input and output connections must...
Input Source Hazard analysis xxx item xx, ISO XYZ section xx
Specification Input connector must be...; Output connector must be... Connection between input and output must not be possible
Design Output Subassembly drawing XXX
V&V Reference Design review XXX, design verification report xxx, Usability validation xxx

If you document things this way, it is super easy to see all the connections between input, output, spec, testing.
 
Thread starter Similar threads Forum Replies Date
shimonv Design input/output traceability for mechanical parts ISO 13485:2016 - Medical Device Quality Management Systems 13
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 Input/Output and Design V&V (Verification and Validation) Interpretations 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 14
M Design Input & Output in Stages - Overkill? ISO 13485:2016 - Medical Device Quality Management Systems 16
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 9100, Nadcap and related Aerospace Standards and Requirements 7
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
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
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
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
sardonyx Design Input and Output Documents - Seeking specific examples - Medical Devices Design and Development of Products and Processes 7
M Design Input - 820.30(c) - Addressing incomplete, ambiguous... requirements Design and Development of Products and Processes 1
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Reliability Analysis - Predictions, Testing and Standards 0
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A AS9102B - 3.6 Design Characteristics and form 3 AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 3
P Design FMEA - Detection Rating criteria ISO 14971 - Medical Device Risk Management 3
U Medical Device Design finalization testing ISO 13485:2016 - Medical Device Quality Management Systems 2
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
D Design Transfer Template capturing Customer Specific Requirements Other Medical Device Related Standards 3
Similar threads


















































Top Bottom