Software als Me­di­zin­pro­dukt (SaMD) gemäß EU-MDR: Klas­si­fi­zie­rung und Zer­ti­fi­zie­rung, er­läu­tert

Besondere Merkmale der Software

Software unterscheidet sich in einem wesentlichen Punkt von herkömmlichen Medizinprodukten: Sie verändert sich rasant. Releases, Patches, Cloud-Umgebungen, Schnittstellen, KI-Funktionen und Cybersicherheitsrisiken sind natürliche Bestandteile ihres Lebenszyklus. Die MDR trägt dem Rechnung. Anhang I fordert für Software unter anderem einen modernen Ansatz für den Entwicklungszyklus, das Risikomanagement, die Verifizierung und Validierung sowie Mindestanforderungen an Hardware, IT-Netzwerke und den Schutz vor unberechtigtem Zugriff. Cybersicherheit ist somit kein sekundäres IT-Thema, sondern integraler Bestandteil der Produktsicherheit und -leistung.

Insbesondere bei Software kommt es nicht auf den Code an, sondern auf den medizinischen Zweck. Eine Wellness-App gilt nicht automatisch als medizinische Software, nur weil sie technisch komplex ist. Umgekehrt kann eine scheinbar einfache Anwendung durchaus unter die Medizinprodukteverordnung fallen, wenn ihre Informationen für diagnostische oder therapeutische Entscheidungen verwendet werden. aktuelle MDCG-Leitlinien Die Regelung zur Qualifizierung und Klassifizierung von Software verdeutlicht genau diese Unterscheidung.

Anforderungen der MDR – wo sind sie zu finden?

Wer Software unter den folgenden Bedingungen auf den Markt bringen möchte: MDR Sie sollten die entsprechenden Abschnitte der Verordnung sehr sorgfältig lesen. Die wichtigsten Abschnitte sind:

Anhang I Diese Richtlinie legt die allgemeinen Sicherheits- und Leistungsanforderungen fest. Für Software sind hierbei insbesondere die Anforderungen an den Entwicklungsprozess, das Risikomanagement, die Informationssicherheit, die Validierung und die IT-Umgebung relevant.

Anhang II Und Anhang III Sie regeln sowohl die technische Dokumentation als auch die Anforderungen an die Marktüberwachung. Bei Software umfasst dies auch den Nachweis der Softwareverifizierung und -validierung als Teil der Produktdokumentation.

Anhang VIII , insbesondere Regel 11 Die Klassifizierung medizinischer Software ist von zentraler Bedeutung. Die MDCG 2019-11 (überarbeitet 2025) erläutert die drei Grundprinzipien der Regel 11: Software, die Informationen für diagnostische oder therapeutische Entscheidungen bereitstellt; Software, die physiologische Prozesse überwacht; und „alle anderen Software“. Je nach klinischer Relevanz kann die Klassifizierung von Klasse I bis Klasse III reichen.

Artikel 52 Und Anhänge IX bis XI Beschreiben Sie die Konformitätsbewertung. Bei Medizinprodukten der Klasse I wird die Konformitätserklärung in der Regel vom Hersteller selbst ausgestellt; bei Medizinprodukten der Klasse IIa und höher ist die Beteiligung einer Benannten Stelle erforderlich.

Anhang XIV Schließlich ist sie die zentrale Referenz für die klinische Bewertung und die klinische Nachbeobachtung nach der Markteinführung (PMCF). Gerade bei Software ist dies ein Bereich, der systematisch oft zu spät etabliert wird.

Was kommt als Nächstes? Der von der EU-Kommission vorgeschlagene Entwurf zur Überarbeitung von Regel 11 (Dezember 2025). Am 16. Dezember 2025 veröffentlichte die Europäische Kommission einen Entwurf zur Änderung der Medizinprodukteverordnung (MDR), der Regel 11 überarbeiten würde. Erste Anzeichen deuten darauf hin, dass die Klasse I die Standardklassifizierung für Software von Medizinprodukten sein soll, sofern keine spezifischen Kriterien für ein höheres Risiko erfüllt sind. Dies ist eine Reaktion auf jahrelange Kritik, dass Regel 11 in ihrer jetzigen Form nahezu alle Software unabhängig vom tatsächlichen Risiko in die Klasse IIa oder höher einstuft.

Wichtig: Dies ist ein Entwurf, kein verabschiedetes Gesetz. Wie bereits bei früheren MDR-Änderungsdiskussionen kann sich der Text bis zur endgültigen Fassung noch ändern, falls er überhaupt verabschiedet wird. Hersteller sollten ihre Produkte weiterhin gemäß der geltenden Regel 11 und der MDCG-Leitlinie 2019-11 Rev. 1 einstufen und diesen Vorschlag aufmerksam verfolgen. DQS MED wird diesen Artikel im Verlauf des EU-Gesetzgebungsverfahrens aktualisieren.

Die wichtigsten Standards für medizinische Software

Die MDR legt die regulatorischen Anforderungen fest. In der praktischen Umsetzung sind jedoch einige Standards besonders wichtig, da sie den aktuellen Stand der Technik definieren.

IEC 62304 ist der Kernstandard für den Softwarelebenszyklus medizinischer Software. Er beschreibt Prozesse für die Entwicklung und Wartung von Software, wenn die Software selbst ein Medizinprodukt oder ein integraler Bestandteil eines Medizinprodukts ist.

ISO 14971 ist der Referenzstandard für das Risikomanagement von Medizinprodukten, einschließlich Software als Medizinprodukt.

