Regulatorische Anforderungen an Medizinprodukte-Software nach MDR und IVDR

Software kann ein Medizinprodukt sein. Im Wesentlichen entscheidet die Zweckbestimmung darüber, ob eine App, ein Algorithmus oder ein eingebettetes Steuerprogramm unter die Europäische Verordnung über Medizinprodukte, (EU) 2017/745 (MDR) oder In-vitro-Diagnostika, (EU) 2017/746 (IVDR), fällt. Handelt es sich um eine Medizinprodukte-Software gemäß MDR oder IVDR, gelten dieselben grundlegenden Pflichten wie für Hardware, ergänzt um software-spezifische Anforderungen an Entwicklung, Nachweis und Überwachung.

Dieser Beitrag ordnet ein, wann Software als Medizinprodukt bzw. IVD gilt, wie sie klassifiziert wird und welche produktbezogenen Anforderungen über den Lebenszyklus zu erfüllen sind. Grundlage sind die Zweckbestimmung, die Klassifizierungsregeln und eine Reihe software-bezogener Normen, die den Stand der Technik abbilden.
 

Software als Medizinprodukt

Ausgangspunkt ist die Zweckbestimmung, also der vom Hersteller festgelegte Verwendungszweck. Ein Medizinprodukt liegt nach Art. 2 Abs. 1 MDR vor, wenn die Software einem der dort genannten medizinischen Zwecke dient, etwa Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten. Software, die diese Definition erfüllt, wird gemäß MDCG 2019-11 Rev. 1 als Medical Device Software (MDSW) bezeichnet. Zusätzlich sollte geprüft werden, ob Software als Zubehör eines Medizinprodukts gelten kann oder die Verwendung eines Medizinprodukts steuert bzw. beeinflusst. Auch solche Software kann regulatorisch relevant sein, selbst wenn sie nicht als eigenständige MDSW qualifiziert wird.

Die Leitlinie MDCG 2019-11 Rev.1 beschreibt, wie diese Prüfung praktisch abläuft. Die Kernaussage ist, dass nicht jede Software mit Gesundheitsbezug ein Medizinprodukt ist. Software, die Gesundheitsdaten ausschließlich speichert, archiviert, komprimiert oder unverändert weiterleitet, ist in der Regel kein Medizinprodukt. Auch Anwendungen für Verwaltung, Lifestyle oder Wellness fallen grundsätzlich nicht unter die MDR oder IVDR. Software, die Gesundheitsinformationen verarbeitet, unterliegt der Regulierung nur, wenn diese Verarbeitung unmittelbar einem medizinischen Zweck dient.

Bei Software mit Bezug zu elektronischen Gesundheitsakten, klinischen Informationssystemen oder interoperablen Gesundheitsdatenräumen sollten zusätzlich die Abgrenzung zur MDSW, Anforderungen an Interoperabilität, Datenqualität, Datenzugriff und Datenschutz sowie mögliche Wechselwirkungen mit dem European Health Data Space geprüft werden.
Entscheidend ist also die konkrete Funktion. Berechnet, interpretiert oder verknüpft eine Software Daten, so dass daraus Informationen für medizinische Entscheidungen entstehen, spricht das für eine Qualifizierung als Medizinprodukt. Reine Anzeige oder Weitergabe ohne eigene medizinische Aussage spricht dagegen.
 

Einordnung unter MDR oder IVDR

Steht fest, dass sich die Software als Medizinprodukt qualifiziert, folgt die Zuordnung zur richtigen Verordnung. Auch hier ist die Zweckbestimmung maßgeblich.

