Skip to content
If you are developing a medical device, the “Technical File” (or “Technical Documentation” in some regulations) is the most important set of documents you will ever create. It is your evidence to the world (and the regulators) that your device does what it says it does, safely.
What exactly is a Technical File?
“Technical File” is not a term that appears in any Medical Device Regulation, so it is not exhaustively defined, but it is the documentary evidence you have showing how your Medical Device complies with the applicable regulations.
What belongs in your Technical File?
The Technical File can be quite broad in scope – and lacking a specific definition, it can be flexible depending on who is making the request to review it.
A Technical File should contain:
- Description and Specification of the Medical Device
- User Guides and Labelling
- An explanation of how all of the relevant regulatory requirements have been met (like an Essential Requirements Checklist or a General Safety and Performance Requirements Checklist)
- Design and Manufacturing/Release Specifications
- Plans and Reports for Product/Software Development, Requirements, Verification and Validation Testing
- Clinical Evaluation Planning and Reports
- A Risk Management File, including Post-Market Surveillance
Navigating the Alphabet Soup: DHF, DMR, and DHR
The three terms – DHF, DHR and DMR – come from the US FDA Quality System Regulation (QSR). QSR was superseded in February 2026, so these are no longer present in regulations, but broadly speaking, these mean(t):
- DHF (Design History File) – The full history of the design process of a medical device.
- DMR (Device Master Record) – All the information you need to manufacture/release a version of a medical device.
- DHR (Device History Record) – The record of the manufacture/release of one specific medical device (or a software version for SaMD).
While these specific acronyms are fading from the official regulations, the principles remain.
What is a Medical Device File?
The Medical Device File is a term from ISO 13485. It includes much of the same as a Device Master Record (DMR) above – information about the device, its User Guides and labels and how to make, install and/or maintain it.
Why all the different terms?
Each of these terms are used in slightly different scenarios (e.g. manufacturing vs regulatory submission) and different territories – while there is some good alignment between territories on the requirements of a Medical Device, the regulatory processes are still quite different, so different terminology abounds.
Also, terminology is quite sticky. I’d expect to see some companies still referring to DHFs, DMRs and DHRs in 10 years’ time.
What about company Secrets and Intellectual Property?
It’s a common concern: Do I really have to show the regulator my “secret sauce”? The short answer is yes.
To ensure patient safety, regulators, Notified Bodies, Certification Bodies and the like need to have full access to your documentation. Medical Device Regulations contain requirements that documents related to Medical Devices be shared with regulators, with no regard to company secrets.
This principle is well-established and has been driven by bad practice by a small number of health-tech companies going back decades.
Fortunately, regulators tend to have strict confidentiality clauses and practices with their staff to prevent information from leaking out.
How should I structure a Technical File?
While there are standards defining the structure of a technical file (such as the IMDRF’s Table of Conents model), we’ve found that the best way to structure your Technical File is to align it with your Quality Management System.
The outputs from your Quality Management System (especially your Software Development, Risk Management, Post-Market Surveillance and Clinical Evaluation processes) should form the contents of the Technical File. Don’t build a separate, isolated folder; build a living document suite that reflects your daily operations
Pro Tip: Include a summary document explaining where the reader can find evidence related to the relevant regulations – both in the form of a checklist and an explanatory document structured similarly to the regulation you’re applying (for example, Annex II of EU MDR). This will make it easier for the regulator and your team to find exactly what they need.
When do I need to update the Technical File?
A Technical File is never ‘finished.’ The documents within should be updated in line with your Quality Management System, not on a specific timeline. While some Post-Market Surveillance documents have a maximum review timeline in the regulations, everything else should be kept up-to-date as you make changes to the product.
It’s important to get into a rhythm of determining which documents need to be updated in each release and to set up a QMS that makes it easy to make these edits and approvals.
Need help building a compliant, "audit-ready" Technical File?
At 8fold, we specialise in making the complicated simple. Whether you’re a startup building your first file or a scale-up navigating the new QMSR landscape, we’re here to guide you.
