How to Prepare your Design History File (DHF) for an FDA Inspection

Note: The views expressed in this article are those of the author and do not necessarily represent those of his or her employer, GxP Lifeline, its editor or MasterControl Inc.

FDA inspections strike fear into most companies, but most of the fear is due to a lack of knowledge about what to expect from the FDA. Therefore, the person responsible for the design control process at your company should read two important documents—in addition to this article:

  1. The Quality System Regulation (QSR) Preamble ( – specifically pages 52615-52622 (8 pages)
  2. The Quality System Inspection Technique (QSIT) Manual ( – specifically pages 32-45 (14 pages)

White Paper

This article is related to the White Paper:
Reducing the Documentation Burden in FDA Design Control Process.
To get the full details, please download your free white paper.

The Preamble

The Preamble is important, because it explains the intent of the QSR (21 CFR 820). Design controls were first introduced by the FDA in 1996 by releasing two documents: 1) “Medical Device Design Control Guidance” and 2) “Do It By Design.” These are basic guidance documents that explain best practices in the areas of design controls and the application of human factors to the design of medical devices. The QSR preamble, however, is the official interpretation of the law—not guidance.

To quantify the difference between the QSR and the preamble, there are 67 instances of the word “design” in the QSR and there are 524 instances of the word “design” in the preamble. This reflects the significance of design controls and indirectly shows you that industry had a lot of questions about how the FDA would interpret section 820.30. Therefore, anyone responsible for design controls should read the industry questions and responses by the FDA summarized in the Preamble.

The QSIT Manual

The QSIT Manual is the official work instruction for FDA inspectors conducting a “Level 2” or comprehensive inspection of medical device companies. There are four major subsystems identified in this manual and three minor subsystems. An FDA inspector will review each of these seven subsystems for compliance against the QSR. One of the four major subsystems is design controls.

The design controls section of the QSIT Manual identifies 15 steps for the verification of compliance with design control requirements in 21 CFR 820. When your company is conducting an internal audit, it is advisable to instruct the auditor assigned to design controls to make sure that they consider each of these 15 steps when they conduct internal audits.

Documents to have ready

