MDR — medical devices and SaMD (Reg. EU 2017/745)

The MDR (EU Regulation 2017/745, active since May 2021 with transition periods until 2028) establishes the General Safety and Performance Requirements (GSPR, Annex I) for medical devices in the EU. An AI system for diagnosis or clinical decision support that makes or recommends medical decisions is a Software as a Medical Device (SaMD) subject to MDR.

MDR is positive law, not an AI Act harmonised standard

MDR is a binding regulation with its own notified body (NB) certification pathway. It does not grant presumption of conformity with the EU AI Act (Arts. 40/41). The engine models it as a separate sectorial catalogue — its standard_info("eu/mdr@2017") returns None by design, exactly like DORA. MDR and the AI Act are stacked layers: the AI Act governs the high-risk lifecycle; MDR governs the medical device product certification.

The emerging AI-in-medicine layer is not yet harmonised

AI-specific medical device frameworks (GMLP, BS-AAMI 34971, IEC 63450, IEC 63521) are not yet harmonised under MDR. The engine treats them as emerging guidance, not as a source of presumption.

---

Per-system scope: what part of MDR the engine governs

The engine covers only the governable per-system slice of the SaMD: performance by subgroup, software V&V, residual risk management, SOUP inventory (software of unknown provenance, IEC 62304), and post-market monitoring of the model. This layer stacks on top of the already-governed AI Act layer (ISO 23894 + prEN 18283 for bias) without duplicating logic.

Out of per-system scope (honestly declared gaps): ISO 13485 QMS, full clinical evaluation (Annex XIV), notified body (NB) assessment, organisational PMS (Arts. 83-86), and continuous CVE monitoring of SOUP in production.

---

Clause catalogue

The file crates/froga-core/resources/standards/mdr-clauses.yaml declares the modelled clauses. The identifiers are semantic (mdr.*) and anchored in the public articles/annexes of the Regulation (Annex I GSPR, Art. 84/Annex XIV-B PMS/PMCF).

GSPR — General Safety and Performance Requirements (Annex I)

Clause	Short title	GSPR anchor	satisfied_by
mdr.gspr-1-safety-performance	Safety and performance per the intended purpose: aggregate SaMD residual acceptable against the declared criterion (does not judge full clinical benefit-risk)	GSPR 1	criterion: overall_residual
mdr.gspr-3-risk-management	Risk management system: hazards identified with likelihood and impact over the lifecycle (anchors ISO 14971)	GSPR 3	criterion: risk_estimation
mdr.gspr-4-risk-control	Risk control in priority order: inherently safe design → protective measures → information	GSPR 4	criterion: control_hierarchy
mdr.gspr-8-residual-risk	Acceptable residual risk after control measures (per-system)	GSPR 5/8	criterion: residual_present
mdr.gspr-17-1-performance	Software for SaMD repeatability, reliability and performance by subgroup/scanner	GSPR 17.1	measures_citing: true
mdr.gspr-17-2-sw-lifecycle	Software conforming to the state of the art: IEC 62304 lifecycle, V&V and data governance	GSPR 17.2	measures_citing: true
mdr.gspr-17-1-single-fault	Single-fault condition: risk reduction via HOTL supervision / blocking control	GSPR 17.1	measures_citing: true
mdr.gspr-23-information	Information supplied: intended purpose, limitations and affected persons identified	GSPR 23	evidence: affected_persons

PMS / PMCF — Post-Market Surveillance

Clause	Short title	Anchor	satisfied_by
mdr.pms-postmarket	Post-market surveillance of SaMD performance: declared monitoring plan	Art. 84 / Annex XIV-B	measures_citing: true, evidence: monitoring_plan

SOUP — IEC 62304 (inventory and risk of software of unknown provenance)

Clause	Short title	Anchor	satisfied_by
mdr.soup-inventory	SOUP inventory: components by name/version/purl in signed CycloneDX BOM	IEC 62304 §8.1.2 / GSPR 17.2	evidence: signed_bom
mdr.soup-requirements	SOUP functional/performance requirements and HW/SW prerequisites verified	IEC 62304 §5.3.3-5.3.4 / GSPR 17.2	measures_citing: true
mdr.soup-risk	SOUP failure risk analysis and evaluation of published anomalies/CVEs	IEC 62304 §7.1.2-7.1.3 / GSPR 3/17.2	measures_citing: true, evidence: monitoring_plan

---

How the satisfied_by model works

The mechanism is identical to the other sectorial catalogues:

• criterion: <name> — the clause is covered when the criterion (e.g. overall_residual, risk_estimation, control_hierarchy, residual_present) is satisfied in the signed bundle.
• measures_citing: true — the clause is covered when at least one signed measure cites it and its associated control passes. Without a citing measure, it emits GAP.
• evidence: <type> — the clause is covered when evidence of the indicated type is present: signed_bom (signed CycloneDX BOM), monitoring_plan, affected_persons.

The mapping to Annex I GSPR happens without rewriting the engine: the same criteria that satisfy ISO 23894 satisfy GSPR 3 (risk_estimation) and GSPR 4 (control_hierarchy).

---

Honest gaps

🟡 Partial — The engine covers the per-system slice of the SaMD. Full clinical evaluation, ISO 13485 QMS, and organisational PMS are out of scope by design. See Status & gaps.

mdr.soup-inventory / SOUP inventory: the engine certifies “signed CycloneDX BOM with purls present” (signed_bom). It does not certify “complete SOUP-list with software safety class per item” (IEC 62304 §4.3 — class A/B/C): that materialisation is done by the cloud plane. Without a signed BOM in the bundle, this clause is a GAP.

mdr.soup-requirements: without a citing measure that verifies the SOUP meets its functional and performance requirements, this clause is a GAP. The engine does not infer requirements from the purl.

mdr.soup-risk / CVE: the engine certifies that a measure or plan exists to channel anomaly evaluation. It does not consume CVE/NVD feeds in real time; it certifies the declared plan, not the ongoing operational review of published vulnerabilities.

Full clinical benefit-risk (GSPR 1): satisfying mdr.gspr-1-safety-performance verifies that the system’s aggregate residual is acceptable against the declared criterion. It does not judge the full clinical benefit-risk or the indication/contraindication decision, which belongs to the clinical evaluation (MDR Annex XIV).

AI Act Art. 72 post-market: EU AI Act Art. 72 (post-market monitoring for high-risk AI systems) is cited as eu/ai-act@2024#art-72 — not as MDR — because it is an AI Act obligation, not an MDR obligation.

---

How to use froga conformance with MDR

# Evaluate the per-system MDR slice (GSPR + SOUP) from the signed bundle
froga conformance --standard eu/mdr@2017

# With history per RDD iteration
froga conformance --standard eu/mdr@2017 --history

# Export to .froga/conformance/
froga conformance --standard eu/mdr@2017 --out

The report emits COVERED / PARTIAL / GAP per clause, grouped by phase (GSPR risk management, software lifecycle, SOUP, post-market).

---

Relation to other standards

• ISO 23894 — the risk management process underlying the engine; risk_estimation and control_hierarchy are the primary criteria satisfying GSPR 3 and GSPR 4. See ISO 23894.
• prEN 18228 — the harmonised AI risk management standard (AI Act Art. 9); the MDR layer stacks on top of it. See prEN 18228.
• prEN 18283 (bias) — the bias/fairness catalogue (AI Act Art. 10); in medical SaMD, subgroup/scanner bias is an obligation under both the AI Act and GSPR 17.1. See prEN 18283.