MDCG 2019-11 rev.1: Was die neue Version für medizinische und IVD-Software ändert

Seit 2019 ist der Leitfaden MDCG 2019-11 eine Referenz für Hersteller von Software für Medizinprodukte (MDSW) und In-vitro-Diagnostik-Software (IVD MDSW). In der Praxis ließ die erste Version jedoch viele Grauzonen: ungelöste Grenzfälle, mangelnde Klarheit in Bezug auf Softwaremodule und unterschiedliche Auslegungen von Regel 11.

Die überarbeitete Fassung, die am 17. Juni 2025 veröffentlicht wurde, geht weit über kosmetische Aktualisierungen hinaus. Sie bringt wesentliche konzeptionelle und operative Klarstellungen mit sich, wobei der Schwerpunkt auf dem Konzept der Zweckbestimmung, modularen Softwarestrukturen und den Wechselwirkungen mit anderen Vorschriften wie dem EHDS liegt.

In diesem Artikel werden die wichtigsten Änderungen aufgeschlüsselt, die konkreten Auswirkungen für Hersteller dargelegt und praktische Szenarien vorgestellt, die Ihnen bei der Anpassung Ihrer Produkte und technischen Unterlagen helfen.

1. Zur Erinnerung: Was deckt die MDCG 2019-11 ab?

Die Leitlinien konzentrieren sich auf zwei Kernkonzepte:

• Qualifizierung: Bestimmung, ob ein Softwareprodukt unter die MDR oder IVDR fällt und als Medizinprodukt oder Zubehör gilt.
• Klassifizierung: Zuweisung der geeigneten Risikoklasse für die Software auf der Grundlage ihrer Zweckbestimmung (insbesondere gemäß Regel 11 der MDR).

Es werden auch Sonderfälle behandelt:

• Software, die ein Medizinprodukt steuert oder beeinflusst,
• Unterscheidung zwischen MDSW und nichtmedizinischen Modulen,
• Software, die in der Cloud, auf mobilen Geräten oder eingebettet in Hardware eingesetzt wird.

Der Verwendungszweck ist von zentraler Bedeutung: Er bestimmt die Qualifikation, die Klassifizierung und die anwendbaren regulatorischen Anforderungen.

2. Was ändert sich mit Revision 1 (Juni 2025)

2.1 Eingeführte Klarstellungen

• Erweiterung des Anwendungsbereichs auf Software gemäß Anhang XVI (Produkte ohne medizinischen Zweck, z. B. ästhetische Geräte).
• Zweckbestimmung: Die Leitlinien betonen die Notwendigkeit einer klaren, präzisen und eindeutigen Zweckbestimmung - jede Funktion mit medizinischer Zielsetzung muss klinisch begründet werden.
• Modularer Ansatz: Das Dokument erkennt an, dass Software in Module aufgeteilt werden kann. Einige Module können MDSW sein, andere nicht. Der Hersteller muss:
• Die funktionalen Grenzen klar definieren,
• Wechselwirkungen dokumentieren,
• Nachweisen, dass nicht-medizinische Module die Sicherheit oder Leistung der medizinischen Module nicht beeinträchtigen.
• Interoperabilität mit EHR-Systemen: Der Leitfaden enthält die neuen Anforderungen des Europäischen Gesundheitsdatenraums (EHDS). Die Forderung nach Interoperabilität bringt zusätzliche Verpflichtungen mit sich.

2.2 Neue Beispiele

• Fälle von Software, die der Behandlung dient (insbesondere in den Bereichen psychische Gesundheit, Rehabilitation, Essstörungen).
• Therapeutische Software, die virtuelle Realität oder interaktive Spiele verwendet.
• Beispiele, bei denen nichtmedizinische Module für den Betrieb unerlässlich sind, aber nicht unter die MDR/IVDR fallen - sofern die Grenzen gut dokumentiert sind.
• Ein seltenes Beispiel für eine Software der Klasse I (App zur unterstützenden Kommunikation für Patienten mit Autismus oder Zerebralparese).

2.3 Klassifizierung und Regel 11

Das Dokument verdeutlicht die drei Unterregeln:

• 11a: Software, die Informationen liefert, die für diagnostische oder therapeutische Entscheidungen verwendet werden.
• 11b: Software zur Überwachung physiologischer Prozesse.
• 11c: Alle sonstige Software.

Es enthält auch eine hilfreiche Matrix, die auf dem Schweregrad der klinischen Situation und der Auswirkung der Software auf medizinische Entscheidungen basiert und sich am IMDRF-Rahmen orientiert.

