---
title: "EU MDR Rule 11 software classification"
canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/rule-11-software"
source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/rule-11-software"
author: "Sorena AI"
description: "Classify MDR medical device software under Rule 11 using intended purpose, diagnosis or therapy decision impact, physiological monitoring, conformity route, clinical evidence, and software-change records."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU MDR Rule 11"
  - "medical device software classification"
  - "MDCG 2019-11"
  - "MDR software"
  - "Regulation (EU) 2017/745"
  - "EU MDR"
  - "MDR Rule 11"
  - "medical device software"
  - "software classification"
  - "clinical evaluation"
---
**[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 Rule 11 software classification

Classify MDR medical device software under Rule 11 using intended purpose, diagnosis or therapy decision impact, physiological monitoring, conformity route, clinical evidence, and software-change records.

*Artifact Guide* *EU MDR*

## EU MDR Rule 11 software classification

Rule 11 classifies MDR software that provides information for diagnosis or therapeutic decisions, monitors physiological processes, or falls into the residual software class.

Use this page to document whether software is medical device software, which Rule 11 branch applies, what conformity route follows, and what clinical and change evidence belongs in the file.

MDR Rule 11 is not a generic software rule for every health app. It applies after a qualification decision: the software must be a medical device, an accessory, or software that drives or influences a medical device. The classification record should start with intended purpose and patient benefit, then show whether the software supports diagnosis or therapy decisions, monitors physiological processes, or falls into the residual class I branch.

## Decide whether the software is medical device software

Start with the MDR Article 2(1) medical device definition and the manufacturer's intended purpose. The MDR expressly includes software when it is intended for medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation, investigation, replacement, modification, or providing information by in vitro examination of human specimens.

MDCG 2019-11 narrows the practical test: software must have a medical purpose on its own to qualify as medical device software. The same guidance says hosting location does not decide the question; cloud software, mobile apps, desktop software, and software embedded in a hardware device can all qualify if the intended purpose and function meet the medical-device test.

Exclude functions that merely store, archive, communicate, compress without loss, or perform simple search unless the software also processes, analyses, creates, or modifies medical information for a medical intended purpose. Separately record any software that drives or influences a hardware medical device because it may be covered as a part, component, or accessory even if it does not have its own medical purpose.

- Evidence input: intended purpose from labels, instructions for use, promotional statements, product requirements, clinical evaluation scope, and release notes.
- Qualification decision: medical device software, software driving or influencing a device, accessory software, IVDR software, Annex XVI-related software, or out-of-scope operational software.
- Non-qualifying examples to document carefully: invoicing, staff planning, messaging, backup, simple search, unmodified storage, and administrative dashboards without a medical intended purpose.

Sources for this answer:

- [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Article 2(1) includes software in the medical device definition when the manufacturer intends it for specified medical purposes.
- [MDCG 2019-11 - Qualification and classification of software](https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_en_0.pdf?ref=sorena.io) - Explains medical device software qualification, non-qualifying simple software functions, software location, and software that drives or influences a device.

## Apply the Rule 11 classification branches

For qualified MDR medical device software, apply Rule 11 by function and foreseeable decision impact. Software that provides information used for diagnosis or therapeutic decisions starts at class IIa, but moves to class III when those decisions may cause death or irreversible deterioration of health, and to class IIb when they may cause serious deterioration of health or surgical intervention.

Software intended to monitor physiological processes is class IIa. It becomes class IIb when it monitors vital physiological parameters and the nature of variation could create immediate danger to the patient. All other Rule 11 software is class I, unless another Annex VIII rule or implementing rule produces a higher class.

MDCG 2021-24 warns that software is an active device and should not be reviewed only in the context of Rule 11. Keep a short cross-check for active therapeutic, diagnosis and monitoring, closed-loop, and hardware-control rules when the software controls therapy, influences a class IIb active therapeutic device, monitors an active implantable device, or significantly determines patient management.

- Diagnosis or therapy branch: name the decision, decision-maker, patient condition, data inputs, software output, and the harm scenario if the output is wrong or unavailable.
- Physiological monitoring branch: identify the physiological process, whether it is vital, and whether variations could immediately endanger the patient.
- Residual branch: explain why the software is still qualified as medical device software but does not provide decision information or monitor physiological processes within the higher branches.

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 VIII Rule 11 sets the class IIa, IIb, III, and residual class I outcomes for MDR software.
- [MDCG 2021-24 - Guidance on classification of medical devices](https://health.ec.europa.eu/system/files/2021-10/mdcg_2021-24_en_0.pdf?ref=sorena.io) - Classification guidance notes that software is an active device and should not be assessed only under Rule 11.

*Recommended next step*

*Placement: after implementation section*

## Review a Rule 11 software classification file

Check the intended purpose, software qualification, Rule 11 branch, conformity route, clinical evidence, and change-control evidence before release.

- [Open Research Copilot](/solutions/research-copilot.md): Answer MDR software classification and evidence questions with cited outputs.
- [Talk through implementation](/contact.md): Review your Rule 11 rationale, route decision, and clinical-evidence plan.

## Connect the software class to the conformity route

Rule 11 classification changes the market route. Class IIa, class IIb, and class III software require notified-body involvement under MDR Article 52. Class III software follows Annex IX or Annex X plus Annex XI. Class IIb software follows Annex IX with technical documentation assessed for at least one representative device per generic device group. Class IIa software follows Annex IX with technical documentation assessed for at least one representative device for each category of devices.

Class I software can generally be self-declared after the manufacturer draws up Annex II and Annex III technical documentation and issues the EU declaration of conformity, unless another class I feature requiring notified-body involvement applies. A Rule 11 record should therefore state both the resulting class and the conformity assessment consequence, not only the rule label.

For software that drives or influences a hardware device, keep the software classification rationale aligned with the hardware device route. If the software changes the operation, output, risk controls, alarms, therapy delivery, or diagnostic information of another device, the conformity route discussion belongs in the combined device file.

- Route fields: class, Annex VIII rule branch, notified-body involvement, technical-documentation sampling basis, certificate scope, and declaration of conformity impact.
- Release gate: block market-release decisions that cite Rule 11 without identifying the Article 52 route and the technical-documentation package affected by the software version.
- Procurement and audit evidence: keep the classification memo, conformity route memo, notified-body correspondence, technical-documentation index, and software release identifier together.

Sources for this answer:

- [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Article 52 links class I, IIa, IIb, and III devices to the applicable conformity assessment procedures and notified-body involvement.
- [European Commission - notified bodies for medical devices](https://health.ec.europa.eu/medical-devices-topics-interest/notified-bodies-medical-devices_en?ref=sorena.io) - Commission overview explains that notified bodies assess conformity where third-party intervention is required.

## Build clinical and performance evidence around the software claim

A Rule 11 classification record is not enough to support medical claims. MDR Article 61 requires conformity with relevant general safety and performance requirements, benefit-risk acceptability, and undesirable side-effect evaluation to be based on clinical data providing sufficient clinical evidence. The manufacturer must specify and justify the level of clinical evidence needed for the device characteristics and intended purpose.

For decision-support or monitoring software, the clinical evaluation should tie the algorithm, data inputs, output, target users, patient population, clinical workflow, and claimed clinical benefit to evidence. MDCG 2020-6 describes clinical evaluation as a lifecycle process and highlights the need to incorporate PMS and PMCF data into the clinical evaluation.

When software changes, update the evidence question before release. New or modified algorithms, changed presentation of medical data, closed-loop replacement of user input, new diagnostic or therapeutic features, or new interoperability channels can affect safety, performance, classification, clinical evaluation, and notified-body handling.

- Clinical evaluation inputs: intended purpose, indications, contraindications, target groups, clinical benefit, alternatives, data appraisal, risk management links, verification and validation, and PMS or PMCF outputs.
- Software evidence inputs: versioned requirements, architecture, data set description, model or algorithm validation, cybersecurity and usability controls, verification results, known limitations, and release risk assessment.
- Change evidence inputs: algorithm change rationale, affected claims, affected diagnostic or therapeutic decisions, vital-parameter monitoring impact, clinical or usability data need, notified-body notification result, and updated technical documentation.

Sources for this answer:

- [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Article 61 and Annex XIV require clinical evaluation, sufficient clinical evidence, justified evidence level, lifecycle updates, and documentation in the technical file.
- [MDCG 2020-6 - Clinical evidence for legacy devices](https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2020_6_guidance_sufficient_clinical_evidence_en.pdf?ref=sorena.io) - Guidance supports clinical-evidence planning, lifecycle clinical evaluation, PMS and PMCF incorporation, and justification of sufficient evidence.
- [MDCG 2020-3 - Significant changes under MDR transitional provisions](https://health.ec.europa.eu/system/files/2023-05/mdcg_2020-3_en.pdf?ref=sorena.io) - Software change chart identifies algorithm, architecture, closed-loop, diagnostic or therapeutic feature, interoperability, and medical-data presentation changes that can be significant.

## Primary sources

- [Regulation (EU) 2017/745 on medical devices](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary MDR source for the medical device definition, Rule 11 classification, Article 52 conformity assessment routes, Article 61 clinical evaluation, and technical-documentation requirements.
  - Quote: "Software intended to provide information"
- [MDCG 2019-11 - Qualification and classification of software](https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_en_0.pdf?ref=sorena.io) - Guidance used for medical device software qualification, non-qualifying simple software functions, software location, software driving or influencing a device, and Rule 11 interpretation.
  - Quote: "Medical device software is software"
- [MDCG 2021-24 - Guidance on classification of medical devices](https://health.ec.europa.eu/system/files/2021-10/mdcg_2021-24_en_0.pdf?ref=sorena.io) - Guidance used for Annex VIII classification context, active-device cross-checks, and the warning that software should not be reviewed only under Rule 11.
  - Quote: "Software is also an active device"
- [MDCG 2020-6 - Clinical evidence for legacy devices](https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2020_6_guidance_sufficient_clinical_evidence_en.pdf?ref=sorena.io) - Guidance used for lifecycle clinical evaluation, sufficient clinical evidence, PMS and PMCF incorporation, and evidence-level justification.
  - Quote: "sufficient clinical evidence"
- [MDCG 2020-3 - Significant changes under MDR transitional provisions](https://health.ec.europa.eu/system/files/2023-05/mdcg_2020-3_en.pdf?ref=sorena.io) - Guidance used for software change-control evidence, including architecture, algorithm, closed-loop, interoperability, diagnostic or therapeutic feature, and medical-data presentation changes.
  - Quote: "New or modified architecture"
- [European Commission - notified bodies for medical devices](https://health.ec.europa.eu/medical-devices-topics-interest/notified-bodies-medical-devices_en?ref=sorena.io) - Commission source used for the role of notified bodies when MDR conformity assessment requires third-party involvement.
  - Quote: "assess the conformity of certain products"

## Related Topic Guides

- [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.
- [EU MDR Annex II and III Technical Documentation](/artifacts/eu/medical-device-regulation/annex-ii-and-iii-technical-documents.md): Build an MDR technical documentation index for Annex II device files and Annex III post-market surveillance evidence, including GSPR, risk, clinical, PMS, UDI, and EUDAMED records.
- [EU MDR Annex VIII Classification Guide](/artifacts/eu/medical-device-regulation/annex-viii-classification.md): Classify EU MDR medical devices under Annex VIII using intended purpose, duration, invasiveness, active device and software rules, and conformity assessment impact.
- [EU MDR Annex XVI products without a medical purpose](/artifacts/eu/medical-device-regulation/annex-xvi-products.md): source-linked EU MDR guide for Annex XVI products: listed product groups, common specifications, clinical evidence, notified-body route, UDI, EUDAMED, PMS, and vigilance evidence before launch.
- [EU MDR Applicability Test](/artifacts/eu/medical-device-regulation/applicability-test.md): Test whether a product, accessory, software function, or Annex XVI product falls under the EU Medical Device Regulation, and record the evidence for the next classification step.
- [EU MDR change assessment workflow](/artifacts/eu/medical-device-regulation/change-assessment-workflow.md): Assess EU MDR device, design, software, intended purpose, QMS, clinical, PMS, UDI, classification, and notified-body impacts before releasing a medical device change.
- [EU MDR Checklist for Medical Device Compliance](/artifacts/eu/medical-device-regulation/checklist.md): Practical EU MDR checklist covering qualification, classification, conformity assessment, technical documentation, GSPR, clinical evidence, UDI, EUDAMED, PMS, vigilance, QMS, and legacy transition evidence.
- [EU MDR classification workflow](/artifacts/eu/medical-device-regulation/classification-workflow.md): A concrete EU MDR classification workflow for intended purpose, device or accessory qualification, Annex VIII rule selection, Rule 11 software review, class outcome, and notified body impact.
- [EU MDR Clinical Evaluation Overview](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): EU MDR clinical evaluation overview covering Article 61, Annex XIV, clinical data sources, equivalence, PMCF, CER evidence, notified body review, GSPR, and benefit-risk support.
- [EU MDR Clinical Evaluation Report Template](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A source-linked EU MDR clinical evaluation report template covering intended purpose, GSPR linkage, clinical data appraisal, equivalence limits, PMCF, conclusions, and reviewer signoff.
- [EU MDR clinical evidence guide](/artifacts/eu/medical-device-regulation/clinical-evidence.md): source-linked EU MDR guide to clinical evaluation, clinical investigations, equivalence, PMCF, GSPR support, technical documentation, and notified-body review.
- [EU MDR compliance obligations](/artifacts/eu/medical-device-regulation/compliance.md): EU MDR compliance guide for device qualification, classification, conformity assessment, QMS, technical documentation, UDI, EUDAMED, PMS, vigilance, and legacy transition controls.
- [EU MDR conformity route workflow](/artifacts/eu/medical-device-regulation/conformity-route-workflow.md): source-linked EU MDR workflow for classifying a device, choosing the conformity assessment route, preparing technical and QMS evidence, and reaching certificate, DoC, UDI, EUDAMED, and CE outputs.
- [EU MDR deadlines and compliance calendar](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): Grounded EU MDR calendar for application, legacy-device transition, UDI, EUDAMED, and recurring QMS, technical documentation, clinical, PMS, vigilance, certificate, and change reviews.
- [EU MDR Device Classification Guide](/artifacts/eu/medical-device-regulation/device-classification-guide.md): Classify an EU MDR medical device by intended purpose, Annex VIII duration, invasiveness, active-device and software rules, then document the conformity route impact.
- [EU MDR EUDAMED and UDI registration](/artifacts/eu/medical-device-regulation/eudamed-and-udi.md): source-linked MDR guide to Basic UDI-DI, UDI-DI, EUDAMED device registration, actor roles, labels, technical documentation, and UDI data governance.
- [EU MDR FAQ: qualification, evidence, UDI, and transition](/artifacts/eu/medical-device-regulation/faq.md): 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 Legacy Device Transition](/artifacts/eu/medical-device-regulation/legacy-device-transition.md): source-linked EU MDR legacy device transition guide covering Regulation (EU) 2023/607 conditions, certificate validity, significant-change limits, surveillance, PMS, vigilance, QMS, and evidence records.
- [EU MDR notified body route selection](/artifacts/eu/medical-device-regulation/notified-body-route-selection.md): Choose an EU MDR conformity assessment route by device class, Article 52 option, notified body designation scope, QMS readiness, technical documentation, clinical evidence, and certificate evidence.
- [EU MDR penalties and enforcement risk](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): source-linked EU MDR penalties and enforcement-risk guide covering Article 113, Member State penalty rules, market restrictions, recalls, certificate consequences, and evidence.
- [EU MDR PMS and Vigilance Guide](/artifacts/eu/medical-device-regulation/pms-and-vigilance.md): EU MDR guide to post-market surveillance, PMCF updates, PMS reports, PSURs, serious incident reporting, FSCA/FSN handling, trend reporting, and evidence records.
- [EU MDR PMS and vigilance records](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): source-linked EU MDR guide to PMS plans, PMS reports, PSURs, PMCF updates, serious incident and FSCA reporting, trend reporting, and EUDAMED evidence handling.
- [EU MDR PMS Plan Template for Medical Devices](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A source-linked EU MDR post-market surveillance plan template covering device scope, PMS data sources, PMCF linkage, vigilance, trend reporting, PMSR or PSUR outputs, roles, cadence, and evidence records.
- [EU MDR QMS and technical file evidence map](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): Map EU MDR Article 10 QMS duties to Annex II and Annex III technical documentation, PMS, vigilance, UDI records, and notified-body review evidence.
- [EU MDR QMS requirements under Article 10](/artifacts/eu/medical-device-regulation/qms.md): EU MDR QMS guide for Article 10 manufacturer controls covering regulatory strategy, design, risk, clinical evaluation, PMS, vigilance, UDI, suppliers, CAPA, and conformity records.
- [EU MDR qualification and borderline products](/artifacts/eu/medical-device-regulation/qualification-and-borderline-products.md): EU MDR qualification guide for medical purpose claims, accessories, software, Annex XVI products, and borderline routes to classification and conformity assessment.
- [EU MDR qualification workflow](/artifacts/eu/medical-device-regulation/qualification-workflow.md): A concrete EU MDR workflow for deciding whether a product is a medical device, accessory, Annex XVI product, IVD interface, medicinal-product interface, or non-MDR product before classification and conformity assessment.
- [EU MDR requirements checklist](/artifacts/eu/medical-device-regulation/requirements.md): Concrete EU MDR requirements for medical-device scope, classification, GSPR, conformity assessment, technical documentation, QMS, clinical evidence, UDI, EUDAMED, PMS, vigilance, and economic-operator records.
- [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.
- [EU MDR Transition Timelines: practical guide](/artifacts/eu/medical-device-regulation/transition-timelines.md): EU Medical Device Regulation guide to Transition Timelines with scope decisions, owner actions, evidence records, source-linked citations, and practical next steps.
- [EU MDR UDI and EUDAMED registration guide](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): EU MDR guide to Basic UDI-DI, UDI-DI, UDI carriers, EUDAMED actor and device registration, change impacts, and evidence governance.
- [EU MDR vigilance reporting workflow](/artifacts/eu/medical-device-regulation/vigilance-reporting-workflow.md): Concrete EU MDR vigilance workflow for incident intake, serious incident assessment, FSCA and FSN handling, trend reporting, EUDAMED caveats, CAPA, PMS, clinical evaluation updates, and records.
- [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.
- [MDR vs AI Act for medical-device software](/artifacts/eu/medical-device-regulation/mdr-vs-ai-act.md): Compare MDR software qualification, classification, clinical evidence, QMS, PMS, UDI, EUDAMED, and notified-body evidence boundaries against cautiously scoped AI Act overlap.
- [MDR vs GPSR: medical-device boundary checks](/artifacts/eu/medical-device-regulation/mdr-vs-gpsr.md): Compare MDR medical-device scope with general product-safety fallback questions for borderline, non-medical, and Annex XVI products.
- [MDR vs IVDR: medical devices and IVDs compared](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): Compare EU MDR and IVDR scope, classification, conformity routes, technical documentation, clinical or performance evidence, UDI, EUDAMED, PMS, and vigilance.
- [MDR vs Product Liability Directive evidence comparison](/artifacts/eu/medical-device-regulation/mdr-vs-product-liability-directive.md): Compare EU MDR market-access evidence with Product Liability Directive exposure without treating compliance records as a liability outcome.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.
- [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.


---

[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/rule-11-software