Design controls and the DHF under MDR — practical, not theoretical

#qms #medtech #compliance #regulatory

Design controls are where you prove you thought about safety before clinicians do the creative work of making the device fail in situ. To be fair, the term "Design History File" (DHF) is an FDA construct — 21 CFR 820.30 — but the activities behind it map directly to what the MDR expects in your Technical Documentation (see MDR Annex II). Treating the DHF as a compliance check-box instead of a living record is the single fastest route to a painful notified-body audit.

Why the DHF mentality still matters under MDR

MDR moved things from single-document box‑checking to traceable, auditable storylines: requirements → design → verification/validation → risk controls → clinical evidence → post‑market feedback. Annex II asks for design and manufacturing information that demonstrates conformity; ISO 13485 section 7.3 and FDA 21 CFR 820.30 still give the practical design-control steps.

In practice this means:

You need a documented design process (plan, inputs, outputs, reviews).
Every design decision should link to a risk assessment (ISO 14971).
Verification/validation need acceptance criteria and test evidence.
Changes, reviews and releases must be controlled and auditable.

What a practical DHF/Technical File contains (mapped to work you actually do)

I stop counting when people hand over a folder and say "it's all in there". A usable set of records has structure. At minimum I expect:

Design plan and design history timeline (who did what, when).
Design inputs: user needs, intended use, functional and safety requirements.
Design outputs: drawings, specifications, firmware/software builds, BOMs.
Design reviews and meeting minutes with attendees and action items.
Verification records (protocols, test reports) with pass/fail and acceptance criteria.
Validation records (clinical or simulated use, human factors/usability where applicable).
Risk management file (hazards, risk controls, residual risks, benefit‑risk).
Traceability matrix (requirements ↔ outputs ↔ verification/validation ↔ risks).
Design changes and change impact analysis with approvals.
Supplier qualification evidence for critical components.
Software lifecycle artefacts if applicable (IEC 62304 mapping, versioned builds).
Deployment/release records and design transfer to production.

If it's compressed down to "specs + reports", you're missing the connective tissue that NB auditors want.

What notified bodies actually ask for

My experience with audits under MDR is blunt: they do not want to reassemble the story for you. Expect questions like:

Show me how requirement X ended up as test Y and which risk control it mitigates.
Where is the acceptance criteria for test Z, and who approved it?
Which clinical data supports this intended use claim?
Show all changes since CE mark and the associated impact analyses.

To be fair, some NB teams are more tolerant than others — but none tolerate missing traceability or undocumented design reviews.

Common mistakes that trigger findings

Traceability exists but is static or incomplete (no link to risk controls).
Verification protocols with no predefined acceptance criteria.
“Validation” that is actually verification in thin clothing — e.g., bench tests presented as clinical validation.
Design review minutes without evidence that actions were closed.
Poor supplier change control: a component swap appears in production records but is missing from the Design Change log and impact analysis.
Software builds without controlled baselines and release notes.

Those are the practical, recurring failures I see every quarter.

Practical tips — make the DHF usable, not just auditable

Start with a Design Traceability Matrix (DTM). Make it the navigation hub of the DHF.
Define acceptance criteria before testing — reviewers will thank you and NBs will stop asking the same question.
Use consistent versioning and a clear design freeze / release process; auditors want to see who accepted a release.
Link risk management items directly to requirements and verification tests; a single cross-reference column saves hours.
Capture rationale for deviations and exceptions — it's not that deviations are forbidden, it's that they must be justified and reviewed.
For software and SaMD, map IEC 62304 outputs into your DHF and keep build artifacts (binary list, compiler settings) with the file.
Integrate change control with CAPA and supplier management — automated CAPAs and change impact analysis in your eQMS reduce friction and improve reviewability.

I use an eQMS that gives me connected workflow and traceability; it's not magic, it forces me to stop attaching PDF after PDF and instead link records where reviewers can follow a single path. Controlled assistance for CAPAs and AI‑guided impact mapping can help, but keep the reviewer-in-the-loop — traceability must remain human-reviewable.

Closing: make it a design story, not a paperwork pile

The DHF or Technical File under MDR is not only a regulatory artefact; it's the company's memory of why the device is safe and effective. If you can tell the story start-to-finish, with evidence at each step and risks addressed, audits become checks, not firefights.

What's one recurring design-control headache your team faces that you'd like a practical workaround for?