A defensible DHF is a connected evidence trail, not a shelf of final documents

The last DHF traceability gap I had to close did not involve a missing document.

It involved four documents, all of which existed.

A drawing had been revised following a design change. The change-control record said the revision was “minor” and had “no impact on risk”. The risk-management file still referenced the previous revision, while a supplier concession contained the only explanation of why the change had been introduced. The verification report had the right title, but no link to either the drawing revision or the risk file.

Individually, each record looked acceptable. Together, they proved nothing.

That is the practical difference between a complete DHF and a defensible one. Completeness asks whether the expected documents are present. Defensibility asks whether an auditor can reconstruct what was known, what was decided, who approved it, and how the decision was implemented.

The MDR does not prescribe a folder literally called a “DHF”, but it expects the technical documentation to demonstrate design, risk and verification traceability under Annex II sections 3 and 4. ISO 13485:2016 is more explicit: clause 4.2.3 requires a design history file for each device type or family, while clause 7.3.9 requires design changes to be reviewed, verified and validated, as appropriate, with the results recorded.

In practice, this means a DHF is not a collection of final artefacts. It is an evidence chain.

Start with the quality event, not the document

Teams often begin a DHF project by creating an index and collecting controlled documents. That is backwards for a change, complaint, non-conformance or audit finding. The event is what makes the workflow necessary.

For each quality event, capture the basic facts first:

• the object of the event;
• affected device configuration and revision;
• affected lot, batch or serial range, where relevant;
• the risk potentially affected;
• the procedure determining scope;
• the owner and required review roles.

Only then should the record generate linked activities such as impact assessment, risk review, verification, corrective action or document revision.

This matters because quality events have different origins but need the same underlying discipline. A design change may affect a drawing, supplier instruction and risk control. A complaint may affect the same records from the opposite direction. A supplier non-conformance may affect only a subset of the released configuration.

The connected workflow should make those routes explicit rather than leaving each specialist to reconstruct the chain independently.

Walk one design change end to end

I use a simple test when reviewing a design change: can I move from the change record to the released device and back again without relying on someone’s memory?

For the handle-geometry change I mentioned earlier, the defensible chain looked like this.

The design input identified the requirement: the instrument must remain controllable during use. The risk file linked that requirement to foreseeable hazards such as slipping, excessive force or user error. The drawing revision showed how the design satisfied the input. The verification protocol defined how that would be tested. The results demonstrated acceptance against predefined criteria.

The risk-management file then recorded whether the existing controls remained valid and whether any new verification was required. Finally, the release record identified exactly which drawing, bill of materials, work instruction and IFU became effective.

The important point is bidirectionality. The change record points to the risk review. The risk review points back to the change and its verification evidence. The released configuration points back through the approval history to the approved revision.

A single link from a change log to a PDF is not enough.

Review risk impact explicitly

“Risk impact: none” should not be an unexplained conclusion.

Under ISO 14971:2019, the review needs to consider whether the change:

• introduces a new hazard or sequence of events;
• changes the severity or probability of an existing hazard;
• invalidates an existing risk control;
• changes a design input or essential performance;
• affects production, packaging, servicing or disposal.

The output is not simply a tick-box. It is a traceable rationale identifying the hazards considered, the controls affected and the evidence used to conclude whether further action was necessary.

For software changes, the same principle applies, with the applicable software-development evidence added under IEC 62304 where relevant.

Preserve the reasoning, not just the result

The audit trail should retain superseded revisions, review comments, approvals and the reason for changes. A corrected document can hide the original error, but it cannot preserve the investigation that led to the correction.

At minimum, each controlled record should make the following recoverable:

• who prepared, reviewed and approved it;
• when each action occurred;
• which revision or version was considered;
• what evidence was attached;
• what subsequent event required the change;
• whether the change affected released devices.

If these facts exist only in someone’s inbox, they are not part of the audit trail.

Close the loop with post-market quality events

A DHF also has to work backwards from post-market information.

Consider a complaint involving an instrument that loosened during use. The defensible path runs from the complaint to the device configuration, manufacturing or supplier records, risk controls, maintenance instructions, previous complaints and related CAPAs.

The critical document is often the CAPA. I have seen CAPAs close with a reference to an “updated instruction” but no document number or revision. That is not a closed link. It makes the effectiveness check impossible to audit and leaves the DHF unable to demonstrate that the identified cause was actually addressed.

An effective CAPA should connect:

• the originating quality event;
• investigation and root-cause evidence;
• affected products and processes;
• risk-management assessment;
• corrective actions and controlled records;
• effectiveness criteria and results;
• any Design History File or technical-documentation updates.

The work is repetitive by design. If a complaint cannot reach the released configuration and its risk controls, the DHF is not doing its job.

Use a five-minute traceability test

Before release, I check whether a reviewer can answer five linked questions:

1. What requirement did the design need to satisfy?
2. Which hazard or risk does that requirement address?
3. Which control or verification demonstrates compliance?
4. Which released revision and process implemented it?
5. Which quality event would trigger re-evaluation if it failed?

These links should exist for a design change, complaint, non-conformance and audit finding. Not every event needs the same depth of investigation, but each needs an evidence-based scope decision.

For a visual walkthrough of linked design changes, risks and quality events, this is worth a watch: A practical DHF traceability walkthrough.

Keep the workflow controlled, not merely connected

Automated link suggestions or impact-mapping assistance can reduce clerical effort, but they do not determine regulatory significance. The reviewer still needs to approve the scope, document the rationale and remain accountable for the conclusion.

That is the part I wish more systems understood: traceability is not the number of links present. It is the ability to follow a defensible line from a quality event to a controlled decision and its implementation.

Where does traceability most often break in your design-change process: risk assessment, verification, document release or post-market feedback?