Software, die Informationen auf Grundlage von Daten aus In-vitro-Untersuchungen von Proben aus dem menschlichen Körper für einen IVDR-relevanten medizinischen Zwecke liefert, gilt als In Vitro Diagnostic Medical Device Software (IVD-MDSW) und fällt unter die IVDR. Ein Beispiel ist Software, die Laborwerte einer Blutprobe auswertet und ein Ergebnis mit diagnostischer Aussage erzeugt. Software mit anderem medizinischem Zweck, der nicht in den Anwendungsbereich der IVDR fällt, kann unter die MDR fallen, sofern sie die Definition eines Medizinprodukts nach Art. 2 Nr. 1 MDR erfüllt. Verarbeitet eine Software sowohl IVD-Untersuchungen als auch andere gesundheitsbezogene Daten, ist nach MDCG 2019-11 Rev.1 die Herkunft der für die medizinische Aussage entscheidenden Daten ausschlaggebend.

Diese Weichenstellung wirkt sich auf den gesamten weiteren Konformitätsweg aus, da MDR und IVDR unterschiedliche Klassifizierungsregeln, Konformitätsbewertungsverfahren und Nachweisanforderungen vorsehen.
 

Klassifizierung

Die Risikoklasse bestimmt das Konformitätsbewertungsverfahren und damit, ob eine Benannte Stelle einzubinden ist.

Unter der MDR erfolgt die Klassifizierung nach Anhang VIII. Für Software ist vor allem Regel 11 maßgeblich. Vereinfacht gilt: Software, die Informationen für Entscheidungen zu diagnostischen oder therapeutischen Zwecken liefert, ist mindestens Klasse IIa. Sie steigt in Klasse III, wenn die Entscheidung Tod oder eine irreversible Verschlechterung des Gesundheitszustands verursachen kann, und in Klasse IIb bei einer schwerwiegenden Verschlechterung oder einem chirurgischen Eingriff. Software zur Überwachung physiologischer Prozesse ist grundsätzlich Klasse IIa, bei vitalen Parametern mit unmittelbarer Gefahr Klasse IIb. In den übrigen Fällen verbleibt Software mit medizinischem Zweck in Klasse I. Regel 11 gilt als weit gefasst, weshalb viele MDSW in Klasse IIa oder höher fallen und eine Benannte Stelle benötigen.

Unter der IVDR richtet sich die Klassifizierung nach Anhang VIII IVDR mit den Klassen A bis D. IVD-MDSW wird grundsätzlich so eingestuft, wie es der Zweckbestimmung und dem zugehörigen diagnostischen Kontext entspricht. Eigenständige Software erhält eine eigene Einstufung nach den IVDR-Regeln 1 bis 7.
 

Besondere produktbezogene Anforderungen

Für Software gelten neben den allgemeinen grundlegenden Sicherheits- und Leistungsanforderungen (Anhang I MDR bzw. IVDR) mehrere software-spezifische Normen. Die Anwendung einschlägiger Normen ist grundsätzlich freiwillig. Soweit harmonisierte EN-Normen im Amtsblatt der EU gelistet sind, kann ihre Anwendung eine Vermutung der Konformität mit den jeweils abgedeckten grundlegenden Sicherheits- und Leistungsanforderungen begründen. Unabhängig davon bilden IEC 62304, IEC 62366-1, ISO 14971, IEC 82304-1 und einschlägige Cybersecurity-Normen den Stand der Technik ab und werden von Benannten Stellen in der Praxis erwartet.

Zentral ist der Software-Lebenszyklus nach IEC 62304. Die Norm verlangt einen strukturierten Prozess für Planung, Entwicklung, Wartung, Risikomanagement, Konfigurations- und Problemmanagement. Sie ordnet Software je nach möglichem Schaden bei Fehlfunktion in die Sicherheitsklassen A, B oder C ein. Mit steigender Klasse wachsen die Anforderungen an Dokumentation und Verifikation. Geltende Fassung ist IEC 62304:2006 einschließlich Amendment 1:2015. Eine zweite Edition, befindet sich derzeit noch im Entwurfsstadium.

Für die Bauform kann zwischen eigenständiger und eingebetteter Software unterschieden werden. Für Software, die nicht lediglich integraler Bestandteil eines konkreten medizinischen Geräts ist, kann IEC 82304-1 ergänzend relevant sein. Der früher dafür häufig verwendete Begriff ‚Standalone-Software‘ sollte unter MDR/IVDR nur noch erläuternd verwendet werden. Maßgeblich bleiben Zweckbestimmung, Funktion und regulatorische Rolle der Software. Die IEC 82304-1 formuliert produktbezogene Anforderungen an Gesundheitssoftware, etwa an Begleitdokumentation, Validierung und Marktphase, und ergänzt damit die prozessorientierte IEC 62304.

Ist Software Bestandteil eines medizinischen elektrischen Geräts oder Systems, ist zusätzlich IEC 60601-1 einschließlich der PEMS (Programmable Electrical Medical System)-Anforderungen zu berücksichtigen. Für andere aktive oder implantierbare Produkte können stattdessen spezifische Produkt- oder Sicherheitsnormen einschlägig sein.

Hinzu kommen die Gebrauchstauglichkeit nach IEC 62366-1, die nutzungsbezogene Risiken adressiert, sowie die Anforderungen an Cybersecurity. Für Letztere sind neben den softwarebezogenen Anforderungen aus Anhang I MDR/IVDR die Leitlinie MDCG 2019-16 Rev.1 und die Norm IEC 81001-5-1 wesentliche Bezugspunkte.

Die folgende Übersicht ordnet die Normen ihren Anwendungsfällen zu:

Weitere Pflichten im Lebenszyklus

Über Entwicklung und Konformitätsbewertung hinaus gelten fortlaufende Pflichten.

Hersteller müssen ein angemessenes Qualitätsmanagementsystem unterhalten. Für Software umfasst dies u.a. Entwicklungs- und Freigabeprozesse, Risikomanagement, Konfigurations- und Änderungsmanagement sowie Lieferanten- und SOUP/OTS-Komponentensteuerung. ISO 13485 ist hierfür die zentrale Norm.

Schließlich ist die klinische Bewertung nach Art. 61 und Anhang XIV MDR bzw. die Leistungsbewertung nach Art. 56 und Anhang XIII IVDR zu dokumentieren. Sie weist Sicherheit und Leistung der Software für ihre Zweckbestimmung nach.

Die technische Dokumentation nach Anhang II und III MDR/ IVDR muss den Konformitätsnachweis vollständig und nachvollziehbar abbilden, einschließlich der Software-Architektur, der Verifizierungs- und Validierungsnachweise sowie des Risikomanagements.

Nach dem Inverkehrbringen sind ein System zur Überwachung nach dem Inverkehrbringen (Post-Market Surveillance, PMS, Art. 83 bis 86 MDR bzw. Art. 78 bis 81 IVDR) sowie die klinische Nachbeobachtung (Post-Market Clinical Follow-up, PMCF) bzw. für IVD die Leistungsnachbeobachtung (Post-Market Performance Follow-up, PMPF) umzusetzen.

Eine software-typische Besonderheit ist das Änderungsmanagement. Updates und neue Versionen sind Änderungen und können nachweispflichtig sein. Ob eine Änderung als wesentlichgilt und damit die Benannte Stelle einzubinden ist, richtet sich nach Art und Umfang der Änderung. Ein dokumentierter Prozess zur Bewertung von Änderungen ist daher Teil eines belastbaren Software-Managements.
 

Angrenzende Regulierung: KI-Software

Enthält die Software Künstliche Intelligenz, ist zusätzlich der AI Act (Verordnung (EU) 2024/1689) relevant. MDSW mit KI-Funktion, die eine Konformitätsbewertung durch eine Benannte Stelle durchläuft und die Voraussetzungen des Art. 6 AI Act erfüllt, gilt als Hochrisiko-KI-System. Die entsprechenden Pflichten gelten ab dem 2. August 2028. Der AI Act verändert die MDR- oder IVDR-Klassifizierung nicht, sondern tritt als zusätzliche Ebene hinzu. Die Leitlinie MDCG 2019-11 Rev.1 hat hierfür den Begriff Medical Device Artificial Intelligence (MDAI) eingeführt. Unabhängig von der Einstufung als Hochrisiko-KI-System und den hierfür erst ab dem 2. August 2028 geltenden Anforderungen sind jedoch bestimmte Pflichten des AI Act, insbesondere Regelungen zu verbotenen KI-Praktiken sowie ausgewählte Transparenz- und KI-Kompetenzanforderungen, bereits zuvor anwendbar.
 

