This guide covers what the design history file is, what design history file requirements apply under FDA QMSR and ISO 13485, exactly what it must contain, and how to build one that holds up under inspection.

What Is a Design History File?

A Design History File (DHF) is a structured compilation of records that documents the entire design and development history of a medical device. It is not a single document. It is a file, or a collection of records, that demonstrates your device was designed through a controlled, documented process aligned with your design plan.

The DHF must contain or reference all records necessary to show that design and development were conducted in accordance with your approved design plan and applicable regulatory requirements. Every design decision, every test result, every design review, and every design change must be traceable through the DHF.

FDA described it directly: the DHF captures the history of how your device came to be. If a record does not exist in the DHF, in FDA’s assessment, the activity either did not happen or was not controlled.

Design History File Requirements: What Regulations Say

Design history file requirements come from two sources that now operate in alignment.

Under the FDA’s Quality Management System Regulation (QMSR), effective February 2, 2026, the DHF requirement is carried forward from 21 CFR Part 820.30 and now operates under ISO 13485:2016 Section 7.3.10. The QMSR incorporates ISO 13485 by reference, meaning the standard’s design and development file requirements are now U.S. regulatory requirements.

ISO 13485 Section 7.3.10 states that organizations must maintain a design and development file for each medical device type or device family. The file must include or reference documents generated to demonstrate conformity to design and development requirements, and documents generated during design and development.

Under both frameworks, the DHF must be established at the start of development and maintained throughout. It is not a document created at the end of the design process. It is built in real time as design activities occur.

What the Design History File Must Contain

Design history file requirements specify that the DHF must contain or reference records covering the complete design control lifecycle. The following records are required.

Design and Development Plan

The design plan defines who is responsible for each design phase, the timeline and milestones, the design review points, and the verification and validation activities required. The plan must be established before development begins and updated as the project progresses. The DHF holds each version of the plan with its approval record.

Design Inputs

Design inputs are the functional, performance, safety, usability, and regulatory requirements your device must satisfy. They form the specification baseline against which your verification testing is measured. Every design input must be documented, reviewed, and approved. When an input changes, the change must be controlled and documented in the DHF.

Incomplete or vague design inputs are one of the most common causes of 510(k) additional information requests. FDA expects inputs to be specific, measurable, and traceable to user needs and applicable standards.

Design Outputs

Design outputs are the results of the design process: drawings, specifications, bill of materials, manufacturing instructions, and acceptance criteria. Outputs must meet every design input requirement and must be in a form suitable for manufacturing once transferred.

The DHF must contain the approved design output documents, including version history and approval records for each.

Design Review Records

Formal design reviews must occur at defined stages of development. Each review must have documented attendees, agenda, design status, action items, and outcomes. Design review records confirm that independent evaluation of the design occurred at defined milestones and that issues identified were formally tracked to resolution.

Design Verification Records

Verification confirms that design outputs meet design inputs. It requires documented test protocols written before testing begins, executed test results, and a formal statement of whether each design input was satisfied.

The DHF must contain both the approved protocol and the completed results record for every verification test. Undocumented or informal testing does not satisfy design history file requirements.

Design Validation Records

Validation confirms that the finished device meets the needs of the intended user under actual or simulated use conditions. It is distinct from verification. Verification asks whether you built the design right. Validation asks whether you built the right design.

Validation records in the DHF include usability testing protocols, clinical evaluation documentation, simulated use test results, and the formal validation summary report. All validation must be completed before the design is transferred to production.

Design Transfer Records

Design transfer documents confirm that the design has been correctly translated into production specifications. This includes evidence that production staff can manufacture the device to specification, that production processes are validated where required, and that the Device Master Record (DMR) reflects the completed, validated design.

Design Change Records

Every change to a design input, output, specification, or process after initial approval must go through a controlled change process. The DHF must contain change request records, impact assessments, approval records, and evidence that verification or validation was repeated where required by the change.

Undocumented design changes are one of the highest-risk DHF gaps. An inspector who identifies that a device in the field differs from the validated design without a corresponding change record will treat it as a major quality system nonconformance.

DHF vs DMR vs DHR: Understanding the Difference

