Of course, this is somewhat of a loaded question. There are lots of different scenarios and situations to consider regarding medical device design controls compliance. Let’s start with a brief overview:
- FDA Design Controls are addressed in 21 CFR 820.30. ISO 13485 covers medical device design and development in section 7.3. Fortunately, both FDA and ISO are VERY similar with respect to medical device product development expectations.
- DHF is the FDA abbreviation for a Design History File.
- ISO 13485 and EU Medical Device Directive (MDD) do not use the term DHF per se. Rather, design and development documentation and records must be maintained.
- DHF is not a regulatory submission. A DHF is a compilation of Design Control records.
- It is possible to establish a medical device product development process that complies with FDA Design Controls and ISO 13485 Design & Development.
Okay, any one of the bullet points above could be expanded and the subject of an entire blog post or two. For now, let’s just agree to use the term DHF to describe a repository of medical device product development records.
Simply put, if you DHF needs work, you must fix it. It’s important, though, to take into consideration where the product is in its lifecycle, in my opinion. Here are some “rules” I would suggest:
- First, analyze your medical device product development procedures, processes, work instructions, forms, etc. Do these comply with FDA and ISO? If not, fix them first.
- If your product is still in development and has not been transferred to production, then fix the DHF now. Don’t wait until after the product is launched, suggesting you will do it later. If you don’t fix it now, you probably won’t do it later until required because of a FDA inspection or ISO audit.
- If your product is in production, assess the DHF gaps and issues. Analyze the risks associated with the gaps from both a business and regulatory compliance perspective. Document the gap analysis results. Document the risk-based decisions. Identify an action plan (and maybe even open a CAPA) to address the issues.
In my opinion, plugging the gaps in a DHF after the fact can sometimes be challenging. For example, if a DHF is missing a Design & Development Plan and the product is already in the marketplace, then there’s not much that can be done to fix this. But you should definitely document your finding in a memo, audit report, etc. And you might consider opening a CAPA to ensure it doesn’t happen again.
But there are some contents of a DHF that you should mitigate if found missing. For example:
- If you failed to adequatley demonstrate the design outputs meet the design inputs, identify what additional design verification activities are required.
- If you failed to adequately demonstrate the product meets the user needs, identify how you can address design validation through end-user experience. Of course it is important to realize that these activities are retrospective. While this is NOT a best practice, identifying and mitigating short-comings is still a recommended practice.
- If you did not document risk management activities per ISO 14971, then you should create these records (again, make sure you have also reviewed risk management procedures).
I cannot stress enough the importance of documenting your rational throughout this process. While you may not always make the right decisions in the eyes of regulators regarding missing DHF contents, ignoring it altogether is a BAD thing. Fall on your sword and assess the short-comings using risk-based approaches.