Design controls

Design controls are the regulated, documented product-development discipline that medical-device manufacturers (and any organisation that wants its development process to stand up to FDA QSR/QMSR or ISO 13485 audit) must apply when designing or significantly modifying a product. They are codified in 21 CFR 820.30 for the US, in ISO 13485:2016 §7.3 internationally, and in EU MDR Annex II §6 for the European market. The substance across all three is the same: planning, defined inputs, defined outputs, formal reviews at milestones, verification, validation, controlled transfer to production, controlled changes, and an evidence file (the Design History File) that proves the design was developed per the plan.

The point of design controls is not bureaucracy. It is to make defects expensive to ship and easy to trace. A controlled design process catches a missing input requirement during review (cheap), not during validation (expensive), not during a complaint investigation (very expensive), not during a recall (extremely expensive). The data behind the 1997 FDA Design Control Guidance is unambiguous: design defects — wrong inputs, missing inputs, mismatched outputs, unverified outputs — drive a disproportionate share of post-market device failures. The §820.30 regime exists because the cheaper way to fix that problem is upstream, with a paper trail.

FDA's QSIT (Quality System Inspection Technique) lists four 'major subsystems' as the spine of every comprehensive device inspection: Management Controls, Design Controls, Corrective and Preventive Actions, and Production and Process Controls. Design controls are reviewed in every QSIT-based inspection that touches a device subject to §820.30. For Class II and Class III devices, that means almost every inspection. The inspector's first questions are predictable: show me the design and development plan; show me the design input document; show me the design output document; show me the traceability matrix; show me the design verification protocols and results; show me the design validation protocols and results; show me the design transfer record; show me the design changes log; show me the DHF index.

The most-cited design-control observations on FDA Form 483 over the last decade are consistent: 'Procedures for design controls have not been [adequately] established' (820.30(a)); 'Design input requirements have not been [adequately] established and documented' (820.30(c)); 'Design output procedures do not contain or make reference to acceptance criteria' (820.30(d)); 'Design verification did not confirm that design output meets design input requirements' (820.30(f)); 'Design validation has not been [adequately] performed under defined operating conditions' (820.30(g)); 'Procedures for the control of design changes have not been [adequately] established' (820.30(i)); and the catch-all, 'Design History File has not been [adequately] established' (820.30(j)).

Beyond the inspection risk, design controls drive cost-of-quality. The single best predictor of low post-launch warranty cost, low complaint rate, low first-year recall risk and short time-to-CE/510(k)-clearance is a tight design-control programme. The companies that ship reliably ship from a clean DHF.

Design controls are required by every major medical-device regime, by ISO 13485 for any organisation seeking the certificate, and by EU MDR/IVDR as part of the technical documentation that supports CE marking. The major scope and clause map:

§820.30 / §7.3 break the discipline into eight reinforcing elements. Each has a specific evidence expectation in the DHF.

1. Design and development planning (§820.30(b) / §7.3.2) — a documented plan that describes the activities, responsibilities, interfaces between groups, identified inputs/outputs, review/verification/validation activities, and the design-transfer plan. The plan is updated as the design evolves.
2. Design inputs (§820.30(c) / §7.3.3) — the physical and performance requirements derived from user needs, intended use, regulatory requirements, applicable standards, risk-management outputs and usability inputs. Inputs must be unambiguous, complete, verifiable and not in conflict with each other. Approval signature required before development proceeds.
3. Design outputs (§820.30(d) / §7.3.4) — the drawings, specifications, code, labelling, packaging, IFU, accept/reject criteria and any other artefact that defines the device or guides production. Each output must reference its input(s) for traceability. Approval signature required before release for design transfer.
4. Design review (§820.30(e) / §7.3.5) — formal, documented reviews at planned milestones (typically end-of-phase). Each review includes representation from every function affected (R&D, QA, RA, manufacturing, service, marketing) plus at least one person not directly involved in the design stage under review (the independent reviewer). Output is a decision (proceed / conditional / hold) with rationale.
5. Design verification (§820.30(f) / §7.3.6) — activities that confirm design outputs meet design inputs. Typical activities: dimensional measurement, performance testing on bench, software static analysis, code review, design analysis. Documented protocols with pre-approved acceptance criteria; documented results; deviation handling.
6. Design validation (§820.30(g) / §7.3.7) — activities that confirm the device, as built, meets user needs and intended use under actual or simulated use conditions. Performed on initial production units or their equivalent. Includes use validation, clinical evaluation where required, and software validation. Documented protocols and results.
7. Design transfer (§820.30(h) / §7.3.8) — the controlled handoff of the validated design to production. Outputs include the Device Master Record (DMR) — drawings, specifications, manufacturing procedures, in-process and release tests, packaging, labelling and installation/servicing procedures — released under change control with first-article inspection and (where required) process validation (IQ/OQ/PQ) complete.
8. Design changes (§820.30(i) / §7.3.9) — every change to a released design proceeds via the change-control process, with impact assessment, verification/validation as needed, regulatory-impact assessment (new 510(k)? PMA supplement? significant change under MDR?) and approval before implementation.
9. Design history file / files (§820.30(j) / §7.3.10) — the cumulative evidence package: plan, inputs, outputs, reviews, verification, validation, transfer, changes, plus the traceability matrix and the regulatory submissions that flowed from the design.

The most common conceptual mistake in design controls is conflating user needs with design inputs. User needs describe what the user expects the device to do in their world ('the surgeon needs to deliver a controlled dose of drug to the spinal nerve root'). Design inputs are the engineering requirements derived from those needs, with numerical thresholds, environmental envelopes, regulatory references and acceptance criteria ('the device shall deliver 1.0 ± 0.05 mL when actuated at 22 ± 3 °C; needle deflection under load shall not exceed 0.5 mm at 5 N; compliance with USP <788> for particulate; IEC 60601-1 for electrical safety'). User needs validate; design inputs verify. Both are required; both are formally documented; both are signed; both feed the traceability matrix.

The V-model is the visual aid: down the left arm, user needs → design inputs → design outputs; up the right arm, verification (output meets input) → validation (system meets user need). Every left-arm artefact has a matching right-arm artefact. The traceability matrix is the explicit mapping; a row without a verification protocol or a validation activity is a regulatory finding waiting to be written.

§820.30(e) requires that 'each design review include an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed'. The independent-reviewer requirement is the most-frequently weak part of small-company DHFs. The independent reviewer must be competent (technical credentials, training record), formally appointed (named in the review record), present (signature on minutes), and outside the design team for the stage under review. Self-review by the design lead is not a design review.

Each review record should contain: scope (which deliverables are being reviewed), attendees with role and independence marker, pre-read materials referenced, findings with severity, decisions (proceed / proceed with conditions / hold), action owners with dates, the next review trigger, and approval signatures. A 'proceed' decision with open findings is acceptable only when each open finding has an owner, date and tracking mechanism — typically a CAR or design action item in the change log.

Typical milestone cadence: end of Concept (review of user needs and high-level inputs), end of Feasibility (review of architecture and detailed inputs), end of Detailed Design (review of outputs and verification plan), end of Verification (review of verification results and validation plan), end of Validation (review of validation results and transfer readiness), Design Transfer Review (release-to-production gate), Post-Launch Review (feedback loop to design for the next change cycle).

FDA Design Control Guidance §6.1: 'Verification is confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.' Verification answers 'did we build the device right' — did the outputs meet the inputs. ISO 13485 §7.3.6 mirrors this. Typical activities: bench testing against specifications, dimensional inspection, environmental testing, EMC testing, software unit/integration testing, code review, biocompatibility testing per ISO 10993, sterilisation validation per ISO 11135/11137, packaging validation per ASTM F2096.

FDA Design Control Guidance §6.2: 'Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.' Validation answers 'did we build the right device' — does it meet user needs in actual use. Activities: simulated-use testing with representative users in representative environments, human factors / usability validation per IEC 62366-1 §5.9, clinical evaluation per MDR Article 61 / 21 CFR 860 where required, software validation across the operational profile, in-vivo / clinical investigation where the intended use cannot be confirmed without patient data.

