A Design History File (DHF) is the organized body of evidence showing how a medical device was designed and developed under controlled processes. For Software as a Medical Device (SaMD), connected devices, and other medical device software, it connects product intent to requirements, risk controls, design outputs, verification, validation, releases, and changes.
A DHF should never be a stack of documents assembled at the end of a project. It is a living, controlled record set built as engineering happens. When maintained well, it helps a manufacturer demonstrate that product decisions were intentional, traceable, reviewed, tested, and appropriate for the device’s intended use.
This guide explains what a design history file is, FDA design history file requirements in the QMSR era, what belongs in a DHF, how a DHF differs from related records, and how medical device software teams can manage templates, traceability, releases, remediation, and postmarket changes.
Important: This article provides general educational information, not legal or regulatory advice. The legal manufacturer remains responsible for its quality system, regulatory strategy, market authorization, product evidence, and postmarket obligations. Consult qualified regulatory professionals for product- and market-specific guidance.
What Is a Design History File?
A Design History File (DHF) is the organized set of records demonstrating how a finished medical device was designed and developed. The DHF should contain—or reference—the evidence needed to show that the manufacturer followed its approved design-and-development plan and applicable requirements.
A design history file is not necessarily a single physical folder, a single PDF, or a single software repository. In a modern quality system, it is often an index or a structured collection of approved records maintained across interconnected systems: an electronic QMS, a requirements-management platform, a risk-management tool, a source-control system, a test-management system, and a controlled document repository.
The key requirement is not the container. It is the ability to retrieve complete, current, approved, and traceable evidence showing how the product moved from user need to released design.
FDA Design History File Requirements and QMSR
Teams still commonly search for “FDA design history file requirements” and the former 21 CFR 820.30(j) DHF language. That terminology reflects the legacy Quality System Regulation framework.
FDA’s Quality Management System Regulation (QMSR) became effective on February 2, 2026, and incorporates ISO 13485:2016 by reference. The traditional term “DHF” remains familiar and useful, especially for organizations working with legacy FDA design-control terminology. In current practice, manufacturers should maintain documented design-and-development evidence consistent with their quality management system, QMSR, applicable FDA requirements, and requirements in each target market.
For software teams, this work is most effective when engineering is aligned early on the manufacturer’s classification, intended use, evidence, and submission strategy. See how Sequenex approaches SaMD engineering aligned to your regulatory strategy
For teams pursuing international market access, the design-and-development evidence maintained in the DHF also supports broader technical documentation, clinical evaluation, risk management, and conformity-assessment activities.
Why a DHF Matters for Medical Device Software
Medical device software can change quickly. Requirements evolve, algorithms are refined, integrations are added, cybersecurity vulnerabilities are discovered, and releases may occur more frequently than changes to traditional hardware products.
Without controlled documentation, a team may struggle to answer basic but high-stakes questions:
- Which user need led to this software requirement?
- Which risk was identified, and what feature or control reduces it?
- Was that control implemented, tested, and included in the released version?
- Which test cases verify a requirement after an update?
- Which software version was evaluated, approved, and deployed?
- Did a new integration, cloud-service change, or AI/ML model update affect safety, performance, privacy, cybersecurity, or regulatory status?
A well-maintained design history file makes those answers available through objective records rather than memory, informal conversations, or disconnected project-management tickets.
It also helps teams reduce costly rework. Reconstructing requirements, test evidence, risk decisions, and release history after development is often slower and less reliable than producing controlled records during development.
Design History File vs. Related Records
A DHF is important, but it is not the same as every other regulated product record. Confusing these record types creates gaps in evidence and weakens traceability.
Record | Primary purpose | Typical contents |
DHF / design-and-development record set | Demonstrates how the device was designed and developed under controlled processes | Design plans, user needs, design inputs and outputs, reviews, risk records, V&V evidence, usability evidence, changes, and release records |
Traceability matrix | Shows relationships among requirements, risks, design elements, tests, and releases | Links from user needs and requirements to design outputs, risk controls, test cases, test results, defects, changes, and versions |
Risk-management file | Demonstrates systematic risk-management activities across the product lifecycle | Hazard analyses, risk estimates, risk controls, residual-risk evaluations, benefit-risk analysis where applicable, and production/postproduction information |
Device Master Record (DMR) | Defines how the device is produced and serviced | Device specifications, manufacturing/process specifications, quality-assurance procedures, labeling/packaging specifications, and servicing procedures |
Device History Record (DHR) | Demonstrates that a specific device unit, lot, or batch was produced according to approved requirements | Production history, acceptance records, labeling records, quantities, and lot/batch-specific information |
EU technical documentation | Supports conformity assessment and market access under EU MDR or IVDR | Device description, classification rationale, GSPR evidence, risk-management documentation, clinical evaluation/performance evidence, PMS information, labeling, and technical records |
For software-only products, the DMR and DHR concepts may be implemented differently from traditional manufacturing records. However, teams still need controlled specifications, release records, deployment evidence, and appropriate evidence that the released product matches the approved configuration.
The Core Structure of a DHF
A strong design history file is organized around the product lifecycle. The exact structure varies by device, quality system, risk profile, and market, but the following components are commonly expected.
Design and Development Planning
Planning records explain how the organization will control design and development. They should identify responsibilities, interfaces, development phases, deliverables, reviews, risk management activities, verification and validation strategy, configuration management, and change control processes.
For medical device software, the plan should also address the chosen software lifecycle approach, third-party software, cloud infrastructure, cybersecurity, data management, and release practices.
User Needs and Intended Use
User needs state what users require from the product. Intended-use documentation identifies the medical purpose, intended users, patient population, use environment, clinical setting, limitations, contraindications, and relevant claims.
These records are foundational. If intended use is unclear or changes informally, downstream requirements, risk decisions, clinical evidence, labeling, and regulatory strategy can become inconsistent.
Design Inputs
Design inputs translate user needs, intended use, risk controls, regulatory requirements, usability needs, interoperability needs, cybersecurity requirements, and performance requirements into objective design criteria.
For SaMD, inputs may include clinical workflow requirements, alert thresholds, data-quality requirements, algorithm performance requirements, privacy/security requirements, mobile-device compatibility, cloud-availability requirements, and interface specifications.
Design Outputs
Design outputs describe how the device will meet design inputs. For software, outputs can include system architecture, software architecture, interface specifications, data-flow diagrams, database designs, source code, configuration specifications, user-interface designs, deployment configurations, and controlled build instructions.
Outputs should be reviewable and should provide an adequate basis for verification.
Design Reviews
Design reviews are formal, documented evaluations conducted at appropriate stages of development. They bring together relevant functions—such as engineering, quality, regulatory, clinical, product, cybersecurity, and manufacturing or operations—to assess whether the design is progressing appropriately.
A useful review record captures what was reviewed, who participated, key decisions, action items, unresolved issues, approvals, and the impact of decisions on risk, requirements, evidence, and timeline.
Risk Management
Risk management should be integrated throughout design and development, rather than added after feature decisions are complete. For each relevant hazard or hazardous situation, teams should document risk controls, evidence of implementation, evidence of verification, and residual risk evaluation.
For medical device software, risk records often connect to requirements, alarms and alerts, user-interface safeguards, cybersecurity controls, fault handling, data validation, access controls, algorithm behavior, and clinical workflow assumptions.
Design Verification
Design verification confirms that design outputs meet design inputs. It asks: “Did we build the product according to specified requirements?”
Verification evidence may include:
- Requirements-based test cases and results
- Code reviews and static analysis where applicable
- Unit, integration, system, interface, and regression test results
- Inspection or analysis of design outputs
- Cybersecurity control verification
- Performance testing against predefined acceptance criteria
- Verification of labeling, user-interface, and deployment requirements
Design Validation
Design validation confirms that the finished device meets user needs and intended uses under actual or simulated-use conditions. It asks: “Did we build the right product for its intended users and use environment?”
Depending on the product, validation evidence may include usability or human factors evaluations, clinical performance studies, simulated-use studies, workflow validation, user acceptance evidence, and validation of intended-use claims.
Verification and validation are related but different. A product can pass a requirement-based test and still fail to meet a user need in the real-world workflow it was intended to support.
Design Transfer and Release
Design transfer ensures that the approved design can be consistently implemented, produced, deployed, serviced, or otherwise released in accordance with established specifications.
For software, this can include approved release criteria, build and deployment procedures, environment configuration, version and configuration identification, release notes, installation instructions, operational handover, rollback procedures, and confirmation that the released version matches the tested and approved configuration.
Design Changes
Changes should be documented, reviewed, risk assessed, verified, validated as appropriate, and approved before release. This includes changes to requirements, architecture, source code, algorithms, data sources, integrations, infrastructure, third-party components, cybersecurity controls, labeling, and clinical claims.
A design-change record should answer: what changed, why it changed, which requirements and risks are affected, which evidence must be updated, what testing is required, whether the change affects regulatory status, and which released version contains the change.
Traceability: The Backbone of a Software DHF
Traceability is what turns a set of separate documents into defensible design-and-development evidence. It allows a reviewer to trace the relationships among a need, a requirement, a risk control, a design decision, a test, and a released product version.
A practical software traceability path looks like this:
User needsDesign inputsSystem/software requirementsDesign outputsRisk controlsTest casesTest resultsRelease evidence
Traceability should also work in reverse. If a test fails, a defect is discovered, a vulnerability is reported, or a customer complaint points to a safety issue, the team should be able to identify the affected requirements, risks, controls, versions, and users.
What a Traceability Matrix Should Include
A traceability matrix may be managed in a dedicated requirements tool, a QMS, or, for smaller programs, a controlled spreadsheet. It should be controlled, reviewable, and kept up to date.
Traceability element | Example question it answers |
User need | What user or clinical need does this feature address? |
Design input | What measurable requirement defines acceptable performance? |
Software requirement | What must the system or software do? |
Risk and risk control | What safety, performance, usability, or cybersecurity risk does it address? |
Design output | Where is the feature specified or implemented? |
Test case | How is the requirement or control verified? |
Test result | Did the approved build meet the acceptance criteria? |
Defect/change record | What happened if the feature changed or failed? |
Release/version | Which released configuration contains the approved and tested result? |
The traceability matrix is not a substitute for the DHF, DMR, DHR, or risk-management file. It connects evidence held across those controlled records.
For regulated software, traceability should be maintained continuously—from approved requirements through risk controls, test cases, test results, and release records—not recreated just before submission. Sequenex provides requirements traceability and V&V evidence as part of its SaMD engineering process.
Software-Specific DHF Evidence
A software-focused DHF should include more than just generic design control documents. The evidence should reflect the product’s architecture, data flows, cybersecurity profile, integrations, release model, and change velocity.
Software Development and Architecture Records
- Software development plan and lifecycle approach
- System and software requirements specifications
- Software architecture and detailed design records
- Data-flow diagrams and interface specifications
- Cloud, mobile, web, and device-integration architecture
- Software-item identification and configuration records
- Third-party, open-source, and software-of-unknown-provenance (SOUP) inventory
- Supplier and component evaluation records where applicable
Verification and Validation Records
- Requirements-to-test traceability matrix
- Unit, integration, system, interface, regression, and acceptance-test records
- Test protocols, predefined acceptance criteria, results, deviations, and approvals
- Performance, reliability, interoperability, and load-test evidence where applicable
- Usability-engineering and human-factors evidence
- Clinical-performance evidence where required by intended use or market pathway
- Defect records, investigation, root cause, corrective actions, and closure evidence
Cybersecurity Records
- Cybersecurity requirements and security architecture
- Threat model and threat-analysis records
- Authentication, authorization, encryption, logging, and access-control specifications
- Vulnerability assessments, penetration-test records, and remediation evidence where applicable
- SBOM and component-vulnerability monitoring processes where appropriate
- Security testing records and security-release approval criteria
- Incident response, patching, and coordinated vulnerability disclosure procedures
Configuration, Build, and Release Records
- Source-control strategy and configuration-management plan
- Approved baselines and version identification
- Build instructions, build records, and reproducibility evidence
- Release notes and known-issue records
- Release approval and deployment authorization
- Deployment configuration and environment records
- Rollback or recovery procedures
- Evidence that the released software configuration matches the tested, approved version
Maintaining the DHF in Agile Development
Agile development does not remove the need for controlled design evidence. It changes how teams must integrate those controls into frequent planning, development, testing, review, and release cycles.
The goal is not to turn every sprint into a paperwork exercise. The goal is to ensure that product iteration remains planned, traceable, risk-informed, verified, reviewed, and appropriately approved.
Practical Agile controls include:
- Maintaining a controlled product backlog linked to approved user needs and requirements
- Reviewing whether proposed stories or changes affect intended use, safety, cybersecurity, usability, performance, or regulatory claims
- Updating risk records when features, workflows, data inputs, or interfaces change
- Preserving versioned requirements, design records, code, tests, and release artifacts
- Maintaining bidirectional traceability from requirements and risk controls through verification evidence
- Defining objective release criteria and approval roles
- Capturing defects, deviations, investigations, and corrective actions in controlled workflows
- Performing periodic DHF completeness reviews rather than waiting for submission preparation
A useful principle is simple: if a change can affect safety, performance, quality, cybersecurity, clinical use, or regulatory status, it should be visible in the DHF evidence chain.
Cybersecurity and Postmarket Change Control
For software products, the DHF must support a lifecycle that continues beyond the initial release. New vulnerabilities, cloud platform changes, operating system updates, new integrations, third-party library updates, and customer feedback can all trigger controlled engineering work.
A mature postmarket process should connect field information to the design-and-development record set:
- Intake and triage of complaints, support issues, vulnerability reports, and performance signals
- Assessment of impact on safety, performance, privacy, cybersecurity, and regulatory status
- Investigation, root-cause analysis, corrective action, and preventive action where applicable
- Change-impact assessment for requirements, risks, tests, labeling, clinical claims, and submissions
- Verification and validation of updated software as appropriate
- Release approval, deployment monitoring, and rollback capability
- Documentation of the affected software version and customers or environments where relevant
This approach lets teams move quickly without losing control of the evidence needed to support safe, maintainable, and compliant software.
Cybersecurity evidence should be maintained alongside the rest of the DHF, including relevant threat models, component inventories, security testing, vulnerability assessments, and controlled remediation records. Learn more about Sequenex’s approach to cybersecurity artifacts for SaMD.
AI/ML Software in the DHF
AI/ML-enabled medical device software may require additional evidence because model behavior depends on data, training methods, evaluation methods, clinical context, and update controls.
In addition to standard software records, the DHF may need to reference or include:
- Data provenance, permissions, governance, and dataset descriptions
- Dataset inclusion/exclusion criteria and representativeness considerations
- Ground truth and labeling procedures
- Training, validation, and test-set definitions
- Model architecture, hyperparameters, code, and version records
- Performance metrics tied to the intended use and clinically relevant subgroups
- Bias, robustness, failure-mode, and human-factors analysis
- Model monitoring and drift-detection plans
- Controlled model-update procedures and change assessments
- Evidence supporting any planned modification approach, where applicable
A locked model still requires robust version and release control. An adaptive model introduces additional complexity because changes to model behavior must be governed, evaluated, documented, and assessed against applicable regulatory expectations.
Teams building AI-enabled medical software should also consider the broader AI/ML SaMD development considerations, including intended use, evidence strategy, model validation, controlled updates, and postmarket monitoring.
Common DHF Mistakes
Building the DHF at the End of Development
A design history file should be developed continuously. Retrospective documentation often reveals missing requirements, incomplete risk assessments, untraceable tests, and uncertain release history.
Confusing Verification With Validation
Verification demonstrates that design outputs meet design inputs. Validation demonstrates that the finished product meets user needs and intended uses. Both are necessary, but they answer different questions.
Treating Traceability as a Spreadsheet Exercise
A matrix is only useful if the linked records are controlled, complete, current, and meaningful. Traceability should reveal real relationships among requirements, risks, design outputs, tests, defects, changes, and releases.
Separating Risk Management From Software Development
Risk controls should be translated into requirements, design decisions, and test cases. A disconnected risk file cannot demonstrate that controls were implemented and verified.
Omitting Cybersecurity Evidence
Security controls, third-party software, vulnerability response, SBOM practices where appropriate, and release evidence should be planned—not created only after an incident.
Losing Version and Release History
Teams must be able to show which version was tested, approved, deployed, and changed. This is particularly important for cloud-hosted SaMD, frequently released products, and AI/ML products.
Creating Unnecessary Documents
The objective is not documentation volume. Create and maintain records that are necessary to demonstrate controlled design and development, traceability, safety/performance evidence, and compliance with the quality system.
Design History File Remediation: How to Address Gaps
Design history file remediation is the structured process of identifying, prioritizing, and closing gaps in design-and-development evidence. It is common when a product was developed before a mature quality system was established, after an acquisition, before a regulatory submission, or when a team is preparing for an audit or major release.
A practical remediation process includes:
- Define the scope. Identify the device, software versions, target markets, product changes, and milestone driving the review.
- Create a DHF index. Inventory existing records and identify the system of record for each item.
- Map traceability. Connect user needs, requirements, risk controls, design outputs, tests, defects, changes, and releases.
- Identify critical gaps. Prioritize missing evidence that affects intended use, safety, performance, cybersecurity, clinical evidence, or release history.
- Reconstruct evidence carefully. Use controlled records, source-control history, test outputs, issue records, reviews, and subject-matter expertise. Clearly distinguish contemporaneous evidence from remediation-created evidence.
- Perform risk-based verification and validation. Determine whether missing or changed evidence requires additional testing, analysis, usability work, cybersecurity assessment, or clinical evaluation.
- Document decisions and approvals. Record the rationale, corrective actions, residual gaps, and responsible approvals.
- Establish sustainable controls. Update procedures, tools, training, and review practices to prevent recurrence of the issue.
DHF remediation should not mean backdating documents or creating unsupported evidence. The purpose is to create an accurate, controlled, and transparent record of the product’s design and development history, as well as the actions taken to address gaps.
Design History File Template: Suggested Structure
A design history file template should act as a controlled index of approved records rather than a collection of empty forms. The exact structure should match the manufacturer’s quality system, device type, risk profile, development model, and target markets.
For medical device software, a practical DHF index can include:
- Project and document-control information
- Design and development plan
- Intended use, user needs, and product claims
- Design inputs
- Design outputs and architecture
- Design-review records
- Risk-management records
- Verification planning and results
- Validation planning and results
- Usability and human-factors evidence
- Cybersecurity documentation
- Configuration management, build, and release records
- Design-transfer records
- Design-change records
- Postmarket feedback and change-impact records
- DHF completeness review and approvals
The DHF index should identify each record’s title, document identifier, version, approval status, location, owner, and relationship to relevant requirements, risks, tests, and releases.
A template provides a starting structure. It does not replace product-specific design controls, risk management, verification, validation, or regulatory review.
Design History File Example for Medical Device Software
Consider a cloud-based SaMD application that analyzes patient-recorded ECG data and flags patterns for clinician review.
A simplified design history file evidence chain could look like this:
DHF element | Example record |
User need | A clinician needs a reliable way to identify ECG recordings that may require timely review |
Design input | The software must analyze uploaded ECG data and present flagged recordings according to defined performance and usability requirements |
Risk record | A false negative could delay review of a clinically important pattern |
Risk control | The product includes defined algorithm performance requirements, data-quality checks, and a workflow that makes limitations clear to the clinician |
Design output | Algorithm specification, data-processing design, user-interface design, and alert-display requirements |
Verification | Test results confirm that the implemented software meets defined data-processing, display, security, and performance requirements |
Validation | Simulated-use or clinical-workflow evidence confirms intended users can interpret and act on the output appropriately |
Release evidence | Approved version, test results, release notes, deployment configuration, and change assessment |
This is not a complete DHF and should not be treated as a submission-ready example. It illustrates how a DHF connects the product’s intended use, risks, technical implementation, testing, and released version.
Design History File Checklist
Before a major milestone—such as design transfer, a clinical evaluation, a regulatory interaction, submission preparation, or a significant release—review whether the design history file contains or references:
- An approved design-and-development plan
- Defined intended use, user needs, target users, claims, and use environment
- Approved design inputs and design outputs
- Current risk-management records connected to implemented controls
- Documented design reviews and resolution of significant action items
- Requirements-to-risk-to-test traceability
- Complete verification protocols, results, deviations, and approvals
- Appropriate validation evidence for intended users and intended use
- Current software architecture, interfaces, configuration, and component records
- Cybersecurity requirements, threat analysis, and relevant security-test evidence
- Version, build, release, deployment, and rollback records
- Controlled design-change records and impact assessments
- Postmarket feedback, complaint, issue, vulnerability, and CAPA links where applicable
- A DHF index that makes records easy to retrieve during internal review, audit, due diligence, or regulatory preparation
How Sequenex Supports DHF-Ready Software Development
Sequenex provides DHF-ready engineering deliverables for medical device software teams, including controlled requirements, architecture records, risk artifacts, V&V evidence, cybersecurity documentation, traceability matrices, and release records. Requirements, architecture, risk artifacts, test evidence, cybersecurity documentation, configuration records, and release evidence should be created as the product is built—not reconstructed later.
Sequenex supports medical device software teams with regulated engineering practices designed to produce controlled technical deliverables. Depending on the engagement, this may include SaMD product development, system and software requirements, architecture, integrations, risk-informed development workflows, verification and validation support, cybersecurity engineering, traceability matrices, and evidence of controlled release.
Sequenex operates within an ISO 13485-certified quality management system and structures engineering deliverables to integrate with the legal manufacturer’s quality processes and DHF. The manufacturer remains responsible for the applicable regulatory strategy, product evidence, submissions, and postmarket obligations.
If your team is building SaMD, modernizing regulated software, integrating connected devices, remediating DHF gaps, or preparing a product for a major milestone, a DHF-readiness review can identify documentation and traceability gaps before they lead to costly delays.
Frequently Asked Questions
What Is a Design History File?
A design history file is an organized, controlled set of records showing how a medical device was designed and developed. It contains—or references—evidence such as design plans, user needs, design inputs, design outputs, risk-management records, reviews, verification, validation, design changes, and release documentation.
Is a DHF One Document?
No. A DHF is usually an organized body of controlled records or an index that references records held across approved systems. The important point is that the required evidence is complete, current, retrievable, approved, and traceable.
What Goes in a Design History File?
A design history file typically includes design plans, intended use, user needs, design inputs, design outputs, design reviews, risk management records, verification results, validation results, change records, and design transfer or release documentation. For medical device software, it should also include evidence of architecture, cybersecurity, configuration, build, testing, deployment, and release, as appropriate.
Who Owns the DHF When an External Developer Builds the Software?
The legal manufacturer remains responsible for the quality system and design-and-development evidence. An external engineering partner can create technical deliverables, but responsibilities for ownership, review, approval, access, change control, and record retention should be defined in written quality and development agreements.
What Is the Difference Between a Design History File and a Device Master Record?
The design history file documents how the product was designed and developed. The Device Master Record defines the specifications and procedures needed to produce and service the device. For software, the DMR may include approved specifications for release, deployment, installation, configuration, and support.
What Is the Difference Between a DHF and a DHR?
The DHF is the design-and-development record set. The Device History Record provides evidence that a particular unit, lot, or batch was manufactured according to the approved DMR and applicable requirements. For software, equivalent evidence of release and deployment may be especially important.
Does a Design History File Apply to SaMD?
Yes. SaMD teams should maintain design-and-development evidence appropriate to the device and applicable quality-system requirements. Software DHF records commonly include requirements, architecture, risk controls, test evidence, cybersecurity records, configuration management, releases, and change history.
What Is Design History File Remediation?
Design history file remediation is a controlled process for identifying and addressing missing, incomplete, outdated, or untraceable design and development evidence. It typically includes an evidence inventory, traceability analysis, risk-based gap prioritization, additional verification or validation where needed, documented decisions, and preventive improvements to development controls.
Can Agile Software Development Be Compliant?
Yes. Agile methods can be used in a regulated lifecycle when teams maintain planning, traceability, risk management, verification evidence, configuration control, change assessment, and release approvals. The methodology is less important than the quality and control of the resulting evidence.
When Should the DHF Be Reviewed?
Review it throughout development, at formal design reviews, before major releases, during design transfer, before regulatory interactions or submissions, and after significant changes. Waiting until the end of a project increases the risk of missing evidence or leaving it untraceable.
Does a DHF Alone Prove a Device Is Safe and Effective?
No. A DHF is an important record of controlled design and development. It supports the manufacturer’s broader safety, performance, clinical, quality, and regulatory evidence, but it does not, on its own, establish market authorization or guarantee compliance.
