What is a DHF — and why the ones that fail review are always the ones that got compiled at the end

Half the Design History Files I've reviewed in the last two years were compiled, not maintained. You can tell at a glance. The narrative is too clean. Every design decision traces to a stated rationale. Nothing contradicts anything else. Memory is reconstructive, not reproductive — a real development history has fragments, open questions, dead ends that got abandoned. A compiled DHF smooths all that out. FDA reviewers know the difference.

21 CFR 820.30(j) requires every manufacturer to establish and maintain a DHF for each type of device. The file has to demonstrate the design was developed according to the approved plan and the regulation. "Maintained" is the word that does the work. A DHF assembled six weeks before submission isn't a maintained file. It's a reconstruction. Reconstructions fail review at predictable rates.

What 820.30 actually requires inside the file

The regulation structures design controls as a sequence, and the DHF has to cover evidence of each stage.

Design and development planning. What you intended to build, how you planned to build it, who owns what phase. The plan isn't a static document — it updates as development progresses, and a plan that doesn't reflect the actual project trajectory is a documentation failure.

Design inputs. The physical and performance requirements the device must satisfy. Not marketing requirements. Engineering requirements with measurable acceptance criteria. User needs translate into inputs, and that translation itself has to be documented. Common gap: well-articulated user needs, well-defined outputs, no documented logic for how one became the other.

Design outputs. The deliverables — drawings, specs, software, manufacturing procedures. Outputs must be expressed in terms that allow evaluation against the inputs they satisfy. If your output can't be measured against your input, your design control process has a structural gap.

Design reviews. Formal documented evaluations at appropriate development stages. Each review includes at least one individual who doesn't have direct responsibility for the stage being reviewed. Records include attendees, findings, action items, and action item closure. Incomplete review records — common ones are missing attendee lists or unclosed action items — are standard FDA findings.

Design verification. Does the output meet the input? Testing, analysis, inspection. Records of what was tested, how, what the acceptance criteria were, what the results showed.

Design validation. Does the device meet user needs under actual or simulated use conditions, with representative users? Validation confirms the specifications were the right specifications, not just that the device met them.

Design transfer. Translation of verified and validated design into production. Evidence that what gets manufactured at scale is what was validated.

Design changes. Every change needs documentation, impact evaluation, verification and validation as appropriate, and approval before implementation. Every change extends the traceability thread. Every change that doesn't extend the thread is a future finding.

The compilation problem in practice

Here's what the compiled DHF actually looks like. Engineering team finishes their work using whatever tools they use — CAD, requirements tools, Jira, source control, shared drives, emails. Submission is approaching. Regulatory affairs hires or assigns someone to "build the DHF." That person spends weeks reading files, interviewing engineers, writing rationale statements for decisions made 18 months earlier. Out comes a coherent document package.

The structural problem is the gap between what happened and what got written. The engineer who picked a particular material in month 4 of the project may have had three alternatives under consideration. They ran tests on all three. Two didn't pan out for reasons that didn't get fully written up. The compiled DHF says "Material X was selected based on performance characteristics." The rationale for rejecting Y and Z — and the test data behind those rejections — either didn't get captured, or got captured informally and didn't make it into the final record.

FDA reviewers aren't looking for the conclusion. They're looking for the evaluation that produced it. A DHF that presents only conclusions, written with the clarity of hindsight, raises questions about whether design controls were followed or documented after the fact.

The 510(k) review letters I've seen most often cite "insufficient design documentation" — a euphemism for "this reads like it was written at the end, and we want to see the contemporaneous evidence." The path forward is usually a Deficiency response that adds 60-120 days to the review. For PMAs the stakes are higher.

The change management trap

Every design change has to update the DHF. Input changes, output changes, risk control changes, verification records, validation coverage — whichever are affected. In a fragmented documentation environment, identifying which records need updating requires manual cross-referencing across disconnected systems.

