The Design History File (DHF) and Design and Development File (DDF) are the two primary regulatory records that document product design from conception through post-market monitoring. Every medical device organization must maintain one or both, yet many teams struggle with what belongs in these files, how to structure them, and what happens when auditors request them. This article clarifies what each file is, what it must contain, how they differ, and how to build compliant files that survive regulatory scrutiny.

What Is the Design History File (DHF)?

The Design History File is an FDA concept introduced in 21 CFR Part 820.30(j). It is the compilation of records containing the procedures and activities related to the design and development of the finished device. The DHF is the master record of the design process and serves as evidence that the organization followed its design procedures, performed required activities, and achieved design outputs.

The DHF Under FDA 21 CFR Part 820

The FDA does not specify a particular structure or format for the DHF—it must be organized in a way that enables the organization and FDA investigators to understand the design process. However, 21 CFR 820.30(j) requires that the DHF be established and maintained, that it contain or reference design inputs, design outputs, design review records, design verification records, design validation records, design change records, and design history. The regulation treats the DHF as a statutory document—if a design activity occurred, evidence of that activity must be in the DHF.

FDA investigators reviewing a DHF during an inspection follow a predictable pattern: they examine whether design inputs were defined, whether design outputs address those inputs, whether reviews occurred at appropriate points, whether verification and validation were adequate, whether changes were controlled, and whether the overall record is traceable and complete. A disorganized or incomplete DHF is a common FDA observation and can escalate into a warning letter if underlying compliance issues are identified.

What the DHF Must Contain

• Design input records: Documents that specify functional and performance requirements, including user needs, intended use, regulatory requirements, risk management inputs, and design standards.

• Design output records: Specifications, drawings, algorithms, software source code, material lists, and manufacturing procedures that define the finished device.

• Design review records: Minutes and approvals documenting formal design reviews (e.g., preliminary design review, critical design review, design release review).

• Design verification records: Test protocols, test reports, and evidence that design outputs meet design inputs (often includes bench testing, software validation, material testing).

• Design validation records: Clinical data, usability study reports, and evidence that the device meets intended use (often includes human factors validation, clinical trials, post-market surveillance).

• Design change records: Change requests, impact assessments, approvals, and implementation evidence for any modifications to the approved design.

• Design history narrative: A summary that explains the overall design process, key decisions, and how the design addresses safety and performance requirements.

• Risk management file: FMEA, risk matrix, risk assessment reports, and risk control measures linked to design elements.

What Is the Design and Development File (DDF)?

The Design and Development File is the ISO 13485 equivalent of the DHF. It is the compilation of records that demonstrate that design and development has been carried out according to the organization's documented design and development procedures. The DDF is not a regulatory file per se (since ISO 13485 is a quality management standard, not a regulation), but it is the primary file reviewed by notified bodies during conformity assessment audits in Europe and by other regulatory bodies examining ISO 13485 compliance.

The DDF Under ISO 13485 Section 7.3.10

ISO 13485 Section 7.3 addresses design and development control. Section 7.3.10 specifically requires that the organization establish and maintain a design and development file that includes or references the results of design input reviews, design output reviews, design review records, design verification records, design validation records, design change records, and design history. The standard gives organizations flexibility in format and organization but requires that the file be complete and traceable.

Notified bodies audit the DDF to confirm that the design process followed the organization's procedures, that all required activities (design input, design output, design review, design verification, design validation, design change control) were performed, and that the design is safe and effective. A DDF that is incomplete or poorly organized is a common source of non-conformities in ISO 13485 audits.

What the DDF Must Contain

• Design and development planning records: Plans that define the overall design strategy, timeline, resource allocation, and design review gates.

• Design input records: User needs, functional requirements, performance requirements, regulatory requirements, and risk management inputs.

• Design output records: Specifications, drawings, software design documents, manufacturing procedures, inspection and test procedures.

• Design review records: Evidence that formal reviews occurred at appropriate design phases with appropriate attendance and documented decisions.

• Design verification records: Test protocols, test reports, and evidence that design outputs satisfy design inputs.

• Design validation records: Clinical data, field trial reports, usability study reports, and evidence that the device meets intended use requirements.

• Design change records: Change requests, impact assessments, risk re-assessment, approvals, and implementation records.

• Design transfer records: Evidence that the design was successfully transferred to manufacturing or operations.

• Post-design activities: Field complaint data, adverse event reports, trend analysis, and evidence of design improvements based on post-market feedback.

DHF vs. DDF: Key Similarities and Differences

The DHF and DDF are functionally similar because ISO 13485 was developed in alignment with FDA's design control concepts. Both require documentation of design inputs, outputs, reviews, verification, validation, and changes. Both must be organized and traceable. Both are subject to audit and inspection.

The key differences are: (1) The DHF is required by FDA regulation (21 CFR 820.30(j)) for devices subject to US approval; the DDF is required by ISO 13485 for any organization claiming ISO 13485 compliance. (2) The DHF focuses on evidence of compliance with FDA regulations and intended-use claims; the DDF focuses on evidence of compliance with the organization's documented procedures. (3) The DHF must demonstrate that design verification and validation occurred; the DDF must also demonstrate that the design was transferred to manufacturing (design transfer). (4) Terminology: the FDA uses 'design input,' 'design output,' and 'design review;' ISO 13485 uses the same terms, but some organizations prefer 'requirements,' 'specifications,' and 'design reviews.'

