Design History File Remediation: A Practical Guide for Medical Device Manufacturers

The Design History File (DHF) is one of the most consequential documents in a medical device manufacturer's regulatory portfolio, yet it is also one of the most frequently misunderstood and neglected. At its core, the DHF is the complete compilation of records that describes the design history of a finished medical device. It serves as objective evidence that the device was developed in accordance with an approved design plan and that the resulting design meets specified requirements. In the United States, the DHF is an explicit regulatory requirement under 21 CFR 820.30(j), which states that each manufacturer shall establish and maintain a DHF for each type of device. The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of 21 CFR Part 820. In the European regulatory context, the concept is embedded within the technical documentation requirements of EU MDR 2017/745 Annex II, which demands comprehensive design and manufacturing information including design stages applied to the device, the complete results of all verification and validation activities, and data on design changes throughout the device lifecycle. While the EU MDR does not use the specific term "Design History File," the substantive requirements for demonstrating design control compliance are functionally equivalent. The DHF is not a design output in itself. It is the organized repository that captures every significant decision, verification, validation, review, and change that occurred during the design and development of the device. When properly maintained, the DHF tells the complete story of how a device went from concept to market-ready product, providing traceability from user needs through design inputs, design outputs, verification and validation, design reviews, and ultimately design transfer to manufacturing. When the DHF is incomplete, disorganized, or absent, the manufacturer loses the ability to demonstrate regulatory compliance to auditors, inspectors, and Notified Bodies, and exposes the company to warning letters, consent decrees, import alerts, and certificate suspensions.

The regulatory requirements for design controls, and by extension the DHF, originate from two primary frameworks that most global medical device manufacturers must satisfy. Under FDA regulations, 21 CFR Part 820, the Quality System Regulation (QSR), Subpart C establishes the design control requirements. Section 820.30 mandates that manufacturers of Class II and Class III devices (and certain Class I devices listed in 21 CFR 820.30(a)(2)) establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met. The design control process encompasses design and development planning, design input, design output, design review, design verification, design validation, design transfer, and design changes. The DHF under 820.30(j) is the compilation of all records generated during this process. FDA has published guidance documents, most notably "Design Control Guidance for Medical Device Manufacturers" (1997), which remains the foundational reference for interpreting the design control requirements. This guidance explicitly describes the DHF as a compilation that allows the manufacturer to demonstrate that the design was developed in accordance with the design plan. On the European side, EU MDR Annex II, Section 4 requires the technical documentation to include design and manufacturing information that allows understanding of the design stages and manufacturing processes, including identification of design stages applied to the device, complete information on the design verification and validation activities and their results (including the analytical, bench, and clinical studies), and information on the design changes. Additionally, the manufacturer must demonstrate compliance with the General Safety and Performance Requirements (GSPR) of Annex I through a systematic traceability structure. ISO 13485:2016, the harmonized standard for quality management systems in the medical device industry, reinforces these expectations in Clause 7.3, which requires outputs of design and development planning, inputs, outputs, reviews, verification, validation, transfer, and changes to be documented and maintained. The convergence of FDA, EU MDR, and ISO 13485 requirements means that a well-structured DHF serves as the common foundation for demonstrating design control compliance across multiple regulatory jurisdictions simultaneously.

DHF remediation becomes necessary in a range of scenarios that medical device manufacturers encounter throughout the device lifecycle. The most common trigger is the discovery of DHF deficiencies during an FDA inspection. FDA Form 483 observations related to design controls consistently rank among the top findings in device establishment inspections, and when an investigator documents that the DHF is incomplete, lacks required records, or does not demonstrate compliance with the design plan, the manufacturer must remediate the file to address the observation and prevent escalation to a warning letter. Warning letters themselves frequently cite specific DHF failures, such as the absence of design reviews at suitable stages, missing verification or validation records, failure to document design inputs adequately, or lack of evidence that the device was developed in accordance with the approved design plan. In the European context, remediation is increasingly driven by the transition from the Medical Device Directive (MDD) to the EU MDR. Legacy devices that were originally developed under less rigorous or no formal design control processes now require comprehensive technical documentation that demonstrates the design was controlled and validated. Notified Bodies conducting MDR conformity assessments routinely identify gaps in the design and manufacturing information section of the technical documentation and issue deficiency letters requiring the manufacturer to provide the missing evidence. Remediation is also triggered by corporate events such as mergers, acquisitions, and divestitures, where the acquiring company discovers that inherited product portfolios lack adequate design history documentation. Post-market events can drive remediation as well: when a CAPA investigation reveals that a design-related failure mode was not adequately addressed during original development, the manufacturer may need to reconstruct and remediate the DHF to demonstrate that the root cause has been identified and the design has been brought into compliance. Finally, manufacturers expanding into new markets, particularly the United States for companies that previously only held CE marks, often discover that their existing design documentation does not meet the specific DHF requirements of 21 CFR 820.30.