The most-cited validation finding: validation performed on prototypes rather than on production-equivalent units. §820.30(g) and §7.3.7 both require validation on 'initial production units, lots, or batches, or their equivalents'. A prototype hand-built by R&D does not equal a production unit unless the production process has been demonstrated to produce equivalent output, and that demonstration itself must be documented.

§820.30(h) requires 'procedures to ensure that the device design is correctly translated into production specifications'. The design-transfer gate is where the DHF ends and the DMR / eDHR begin — it converts an engineering deliverable into a manufacturable, releasable product. It is also the most failure-prone gate in design controls. Common failure modes: design outputs not in producible form (no tolerance, no inspection method); production process not validated (IQ/OQ/PQ incomplete); training not delivered to operators; supplier quality not aligned (no purchasing specification, no incoming inspection plan); labelling not approved per §820.120 + §820.180; risk-control measures from the RMF not implemented in production controls; software not under configuration control in production environment.

A defensible design-transfer record includes: a transfer plan with explicit deliverables and gating criteria; first-article inspection results against the DMR; process validation status (IQ/OQ/PQ or equivalent); training records for production and QC staff on the new product; supplier-readiness confirmation (POs released against approved specs); labelling approval per §820.120; DMR baseline frozen and released under change control; pilot lot results; and a formal transfer-decision signature by manufacturing, QA and RA leadership.

§820.30(i): 'Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.' Once design transfer is complete, every design change — to outputs, to the DMR, to labelling, to manufacturing procedures, to software, to supplier specs — proceeds through the change-control process. The change record must contain: description, rationale, impact assessment (technical, risk, regulatory, manufacturing), verification/validation plan, regulatory-impact assessment (does this require a new 510(k) per FDA guidance 'Deciding when to submit a 510(k) for a change'? a PMA supplement? significant change notification under MDR Article 120?), training plan, implementation plan, effectivity date and approval signatures.

Common 483 observations on design changes: changes implemented without verification / validation; regulatory-impact assessment not performed; cumulative changes not aggregated for regulatory review; supplier-driven changes not flowed through; labelling changes not handled per §820.120; software changes not under configuration management per IEC 62304 §6.

§820.30(j): 'Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.' The DHF is a logical compilation, not necessarily a single physical file — but the index that ties it together is required. A modern DHF index references:

• Design and development plan (latest approved version)
• User needs document with approval signatures
• Design input document(s) with approval signatures
• Design output document(s) with approval signatures
• Risk management file (per ISO 14971) — linked, not duplicated
• Usability engineering file (per IEC 62366-1) — linked, not duplicated
• Software development file (per IEC 62304) — linked, not duplicated
• Design review minutes for every milestone, with attendee list and decision
• Design verification protocols, executed records and deviations
• Design validation protocols, executed records and deviations
• Clinical evaluation report (where applicable)
• Biological evaluation report per ISO 10993
• Design transfer record including first-article inspection
• DMR baseline reference with release signature
• Design change log with approved change records
• Traceability matrix (user needs ↔ inputs ↔ outputs ↔ verification ↔ validation ↔ risk controls)
• Regulatory submissions and clearances/approvals derived from the design (510(k), De Novo, PMA, MDR technical documentation, ISO 13485 certificate references)

ISO 14971 risk management does not stand apart from design controls; the two processes interleave continuously. Risk analysis under §4.3 / §5 begins during concept and identifies hazards that become design inputs. Risk evaluation under §5.5 supports the design-review decision at each milestone. Risk control under §7 generates risk-control measures that themselves become design inputs, design outputs, verification activities and (sometimes) usability requirements. Residual-risk evaluation under §8 happens at validation. Production and post-production information under §10 feeds back to risk-file review, which feeds back to design changes.

Inspectors increasingly check the cross-references both ways: every Class III risk control should be traceable to a design output, a verification record and a residual-risk acceptability decision; every design input that addresses safety should be traceable to a hazard in the risk file. A traceability matrix that ignores the RMF is an audit finding waiting to be written.