When the FDA performs an inspection of the design control process, the inspector will select a single Design History File (DHF) to sample and request a copy of your Design Controls procedure. If you have any concerns about your current Design Controls procedure, you should perform a gap analysis against the QSR requirements in section 820.30. You might also consider reviewing one of my blogs on writing design control SOPs (

What happens If the design control procedure changes?

It is normal for a company to change the design control procedure in the middle of a design project, because projects take months or years. Therefore, it is important to define how any work in progress will be treated when the design control procedure changes. This is no different from defining how open work orders will be treated when a drawing changes. My recommendation is to implement the change to the revised procedure after then next design review. This will help to identify a clear break between the two versions of the procedure. It is also typical to update the design plan at each design review, and the design plan is an ideal record in which you should reference the current version of the design control procedure.

How do you define your DHF?

Section 820.3(e) in the QSR defines Design History File (DHF) as “a compilation of records which describes the design history of a finished device.” This definition is vague and therefore creates an opportunity for compliance issues. To avoid this, you should focus on two aspects of the definition. First, you should define which records comprise the DHF. The list below is what your FDA inspector will be looking for:

  1. Design plan
  2. User needs
  3. Design inputs
  4. Design outputs
  5. Risk analysis, including hazard identification
  6. Human factors analysis
  7. Design verification, with acceptance criteria
  8. Design validation, with acceptance criteria
  9. Design changes
  10. Software validation—if applicable
  11. Design reviews
  12. Design transfer

The best practice for ensuring that these documents are created is to create forms to document each design review. You may create a different form for each phase of design or you may have a generic design review form that can be used for all phases. Regardless of which approach you use, you should make it clear which of the above documents are required as a deliverable at each design review. It is also recommended to define who are required attendees and approvers of the design review. There may be several people in attendance at the design review that are optional, but the minimum requirements for attendance should be clear. When you define these minimum requirements, you should also use job functions—not titles or names. In the course of an 18-month design project titles and names will change, but the essential functions should always be included in the team.

Figure 1

The second aspect of your DHF documentation to focus on is when the DHF begins and ends. If you initiated a DHF later in the design process than your procedure specifies, then you should summarize some of the design activities that already took place retroactively. This is not uncommon but inspectors want to see that the documents required in your procedure are included in the DHF. In Figure 1, I have indicated the typical times for initiation and closure of a DHF on a two-hump diagram (R = research, and D = Development).


Best practices for “closure” of a DHF is to close it when you receive your 510(k) clearance letter or PMA approval from the FDA. You should not keep your DHF open for the life of the product. The last three steps of your design transfer process should be as follows:

  1. Initiate a Device Master Record (DMR); a DMR Index is best practice and may serve as a Technical File Index as well.
  2. Initiate a Post-Market Surveillance (PMS) Plan for the new product or update an existing PMS plan for a product family; this should include an updated risk management plan.
  3. Add the 510(k) letter or PMA approval to the DHF.

Tracking of design changes in the DHF

Tracking design changes is a common weakness in most companies—regardless of the stage of the design process. One of the key reasons for closing the DHF after transfer has occurred is to facilitate tracking of changes. The DMR Index is first created when the DHF is closed. At this stage the revision of the DMR is revision “A” or “1”—depending upon your revision system. If the DMR is an index, then you will have a couple of pages of index followed (or preceded) by the revision history. Every time a design change is made, one of the documents in the DMR will need to be revised. Therefore, the revision history of the DMR Index will identify each change. If your system is paper-based, the length of the revision history will quickly become longer than the DMR Index. However, if you are using MasterControl to manage your DMR then the length of the revision history is irrelevant.

During the design process, most design teams make minor changes throughout the development process prior to verification activities. However, many of these minor changes fail to be captured in the DHF because the documents are not yet under document control. Typically the only changes I see captured during the development process are those changes made to drawings at the later stages of development—often after verification activities are well under way.

Not every change is worthy of documenting in your DHF. I recommend the following criteria for deciding if a change should be documented in the DHF:

  1. Did the design plan change?
  2. Did a design input change?
  3. Did a design output change?
  4. Was the risk analysis affected?

You cannot have a change that affects verification or validation activities that doesn’t meet at least one of these four criteria. If any of these criteria are met, the change is significant enough that I recommend documenting it in the DHF. If all four documents are under engineering revision control during the design process, then you can document the change by changing the engineering revision.

Note: “Engineering revisions” typically only require review and approval by a couple of design team members—rather than the full review and approval associated with production revision control.

Which DHF will be selected?

Your FDA inspector could select the DHF for any Class II product that your company legally manufactures. However, the FDA inspector is unlikely to pick a DHF that was sampled during your previous audit. This is why I recommend maintaining a “copy pile” containing copies of all the documents requested by the FDA during an inspection. This pile of copies can be used to create a summary of FDA inspection—which should always include a list of all documents and records that were requested.

If you eliminate the previously reviewed DHF from the list of potential files to sample, the most likely criteria for sampling from the remaining files are:

  1. Which product had a recall since the last FDA inspection?
  2. Which product resulted in the most adverse events reported since the last FDA inspection?
  3. Which product received a 510(k) since the last FDA inspection?

An FDA inspector is extremely unlikely to select a file that is not completed, because these products have not been registered or listed yet. None of the three criteria listed above would apply either. Therefore, you should focus on files that are completed instead of new products that are still being developed.

Robert Packard is a regulatory consultant with 20 years experience in the medical device, pharmaceutical and biotechnology industries. He is a graduate of UConn in Chemical Engineering. Robert was a senior manager at several medical device companies—including President/CEO of a laparoscopic imaging company. His quality management system expertise covers all aspects of developing, training, implementing, and maintaining ISO 13485 and ISO 14971 certification. From 2009-2012, he was a Lead Auditor and instructor for one of the largest Notified Bodies. Robert’s specialty is regulatory submissions for high-risk medical devices, such as implants and drug/device combination products for CE marking applications, Canadian medical device applications and 510(k) submissions. The most favorite part of his job is training others. Please visit his website,, if you are interested in reading his blogs or registering for a training event. You can also email him directly at: