So, the FDA is coming to inspect your medical device company.If you’re confident that you have everything together, you’re possibly feeling pretty easy about the whole thing and looking forward to having a couple of quiet celebratory drinks afterwards. If you’re not prepared, you’re possibly feeling a little stressed (and perhaps having that drink now instead).
One of the common causes of angst among medical device developers is preparing their design history file (DHF) so that it is up to scratch for the scrutiny of the FDA.
It doesn’t have to be that way. You can go confidently into your FDA inspection if you’ve followed some best practices and avoided a few common pitfalls:
Common Pitfalls
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.”
If you’re due for an inspection, the FDA will want to examine your DHF, so it’s important that you’re ready. Here are a few of the common pitfalls we strike:
Paper, paper, paper…
Believe it or not, the most common format for a DHF is still on paper. The problems occur when you have a piece of paper in your desk drawer, some in binders, some on top of file cabinets and even folders on people’s hard drives.
Who knows where the contents of your DHF are, let alone any kind of coherent organization? A related mistake here is missing or incomplete paperwork. If you have stuff all over the place for your DHF, how do you know everything is there?
As for the papers found inside the binders, we often come across missing signatures and other incomplete, vital sections. This says that your DHF is not kept up-to-date and you’re probably missing the point of it.
Your DHF should always be accurate and kept updated. Remember, it’s there to help you prove the safety and efficacy of your device.
Post-it notes everywhere
This is another common mistake - we see post-it notes scattered throughout the file, usually to make note of things that the person intends to go back and update in the DHF. The problem is that this often doesn’t happen.
We find that the DHF wasn’t really kept current and that no one went back and scrubbed it before product launch.
It’s worth noting here, this is one of the reasons we came up with Greenlight Guru. Why aren’t those paper-based files kept up to date? Because they’re kind of cumbersome and time-consuming to get through. It’s often unintentional too - the person thought they would go back and update the file at the time they made the note, but in the busy environment of the company, that just never happened.
Greenlight Guru makes creating and updating a DHF easy as it is all within the centralized software system. There’s no need for a post-it when you can just add an appropriate note immediately.
The over-stuffed DHF
This is another common mistake. The company thinks they’re erring on the “safe” side by adding everything possible to the DHF, but all they’re really doing is creating an extra load for themselves.
Your DHF should be a collection of the objective evidence that demonstrates you’re following 820.30. (Note here: the term DHF is not used in ISO 13485:2016, but they define Design and Development files, which is 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, efficacy or meeting the needs of the end user. A DHF should fit within a project file and focus on design control activities.
The disorganized file
Kudos for having a DHF in the first place as many companies seem to delay getting one together, but having a disorganized file will only create more hassles for you.
We often find that contents are dumped into the folder without any structure or organization. If it’s hard to follow, the company will have a hard time finding information. (Or the FDA will, then you might find that they perhaps think something is missing).
Not putting together traceability matrices
Traceability matrices for your design controls are one of the key things to have prepared before an FDA inspection.
Greenlight Guru Multi-level Design Control Traceability Matrix
This is essentially the roadmap to what’s in your DHF and shows the relationship/flow-down from design control activities. The FDA inspector will appreciate the understanding of how everything works, but it’s also good to have for internal use so that your key team members are all on the same page.
Trying to construct a traceability matrix late in the process
It’s a mistake to put off creating your traceability matrix until near the end of development. We’ve even seen some people frantically trying to construct one immediately prior to an FDA inspection. The problem is that you might then identify gaps that will hold up your launch.
Early on in my career, I made a mistake like this as an engineer. I put together traceability at the end and identified that they’d missed a specific biocompatibility test that he knew would be an absolute requirement. I had to tell his boss the 510(k) would be delayed several weeks and that they needed another $15k to conduct the test. Not too many would be impressed by the delay!
The advantage to creating traceability at the beginning is visibility over what needs to happen and be addressed. This would have saved the delay before regulatory submission. For me, this was part of his inspiration for Greenlight Guru. I wanted a system that makes it easy to keep traceability updated as you go.
Keeping traceability up-to-date can otherwise take several hundred hours out of your year. Companies often use Excel or similar tools and they’re just not efficient. Think about the time spent adding rows, cells, or columns, for example. Many companies we’ve spoken to have saved hundreds of hours by using Greenlight Guru throughout their project.
Best practices
One of our top best practices is that your design history file must be accurate and should be a “living” document. This means keeping it updated beyond the development phase too. When you archive your DHF after manufacturing, it defeats the purpose. It should always be an accurate representation of the product you are delivering.
This means you should assess it for any changes and keep it up to date. Sometimes downstream, the DHF doesn’t represent the product you have on the market, which is not a good situation for the sake of transparency.
If you’re lined up for an inspection, you could get into trouble with FDA if it’s not updated. They expect 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, it will end up very fragmented.
Remember this; if you have a 510(k) cleared device, you absolutely will be inspected by FDA. You should expect that your design controls and DHF will be part of the inspection. The problem is not coming back and fixing the delayed design controls or DHF until the FDA calls and says they’ll be onsite in the next few days. It’s too late to organize then.
Final Thoughts
Successful companies keep their documents up to date and current through the entire process. Even on transfer to manufacturing, they keep the DHF updated. The DHF contains objective evidence of safety and efficacy - if there is no file or if it exists but is disorganized, it didn’t happen. You can’t show proof or documented evidence to FDA.
You could get 483 observations or be told you can’t sell the product until your DHF is fixed. Poor documentation is always at the top of the list of issues for warning letters and 483s.
In short, keep your DHF updated from the beginning of the project if you want a better chance of getting through your inspection unscathed!
BONUS CHECKLIST:
Key Elements to Include in Your Design History File
Key Elements to Include in Your Design History File
