Medical Device Technical File: Complete Preparation Guide

Introduction

Many medical device manufacturers struggle with preparing technical documentation that consistently meets evolving regulatory expectations. A 2024 survey of European Notified Bodies revealed that approximately 6,978 MDR product certificates were issued from over 20,424 applications submitted between February 2021 and January 2024 — indicating that roughly one-third of submissions faced significant hurdles during technical documentation review.

A medical device technical file is a structured, controlled collection of documents demonstrating a device's conformity with applicable safety, performance, and regulatory requirements across its entire lifecycle. Think of it as the regulatory identity document your device needs before it can legally enter the EU, US, or most global markets.

This guide is written for medical device manufacturers, QA/RA teams, IVD manufacturers, SaMD developers, and startups preparing for CE marking, FDA submissions, or multi-market approvals. No device can be placed on the market without a compliant technical file — it is the foundational regulatory artifact in your product development process.

This guide covers:

• What a technical file is and what it must contain
• How to prepare one, step by step
• Common mistakes that trigger rejections or delays
• How technical files are reviewed and maintained across your device's commercial lifecycle

TLDR

• A medical device technical file is a comprehensive regulatory dossier proving a device meets all safety, performance, and compliance requirements before market entry
• Required under EU MDR 2017/745, EU IVDR 2017/746, ISO 13485:2016, and FDA premarket submissions (510(k), De Novo, PMA)
• Core contents: device description, risk management (ISO 14971), GSPR checklist, V&V data, clinical evaluation, PMS documentation, labelling, and QMS certificates
• Preparation begins during design and development — not after — and must be maintained as a living document throughout the commercial lifecycle
• Most common rejection causes: incomplete risk management, insufficient clinical evidence, poor version control, and siloed documentation across teams

What Is a Medical Device Technical File?

A medical device technical file is the regulatory identity document of your device. It consolidates design, development, manufacturing, clinical, risk management, and post-market evidence into a single record that demonstrates conformity with applicable requirements.

The terminology varies by jurisdiction: under EU MDR/IVDR it is called "technical documentation," under ISO 13485 it is the "medical device file" (Clause 4.2.3), and under the FDA it is expressed through the Design History File (DHF), Device Master Record (DMR), and Device History Record (DHR).

When Is a Technical File Required?

A technical file must be established during the design and development phase and completed before regulatory submission or market placement. All device classes require a technical file, though the depth and scope scale with risk classification:

• EU MDR: Class I devices require self-certification with technical documentation; Class Is, Im, Ir, IIa, IIb, and III require Notified Body involvement
• FDA: 510(k) submissions require substantial documentation; PMA requires even more comprehensive evidence

Under EU MDR, the technical file must be retained for 10 years from market placement — or 15 years for implantables — and kept accessible to regulatory authorities upon request.

Governing Regulatory Frameworks

The technical file is governed by multiple regulatory frameworks depending on your target markets:

• EU MDR: Article 10(4) and Annex II–III define technical documentation requirements
• EU IVDR: Annex II–III specify IVD technical documentation structure
• ISO 13485:2016: Clause 4.2.3 establishes the medical device file requirement
• FDA: 21 CFR Part 820 design controls (with the QMSR effective February 2, 2026, aligning Part 820 with ISO 13485)

What Must a Medical Device Technical File Contain?

While no single global template exists, the EU MDR Annex II–III structure is widely used as a reference framework. The Summary Technical Documentation (STED) format from GHTF/IMDRF is recognized across Europe, the US, Australia, and Japan, though each regulator has its own acceptance criteria.

Core Technical and Safety Documentation

Six documentation categories form the core of any compliant technical file:

1. Device Description and Specifications

• Device name, model, UDI, intended use
• Target user/patient population
• Variants and accessories
• Principles of operation and technology overview

2. Classification and Conformity Assessment Route

• Device class justified against Annex VIII rules (EU MDR) or FDA classification
• Selected conformity pathway (self-certification, Notified Body assessment, FDA premarket submission type)

3. Design and Manufacturing Information

• Design drawings and engineering specifications
• Manufacturing flowcharts and process descriptions
• Materials specifications and supplier documentation
• Process validation evidence
• Traceability to ISO 13485 Clauses 7.3 (Design and Development) and 7.5 (Production)

4. Risk Management Documentation per ISO 14971

• Complete risk management file including hazard identification
• Failure Mode and Effects Analysis (FMEA)
• Risk control measures and implementation evidence
• Evaluation of residual risks against clinical benefits
• Post-production information integration

5. General Safety and Performance Requirements (GSPR) Checklist

