--- title: "EU MDR FAQ: qualification, evidence, UDI, and transition" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/faq/items/page/3" author: "Sorena AI" description: "Concise EU MDR FAQ covering device qualification, software classification, accessories, custom-made devices, clinical evidence, UDI, EUDAMED, notified bodies, significant changes, and legacy transition." published_at: "2026-05-09" updated_at: "2026-07-31" keywords: - "EU MDR FAQ" - "medical device qualification" - "Rule 11 software" - "clinical evaluation" - "PMCF" - "PSUR" - "SSCP" - "UDI" - "EUDAMED" - "notified body" - "legacy devices" - "EU Medical Device Regulation" - "EU MDR" - "Regulation (EU) 2017/745" - "Medical device software" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MDR FAQ: qualification, evidence, UDI, and transition Concise EU MDR FAQ covering device qualification, software classification, accessories, custom-made devices, clinical evidence, UDI, EUDAMED, notified bodies, significant changes, and legacy transition. *EU MDR FAQ* *Regulation (EU) 2017/745* ## EU MDR FAQ Short answers to recurring EU Medical Device Regulation questions on scope, classification, software, clinical evidence, UDI, EUDAMED, notified bodies, and transition planning. This page helps separate MDR facts that change conformity assessment and technical documentation from generic compliance housekeeping. This FAQ answers practical EU MDR questions that affect product scope, regulatory route, clinical evidence, market registration, and post-market obligations. It is written for product, quality, regulatory, and legal teams that need concise cited answers before changing claims, software functions, technical documentation, or launch plans. ## Definitions ### EU Medical Device Regulation **Term:** EU MDR The EU MDR is Regulation (EU) 2017/745, the directly applicable European Union law governing medical devices and their accessories placed on the Union market, made available, or put into service, as well as clinical investigations conducted in the Union. It also applies to covered Annex XVI products without an intended medical purpose from the applicable common-specification date. **Why it matters here:** The product's intended purpose, legal actor, device class, and market activity determine which MDR route and evidence duties apply. MDCG documents provide non-binding guidance on applying the Regulation; they do not replace its legal text or implementing acts. Sources: - [Regulation (EU) 2017/745, Article 1](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0745&ref=sorena.io) ### Reprocessing of a single-use device **Term:** reprocessing Reprocessing is the process carried out on a used device so it can be safely reused, including cleaning, disinfection, sterilisation and related procedures, testing, restoration of technical and functional safety, and preparation for the next use. MDR Article 17 allows reprocessing of a single-use device only where national law permits it. **Why it matters here:** A commercial reprocessor is normally treated as the manufacturer of the reprocessed device. A health institution can use the narrower Article 17(3) route only for devices reprocessed and used within that institution and under the applicable common specifications and national rules. Sources: - [Regulation (EU) 2017/745, Articles 2(39) and 17](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - [Commission Implementing Regulation (EU) 2020/1207](https://eur-lex.europa.eu/eli/reg_impl/2020/1207/oj/eng?ref=sorena.io) ## Browse sub-FAQ modules ### [Custom-made medical devices under the EU MDR | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/custom-made-devices.md) Concise EU MDR FAQ on custom-made device definition, mass-produced exclusions, Annex XIII statements, documentation, conformity assessment, PMS, vigilance, and records to retain. - 4 items ### [EU MDR significant changes FAQ: legacy-device transition and notified-body review](/artifacts/eu/medical-device-regulation/faq/significant-changes.md) FAQ on MDR significant changes for legacy devices, including intended-purpose, design, software, material, sterilisation, clinical, QMS, notified-body, and evidence impacts. - 3 items ### [EU MDR SSCP: Devices and Requirements](/artifacts/eu/medical-device-regulation/faq/sscp.md) Decide whether an EU medical device needs an SSCP, see worked class IIa, IIb, and III examples, and check the required content, evidence, publication, and update controls. - 6 items ### [How should Basic UDI-DI and UDI-DI be assigned under the EU MDR? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/udi-di-and-basic-udi-di.md) EU MDR FAQ on Basic UDI-DI grouping, device and package UDI-DIs, UDI carriers, EUDAMED registration, change triggers, and required records. - 4 items ### [What should an EU MDR PMCF plan and report cover? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/pmcf.md) Under the EU MDR, PMCF is part of PMS and clinical evaluation. See what the plan, activities, report, updates, and retained evidence should cover. - 2 items ### [What should manufacturers do when an EU MDR classification changes? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/class-changes.md) Concise EU MDR FAQ on classification changes, intended purpose, software, notified-body route impact, certificates, technical documentation, and retained evidence. - 2 items ### [When can clinical equivalence be used under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/equivalence.md) EU MDR FAQ on clinical equivalence, including technical, biological, and clinical characteristics, access to equivalent-device data, class III and implantable-device limits, clinical evaluation, PMCF, and retained evidence. - 4 items ### [When do software or products make medical purpose claims under the EU MDR? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md) EU MDR FAQ on medical purpose claims, intended purpose evidence, software qualification, Annex XVI contrasts, and records to keep. - 4 items ### [When is a PSUR required under the EU MDR and what should it contain? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/psur.md) EU MDR FAQ on PSUR scope, content, update cadence, PMS and PMCF links, notified-body handling, EUDAMED submission, and evidence to retain. - 3 items ### [When is an accessory regulated under the EU MDR? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/accessories.md) EU MDR FAQ on when an article is a medical device accessory, how intended purpose affects classification, and what evidence to keep. - 2 items ### [When is software a medical device under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md) EU MDR FAQ on medical device software qualification, Rule 11 and other classification rules, modules, evidence, software changes, UDI, and EUDAMED. - 3 items ### [Which EUDAMED modules matter under the EU MDR? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md) EU MDR FAQ mapping EUDAMED modules to actor registration, UDI/device data, certificates, clinical investigations, vigilance/PMS, market surveillance, and practical records. - 3 items Browse all indexed questions: [/artifacts/eu/medical-device-regulation/faq/items](/artifacts/eu/medical-device-regulation/faq/items.md) ## All FAQ items *Page 3 of 3. Showing 10 of 40 items.* ### [What the PSUR should summarize](/artifacts/eu/medical-device-regulation/faq/psur.md#what-the-psur-should-summarize) *Module: [When is a PSUR required under the EU MDR and what should it contain?](/artifacts/eu/medical-device-regulation/faq/psur.md)* The PSUR summarizes the results and conclusions of PMS data analysis gathered under the Article 84 PMS plan, together with the rationale and description of preventive or corrective actions. - PMS analysis: complaints, feedback, trend data, serious incidents, non-serious incidents, field safety corrective actions, literature, databases, registers, and similar-device public information where relevant. - Benefit-risk link: explain whether PMS and vigilance data changed the benefit-risk determination or risk-management file. - PMCF link: summarize main PMCF findings and cross-reference the PMCF evaluation report where PMCF is performed. - Corrective-action link: state the rationale for preventive, corrective, or field safety corrective actions and track implementation. - Market-exposure link: include sales volume, population estimate, population characteristics, and usage frequency where practicable. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - MDR Articles 83, 84, 86, 87, 88, 89, and Annex III ground the PSUR relationship to PMS, vigilance, trends, corrective actions, benefit-risk updates, PMCF, and technical documentation. ### [Evidence to retain](/artifacts/eu/medical-device-regulation/faq/psur.md#evidence-to-retain) *Module: [When is a PSUR required under the EU MDR and what should it contain?](/artifacts/eu/medical-device-regulation/faq/psur.md)* Retain the evidence needed to reproduce the PSUR conclusions and the notified-body or authority review path. The record should show which PMS inputs were collected, how they were analyzed, what changed in benefit-risk or risk management, and which actions were opened or closed. - Device scope: device identifiers, risk class, category or group rationale, custom-made status if relevant, and reporting period. - PMS inputs: complaints, user feedback, distributor and importer feedback, literature or register searches, similar-device public information, trend analyses, vigilance records, serious incidents, field safety corrective actions, and non-serious incident data. - PMCF records: PMCF plan, PMCF evaluation report, clinical-evaluation updates, and any justification for non-performance of PMCF. - Benefit-risk records: updated risk-management file, benefit-risk conclusion, thresholds or indicators used, and explanation of any new or changed risk signal. - Action records: preventive or corrective action rationale, field safety corrective action records, owner, status, effectiveness checks, and notified-body or competent-authority correspondence. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - MDR Annex III lists PMS-plan inputs and confirms that the PSUR and PMS report are part of post-market surveillance technical documentation. - [European Commission - EUDAMED overview](https://health.ec.europa.eu/medical-devices-eudamed/overview_en?ref=sorena.io) - Current Commission source identifying Vigilance and post-market surveillance as an EUDAMED module and listing it as in development. ### [When is an accessory regulated as a medical device accessory under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/accessories.md#when-is-an-accessory-regulated-as-a-medical-device-accessory-under-the-eu-mdr) *Module: [When is an accessory regulated under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/accessories.md)* The manufacturer's intended purpose controls the accessory test. The article must not itself be a medical device, and the manufacturer must intend it for use with one or more particular medical devices to enable their intended use or to specifically and directly assist their medical functionality. - Record the particular device or device family the article supports and the intended medical function it enables or assists. - Distinguish an accessory from a component, spare part, system, or procedure pack; those categories can trigger different MDR analyses even when products are supplied or used together. - Classify the accessory separately from the device with which it is used; Annex VIII states that accessories are classified in their own right. - If the product is qualified as an accessory, keep MDR technical documentation, clinical evaluation evidence where applicable, UDI assignments, EU declaration of conformity data, registration evidence, and PMS inputs proportionate to its class and risk. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Defines accessories for medical devices, brings accessories within MDR device rules, and requires separate classification of accessories in their own right. - [MDCG 2022-7 - Questions and answers on the UDI system](https://health.ec.europa.eu/system/files/2022-05/mdcg_2022-7_en.pdf?ref=sorena.io) - Explains Basic UDI-DI grouping, UDI responsibilities, and UDI handling for device components and regulatory documentation. - [European Commission - EUDAMED UDI/device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Commission source for the UDI/device registration module used for device identification and registration data. ### [Accessory evidence to retain](/artifacts/eu/medical-device-regulation/faq/accessories.md#accessory-evidence-to-retain) *Module: [When is an accessory regulated under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/accessories.md)* A useful accessory file should let a reviewer see the product boundary, the medical device relationship, and the MDR duties triggered by the conclusion. Keep the rationale close to the technical file rather than as a standalone label decision. - Qualification: why the article is a medical device, an accessory, outside MDR, or part of another configuration. - Classification: Annex VIII rule applied to the accessory, risk class, and notified-body involvement where that route follows from the classification. - Lifecycle duties: technical documentation, EU declaration of conformity data, UDI and registration records, clinical evaluation support where applicable, PMS plan inputs, complaint handling, vigilance triggers, and corrective-action records. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Grounds manufacturer duties for technical documentation, UDI, registration, EU declaration of conformity, classification, and PMS. - [MDCG 2022-7 - Questions and answers on the UDI system](https://health.ec.europa.eu/system/files/2022-05/mdcg_2022-7_en.pdf?ref=sorena.io) - Supports UDI and Basic UDI-DI evidence expectations for documentation, certificates, declarations of conformity, SSCP, and PSUR references. ### [When does software qualify as medical device software?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md#when-does-software-qualify-as-medical-device-software) *Module: [When is software a medical device under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md)* Start with the intended purpose stated on the label, in the instructions for use, in promotional or sales materials or statements, and in the clinical evaluation. MDR Article 2(1) includes software intended for specific medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or disability; or investigation, replacement, or modification of anatomy or a physiological or pathological process or state. - Record the intended medical purpose, patient population, user group, input data, output data, and claim text before assigning the MDR class. - Separate software with its own medical purpose from software that only drives, influences, or specifically enables a hardware device. - Do not qualify an entire platform automatically. Identify each medical module, its dependencies, and its boundaries and interfaces with non-medical modules; then show that the combined configuration is safe and does not impair the regulated module's performance. - Check separately whether software is an MDR accessory, an IVDR device, or software intended for an Annex XVI product. An accessory can fall under the MDR without having its own medical purpose, the IVDR has its own definition, and Annex XVI brings listed product groups without an intended medical purpose into the MDR framework. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/2026-01-01/eng?ref=sorena.io) - Current consolidated MDR text for Article 2 definitions, accessories, intended purpose, software as an active device, and the Annex VIII rules. - [MDCG 2019-11 Rev.1 - qualification and classification of software](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf&ref=sorena.io) - June 2025 non-binding MDCG guidance for MDSW qualification, MDR/IVDR boundaries, accessories, deployment location, simple search, Annex XVI software, and modular products. ### [How does Rule 11 classify MDR software?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md#how-does-rule-11-classify-mdr-software) *Module: [When is software a medical device under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md)* After qualification, classify the software from its intended purpose and all applicable Annex VIII implementing and classification rules. Rule 11 addresses software that provides information used for diagnostic or therapeutic decisions and software intended to monitor physiological processes, but it is not the only possible rule. Depending on the purpose and configuration, Rules 12, 13, 15, or 22 and the rules for software that drives or influences another device may also matter. - Keep a classification memo covering every applicable Annex VIII rule, not only Rule 11. Record diagnosis or therapy decision impact, monitoring purpose, vital-parameter risk, any direct administration or closed-loop function, and any hardware-device rule that also applies. - Map each medical module separately when the product combines administrative, display, communication, decision-support, monitoring, or control functions. - Tie the class outcome to the conformity assessment route, notified-body involvement, technical documentation index, and release approval. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/2026-01-01/eng?ref=sorena.io) - Current consolidated MDR text for Annex VIII implementing rule 3.3, the strictest-rule principle, Rule 11, and other active-device classification rules; EUR-Lex notes that the consolidated text itself has no legal effect. - [MDCG 2019-11 Rev.1 - qualification and classification of software](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf&ref=sorena.io) - June 2025 MDCG guidance explaining Rule 11, other potentially applicable MDR rules, software that drives or influences devices, and non-binding classification examples. ### [What evidence should software teams keep?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md#what-evidence-should-software-teams-keep) *Module: [When is software a medical device under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md)* Keep a qualification and classification file that a reviewer can follow without product-history context. It should show the intended purpose, claims, users, patient population, input data, output data, medical action, module boundaries, Rule 11 analysis, applicable Annex VIII rules, and final class. - Use the same intended purpose across claims, IFU, clinical evaluation, technical documentation, classification memo, certificate scope, UDI records, and EUDAMED submissions. - For software commercially available on its own and constituting a device in itself, assign the UDI at the software system level. Display the UDI in an accessible plain-text screen; software without a user interface must be able to transmit it through an API. Software identification is part of the UDI-PI. - Assess every software change before release. A change to intended purpose, claims, performance, safety, interpretation of data, algorithms, database structure, operating platform, architecture, user interface, interoperability, module boundaries, or hardware interaction can affect qualification, classification, conformity assessment, or registration. MDR Annex VI separately requires a new UDI-DI for software modifications that change original performance, safety or intended use, or interpretation of data; minor revisions generally require a new UDI-PI instead. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/2026-01-01/eng?ref=sorena.io) - Current consolidated MDR text for technical documentation, clinical evaluation and PMCF, post-market surveillance, software UDI assignment and display, and UDI-DI change rules; EUR-Lex notes that the consolidated text itself has no legal effect. - [MDCG 2019-11 Rev.1 - qualification and classification of software](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf&ref=sorena.io) - June 2025 MDCG guidance for intended-purpose control, module dependencies, conformity assessment routes, and reassessment of software changes. - [European Commission - UDI/Device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Current Commission page confirming that the UDI/Devices module has been mandatory since 28 May 2026 and that manufacturers submit UDI/device information for devices subject to registration. ### [Which EUDAMED modules matter under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md#which-eudamed-modules-matter-under-the-eu-mdr) *Module: [Which EUDAMED modules matter under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md)* The Commission describes six EUDAMED modules: actor registration, UDI/device registration, notified bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance. The first four modules declared functional - Actor, UDI/Device, Notified Bodies and Certificates, and Market Surveillance - became mandatory on 28 May 2026. - Actor registration: manufacturer, authorised representative, importer, or system/procedure pack producer registration, SRN, registration request, supporting documents, and user access roles. - UDI/device registration: Basic UDI-DI, UDI-DI, device data, EMDN code, legacy-device data where applicable, and updates to device records. - Notified bodies and certificates: notified-body designation context, certificate information, certificate status changes, restrictions, refusals, suspensions, withdrawals, or reinstatements. - Clinical investigations: applications, single identification numbers, substantial modifications, reports, summaries, and adverse-event reporting that the MDR routes through the clinical-investigation electronic system. - Vigilance/PMS: serious incident reports, field safety corrective actions, field safety notices, PSURs for relevant devices, trend reports, and competent-authority coordination records. - Market surveillance: authority inspection reports, surveillance summaries, non-compliance measures, risk evaluations, and communications between competent authorities, the Commission, and notified bodies where the MDR requires them. Sources for this answer: - [European Commission - EUDAMED overview](https://health.ec.europa.eu/medical-devices-eudamed/overview_en?ref=sorena.io) - Current Commission source for the six modules, mandatory use of the first four since 28 May 2026, and the development status of the two remaining modules. - [European Commission - Actor registration module](https://health.ec.europa.eu/medical-devices-eudamed/actor-registration-module_en?ref=sorena.io) - Commission module page for actor registration, Single Registration Number, actor request process, required documents, and access roles. - [European Commission - UDI/Device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Commission module page for UDI/device registration, manufacturer device submissions, EMDN use, legacy-device registration, and the UDI helpdesk. - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745&ref=sorena.io) - Binding MDR source for EUDAMED electronic systems covering devices, economic operators, notified bodies/certificates, clinical investigations, vigilance/PMS, and market surveillance. - [Commission Implementing Regulation (EU) 2021/2078 on EUDAMED](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R2078&ref=sorena.io) - Implementing regulation source for EUDAMED setup, maintenance, data exchange, access, and IT security rules. ### [What practical records should teams keep for EUDAMED module work?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md#what-practical-records-should-teams-keep-for-eudamed-module-work) *Module: [Which EUDAMED modules matter under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md)* Keep a module-level record that explains what was submitted or reviewed, why it belongs in that module, who owns the EUDAMED account action, and what must be updated when the device, certificate, incident, investigation, or authority status changes. - Link each EUDAMED record to the legal manufacturer, authorised representative, importer, or system/procedure pack producer that owns it. - Keep UDI/device registration data aligned with the technical documentation, labels, certificates, SSCP where relevant, and change-control record. - For certificates, keep the notified body, certificate number, certificate type, scope, status, restrictions, and any related suspension, withdrawal, reinstatement, refusal, or amendment record. - For clinical investigations, keep the EUDAMED identifier, application dossier, substantial modifications, adverse-event reports, final report, and public summary status. - For vigilance/PMS, keep the report type, device identifier, incident or trend facts, FSCA/FSN record, PSUR where relevant, competent-authority correspondence, and closure rationale. - For market surveillance, keep inspection reports, non-compliance findings, measures required of economic operators, notified-body notifications, and authority communications. Sources for this answer: - [European Commission - EUDAMED overview](https://health.ec.europa.eu/medical-devices-eudamed/overview_en?ref=sorena.io) - Current Commission source for the six modules, mandatory use of the first four since 28 May 2026, and the development status of the two remaining modules. - [European Commission - Actor registration module](https://health.ec.europa.eu/medical-devices-eudamed/actor-registration-module_en?ref=sorena.io) - Commission module page for actor registration, Single Registration Number, actor request process, required documents, and access roles. - [European Commission - UDI/Device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Commission module page for UDI/device registration, manufacturer device submissions, EMDN use, legacy-device registration, and the UDI helpdesk. - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745&ref=sorena.io) - Binding MDR source for EUDAMED electronic systems covering devices, economic operators, notified bodies/certificates, clinical investigations, vigilance/PMS, and market surveillance. - [Commission Implementing Regulation (EU) 2021/2078 on EUDAMED](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R2078&ref=sorena.io) - Implementing regulation source for EUDAMED setup, maintenance, data exchange, access, and IT security rules. ### [What should not be inferred from an EUDAMED entry?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md#what-should-not-be-inferred-from-an-eudamed-entry) *Module: [Which EUDAMED modules matter under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/eudamed-modules.md)* An EUDAMED entry does not establish full MDR compliance. MDR Annex VI states that presence of a device UDI-DI in the UDI database must not be assumed to mean that the device conforms with the Regulation. - Do not treat actor registration or an SRN as proof that device technical documentation, conformity assessment, or PMS duties are complete. - Do not treat UDI/device registration as proof of conformity; keep the conformity evidence and device-registration record cross-referenced but separate. - Do not mix clinical-investigation records with post-market vigilance reports unless the MDR route for the event actually requires that linkage. - Do not cite national enforcement details, guessed module go-live dates, or future EUDAMED releases unless a current official source supports them. Sources for this answer: - [European Commission - EUDAMED overview](https://health.ec.europa.eu/medical-devices-eudamed/overview_en?ref=sorena.io) - Current Commission source for the six modules, mandatory use of the first four since 28 May 2026, and the development status of the two remaining modules. - [European Commission - Actor registration module](https://health.ec.europa.eu/medical-devices-eudamed/actor-registration-module_en?ref=sorena.io) - Commission module page for actor registration, Single Registration Number, actor request process, required documents, and access roles. - [European Commission - UDI/Device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Commission module page for UDI/device registration, manufacturer device submissions, EMDN use, legacy-device registration, and the UDI helpdesk. - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745&ref=sorena.io) - Binding MDR source for EUDAMED electronic systems covering devices, economic operators, notified bodies/certificates, clinical investigations, vigilance/PMS, and market surveillance. - [Commission Implementing Regulation (EU) 2021/2078 on EUDAMED](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R2078&ref=sorena.io) - Implementing regulation source for EUDAMED setup, maintenance, data exchange, access, and IT security rules. ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/medical-device-regulation/faq/items](/artifacts/eu/medical-device-regulation/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 3 of 3 Pages: [1](/artifacts/eu/medical-device-regulation/faq/items.md) | [2](/artifacts/eu/medical-device-regulation/faq/items/page/2.md) | [3](/artifacts/eu/medical-device-regulation/faq/items/page/3.md) [Previous page](/artifacts/eu/medical-device-regulation/faq/items/page/2.md) *Recommended next step for EU MDR teams* *Placement: after implementation section* ## Resolve MDR scope and evidence questions with citations Use the FAQ as a starting point for product-specific MDR qualification, classification, clinical evidence, UDI, EUDAMED, and transition records. - [Open Research Copilot](/solutions/research-copilot.md): Answer MDR interpretation questions with cited source material. - [Talk through implementation](/contact.md): Review your device scope, evidence model, and next MDR actions. --- [Privacy Policy](https://www.sorena.io/privacy.md) | [Terms of Use](https://www.sorena.io/terms-of-use.md) | [DMCA](https://www.sorena.io/dmca.md) | [About Us](https://www.sorena.io/about-us.md) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/faq/items/page/3.md