The medical device industry uses several overlapping terms that frequently cause confusion, and clarifying the distinctions is essential before undertaking any remediation effort. The Design History File (DHF) is, in FDA terminology, the compilation of records describing the design history of a finished device. It is specifically focused on the design and development process and contains or references all records generated during design controls. The Device Master Record (DMR), defined in 21 CFR 820.181, is a separate compilation that includes the device specifications, production process specifications, quality assurance procedures, and labeling needed to manufacture the device. The Device History Record (DHR), defined in 21 CFR 820.184, is the production record for each specific unit or batch of devices, documenting that the device was manufactured in accordance with the DMR. These three files serve distinct purposes: the DHF shows how the device was designed, the DMR shows how the device should be manufactured, and the DHR shows that a specific unit was manufactured correctly. In the European context, the term "technical documentation" or "technical file" refers to the comprehensive documentation required by EU MDR Annex II and III, which encompasses design information, manufacturing information, risk management, clinical evaluation, labeling, GSPR compliance, and post-market surveillance documentation. The technical documentation is broader in scope than the DHF because it includes post-market and lifecycle elements. The term "design dossier," historically used under the MDD for Class III devices undergoing Annex II (MDD) full quality assurance plus design examination, referred to a subset of the technical file focused on design and development. Under the MDR, the design dossier as a distinct document type no longer exists; its contents are subsumed into the unified technical documentation structure. When undertaking DHF remediation, manufacturers must understand which regulatory framework they are remediating for and ensure that the resulting documentation satisfies all applicable requirements. A DHF that satisfies FDA expectations may not fully satisfy EU MDR Annex II without additional content, and vice versa. The most efficient approach for manufacturers operating in both jurisdictions is to build a unified design documentation structure that meets the superset of requirements.

A complete DHF must contain or reference a defined set of records that, taken together, demonstrate the device was developed under controlled conditions with documented evidence of compliance at each stage. The design and development plan is the first essential component. This document establishes the scope, objectives, responsibilities, timeline, and required activities for the design project. It identifies the design stages, the deliverables for each stage, the design review points, and the resources and organizational responsibilities assigned to each activity. The plan must be updated as the design evolves. Design inputs are the documented physical and performance requirements of a device that are used as a basis for device design. These include functional requirements, performance specifications, safety requirements, regulatory requirements, applicable standards, environmental conditions, labeling requirements, and any user needs derived from market research, clinical input, or human factors analysis. Design inputs must be reviewed and approved for adequacy and documented in a manner that allows them to be verified. Design outputs are the documented results of the design effort at each design phase and at the end of the total design effort. They include device specifications, drawings, software source code and object code, manufacturing specifications, labeling, and any other documents that define the device and its production. Design outputs must be expressed in terms that allow comparison with design inputs to confirm that design requirements have been met. Design reviews are planned, systematic examinations of a design at defined stages to evaluate the adequacy of the design results, identify problems, and propose corrective actions. The DHF must document each review, including the participants, the design stage reviewed, the results of the review, and any actions taken. Design verification provides confirmation through examination and provision of objective evidence that design outputs meet design input requirements. Verification activities include inspections, analyses, bench testing, and other methods. The DHF must include the verification protocols, acceptance criteria, results, and conclusions. Design validation is the confirmation through examination and provision of objective evidence that the device specifications conform with user needs and intended uses. Validation must be performed on production-equivalent or initial production units under defined operating conditions, including simulated or actual use conditions. The DHF must include the validation protocols, acceptance criteria, results, and conclusions, including any software validation records and human factors validation results. Design transfer records document the process by which the design was translated into production specifications and methods, ensuring that the manufacturing process can reliably produce devices that meet the approved design outputs. Design change records document any changes made to the design after initial approval, including the rationale, impact assessment, verification or validation of the change, and approval before implementation.

