Design History File Guide: Keep DHF Current as Design Changes

Every medical device engineering lead knows the specific panic of an upcoming notified body audit. Three weeks before the auditor arrives, development stops. Quality engineers pull CAD models, design review slides, and test reports from scattered drives to assemble a design history file that matches what the factory is actually building. Someone discovers that the injection molded chassis went through two wall thickness changes in SolidWorks that never made it into a design review note. Worse, the drop-test verification report was run on Rev B, but the production release is Rev D.

Reconstructing a design history file after months of engineering velocity is not compliance. It's an archaeological dig. It creates regulatory risk and burns hundreds of engineering hours on administrative backfilling.

This guide lays out a repeatable routine for keeping your design history file current as the hardware changes. If you manage design controls for medical devices or safety-critical hardware, you'll learn how to structure changes so your DHF stays audit-ready all the time.

Step 1: Know what the DHF holds under FDA design controls (21 CFR 820.30, QMSR and ISO 13485 7.3.10)

A design history file is not a generic project folder or a dump of CAD files. Historically, the FDA defined the DHF under 21 CFR 820.3(e) as a compilation of records that describes the design history of a finished device, while section 820.30(j) required maintaining the file and detailed its contents. With the FDA's final Quality Management System Regulation, the agency aligned its requirements directly with ISO 13485:2016.

Under ISO 13485 clause 7.3.10, the requirement is formally called the design and development file. The regulation says an organization must maintain records that demonstrate conformity to the requirements of design and development planning, inputs, outputs, review, verification, validation, design transfer, and design changes. Whether an auditor asks for a DHF under legacy 21 CFR 820 terminology or a design and development file under ISO 13485, the expectation is the same: prove that the device was developed following an approved plan and that every design output satisfies the original design inputs.

The DHF must contain seven specific record classes:

• Your design and development plan.

• Documented user needs and product requirements (inputs).

• Engineering drawings, specifications, and source code (outputs).

• Dated and authorized design review records.

• Design verification protocols and signed reports.

• Design validation evidence proving user needs are met.

• Documented design changes that explain why modifications occurred.

The standard requires that you show how the work progressed, not just where it ended up.

Step 2: Separate the DHF from the DMR, DHR and the ISO 13485 medical device file

Engineering teams often mix up four separate regulatory files. Mixing them up leads to bloated binders and messy audits. Each file answers a distinct question about your hardware.

The design history file (DHF) documents how you developed the product. It captures the history: inputs, outputs, verification protocols, design reviews, and engineering trade studies that justify how the product reached its final state. The device master record (DMR), defined under 21 CFR 820.3(j) with contents detailed in 21 CFR 820.181, functions as the manufacturing recipe for the device, alongside the related Medical Device File established under ISO 13485 clause 4.2.3. The DMR contains released production drawings, bills of materials, assembly instructions, software binaries, packaging specifications, and inspection criteria. If the DHF is the story of how the recipe was written and tested, the DMR is the finished cookbook.

The device history record (DHR) documents what you actually manufactured. Every production lot, traveler, calibration certificate, serial number, and test sign-off belongs to the DHR. The DHR proves that production followed the DMR recipe.

Keep these separations clear in your team's daily workflow. When a mechanical engineer updates a fillet radius to relieve stress, the updated drawing lands in the DMR once released. The rationale for the change, the CAD stress analysis, the review approval, and the updated verification protocol belong in the DHF. Don't let your DHF turn into an uncurated archive of manufacturing lot sheets or purchase orders.

Step 3: Find where your DHF drifts (unlinked CAD changes, detached review minutes, stale verification evidence)

DHF drift happens because engineering moves faster than quality record-keeping. The drift concentrates around three specific fault lines.

The first fault line is unlinked CAD modifications. An engineer changes a wall thickness or rib feature in SolidWorks or Onshape to fix a tooling issue the supplier found. The CAD part changes, the STEP file exports, but no requirement or design input links to that revision. The CAD history captures the geometry changes and none of the regulatory reasoning. For more on this gap, see our guide on cad revision history best practices.

The second fault line is detached review minutes. Critical design decisions happen in cross-functional meetings, Slack channels, or email threads. Someone agrees to lower an operating temperature threshold from 55C to 45C. The change is modeled in CAD, but the formal design review records contain only generic slide decks. An auditor reading the DHF six months later sees a requirement revision with no record of the review meeting, the attendee approvals, or the technical alternatives considered.

The third fault line is stale verification evidence. When a printed circuit board moves a power rail from Rev C to Rev D to reduce ripple, testing must confirm that safety requirements still hold. Instead, the team points to a verification report completed against Rev B. During an audit, the notified body compares the test report serial/revision block against the production DMR bill of materials. The mismatch triggers an immediate nonconformance. Teams often maintain a verification cross reference matrix to avoid this, but it fails quickly when it's disconnected from live mechanical CAD and electrical revisions.

Step 4: Link each design change to the design input it affects

Every physical change to your hardware must anchor to a requirement. Under ISO 13485 clause 7.3.9, you must evaluate the impact of design and development changes on parts in progress, delivered products, and risk management inputs. You can't evaluate impact if your requirements live in a static Excel matrix while your parts live in a CAD repository.