Three related terms cause consistent confusion in medical device quality management. Understanding their differences is essential for building a correct documentation structure.

The Design History File (DHF) documents how the device was designed. It covers the design and development process from concept through design transfer. It is the development record.

The Device Master Record (DMR) documents how the device is manufactured. It contains the specifications, procedures, and drawings required to produce the device consistently. It is the production instruction set.

The Device History Record (DHR) documents that a specific production lot or unit was manufactured in accordance with the DMR. It is the production execution record.

These three records are distinct and must be maintained separately. The DHF feeds the DMR at design transfer. The DMR governs the DHR at production. All three are required by FDA QMSR and ISO 13485.

When to Start the Design History File

The DHF must start before design and development activities begin, not after.

This is the most common design history file requirement that teams violate. Many medical device companies, especially startups and early-stage teams, develop their device through informal iterations, generate test data, and then attempt to write DHF documentation after the prototype is working. This approach is not compliant and FDA inspectors recognize it.

A retroactively constructed DHF has no real-time design review records. It has no evidence that verification protocols were written before testing began. It has no audit trail showing when decisions were made and why. These gaps are evident to anyone reviewing the records.

The correct approach: create your design plan on day one. Open your DHF when you write your first design input. Document every review, test, and decision in real time as it happens.

Common Design History File Mistakes

These failures appear consistently across startup and established device company audits and inspections.

Starting the DHF after development is complete. Retroactive documentation creates traceability gaps, inconsistent timestamps, and records that do not accurately reflect the development process. This is the most inspected and most cited DHF failure.

Incomplete design inputs. Vague or incomplete inputs like “device must be safe” or “device must meet applicable standards” are not measurable and cannot be verified. Inputs must be specific, quantified, and tied to user needs or regulatory requirements.

Missing verification protocols. Executing tests without approved written protocols before testing begins means test results are uncontrolled. FDA expects to see that the protocol existed and was approved before the test was run, not written after the results were generated.

Skipping design reviews. Design reviews must be formal, documented, and include independent reviewers who are not directly responsible for the design element under review. Informal team meetings with no records do not satisfy design review requirements.

No change control for design changes. Every change to an input, output, or specification requires a documented change record. Design changes made informally, even minor ones, create audit trail gaps that become inspection findings.

DHF not linked to the risk management file. Risk management records must be integrated with design controls. Your hazard analysis informs design inputs. Your risk controls appear in design outputs. A DHF with no connection to the Risk Register is structurally incomplete under ISO 14971:2019 requirements.

How to Build a Design History File: A Practical Sequence

Building a defensible DHF follows the sequence of design controls activities. The DHF is not something you build separately. It is the output of a properly executed design controls process.

Before development begins: Create and approve your design and development plan. Define inputs for design reviews, verification, and validation. Open the DHF folder or system and begin version-controlling all documents from this point forward.

During design and development: Document every design input as it is defined and approved. Record every design review meeting with attendees, content reviewed, decisions made, and action items assigned. Write verification protocols before testing begins. Execute tests per the approved protocol and record results as they occur. Update the risk management file as design outputs are defined.

Through design verification: Compile all verification test results against their corresponding design inputs. Document any design changes that resulted from verification findings, including impact assessments and re-verification where required.

Through design validation: Document all validation activities, including simulated use testing, usability testing, and clinical evaluations where required. Produce a validation summary that confirms the device meets user needs and intended use requirements.

At design transfer: Document the transfer of design outputs to production. Confirm that all production processes can reproduce the validated device design. Establish the Device Master Record. Record formal transfer approval.

Post-transfer: Maintain the DHF as a controlled, version-tracked record set. Any post-transfer design change requires a change control record that references and updates the DHF.

Managing the Design History File in a Validated eQMS

A DHF managed in a paper binder, a shared folder, or a general-purpose document management system creates immediate design history file requirement gaps. Version control is manual. Approval records exist in email. Timestamps are not tamper-evident. Traceability between design inputs and verification results requires manual cross-referencing.

A validated eQMS purpose-built for medical device quality management solves each of these problems with a connected, traceable record structure.

