The Medical Device Design File: Foundation of ISO 13485 and 21 CFR Part 820 Compliance

Introduction

"A solid design file doesn't hinder innovation: it secures and enhances it."

The Design History File (DHF) is often perceived as a constraint. Yet, ISO 13485 (§7.3) and 21 CFR Part 820 (§820.30) assign it a strategic role: demonstrating that every technical decision is justified, every requirement verified, every risk controlled. A robust DHF proves that your medical device is safe and effective, acting as a performance lever that accelerates audits and facilitates post-market modifications.

This article deciphers the cross-requirements of ISO 13485 and 21 CFR Part 820, and structures the essential DHF content to transform this regulatory obligation into a competitive advantage.

Why the Design File is Crucial 🎯

Your Passport to CE Marking and FDA Authorization

A well-structured design dossier does not replace the MDR technical documentation, but it forms its backbone.

During an assessment by a Notified Body, it is the technical documentation (Annexes II and III of the MDR) that is analyzed first. However, when the consistency of the evidence is questioned (requirements, testing, change management, traceability), the auditor will very often refer back to elements from the design dossier.

A solid DHF therefore makes it possible to produce more robust, consistent, and defensible technical documentation.

Common Misconceptions About the Design History File

⚠️ Beware of frequent confusions

The design file is not a simple compilation of technical documents created at the last minute to satisfy an auditor. It's a living system, built throughout development, integrating R&D, quality, and regulatory affairs. Without this systemic vision, the file becomes a burden rather than a control tool.

➡️ Golden rule: What is not documented does not exist in the eyes of auditors. No verification can be recognized without formal proof.

1.3. Risks of an Inadequate File

Deficiencies frequently identified during audits:

❌ Critical safety requirements without formal verification proof
❌ Technical modifications made without following the change control procedure
❌ Broken traceability between requirements, design outputs, and test results
❌ Validation performed on prototypes instead of initial production units (21 CFR §820.30(g) requirement)

An inadequate file transforms a certification audit into an obstacle course. Information requests accumulate, timelines extend, budgets explode. Meanwhile, the market window closes and competitors advance.

ISO 13485 vs 21 CFR Part 820: Convergences and Specificities 🌍

Both standards share the same philosophy: control design through systematic checks. However, their approaches differ slightly.

Comparative Requirements Table

Recommended Integrated Approach

For manufacturers targeting both CE marking and FDA authorization, the strategy consists of creating a single design file structured according to 21 CFR Part 820 §820.30 (more prescriptive, particularly on design transfer) while ensuring ISO 13485 §7.3 compliance. This approach avoids inconsistencies and ensures no regulatory requirement is overlooked.

The design file is not self-sufficient: it must be consistent with risk management, software development, usability engineering, and clinical evaluation files. Traceability between these files ensures overall technical documentation alignment.

The 7 Pillars of the Design File 🏛️

The DHF is an assembly of documents proving control at each phase.

Design and Development Plan

The design plan structures the project by defining: device scope (type, class, innovation), development phases with their validation milestones, organization of responsibilities (R&D, quality, regulatory), phase transition criteria, and links to QMS procedures (risks, changes, CAPA).

⚠️ Critical point: The plan must be a living document, updated at each phase. A version frozen at project start is insufficient.

Design Requirements (Design Input)

Design inputs define what the device must accomplish and under what conditions. They must be complete, unambiguous, verifiable, and traceable, covering all device aspects: functional performance, usability, clinical performance, material biocompatibility, environmental robustness, cybersecurity, data protection, and any other relevant requirement depending on device nature.

➡️ Good practice: Each requirement must have a unique ID, a source, and above all, a measurable verification criterion.

Design Outputs

Outputs translate requirements into technical specifications exploitable for verification and transfer to production. They include, depending on device type: detailed plans and diagrams (3D CAD, electronic schematics, software architecture diagrams), complete bill of materials (BOM with supplier references), material specifications (biocompatibility justifications, certificates), and source code with software documentation (IEC 62304).

⚠️ Critical requirement: Each output must be linked to the inputs it satisfies (bidirectional traceability matrix).

Design Verification: "Did We Build the Product Right?"

Verification confirms that design outputs meet inputs. It relies on methods adapted to the device (performance testing, Worst-Case analysis, simulations, documentary reviews) and produces formal deliverables: detailed verification protocols, test reports with documented deviations.

⚠️ Common error: Testing only main functions. All requirements must be formally verified.

Design Validation: "Did We Build the Right Product?"

Validation proves that the device meets user needs under representative conditions of use. 21 CFR §820.30(g) requires it be performed on initial production units or equivalents.

Required validations vary by device: clinical trials, usability testing (IEC 62366-1), software validation (IEC 60601-1 §14 or IEC 82304-1), sterilization validation, packaging, or cleaning validation as applicable. Each validation produces a report documenting methodology, success criteria, results, and acceptability conclusion.

