Medical Device Technical File: Complete Guide to EU MDR Technical Documentation (Annex II & III)
Comprehensive guide to medical device technical documentation — EU MDR Annex II & III requirements, FDA Design History File comparison, STED format, ISO 13485 medical device file, and step-by-step preparation instructions.
What Is a Medical Device Technical File?
A medical device technical file — more formally called technical documentation under the EU Medical Device Regulation (MDR) 2017/745 — is the complete body of evidence that demonstrates a device conforms to all applicable safety and performance requirements. It is the single most important regulatory document a manufacturer prepares, maintains, and makes available to regulatory authorities and Notified Bodies.
Every medical device placed on the European market must have a technical file, regardless of risk class. For higher-risk devices (Class IIa, IIb, III), this documentation is reviewed by a Notified Body as part of the conformity assessment. For Class I devices (except sterile, measuring, or reusable surgical instruments), the manufacturer self-declares conformity but must still prepare and maintain the full documentation.
The technical file is not a static document. It is a living compilation that must be kept current throughout the device's entire lifecycle — from initial design through post-market surveillance. Failure to maintain adequate technical documentation is one of the most common findings in Notified Body audits and a frequent trigger for regulatory enforcement actions.
Legal Basis Across Regulatory Frameworks
| Framework | Document Name | Legal Reference | Scope |
|---|---|---|---|
| EU MDR | Technical documentation | Annexes II & III, Article 10(4) | All medical devices |
| EU IVDR | Technical documentation | Annexes II & III, Article 10(4) | All IVDs |
| FDA (US) | Design History File (DHF) & Device Master Record (DMR) | 21 CFR 820.30(j), 820.181 | Class II & III devices (design controls) |
| ISO 13485 | Medical device file | Clause 4.2.3 | All devices under QMS scope |
| IMDRF/GHTF | STED (Summary Technical Documentation) | GHTF SG1 N011:2012 | International harmonization |
Terminology: Technical File vs Technical Documentation vs DHF vs DMR vs STED
These terms are often used interchangeably, but they have distinct regulatory meanings:
Technical File — A general industry term most commonly associated with the EU regulatory framework. It refers to the collection of documents demonstrating conformity. Under the MDD 93/42/EEC, this was the standard term.
Technical Documentation — The formal term used in the MDR (Article 10(4), Annexes II and III). It has a precisely defined structure and content requirements. This is the legally correct term under EU MDR/IVDR.
Medical Device File — The term used in ISO 13485:2016 Clause 4.2.3. It is a subset of the full technical documentation — focused on demonstrating that design realization, production, verification, and validation requirements are met.
Design History File (DHF) — The FDA term under 21 CFR 820.30(j). It is a compilation of records describing the design history of a device, covering the design control process from inputs through validation.
Device Master Record (DMR) — The FDA term under 21 CFR 820.181. It contains all specifications, production processes, labeling, and quality records for a finished device. It is closer in scope to the EU technical documentation than the DHF.
STED (Summary Technical Documentation) — A format developed by the Global Harmonization Task Force (GHTF), now maintained by IMDRF. It provides an internationally harmonized structure for presenting technical documentation in a summarized form suitable for regulatory review.
Comparison Table
| Characteristic | EU MDR Technical Documentation | FDA DHF | FDA DMR | ISO 13485 Medical Device File | STED |
|---|---|---|---|---|---|
| Regulatory scope | EU market | US market | US market | Global (QMS) | International |
| Covers design | Yes | Yes | Partially | Yes | Yes |
| Covers manufacturing | Yes | No | Yes | Partially | Partially |
| Covers clinical evidence | Yes | No | No | No | Yes |
| Covers labeling | Yes | No | Yes | Partially | Yes |
| Covers PMS | Yes (Annex III) | No | No | No | No |
| Reviewed by authority | Notified Body | FDA (inspection) | FDA (inspection) | Auditor | RA/CAB |
| Lifecycle document | Yes, updated continuously | Completed at design transfer | Updated continuously | Updated continuously | Snapshot |
EU MDR Annex II: Structure and Requirements
Annex II of the MDR defines six mandatory sections that must be included in the technical documentation. Each section has specific content requirements.
Section 1: Device Description and Specification
This section must provide a complete description of the device sufficient for anyone reading the documentation to understand what the device is, how it works, and what it is intended to do.
Required content:
- General description — The device name, its intended purpose, and a physical description including materials, components, and configuration
- Intended patient population — Who the device is designed for, including medical conditions, age groups, and any patient selection criteria
- Principles of operation — How the device achieves its intended purpose (mechanical, electrical, chemical, biological, etc.)
- Basic UDI-DI — The system for assigning the Basic UDI-DI as required by Article 27(5)
- Risk classification — The device class (I, IIa, IIb, or III) with the classification rule(s) applied from Annex VIII and a justification
- Qualification rationale — Why the product qualifies as a medical device under Article 2(1)
- Variants and accessories — Description of all variants and accessories covered by the documentation
- Novel features — Detailed description of any novel or innovative features
- Reference to predicate devices — If applicable, identification of previously marketed devices used for equivalence
- Images and diagrams — Photographs, drawings, or schematics sufficient to understand the device
Key point: The description of the intended purpose is one of the most critical elements — it determines the device classification and, consequently, the conformity assessment route. Inconsistencies between the intended purpose stated in the technical file, the IFU, and the clinical evaluation are one of the most common Notified Body findings.
Section 2: Information to Be Supplied by the Manufacturer
This section covers all labeling and information materials that accompany the device.
Required content:
- Labels — All labels affixed to the device or its packaging, in compliance with Article 21 and Annex I Chapter III
- Instructions for Use (IFU) — The full IFU, including all required information per Article 10(11) and Annex I Chapter III Section 23
- Electronic IFU (eIFU) — If applicable, justification for providing IFU in electronic format per Regulation (EU) 2021/2226
- Languages — Evidence that labeling is provided in the official languages of the Member States where the device is placed on the market
- Patient information — Any patient-facing materials, implant cards (for implantable devices), and information required by Article 18
Section 3: Design and Manufacturing Information
This section documents how the device was designed and how it is manufactured.
Required content:
- Design stages — Description of the design process from concept through design transfer, including design inputs, outputs, verification, and validation activities
- Design specifications — Complete set of drawings, component specifications, and assembly information
- Materials — Identification of all materials in contact with the patient, including chemical composition and biocompatibility status
- Manufacturing processes — Description of all manufacturing processes, including special processes (sterilization, molding, coating, etc.)
- Manufacturing sites — Identification of all sites involved in manufacturing, including subcontractors and critical suppliers
- Process validation — Evidence that manufacturing processes have been validated (IQ/OQ/PQ for critical processes)
- Environmental conditions — Any special environmental controls required during manufacturing or storage
Section 4: General Safety and Performance Requirements (GSPR)
This is the compliance matrix — the core of the technical file. The manufacturer must demonstrate conformity with every applicable GSPR from Annex I of the MDR.
Structure of the GSPR checklist:
Each GSPR entry should include:
- GSPR reference number and text — The exact requirement from Annex I
- Applicability — Whether the requirement applies to the device, with justification if not applicable
- Method of conformity — How compliance is demonstrated (e.g., testing, analysis, clinical data)
- Harmonized standards applied — Which EN ISO/IEC standards were used (with date/version)
- Evidence reference — Pointer to the specific test report, analysis, or document that proves conformity
The MDR contains approximately 30 GSPRs organized in three chapters:
- Chapter I — General requirements (risk management, safety, performance, benefit-risk analysis)
- Chapter II — Requirements regarding design and manufacture (chemical/physical/biological properties, infection/microbial contamination, mechanical/thermal risks, radiation, software, electromagnetic compatibility)
- Chapter III — Requirements regarding the information supplied with the device (labels, IFU, patient information)
Common mistake: Many manufacturers mark GSPRs as "not applicable" without adequate justification. Every "N/A" determination must be supported by a reasoned explanation.
Section 5: Benefit-Risk Analysis and Risk Management
This section integrates risk management throughout the technical documentation. It must demonstrate that the manufacturer has:
- Established a risk management process in accordance with ISO 14971:2019
- Identified all known and foreseeable hazards — Both in normal use and in foreseeable misuse conditions
- Estimated and evaluated risks — Using a defined risk acceptability criteria
- Implemented risk control measures — In the order of: inherent safety by design, protective measures, and information for safety
- Evaluated residual risks — Demonstrating that overall residual risk is acceptable when weighed against benefits
- Conducted benefit-risk analysis — Showing that the benefits of the device outweigh the residual risks
- Managed risk throughout the lifecycle — Including post-production monitoring
The risk management file (per ISO 14971) is typically a separate document referenced from this section, with the technical file containing the risk management summary and conclusions.
Section 6: Product Verification and Validation
This section contains the evidence that the device actually works as intended and is safe. It must include:
- Bench testing / laboratory studies — Performance testing, mechanical testing, electrical safety testing
- Biocompatibility testing — Per ISO 10993 series, for all patient-contacting materials
- Software verification and validation — Per IEC 62304 for software as a medical device or software incorporated into devices
- Clinical evaluation — The Clinical Evaluation Report (CER) per Article 61 and Annex XIV, including literature review, clinical investigation data (if applicable), and equivalence analysis
- Animal studies — If applicable, per pre-clinical testing requirements
- Usability evaluation — Per IEC 62366-1, demonstrating the device can be used safely and effectively
- Electromagnetic compatibility (EMC) — Per IEC 60601-1-2 for electrical medical devices
- Sterilization validation — If the device is supplied sterile, validation of the sterilization process
- Shelf life / stability testing — Real-time or accelerated aging data supporting the claimed shelf life
- Packaging validation — Evidence that packaging maintains device integrity throughout distribution and shelf life
Critical requirement: The verification and validation data must cover the complete scope of the intended purpose. Clinical data that only covers part of the intended patient population or indications will be flagged as a deficiency by Notified Bodies.
EU MDR Annex III: Technical Documentation on Post-Market Surveillance
Annex III requires that technical documentation include comprehensive post-market surveillance (PMS) documentation:
- PMS plan — Per Article 84, defining how the manufacturer will collect, analyze, and act on post-market data
- PMS report (Class I) — Per Article 85, summarizing the results and conclusions of PMS data analysis
- Periodic Safety Update Report (PSUR) — Per Article 86, for Class IIa, IIb, and III devices and Class B, C, and D IVDs, updated at defined intervals
- Post-Market Clinical Follow-Up (PMCF) plan and evaluation — Per Annex XIV Part B, for devices requiring ongoing clinical evidence generation
- Summary of Safety and Clinical Performance (SSCP) — Per Article 32, for Class III and implantable devices, uploaded to EUDAMED
FDA Requirements: DHF and DMR
Under FDA's Quality System Regulation (21 CFR Part 820), manufacturers must maintain two key documentation sets:
Design History File (DHF) — 21 CFR 820.30(j)
The DHF is a compilation of records describing the design history of a finished device. It must contain or reference:
- Design and development planning records
- Design input requirements
- Design output documents
- Design review meeting minutes and records
- Design verification records
- Design validation records (including clinical evaluations)
- Design transfer records
- Design change records
The DHF is retrospective — it documents what was done during the design process. It is not a forward-looking document.
Device Master Record (DMR) — 21 CFR 820.181
The DMR contains the current specifications and procedures for manufacturing:
- Device specifications (drawings, component specs, formulation)
- Production process specifications
- Packaging and labeling specifications
- Quality Assurance procedures and acceptance criteria
- Installation, maintenance, and servicing procedures
DHF/DMR vs EU MDR Technical Documentation
| Aspect | EU MDR Technical Documentation | FDA DHF + DMR |
|---|---|---|
| Clinical evidence | Required for all classes | Not required in DHF/DMR (separate submission) |
| Risk management | Integrated throughout | Referenced but not in DHF directly |
| PMS documentation | Required (Annex III) | Separate requirement (MDR reporting) |
| Labeling | Included | In DMR |
| Manufacturing | Included | In DMR |
| Lifecycle updates | Continuous obligation | Updated through design changes |
| Review mechanism | Notified Body review | FDA inspection |
2026 Update: As of February 2, 2026, the FDA's new Quality Management System Regulation (QMSR) incorporates ISO 13485:2016 by reference, replacing the legacy QSR (21 CFR 820). While the DHF and DMR concepts remain, manufacturers should align their documentation practices with ISO 13485 Clause 4.2.3 (Medical Device File). This convergence means that a well-structured EU MDR Technical File can serve as a strong foundation for FDA compliance as well, reducing duplication across regulatory frameworks.
ISO 13485 Medical Device File
ISO 13485:2016 Clause 4.2.3 requires that the organization establish and maintain a medical device file for each medical device type or medical device family. This file must contain or reference:
- Specification documents (product requirements)
- Manufacturing process specifications
- Verification and validation documents
- Measuring and monitoring procedures
- As applicable, installation and service requirements
The medical device file under ISO 13485 is narrower than the full EU MDR technical documentation — it focuses on demonstrating that design realization, production, verification, and validation are adequately controlled within the quality management system. However, it forms a critical subset of the overall technical documentation.
STED Format (Summary Technical Documentation)
The STED was developed by the Global Harmonization Task Force (GHTF) and is now maintained by IMDRF. It provides an internationally recognized format for presenting technical documentation in a summarized, structured form suitable for regulatory review in multiple jurisdictions.
When to use STED:
- When submitting to regulatory authorities that accept STED format (including several Asian and Latin American markets)
- As an internal organizational tool for structuring technical documentation
- When preparing submissions to multiple markets simultaneously
STED structure includes:
- Device description and specifications, including variants and accessories
- Labeling documentation
- Design and manufacturing information
- Essential Principles (GSPR) checklist
- Risk analysis and control summary
- Product verification and validation
- Declaration of conformity
The EU MDR Annex II structure is partly derived from the STED format but adds specific EU requirements (Basic UDI-DI, clinical evaluation per MDR Article 61, PMS documentation per Annex III). Manufacturers using STED should map their documentation to ensure all MDR-specific requirements are covered.
IVDR Technical Documentation
Under the IVDR (Regulation (EU) 2017/746), technical documentation follows the same Annex II/III structure as the MDR but with important differences:
- Analytical performance evaluation — Required in addition to clinical performance evaluation (Section 6 of Annex II)
- Performance evaluation — Must address analytical sensitivity, analytical specificity, trueness, precision, detection limit, and measuring range as applicable
- Common specifications — IVDR references common specifications (CS) in addition to harmonized standards
- Class-specific requirements — Class D IVDs require additional scrutiny and may be subject to EU reference laboratory testing
- Post-market performance follow-up (PMPF) — Analogous to PMCF under MDR, but focused on analytical and clinical performance
- Scientific validity data — Must demonstrate the scientific validity of the analyte, marker, or parameter being measured
Class-Specific Requirements
The depth and breadth of technical documentation scales with the risk class:
Medical Devices
| Requirement | Class I | Class IIa | Class IIb | Class III |
|---|---|---|---|---|
| Full Annex II documentation | Yes | Yes | Yes | Yes |
| Clinical evaluation | Yes (literature-based often sufficient) | Yes | Yes (more rigorous) | Yes (clinical investigation typically required) |
| PMCF | If justified | Yes | Yes | Yes (mandatory) |
| PSUR | No (PMS report instead) | Yes (annual or biennial) | Yes (annual) | Yes (annual) |
| SSCP | No | No | No (unless implantable) | Yes |
| Notified Body review | No (self-declared) | Yes (sampling) | Yes | Yes (full review) |
| Scrutiny procedure | No | No | For certain devices | Yes (Article 54) |
IVDs
| Requirement | Class A | Class B | Class C | Class D |
|---|---|---|---|---|
| Full Annex II documentation | Yes | Yes | Yes | Yes |
| Performance evaluation | Yes | Yes | Yes (more rigorous) | Yes (comprehensive) |
| PMPF | If justified | If justified | Yes | Yes (mandatory) |
| Notified Body review | No (self-declared) | Yes (sampling) | Yes | Yes (full review + EU ref lab) |
How to Prepare a Technical File: Step-by-Step
Step 1: Define the Intended Purpose
Write a clear, precise intended purpose statement. This determines classification, which determines the conformity assessment route, which determines documentation depth.
Step 2: Classify the Device
Apply the classification rules from MDR Annex VIII (or IVDR Annex VII). Document the classification rule applied, the rationale, and the resulting class.
Step 3: Establish the GSPR Checklist
Go through every GSPR in Annex I Chapter I, II, and III. For each, determine applicability, method of conformity, and evidence reference. Use the Team-NB position paper format as a template.
Step 4: Compile Device Description (Section 1)
Prepare a comprehensive description including all required elements from Annex II Section 1.
Step 5: Prepare Labeling Documentation (Section 2)
Compile all labels, IFU, and patient information materials. Ensure language requirements are met for target markets.
Step 6: Document Design and Manufacturing (Section 3)
Gather design records, manufacturing process descriptions, material specifications, and site information. Reference the DHF or design control records.
Step 7: Conduct Risk Management (Section 5)
Perform a complete risk analysis per ISO 14971. Document the risk management file and prepare the benefit-risk analysis summary for the technical file.
Step 8: Perform Verification and Validation (Section 6)
Plan and execute all required testing. Compile test reports and analyses. Ensure the scope of testing covers the complete intended purpose.
Step 9: Complete Clinical Evaluation
Prepare the Clinical Evaluation Report per Annex XIV. For Class III and implantable devices, ensure clinical investigation data or robust equivalence analysis is available.
Step 10: Prepare PMS Documentation (Annex III)
Develop the PMS plan, PMCF plan (if applicable), and templates for PSUR/SSCP.
Step 11: Compile and Cross-Reference
Assemble all documents into the technical file. Ensure all cross-references are accurate and traceable. Create a table of contents and document index.
Step 12: Internal Review
Have the technical file reviewed by someone not involved in its preparation. Use the Notified Body's perspective — is every claim supported by evidence?
Team-NB Best Practice Guidance
The Team of Notified Bodies (Team-NB) has published a position paper: "Best Practice Guidance for the Submission of Technical Documentation under Annex II and III of Medical Device Regulation (EU) 2017/745." Key recommendations include:
- Use a summary document (often called a "roadmap") at the beginning of the technical file to guide the reviewer through the documentation
- Clearly cross-reference between sections — e.g., risk control measures in Section 5 should be traceable to verification tests in Section 6 and GSPR compliance in Section 4
- Present the GSPR checklist in a tabular format with clearly identified evidence documents
- Include a traceability matrix linking user needs, design inputs, design outputs, verification, and validation
- Submit technical documentation in a searchable electronic format (PDF with bookmarks or a structured document management system)
- Ensure the intended purpose, indications, and patient population are consistent across all documents — IFU, CER, risk management file, clinical investigation plan, and technical file
- For device families or systems, clearly identify which documentation applies to which device variant
Common Mistakes in Technical Documentation
1. Incomplete GSPR Mapping
Marking GSPRs as compliant without providing specific evidence, or claiming conformity to a standard without documenting which requirements of the standard were met.
2. Inconsistent Intended Purpose
The intended purpose statement differs between the technical file, the IFU, the clinical evaluation, and the risk management file. Notified Bodies routinely check for consistency across all documents.
3. Insufficient Clinical Evidence
Relying on outdated literature, failing to address all indications in the clinical evaluation, or claiming equivalence without demonstrating full access to the predicate device's technical documentation (MDR Article 61 requires technical, biological, and clinical equivalence with sufficient access to data).
4. Missing Risk-Benefit Analysis
Annex II Section 5 requires an explicit benefit-risk analysis. Many manufacturers include the risk management file but fail to provide the integrated benefit-risk conclusion.
5. Outdated Documentation
Technical files not updated to reflect design changes, new post-market data, updated standards, or new clinical evidence. The MDR requires continuous updating.
6. Poor Organization
Documentation that is difficult to navigate, lacks a table of contents, or has broken cross-references. Notified Bodies review thousands of pages — clear organization directly impacts review efficiency.
7. Inadequate Software Documentation
For devices incorporating software, failing to provide documentation per IEC 62304 (software lifecycle), IEC 62366 (usability), and MDR requirements for software (including cybersecurity and state of the art analysis).
8. Missing Manufacturing Information
Insufficient detail on manufacturing processes, especially for critical suppliers and subcontractors. The MDR requires documentation of all sites involved in the manufacturing chain.
Maintenance and Lifecycle Management
The technical file is a living document. Updates are required when:
- Design changes are implemented (any change affecting safety or performance)
- New clinical data becomes available from post-market surveillance or clinical investigations
- Standards are updated (new editions of harmonized standards may change the presumption of conformity)
- Regulatory changes occur (e.g., new MDCG guidance, amended regulations)
- Post-market data reveals new risks or confirms the benefit-risk profile has changed
- Periodic reviews — Best practice is to review the technical file at least annually, even if no specific trigger exists
- Notified Body surveillance audits — NBs may request updated technical documentation during annual surveillance
All changes must be managed through the manufacturer's design control and document control procedures. The revision history should clearly identify what changed, why, and when.
Notified Body Review Expectations
Notified Bodies assess technical documentation as part of conformity assessment and during surveillance activities. Key expectations:
- Completeness — All six sections of Annex II plus Annex III documentation must be present
- Traceability — Every claim must be traceable to supporting evidence
- Consistency — Information must be consistent across all documents (intended purpose, classification, risk levels)
- Clinical evidence sufficiency — Clinical data must cover the complete intended purpose and patient population
- Risk management integration — Risk control measures must be implemented, verified, and traceable
- Quality — Surveys indicate that 75% of Notified Bodies report submissions are only 50% or less complete. This remains a persistent industry-wide problem.
For Class IIa devices, the Notified Body assesses a representative sample of the technical documentation. For Class IIb and III devices, all technical documentation is typically reviewed. Under Article 54, Class III and certain Class IIb implantable devices are also subject to a clinical evaluation consultation procedure (scrutiny).
Frequently Asked Questions
Is a technical file required for Class I devices?
Yes. All devices regardless of class require technical documentation per Annex II and III. The difference is that Class I devices (non-sterile, non-measuring, non-reusable surgical) do not require Notified Body review. The manufacturer prepares the documentation and makes it available to Competent Authorities upon request.
What is the difference between a technical file and a design history file (DHF)?
A DHF (FDA term) records the design control process — it documents the history of design activities. A technical file (EU term) is broader, covering the device description, risk management, clinical evidence, manufacturing, labeling, and PMS. The DHF is a subset of what the EU technical documentation requires.
How long must technical documentation be retained?
Under MDR Article 10(15), the documentation must be kept for at least 10 years after the last device has been placed on the market. For implantable devices, the period is at least 15 years. For devices distributed in the US, 21 CFR 820 requires records to be retained for the device lifetime or a minimum period as defined in the manufacturer's procedures.
Can a technical file cover multiple devices?
Yes, for device families and systems. The technical documentation may cover a group of similar devices if they share the same intended purpose, technology, and risk profile. However, each device must be individually identifiable, and any device-specific differences must be documented.
What language must the technical file be in?
The technical file itself can be in any language. However, if a Competent Authority requests the documentation, it must be provided in an official EU language determined by the requesting Member State. Labels and IFU must be in the official language(s) of each Member State where the device is sold.
Does the technical file need to be submitted to anyone?
Not routinely. It is held by the manufacturer and made available to Notified Bodies (for conformity assessment and surveillance) and Competent Authorities (upon request). The only submission required is the SSCP for Class III and implantable devices, which is uploaded to EUDAMED.
How often should the technical file be updated?
The MDR requires continuous updating. At minimum, a formal review should be conducted annually and whenever there are design changes, new clinical data, updated standards, or new post-market surveillance findings.
What is a GSPR checklist?
It is a compliance matrix mapping each General Safety and Performance Requirement from MDR Annex I to the evidence demonstrating conformity. It should show: the GSPR reference, whether it applies, the method of conformity (testing, analysis, etc.), standards applied, and the specific evidence document and reference.
Do software devices need a different technical file structure?
No — the same Annex II/III structure applies. However, software devices have additional documentation requirements per IEC 62304 (software lifecycle), including software architecture documentation, unit verification, integration testing, and software maintenance records. The MDR also specifically requires cybersecurity documentation for connected devices.
What is the STED and should I use it?
The Summary Technical Documentation (STED) is an IMDRF/GHTF format for regulatory submissions. It is recognized internationally. You can use the STED format as a basis for your technical file, but you must ensure all MDR-specific requirements (Basic UDI-DI, clinical evaluation per Article 61, PMS per Annex III) are additionally covered.
What happens if the Notified Body finds gaps in the technical file?
The Notified Body will issue findings (minor or major non-conformities). The manufacturer must address these within agreed timelines. Major non-conformities must be resolved before a certificate can be issued. Unresolved findings can delay market access by months.
Can I use the same technical file for FDA and EU submissions?
The underlying evidence (test reports, clinical data, risk analysis) is largely shared. However, the presentation format differs. FDA requires a DHF/DMR structure, while the EU requires the Annex II/III structure. Many manufacturers maintain a single evidence base and format it differently for each market.
Is a clinical evaluation required for all devices?
Yes. MDR Article 61(1) requires a clinical evaluation for all devices, regardless of class. For lower-risk devices, the clinical evaluation may be based primarily on literature and post-market data. For Class III and implantable devices, clinical investigation data is generally required unless equivalence can be fully demonstrated.
What is the relationship between the technical file and the DoC?
The EU Declaration of Conformity (Article 19) is a separate document in which the manufacturer declares that the device complies with the MDR. It references the technical documentation as the basis for the declaration. The technical file supports the DoC — it is the evidence behind the declaration.
How does the technical file relate to EUDAMED?
EUDAMED device registration requires data that comes from the technical file — Basic UDI-DI, device risk class, intended purpose, and other device attributes. The technical file should be the authoritative source for all data entered into EUDAMED. Any inconsistency between EUDAMED data and the technical file can be flagged during Notified Body audits.
Related Guides
- EU MDR / IVDR Complete Guide — Comprehensive overview of both regulations, including scope, classification, and transition timelines.
- Clinical Evaluation Report Guide — Detailed guidance on writing a CER that meets MDR Article 61 requirements.
- Design Controls Guide — FDA and ISO 13485 design control requirements for the device development lifecycle.
- DHF, DMR & DHR Documentation Guide — Understanding the US documentation framework and how it maps to EU requirements.
- ISO 14971 Risk Management Guide — The risk management process that feeds into your technical documentation.