Skip to main content

The Ultimate Guide to EU MDR Technical Documentation for Medical Device Manufacturers

Written by Karl Larsson on . Posted in Blog.

If you plan to develop and sell a medical device on the European Market, complying with the MDR (European Union Medical Device Regulation (EU MDR 2017/745)) is mandatory.

A cornerstone of this regulation is to write and maintain the required technical documentation, often referred to as the Technical File. Getting your Technical File complete, correct and consistent is an essential step of the conformity assessment procedure. 

When completed, you will submit the Technical File to your Notified Body, If the Notified Body is satisfied, your product will receive the CE mark necessary for selling the medical device in the EU market.

This guide provides an in-depth look at the essential elements of the Technical File, helping you ensure compliance, achieve CE marking, and bring safe, effective devices to market.

The Technical File – What is it?

The Technical File consists of a number of documents. Exactly which documents to include is partly mandatory (e.g. demonstrating conformity to Annex I of MDR) and partly up to the manufacturer. The areas the documents need to address are mandatory and outlined in Annex II of MDR.

In essence, the documentation describes your device, what it is made for (its intended use), how it is designed and manufactured, how you have made sure that it is safe and how you intend to make sure that it is safe in the future, taking into account changes you make but also post-market surveillance data from the market.

The underlying reason for having to compile and submit this documentation is that its content constitutes the proof that the medical device is safe for its intended use and effectively fulfills its purpose for patients and users.

Where to Start?

Let’s be honest. Compiling a Technical File a considerable task. However, if it makes you feel better, many companies, like your own, has successfully done this in the past and so will you.

You will notice that some requirements on the Technical File are very concrete (or at least appear to be very concrete) whereas other requirements are less firm and leaves a lot of latitude to the manufacturer. There also tends to be a continuously ongoing debate in the industry on how to best fulfill some of the more nebulous requirements.

Therefore, first make sure that you have a copy of the MDR text including the Annexes readily available. Then, please (!), take some time to read it through (suggested read order?) (I am sorry but you really have to read it).

The Technical File – continuously updated (even after approval!)

Note that the MDR requires you to not only compile and submit your technical documentation prior to launching a product. Be aware of thar  the technical file must be kept up to date by the manufacturer (you) and is part of the documentation obligations even after the product has been placed on the market.

Furthermore, you have make the documentation accessible to market surveillance authorities upon request once the device is available on the market. You must be able to make the technical documentation available to the competent authorities for at least 10 years after a device has been placed on the market. For implants, this minimum period is extended to 15 years.

Last but not least , if a competent authority checks whether an assessment by a notified body has been carried out properly, this also includes the technical documentation of a medical device i.e. they might want to take a look at your Technical File. In addition, a Member State in which a Notified Body is established may also require that technical documentation is provided.

One person in your organization will be appointed responsible for keeping the Technical File up to date. This Person responsible for regulatory compliance (PRRC) is responsible for ensuring that the technical documentation and the EU declaration of conformity are correct, complete, consistent and kept up to date.

According to the MDR, you (the manufacturer) must set up a surveillance system for monitoring the medical device after it has been placed on the market. The collected post-market data serves as a basis for the ongoing updating of the technical documentation.

Bottomline: a Technical File is not completed upon submission. The Technical File needs to be actively maintained for years to come and you must be prepared to show it upon a valid request. Therefore, your goal should not only be to prepare your Technical File for submission but also take active measures to make sure that it is easy to maintain.

How do I organize my Technical Documentation?

Everything OK so far? Then it is time to decide how to organize the Technical File. This takes us to the sensitive matter the Technical File structure. The Annex II of the EU MDR prescribes a number of Technical File sections. Annex II therefore prescribes both mandatory content parts but also the structure/order in which a Notified Body expect these to appear in your Technical File.

Note that the Annex does not necessarily prescribes concrete documents. Rather, it prescribe information sections. It is up to you to decide how you package these information sections into documents. You should, though, adhere to the structure of Annex II.

You will also notice that the information structure in Annex II does not chronologically align with the development cycle of a medical device. E.g. the Instructions for Use (IFU) is listed very early in the structure but can obviously not be compiled until very late in the development cycle. Thus, the structure of the Technical File does not correspond to the chronological creation time of the information and documents that constitute it.

Many of the documents in the Technical File are resulting from your development process and I suggest that you create these documents in the order that is prescribed by your development process but make sure that they are ordered in the structure mandated by Annex II and Annex III b.

Structure supplied by the Notified Body

Many notified bodies explicitly require you to use their Technical File structure. This makes their review work easier. These structures are expansions on the mandatory Annex II and Annex III b structure. If you have a Notified  Body, ask them if they require a structure and if yes, use that structure.

Document Format

There is a strict requirement in MDR that technical documentation should be prepared in a “clear, organized, readily searchable, and unambiguous manner”. This can of course mean many different things.