The natural result is that changes get implemented and the DHF updates lag. Not because engineers are careless. Because the mechanism for keeping the DHF current is someone manually checking, every time. The check either happens rigorously and slows everything down, or it happens loosely and creates record drift.

Record drift is where most of the 10+ year post-market product liability claims originate. A lawsuit asks for DHF excerpts from 2018. The design has changed three times since. The DHF reflects some of those changes. Tracing which version of the record corresponds to the incident is a forensics exercise.

Why a generated DHF is structurally different

If the DHF is an output of the engineering process rather than a separate compilation task, the gap between work and record closes. Design decisions made in the platform are structured with their regulatory context from the moment they exist. A design input isn't just text — it's an object that knows which user need it addresses, which design outputs will implement it, and which verification activity will confirm it.

Design changes become change events that understand their downstream implications. The risk file entries affected, the verification tests that need re-running, the validation coverage that may need supplementing — all surface automatically when the change gets proposed.

The DHF isn't a document assembled at submission time. It's the accumulated record of the engineering work, accurate continuously because it's the direct byproduct of the decisions, not a reconstruction of them. By the time submission prep starts, the record is substantially complete. The work shifts from compilation to review — confirming the record is adequate, not building it from scratch.

This isn't a convenience story. It's an evidence-quality story. A maintained DHF has coherence that a compiled DHF can't manufacture after the fact. FDA reviewers, notified bodies, plaintiffs' attorneys in product liability cases — each reads the DHF for different reasons, and each can tell when it was built continuously versus when it was assembled in a hurry.

The DHF vs the DMR — a clarification that matters

Common confusion worth clearing up. The DHF is the history of how the device was designed and developed — everything between initial concept and design transfer. The Device Master Record (DMR), required under 21 CFR 820.181, is the complete set of specifications needed to manufacture the finished device — drawings, process procedures, specifications, quality assurance procedures, installation instructions.

DHF is past tense — it captures what happened during development. DMR is present tense — it's the recipe that production follows every day. Both are required. They reference each other but serve different purposes. Submissions that conflate them, or that use DMR-style content where DHF-style evidence is expected, generate Additional Information requests.

Why MANKAIND generates the DHF rather than compiles it

The premise behind the platform is that the DHF should be a view into engineering activity, not a separate artefact. When engineers work in MANKAIND, every decision carries its regulatory context. User needs link to design inputs. Inputs link to outputs. Outputs link to verification. Verification links to validation. Every change propagates implications.

The DHF that comes out at submission time isn't written. It's rendered. The engineering record is the DHF — shown through a regulatory lens when that's what the audience needs. For teams working on complex or high-risk devices, the difference between a submission DHF that holds up under scrutiny and one that requires reconstruction isn't effort. It's architecture.

Frequently asked questions about the Design History File

What is a Design History File (DHF)?

A Design History File is the formal record that a medical device was developed under design controls. It contains contemporaneous evidence that every design decision from user needs through validation was intentional, traceable, and defensible — required by FDA under 21 CFR 820.30(j).

Is a Design History File required by FDA?

Yes. 21 CFR 820.30(j) requires every medical device manufacturer to establish and maintain a DHF for each type of device. The DHF must contain or reference the records necessary to demonstrate the design was developed in accordance with the approved design plan and the regulation.

What does a DHF contain under 21 CFR 820.30?

A DHF contains evidence of design and development planning, design inputs, design outputs, design reviews, design verification, design validation, design transfer, and design changes — each with the records and rationale required by the regulation.

When should the DHF be created?

The DHF should be maintained contemporaneously throughout development, not compiled at the end. FDA reviewers can distinguish between a DHF written as a coherent end-of-project narrative and one assembled from records created as decisions were made.

Is a DHF the same as a Device Master Record (DMR)?

No. The DHF captures how the device was designed and developed. The DMR (21 CFR 820.181) captures the specifications required to manufacture the device. The DHF is the history of design; the DMR is the recipe for production.