Compiling a Design History File (DHF) for a medical device product

For medical device developers assembling and presenting all the required documentation for the DHF (Design History File) in a systematic and auditable way is a key challenge in their NPI process. So, what’s in a DHF and how should you go about compiling it?

What is a Design History File (DHF)

The DHF is a formal document that must be prepared for each medical product, medical device or diagnostic that your business develops and manufactures. The DHF can be either a collection of physical or digital documents generated in a product development process - or an index of documents and their storage location. The DHF is referenced as a requirement for medical device developers in ISO 13485 section 7.3.10. and in the FDA 21 CFR Part 820.30

Defining the DHF requirement

The FDA defines the DHF as follows:

FDA 21 CFR Part 820.30

"Design history file. Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part."

While ISO 13485 outlines the requirement in this way:

ISO 7.3.10 Design and development files

The organization shall maintain a design and development file for each medical device type or medical device family. This file shall include or reference records generated to demonstrate conformity to the requirements for design and development and records for design and development changes.

DHF, DMR and DHR. Demystifying FDA medical device development requirements

Design controls are central to the Design History File

Elsewhere, the FDA and ISO state that the contents of the file must describe and record all the ‘design controls’ that you have undertaken as you have developed your product to ensure its conformity with the regulation.

The DHF should record the way you have controlled your design and development process

Design controls describe an iterative, phase gated design process. They ensure regular reviews of a project’s progress against inputs like user needs, technical specifications and regulatory standards. They provide for the verification of designs against captured design requirements, and the validation of the finished product against user needs.

What are the required contents of the DHF

• Detailed design and development plans that specify design tasks and deliverables for your device, showing their iterations and approvals over time
• Copies of approved design input documents and design output documentation
• Documents covering the design reviews you have undertaken
• Verification and validation documentation
• Copies of controlled design documents and change control rationale and records

Common challenges of DHF compilation:

Many startups and SMEs are so focused on the design and development of their product that they only start thinking about how to meet the DHF requirements at the end of the project. At that point, though, trying to retrospectively piece together the necessary documentation can be almost impossible.

Indeed, the FDA say that gaps and omissions in the record of the design control process (and by extension the DHF) is a common cause of organisations failing audits and delaying their own paths to market.

If you don’t use a single dedicated digital platform to create and manage all your documents throughout a medical product design and development process - there’s a high chance that you won’t have everything you need to produce the DHF at the end.

These are common problems faced by organisations trying to put together a Design History File:

1. Missing documents and records

Documents that have been misfiled or otherwise mislaid can present a huge challenge to medical device developers as they attempt to pull together a DHF. This can happen where filing structures have sprawled across multiple platforms over time, and naming conventions are not consistent or adhered to properly throughout a process.

2. Documents and records without auditable version histories

Being able to link to and see a final, approved and date stamped ‘issue’ of a document is key to delivering a DHF. Using a document management system that does not automatically discriminate between ‘drafts’ and ‘issues’ of quality documentation can lead to confusion and misunderstandings about the history of changes made to a file and what represents the final and complete version. Having to trawl through multiple, mislabelled iterations of documents to demonstrate the history of its evolution is a time consuming and error prone process.

3. Missing review and approval signatures on documents

In regulated industries being able to absolutely prove when and by whom documents have been signed off is a requirement. Printed out and signed off paper documents are the way some organisations record these final approvals, but paper has a habit of going missing and can be challenging to digitise and retrospectively incorporate into a digital document management system.

Choosing the right digital tools to meet the DHF challenge

A digital document management system (DMS) which allows you to map out and link to all the documentary requirements of each phase of a project within a single digital view is an excellent way to meet the requirements of the DHF.

Behind this digital view can be links to the documents themselves with a full, auditable history of each document.

These kind of DMS can help you define the necessary documents for an entire design and development process as templates that are then completed as you work through a required sequence of phase gates.

Why design controls matters in medical device development

They can help you set up automated work-flows for their completion and approval by required stakeholders. With the ability to date and time stamp approvals as well as collect digital signatures, the right DMS can help your DHF prove that each step of a med tech project has been delivered in a compliant way.

The DHF as an organisational tool

The Design History File, therefore, can become not just the repository for all your design and development documentation, but the organisational tool that helps you manage its assembly and keep required records of why, when and how design changes are made.

In fact, Design History Files should be ‘living documents’ in just this way. They are not a bunch of files to be archived and forgotten about until an auditor turns up. As your product goes into production and is then subject to CAPA requests and further updates - the processes by which the need for future changes are documented and then implemented should continue to be recorded within the DHF.

Conclusion

If you treat your Design History File as an integral part of your design and development process from the beginning, then these requirements will be easier to deliver at the end of the project and as the product changes and evolves. At the same time, your approach to implementing and documenting the proper design controls can simply become ‘the way you do things’. In this way a DHF can be much more than a static record of what has gone before, it can become an easily repeatable template for future success.

Blog post updated on 01/06/2022