3. Praktische Szenarien: Was dies für Sie bedeutet

Fall 1 - Modulare Rehabilitationssoftware

Ein Entwickler baut eine Rehabilitationsplattform, die Folgendes umfasst:

• Ein Virtual-Reality-Therapiemodul (MDSW),
• Ein administratives Tracking-Modul (nicht MDSW),
• Ein Modul zur Erfassung der Patientenbeteiligung.

Was Revision 1 besagt

• Jedes Modul muss separat bewertet werden.
• Das therapeutische Modul wird unter Regel 11 eingeordnet.
• Nicht-medizinische Module müssen dokumentiert und ihre Interaktion in der technischen Akte analysiert werden.

Fall 2 - Software, die mit einem EHR verbunden ist

Ein Entscheidungshilfe-Tool ist in ein zertifiziertes EHR-System integriert.

Was Revision 1 sagt

• Wenn der Hersteller Interoperabilität behauptet, ist auch die Einhaltung des EHDS erforderlich (Interoperabilitätsspezifikationen, Dokumentation, Cybersicherheit).
• Die MDR-Qualifikation allein reicht nicht mehr aus: Der Rechtsrahmen wird dual.

4. Häufig gestellte Fragen (FAQ)

1. Bleibt meine Software Klasse IIa, wenn ich den Algorithmus nicht geändert habe?

Nicht unbedingt. Was zählt, sind die Auswirkungen auf medizinische Entscheidungen. Auch ohne technische Änderungen kann sich Ihre regulatorische Position aufgrund der neuen Leitlinien ändern.

2. Kann ich nichtmedizinische Module als "außerhalb des Anwendungsbereichs" deklarieren?

Ja, aber nur, wenn Sie begründen können, dass sie keine Auswirkungen auf die Sicherheit oder Leistung des MDSW haben.

3. Hat das Cloud-Hosting Auswirkungen auf die Klassifizierung meiner Software?

Nein. Die Klassifizierung hängt vom Verwendungszweck ab, nicht von der technischen Bereitstellung. Es können jedoch zusätzliche Anforderungen gelten (Cybersicherheit, Rückverfolgbarkeit, Verfügbarkeit). Siehe auch: Neue Leitlinie MDCG 2025-4: Anforderungen an Software-Apps für Medizinprodukte auf Online-Plattformen.

4. Was ist, wenn ich meine Software mit einem EHR verbinden möchte?

Dann müssen Sie sowohl EHDS als auch MDR/IVDR einhalten. Ein spezielles Interoperabilitätsdossier ist erforderlich.

5. Meine Software wurde zuvor als nicht-MDSW eingestuft. Sollte ich sie neu qualifizieren?

Möglicherweise. Grenzfälle sind jetzt klarer geregelt und können nun als MDSW eingestuft werden.

5. Was Hersteller jetzt tun sollten

• Überprüfen Sie Ihren beabsichtigten Zweck mit der klinischen Ausrichtung.
• Stellen Sie Ihre Software-Architektur dar: Module, Datenflüsse, Schnittstellen.
• Requalifizieren Sie Grenzmodule im Lichte der neuen Beispiele.
• Aktualisieren Sie die technische Dokumentation: Begründung der Klassifizierung, Schnittstellenanalyse, EHDS-Konformität, falls zutreffend.
• Überprüfen Sie die Strategien für die klinische Bewertung/Leistungsbewertung für jedes Modul.

6. Schlussfolgerung

Dies ist mehr als nur eine geringfügige Aktualisierung: Sie konsolidiert den Interpretationsrahmen, klärt endlich einige seit langem bestehende Unklarheiten (Behandlungsansprüche, modulare Logik, Interoperabilität) und stärkt gleichzeitig die Forderung nach einer fundierten Begründung.

Dies wird den Herstellern Arbeit abverlangen, aber es bietet auch eine Chance: robustere, klarere und vertretbarere Softwarearchitekturen und technische Unterlagen zu erstellen.

Benötigen Sie strategische Unterstützung?

Bei CSDmed helfen wir Herstellern:

• Strukturierung ihres Verwendungszwecks und ihrer Software-Architektur,
• Software nach der MDR/IVDR-Logik zu klassifizieren,
• Anpassung an die MDR-, IVDR-, AIA- und EHDS-Anforderungen, ohne die Entwicklung übermäßig zu verkomplizieren

Entwickeln Sie ein Gesundheitssoftwareprodukt? Beginnen Sie mit der richtigen Grundlage. Lassen Sie uns darüber reden.