ISO 13485 ist der zentrale Qualitätsmanagementstandard für Medizinprodukte über den gesamten Produktlebenszyklus hinweg. Für Hersteller, die eine robuste, MDR-konforme Organisation aufbauen möchten, dient er als praktische operative Grundlage.

IEC 62366-1 Es umfasst Usability Engineering. Dies ist insbesondere für Software relevant, da Fehlbedienungen, irreführende Benutzerhinweise oder unklare Warnmeldungen unmittelbare Sicherheitsrisiken bergen können.

IEC 82304-1 Dies gilt insbesondere für Gesundheitssoftware auf allgemeinen IT-Plattformen, d. h. für Produkte ohne dedizierte Hardware. Der Standard behandelt Sicherheit und Schutz auf Produktebene und ist daher von großer Bedeutung für viele eigenständige Softwareprodukte oder Software als Medizinprodukt (SaMD). Besonders hervorzuheben ist, dass IEC 82304-1 spezifische Anforderungen für die Validierung von SaMD definiert und gleichzeitig in IEC 62304 referenziert wird, die im Rahmen der MDR harmonisiert ist.

Klassifizierung: Der entscheidende erste Schritt

Die häufigste und wichtigste Ausgangsfrage lautet: In welche Klasse fällt meine Software? Genau hier scheitern viele Projekte – nicht an der Technologie, sondern an einem unklaren Zweck. Gemäß MDCG 2019-11 Rev. 1 wird Regel 11 im Wesentlichen danach angewendet, ob die Software Informationen für diagnostische oder therapeutische Entscheidungen liefert, physiologische Prozesse überwacht oder in die Restkategorie fällt. Beispiele in der Leitlinie zeigen, dass diagnostische oder therapieunterstützende Software schnell in die Klassen IIa, IIb oder III fallen kann, während „alle anderen Softwareprogramme“ der Klasse I zugeordnet werden.

Aus Sicht einer Benannten Stelle ist daher klar: Die Klassifizierung ist kein abschließender Verwaltungsschritt, sondern die Grundlage der gesamten Strategie für die Marktzulassung. Sie beeinflusst den Umfang der klinischen Evidenz, die Tiefe der technischen Dokumentation, die Anforderungen an das Arzneimittelmanagementsystem (PMS) und das Arzneimittelmanagement-Fortbildungsprotokoll (PMCF) sowie natürlich die Frage, ob und in welchem Umfang eine Benannte Stelle einbezogen werden muss.

Klinische Daten: Ohne klinische Evidenz funktioniert es nicht.

Für medizinische Software ist klinische Evidenz kein optionales Extra. MDCG 2020-1 legt ausdrücklich fest, dass medizinische Software mit einem definierten Zweck und einem beanspruchten klinischen Nutzen im Rahmen der Konformitätsbewertung klinische Evidenz erfordert. Ziel ist es, nachzuweisen, dass die Software sicher ist, die versprochene Leistung erbringt und den beanspruchten klinischen Nutzen liefert.

In der Praxis bedeutet dies für Software: Es genügt nicht, lediglich die technische Funktionsfähigkeit des Algorithmus nachzuweisen. Es muss auch beurteilt werden, ob die Software im klinischen Kontext die korrekten Informationen liefert, wie diese Informationen genutzt werden und ob sie tatsächlich einen nachweisbaren Nutzen bringt. Die klinische Evaluation ist kein einmaliges Dokument, sondern ein fortlaufender Prozess.

Klinische Nachbeobachtung nach der Markteinführung (PMCF)

PMCF wird im Softwarekontext oft unterschätzt. Die MDR definiert PMCF als einen kontinuierlichen Prozess, der die klinische Bewertung aktualisiert und im PMS-Plan des Herstellers verankert sein muss. Genau das ist es, was MDCG PMCF-Vorlage beschreibt es explizit.

PMCF ist insbesondere für Software von großer Bedeutung, da sich Nutzungskontexte, Betriebssysteme, Schnittstellen, Cyberbedrohungen und klinische Anwendungsmuster ständig verändern. Hersteller benötigen daher nicht nur eine solide Strategie für die Marktzulassung, sondern auch ein robustes System zur Erfassung und Auswertung von Leistungs- und Sicherheitsdaten aus der Praxis nach der Markteinführung, um diese in die Produktverbesserung einfließen zu lassen.

Wie funktioniert der Zertifizierungsprozess aus der Sicht einer Benannten Stelle?

Der Weg zur Zertifizierung lässt sich in sechs Schlüsselschritten zusammenfassen.

Erste: Der Verwendungszweck muss präzise definiert werden. Nur so lässt sich eindeutig feststellen, ob die Software unter die MDR fällt.

Zweite: Die Software muss korrekt klassifiziert werden – in der Regel auf Grundlage von Anhang VIII und Regel 11.

Dritte: Das Unternehmen benötigt ein angemessenes Qualitätsmanagementsystem und einen nachweisbaren, modernen Entwicklungsprozess, der typischerweise auf Folgendem basiert: ISO 13485 , IEC 62304, ISO 14971 und andere Normen, abhängig vom Produkt.

Vierte: Die technische Dokumentation muss vollständig, strukturiert und nachvollziehbar sein – einschließlich Softwareverifizierung und -validierung.

Fünfte: Die klinische Bewertung, das PMS und das PMCF müssen produktgerecht strukturiert sein.

Sechste: Ist für die Einstufung die Beteiligung einer Benannten Stelle erforderlich, erfolgt die formale Konformitätsbewertung nach den in der MDR festgelegten Verfahren.

Dieser Artikel wurde im September 2026 von Dr. Andrei Ninu, Benannter Experte für Software und KI im Gesundheitswesen und Leiter der Software Operations Group bei DQS MED, geprüft.