How to Prepare Your Design History File For An FDA Inspection

By Jon Speer, founder & VP of QA/RA, greenlight.guru

For some medical device companies, an FDA visit can be scary and stress-inducing — if you don’t have your ducks in a row.

One of the most common causes of apprehension among developers is preparing a design history file (DHF) that withstands FDA scrutiny, but it doesn’t have to be that way. You can go confidently into an FDA inspection if you’ve followed some best practices and avoided a few common mistakes.

According to the FDA, “the design history file 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 (21 CFR Part 820.30). Each manufacturer shall establish and maintain a DHF for each type of device.”

Here are a few common mistakes to avoid as you fine-tune your DHF:

The Unruly File

First of all, congrats for having a DHF in the first place. Many companies seem to delay getting one together at all, but having a disorganized file can only create more stress. If contents are dumped into a folder without any organization, the company will have a hard time finding information, which might lead the FDA to assume something is missing.

Paper Problems

Believe it or not, the most common format for a DHF is still paper. You might have a piece of paper in your desk drawer, some papers in binders, some on top of file cabinets, and even folders on other people’s hard drives. But, when you’re in a rush to find the contents of your DHF, the last thing you want to do is go on a treasure hunt.

A related mistake here is missing or incomplete paperwork. If DHF documents are strewn all over the, how do you know whether everything is there? Additionally, we often come across missing signatures or vital sections left incomplete. Your DHF should always be accurate and updated.

The Overcompensating DHF

Another common mistake is when companies — under the premise of safety — add everything they possibly can to the DHF. Really, they’re just creating extra work for themselves. Your DHF should be a collection of the objective evidence that demonstrates you’re following 820.30. (Note: the term “DHF” is not used in ISO 13485:2016, but the document defines “Design and Development” files, and the terms are synonymous, for all intents and purposes.)

Companies often throw in more business-related items, such as cost studies or competitor analyses, but these are not necessary: they don’t relate to safety and efficacy, or meet the needs of the end user. A DHF should fit within a project file and focus on design control activities.

No Traceability Matrices

Traceability matrices for your design controls are one of the key things to prepare before an inspection. These matrices represent a roadmap to what’s in your DHF and show the relationship from design control activities. The FDA inspector will appreciate the understanding of how everything works, but traceability matrices also are an important internal tool to keep team members on the same page.

Constructing A Traceability Matrix Late In Development

I’ve seen some companies wait until the last minute, and then frantically try to construct a traceability matrix immediately prior to an FDA inspection. What are you going to do if you identify gaps that will hold up your launch?

Early in my career, I made this mistake as an engineer. I put together traceability at the end, and identified that the company had missed a specific biocompatibility test that developers knew would be a requirement. I had to tell executives that the 510(k) would be delayed several weeks, and that they needed another $15,000 to conduct the test.

The advantage of creating traceability at the beginning is visibility over what needs to happen and be addressed. In the example above, forethought would have prevented the delay before regulatory submission.

Best Practices

As a rule of thumb, your DHF must be accurate and should be a “living” document, meaning it should be consistently updated even beyond the development phase. When you archive your DHF after manufacturing, it defeats the purpose. It should always be an accurate representation of the product you are delivering.

The FDA expects all changes to be assessed from a design control perspective. You must verify and validate any changes before implementing in production. Design control records must support that and, if you don’t keep up, those records will end up very fragmented.

Remember this; if you have a 510(k)-cleared device, you absolutely will be inspected by the FDA. You should expect that your design controls and DHF will be part of the inspection. Don’t  wait until the FDA calls and says they’ll be on-site in the next few days to revisit and fix delayed design controls or an incomplete DHF — by then, it’s too late.

Final Thoughts

Successful companies keep their documents up-to-date through the entire development process, even on transfer to manufacturing. The DHF contains objective evidence of safety and efficacy — if there is no file, or a file exists but is disorganized, it didn’t happen, and you can’t show documented evidence to FDA. Such sloppiness could earn your company 483 observations, or an order not to sell the product until your DHF is fixed.

In short, keep your DHF updated from the beginning of the project if you want a better chance of getting through your inspection unscathed!

About The Author

Jon Speer is the founder and VP of QA/RA at greenlight.guru, a software company that produces quality management software exclusively for medical device companies. Jon is a medical device industry veteran with over 18 years of experience, having helped dozens of devices get to market over his career in a variety of roles, including product development, project management, quality, and regulatory. He also is a thought leader, speaker, and regular contributor at numerous leading industry publications.