How to Create a Design and Development File for Medical Devices

This blog was orginally posted on January 15th, 2025. It was updated in 2026 in accordence with the FDA QMSR (effective February 2, 2026)

The Design and Development File is a critical component of the medical device design and development process. Required by ISO 13485 and enforced by the FDA through the Quality Management System Regulation (QMSR), the Design and Development File ensures that medical devices are designed in compliance with regulatory standards for safety and effectiveness. For anyone involved in medical device development, understanding the purpose, structure, and requirements of the Design and Development File is essential.

This blog explores what a Design and Development File is, why it's important, and how it supports compliance in medical device development. We'll also provide actionable insights into creating and maintaining a robust Design and Development File to help satisfy regulatory requirements and streamline your device's path to market.

What is a Design and Development File?

A Design and Development File is a collection of documents that demonstrate a medical device has been developed in accordance with a company's design plan and regulatory requirements. Under ISO 13485:2016, Clause 7.3.10, organizations are required to maintain a Design and Development File for each medical device type or medical device family. The file must include records of all activities and design outputs related to the development of the medical device.

If the term sounds new, you may know it by its predecessor: the Design History File (DHF). When the FDA's QMSR took effect on February 2, 2026, it amended 21 CFR Part 820 to incorporate ISO 13485 by reference rather than maintaining its own standalone requirements. The substance of what you need to document hasn't changed; the terminology and regulatory framework have been harmonized with the international standard.

