The FDA's Quality Management System Regulation (QMSR) no longer uses the term Design History File (DHF). Instead, ISO 13485:2016 Clause 7.3.10 requires manufacturers subject to design and development requirements to maintain a design and development file for each medical device type or device family.
This file contains or references the records needed to demonstrate that the device was designed and developed in accordance with applicable requirements. The Medical Device File (MDF), required under Clause 4.2.3, is a related but distinct collection of current device specifications and procedures. Although the terminology and organization have changed, manufacturers must still maintain complete, controlled, and traceable evidence of the design and development process.
Introduction
In the US medical device industry, recent FDA regulatory changes have updated the terminology used for device design and development documentation. The Quality Management System Regulation (QMSR), which became effective on February 2, 2026, incorporates ISO 13485:2016 into 21 CFR Part 820. As a result, “Design History File” is no longer a defined record type under the regulation.
However, the documentation requirements behind the DHF have not disappeared. Medical device developers and professionals working across design, development, quality, and regulatory affairs still need to understand how design records should be created, controlled, and maintained.
In this post, we’ll explain what happened to the DHF, how design and development files differ from the Medical Device File, and what manufacturers need to document under FDA QMSR.
Key takeaways
What was a Design History File?
A Design History File (DHF) was a structured collection of records, required under the former 21 CFR 820.30(j), documenting how a medical device was designed and developed throughout its lifecycle. Its purpose was to demonstrate that the design process followed approved procedures and that the finished device met its design requirements.
Before the FDA’s new Quality Management System Regulation (QMSR) came into force on February 2, 2026, medical device manufacturers in the United States were required to maintain a DHF as part of their quality system documentation under the previous Quality System Regulation (QSR).
Although the term “Design History File” is no longer formally used under QMSR, the underlying expectation has not disappeared and much of the documentation required is the same, but organized differently. In essence, manufacturers are still required to maintain documented evidence of design and development activities.
Notably, many industry experts believe that legacy terminology will likely continue to persist informally for years. Many experienced medical device professionals still naturally refer to “the DHF” even when operating under ISO-based systems.
What is a Medical Device File and how is it different?
The Medical Device File (MDF), required under ISO 13485:2016 Clause 4.2.3, is the controlled set of current specifications and procedures needed to produce, monitor, install and service the device. It’s the closest equivalent to the former Device Master Record (DMR) and is a separate record from the design and development file.
Under the FDA’s new QMSR, which references international standard ISO 13485:2016 by reference, every manufacturer must establish and maintain a Medical Device File (MDF) for each medical device type or medical device family.
The MDF contains or references:
-
A general description of the device, its intended use, and its labelling (including instructions for use).
-
Product specifications.
-
Manufacturing, packaging, storage, handling, and distribution specifications or procedures.
-
Procedures for measuring and monitoring.
-
Installation and servicing requirements, where applicable.
In simple terms, the MDF describes how the device is manufactured and controlled in its current state. By contrast, the design and development file documents how the device was designed and developed.
Under ISO 13485:2016 Clause 7.3.10, the design and development file contains or references the records needed to demonstrate conformity with the design and development requirements of Clause 7.3. This includes records of design and development changes. It is a separate record from the MDF.
The distinction is primarily one of purpose and lifecycle stage: the MDF provides the controlled specifications and procedures needed to manufacture and service the finished device. Meanwhile, the design and development file provides evidence of the design and development process and its conformity with applicable requirements.
Overall, the MDF is used to demonstrate the safety and performance, and compliance of a medical device, while also providing documented evidence that appropriate design and development processes were followed throughout the product lifecycle.
Design and Development File requirements under FDA QMSR
The FDA’s QMSR incorporates ISO 13485:2016 directly into the US regulatory framework by reference, including the requirements surrounding design and development documentation. Specifically, Clause 7.3.10 outlines the expectation for organizations to establish and maintain design and development files for each type of medical device or device family. These files must either contain or reference the records generated during design and development activities.
The practical outcome is that manufacturers need to maintain:
- Design and development planning records
- User needs and design inputs
- Design outputs, including specifications, and acceptance criteria
- Design and development reviews
- Design verification
- Design validation
- Design transfer
- Risk management activities
- Design and development changes
- Traceability between requirements, risks, outputs, and testing
These requirements are largely unchanged from the previous DHF requirements. In other words, the underlying documentation itself remains very familiar.
What changed? Design and Development Files under FDA QMSR
Importantly, the FDA did not eliminate the need for traceable design documentation. Instead, the agency clarified that ISO 13485 already contains substantively similar requirements to those previously covered under the DHF terminology. For manufacturers, this means the practical compliance burden remains largely unchanged. Organizations must still demonstrate that devices were developed under controlled conditions, according to documented procedures, and with appropriate verification and validation activities.
The biggest adjustment for many companies starts with education (reading, learning about and complying with ISO 13485:2016 clause 7.3.10, which requires a design and development file for each medical device type or family, kept as a distinct record from the Medical Device File under Clause 4.2.3).
Beyond this, the majority of the adjustments are organizational rather than operational, because much of the information that needs to be kept remains the same. Documentation names, file names, existing documentation systems, templates, procedures, and training materials need to be updated to reduce compliance risks and reflect the new ISO-aligned terminology.
Recommended learning:
Design transfer in medical devices: What changed under FDA QMSR?
How do the Design and Development Files establish the design and development process?
Design and development files create documented evidence that a device moved from concept to approved finished product through a structured, controlled, and traceable process. The records typically cover these stages:
- Design and development planning: Defines development stages, responsibilities, resources, review points, interfaces, and methods for maintaining traceability.
- Design inputs: Translate user needs, intended use, safety requirements, performance expectations, and applicable regulatory requirements into defined and measurable requirements.
- Design outputs: Document the specifications, drawings, software requirements, acceptance criteria, and other results needed to produce and evaluate the device.
- Design review: Provides documented, systematic reviews of whether the design is progressing appropriately and whether any issues need to be addressed.
- Design verification: Demonstrates that the design outputs meet the approved design inputs.
- Design validation: Demonstrates that the resulting device meets user needs and its intended use under defined operating conditions.
- Design transfer: Ensures that design outputs are correctly translated into manufacturing specifications and production processes.
- Design changes: Records why changes were made, how their potential impact was assessed, and how they were reviewed, verified, validated, and approved where appropriate.
Together, these records create an auditable timeline showing not only what decisions were made, but also why they were made and how they were verified. This level of traceability is especially important during FDA inspections and ISO audits, where auditors often look for clear evidence that design decisions were systematically reviewed, approved, tested, and controlled throughout development.
Design and Development Files checklist: What belongs in your Medical Device File?
The exact documentation required will depend on device classification, complexity, applicable markets, and organizational processes. However, the overall goal is always to provide complete evidence that the device was developed and manufactured under controlled conditions. Although every organization structures documentation slightly differently according to device classification, a design and development file typically includes or references:
Planning
- Design and development plan
- Defined development stages and review points
- Roles, responsibilities, and interfaces
- Project timelines and deliverables
- Risk management plan
- Regulatory strategy
- Applicable standards and regulatory requirements
Design inputs
- User needs and intended use
- Functional and performance requirements
- Safety and usability requirements
- Applicable regulatory requirements
- Risk control requirements
- Evidence that inputs are complete, unambiguous, able to be verified or validated, and not in conflict with each other.
Design outputs
- Technical drawings and specifications
- Software architecture and software documentation, where applicable
- Bill of Materials
- Product and component specifications
- Manufacturing and inspection requirements
- Labeling and packaging specifications
- Output acceptance criteria
Design reviews
- Review plans and agendas
- Meeting minutes
- Identified issues and actions
- Review participants
- Decisions, approvals, and sign-offs
Design verification
- Verification plans and protocols
- Test methods and acceptance criteria
- Verification results and reports
- Records demonstrating that outputs meet inputs
- Documentation of deviations and resolutions
Design validation
- Validation plans and protocols
- Validation results and reports
- Usability or human factors studies
- Clinical or performance evaluations, where applicable
- Evidence that the device meets user needs and its intended use
Design transfer
- Manufacturing transfer plans
- Approved production specifications
- Process and equipment requirements
- Supplier qualification records, where applicable
- Evidence that the design was correctly transferred into production
Design changes
- Change requests and descriptions
- Reasons for each change
- Risk and impact assessments
- Review and approval records
- Verification or validation of the change, where applicable
- Updated traceability records
File control and traceability
- Design traceability matrix
- File index or table of contents
- Document approval and version history
- References to records stored elsewhere
- Confirmation that required records are complete and accessible
Risk Management
- Risk management plan
- Hazard identification and risk analysis
- Risk control measures traced to design inputs, design outputs and verification
- Residual risk verification
- Risk management report
- Production/post-production information feedback.
Common pitfalls when compiling the Design and Development Files
One of the most common issues manufacturers encounter is incomplete or fragmented documentation. When teams manage records across spreadsheets, emails, shared drives, and disconnected systems, maintaining traceability becomes extremely difficult. These issues can include:
Compiling the file retrospectively
Design and development records should be created and controlled as development takes place. Attempting to reconstruct decisions, reviews, test results, or approvals shortly before an audit can create gaps and make it difficult to demonstrate when and why key decisions were made.
Including records without a clear purpose
Completeness does not mean placing every project document into the design and development file. The file should contain or reference the controlled records needed to demonstrate conformity. Unnecessary drafts, duplicate records, and uncontrolled correspondence can make the file harder to maintain and review.
Unclear ownership and access
Organizations should define who is responsible for maintaining the file, approving records, managing access, and ensuring that referenced documents remain available. Shared folders with uncontrolled editing permissions, outdated email attachments, and unclear document ownership can undermine an otherwise compliant design process.
Another frequent challenge is poor version control of documentation, which can happen when storing and tracing files manually through spreadsheets rather than through modern electronic Quality Management System (eQMS).
During development, specifications and requirements often change rapidly, and without a centralized document management system such as an eQMS, organizations can easily lose track of approved versions or inadvertently rely on outdated records. These problems can create significant compliance risks, especially during FDA inspections or ISO certification audits.
In my experience, one of the biggest benefits of maintaining easily accessible and centralized design documentation is that it also improves internal organizational knowledge. Teams can revisit historical decisions, understand why changes were implemented, and reduce the risk of repeating past mistakes during future product iterations.
Conclusion: Make Design and Development Files easy with an eQMS
FDA QMSR has changed the terminology and regulatory framework surrounding medical device design records, but it has not removed the need to document the design and development process.
The former DHF requirements are now largely addressed through the design and development file required by ISO 13485 Clause 7.3.10. The Medical Device File is a related but distinct requirement that contains or references the current specifications and procedures needed to manufacture and support the device.
An eQMS like Scilife Smart QMS helps simplify this process by centralizing documentation, automating workflows, and maintaining complete traceability across design and development activities. With Scilife Smart QMS, medical device companies can:
- Centralize design and development documentation
- Maintain version control and approval traceability
- Simplify audit preparation and regulatory inspections
- Reduce compliance risks associated with fragmented records
- Improve collaboration between quality, regulatory, R&D, and manufacturing teams
By using a structured digital quality system, organizations can reduce administrative burden while maintaining confidence that their design and development files remain compliant, organized, and inspection-ready.