Praktische Vorgehensweise

• Zweckbestimmung präzise formulieren, da sie über Qualifizierung, Verordnung und Klasse entscheidet.
• Qualifizierung und MDR/IVDR-Zuordnung anhand der Zweckbestimmung und unter Berücksichtigung von MDCG 2019-11 Rev.1 dokumentiert herleiten.
• Risikoklasse bestimmen und daraus das Konformitätsbewertungsverfahren und die Notwendigkeit einer Benannten Stelle ableiten.
• Software-Prozesse früh an IEC 62304 ausrichten und die je nach Produktart passenden Normen (IEC 82304-1 oder IEC 60601-1) sowie Usability und Cybersecurity einbeziehen.
• Änderungs-, PMS- und PMCF/PMPF-Prozesse von Beginn an mitplanen und bei KI-Anteilen den AI Act berücksichtigen.

FAQ

Ist jede Gesundheits-App ein Medizinprodukt?

Nein. Maßgeblich ist die Zweckbestimmung. Apps für Lifestyle, Wellness oder reine Datenverwaltung sind in der Regel keine Medizinprodukte. Erst ein unmittelbarer medizinischer Zweck im Sinne der MDR/IVDR führt zur Einordnung als MDSW.

Woran erkenne ich, ob MDR oder IVDR gilt? 

An der Datengrundlage der medizinischen Aussage. Beruht diese auf In-vitro-Untersuchungen von Körperproben, gilt die IVDR. Bei anderem medizinischem Zweck greift die MDR.

Fällt Software oft in Klasse I? 
Eher selten. Regel 11 der MDR ist weit gefasst, sodass viele Software-Medizinprodukte mindestens Klasse IIa erreichen und eine Benannte Stelle benötigen. Die konkrete Einstufung hängt vom Einfluss auf medizinische Entscheidungen ab.

Muss ich IEC 62304 anwenden? 

Die Norm ist nicht rechtlich verpflichtend, gilt aber als Stand der Technik für Software-Lebenszyklusprozesse und wird von Benannten Stellen erwartet. Eine Abweichung müsste begründet werden.

Sind Software-Updates meldepflichtig?

Updates sind Änderungen und können nachweispflichtig sein. Ob eine Meldung an die Benannte Stelle erforderlich ist, hängt davon ab, ob es sich um eine wesentliche Änderung handelt. Ein dokumentierter Bewertungsprozess ist erforderlich.
 

Fazit

Medizinprodukte-Software unterliegt denselben grundlegenden Pflichten wie Medizinprodukte-Hardware, ergänzt um software-spezifische Anforderungen an Lebenszyklus, Gebrauchstauglichkeit, Cybersecurity und Nachweis. Ausgangspunkt ist stets die Zweckbestimmung, denn sie steuert Qualifizierung, Zuordnung zu MDR oder IVDR sowie Klassifizierung. Ein Ende 2025 vorgelegte MDR-Änderungsvorschlag kann die Klassifizierung von Software künftig verändern, ist derzeit aber noch im Entwurfsstadium. Eine frühzeitige, dokumentierte Einordnung reduziert das Risiko späterer Nacharbeiten im Konformitätsbewertungsverfahren.

Wenn Sie prüfen möchten, ob und wie Ihre Software reguliert ist, unterstützen wir Sie bei Qualifizierung, Klassifizierung und der Wahl des passenden Weges zum Marktzugang. Sprechen Sie uns gerne dazu an.

Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Sämtliche Inhalte wurden vor Veröffentlichung fachlich geprüft und werden regelmäßig auf Aktualität, Vollständigkeit und Richtigkeit überprüft. Trotz sorgfältiger Erstellung und Qualitätskontrolle können Fehler, Unvollständigkeiten oder zwischenzeitlich eingetretene Änderungen der Rechtslage nicht ausgeschlossen werden.