You Quality Management System already has a Document Management SOP. Use this for your technical documentation as well, such as:

  • Documents being uniquely named
  • Documents shall indicate their status
  • Each document has a version with a properly dated change history

Regarding document formats, clearer input is sometimes issued by Notified Bodies themselves. BSI, for example, gives helpful input on what they expect from a concrete documentation format perspective, such as:

  • Language: English (with a few exception)
  • Format: paginated, fully searchable bookmarked PDF files
  • Preferably the entire Technical File content in a single file
  • File Size: < 500 MB
  • The documents shall be not file protected or locked with passwords
  • Rules for consistent bookmarking
  • Logical file names
  • Specification on accepted signature approaches

(MDR Readiness Review (bsigroup.com))

Structuring Your Technical Documentation

According to Annex II your Technical File should be structured into the following sections:

Device Description and Specifications

This section states overall important key facts about your device. As previously mentioned, it is not clear if this is a single document or several documents. It is up to you to decide.

  • General Description: Provide the trade name, basic UDI-DI (Unique Device Identification - Device Identifier), and a detailed description of your device, including its intended purpose and principles of operation.
  • Classification Rationale: Explain your device's classification under the MDR, referencing the rules in Annex VIII and Article 51.
  • Variants and Accessories: Describe any device variants, accessories, or other devices that are part of the system.
  • Technical Specifications: Include detailed drawings, schematics, and descriptions of key functional elements, parts, components, and software.
  • Previous Generation(s): If applicable, describe previous versions of the device and outline the differences and improvements made.

Information Supplied by the Manufacturer

Although this section concerns various kinds of “printed” information, there is not always a great deal of commonality between the subsections. Also note that the content for this section tends to mature fairly late in the development cycle.

  • Labels and Packaging: Include all labeling information, ensuring compliance with MDR requirements for symbols, warnings, handling instructions, date of manufacture, and expiry date.
  • Instructions for Use (IFU): Provide comprehensive instructions, detailing the intended use, intended users, contraindications, precautions, warnings, and any relevant hazards.
  • Language Requirements: Ensure that labels and IFUs are available in the official EU language(s) required by each Member State where the device is marketed.
  • Electronic Instructions: If applicable, describe how electronic IFUs are provided and accessed, ensuring compliance with electronic documentation regulations.

Design and Manufacturing Information

Again, four very different points, although all concretely related to the product itself.  This is one of the bulkier sections of the Technical Documentation where you will spend a lot of time.

  • Design Documentation: Present detailed design drawings, material specifications, and descriptions of design stages.
  • Manufacturing Processes: Outline each step of the manufacturing process, including processes of manufacture, quality control procedures, and checks.
  • Site Information: List all sites where design and manufacturing activities occur, including subcontracted processes like sterilization or packaging, along with full details of subcontractors.
  • Supplier Management: Describe how suppliers are selected, evaluated, and monitored, including quality agreements and audits.

General Safety and Performance Requirements (GSPRs)

This information is, as mentioned, often collected in a single document, namely the GSPR checklist. You should start addressing this section early during the development in order to identify which documents you need to produce in order to complete this checklist. Note that the documents that constitute the evidence of compliance can in some cases be available only fairly late during the documentation process. It is not uncommon that this document is worked on continuously right to the moment before submission.

  • Compliance Checklist: Create a GSPR checklist (formerly the Essential Requirements Checklist under MDD) to demonstrate how your device meets each applicable requirement in Annex I.
  • Standards and Solutions: Reference harmonized standards, common specifications, or other solutions applied to meet the GSPRs.
  • Justifications: For any GSPRs that are not applicable, provide clear justifications with reasoning.
  • Evidence of Compliance: Include cross-references to controlled documents that provide evidence of conformity, such as test reports and certificates.

Benefit-Risk Analysis and Risk Management

Risk management activities accompanies the development process during the entire product development cycle (as well as after the release of the product). 

  • Risk Management Plan: Develop a plan in line with ISO 14971, detailing how risks are identified, evaluated, and controlled throughout the device's lifecycle.
  • Risk Analysis: Conduct a thorough risk assessment, including identification of potential hazards and estimation of associated risks.
  • Risk Control Measures: Describe the measures implemented to mitigate identified risks, including design features and protective measures.
  • Benefit-Risk Analysis: Document an analysis showing that the device's benefits outweigh any residual risks, ensuring acceptability.
  • Risk Management Report: Summarize the risk management activities and outcomes, confirming that the device is safe and effective.

Product Verification and Validation

V&V activities tend to be very rich in output. Our experience shows that V&V related documentation constitute up to 50% of the entire technical documentation volume. It is also one of the documentation sections that are the last to be finalized before submission. Therefore, plan what you can. Note that verification and validation is much more than just the actual testing.

