# How to Create a Design and Development File for Medical Devices **Lee Chickering** **April 3, 2026** _This blog was originally posted on January 15th, 2025. It was updated in 2026 in accordance 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](https://www.iso.org/standard/59752.html) and enforced by the FDA through the [Quality Management System Regulation (QMSR)](https://www.federalregister.gov/documents/2024/02/02/2024-01911/quality-management-system-regulation), 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](/content/capabilities/documentation/index.html) 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](https://www.iso.org/standard/59752.html), 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](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/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](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-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**](https://www.federalregister.gov/documents/2024/02/02/2024-01911/quality-management-system-regulation), 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](https://www.iso.org/standard/59752.html), [21 CFR 820 (QMSR)](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820), 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)](https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/premarket-notification-510k) 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](https://www.iso.org/standard/59752.html). The regulation [21 CFR 820](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-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](https://docs.ketryx.com/work-instructions/wi-01-requirement) 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](https://docs.ketryx.com/integrations/source-code/code-change-reviews) at key stages, involving cross-functional teams and independent evaluators. Record results in the Design and Development File. ### **Design and Development** [**Verification**](https://docs.ketryx.com/reference/project-settings#design-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](https://docs.ketryx.com/work-instructions/wi-02-software-item-spec). ### **Design and Development Changes (Clause 7.3.9)** Establish procedures to document, review, and [approve](https://docs.ketryx.com/manuals/man-11-approval-rules) 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](https://docs.ketryx.com/reference/document-templating) 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](https://docs.ketryx.com/manuals/man-01-ketryx-lifecycle-management#id-5.4.-versions-and-releases) - [Automated traceability matrices](/content/capabilities/traceability/index.html) - [Centralized document storage](https://docs.ketryx.com/work-instructions/wi-11-document) **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](https://docs.ketryx.com/manuals/man-08-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](https://www.iso.org/standard/72704.html). 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**](https://docs.ketryx.com/manuals/man-07-traceability) **:** 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](https://www.iso.org/standard/71604.html) standard for [SaMD lifecycle management](/content/use-case/samd/index.html). Example: Documentation of change control processes and maintenance plans for post-market updates. 9. **Final** [**Design Documentation**](https://docs.ketryx.com/manuals/man-01-ketryx-lifecycle-management#id-7.-records-and-artifacts) **:** 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**](/content/blog/traceability-101/index.html) **:** 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**](https://docs.ketryx.com/work-instructions/wi-11-document) **:** 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](https://www.iso.org/standard/59752.html), the [QMSR amendments to 21 CFR 820](https://www.federalregister.gov/documents/2024/02/02/2024-01911/quality-management-system-regulation), 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.