What is the medical device technical file? What should it contain and how should it be structured? And is it even called the medical device technical file anymore?
What is the medical device technical file?
The medical device technical file (now known simply as the medical device file) is a term used in ISO 13485:2016.
It refers to the documents required by auditors and regulators to prove your product currently meets all performance and safety standards.
In the EU MDR and IVDR this collection of files is referred to as the “technical documentation.
In the US FDA QSR (Quality System Regulation) a similar collection of files is known as the Device Master Record.
Why is the medical device file so important?
Depending on device classification, in the EU the medical device file must be reviewed by a Notified Body and approved, with a certificate of conformity provided to you, before you can attach a CE or UKCA mark to your product and bring it to market.
In the US the DMR (Device Master Record) is one of three files that must be in place and approved by the FDA before you can launch there.
The technical file or DMR will be subject to regular (and often annual) review by your Notified Body and/or Regulatory Authority (depending on which country it is placed on the market). As a result it needs to be effectively controlled and maintained in real-time.
Does every medical device need a device file?
For devices that do not require 3rd party certification by a Notified Body or Regulatory Authority, (such as CE Class I devices, or devices that are 510(k) exempt in the USA) you are still required to comply with the requirements for compiling and maintaining a medical device file for your product. You are just not required to formally submit it for review and approval.
What should the medical device technical file contain?
The EU MDR and IVDR specifies the ‘technical documentation’ that you must submit to the regulator to be granted permission to apply the CE marking to your product.
Full details of these technical documentation requirements can be found here in Annex II (Technical Documentation) and Annex III (Technical Documentation on Post-Market Surveillance).
The technical documentation can be a submission of a bundle of documents in a single location or a summary document linking to the relevant version of each document in a document management system. But contents must include:
- Device description and specification, including all the variants and accessories.
- Complete labelling and packaging information.
- Instructions for use in all the languages accepted in the EU Member States.
- Design and manufacturing information.
- Documentation demonstrating compliance with all general safety and performance requirements and all relevant harmonised and non-harmonised standards.
- Benefit-risk analysis and risk management file.
- Product verification and validation report.
- Pre-clinical and clinical data, such as test results, Clinical Evaluation Report (CER) and Post-Market Clinical Follow-Up (PMCF) evaluation plan.
- Post-Market Surveillance (PMS) plan and report.
- Declaration of Conformity.
The MDR makes it clear that this documentation must be:
- Prepared and approved before your product is launched on the market.
- Available for review by auditors on demand throughout the product lifecycle.
While historical records of updates should be saved and archived for a period of 10 years from when the product was launched.
What does ISO 13485;2016 say about required technical documentation?
ISO 13485 says the following:
4.2.3 Medical device file
For each medical device type or medical device family, the organization shall establish and maintain one or more files either containing or referencing documents generated to demonstrate conformity to the requirement of this International Standard and compliance with applicable regulatory requirements.
The content of the file(s) shall include, but is not limited to:
a) general description of the medical device, intended use/purpose, and labelling, including any instructions for use;
b) specifications for product;
c) specifications or procedures for manufacturing, packaging, storage, handling and distribution;
d) procedures for measuring and monitoring;
e) as appropriate, requirements for installation;
f) as appropriate, procedures for servicing.
What is the technical documentation required by the FDA?
In the US the FDA’s technical documentation requirement is broken down into three separate submissions, the DMR (Device Master Record), the (Device History Record) and the DHF (Device History File).
The Device Master Record is equivalent to the Medical Device Technical File in ISO 13485:2016 and is specified in 21 CFR Part 820:
Each manufacturer shall maintain device master records (DMR’s). Each manufacturer shall ensure that each DMR is prepared and approved in accordance with § 820.40. The DMR for each type of device shall include, or refer to the location of, the following information:
(a) Device specifications including appropriate drawings, composition, formulation, component specifications, and software specifications;
(b) Production process specifications including the appropriate equipment specifications, production methods, production procedures, and production environment specifications;
(c) Quality assurance procedures and specifications including acceptance criteria and the quality assurance equipment to be used;
(d) Packaging and labeling specifications, including methods and processes used; and
(e) Installation, maintenance, and servicing procedures and methods.
Is there a globally accepted structure for technical documentation?
Yes! Well, almost.
With so much complexity involved in preparing technical documentation for regulatory approval, various attempts by international bodies have been made to harmonise requirements across different markets.
The first attempt at this, the STED (Summary Technical Document) has now been replaced with two further summary templates (for IVD and non-IVD devices) published by the IMDRF (the International Medical Device Regulators Forum).
These two documents provide a useful structure for the technical documentation that is required by regulators in America, Canada, Brazil, Australia, Japan, Europe and then UK.
Using these as your templates means you don’t have to build different versions of your technical file for each region. They are known by the catchy title ‘IMDRF Table of Contents’:
What software do I need to structure and control my medical device technical file?
So, how do the people who deal with medial technical file submissions every day, prepare their technical documentation for audit?
We asked our Medical Device Quality Consultant partner Sam Shelley what kind of system she recommends to build out a compliant technical file, while minimising the amount of effort and disruption involved every time you are audited.
She emphasised that in contrast to the Design History File, the medical device technical file is essentially a ‘snap shot’ of your current compliance status. She told us
“The medical device file is the ‘here and now’ documented evidence, which gives all the latest information about the product you are making. It contains all the evidence that your product is currently safe, effective and complies with relevant regulatory requirements and standards.”
To make this happen you need a system that can help you build the contents of your file in real time as you develop your product, while automatically archiving each fresh iteration of your process for your Design History File (DHF).
As Sam points out:
“Creating the technical file requires pulling all of the associated documents into a single location, fixed at the version applicable when you create that file. As the product evolves and the documents are revised, the superseded versions of those documents should become part of the Design History File (DHF).”
Why it’s hard to control your device file without a dedicated DMS
It’s important to remember your medical device file is a continually evolving document.
Following quality audits, you may respond to PMS data by updating your risk management file; you may also need to update your SOPs, testing procedures, validation records accordingly. All these changes must be captured in real time, so the file remains a faithful record of your safety and performance status.
The summary technical file always needs to point to the latest, approved version of each of these quality documents even as they are changed and updated. What’s more, these documents will need to exist simultaneously in different places in your document management system, and be automatically updated in these places when changes are made. In addition, they all need to have a full audit trail available of previous versions to prove they have been subject to appropriate change control.
If there are substantial changes to your product, process or procedures you will need to resubmit your entire Medical Device File to the regulator again. At this point you'll need to create a brand new Design History File that reflects and records all the changes your product has gone through.
Google Docs is not enough
Attempting to manage all this complexity using a paper-based system or something like Google Docs can easily end up in a mess of 1000s of files and file names scattered and duplicated across your servers. Without a centralised, automated system of document and version control you risk making mistakes that can cost you time and money.
You risk misfiling, misnaming or duplicating important documents, leading to broken links and poor navigation within your summary document. This can mean failed audits and significantly slow your route to market.
For more information on this, just read our latest blog about the pros and cons of using Google as a medical device QMS.
Choose a dedicated DMS to manage your medical device technical documentation
Choosing the right document management software that collates documentation within templates as you work, will save you days of filing and frustration.
Not only that, but when major changes are made to your product it can help you manage your Design History File much more efficiently.
As Sam Shelley points out, developers using dedicated Document Management Systems can accomplish big documentation tasks like this with relative ease:
“If you've got a version one of your product and you're now launching version two you can simply ‘archive’ the whole version of that technical file. So it goes from being the medical device file to being the Design History File version in practically one simple action.”
The medical device file is an essential part of your compliance documentation. The summary document with links to all required documents must be easy to navigate, always up-to-date, and ready for inspection on demand.
It’s impossible to manage evolving documentation like this without having the right document controls in place. But you should look for tools that can help you meet requirements in the most frictionless way possible.