Plan carefully how many instances of your instruments you will need for testing, which instances that can be used in parallel, which additional equipment you need for testing. Make sure that you make early reservations at any accredited labs. Nothing is more annoying than having a product that is ready but all testing labs are suddenly booked out.

  • Pre-Clinical Data: Include results from tests on biocompatibility (ISO 10993-1), chemical safety, electrical safety, mechanical performance, and software validation (if applicable).
  • Clinical Evaluation Reports (CERs): Provide a thorough clinical evaluation in line with Annex XIV, including data from clinical investigations, scientific literature, and clinical experience.
  • Biological Evaluation Report (BER): Compile biocompatibility data for all materials in contact with the patient, ensuring compliance with ISO 10993-1 standards.
  • Stability and Sterility Testing: Present evidence that the device maintains its safety and performance over its intended shelf life and under storage conditions.
  • Usability Testing: Include usability engineering processes and validation to ensure the device can be used safely and effectively by intended users.
  • Software Verification and Validation: For devices incorporating software, provide detailed software lifecycle documentation, including verification and validation activities per IEC 62304.

Post-Market Surveillance (PMS)

It might seem daunting to plan for the collection of post-market data for a device that do not yet exist. Still, it has to be done.

  • PMS Plan: Develop a proactive PMS plan as required by Article 83, detailing how you will collect and analyze post-market data.
  • Periodic Safety Update Reports (PSURs): For Class IIa devices and above, prepare PSURs summarizing the results and conclusions of your PMS data analysis.
  • Post-Market Clinical Follow-Up (PMCF): Outline your PMCF plan and summarize any findings, ensuring ongoing compliance and safety monitoring.
  • Vigilance Reporting: Establish procedures for reporting serious incidents and field safety corrective actions.
  • Trend Reporting: Implement systems to identify and report significant increases in the frequency or severity of incidents not considered serious.

What are the GSPR:s?

GSPR stands for General Safety and performance requirements. The are listed in Annex I of MDR. A part of your Technical File is to demonstrate how your medical device and your organization satisfies the mandatory GSPR requirements.

The GSPR’s are structured into the following four sections:

  • Requirements on how to design the medical device
  • Requirements on Safety and Risk management
  • Requirements on Materials and Packaging
  • Requirements on Information supplied by the manufacturer 

The GSPR’s are a fairly heterogenous set of requirements where some are very specific and others are much more high-level. Some of them are related to the product and others are more process related. 

I strongly recommend that you make yourself acquainted with the GSPR’s early in the development process. This will make it easier to plan and foresee your way to completion.

How do I comply with the GSPR:s

The absolute standard way to demonstrate conformity with the GSPR requirements is through a checklist. The checklist ideally has the following columns:  

  • The GSPR Requirements (text from MDR)
  • A justification describing why the GSPR does not apply, if it does not apply
  • The Methods used to demonstrate conformity with the requirement
  • Harmonised standards and/or common specifications used/applied
  • Reference to your own documents in the Technical File that demonstrate evidence of conformity with each harmonised standard or common specification.  

Note that if a requirement applies, you do not need to justify why.

However, if it does not apply, you must clearly state why with a full and proper justification. For example: ‘The device is not an active device since it is not powered. This requirement does not apply.'

Common Pitfalls and How to Avoid Them

Inadequate Documentation

Try to avoid insufficient detail. You should make sure that all sections of the Technical File are thoroughly documented with supporting evidence available.

Provide comprehensive evidence. Make sure that complete test reports, certificates, and validation results are available rather than summaries.

Use consistent language, numbering and identification schemas. Check for consistency across all documents, avoiding contradictions or outdated information.

Poor Risk Management

Conduct structured risk assessment in order to achieve exhaustive risk elicitations, considering all potential hazards, including those related to cybersecurity and data protection.

Implement effective risk control measures and verify their effectiveness. This can sometimes be both difficult and daunting but it needs to be done.

Fully document all risk management activities, including rationales for accepting residual risks.

Neglecting Post-Market Activities

Do not ignore feedback. Feedback is the best way for you to not only monitoring the safety of your product but also an invaluable source of information to make sour product better. Actively collect and analyze feedback from users and implement improvements to make the product better and safer.

Do not delayed your PMS updates. Regularly update PMS and PMCF plans and reports, integrating findings into risk management and clinical evaluation. To do this properly requires plenty of resources so make sure you plan accordingly.

Non-Compliance with Vigilance. Sooner or later it can happen to you. Train for the event of a vigilance case in order to ensure timely reporting if an incident occurs.

Conclusion

Preparing a thorough Technical File in line with the EU MDR is more than just a regulatory box to check—it's a critical step that directly impacts the safety and effectiveness of your medical device. By doing this right, you're not just ensuring compliance; you're building trust with your users and stakeholders.

When you compile and maintain your technical documentation, you’re showing a commitment to the highest standards of quality and patient safety. This isn’t just about meeting a requirement; it’s about positioning yourself for success in the EU medical device market, where quality is everything.

Meeting the EU MDR’s rigorous standards sets you apart from the competition. It shows the market that your company is serious about excellence and compliance. Think of it as an investment—not only in regulatory approval but in the long-term success and reputation of your business.