Cloudtheapp’s Design Controls application manages the full DHF lifecycle in a single platform. Design plans, inputs, outputs, review records, verification protocols and results, validation records, and design change records are all created, approved, and linked within the system. Every record carries a compliant electronic signature and an immutable audit trail. Design inputs link directly to verification results. Risk records link to design outputs. Change records reference the specific DHF sections they affect.

When an FDA inspector or a certification body auditor asks to see your DHF, you produce a complete, traceable, timestamped record set rather than a binder assembled from scattered files and email threads.

For a broader view of how design controls fit into the full QMS structure for medical device startups, see QMS for Medical Device Startups: Building Compliance Infrastructure from Day One.

Conclusion

Design history file requirements are clear: the DHF must be established before development begins, maintained in real time, and contain complete, traceable records across the full design control lifecycle. A DHF built retrospectively, incompletely, or without a validated record management system will not satisfy FDA or ISO 13485 inspection expectations.

The good news is that a well-structured design controls process, executed correctly from day one, produces the DHF as a natural output. The records exist because the work was done in a controlled, documented way. The DHF is simply the organized collection of those records.

If your team is building a Design History File now and needs a validated eQMS platform that manages design controls, risk management, and document control in one connected system, book a free demo of Cloudtheapp and see how quality teams build complete, inspection-ready DHFs without the paper binder.

This post created by and appeared first on Cloudtheapp

A practical guide to 510(k) QMS requirements for medical device startups — covering design controls, DHF, risk management, CAPA, and how QMSR 2026 changes what FDA expects before clearance.

What QMS Does a Medical Device Startup Need for 510(k)?

If you are building a medical device and targeting the 510(k) pathway, your quality management system is not an afterthought you stand up after clearance. It is part of the evidence that gets you there.

The FDA evaluates your 510(k) submission for substantial equivalence to a predicate device, but your QMS sits directly behind that submission. Design controls documentation, risk analysis records, verification and validation test protocols, and your Design History File all come from the same QMS you build before you submit.

Startups that delay QMS implementation until post-clearance consistently spend more time and money correcting gaps than they would have spent building it right from day one. This guide breaks down exactly what 510(k) QMS requirements apply to medical device startups, what FDA inspectors look for, and how to structure your QMS for clearance without overbuilding it.

What Is a 510(k) and Why Does Your QMS Matter for It?

A 510(k) Submission is a premarket notification submitted to the FDA under Section 510(k) of the Federal Food, Drug, and Cosmetic Act. It applies primarily to Class II medical devices and requires the manufacturer to demonstrate that the new device is substantially equivalent to a predicate device already legally on the U.S. market.

Clearance does not equal approval. FDA grants clearance based on substantial equivalence, meaning your device performs similarly to the predicate in intended use, technological characteristics, and safety profile. But the documentation that supports substantial equivalence, specifically your performance testing, risk analysis, and design records, all come from your QMS.

Beyond the submission itself, FDA can inspect your facilities after clearance or at any point during commercialization. A QMS that cannot withstand inspection is a business risk even after you clear 510(k).

Does FDA Require a Full QMS Before a 510(k) Submission?

This is one of the most common questions medical device startups ask. The direct answer: no, FDA does not require your full Quality Management System Regulation (QMSR) QMS to be operational before you submit a 510(k). However, FDA does require design controls to be in place and documented during the development process.

Design controls are not retroactive. You cannot develop your device, generate your test data, and then write your design controls documentation afterward. The controls must be in place during design and development, which means your QMS framework for design controls must exist before you begin those activities.

The practical approach for pre-production companies is to implement the QMS elements that govern design and development first, then build out the full QMS as you move toward manufacturing and commercialization. This approach satisfies 510(k) QMS requirements without requiring you to build a complete post-market QMS on day one.

The practical implication: start your QMS at the beginning of product development, not at the end.

The Core 510(k) QMS Requirements Every Startup Must Meet

The QMSR, effective February 2, 2026, incorporates ISO 13485:2016 by reference and governs all quality management system requirements for medical device manufacturers in the United States. Under QMSR and ISO 13485, the following QMS elements are directly relevant to 510(k) preparation.

Design Controls

