Technical File vs. 510(k) vs. Design History File: What Medical Device Developers Should Know

Sometimes it feels like you need to know an entirely new language to work in the medical device field.

As with any kind of files in medical device development, these require a lot of effort, however, if you’ve done the background work, you will find that the information required inter-relates.

Here’s what we mean:

Free Bonus Giveaway: 4 Helpful Tips for Better Management of Your Design History File. Grab It Here.

Design History File

The design history file is an FDA term which you’ll find described in 21 CFR Part 820.30. It talks about your design controls and how they must be kept in a design history file. When you see the acronym “DHF” this is talking about the design history file, which is simply the collection of documents from the design and development process.

Here’s how the FDA describe it in 21 CFR Part 820.30(j):

“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 does now specify the need to establish “design and development files”.

“The organization shall maintain a design and development file for each medical device type or medical device family. This file shall include or reference records generated to demonstrate conformity to the requirements for design and development and records for design and development changes.”

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

People often look at the DHF as a snapshot of time, showing where the product is during any given moment. Often, when the product goes from design to manufacturing, the DHF gets buried or archived, which is not a good practice. If there are changes made during production or post-production, the DHF and associated design controls should be updated, along with revising risk assessments. It should be a living file that is used throughout the product's lifecycle rather than being viewed as an archive.

Typically, maintaining a DHF has been a very manual process, involving old-school, three-ring binders, filing cabinets and plenty of paper. With electronic-based quality management systems, the creation of the DHF has become a much easier task. For example, a DHF is one of the outputs of Greenlight Guru, created and updated through user inputs in the system.

We’ve begun 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) is the pre-submission form for all devices that are Class II or higher on the US market. Here’s how the FDA describes it:

“… a premarket submission made to FDA to demonstrate that the device to be marketed is at least as safe and effective, that is, substantially equivalent, to a legally marketed device (21 CFR 807.92(a)(3)) that is not subject to premarket approval.”

The aim is quite simple, to demonstrate to the FDA that your product is safe and that it works. However, in practice, the submission process can be quite daunting. A 510(k) submission contains 20 sections for different things like indications of use, device description, performance and more. Your design controls will feed into many of these sections.

Creating a 510(k) submission that is likely to get accepted is no easy task, yet many companies fail to give themselves a good base of having established design controls and a DHF. These should be your first step before preparing your 510(k). Why? Because your design controls and DHF provide documented evidence of your product development process in order to prove that your device is safe and effective.

Another thing that you should consider here is that once you have 510(k) clearance, you are immediately subject to FDA inspection at any time. Your design controls and DHF will be subject to their scrutiny and you can end up with 483 observations, and possibly a warning letter, if these aren’t up to par.

You need to at least be through your design verification process in order to submit a good 510(k). You should have gathered enough evidence from this process to support the requirement of “substantive equivalence.” This means that you can compare your product to another device that has already received 510(k) clearance.

The Technical File

A technical file is much closer in nature to a 510(k) than a design history file; it’s basically the European version of the 510(k). It is required to get your device into Europe and several other parts of the world. The aim of the technical file is to answer the following question:

How does this product demonstrate conformity to applicable European Union medical device regulations (EU MDR)?

The technical file is a bit less prescriptive than a 510(k) but has an expected format. This is known as Summary Technical Documentation (STED), and is explained in a guidance document from the Global Harmonization Taskforce.

Note that this has officially rebranded as IMDRF - International Medical Device Regulators forum, but their website still has Global Harmonization Taskforce branded documents. To put together your technical file, you need to be through 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. While design validation is proof that your product meets the needs of the end user, clinical evaluation is similar yet different. 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.

Here’s another point of difference from the 510(k); the technical file is required regardless of the class of device in the EU, whereas the 510(k) is for Class II and above in the US. The path to get your device to market in EU is dependent on class, so being able to classify your device is a vital early task. If your product is Class I or IIa, you may be able to self-certify; however, you still need authorized representatives to legally represent your product at market.

You might say: “But I never had to submit my tech file to my authorized representative?" This is changing as there is now a lot of heat on authorized representatives due to bad practices previously (companies weren’t asked to produce them, so simply didn’t do technical files for Class I and IIa). You will need to do something about it sooner rather than later.

Device Master Record (DMR)

Another distinction of the technical file is the device master record (DMR). This is basically the recipe for a device, including listing of components, pieces, materials, drawings, specifications, inspection procedures, manufacturing instructions and anything else that goes into its production. Your technical file is required to provide evidence of manufacturing processes, so in this sense, the DMR feeds into it.

In contrast, the FDA doesn’t check the DMR elements on 510(k) submissions, but will check it for premarket approval (PMA) for Class III devices.

The DMR originates in design controls as you’re developing the manufacturing process. Design outputs are developed during the design control process and are the preliminary device master record (drawings, specifications, etc.). During the design transfer process when a device transitions from product development to manufacturing, the design outputs are formally reviewed and approved and become the DMR.

Free Bonus Giveaway: 4 Helpful Tips for Better Management of Your Design History File. Grab It Here.

Set Yourself Up for Success…

These different documents may seem overly complicated, but if you lay the groundwork from early in your process, you’ll find you have a much simpler task ahead of you. You should:

• 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 that a consultant coming in to do your 510(k) will be able to do a great job of it if the DHF and design controls aren’t in place already. Lay the groundwork and give your company a better chance of success.

Looking for a design control solution to help you bring safer medical devices to market faster with less risk?  Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →