Healthcare software and MDR: qualification, rule 11 and engineering evidence
What the development team should map before code: medical destination, MDCG 2019-11 rev.1, branches of rule 11, IEC 62304 and SOUP inventory — separate from the English-speaking MDR guide.
Ala Ben Aicha
Direct answer
Qualify the software before classifying it. MDCG 2019-11 rev.1 (June 17, 2025) operationalizes Article 2 and Rule 11. A user story is not a medical destination. This is not a notified body opinion.
The ticket is not the technical file
The English page SaMD under EU MDR carries out qualification, rule 11, 62304 and CE marking. This is the dev team contract : what engineering artifacts can to feed a file, and which ones are not. Associated service: HealthTech development, not a regulatory stamp.
Text: Regulation (EU) 2017/745. Guide: MDCG 2019-11 rev.1, published on June 17, 2025. If your copy is from October 2019, stop and reload. Rev.1 clarifies the destination, the modules, examples of processing, and adds a point of articulation with the DPI systems of the EHDS (annex I.c.1 of the guide): a DPI system is not automatically a device; an interpretation module can be.
Qualification before classification
Four tests, in this order (operational reading of the guide, not a substitute):
- Is this software ?
- Does it act on data beyond storage, archiving, simple communication or research?
- Is the action for the benefit of individual patients ?
- The destination does she enter into art. 2(1) (diagnosis, prevention, monitoring, prediction, prognosis, treatment, etc.)?
An appointment booking module that does not interpret anything generally remains out of qualification. A module that recommends therapeutic behavior must be evaluated separately, even if it lives in the same app. Rev.1 insists: write a destination clear, by function. “Our AI-powered platform” is not a destination.
Classification only starts if the qualification is positive. Rule 11 (Annex VIII) has nothing to say about non-device software.
Rule 11: branches, not a repo label
Paraphrase of Annex VIII, Rule 11 — other rules may apply; a product name does not classify:
| Branch | Class | Signal for the team | What it is not |
|---|---|---|---|
| Information used for diagnostic or therapeutic decisions, without the more serious consequences below | IIa | The majority of “help” CDS land here | “We are Class I because it’s SaaS” |
| These decisions can cause serious deterioration or surgery | IIb | The destination and potential harm matters | An IEC 62304 class |
| Death or irreversible deterioration | III | Rare; do not self-attribute it to “look serious” | A GitHub risk score |
| Monitoring of physiological processes | IIa | Monitoring ≠ vital alert | A wellness dashboard |
| Vital parameters whose variation can create an immediate danger | IIb | Define what parameter | A leisure heart rate widget |
| Other software in the rule | I | The exception, not the default | A way to avoid the notified body |
Class IIa and beyond: notified body. I'm not one. I do not estimate your evaluation times: it is not an SLA Commission.
IEC 62304 (software safety classes A/B/C) is a life cycle process, not a 1:1 mapping to I / IIa / IIb / III. You can have MDR IIa and 62304 class B software. Two boards, two owners.
Sprint matrix → proof (and what doesn't pass)
| Engineering artifact | What it can power | What it is not |
|---|---|---|
| Statement of destination versioned (intended purpose) | Art. 2(1), MDCG 2019-11 | A user story “as a clinician, I want…” |
| Qualification decision per module | Device/non-device boundary | A label ai about the Node service |
| Argued rule 11 branch | Annex VIII | A Slack vote |
| Inventory SOUP (npm, images, models) | IEC 62304 | npm audit all alone |
| Unique ID requirements → design → testing | 62304 + ISO 14971 | 80% Jest coverage |
| Risk analysis (severity × probability) | ISO 14971 | A CSV of 500 errors |
| Destination Change Log | Regulatory review | A marketing changelog |
SOUP: each npm package in the tree is, in the 62304 sense, software of unknown origin. The inventory (name, version, intended use, risk if the package lies, maintenance, CVE) is a deliverable. Dependabot helps sleep ; he does not write the evaluation.
Change the destination (“we add a sepsis score”) reopens qualification and classification, even if the Git diff fits into ten lines. The regulatory owner decides; the dev team does not “reclassify” into a ticket.
EHDS, IA, IVDR: other doors
- A DPI system under EHDS Chapter III can coexist with a SaMD module. Two audits, two files. See EHDS manufacturers.
- An AI model does not assign a class. TheAI Act is a separate regime.
- Software that acts on in vitro diagnostic data may fall under theIVDR (2017/746), not just the MDR.
What this page is not
It is not a qualification, not a classification, not a notified body opinion, not an ISO 13485 QMS, not a clinical evaluation report, not legal or clinical advice. I am not signing your EU declaration. Implementing Git traceability is not CE marking.
If you are building the software and need to connect requirements, interfaces and tests without claiming the stamp, this is the HealthTech development. For a bounded spike, use the contact with project intention.