Design controls are the most critical 510(k) QMS requirement. They are required under ISO 13485 Section 7.3 and were previously codified under 21 CFR Part 820.30. Under the 2026 QMSR, they remain a mandatory quality system element.

Design controls require you to define and document your design and development process through these stages:

Design planning: Define who is responsible for each design phase, what the inputs and outputs are, and what verification and validation activities are required.

Design inputs: Document the functional, performance, safety, and regulatory requirements your device must meet. These inputs become the basis for your verification testing.

Design outputs: Document the specifications, drawings, and production procedures that result from the design process. Outputs must meet every input requirement.

Design verification: Confirm through testing or analysis that your design outputs meet your design inputs. This is the test data that appears in your 510(k) submission.

Design validation: Confirm that your finished device meets the needs of the intended user under actual or simulated use conditions.

Design transfer: Ensure the completed design translates correctly into production specifications.

Design changes: Control and document any changes to the design after the initial approval.

Without documented design controls, your 510(k) submission lacks the technical foundation FDA expects. Design control records also feed your Design History File.

Design History File

The Design History File (DHF) is the compiled record of your device's entire design and development history. It is not a single document. It is a structured collection of all design control records, including inputs, outputs, verification test results, validation records, design reviews, and any design changes.

The DHF is what an FDA inspector reviews to verify that your device was designed in accordance with your approved design plan. A missing or incomplete DHF is one of the most common reasons 510(k) submissions receive additional information requests from FDA.

Start your DHF on day one of development. Every design review meeting, every test result, every input revision must be captured in the DHF as it happens. Reconstructing a DHF after the fact is one of the most expensive quality mistakes a startup can make.

Cloudtheapp's Design Controls application manages the full DHF lifecycle in a single validated platform, from design inputs through validation records, with a complete audit trail for every document version and approval.

Risk Management

Risk management is required by ISO 14971:2019 for all medical devices. It is also referenced throughout ISO 13485:2016, making it a direct 510(k) QMS requirement under the QMSR.

Your risk management file must include a risk management plan, hazard identification, risk analysis, risk evaluation, risk controls, and a post-production risk monitoring plan. The residual risk after controls must be acceptable relative to your device's intended benefit.

Risk analysis outputs, specifically your hazard analysis and risk control measures, also appear in your 510(k) submission as part of your safety and performance data.

A Risk Register connected to your device design records keeps risk management integrated with design controls rather than managed as a separate, disconnected exercise.

Document Control

Document control is the operational foundation of your QMS. Every procedure, specification, test protocol, and record in your QMS must be version-controlled, approved, and traceable.

For a 510(k)-stage startup, document control means:

• Every SOP has an approved version with an electronic signature and revision history
• Obsolete documents are retired immediately upon the release of a new revision
• All design and test records are controlled and retrievable on demand

FDA inspectors reviewing a 510(k) submission company will ask to see the documents behind the data. If your test protocols are uncontrolled, your test results are untrustworthy in the FDA's assessment.

CAPA

Corrective and Preventive Action (CAPA) is required under ISO 13485 Section 8.5.2 and 8.5.3. Even in a pre-production startup environment, you need a functioning CAPA process.

Why does a startup need CAPA before they have products in the field? Because nonconformances happen during development. When a test fails, when a design input changes because of a user study finding, when a supplier delivers out-of-specification material, those events require documented investigation and corrective action. CAPA is the mechanism that closes those loops.

A CAPA system that cannot document Root Cause Investigation for development nonconformances is a gap FDA will find in a post-clearance inspection.

Supplier Controls

If your device incorporates purchased components, sub-assemblies, or contract manufacturing services, ISO 13485 requires supplier controls. This includes an approved supplier list, supplier qualification records, incoming inspection procedures, and a process for issuing supplier corrective action requests when a supplier delivers nonconforming material.

For 510(k)-stage startups, supplier controls are especially important for any critical components that affect device safety or performance. Your Supplier Quality Management process does not need to be complex, but it must be documented and defensible.

How QMSR 2026 Changes 510(k) QMS Requirements

