How Should a Medical Device Startup Structure Its Design History File From Day One?

This is the question that arrives, usually with some urgency, when a medical device startup realizes that the FDA’s 510(k) or PMA submission is six months away and the design history has been living in a combination of Confluence pages, shared drives, Slack threads, and the institutional memory of two engineers who may or may not still be at the company.

The short answer: start the DHF before you write a single requirement, structure it around the six design control phases defined in 21 CFR 820.30, and treat every design decision as a DHF entry rather than a future documentation task. The rest of this article explains exactly what that means and how to do it.

What Is a Design History File, and What Does the Regulation Actually Require?

The Design History File is the compiled record that demonstrates a finished device was developed in accordance with the approved design plan. That is the FDA’s framing under 21 CFR 820.30(j). ISO 13485:2016 uses nearly identical language in Section 7.3, calling it the records that demonstrate the design and development process was followed.

Both frameworks share the same underlying logic: the DHF is not the device documentation, it is the process documentation. It answers the question “how did you arrive at this device?” not “what does this device do?” The difference matters. Engineers routinely conflate the DHF with the Device Master Record (DMR), which contains the instructions for manufacturing the device. The DHF contains the evidence that the design was controlled.

Concretely, 21 CFR 820.30 requires documented procedures and records for:

  • Design and development planning (820.30(b)): A plan that identifies responsibilities, phases, and review points.
  • Design inputs (820.30(c)): Requirements derived from intended use, user needs, and applicable standards.
  • Design outputs (820.30(d)): The specifications, drawings, and other documents that define the finished device.
  • Design reviews (820.30(e)): Formal, recorded reviews at each major phase with participants who are not directly responsible for the design.
  • Design verification (820.30(f)): Confirmation that design outputs meet design inputs.
  • Design validation (820.30(g)): Confirmation that the device meets user needs and intended use under actual or simulated conditions.
  • Design transfer (820.30(h)): Evidence that the design can be manufactured reproducibly.
  • Design changes (820.30(i)): Records of all changes with review and approval.

ISO 13485 Section 7.3 maps almost exactly onto this list, with slightly different terminology. If you structure your DHF to satisfy 820.30, you are most of the way to ISO 13485 compliance on design controls.

When Should You Start?

The moment you write your first user need statement. Not when you hire a regulatory affairs consultant. Not when you start verification testing. Not six months before submission.

The practical reason is this: the DHF must demonstrate that design controls were applied throughout development. If your earliest dated document in the DHF is a verification protocol written eighteen months into a two-year development program, you have not demonstrated that design controls governed the design — you have demonstrated that you performed verification. That is necessary but not sufficient.

The strategic reason is simpler: reconstruction is catastrophically expensive. Teams that backfill DHFs before submission routinely spend eight to twelve weeks doing work that, had it been done continuously, would have added roughly two to four hours per week to the development process.

The Six-Section DHF Structure That Actually Works

Think of the DHF as a folder structure — physical or digital — organized around the six design control phases. Every document belongs to one of these sections, and the sections tell a sequential story.

1. Design and Development Plan

This is your opening chapter. It should exist before any design work begins and should be updated as the program evolves. It documents: who owns design decisions, what the major development phases are, what the review criteria are for moving between phases, what applicable standards and regulations govern the device, and how design changes will be handled.

A common startup mistake is writing the plan after the fact to match what actually happened. This is both a regulatory problem and a missed opportunity. A real, dated plan that shows course corrections is more credible to an FDA reviewer than a pristine retrospective plan — because the former shows a controlled process and the latter shows paperwork.

2. Design Inputs

Design inputs are your requirements. This section should capture:

  • User needs: What the user is trying to accomplish, expressed in user language, not engineering language.
  • Intended use and indications for use: The regulatory framing of what the device does and for whom.
  • Design requirements: Engineering specifications derived from user needs, expressed in measurable, verifiable terms.
  • Regulatory and standards requirements: Any applicable FDA guidance documents, IEC 60601 series, ISO 14971, or device-specific standards.

The critical discipline here is traceability. Every design requirement should trace back to at least one user need or regulatory requirement. Requirements that cannot be traced to an origin are either unnecessary or missing their justification. Both conditions create problems during submission review.

Design inputs must also be reviewed and approved. The regulation requires that incomplete, ambiguous, or conflicting requirements be resolved. Document the resolution, not just the final requirement.

3. Design Outputs

Design outputs are the specifications, drawings, software architecture documents, algorithms, labeling, and other technical deliverables that define the device as it will be manufactured. The DHF section for design outputs should reference (or contain) these documents and explicitly link each output to the design input it satisfies.

This is where the traceability matrix — often called the Requirements Traceability Matrix or RTM — becomes essential. The RTM is not a separate deliverable; it is the connective tissue of the DHF. A well-maintained RTM shows that every input has at least one output, and every output was generated to satisfy at least one input.

