Design Input detail & specificity

[ThatSinc]

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.

 

[yodon]

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]

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]

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]

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.

 

[ThatSinc]

Hi All, circling back around to this as I've been faced with a "this is how we've always done it" and "I've been working in design for years" set of responses when I raised a question on something I was asked to review.


The products in question are for cleaning & disinfecting medical devices.
The user needs are basic; must clean and disinfect stainless steel instruments, must be suitable for machine and hand use, must disinfect within 30 minutes, must be non-hazardous, must be suitable for disposal in municipal waste water.

Currently the Design Inputs are just the formulation listed out in terms of the percentage composition of the specific component used in the formula, which I've advised isn't appropriate - as all they are doing as a part of *design* verification is showing that the end product has x% of a certain component within it - which should fall under the design transfer section for ensuring that the product can be made to specifications.

There is no up-front requirement from the customer or any regulations or standards, or marketing, to use a specific brand of disinfectant or specific brand of surfactant, but they have them listed as design inputs.

I've advised that the formulation is the design output and suggested that the design inputs be reformatted to reflect what each constituent component needs to do, asking the question of "why is this component in here at x% w/v"
Things like "disinfectant must reduce viable organism count in accordance with ISO XYZ within 30 minutes" - with the design output being the percentage of the actual disinfectant included in the formulation. the verification can then clearly have an objective requirement, and be either met or not.

My question is; is the way they are currently documenting their design inputs non-conforming to any requirements and how?
What are the consequences of keeping it in the way that it is?

TIA,

TS.

 

[Tidge]

Currently the Design Inputs are just the formulation listed out in terms of the percentage composition of the specific component used in the formula, which I've advised isn't appropriate - as all they are doing as a part of *design* verification is showing that the end product has x% of a certain component within it - which should fall under the design transfer section for ensuring that the product can be made to specifications.

There is no up-front requirement from the customer or any regulations or standards, or marketing, to use a specific brand of disinfectant or specific brand of surfactant, but they have them listed as design inputs.

'''

My question is; is the way they are currently documenting their design inputs non-conforming to any requirements and how?
What are the consequences of keeping it in the way that it is?

As written (in the part I snipped) I believe your advice to be correct. I can write more (even specific to user cleaning), but you have correctly identified the difference between a design input and a design output.

With respect to cleaning: Many medical devices ought to have a basic use requirement that they can be cleaned (a priori)... typically this is a risk control for the spread of some sort of infectious agent. The use cases will help to inform the considerations of what types of infectious agents as well as what types of typical cleaning solutions/methods will be available/applied. Sometimes design choices will reveal new risks that require specific cleaning methods (e.g. standing water in Cooler/Heaters used in cardiac surgery).

IF the design team is ignorant, stubborn, or simply prone to making uninformed decisions in the development process... it is not uncommon to force a development team to implement specific design choices via targeted requirements. This shouldn't be necessary because design outputs are supposed to be subjected to appropriate review and approval. One (project) risk is that the review might happen 'too late' in a project, and an unacceptable design output may have consumed 'too much' project time.

Implementing narrowly focused requirements is a risk control for projects that itself introduces new project risks. The new (project) risks are that if there is a defect it will be with the requirement and not the output... and it adds more time to a project to revise requirements than it does to correct a defective output.