Design history file: assembled during the project, not after it

A design history file is the compilation of records showing how a medical device was designed: the plan that was followed, the inputs that defined what it had to do, the outputs that resulted, the reviews, the verification and validation, and the changes made along the way. Its purpose is to demonstrate that the design was developed in accordance with the plan and the applicable requirements.

The word compilation matters. A DHF is not written; it is assembled from records that were created as the work happened. Teams that plan to produce it at the end find that the evidence does not exist — reviews held without minutes, requirements changed without a trace, tests run before the protocol was approved. Those gaps cannot be closed retrospectively without creating records after the fact, which is a considerably worse position.

What a design history file has to show

• The design and development plan, and evidence it was followed or amended deliberately.
• Design inputs: requirements, intended use, user needs, applicable standards — with the review that found them adequate and unambiguous.
• Design outputs: specifications, drawings, software, labelling — traceable to the inputs they satisfy.
• Design reviews, with the participants, findings and their resolution.
• Verification, showing the outputs meet the inputs; and validation, showing the device meets user needs in the intended use environment.
• Design transfer to production.
• Design changes, each with its review, verification and approval.
• Traceability that lets a reader follow a user need through to the test that demonstrates it was met.

Traceability is the part that decides how the audit goes

The single question an auditor returns to is whether each requirement can be followed through to an output and to the evidence it works. A file of individually excellent documents with no traceability leaves the auditor building the matrix themselves, in your office, out loud. Maintaining that matrix as the project runs costs a fraction of reconstructing it, and it is also the artefact that tells the team what breaks when a requirement changes.

The regulatory framework here is in transition, with the United States requirements being aligned to the international quality management standard and the terminology changing accordingly. What a file must be called and exactly how it is structured should be checked against the current rule rather than against older guidance — including this post.

Where files usually thin out

Three places, consistently. Validation evidence, where usability and the intended-use environment are treated as an afterthought. Design changes late in the project, made under schedule pressure with the review documented afterwards if at all. And software, where the development records live in engineering tools and were never connected to the design file at all. All three are visible to an experienced reviewer within an hour.

Keeping the compilation

Ettex Records holds the index of the file — what exists, where it is, and its status — with the review dates visible, and Ettex Docs keeps the plans, reports and reviews with version history so what was approved when is recoverable. The manufacturing counterpart is covered in device master record.

To be explicit: this is documents and records, not a regulated quality management system, and none of it is regulatory advice. Medical device manufacturers need a QMS meeting the applicable requirements, with validated software where required; what this covers is the discipline of assembling as you go.