eQMS for Medical Devices
Explore this topic in more depth to build a complete picture of your quality and compliance operations.
Explore
Glossary Term
Design Controls
The governed process behind every compliant medical device design — and the file that proves it.
Design controls turn device development into a traceable, reviewable process: inputs to outputs, verification to validation, all captured in the Design History File.
On this page
What design controls are
Design controls are the formalised, documented practices that govern medical-device design and development. In US device GMP they originated in 21 CFR §820.30; under the FDA QMSR (effective 2 February 2026) that content now flows through ISO 13485:2016 §7.3, which the QMSR incorporates by reference. The elements are consistent across both: design and development planning (§820.30(b)), design inputs (§820.30(c)), design outputs (§820.30(d)), design review (§820.30(e)), design verification (§820.30(f)), design validation (§820.30(g)), design transfer (§820.30(h)), design changes (§820.30(i)), and the Design History File (§820.30(j)) — all under control.
The Design History File (DHF) is the compilation of records demonstrating the design was developed in accordance with the approved design plan and the design-control requirements. It is the evidence trail an auditor walks to confirm the process was followed. Two related but distinct files often get confused with it: the Device Master Record (DMR) — the recipe for building the device, an output of design transfer — and the Device History Record (DHR) — the production record for specific units. Under EU MDR (2017/745), the Technical File is the equivalent regulator-facing dossier bundling design, risk, V&V, and clinical evidence.
DHF vs DMR vs DHR vs Technical File
| File | Answers the question | Primary regulator | Audience |
|---|---|---|---|
| DHF Design History File | How was this design developed? | FDA §820.30(j) | Internal audits, FDA inspections |
| DMR Device Master Record | How is the device manufactured? | FDA §820.181 | Manufacturing, inspections |
| DHR Device History Record | Was this specific batch built to spec? | FDA §820.184 | QC release, inspections, recalls |
| Technical File | Does this device meet EU MDR safety + performance requirements? | EU MDR Annex II/III | Notified Body, EU competent authorities |
Design controls apply to most Class II and Class III devices and a subset of Class I devices; the requirement scales with risk, but for any device where they apply, the traceability they create is the spine of the technical documentation.
Design controls vs a DHF system
Design controls are the process. A dedicated DHF / product-development system (sometimes called an ALM or requirements-management tool) manages the live requirements-to-outputs-to-V&V traceability matrix as structured, linked data. An eQMS governs the quality records around that process — the controlled documents, reviews, changes, and risk files. The two are complementary; one does not replace the other, and a buyer should be clear which they are evaluating.
Why design controls dominate device audits
Design controls are among the most-cited areas in FDA device inspections and a central focus of notified-body audits under the EU MDR. The reason is structural: nearly every serious device field problem can be traced back to a design-control gap, so regulators treat the design-control records as a leading indicator of product safety.
The recurring failures are traceability failures. Design inputs that don't trace to outputs. Verification that doesn't close every input — leaving a requirement asserted but never tested. Validation performed on non-representative product, or on bench units rather than production-equivalent devices. And — the most common of all — design changes made without re-assessing impact, re-running the affected verification or validation, and updating the DHF, so the file gradually diverges from the device that actually ships.
Two integrations make or break design control, and auditors probe both. Risk management (ISO 14971) must feed design inputs — risk controls become requirements — and must be revisited as the design evolves, so the risk file and the design file stay in step. Change control must catch every design change, route it through review and the appropriate re-verification or re-validation, and update the DHF. A device team can have excellent design documents and still fail if these two threads aren't connected to them.
Inspector perspective: “Show me the traceability matrix for this device. Pick any user need, walk it to the design input it generated, then to the output, then to the verification record that closes it, then to the validation evidence. Then show me the last three design changes and how each one updated the DHF, the risk file, and the V&V records.” The two probes together reveal both the integrity of the original design control AND whether the file has stayed honest through changes. The change-control linkage is where most files break.
Where design controls live
The regulatory framework spans US, EU, and ISO references:
- 21 CFR §820.30(a)-(j) — the original FDA design-controls requirement broken into 8 sub-clauses (planning, inputs, outputs, review, verification, validation, transfer, changes, DHF). Content now applies via ISO 13485 §7.3 under QMSR.
- ISO 13485:2016 §7.3.2-§7.3.10 — design and development; the clause structure the QMSR and notified bodies both work from
- EU MDR (2017/745) Annexes I, II, III — general safety and performance requirements, plus the technical documentation that the Technical File bundles
- ISO 14971:2019 — risk management; design inputs and risk controls are intertwined throughout the design process
- IEC 62304 §5.1-§5.8 — software lifecycle for devices containing software (SaMD and software-in-device); a design-control sub-discipline
- IEC 62366-1 §5.1-§5.9 — usability engineering; feeds design validation and human-factors evidence
- FDA Design Controls Guidance (1997) — the long-standing interpretive guide for the waterfall/iterative design model
- FDA HFE/UE Guidance — expectations for human factors and usability engineering
- FDA PCCP Final Guidance (December 2024) — predetermined change control plans for ML-enabled devices
- FDA-Health Canada-MHRA Good Machine Learning Practice Principles (October 2021) — ten guiding principles for AI/ML device development
- FDA Compliance Program 7382.850 — design records within scope of the risk-based inspection program that replaced QSIT
How the design-control loop actually runs
In practice, design control is a loop, not a waterfall — even when documented in phases. A workable rhythm:
Plan and capture inputs. The design and development plan defines stages, responsibilities, reviews, and the verification/validation strategy. Design inputs are gathered from user needs, intended use, regulatory requirements, and — critically — the risk analysis, where each risk control measure becomes a design input that must be verified later.
Produce and review outputs. Design outputs (drawings, specifications, software, labelling) are created against the inputs and reviewed at defined milestones with the right participants and independent reviewers. Each review is a record per §820.30(e).
Verify, then validate. Verification confirms outputs meet inputs — every input closed by an objective test, with a traceability matrix proving none were missed. Validation confirms the finished device meets user needs and intended uses under actual or simulated conditions, on production-representative product. Summative human factors validation per IEC 62366-1 is a design validation activity for use-related risk.
Transfer and control changes. Design transfer translates the design into the DMR for manufacturing, verified to ensure the design is correctly rendered into production. From that point, every design change is evaluated for impact per §820.30(i), re-verified or re-validated as appropriate, approved, and reflected in the DHF — the discipline that keeps the file honest over the product's life.
The DHF accumulates throughout: plans, inputs, outputs, review records, verification and validation results, the traceability matrix, transfer records, and the running design-change history. It is assembled continuously, not reconstructed at audit time.
What strong design control looks like
Whether you run a dedicated DHF tool or assemble the file from documents, these are the controls auditors look for:
The change that breaks the file
The single most common design-control finding is a design change implemented without updating the DHF, the traceability matrix, or the risk file — so the documented design and the shipped device drift apart. Strong programs make a design change un-closeable until its impact, re-verification, and file updates are complete. That gate is a change-control function, not a documentation habit.
- A maintained traceability matrix — user needs to inputs to outputs to verification to validation, with no orphan requirements
- Risk-linked inputs — every ISO 14971 risk control traceable to a design input and its verification
- Milestone design reviews — with required participants, independent review, and records of issues and resolutions
- Verification closing every input — objective evidence per input, not a sampled subset
- Validation on representative product — production-equivalent units, actual or simulated use, including human factors per IEC 62366-1 where applicable
- Controlled design transfer — verified rendering of design into the DMR
- Design-change control — every change impact-assessed, re-V&V'd as appropriate, approved, and reflected in the DHF and risk file
- Software lifecycle control — IEC 62304 activities where the device contains software, with risk-based safety class driving documentation depth
- A continuously assembled DHF — built as you go, retrievable on demand
- Linkage to Technical File for EU MDR scope — design records feed the Technical File without parallel maintenance
Where Complere supports design control — honestly scoped
Complere is not a Design History File system. It does not maintain the live design-input-to-output-to-verification traceability matrix that a dedicated product-development or ALM tool provides, and device teams whose work depends on that structured, linked requirements data should run one. Saying this plainly is the point: a vendor who claims an eQMS replaces a DHF tool is overselling, and a skeptical device-quality lead will catch it.
What Complere governs is the quality-system layer around design control — and that layer is substantial. Design plans, review minutes, design outputs, and the DHF documents themselves live in Document Control as controlled, versioned records with electronic signatures. Design changes route through impact-assessed change control — the gate that keeps the file honest — so a change carries its approval chain, document updates, training triggers, and a documented impact decision. ISO 14971 risk records are managed with linkage to CAPA and change, keeping the risk file in step with the design. Design-related quality issues become CAPAs with full investigation and traceability.
For teams whose engineering and requirements work lives in tools like Jira, GitHub, or TestRail, Complere's integrations roadmap (open REST API first) is built to connect that evidence into the governed quality system, so the design-control records and the development activity stay associated. The honest fit: Complere is a strong governed-quality layer that complements a DHF/ALM tool — controlled documents, change discipline, risk management, and CAPA around the design process — not a replacement for the structured design-traceability system itself. For the broader device picture, see the medical devices industry page.
Frequently asked questions
Common questions about Design Controls sourced from regulatory references and inspection patterns.
What is the difference between DHF, DMR, DHR, and Technical File?
DHF (Design History File) is the record of how the design was developed — plans, inputs, outputs, reviews, V&V, traceability matrix. DMR (Device Master Record) is how to make the device — specifications, drawings, BOM, work instructions; the output of design transfer. DHR (Device History Record) is proof that a specific batch was built to the DMR. Technical File is the EU MDR equivalent that bundles design, risk, V&V, and clinical evidence in a single regulator-facing dossier. The four serve different audiences but share evidence.
What triggers a Design Review under 21 CFR §820.30(e)?
Design Reviews must occur at defined milestones in the design plan and must include independent reviewers — at least one person who didn't perform the work under review. Reviews are required at minimum at each phase transition (inputs approved, outputs approved, V&V complete, design transfer complete). Trigger-driven reviews also occur for significant design changes, unresolved high-severity risks, or new regulatory requirements during development. The review record captures attendees, issues raised, decisions, and action items — and is part of the DHF.
How does ISO 14971 risk management integrate with design controls?
Risk management runs in parallel with design control and is bidirectional. Design inputs include risk control measures from the ISO 14971 risk analysis — each risk control becomes a requirement that must be verified. Design outputs and verification results feed back into the risk analysis — confirming controls were implemented as intended. The risk file and design file must stay synchronized: a design change that affects a risk control triggers re-analysis; a new hazard discovered late triggers design re-review. The integration is auditor-tested specifically: 'show me the risk control for this hazard and the verification record that closes it.'
What is FDA's Human Factors Engineering (HFE) / Usability expectation under design controls?
Use-related risk must be evaluated and controlled. FDA's HFE/UE Guidance and IEC 62366-1 frame the lifecycle: identify users, use environments, and use-related hazards; design with use safety in mind; conduct formative usability testing during development; perform a summative human factors validation under simulated-use with representative users. The summative HF validation is a design validation activity — and FDA increasingly probes it during pre-submission and inspection for higher-risk devices.
How does design control apply to modifications of an already-cleared device?
Every modification goes through change control with a documented impact assessment per 21 CFR §820.30(i) and §820.70. The assessment determines what V&V must be repeated and whether the design transfer record (DMR) needs updating. For modifications that could significantly affect safety or effectiveness, FDA may require a new 510(k) per the Letter to Industry on Deciding When to Submit a 510(k). EU MDR applies similar scrutiny under Annex IX. The discipline is the same regardless of regulator: change → impact assessment → re-V&V where needed → DHF and DMR updated → approved before deployment.
What's the role of software development under design controls?
Software-containing devices (SaMD and software-in-device) must follow IEC 62304 as a design-control sub-discipline. The lifecycle structure is parallel: software development plan, software requirements (from design inputs), architectural design, detailed design, implementation, integration testing, system testing — with risk-based safety classification (Class A/B/C) driving documentation depth. The software lifecycle records are part of the DHF. FDA's PCCP guidance (December 2024) and the joint FDA/Health Canada/MHRA Good Machine Learning Practice principles have layered additional expectations on AI/ML-enabled devices.
How is internal design review different from FDA's inspection of design records?
Internal design review is a milestone activity during development — independent technical evaluation of design state at each phase. FDA's inspection of design records is a post-clearance audit confirming the design-control process was followed. Internal review tests whether the design is sound; FDA's inspection tests whether the file proves the process was sound. The two require different evidence: internal reviews look forward (what risk remains?), FDA inspections look backward (was the documented evidence chain intact?). Both rely on the same underlying records — but the questions asked of them differ.
Which device classes are subject to design controls?
Under 21 CFR §820.30(a), design controls apply to all Class III devices, all Class II devices, and a specific subset of Class I devices listed in §820.30(a)(2) (e.g., devices automated with computer software). Most Class I devices are exempt — but for those subject to the requirement, the scope is the full §820.30 lifecycle. Under FDA QMSR (effective 2 February 2026), the same class scope applies via ISO 13485 §7.3 incorporated by reference. EU MDR imposes design-control-equivalent requirements through Annexes I, II, and III for all classes.
Continue Exploring
Explore related topics, modules, and compliance resources for a deeper understanding of your quality system.
See how the document, change, and risk layer supports design control
Walk through how Complere keeps design documents, change history, risk records, and CAPA traceable across the device design lifecycle.