4. Design Reviews

Each formal design review generates minutes, a participant list, a list of issues or action items, and their resolution. The regulation requires that reviewers include people who are not directly responsible for the design. For a small startup, this often means bringing in an external consultant or a team member from manufacturing or quality, not just the design engineers reviewing their own work.

Keep these records contemporaneous. A design review summary written three weeks after the meeting, based on notes, is weaker than minutes drafted during the meeting and signed within a day. Date everything.

5. Verification and Validation

Verification confirms that design outputs meet design inputs. Validation confirms that the device meets user needs under intended use conditions.

These are distinct activities. Verifying that a blood glucose monitor reports values within ±10 mg/dL of a reference standard is verification of an accuracy requirement. Demonstrating that intended users in a target population can use the device safely and correctly without training is validation. You need both.

The V&V section of the DHF should contain: the test plans, the executed protocols with raw data, and the test reports with pass/fail determination. The traceability between requirements and test cases should be explicit. An FDA reviewer should be able to look at any requirement and immediately identify which test verified it.

Risk management records — your ISO 14971 hazard analysis, risk control measures, and residual risk evaluation — belong here as well, since verification and validation are risk control activities.

6. Design Changes

Every change to a design requirement, output, or any controlled document after initial release must be captured, reviewed, approved, and assessed for impact. This section often becomes the most heavily populated section of a DHF on any program longer than six months.

The change record should capture: what changed, why it changed, who approved it, whether the change triggered re-verification or re-validation, and whether the risk analysis was updated.

Where Modern Tooling Changes the Equation

The structural framework above is not new. What changes the practical difficulty of executing it is whether your tooling supports continuous DHF population or forces periodic reconstruction.

Traditional approaches — requirements managed in Word or Excel, verification tracked in spreadsheets, design reviews documented in shared drive folders — force the reconstruction problem. The information exists, but it is not linked. Generating the traceability matrix before submission means someone manually connects hundreds of items across dozens of documents. That is the nightmare scenario.

Flow Engineering (flowengineering.com) is built around a graph-based requirements model that makes traceability a property of the data structure, not a documentation task. When a design input is created in Flow Engineering, it exists as a node in a connected model. When a design output is linked to that input, the trace is recorded automatically. When a test case is linked to both, the RTM is populated without anyone opening a spreadsheet.

For medical device teams, this matters in two specific ways. First, the DHF sections that require traceability — inputs to outputs, outputs to V&V — are continuously maintained rather than assembled at submission time. Second, when a design change is made, Flow Engineering’s model surfaces the downstream impact immediately: which outputs reference the changed input, which tests cover those outputs, which risk controls depend on them. This is exactly the kind of impact assessment that 820.30(i) requires you to document.

Flow Engineering is intentionally focused on requirements, traceability, and design controls. It is not a complete electronic quality management system (eQMS) and does not handle SOPs, CAPA workflows, or supplier management. Startups will still need a platform like Greenlight Guru, Qualio, or MasterControl for those functions. But for the design controls and DHF story specifically — inputs, outputs, traceability, verification linkage — it structures the work in a way that the DHF populates itself as the product is developed.

Practical Starting Points for a Startup With Nothing Yet

If you are early enough that the DHF is still empty, here is the sequence:

  1. Write the design and development plan this week. One document, fewer than ten pages. It will change. That is fine. Date it and version it.

  2. Capture user needs before you capture requirements. Interview intended users, document what you learned, and store it in the DHF. These become the root nodes of your traceability.

  3. Derive requirements from user needs explicitly. For every requirement you write, record which user need or regulatory obligation drives it.

  4. Choose a traceability tool before you have more than twenty requirements. At twenty requirements, a spreadsheet is manageable. At two hundred, it is not. The cost of migrating early is low. The cost of migrating pre-submission is high.

  5. Hold design reviews on a schedule, not as events. Quarterly phase reviews with documented participants and issues are more credible and less painful than a marathon design review session reconstructed before submission.

  6. Treat every change as a DHF entry. This is the habit that separates teams that have controlled DHFs from teams that have records that happen to exist.

The Bottom Line

The DHF is not a documentation project. It is a record of a controlled design process. The difference between those two framings determines whether building it is a continuous two-hour-per-week discipline or a pre-submission crisis that costs your team weeks and may delay your 510(k) by months.

Start the plan before you start the design. Structure it around the six phases of 820.30. Make traceability a property of your tooling, not a manual task. And treat every design decision — requirements, outputs, reviews, changes — as a DHF entry made in real time.

The FDA reviewer reading your DHF is asking one question: does this record demonstrate that a controlled process produced this device? The answer should be legible in the structure of the file itself.