• Traceability matrix cross-referencing each Annex I GSPR clause to supporting evidence
• Documentation of conformity or justification for non-applicability
• FDA equivalent: design controls traceability matrix in the DHF per 21 CFR 820.30

6. Verification and Validation Data

Your technical file must include test protocols and reports demonstrating conformity with applicable standards:

• Performance testing per device-specific standards
• Biocompatibility (ISO 10993 series)
• Electrical safety (IEC 60601 series)
• Software validation (IEC 62304 for medical device software)
• Sterilization validation where applicable

All V&V data must trace directly to design outputs and risk controls.

Clinical, Post-Market, and Quality Records

Clinical and Performance Evidence

The clinical evaluation component is often the most scrutinized section of a technical file. You must provide:

• Clinical Evaluation Report (CER) for MDR devices following MEDDEV 2.7/1 Rev. 4 methodology
• Performance Evaluation Report (PER) for IVDR devices
• Consolidated peer-reviewed literature, clinical study data, or equivalence data (following MDCG 2020-5 strict equivalence criteria)
• Benefit-risk analysis substantiation
• MDCG 2020-13 Clinical Evaluation Assessment Report (CEAR) template compliance

Under EU MDR, clinical evidence requirements are substantially stricter than under the legacy MDD — insufficient or outdated clinical evidence is the most common cause of Notified Body objections.

Post-Market Documentation

Your technical file must demonstrate active lifecycle monitoring:

• Post-Market Surveillance (PMS) Plan with data collection methodologies
• Periodic Safety Update Report (PSUR) per MDCG 2022-21 guidance — required at least annually for Class IIb and III, every two years for Class IIa
• Post-Market Clinical Follow-up (PMCF) or Post-Market Performance Follow-up (PMPF) plan per MDR Annex XIV Part B
• Vigilance reporting procedures and complaint handling system documentation

Labelling, Instructions for Use, and Quality Management

The final documentation group includes:

• Labelling and IFU documents compliant with ISO 15223-1 symbols, UDI requirements (MDR Article 27 and Annex VI), and language requirements for each target market
• ISO 13485:2016 certificates or MDSAP audit reports, which independently verify your quality system meets applicable regulatory requirements

How to Prepare a Medical Device Technical File

Technical file preparation must run parallel to product design from the outset — not begin after development wraps. Cross-functional ownership is essential: regulatory affairs handles regulatory mapping, quality assurance owns risk and CAPA records, engineering drives design control, and clinical teams lead CER/PER development.

Manufacturers without dedicated in-house regulatory expertise often work with external consultants. Elexes has supported 250+ projects across 200+ product types, covering everything from early development through post-market surveillance.

Step 1: Confirm Device Classification and Regulatory Pathway

Determine Your Device Class

Use the applicable classification rules for your target markets:

• EU MDR: Apply Annex VIII Rules 1–22 to determine Class I, Is, Im, Ir, IIa, IIb, or III
• FDA: Reference 21 CFR Part 860 classification database
• National rules: Check TGA (Australia), Health Canada, or other jurisdictions as needed

Classification determines whether Notified Body involvement is required and which conformity assessment annex applies.

Identify Applicable Regulatory Pathways

• Confirm if your device is also subject to IVD, SaMD, or combination product rules
• Determine the submission route: EU conformity assessment (Annex IX, X, or XI), FDA 510(k)/De Novo/PMA, or other premarket pathways
• Document classification justification with clear rationale

Step 2: Define the File Structure and Build a Master Checklist

Create Your Documentation Framework

Establish a folder hierarchy aligned with MDR Annex II–III requirements or your Notified Body's specific template. A typical structure includes:

1. General Device Information
2. Design and Manufacturing
3. Risk Management
4. GSPR Compliance
5. Verification and Validation
6. Clinical Evaluation
7. Post-Market Surveillance
8. Labelling and Instructions

Develop Your Master Document Checklist

Create a comprehensive checklist listing every required element with:

• Document name and reference number
• Assigned owner (person responsible)
• Due date and current status
• Approval signatures required
• Version number and revision history

Establish document control procedures from the outset per ISO 13485 Clauses 4.2.4 (Control of Documents) and 4.2.5 (Control of Records). This prevents the single most common audit finding: poor version control and document traceability.

Step 3: Compile All Technical, Clinical, and Quality Evidence

Collect all required evidence across functional areas:

