Foundation of Product Development: Design Input Requirements - Part 1

Design Input Requirements are critical to a product development project. According to the FDA’s Design Control Guidance document, requirements “the single most important design control activity”. Whether this is true or not is debatable and probably a moot point. Design Input Requirements are, however, the foundation of a product development project.

I need to clear upsome terminology before proceeding too much further into this series of posts about Design Input Requirements. According to FDA Code of Federal Regulations (CFR) 820.3(f), Design Input means “the physical and performance requirements of a device that are used as a basis for device design”. Many terms are often used somewhat interchangeably to describe requirements:

• Design Inputs
• Design Input Requirements
• Design & Development Inputs
• Design Requirements
• Performance Requirements
• Product Requirements

There are probably more terms that are used, but for the sake of this post, I will try to stick with Design Inputs and/or Design Input Requirements. Even though the above list may seem like an issue of semantics, do not underestimate how much confusion terminology can cause.

The FDA & ISO

Design Inputs are addressed in the FDA CFR:

820.30(c) - Design Input

• Each manufacturer shall establish and maintain procedures to ensure that the design input requirements to a device are appropriate and address the intended use of the device, including the needs of the user and patient.
• The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
• The design input requirements shall be documented and shall be reviewed and approved by designated individual(s).
• The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.

ISO 13485:2003 - Medical Devices - Quality Management Systems also defines Design Inputs:

7.3.2 Design and Development Inputs

Inputs relating to product requirements shall be determined and records maintained (see 4.2.4). These inputs shall include:

a) functional, performance and safety requirements, according to the intended use,
b) applicable statutory and regulatory requirements,
c) where applicable, information derived from previous similar designs,
d) other requirements essential for design and development, and
e) output(s) of risk management (see 7.1).

These inputs shall be reviewed for adequacy and approved.
Requirements shall be complete, unambiguous and not in conflict with each other.

Simple enough, right? My experience is that defining good, objective, verifiable design input requirements is extremely difficult and challenging. Design input requirements take time, experience, and input from a cross-functional team. I will go into more details about the art of defining design inputs in part 2 of this series.