⚠️ Common error: Limiting to technical verification without validation under real-world conditions..

Formal Design Reviews

Design reviews are mandatory milestones where the multidisciplinary team evaluates design adequacy to requirements, test and analysis results, risk management status, as well as identified problems and corrective actions. 21 CFR §820.30(e) requires participation of at least one person independent from the design team.

Each review must be documented: participant list with signatures, examined documents (with versions), identified problems, decisions made (go/no-go, modifications), and assigned actions with responsible parties and deadlines.

➡️ Recommended frequency: At the end of each major phase (minimum 3-4 reviews per project).

Design Transfer to Production

Transfer formalizes the passage from design to manufacturing operations.

Key transfer elements:

• Validated manufacturing instructions
• Production control specifications
• Production personnel training
• Equipment and process validation (IQ/OQ/PQ)
• Traceability transfer (serial numbers, batches)

⚠️ Common pitfall: Modifying design during transfer without documentation. Any modification must follow the change control procedure.

Change Management: The Continuous Process ♻️

Once design is validated, the file continues to live. Each modification must be:

1.Identified and documented
Nature of change
Justification (improvement, correction, regulatory obligation)

2.Evaluated for impact
Impact on safety and performance
Impact on requirements and tests
Impact on clinical evaluation and CE marking
Need for reverification/revalidation

3.Formally approved
By quality and technical managers
By regulatory manager if impact on technical file

4.Verified and/or validated
According to change magnitude
Systematic regression testing

5.Traced in the file
DHF update with new version
Accessible modification history

Complementary Documents According to Device Nature 📋

The design file integrates or references specific documents according to device technology and risks.

Devices with software (SaMD or embedded): The file includes or references the software development file (IEC 62304) comprising development plan, software requirements specification, architecture, detailed unit design (class C), test protocols and results (unit, integration, system), SOUP documentation, and configuration management. Documentary depth depends on software safety class (A, B, or C). For devices with connectivity or sensitive data processing, the file also integrates cybersecurity documentation: cyber risk analysis, secure architecture specifications, SBOM, vulnerability monitoring plan (CVE), and incident response procedure.

Electromedical devices (IEC 60601-1): The file contains complementary validations: SEMP validation (§14), electrical safety test reports, electromagnetic compatibility (IEC 60601-1-2).

Sterile or prolonged contact devices: The file includes biocompatibility reports (ISO 10993), sterilization validation (ISO 11135, ISO 11137), packaging validation (ISO 11607), and stability studies.

Regardless of device type, the design file objective remains identical: demonstrating through tangible evidence that the device is safe, effective, and compliant with applicable requirements.

Common Errors to Avoid ⚠️

Late Documentation

The most common error is creating the design file at project end to "satisfy the audit." This approach makes traceability impossible to reconstruct reliably. The file must be fed continuously, from the first development sprint, integrating each decision, modification, and test result as they occur.

Imprecise or Ambiguous Requirements

Requirements formulated vaguely ("the device must be easy to use," "measurement must be accurate") generate multiple interpretations and inconclusive tests. Each requirement must be verifiable with a measurable and unambiguous success criterion. Systematic requirements review before development start avoids these drifts.

Absence of Traceability Matrix

Without bidirectional traceability (requirement → output → test → result), the auditor cannot verify that all requirements have been satisfied. The traceability matrix must be created from the requirements phase and updated throughout the project.

Validation on Prototypes Instead of Production Units

21 CFR §820.30(g) explicitly requires validation on initial production units or equivalents. Validating only on prototypes exposes to refusal during FDA inspection or Notified Body audit.

Undocumented Modifications

Modifying design without following the change management procedure (impact assessment, approval, reverification) breaks DHF traceability. Each change, even minor, must be documented according to the established procedure.

Insufficient Design Reviews

Limiting to a single review at project end doesn't allow detecting problems early enough. Plan at minimum 3 to 4 formal reviews at key milestones, involving a person independent from the design team (21 CFR §820.30(e) requirement).

Partial Verification

Testing only main functions while neglecting secondary or safety requirements creates blind spots. All critical requirements must be verified with formal protocols and documented results.

Conclusion: The Design File, Your Best Ally 🏁

The design file is not an innovation brake: it's a control and credibility tool.

Benefits of a well-structured file:

✅ Rapid certification (fewer information requests)
✅ Controlled modifications (evaluated impact, targeted revalidation)
✅ Serene audits (immediate traceability)
✅ Cost control (prevention of delays and late corrections)

The 3 golden rules:

Start early: Integrate documentation from the first sprint
Trace everything: Traceability matrix = your best friend
Collaborate: R&D, Quality, Regulatory work together, not in silos

➡️ This is the key to successful CE marking and FDA authorization without blockage.

Ready to structure your design file for seamless certification?

At Certeafiles, we support you :

-Personalized support from our experts
-Practical adapted training
-Internal audits

👉Contact us for a free initial consultation and discover how Escyon can accelerate your market entry.