• Design records: specifications, drawings, architecture diagrams
• Manufacturing procedures: process flows, work instructions, supplier agreements
• Risk management files: hazard analysis, risk evaluations, control measures
• V&V test reports: performance, biocompatibility, electrical safety, software validation
• Clinical/performance evaluation reports with literature reviews and study data
• Labelling drafts and packaging artwork
• PMS plans and post-market data
• QMS certificates and audit reports

Build Your GSPR Traceability Matrix

The GSPR checklist is your master tool for confirming completeness. For each Annex I requirement:

• State whether it applies to your device
• Reference the specific supporting evidence (document number and section)
• Confirm the evidence demonstrates conformity
• Document any gaps requiring additional work

This cross-referencing process often surfaces documentation gaps before Notified Body review — catching them early avoids costly revision cycles downstream.

Step 4: Review, Submit, and Maintain as a Living Document

Conduct Internal Cross-Functional Review

Before external submission, conduct a formal internal audit to check:

• Consistency: Intended use in device description must match labelling, clinical claims, and risk controls
• Completeness: All checklist items present with current versions
• Traceability: Clear connections between risk controls, design outputs, V&V results, and clinical evidence
• Compliance: Documentation meets applicable standards and guidance

Submit to Notified Body or Regulatory Authority

Prepare your submission package according to the specific requirements of:

• Your Notified Body's technical documentation template
• FDA eCopy format for 510(k) or PMA modular structure
• TGA ARTG application format
• Health Canada MDL/MDEL submission requirements

Maintain as a Living Document

Under MDR Article 10(8), manufacturers must review and update technical documentation regularly to ensure continued conformity. Update your technical file whenever triggered by:

• Design changes or software revisions
• CAPA implementation affecting safety or performance
• New PMS or PMCF/PMPF data
• Regulatory standard updates
• QMS certificate renewals
• Notified Body or competent authority feedback

Each update must follow document control procedures with full version history, approval records, and change justification. Failure to maintain the file is a major nonconformity during surveillance audits.

Common Mistakes in Technical File Preparation

Incomplete or Poorly Structured Risk Management Documentation

The most frequently cited audit finding is incomplete risk management. According to BSI Notified Body guidance, manufacturers often:

• Fail to link risk controls to specific design outputs
• Omit residual risk evaluation or benefit-risk analysis
• Leave the risk management file disconnected from V&V and clinical data
• Don't update risk files with post-market surveillance findings

Reviewers expect full traceability through the entire ISO 14971 process — from hazard identification through post-production information — with clear evidence that each risk control was implemented and verified.

Insufficient or Outdated Clinical Evidence

Clinical evaluation is the primary bottleneck in MDR submissions. Common problems include:

• Inappropriate use of equivalence: MDCG 2020-5 requires strict technical, biological, and clinical characteristics alignment — equivalence criteria under MDR are substantially tighter than under legacy MDD
• Outdated CERs: Submitting clinical evaluations that don't reflect current PMS data or recent literature
• Missing PMCF plans: Higher-risk devices require ongoing post-market clinical follow-up; omitting a PMCF plan or justification for its absence is grounds for rejection

Under EU MDR Article 61, clinical evidence requirements are significantly stricter than under the legacy MDD — this is the most common cause of Notified Body objections.

Fragmented Documentation and Poor Version Control

When design, QA, clinical, and manufacturing teams store documents in separate systems with inconsistent naming, version numbers, or approval statuses, the technical file becomes internally inconsistent. Regulators and Notified Bodies will identify contradictions between:

• Device description and intended use statements
• GSPR checklist claims and actual V&V results
• Labelling instructions and clinical evaluation conclusions
• Risk controls documented versus design outputs implemented

A single document control system with unified versioning is essential for maintaining consistency.

Treating the Technical File as a One-Time Submission

Compiling the technical file once at submission and leaving it static is a reliable path to nonconformities at surveillance audits. The file must be updated whenever:

• Design changes affect safety or performance
• New risks are identified through complaints or vigilance
• PMS data reveals performance trends
• Regulatory standards are updated
• Clinical evidence evolves

Catching these gaps before they reach a reviewer — rather than during Notified Body assessment — is where experienced regulatory partners add the most value. Elexes' regulatory due diligence service has helped clients achieve a 90% audit clearance rate across 200+ product types by identifying inconsistencies, missing evidence, and compliance gaps during internal review.

How a Technical File Is Reviewed and Maintained

Internal Review Process

Before any external submission, conduct a cross-functional internal audit involving regulatory affairs, quality assurance, engineering, clinical, and manufacturing stakeholders. Use your GSPR checklist or submission-specific checklist as the review instrument, evaluating:

• Document completeness against the master checklist
• Traceability between design inputs, outputs, verification, and validation
• Consistency of intended use, indications, contraindications, and warnings across all sections
• Adequacy of risk management and clinical evidence
• Compliance with applicable standards and guidance documents

This internal review catches inconsistencies, missing documents, and incomplete evidence before they are flagged by a Notified Body or regulatory authority, which saves significant time and cost downstream.

External Review Process

EU MDR Notified Body Assessment

Notified Body review approaches vary by device class:

• Class III and certain Class IIb implantables: Individual assessment of full technical documentation
• Class IIa and some Class IIb non-implantable devices: Assessment may occur on representative sampling basis
• Class I sterile (Is), measuring (Im), reusable surgical (Ir): NB involvement limited to those specific characteristics

Review timelines depend on documentation completeness, device complexity, and Notified Body workload. As of early 2024, approximately 6,978 MDR product certificates were issued from 20,424 applications, indicating substantial review scrutiny.

FDA Premarket Review

FDA review timelines are governed by MDUFA V performance goals:

• 510(k): FY2024 average 124 calendar days; FY2025-2027 goal 112 days (95% within 90 FDA days)
• De Novo: 70% within 150 FDA days
• PMA: 290 days total time goal (FY23-24), 285 days (FY25-27); 90% within 180 FDA days for original PMAs without panel

Interactive review is common, and incomplete technical documentation can push timelines well beyond these targets.

Technical File Updates and Maintenance

Approval is not the finish line. Under MDR Article 10(8) and Annex III, manufacturers must maintain, review, and update technical documentation throughout the device lifecycle. Key update triggers include:

Design and Development Changes

• Design modifications affecting safety, performance, or intended use
• Software version updates or algorithm changes
• Material or component supplier changes
• Manufacturing process modifications

Quality and Post-Market Triggers

• CAPA implementation affecting device characteristics
• New complaint trends or vigilance events
• PMS or PMCF/PMPF data revealing performance issues
• PSUR findings requiring risk re-evaluation

External Regulatory Triggers

• Harmonized standard updates or new guidance documents
• QMS certificate renewals or surveillance audit findings
• Notified Body or competent authority requests for additional information
• Regulatory framework changes (e.g., MDD-to-MDR transition)

Each update must follow your document control procedures with full version history, approval records, and change justification. An auditor reviewing your file mid-cycle should find the same story told consistently — from the original design rationale through to the latest post-market data.

Frequently Asked Questions

How do I prepare a medical device technical file?

Preparation starts during the design phase — not after. Confirm your device classification, define the file structure per MDR Annex II–III, compile required documentation (design, risk, V&V, clinical, PMS, labelling, QMS), and conduct an internal GSPR traceability review before submission to the Notified Body or regulatory authority.

What should a medical device technical file include?

Per EU MDR Annex II–III, required content covers device description, classification justification, design and manufacturing information, ISO 14971 risk management, a GSPR checklist with supporting evidence, verification and validation data, a clinical evaluation report (CER), post-market surveillance documentation, labelling, and valid QMS certificates.

What is technical documentation under the EU Medical Device Regulation (MDR)?

Under EU MDR 2017/745, "technical documentation" is the complete body of evidence under Annex II and III demonstrating conformity with Annex I General Safety and Performance Requirements (GSPRs). It must be completed before signing the Declaration of Conformity and retained for at least 10 years (15 years for implantables).

What is the difference between MDD and MDR technical documentation?

Under the legacy MDD (93/42/EEC), Class III devices required a Design Dossier. Under EU MDR 2017/745, all devices must have standardized technical documentation per Annex II–III regardless of class. Requirements are significantly stronger for clinical evidence, post-market surveillance, GSPR traceability, and lifecycle integration. The transition deadline for legacy MDD certificates is December 2027/2028 depending on device class.

What are the main types of technical documentation for medical devices?

Terminology varies by jurisdiction: EU MDR/IVDR calls it "technical documentation" (Annex II–III); ISO 13485 uses "medical device file" (Clause 4.2.3); the FDA requires the DHF, DMR, and DHR under 21 CFR Part 820 (QMSR, effective February 2026, aligns this to ISO 13485). All frameworks serve the same purpose — demonstrating device conformity and regulatory compliance.

What is clause 7.3 of ISO 13485?

ISO 13485:2016 Clause 7.3 covers Design and Development controls, requiring documented design inputs, outputs, reviews, verification, validation, transfer, and change records. These form a core part of the medical device file (Clause 4.2.3) and feed directly into the technical file's design section and GSPR compliance evidence.