The traceability matrix is the structural backbone of a well-organized DHF, and its absence or inadequacy is one of the most common deficiencies identified during both FDA inspections and Notified Body audits. A traceability matrix, sometimes called a requirements traceability matrix (RTM), is a document that maps and links each design input requirement to its corresponding design output, verification activity, and validation activity. The purpose is to provide objective evidence that every requirement has been addressed through the design process and that nothing has been lost, overlooked, or left unverified. At minimum, the traceability matrix should include columns for the requirement identifier, the requirement description or reference, the source of the requirement (user need, standard, regulation, or risk control measure), the design output that addresses the requirement, the verification method and reference to the verification protocol and report, the validation method and reference to the validation protocol and report, and the status of each linkage. For devices subject to both FDA and EU MDR requirements, the traceability matrix can be extended to include the applicable GSPR from MDR Annex I, the corresponding harmonized standard, and the specific evidence of conformity. This extended traceability matrix effectively becomes a combined DHF traceability and GSPR compliance tool. Building the traceability matrix retrospectively during a remediation effort is one of the most challenging and valuable activities. It forces the remediation team to reconstruct the logical chain from requirements to evidence, identify gaps where verification or validation evidence is missing, and determine which gaps can be filled with existing data versus which require new testing. The matrix also serves as a project management tool during remediation, allowing the team to track progress and prioritize activities. Common deficiencies in traceability matrices include incomplete mappings where requirements lack corresponding verification or validation evidence, circular references where a design output is cited as its own verification, ambiguous or untestable requirements that cannot be verified by any method, and failure to include risk control measures as design inputs that must be traced through verification and validation.

The risk management file and the DHF are deeply interdependent, and any remediation effort that treats them as separate exercises will produce incomplete results. ISO 14971:2019 requires manufacturers to establish, document, implement, and maintain an ongoing risk management process throughout the device lifecycle. The risk management file is the compilation of all records and results of this process, including the risk management plan, hazard identification and risk analysis results, risk evaluation, risk control measures and their verification of implementation and effectiveness, evaluation of overall residual risk, and the risk management report. The connection to the DHF operates in both directions. Risk control measures identified through risk analysis become design inputs that must be implemented through design outputs and verified and validated like any other design requirement. If a risk analysis identifies that a particular hazardous situation must be mitigated through a design feature, that feature must appear as a design input in the DHF, the corresponding design output must implement the feature, and the verification and validation records must confirm the feature performs as intended. Conversely, design review records in the DHF should reference the risk management file to confirm that design decisions were informed by risk analysis results. During remediation, one of the most common gaps is a disconnect between the risk management file and the DHF. The risk analysis may identify a hazard and specify a risk control measure, but the DHF may lack evidence that the control measure was implemented and verified. Alternatively, the DHF may contain design outputs that address safety concerns, but the risk management file may not trace these back to identified hazards. Closing these gaps requires the remediation team to perform a cross-reference audit between the two files, mapping each risk control measure to its corresponding design input, output, and verification or validation record. Where evidence is missing, the team must determine whether existing test data can be reinterpreted to demonstrate risk control effectiveness, or whether new testing is required. The risk management file must also reflect any changes made during remediation as design changes with corresponding risk impact assessments.