Set a rule: no CAD model or drawing revision gets approved for release without an explicit parent link to a system requirement, component constraint, or risk mitigation. When an engineer adjusts a latch engagement depth, they must identify whether that change alters the enclosure retention input (REQ-042) or a user ease-of-use input (REQ-118).

If the change affects an existing requirement, update the input through a formal change workflow. If the change introduces a new constraint, add the child requirement to the architecture hierarchy before checking in the part.

This is where purpose-built tooling matters. Tandem is an AI-native hardware development platform that connects design intent, requirements, CAD changes, and validation evidence in a single system. When a geometry change occurs, they see which requirements it touches right away, so requirements drift can't go unnoticed.

Step 5: Hold design reviews in context of the change being reviewed

Design reviews under 21 CFR 820.30(e) and ISO 13485 clause 7.3.5 require systematic evaluations at planned stages, with participants including representatives of all functions concerned with the stage being reviewed. Standard engineering practice often reduces this to quarterly milestone presentations where 80 slides are shown and signed off without granular traceability.

Slide-based reviews fail audits because they detach the approval from the underlying design data. When an auditor asks to see the design review for a specific ECO on the fluid delivery manifold, a 90-page slide deck from a high-level gate review won't convince anyone.

Shift to in-context design reviews. Scope each review directly to the change: the affected requirement, the specific CAD revision, the risk management update (such as your DFMEA), and the verification plan. Review records must document the specific revision reviewed, the technical objections raised, the action items assigned, and dated approvals from cross-functional owners (systems, mechanical, electrical, quality, and manufacturing).

In Tandem, teams run design reviews directly against the requirement, architecture node, CAD change, and verification evidence they relate to. Reviewers comment on the technical context instead of assembling presentation decks. The approval history attaches permanently to the design entity, which gives you an immutable, auditable record for the DHF without manual slide exports.

Step 6: Tie verification evidence to the revision it tested

Verification proves that design outputs meet design inputs. Under FDA design controls, a test report that doesn't record the exact configuration of the test unit is functionally useless. In an audit, unanchored test reports can trigger regulatory inspection findings regarding design verification documentation.

Enforce an explicit configuration rule for verification protocols: every test record must document the part number, revision level, and serial number of all assemblies involved in the test. If an engineer tests an enclosure for IP54 ingress protection, the protocol can't simply say it tested 'the prototype enclosure.' It must say: 'Chassis Base PN 10042 Rev C, Chassis Cover PN 10043 Rev B, Silicone Gasket PN 10088 Rev A.'

When a later CAD change moves the gasket compression groove to Rev C, flag the ingress protection requirement as unverified. The team must either perform a documented engineering analysis explaining why the change doesn't invalidate Rev B testing, or schedule a re-test against the new baseline. On complex programs, holding this discipline takes structured configuration baseline tracking so that changes automatically surface downstream verification gaps.

Tandem tracks the complete hardware development path from early definition through design, review, validation, and release. It stores validation evidence in the same system as requirements and CAD changes, so you know whether a requirement's verification evidence was generated against the active revision or an obsolete prototype.

What Tandem does not do

Tandem is the context layer for hardware engineering, but it doesn't cover every engineering and manufacturing process. Being precise about what the tool does and doesn't do protects your process integrity.

Tandem is not a CAD tool and not a PLM or PDM replacement. It sits as a context layer above them, storing design intent, requirements, review history, and evidence rather than raw geometry or file check-ins. Tandem does not provide automated 2D drawing generation, drawing diffing, or design for manufacturability (DFM) feedback. It does not author or generate Engineering Change Orders (ECOs).

Tandem does not run engineering calculations, generative CAD, or physical test executions. It stores and connects validation evidence rather than managing test laboratory equipment or executing test cases. It also isn't an electronic Quality Management System (QMS), enterprise resource planning (ERP) system, or supplier management tool. What it does provide is the connective tissue between requirements, CAD changes, and evidence, so engineers and quality teams avoid traceability gaps.

What to do next: a recurring DHF currency check before audits and milestones

Don't wait for a phase-gate review or a notified body audit notice to assess your DHF. Run a bi-weekly DHF currency check, led by the systems lead and the quality engineer.

Use this four-point checklist on every active hardware subsystem:

First, inspect the CAD check-in log. Identify every part or assembly that moved a revision level over the last two weeks. Verify that each revision links to a corresponding requirement or change ticket.

Second, inspect the requirement hierarchy. Verify that every modified requirement shows an updated status and that no child requirements are orphaned.

Third, review action items from recent design reviews. Confirm that every assigned closure action has a documented resolution and approval record in the review thread.

Fourth, run a verification gap check. For every modified component, check whether the associated test reports match the current revision level. If a test report points to an earlier revision, make sure an engineering justification memo or re-test plan is logged.

This check takes 30 minutes every other week. It ends the three-week reconstruction scramble before regulatory submissions.

Conclusion

A compliant design history file isn't something you assemble after the hardware is built. It's the real-time record of your engineering logic. When your CAD changes, design reviews, and test evidence sit disconnected across spreadsheets, slide decks, and PDM vaults, DHF drift is inevitable. Enforce direct links between CAD geometry, requirements, and test configurations, and you preserve design intent while moving at modern hardware speed.

If your hardware engineering team wants continuous DHF traceability without the manual administrative overhead, book a demo with Tandem to see how the platform links your CAD models, requirements, and validation evidence.