The FDA's Quality Management System Regulation (QMSR) became effective on February 2, 2026, replacing the legacy Quality System Regulation (QSR) under 21 CFR Part 820. The QMSR incorporates ISO 13485:2016 by reference, meaning FDA now enforces the full ISO 13485 standard as part of its regulatory framework.

For medical device startups pursuing 510(k), this change has three key implications.

ISO 13485 is now the U.S. standard. Companies previously operating under the QSR framework must now align with ISO 13485 requirements. For startups building a QMS from scratch, this means building to ISO 13485 from day one rather than retrofitting later.

Management responsibility language is stronger. QMSR increases the accountability requirements for senior leadership in maintaining an effective QMS. Quality objectives, management review, and resource allocation requirements are now explicitly tied to ISO 13485 language.

International alignment is complete. If your startup plans to pursue CE marking or other international regulatory clearances, a QMSR-compliant QMS that follows ISO 13485 satisfies both U.S. and international requirements simultaneously.

For more detail on the QMSR transition, see FDA QMSR 2026: The Complete Guide to the Quality Management System Regulation.

Common 510(k) QMS Mistakes Medical Device Startups Make

Startups pursuing 510(k) clearance consistently encounter the same quality system failures. Knowing these mistakes before you encounter them saves months of remediation work.

Starting the QMS too late. The most common and most costly mistake. Design controls documentation must exist from the beginning of development. Any test data generated without active design controls in place is essentially uncontrolled, and FDA will treat it that way.

Separating risk management from design controls. Risk management and design controls feed each other. Your hazard analysis informs your design inputs. Your risk controls inform your design outputs. When these are managed in separate systems with no connection between them, gaps appear in both.

Building a paper QMS. A QMS managed in binders, shared drives, and email threads cannot scale to commercialization. FDA Form 483 observations related to document control are the most consistently cited quality system finding across device inspections. Paper systems fail document control requirements.

Reconstructing the DHF after development. Many startups develop their device informally and then write their DHF documentation after the fact to prepare for submission. This approach creates audit trail gaps and is a significant inspection risk.

Treating CAPA as a post-market activity. CAPA is required during development. Every design failure, test nonconformance, and supplier deviation generates a CAPA record. A startup with zero CAPA records at submission is telling FDA they never encountered a nonconformance during development, which is not credible.

How to Build a 510(k)-Ready QMS Without Slowing Down Development

The goal is a QMS that is rigorous enough to satisfy 510(k) QMS requirements without creating administrative overhead that delays your device timeline.

Phase 1, before design begins: Establish document control, create your quality manual, define your design control procedure, and set up your risk management framework. These three elements must exist before any design activity begins.

Phase 2, during design and development: Execute design controls in real time. Create design inputs, document every design review, generate verification and validation test protocols before testing begins, and record results as they happen. Build your DHF incrementally, not retrospectively.

Phase 3, before submission: Complete your risk management file, finalize your DHF, confirm all design verification and validation records are complete, and run an internal audit against your 510(k) QMS requirements. Identify and close gaps before submission.

Phase 4, post-clearance: Build out the remaining QMS elements required for commercialization: production controls, complaint handling, post-market surveillance, and full CAPA system expansion.

Cloudtheapp's eQMS platform is built for exactly this phased approach. Medical device startups can activate the Design Controls, Document Control, Risk Management, and CAPA applications from day one, then expand to the full suite as the company scales toward production. The platform is validated to FDA QMSR and ISO 13485:2016, so every record you generate from day one is part of a defensible, audit-ready quality system.

For a broader look at QMS infrastructure for device startups, see QMS for Medical Device Startups: Building Compliance Infrastructure from Day One.

Conclusion

510(k) QMS requirements are not a compliance checkbox you satisfy at the end of development. Design controls, risk management, document control, and CAPA are the infrastructure that makes your submission credible and your post-clearance operations defensible.

Startups that build their QMS from day one spend less time in remediation, produce stronger submissions, and reach commercialization faster than those that bolt on compliance infrastructure at the end.

If your team is at the beginning of this process and looking for a validated eQMS platform built for medical device startups, book a free demo of Cloudtheapp and see how quality teams configure a full 510(k)-ready QMS in weeks, not months.

This post created by and appeared first on Cloudtheapp