QMSEU

EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File

Build a technical file you can maintain through change.

Focus: Annex II/III structure, GSPR traceability, and QMS controls that keep evidence coherent (especially for software updates).

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 22, 2026

Updated

Feb 22, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 22, 2026

Updated Feb 22, 2026

Overview

Under MDR, the technical file is not just a folder - it is the output of your QMS. The fastest way to reduce audit pain is to design a technical file index that matches Annex II/III and to build QMS processes (document control, change control, supplier control, PMS/vigilance) that continuously update the evidence chain.

Section 1

QMS controls that matter most under MDR

You do not need a huge procedure library. You need a QMS that keeps the evidence chain coherent across design, clinical, post-market, labeling, and registration work.

Control: every process should have an owner, required records, review cadence, and a retrieval path that works during an audit.

Article 10 manufacturer controls: document control, design and change control, supplier control, complaint handling, CAPA, internal audits, management review, and technical-documentation maintenance.
Article 15 PRRC coverage: name the responsible person, define release and escalation touchpoints, and keep expertise evidence current. Micro and small enterprises still need permanent and continuous access to a qualified PRRC.
UDI governance inside the QMS: Article 10(9)(h) requires verification of UDI assignments and consistency of Article 29 information.
PMS and vigilance integration: complaints, trend signals, serious incidents, and FSCA actions should feed CAPA, risk management, CER updates, and label changes.
Legacy-device transition control: significant-change assessments, application records, written agreements, and surveillance-transfer files should sit inside the QMS, not outside it.

Section 2

Annex II and III technical documentation: build an index before filling it

A stable Annex II and III index reduces rework and makes reviews faster. The file should tell a consistent story even when the device changes over time.

Output: a technical-file table of contents with document IDs, owner, approval status, and links to the current evidence record.

Annex II device description and specification, including intended purpose, variants, accessories, and family logic such as Basic UDI-DI.
Annex II design and manufacturing information, including critical suppliers, outsourced processes, and software build or deployment dependencies.
Annex II GSPR checklist with explicit evidence links to tests, risk controls, clinical evidence, labeling, usability, and cybersecurity material where relevant.
Annex II verification and validation set: bench, biocompatibility, software V and V, performance, usability, sterilisation, packaging, and shelf-life evidence as applicable.
Annex III PMS file: PMS plan, PMS report or PSUR, vigilance interfaces, CAPA linkage, and change records showing post-market feedback into the file.

Recommended next step

Keep EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File in one governed evidence system

SSOT can take EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Evidence system

Open SSOT for EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File

Start from EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File and keep documents, evidence, and control records in one governed system.

Explore next step

Talk to Sorena

Talk through EU Medical Device Regulation (MDR) 2017/745

Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File.

Explore next step

Section 3

GSPR checklist: make it the traceability backbone

A strong GSPR checklist is the fastest way for a reviewer to understand whether the file is coherent. It should act as a map, not a text dump.

Control: each GSPR row should show the requirement, the design control, the verification evidence, the residual risk treatment, and the linked labeling statement where relevant.

Map each released claim to the GSPR row and to the exact evidence that supports it.
Show where residual risks are communicated, including IFU warnings, training, contraindications, and device limitations.
Tie CER conclusions and PMCF decisions back into the GSPR rows that depend on clinical evidence.
Keep supplier and software changes visible so the checklist does not drift away from the current design.
Check UDI, label, and EUDAMED data consistency as part of the same release gate.

Section 4

Software and frequent updates: add a regulated release dossier

Software devices and connected devices fail audits when releases are treated like routine engineering pushes rather than regulated changes. Build one repeatable release dossier for every production update.

Control: no release closes until the release dossier shows what changed, why it was acceptable, and which downstream records were updated.

Define release gates for verification, validation, cybersecurity review, clinical-impact assessment, risk update, label and IFU review, and UDI or registration impact.
Keep version history tied to CER updates, risk-management updates, PMS findings, and the registered device identity.
For algorithmic software, record new inputs, model retraining, changed automation, new user populations, and changed output claims as explicit review items.
Control third-party software components with supplier notifications, vulnerability notices, patch timelines, and deployment verification.
Archive screenshots, user-facing output samples, and release notes as controlled evidence because they are often what reviewers use to test intended purpose and classification.

Primary sources