Functional, performance, and safety requirements plus applicable regulatory inputs — core input categories from 820.30(c) remain.
Risk management outputs (ISO 14971 hazard analysis results) must explicitly flow into design inputs — no longer implied.
Traceability from ISO 14971 risk controls to design input specifications — common gap where risk and design run as parallel streams.
Maps to
QMSR / ISO 13485: §820.30(c) Design input.
ISO 13485: §7.3.3 Design and development inputs
ISO 14971: §5.4 Identification of hazards and hazardous situations
Requirement text
Inputs relating to product requirements shall be determined and records maintained. These inputs shall include functional, performance, usability and safety requirements, according to the intended use.
Why this clause exists
Devices fail patients not primarily because engineers lacked skill but because the requirements they built to were incomplete or disconnected from actual hazard analysis. The most consequential gap in the Part 820 framework was the absence of a mandatory bridge between risk management outputs and design inputs: organizations could run a thorough FMEA, identify significant hazards, and then write design input specifications that did not reference those hazards at all, because the two processes ran in parallel streams without an explicit handshake. ISO 13485:2016 clause 7.3.3 — incorporated into the QMSR at 820.10 — closes this gap by making applicable outputs of risk management a required category of design input alongside functional, performance, usability, and safety requirements. This means identified hazards must propagate into requirements: if the risk analysis identifies a particular failure mode as safety-critical, a design input requirement must address it, and that requirement must later be verifiable. The inclusion of usability requirements as a named category reflects FDA's recognition that a significant proportion of device-related adverse events stem from use errors rather than technical failures — requirements that do not account for the intended user population and use environment systematically produce devices that are clinically unsafe even when they perform to engineering specifications.
What changed
§820.30(c) — Part 820 (legacy)
"Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating 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 a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented."
§7.3.3 — ISO 13485:2016 (current)
"Inputs relating to product requirements shall be determined and records maintained (see 4.2.5). These inputs shall include: a) functional, performance, usability and safety requirements, according to the intended use; b) applicable regulatory requirements and standards; c) applicable output(s) of risk management; d) as appropriate, information derived from previous similar designs; e) other requirements essential for design and development of the product and processes. These inputs shall be reviewed for adequacy and approved. Requirements shall be complete, unambiguous, able to be verified or validated, and not in conflict with each other. NOTE Further information can be found in IEC 62366–1."
Δ Adds risk management outputs and applicable regulatory standards as required input categories; inputs must now be verifiable or validatable, not merely non-conflicting.
Common gaps (what we see in audits)
- Risk management outputs not included as design inputs — ISO 13485 7.3.3(c) explicitly requires 'applicable output(s) of risk management' as a design input. Most Part 820-era design input documents list functional, performance, and safety requirements but do not trace these to or derive them from a formal risk management process per ISO 14971.
- Missing risk-based decision linkage — Design inputs don't reference risk analysis outputs (e.g., FMEA hazards) as a source for technical requirements. ISO 13485 §7.3.3 requires design inputs to include applicable output of risk management.
- No reference to prior similar designs — ISO 13485 7.3.3(d) requires that information derived from previous similar designs be considered as a design input where appropriate. Many companies develop new design input documents from scratch without systematically reviewing lessons learned or design outputs from predicate or similar devices.
- Usability requirements absent or informal — While Part 820 mentioned 'needs of the user' as an input consideration, ISO 13485 7.3.3 explicitly requires functional, performance, usability, and safety requirements. Many legacy design input documents address performance and safety but lack formal usability requirements derived from human factors analysis or IEC 62366.
- Design input review and approval not adequately documented — ISO 13485 7.3.3 requires that design inputs be reviewed for adequacy and approved. While Part 820 also required this, many legacy QMS libraries show design input documents with engineering signatures but no evidence of cross-functional review for adequacy, completeness, or conflict resolution.