The usability engineering file, governed by IEC 62366-1:2015 and its companion document IEC 62366-2 (guidance), represents another critical interface with the DHF that manufacturers frequently overlook during remediation. IEC 62366-1 establishes a process for manufacturers to analyze, specify, develop, and evaluate the usability of a medical device as it relates to safety. The process encompasses use specification, user interface specification, hazard-related use scenarios, summative (human factors validation) evaluation, and the evaluation of user interface of unknown provenance. The usability engineering file documents this entire process and its outputs. The integration with the DHF is substantive. User needs and use specifications identified through usability engineering activities are a primary source of design inputs. The user interface specification, which defines how the user interacts with the device, becomes a design output that must be verified and validated. Hazard-related use scenarios identified through the usability risk analysis become inputs to both the risk management file and the DHF, as the design must incorporate mitigations for foreseeable use errors. Formative evaluations conducted during design and development are design verification activities that should be documented in the DHF. The summative evaluation, which is the final human factors validation study conducted on production-equivalent devices with representative users performing critical tasks, is a design validation activity that must be included in or referenced by the DHF. During remediation of legacy devices, the usability engineering file is often the weakest element. Older devices may have been developed before IEC 62366-1 was published or widely adopted, and the design documentation may contain little or no formal human factors evidence. Remediating this gap may require conducting a retrospective use specification based on analysis of the marketed device and its labeling, performing a hazard-related use scenario analysis informed by post-market complaint and incident data, and in some cases conducting a summative evaluation if the device has use-related risks that cannot be adequately addressed through existing evidence. The scope and depth of usability remediation should be driven by the device risk profile. High-risk devices with complex user interfaces, multiple user populations, or a history of use-related complaints will require more extensive usability engineering evidence than simple, single-function devices with straightforward user interactions.

Analysis of FDA warning letters, 483 observations, and Notified Body deficiency letters reveals a consistent pattern of DHF deficiencies that manufacturers should use as a diagnostic checklist during remediation planning. The single most cited deficiency is the complete absence of a DHF for a marketed device. This occurs most frequently with legacy devices that were developed before the manufacturer implemented formal design controls, or with devices acquired through mergers and acquisitions where design records were not part of the asset transfer. The second most common deficiency is an incomplete or disorganized DHF that exists in name but lacks critical records. Specific gaps frequently cited include missing or inadequate design input documentation, where requirements are vague, untestable, or do not address all applicable standards and regulatory requirements. Design verification records that do not cover all design inputs, or that lack documented acceptance criteria and pass-fail conclusions, are another persistent finding. Design validation deficiencies are equally common, particularly the failure to conduct validation on production-equivalent units, the failure to validate under actual or simulated use conditions, and the absence of software validation records for devices containing software. Design review records that do not identify the participants, the design stage reviewed, the specific issues raised, or the resolution of identified actions are frequently cited. Inadequate design change documentation is another major category, including changes that were implemented without risk assessment, changes that lack re-verification or re-validation evidence, and changes that were not approved before implementation. FDA investigators and Notified Body auditors also frequently identify failures in design transfer documentation, where the DHF does not demonstrate a controlled handoff from design to manufacturing, including confirmation that production processes can reliably reproduce the design outputs. Finally, traceability failures, where there is no clear linkage from user needs through design inputs, outputs, verification, and validation, consistently appear in inspection findings. Understanding these common deficiency patterns allows the remediation team to prioritize activities and allocate resources where the highest-risk gaps exist.

When confronting a DHF that requires remediation, the manufacturer must make a strategic decision between two fundamental approaches: a phased remediation that addresses the most critical gaps incrementally, or a full DHF reconstruction that rebuilds the file from the ground up. Each approach has distinct advantages and trade-offs, and the choice depends on the severity of the deficiencies, the regulatory pressure driving the remediation, the availability of historical records and subject matter experts, and the resources the manufacturer can allocate. A phased approach is appropriate when the existing DHF has a reasonable foundation but contains identifiable gaps. In this model, the remediation team conducts a gap analysis against the applicable requirements (21 CFR 820.30, EU MDR Annex II, ISO 13485 Clause 7.3), prioritizes the gaps based on risk and regulatory criticality, and addresses them in a structured sequence. High-priority items typically include establishing the traceability matrix, documenting any missing design reviews, completing verification and validation records for requirements that lack evidence, and ensuring design change records are complete and properly approved. The phased approach is less disruptive to ongoing operations, allows the manufacturer to demonstrate progress to regulators during the remediation period, and preserves existing documentation that is adequate. A full DHF reconstruction is warranted when the existing documentation is so incomplete or disorganized that incremental remediation would be more costly and time-consuming than starting with a clean structure. This is often the case for legacy devices that predate formal design controls, devices acquired without design records, or situations where an FDA warning letter demands comprehensive remediation. In a full reconstruction, the team builds the DHF from a retroactive design and development plan, reconstructs design inputs from the marketed device specifications, applicable standards, and risk analysis, documents design outputs from the current device specifications and manufacturing records, and assembles verification and validation evidence from existing test data, production records, and post-market performance data. Where historical evidence does not exist and cannot be reconstructed, the manufacturer may need to conduct new verification and validation activities. Regardless of the approach selected, the remediation must be conducted under the manufacturer's quality management system, with defined procedures, documented rationale, and proper review and approval of all remediation activities.