In practice, most organizations maintain a single integrated file (often called the DHF or DDF depending on the primary regulatory jurisdiction) that satisfies both FDA and ISO 13485 requirements. The file will contain all required elements for both standards, even though some organizations operate under only one regulatory framework. Building a file to both standards is prudent because it future-proofs the organization if it expands into new markets.

Building a Compliant DHF or DDF: Practical Guidance

Start at the Beginning of the Project

Many organizations attempt to build DHF/DDF records after design is complete or after a product has already launched. This is far more difficult than capturing records as design activities occur. A compliant file requires that design inputs be documented before design begins, that design outputs be documented as they are created, and that reviews, verification, and validation occur at the right points in the timeline.

Organizations should establish the DHF/DDF structure and filing conventions before design begins. This includes defining what documents are required, where they will be stored, how they will be named and versioned, who is responsible for maintaining them, and how they will be indexed for retrieval. A project plan should explicitly allocate time and resources to DHF/DDF maintenance, treating it as a core design activity, not an afterthought.

Use a Consistent and Searchable Structure

The DHF/DDF should follow a logical hierarchy that mirrors the design process: design planning records at the top level, followed by design input records, design output records, design review records, design verification records, design validation records, and design change records. Within each category, documents should be indexed, numbered, and dated.

A searchable index or database is essential. Auditors and internal teams need to be able to find specific documents quickly. If the DHF is a forest of unindexed files on a shared drive or a stack of binders in a cabinet, it will fail inspection scrutiny. Modern DHF/DDF systems use document management tools that automatically index documents, assign metadata, and enable full-text search.

Maintain Complete Traceability Throughout

Every design output must be traceable back to design inputs. Every design verification test must be traceable to design outputs. Every design validation activity must address intended-use requirements. Every design review must have documented attendance and decisions. Every design change must show impact assessment, approval, and implementation evidence.

Traceability is typically maintained in a requirements traceability matrix (RTM), which maps user requirements → system requirements → design specifications → design outputs → verification tests → validation evidence → risk controls. The RTM is a key part of the DHF/DDF and is often the first document auditors request.

Keep It Living and Current

The DHF/DDF is not a static document created once and filed away. It is a living record that evolves with design changes. When a design is modified, the DHF/DDF must be updated to reflect the change, including impact assessment, re-verification if needed, updated risk assessment, and approval records. When post-market complaints or adverse events occur, the file should be updated to document investigation and any design improvements made in response.

Similarly, when new regulatory guidance is issued (e.g., an FDA guidance document or updated ISO standard), the organization should review the DHF/DDF to ensure it remains compliant. This may require adding missing documentation, clarifying design rationale, or updating records to reflect current regulatory expectations.

Common DHF and DDF Mistakes

• Design inputs not clearly defined: Requirements are vague or informal, making it impossible to verify that design outputs satisfy them.

• Verification and validation confused: Testing is labeled 'validation' when it is actually verification (testing that specifications are met), or vice versa, leading to gaps in evidence that the device meets its intended use.

• Design reviews not documented: Reviews occur in meetings but no minutes or approval records are generated, leaving no evidence that reviews happened.

• Traceability gaps: Design outputs exist but are not mapped to design inputs; or verification tests exist but are not linked to design specifications.

• Design changes not in the file: Changes are made to designs but not formally recorded in the DHF/DDF, creating hidden design drift.

• File not organized: Documents are in a folder with no index or naming convention, making it impossible to audit or retrieve specific records.

• No accountability: No person is designated as responsible for maintaining the file, resulting in inconsistent updates and missing documents.

• Post-market activities not recorded: Complaints are handled but not linked to the design file; design improvements are made but not documented as design changes.

DHF, DDF, and the EU MDR Medical Device File: How They Relate

The EU Medical Device Regulation (MDR 2017/745) requires a Technical Documentation File (TDF), which is distinct from but overlapping with the DHF and DDF. The TDF includes design and development records, risk management file, clinical evaluation report, and instructions for use. Organizations selling devices in Europe must maintain a TDF that satisfies the MDR.

An organization subject to both FDA and EU MDR requirements typically maintains an integrated file that satisfies all three: the DHF (for FDA), the DDF (for ISO 13485), and the TDF (for EU MDR). While there is significant overlap, some unique requirements differ—for example, the MDR's clinical evaluation report is not specifically required by FDA or ISO 13485. Similarly, the FDA's design history narrative may not be required by ISO 13485.

The safest approach is to build to all three standards simultaneously, ensuring that the file contains all elements required by any jurisdiction the organization serves. A file that is compliant with FDA, ISO 13485, and EU MDR will also satisfy other regulatory frameworks in most jurisdictions.

💡 Matrix Req's integrated DHF/DDF management automatically captures design inputs, outputs, reviews, verification, validation, and changes in a single traceable repository. Automatic impact analysis ensures changes are assessed, integrated risk management links risk controls to design elements, and compliance checking validates that the file meets FDA 21 CFR 820, ISO 13485, and EU MDR requirements.

A compliant DHF or DDF is the regulatory foundation of any medical device. It demonstrates that design was systematic, that safety and performance were considered, and that the organization exercised appropriate oversight. Organizations that invest in a structured, integrated approach to DHF/DDF management find that audits proceed smoothly, compliance gaps are identified and corrected before inspection, and product improvements are traceable and justified. The cost of building a compliant file is far less than the cost of remediation after an inspection or recall.