how_to_retroactively_create_design_controls_dhf.png

So, you haven’t completed your design controls or design history file (DHF)...

Hopefully you’re not sitting here asking, what are those? Especially if you’ve already gone through 510(k) clearance. However, if you are in the situation where you haven’t done anything about them and you need to go back and do them retroactively, you’ve set yourself up for a difficult task, but it’s not too late.

We’re going to run through what you need to look out for on the assumption that you’ve just found out the FDA are coming to inspect and that you need to get your DHF and design controls sorted pronto.

Here’s where we begin:

Free Bonus Giveaway: Get our table for matching up your 510(k) submission sections with your Design History File here.

 

Yikes, you have an imminent inspection...

This is a situation that is familiar - when a company receives notice of an FDA inspection. The company suddenly looks in disbelief and realizes that they need to take action quickly. If you have a Class II medical device, the FDA is mandated to inspect you every 2 years, so you should always be ready.

I received a phone call a couple of years ago from a guy who said “I have a 510(k) clearance, now I have to put together a design history file, what is that? I also need to document my risk management activities and put together a quality system.” This guy had done nothing, which was not a good scenario at all.

Your 510(k) should be a milestone that is put together with the assistance of your design history file and design controls. How on earth did this guy manage to get a 510(k) clearance without those vital pieces in place?

As a side-note to be aware of, there are consultants in this industry who are performing malpractice right now. A client calls them and asks them to put together a 510(k) for them. Of course, they agree because it’s a good payday. They don’t have to put their name on it as the company is ultimately responsible to the FDA. The consultant might ask for information just so they can put together a good submission, but they often won’t ask the simple questions, “Do you have a design history file?” or “Have you documented your risk management activities?” They don’t check that these are in place and the companies they do the work for often don’t know what they don’t know. This means that the company may be non-compliant without knowing it.

It’s not ideal, but if you are in this situation then you MUST go back and complete the DHF.

Tip #1.

If you’re caught in this scenario and have to complete a DHF retroactively, do NOT EVER back-date. Write a memo, acknowledge that you messed up and that things are out of order. Note that you are taking care of design controls retrospectively. Keep this in company records and document this decision. If you have a QMS in place and a CAPA procedure, this is a good opportunity to issue yourself a CAPA.

If the FDA comes in and sees that you are self-policing, that’s a good thing. They will be encouraged by seeing you do the right thing. You want to be in the best standing as possible with the FDA.

 

Where to look on your 510(k)

If you are completing your DHF retroactively, we are highlighting which sections of your 510(k) to go to and extract information from, which you can then populate to your design history file. You can use this as a kind of road map to get there. When that guy came to me with his 510(k) clearance and no DHF, I was able to take the 510(k), and highlight the design history elements for him.

Tip #2. Use the sections of your 510(k) to guide your retroactive DHF and design controls.

Getting to 510(k) without a DHF in place is an appalling scenario because there are many sections of the DHF that feed directly into the 510(k) submission. For example, section #4 “indications for use” is the claim of what your device does. This establishes the basis for design inputs and really sets the stage.

You still need to have a DHF and capture those design controls! Doing so retrospectively is not good, but if you didn’t do it during the design process, retrospectively is better than nothing.

Section #5 is the 510(k) summary. This is an overview or description of your medical device. You might have information included that describes the device, performance characteristics, and labeling. (How your device is labeled is a design output and, along with other inputs and outputs will be captured in the 510(k) summary). You’ll also have a little bit on non-clinical testing, which is an example of specific design verification activities.

Section #9 is the declarations of conformity and summary reports. The FDA has a process where it recognizes consensus standards. The FDA's database follows standards, such as ISO, and will understand if you make a declaration of conformance with those standards. For example, if I declare conformity with ISO 10993, I’m saying the testing I’ve done follows that standard to the letter. There are a number of different standards that may be included here. This section relates to your design control and design history file as part of design verification. These activities show proof that your device does what it sets out to do.

Section #10 is the executive summary. Sure, it may seem there are some redundancies, but the FDA divides up the 510(k) submission between different specialists so there will be some double-ups in information required because they’re not seeing every section. Indications for use are talked about here, which lead to user needs, which feed into design outputs etc. The executive summary will also have some device description information that can be helpful for capturing design inputs, or relate to design outputs. You’ll probably also talk about some of the testing you have done to validate your device. All of these aspects are needed for your DHF.

Section #11 is the device description. This has information describing your device, such as design inputs, and outputs, drawings, schematics, specifications and anything else providing a clear description. This section should (hopefully!) be very well done and a wealth of information for putting together your DHF. The chances are FDA wouldn’t have given a 510(k) clearance if this section was not very thorough. It is one part that is worth spending extra time on getting right.

Section #12 is around substantial equivalence. This is part of design verification and refers to all of the things that you’re doing to show that your product is substantially equivalent to another device. Usually this involves testing for design verification or sometimes validation

Section #13 is proposed labeling. Labels are a design output and FDA requires an entire section on this because the words on the labels are very important. FDA wants to ensure your labeling is accurate and a true reflection of the product, in alignment with its guidelines. Everything in this section is a type of design output. If you’re in the situation with no design controls or DHF, you probably didn’t capture design inputs or outputs. You may have to look at your outputs to retrospectively interpolate design inputs, going back in time from a finished product. You might even need to break it down line by line from the label - each line may become individual design inputs.

Section #14 is sterilization and shelf-life. If this is relevant to your product, you need to prove that you’ve met sterilization requirements via testing or documentation. With regard to shelf-life, there is usually testing, either accelerated or real-time, to prove that your product can remain on the shelf for the time you have said. This is another case where you may need to use testing evidence as an investigative tool to define your design inputs.

Section #15 is on bio-compatibility. This is evidence to show your components are safe and won’t cause any issues with patients who are in contact with the device.

Section #16 is on software, which will only be relevant if your product uses software. This contains user needs, inputs, outputs, verification and maybe even validation. There’s a whole guidance document on this from FDA. If you have software, this might be the largest section of your submission.

Section #17 is electromagnetic compatibility and electrical safety. Everything in this section is a form of design verification. If you have to test to IEC 60601 (if you have an electronic medical device), this is a very detailed standard. There are pages of information required and the report you get can easily be 300 pages. The testing and reports will be very helpful for verification and for guiding to design inputs.

Section #18 is performance testing, bench. This contains design verification activities.

Section #19 is performance testing, animal. Not every device will involve animal testing, but if you do, it will be either design verification, design validation or both.

Section #20 is performance testing, clinical. Most devices don’t require this, but for those that do it will almost always be under the category of design validation.

Free Bonus Giveaway: Get our table for matching up your 510(k) submission sections with your Design History File here.

 

Final Thoughts

While it’s not ideal to be retroactively completing your design controls and DHF, it’s not an impossible task.

You need these before the FDA arrives to inspect or you will get a warning letter. It’s not too late if you’re prepared to take ownership and document everything. Formalize it in a memo and note what you’re doing about it. Create a quality plan or issue a CAPA. Somehow or other, identify that you’ve messed up and need to fix it.

Use the 510(k) sections as a guide to fill in the blanks from a design control standpoint. This is how you fill in the gaps and (we hope) pass inspection.


Still using a manual or paper-based approach to manage your design controls or quality processes? Click here to learn more about how greenlight.guru's modern eQMS software platform exclusively for medical device companies is helping devicemakers all over the globe in more than 320 cities and 26 countries get safer products to market faster with less risk while ensuring regulatory compliance.