How to Build a Design History File That Survives FDA Scrutiny (Part II)

Note: read part I here.

The Traceability Matrix: Where Most DHFs Fall Apart

The single most important DHF document that teams underinvest in is the design traceability matrix (DTM). It’s the document that links:

• User needs → Design inputs → Design outputs → Verification activities → Validation activities → Risk controls

An auditor or reviewer will ask to see the traceability matrix early. It’s the fastest way to evaluate whether the program has actually managed design controls or just accumulated records.

A traceability matrix that’s incomplete, out of date, or shows gaps is more damaging than a single missing record because it suggests the gaps are systemic rather than isolated.

What a strong traceability matrix looks like:

• Every user need traced to at least one design input
• Every design input traced to at least one output, and at least one verification activity
• Every verification activity with a pass/fail status and a reference to the test record
• Risk controls linked back to the risk assessment and forward to their verification evidence
• The matrix kept current through every design change

What a weak one looks like:

• Built once, at the start of the project, and never updated
• Inputs listed at a high level that don’t map clearly to testable specifications
• Validation rows left blank with “TBD” that never got filled in
• No linkage to the risk file

---

The Risk File Has to Live in the DHF

Risk management documentation (your risk analysis, FMEA, risk control measures, and risk-benefit assessment per ISO 14971) should be part of the design record and integrated with the DHF.

This means:

• Risk controls must be traceable to design outputs
• Risk control effectiveness must be verified (and those verification records are in the DHF)
• Residual risk evaluation must reference the validation record
• Changes that affect the risk profile must trigger a risk file update

When the risk file sits in a separate system with no connection to the design controls record, auditors can’t evaluate whether risks were actually mitigated through design. The file may be technically complete but functionally disconnected.

---

Practical Habits That Make the Difference

Build it in real time, not in retrospect

The biggest DHF failure mode isn’t a missing document; it’s a document that was written from memory three months after the decision was made. Contemporaneous records are stronger. They reflect what was actually known at the time. Retroactively constructed records often contain internal inconsistencies that signal their origin.

Date-stamp decisions, not just approvals

When a design input changes, when a test protocol is revised, when a risk control is modified, the record should reflect when that happened and why. Undated documents, or documents dated at the time of final approval, that don’t reflect the actual decision timeline are a documentation integrity problem.

Treat informal design decisions as formal ones

The design decision you made in a hallway conversation still needs to be captured. Many DHF gaps originate not from negligence but from team members making good-faith engineering decisions in real time without a formal change notice. Building a habit of capturing decisions as part of the normal workflow is what separates teams that pass audits from those that scramble before audits.

Conduct a DHF audit before your FDA audit

Before an FDA inspection, conduct an internal DHF audit with someone who wasn’t directly involved in the development. Have them trace a user need from the top of the traceability matrix to the bottom, cross-referencing documents along the way. What they can’t find or reconcile, an FDA investigator won’t be able to either.

Understand what “complete” means before you submit

A DHF for a 510(k) submission is a complete record of design history to date. A DHF for a Class III PMA is more extensive. Knowing what completeness looks like for your regulatory pathway, and building toward that standard from the beginning, prevents the painful sprint to fill gaps at the end of development. Understanding the full product development process helps teams see where DHF requirements fit across each phase.

---

Common 483 Observations Related to Design Controls

If you want to understand what FDA investigators actually flag, 483 observation data is instructive. Among the most frequent design controls observations:

• Failure to establish and maintain procedures for one or more design control requirements
• Incomplete or non-existent design inputs, particularly where inputs weren’t defined before design began
• Inadequate design verification. Missing protocols, undefined acceptance criteria, or results without documented methods
• Missing or incomplete design validation. Using the wrong device units, or not demonstrating representative use conditions
• Undocumented or inadequately controlled design changes. Changes made without formal review or impact assessment
• Lack of traceability between design inputs, outputs, and testing

These aren’t obscure edge cases. They’re consistent patterns across companies of all sizes and device classes, and they’re also all preventable with more structure.

---

Where DISHER Engineering Can Help

At DISHER Engineering, we’ve supported medical device programs from early design controls setup through FDA submission preparation, across device classes from Class I to Class III, combination products, and software as a medical device.

When we join a program, whether at concept stage or mid-development, we integrate with your team’s existing design controls process and help ensure that the documentation record being built will hold up under review. That includes design controls framework setup, traceability matrix development, V&V protocol writing, design change management, and DHF audit support before submission.

If you’re unsure whether your DHF is ready for regulatory scrutiny, our Medical Device Product Development Readiness Assessment is a structured way to evaluate your standing across product, regulatory, engineering, and manufacturing readiness before you find out the hard way.

If you’d rather talk through your specific situation, we’re here for that conversation.