Besonderheiten von Software
Software unterscheidet sich von klassischen Medizinprodukten in einem zentralen Punkt: Sie verändert sich schnell. Releases, Patches, Cloud-Umgebungen, Schnittstellen, KI-Funktionen und Cybersecurity-Risiken gehören zum Lebenszyklus ganz selbstverständlich dazu. Die MDR trägt dem Rechnung. Für Software fordert Annex I unter anderem einen State-of-the-Art-Ansatz für Entwicklungslebenszyklus, Risikomanagement, Verifikation und Validierung sowie Mindestanforderungen an Hardware, IT-Netzwerke und Schutz gegen unbefugten Zugriff. Cybersecurity ist damit kein IT-Nebenthema, sondern Teil von Sicherheit und Leistung des Produkts.
Gerade bei Software entscheidet außerdem nicht der Code, sondern der medizinische Zweck. Eine Wellness-App bleibt keine Medizinsoftware, nur weil sie technisch komplex ist. Umgekehrt kann eine scheinbar einfache Anwendung sehr wohl unter die MDR fallen, wenn ihre Informationen für Diagnose- oder Therapieentscheidungen genutzt werden. Die aktuelle MDCG-Guidance zur Qualifizierung und Klassifizierung von Software konkretisiert genau diese Abgrenzung.
Anforderungen in der MDR – wo sind diese zu finden?
Wer Software nach MDR auf den Markt bringen will, sollte die relevanten Stellen der Verordnung sehr gezielt lesen. Die wichtigsten Fundstellen sind:
Annex I mit den allgemeinen Sicherheits- und Leistungsanforderungen. Für Software sind hier insbesondere Anforderungen an Entwicklungsprozess, Risikomanagement, Informationssicherheit, Validierung und IT-Umgebung relevant.
Annex II und III regeln die technische Dokumentation sowie die Anforderungen an Post-Market Surveillance. Für Software gehört dazu auch der Nachweis von Software-Verifikation und -Validierung als Teil der Produktdokumentation.
Annex VIII, insbesondere Regel 11, ist für die Klassifizierung von Medizinsoftware zentral. Die 2025 revidierte MDCG 2019-11 erläutert die drei Grundlogiken von Regel 11: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert; Software, die physiologische Prozesse überwacht; und „alle andere Software“. Je nach klinischer Relevanz kann die Einstufung von Klasse I bis Klasse III reichen.
Artikel 52 sowie Annex IX bis XI beschreiben die Konformitätsbewertung. Für Klasse-I-Produkte erfolgt die Konformitätserklärung grundsätzlich durch den Hersteller selbst; für Klasse IIa und höher ist die Einbindung einer Benannten Stelle erforderlich.
Annex XIV schließlich ist die zentrale Fundstelle für klinische Bewertung und Post-Market Clinical Follow-Up (PMCF). Gerade bei Software ist das ein Bereich, der oft zu spät systematisch aufgebaut wird.
Die wichtigsten Standards für Medizinsoftware
Die MDR nennt die regulatorischen Anforderungen. In der praktischen Umsetzung sind jedoch einige Standards besonders wichtig, weil sie den „State of the Art“ konkretisieren.
IEC 62304 ist der Kernstandard für den Software-Lebenszyklus von Medizinsoftware. Er beschreibt Prozesse für Entwicklung und Wartung von Software, wenn Software selbst Medizinprodukt ist oder integraler Bestandteil eines Medizinprodukts.
ISO 14971 ist der Referenzstandard für das Risikomanagement von Medizinprodukten, ausdrücklich einschließlich Software as a Medical Device.
ISO 13485 ist der zentrale Qualitätsmanagementstandard für Medizinprodukte über den gesamten Produktlebenszyklus hinweg. Für Hersteller, die eine belastbare MDR-Organisation aufbauen wollen, ist er praktisch die operative Grundlage.
IEC 62366-1 deckt Usability Engineering ab. Das ist für Software besonders relevant, weil Fehlbedienung, missverständliche Benutzerführung oder unklare Alarme unmittelbare Sicherheitsfolgen haben können.
IEC 82304-1 ist besonders relevant für Health Software auf allgemeinen IT-Plattformen, also für Produkte ohne dedizierte Hardware. Der Standard adressiert Safety und Security auf Produktebene und ist daher für viele Standalone-Softwareprodukte beziehungsweise Software as a Medical Device (SaMD) von hoher Bedeutung. Besonders hervorzuheben ist, dass IEC 82304-1 konkrete Anforderungen an die Validierung von SaMD definiert und gleichzeitig in der IEC 62304 referenziert wird, die unter der MDR harmonisiert ist.
Klassifizierung: Der entscheidende erste Schritt
Die häufigste und wichtigste Einstiegsfrage lautet: Welche Klasse hat meine Software? Genau hier scheitern viele Projekte nicht an der Technologie, sondern an einer unklaren Zweckbestimmung. Nach MDCG 2019-11 Rev.1 wird Regel 11 im Kern danach angewendet, ob die Software Informationen für Diagnose- oder Therapieentscheidungen liefert, physiologische Prozesse überwacht oder in die Restkategorie fällt. Beispiele in der Guidance zeigen, dass diagnostische oder therapieunterstützende Software schnell in Klasse IIa, IIb oder III rutschen kann, während „alle andere Software“ Klasse I ist.
Aus Sicht einer Benannten Stelle ist deshalb klar: Die Klassifizierung ist kein administrativer Schritt am Ende, sondern die Grundlage für die gesamte Zulassungsstrategie. Sie beeinflusst Umfang der klinischen Evidenz, Tiefe der technischen Dokumentation, PMS/PMCF-Anforderungen und natürlich die Frage, ob und in welchem Umfang eine Benannte Stelle eingebunden werden muss.
Klinische Daten: Ohne klinische Evidenz geht es nicht
Für Medizinsoftware ist klinische Evidenz kein „Nice to have“. Die MDCG 2020-1 stellt ausdrücklich klar, dass Medizinsoftware mit eigener Zweckbestimmung und beanspruchtem klinischem Nutzen klinische Evidenz im Rahmen ihrer Konformitätsbewertung benötigt. Ziel ist zu belegen, dass die Software sicher ist, ihre Leistung erreicht und den beanspruchten klinischen Nutzen liefert.
Bei Software bedeutet das in der Praxis: Es reicht nicht, nur zu zeigen, dass der Algorithmus technisch funktioniert. Bewertet werden muss auch, ob die Software im klinischen Kontext die richtigen Informationen liefert, wie diese genutzt werden und ob daraus tatsächlich ein nachweisbarer Nutzen entsteht. Die klinische Bewertung ist dabei kein einmaliges Dokument, sondern ein fortlaufender Prozess.
Post-Market Clinical Follow-Up (PMCF)
PMCF wird bei Software häufig unterschätzt. Die MDR versteht PMCF als kontinuierlichen Prozess, der die klinische Bewertung aktualisiert und im PMS-Plan des Herstellers verankert sein muss. Genau das beschreibt auch das MDCG-PMCF-Template ausdrücklich.
Für Software ist PMCF besonders wichtig, weil sich Nutzungskontexte, Betriebssysteme, Schnittstellen, Cyber-Bedrohungen und klinische Einsatzmuster laufend verändern. Hersteller brauchen daher nicht nur eine gute Zulassungsstrategie, sondern auch ein belastbares System, um reale Leistungs- und Sicherheitsdaten nach Markteinführung zu erfassen, auszuwerten und in Produktverbesserungen zurückzuführen.
Wie läuft die Zertifizierung aus Sicht einer Benannten Stelle ab?
Der Weg zur Zertifizierung lässt sich auf sechs Kernschritte verdichten.
Erstens: Die Zweckbestimmung muss präzise definiert werden. Nur so lässt sich sauber entscheiden, ob die Software unter die MDR fällt.
Zweitens: Die Software muss korrekt klassifiziert werden – in der Regel anhand von Annex VIII und Regel 11.
Drittens: Das Unternehmen braucht ein passendes Qualitätsmanagement und einen nachweisbaren Entwicklungsprozess nach dem Stand der Technik, typischerweise gestützt auf ISO 13485, IEC 62304, ISO 14971 und je nach Produkt weitere Normen.
Viertens: Die technische Dokumentation muss vollständig, strukturiert und nachvollziehbar sein – inklusive Software-Verifikation und -Validierung.
Fünftens: Klinische Bewertung, PMS und PMCF müssen produktgerecht aufgebaut sein.
Sechstens: Wenn die Klassifizierung die Einbindung einer Benannten Stelle erfordert, folgt die formale Konformitätsbewertung nach den in der MDR vorgesehenen Verfahren.
