--- 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/2" 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-05-26" 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. Use this page to 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 source-linked answers before changing claims, software functions, technical documentation, or launch plans. ## 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 ### [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 explaining what Basic UDI-DI and UDI-DI identify, how they connect to UDI carriers, EUDAMED records, change triggers, and retained evidence. - 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 regulated as SaMD under the EU MDR? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md) Concise EU MDR FAQ on software qualification, intended medical purpose, Rule 11 classification, modules, clinical evidence, change assessment, UDI, and EUDAMED. - 3 items ### [Which devices need an SSCP under the EU MDR and what should it include? | EU MDR FAQ](/artifacts/eu/medical-device-regulation/faq/sscp.md) EU MDR FAQ on when an SSCP is required, who prepares, validates, uploads, and updates it, and what evidence should support the summary. - 2 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 2 of 2. Showing 16 of 36 items.* ### [How should software and borderline functions be handled?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md#how-should-software-and-borderline-functions-be-handled) *Module: [When do software or products make medical purpose claims under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md)* MDCG software guidance says software must have a medical purpose on its own to qualify as medical device software, unless it is an accessory, an Annex XVI product, or software that drives or influences a medical device. The location of the software, such as cloud, mobile, computer, or a hardware device, does not determine qualification. - Keep a module-level map for mixed products: separate administrative, communication, display, control, and patient-specific analysis functions. - For software that drives or influences a hardware device, document whether it operates, controls, modifies, or supplies output related to the device's functioning. - For patient-specific outputs, record the input data, algorithmic action, output, intended user, medical purpose, and whether the output treats, diagnoses, drives, or informs clinical management. Sources for this answer: - [MDCG 2019-11 - 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) - MDCG guidance for software qualification, including medical purpose, data actions, individual-patient benefit, accessories, and software driving or influencing devices. ### [How does Annex XVI differ from a medical purpose claim?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md#how-does-annex-xvi-differ-from-a-medical-purpose-claim) *Module: [When do software or products make medical purpose claims under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md)* Annex XVI is the MDR route for listed groups of products without an intended medical purpose, such as certain contact lenses, invasive anatomy-modification products, dermal fillers, adipose-tissue reduction equipment, high-intensity electromagnetic radiation equipment for skin treatment, and brain-stimulation equipment. That is different from saying a product has no MDR relevance. - Identify whether the product is listed in Annex XVI and whether the claim set is limited to a non-medical purpose. - Check for mixed positioning, such as aesthetic promotion alongside therapeutic, diagnostic, or clinical-performance claims. - If both medical and non-medical purposes are claimed, preserve both analyses instead of forcing the product into a single bucket. 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 source for Annex XVI and products with both medical and non-medical intended purposes. - [Commission Implementing Regulation (EU) 2022/2346](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2346&ref=sorena.io) - Sets common specifications for Annex XVI product groups without an intended medical purpose. ### [What evidence should be retained?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md#what-evidence-should-be-retained) *Module: [When do software or products make medical purpose claims under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/medical-purpose-claims.md)* Keep the qualification record with the technical documentation or equivalent product-compliance file. MDR Annex II expects a product description including intended purpose and users, medical conditions to be diagnosed, treated or monitored where relevant, qualification rationale, classification rationale, labels, instructions for use, and user-facing specifications such as brochures or catalogues. - Preserve the dated claim inventory and identify which claim text maps to each medical-purpose criterion. - Attach the labels, instructions for use, website and app-store copy, sales materials, release notes, and clinical evaluation excerpts reviewed. - For software, keep version, module, input, processing action, output, intended user, patient-specific benefit, and device-control or device-influence evidence. - Record the final qualification conclusion, classification follow-up if in scope, reviewer approvals, and the change triggers that reopen the analysis. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Annex II source for technical-documentation evidence, including intended purpose, qualification rationale, classification rationale, labels, and instructions. - [MDCG 2019-11 - 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) - Supports keeping software-specific evidence around function, intended purpose, patient-specific benefit, and device-driving or device-influencing behavior. ### [When a PSUR is required](/artifacts/eu/medical-device-regulation/faq/psur.md#when-a-psur-is-required) *Module: [When is a PSUR required under the EU MDR and what should it contain?](/artifacts/eu/medical-device-regulation/faq/psur.md)* Prepare a PSUR when the device is class IIa, class IIb, or class III. MDR Article 86 applies the duty to each device and, where relevant, to each category or group of devices. - Class I: prepare the Article 85 post-market surveillance report, not an Article 86 PSUR. - Class IIa: PSUR required, update when necessary and at least every two years. - Class IIb and class III: PSUR required, update at least annually. - Class III and implantable devices: submit PSURs through the Article 92 electronic system to the notified body involved in conformity assessment. - Other PSUR devices: make the PSUR available to the notified body involved in conformity assessment and, on request, to competent authorities. 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 85 and 86 distinguish class I PMS reports from PSURs for class IIa, IIb, and III devices and state the update cadence, technical-documentation placement, and notified-body handling. ### [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 is not a standalone narrative. It 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 file 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. - [EUDAMED - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED page identifying vigilance and post-market surveillance as one of the EUDAMED electronic-system modules. ### [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 MDR accessory test is not whether the article looks like a medical device. It is whether the manufacturer intends it to be used together with one or more particular medical devices to enable those devices to be used for their intended purpose, 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. - 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 regulated as SaMD under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md)* Start with the intended purpose stated in labels, instructions for use, promotional material, sales statements, and the clinical evaluation. MDR Article 2 includes software in the medical-device definition when it is intended for medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, or diagnosis, monitoring, treatment, alleviation, or compensation for injury or disability. - Record the intended medical purpose, patient population, user group, input data, output data, and claim text before assigning the MDR class. - Separate independent medical device software from software embedded in, connected to, or controlling a hardware device. - Do not qualify an entire platform automatically; identify the modules that have a medical purpose and the boundaries and interfaces with non-medical modules. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Binding MDR source for the medical-device definition, intended purpose, software as an active device, technical documentation, clinical evaluation, and UDI obligations. - [MDCG 2019-11 - 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) - MDCG guidance for medical device software qualification, non-qualifying software functions, software driving or influencing hardware devices, Rule 11, modules, and software change considerations. ### [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 regulated as SaMD under the EU MDR?](/artifacts/eu/medical-device-regulation/faq/software-and-samd.md)* After qualification, classify the software from its intended purpose and Annex VIII rules. For independent medical device software, MDCG 2019-11 points to Rule 11 for software that provides information used for diagnosis or therapeutic decisions, or software intended to monitor physiological processes. - Keep a Rule 11 memo covering diagnosis or therapy decision impact, monitoring purpose, vital-parameter risk, 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/oj?ref=sorena.io) - Binding MDR source for Annex VIII classification rules and implementing rules for software and active devices. - [MDCG 2019-11 - 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) - MDCG guidance explaining Rule 11, software driving or influencing devices, module boundaries, and examples of software classification under the MDR. ### [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 regulated as SaMD 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 UDI at the software system level and display software identification in the UDI-PI where applicable. - Assess software changes before release: new or changed algorithms, architecture, operating-system dependencies, user interfaces, interoperability channels, medical features, or closed-loop behavior can change qualification, classification, safety, performance, or registration data. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Binding MDR source for technical documentation, clinical evaluation, PMCF, UDI, and conformity assessment records. - [MDCG 2020-3 Rev.1 - significant changes under MDR Article 120](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/800e8e87-d4eb-4cc5-b5ad-07a9146d7c90%5Fen?filename=mdcg%5F2020-3%5Fen%5F1.pdf&ref=sorena.io) - MDCG source for software-change examples, including bug fixes, cybersecurity updates, operating-system changes, architecture changes, algorithm changes, UI changes, new medical features, and interoperability changes. - [European Commission - UDI/Device registration](https://health.ec.europa.eu/medical-devices-eudamed/udidevice-registration_en?ref=sorena.io) - Commission source for UDI/device registration and manufacturer submission of UDI/device information in EUDAMED. - [EUDAMED portal](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission portal source for EUDAMED purpose and module structure, including actor registration, UDI/devices, notified bodies and certificates, clinical investigations, vigilance/PMS, and market surveillance. ### [Which devices need an SSCP?](/artifacts/eu/medical-device-regulation/faq/sscp.md#which-devices-need-an-sscp) *Module: [Which devices need an SSCP under the EU MDR and what should it include?](/artifacts/eu/medical-device-regulation/faq/sscp.md)* The EU MDR trigger is specific: implantable devices and class III devices need an SSCP unless they are custom-made or investigational devices. Do not create the answer from a broad risk label alone; confirm classification, implantable status, intended purpose, and whether an exclusion applies. - Manufacturer role: draw up the SSCP, source it from technical documentation, keep it updated, manage translations, and verify the needed EUDAMED uploads before placing the device on the relevant market. - Notified body role: validate the draft against required content and current technical documentation, upload validated SSCPs to EUDAMED, and consider PMS, PSUR, PMCF plan, PMCF evaluation report, and other relevant information during surveillance. - EUDAMED role: make the SSCP publicly available and link it to the Basic UDI-DI; the public availability caveat is that some implantable class IIa and some class IIb implantable SSCP revisions may be uploaded before notified-body validation, so the revision history should state validation status. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745&locale=en&ref=sorena.io) - Article 32 is the binding source for the SSCP trigger, manufacturer duty, notified-body validation, EUDAMED upload, public availability, and label or IFU reference. - [MDCG 2019-9 Rev.1 - Summary of safety and clinical performance](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/5f082b2f-8d51-495c-9ab9-985a9f39ece4%5Fen?filename=md%5Fmdcg%5F2019%5F9%5Fsscp%5Fen.pdf&ref=sorena.io) - MDCG guidance for SSCP presentation, content, validation, translations, revision history, and EUDAMED upload mechanics. - [EUDAMED - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED source for the database role in transparency and device lifecycle information. ### [What evidence should support the SSCP?](/artifacts/eu/medical-device-regulation/faq/sscp.md#what-evidence-should-support-the-sscp) *Module: [Which devices need an SSCP under the EU MDR and what should it include?](/artifacts/eu/medical-device-regulation/faq/sscp.md)* The SSCP should be sourced from the device technical documentation. Keep a traceable pack showing where each public statement came from and how it remains aligned with the current technical file. - Keep classification and implantable-status rationale, intended purpose, label and IFU references, Basic UDI-DI, manufacturer SRN, notified-body name and identification number, and the SSCP reference number. - Keep the risk management file, design verification and validation reports, clinical evaluation report, PMS plan, PMCF plan and reports, PSUR inputs, vigilance or trend evidence, and IFU cross-references used in the SSCP. - Keep revision history showing issue dates, change descriptions, validation language, notified-body validation status, translations sent to the notified body, and EUDAMED upload checks. Sources for this answer: - [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745&locale=en&ref=sorena.io) - Annex XIV grounds the clinical evaluation and PMCF evidence that supports the SSCP's clinical performance and safety summary. - [MDCG 2019-9 Rev.1 - Summary of safety and clinical performance](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/5f082b2f-8d51-495c-9ab9-985a9f39ece4%5Fen?filename=md%5Fmdcg%5F2019%5F9%5Fsscp%5Fen.pdf&ref=sorena.io) - MDCG guidance identifies technical-documentation sources for SSCP content, including risk management, clinical evaluation, PMS, PMCF, IFU, and revision records. - [EUDAMED - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED source for the public database context and the system modules relevant to device, certificate, clinical, vigilance, PMS, and market-surveillance information. ### [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)* EUDAMED is not one generic evidence bucket. The Commission describes six modules: actor registration, UDI/device registration, notified bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance. - 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: - [EUDAMED portal - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED page identifying the six EUDAMED modules and the published mandatory-use notice for the first four 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: - [EUDAMED portal - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED page identifying the six EUDAMED modules and the published mandatory-use notice for the first four 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)* A EUDAMED entry is not the same thing as a full MDR compliance conclusion. 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 the source folder contains current grounded support. Sources for this answer: - [EUDAMED portal - European Database on Medical Devices](https://webgate.ec.europa.eu/eudamed?ref=sorena.io) - Commission EUDAMED page identifying the six EUDAMED modules and the published mandatory-use notice for the first four 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: 2 of 2 Pages: [1](/artifacts/eu/medical-device-regulation/faq/items.md) | [2](/artifacts/eu/medical-device-regulation/faq/items/page/2.md) [Previous page](/artifacts/eu/medical-device-regulation/faq/items.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) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/faq/items/page/2