There are so many different technical terms, documents, and acronyms you need to know working in the medical device field. There are three types of files specifically that cause a great deal of confusion: the design history file, 510(k) submission, and the technical file.

As with any kind of files in medical device development, these require a lot of effort. However, if you have good background knowledge, I think you will find there are similarities between each.

Design History File

The design history file is an FDA term described in 21 CFR Part 820.30, which talks about design controls and how they must be kept in a design history file (DHF). This is simply the collection of documents from the design and development process.

Per FDA, “Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plans and the requirements of this part.”

Until recently, a DHF was technically only a requirement defined by FDA. ISO 13485:2003 made no direct mentioned of a DHF, or something similar. However, the updated ISO 13485:2016 now specifies the need to establish “design and development files”.

The DHF now has more emphasis because it is acknowledged as a key file containing design control documentation. This is important because your design controls are your records demonstrating your product is safe.

Maintaining a DHF is most commonly a very manual process, involving old-school three-ring binders, filing cabinets, and paper. With electronic-based quality management systems, the creation of the DHF has become a much easier task.

I wanted to start with the DHF and your design controls because they really form the basis that feeds into the 510(k) and technical files.

The 510(k) Submission

The 510(k) submission is the common path for medical devices to gain market clearance from FDA. A 510(k) is required for most Class II devices (and some Class I and Class III; some Class II do not require 510(k)). The aim is to demonstrate to FDA that your product is substantially equivalent to a predicate device, a product that has been previously cleared by FDA. A good part of the 510(k) is to also demonstrate your product is safe and it works. It contains 20 sections for different things like device description, indications of use, and performance. Your design controls will feed into many of these sections.

Many companies fail to give themselves a good base of established design controls and a DHF. This should be your first step before preparing your 510(k) because they provide documented evidence of your product development process in order to prove that your device is safe and effective.

Once you have 510(k) clearance, you are could be subjected to FDA inspection at any time. Your design controls and DHF will be a primary subject to their scrutiny and you can end up with 483 observations, and possibly a warning letter, if these aren’t up to par.

The Technical File

A technical file is much closer in nature to a 510(k) than a design history file. It is required to get your device into Europe and several other parts of the world. The aim of the technical file is to demonstrate the conformity of the product to the applicable requirements and EU medical device (or IVD) regulations.

The technical file is a bit less prescriptive than a 510(k) but has an expected format. To put it together, you should to be through design verification and design validation first, whereas you just need to be through verification for the 510(k). Design validation might be addressed by comparative analysis, simulated use, animal studies, and/or clinical investigations.

One big difference with a technical file versus a 510(k) submission is the need to provide a clinical evaluation report. A clinical evaluation report addresses the product’s clinical investigation, risk, and outlines any post-market clinical follow-up (PMCF) studies that may be necessary. It is comparable to and serves a similar purpose to design validation.

Remember:

Determine your device classification early

• Establish good design controls
• Digitize your design history file for easy updating
• Establish your device master record

You shouldn’t expect a consultant coming in to do your 510(k) will be able to do a great job if the DHF and design controls aren’t in place already. Lay the groundwork and give your company a better chance for success.