For devices containing software, IEC 62304 §5 prescribes a software development lifecycle that sits inside the design-control framework: software development planning, software requirements analysis (a flavour of design input), software architectural design, software unit implementation and verification, software integration testing, software system testing (a flavour of design verification), software release, problem resolution and configuration management. The Software Development File is referenced from the DHF; IEC 62304 records are themselves part of the design-control evidence chain.

For devices with a user interface, IEC 62366-1 §5 prescribes a usability engineering process: prepare the use-specification, identify user-interface characteristics, identify hazards and hazardous situations related to use, identify primary operating functions, establish user-interface specification, establish UI evaluation plan, perform UI design, verification and validation (with formative and summative evaluations). The Usability Engineering File is referenced from the DHF and feeds both design inputs and design validation.

• Design and development plan not maintained as the project evolved.
• Design inputs lacking acceptance criteria or with ambiguous wording ('shall be reliable').
• Design inputs missing the corresponding risk-control measures from the RMF.
• Design outputs lacking approval signature before being used as the basis for verification.
• Design review without an independent reviewer present.
• Design review minutes without explicit findings, action owners or decisions.
• Verification protocols without pre-approved acceptance criteria.
• Verification results showing deviations without documented disposition.
• Validation performed on prototypes without documentation of equivalence to production units.
• Validation activities that fail to involve actual users in actual use environments where applicable.
• Design transfer without first-article inspection or with deferred process validation.
• Design changes implemented without verification or without regulatory-impact assessment.
• Software changes not under configuration control per IEC 62304 §6.
• DHF index missing or out of date; cross-references to RMF / SDF / UEF not maintained.
• Cumulative changes since clearance not aggregated for a new 510(k) decision per FDA guidance.

• Design review turnaround time (review scheduled → minutes signed).
• Independent-reviewer attendance rate (target 100%).
• Open design action items aged >30 days.
• Verification protocol pass rate at first execution (deviations as a % of protocols).
• Validation protocol pass rate at first execution.
• Number of design changes per quarter, broken down by impact class.
• Regulatory-impact decision quality: % of design changes for which a documented decision exists.
• Cycle time from design-input approval to design transfer.
• Time from complaint to design-change initiation for design-attributable complaints.
• DHF index completeness (target 100% of required references present and current).
• Traceability-matrix gap count (rows without verification or without validation).

V5 Ultimate models design controls as a first-class workspace inside the QMS, scoped per product family. Each design project has its own plan, inputs, outputs, review milestones, verification and validation activities, transfer record and change log. The DHF index assembles automatically from the project's signed artefacts — no manual index maintenance, no risk of a missing reference at audit.

User needs and design inputs are version-controlled with approval signatures. Each input row is linked to its verification protocol and to its risk-control measure(s) in the RMF, producing a live traceability matrix that flags gaps in real time. Outputs are linked back to the input(s) they fulfil; release of outputs to design transfer is gated by output approval, verification completion and risk acceptance.

Design reviews are scheduled with a defined attendee list, the independent-reviewer role marked, and pre-read materials attached. Minutes are captured live with findings, owners and dates; the decision (proceed / conditional / hold) is signed by the chair and the independent reviewer. Open findings become tracked design action items with SLA dates.

Verification and validation protocols are authored against pre-approved acceptance criteria, executed with electronic capture of results, deviations handled via the standard deviation workflow, and reports auto-assembled with traceability back to the input(s) verified or the user need validated. Validation activities are flagged when performed on prototypes so the equivalence-to-production rationale is captured explicitly.

Design transfer is a formal gate: first-article inspection results, process-validation status, training records, supplier readiness and labelling approval must each be green before the DMR can be released. The release converts the design outputs into the DMR baseline that drives the eDHR for every production unit thereafter — closing the loop from user need to produced unit.

Design changes after release run through the same change-control workflow as the rest of the QMS, with mandatory technical / risk / regulatory / manufacturing impact assessment, verification or validation as required, and a regulatory-impact decision (new 510(k)? PMA supplement? MDR significant-change?). The DHF and the DMR update together under change control, with a complete history available for inspection.