Effective DHF management requires not only the right content but also the right tools and processes to create, organize, and maintain that content throughout the device lifecycle. Many manufacturers continue to manage their DHFs using file-based systems consisting of shared network drives, folder structures, and document management systems such as MasterControl, Veeva Vault, or Greenlight Guru. These systems provide version control, electronic signatures, access controls, and audit trails that satisfy 21 CFR Part 11 and EU MDR requirements for electronic records. The choice of system is less important than the discipline of using it consistently. A well-organized DHF in a simple folder structure with proper document control is vastly preferable to a sophisticated electronic system populated with incomplete or unapproved records. Templates accelerate DHF creation and promote consistency, but they must be used thoughtfully. Standard templates for design and development plans, design review meeting minutes, verification and validation protocols, traceability matrices, and design change requests provide a starting framework that the team can adapt to the specific device. However, templates become a liability when they are filled in mechanically without genuine engineering analysis, when boilerplate text obscures the device-specific content, or when the template structure does not match the actual design process that was followed. Maintaining the DHF through design changes is where many manufacturers lose compliance. Every change to the device design after initial release must be documented in the DHF with a description of the change, the rationale, a risk assessment of the change impact, identification of which design outputs are affected, verification and validation evidence that the change does not adversely affect the device, and approval before implementation. The design change process must also evaluate whether the change triggers a new regulatory submission, notification to the Notified Body, or update to the clinical evaluation. Manufacturers should establish a periodic DHF review process, ideally aligned with management review or product quality review cycles, to confirm that the DHF remains current and complete as the device evolves through its commercial lifecycle.

DHF remediation is a resource-intensive undertaking that demands a combination of regulatory knowledge, engineering expertise, quality systems experience, and project management discipline. Manufacturers must honestly assess whether they have the internal capacity and expertise to execute the remediation effectively, or whether engaging external support is the more prudent path. External regulatory consulting support is most valuable in several specific scenarios. When a remediation is driven by an FDA warning letter or Notified Body certificate suspension, the stakes are high and the timeline is compressed. Experienced consultants bring pattern recognition from prior remediation projects and an understanding of what regulators expect to see in a corrective response. When the manufacturer lacks subject matter experts who were involved in the original device development, external consultants can apply structured methodologies to reconstruct the design history from available records, the marketed device, and current standards. When the manufacturer is simultaneously managing an MDR transition and an FDA remediation, consultants who understand both regulatory frameworks can build a unified documentation structure that satisfies both jurisdictions without duplicating effort. When the remediation requires new verification or validation testing, consultants with access to testing resources and laboratory networks can accelerate the process. At Swiss MPC, our approach to DHF remediation is built on the principle that remediation is not a documentation exercise but an engineering and regulatory exercise that must produce technically sound, audit-ready evidence of design control compliance. Our senior consultants conduct a thorough gap analysis, develop a risk-prioritized remediation plan, and execute the remediation working alongside the manufacturer's engineering and quality teams. We bring direct experience with FDA inspection responses and Notified Body deficiency resolution, and we structure every remediation deliverable to withstand the scrutiny of the most demanding auditors. Whether you are facing a regulatory enforcement action, preparing a legacy device portfolio for MDR transition, or building design control capabilities for the first time, our team provides the strategic guidance and hands-on execution that complex DHF remediation projects require. Contact us at info@swissmpc.com or call +41 44 586 72 67 to discuss your remediation needs.