What Changed Under the QMSR (and What Didn't)

Under the previous 21 CFR 820 (the Quality System Regulation, or QSR), FDA maintained three distinct record types:

• Design History File (DHF): Focused on the design and development process, capturing all records from planning through validation.
• Device Master Record (DMR): Contained instructions, drawings, and specifications for manufacturing the device.
• Device History Record (DHR): Documented the manufacturing history of a specific device or batch, confirming it met specifications.

Under the QMSR, 21 CFR 820 now incorporates ISO 13485 by reference. This consolidates the regulatory terminology:

• DHF is now the Design and Development File (ISO 13485 Clause 7.3.10). This is the file you maintain for each device type to document the full design and development process.
• DMR and DHR are now encompassed by the Medical Device File (MDF) (ISO 13485 Clause 4.2.3). The MDF consolidates manufacturing specifications, production records, and related documentation into a single framework.

What didn't change: You still need to document everything you documented before: inputs, outputs, verification, validation, transfer, changes, and traceability. The substance is identical. The QMSR repackages these requirements under ISO 13485 terminology, aligning the U.S. regulatory framework with international standards that many manufacturers already follow.

Why is the Design and Development File Important?

The Design and Development File serves multiple critical purposes:

1. Regulatory Compliance: The documentation contained in the Design and Development File demonstrates adherence to ISO 13485, 21 CFR 820 (QMSR), and other global regulatory requirements.
2. Quality Assurance: It confirms the device meets performance and safety standards through documented evidence.
3. Traceability: It provides a clear record of decisions, changes, and approvals throughout the design lifecycle.
4. Market Approval: A complete Design and Development File is essential for regulatory submissions, such as FDA 510(k) or PMA (Premarket Approval) applications.
5. Risk Management: It supports risk analysis and mitigation activities by documenting safety evaluations throughout development.
6. Design Knowledge Repository: It acts as a knowledge repository for future product updates or investigations.

Design and Development Requirements Under 21 CFR 820 (QMSR) and ISO 13485

With the QMSR in effect, the FDA's design and development requirements are now defined by ISO 13485 Clause 7.3. The regulation 21 CFR 820 still exists, but its substance now points to ISO 13485 rather than maintaining separate, FDA-specific requirements. ISO 13485 was previously an optional recommendation by the FDA. The Design and Development File must capture the following activities, which map directly to the subclauses of ISO 13485 Clause 7.3:

Design and Development Planning (Clause 7.3.2)

Organizations must create and update plans outlining design activities, responsibilities, and interdepartmental interactions. Plans must evolve as the design progresses and receive formal approval.

Design and Development Inputs (Clause 7.3.3)

Establish procedures to define design requirements that address user needs and intended use. Resolve ambiguities, and document and approve requirements.

Design and Development Outputs (Clause 7.3.4)

Define and document design outputs to confirm they meet inputs and allow proper functioning. Document design output approvals.

Design and Development Review (Clause 7.3.5)

Conduct documented reviews at key stages, involving cross-functional teams and independent evaluators. Record results in the Design and Development File.

Design and Development Verification (Clause 7.3.6)

Confirm that outputs align with inputs. Document methods and results, and include them in the Design and Development File.

Design and Development Validation (Clause 7.3.7)

Validate the design under actual or simulated conditions to confirm it meets user needs and intended use. Record results in the Design and Development File.

Design and Development Transfer (Clause 7.3.8)

Verify that design outputs are suitable for manufacturing before transfer to production. Document procedures for translation of the design into production specifications.

Design and Development Changes (Clause 7.3.9)

Establish procedures to document, review, and approve design changes before implementation.

Design and Development File (Clause 7.3.10)

Maintain a Design and Development File for each medical device type or medical device family. The file must contain or reference the records generated to demonstrate conformity to the design and development requirements and records for design and development changes.

Building the Design and Development File

Maintaining a process for compiling the Design and Development File is vital for compliance and efficiency in medical device development. Here's how to do it:

Establish a Design Plan

Develop a detailed roadmap outlining every stage of the design process, the team responsible, and the expected deliverables.

Standardize Documentation

Use templates and standardized formats to promote consistency and completeness across all Design and Development File documents.

Integrate Cross-Functional Teams

Involve design, engineering, quality assurance, and regulatory teams in maintaining the Design and Development File.

Utilize Dedicated Software

Consider using dedicated software tools to streamline the creation and management of the Design and Development File. Features to look for include:

• Version control
• Automated traceability matrices
• Centralized document storage

Conduct Regular Reviews

Schedule periodic reviews of the Design and Development File to confirm it remains up to date and aligned with regulatory requirements.

Common Challenges in Managing Design and Development Files

Documentation Gaps: Failure to document activities or decisions can result in noncompliance and delays in regulatory approval.

Version Control: Managing multiple iterations of design documents without proper versioning can lead to confusion and errors.

Incomplete Risk Analysis: Neglecting to document risk management activities can leave significant gaps in the Design and Development File.

Regulatory Complexity: Navigating evolving regulations (including the transition from QSR to QMSR) requires constant attention and updates to the Design and Development File.

What Would a Sample Design and Development File Include?

Design and Development File Example Structure

1. Design and Development Plan: A document outlining the overall strategy, timeline, and objectives for the design process. Example: A project plan detailing milestones, team responsibilities, and deliverables for SaMD development.

2. User Needs and Design Inputs: A record of user needs that translate into specific design requirements. Example: "The software must provide real-time glucose monitoring for diabetic patients, accessible via a mobile app."

3. Design Outputs: Tangible results of the design process, such as software architecture, source code, and user interfaces. Example: Screenshots of the SaMD user interface, system flow diagrams, and performance specifications.

4. Risk Management Documentation: Includes risk analyses, mitigation strategies, and compliance with ISO 14971. Example: A risk assessment identifying potential cybersecurity threats and detailing encryption measures implemented to mitigate them.

5. Design Verification and Validation (V&V): Documentation proving the design meets user needs and intended use. Example: Test reports demonstrating that the SaMD accurately diagnoses conditions based on input data.

6. Design Reviews: Records of formal design reviews conducted at key milestones. Example: Meeting minutes summarizing stakeholder feedback and action items from a software prototype review.

7. Traceability Matrix: A visual or document showing the relationships from design inputs to outputs, verification, and validation activities. Example: A matrix showing how specific software requirements are tested and validated during the development process.

8. Software Lifecycle Processes: Adherence to the IEC 62304 standard for SaMD lifecycle management. Example: Documentation of change control processes and maintenance plans for post-market updates.

9. Final Design Documentation: A comprehensive summary of the approved design, ready for submission to regulatory bodies. Example: A finalized version of the SaMD's system architecture and user manual.

Best Practices for Maintaining a Design and Development File

1. Document Everything: Record every decision, activity, and approval, even if it seems minor.
2. Prioritize Traceability: Link all documents to specific design inputs, outputs, and changes.
3. Train Your Team: Provide ongoing training for team members on the importance and requirements of the Design and Development File.
4. Use a Central Repository: Maintain a centralized location for all Design and Development File documents to simplify access and audits.

The Design and Development File is more than just a regulatory requirement; it's a cornerstone of medical device design and development. A well-maintained Design and Development File supports compliance, facilitates regulatory approvals, and provides a roadmap for future device iterations.

By understanding the requirements of ISO 13485, the QMSR amendments to 21 CFR 820, and the best practices outlined here, medical device manufacturers can streamline their development processes while prioritizing patient safety and product quality. Building a process is not just about meeting regulatory expectations—it’s about setting your device up for success in a competitive market.

How Ketryx Helps with Your Design and Development File

Ketryx simplifies and accelerates the creation and maintenance of the Design and Development File by automatically capturing traceability across requirements, risks, tests, and design artifacts. It integrates seamlessly with tools like Jira, GitHub, GitLab, and eQMS platforms, so all relevant records stay synchronized and up to date without disrupting existing workflows.

The platform's automated documentation capabilities compile all requirements, design inputs, outputs, and tests into a configurable, submission-ready Design and Development File directly from your development tools. Documentation is generated as an artifact of work, not as an additional workstream; your Design and Development File builds itself as the product progresses.

Ketryx also supports versioning and change management. With AI Change Impact Assessment, teams can use agents or the Assistant to identify, analyze, and act on change impacts across the Design and Development File in minutes rather than weeks. And with Ketryx AI Agents, teams receive proactive guidance to keep the Design and Development File audit-ready at all times, with a human in the loop at every step.