Softwarequalifizierung · MDR · IVDR
Ist Ihre Software ein Medizinprodukt, ein Zubehör oder keines von beidem?
Die Antwort beginnt mit der Zweckbestimmung und nicht mit der Plattform, dem Algorithmus oder der technischen Komplexität.
Derselbe Programmcode kann als Medizinproduktesoftware reguliert, als Zubehör bereitgestellt, in ein anderes Produkt integriert oder außerhalb von MDR und IVDR eingeordnet werden. Entscheidend ist, wofür der Hersteller die Software bestimmt und wie sie Informationen verarbeitet.
Qualifizierungsweg durchlaufen ↓Zweckbestimmung · Daten · Ergebnis
Herstellerangaben und tatsächliche Funktion prüfen
Zuerst Qualifizierung · dann Klassifizierung
Die kurze Antwort
Beginnen Sie mit dem Zweck der Software selbst
Software wird nicht deshalb reguliert, weil sie künstliche Intelligenz nutzt, Gesundheitsdaten verarbeitet oder neben einem Medizinprodukt betrieben wird. Sie fällt unter MDR oder IVDR, wenn ihre Zweckbestimmung und Funktion die jeweilige rechtliche Definition erfüllen.
01
Die erste Frage ist nicht die Risikoklasse #
Hersteller beginnen häufig mit der Frage, ob ihre Software der Klasse I, IIa, IIb oder III angehört. Diese Frage kommt zu früh.
Die Klassifizierungsregeln werden erst angewendet, nachdem die Software als Medizinprodukt oder In-vitro-Diagnostikum qualifiziert wurde. Zunächst muss festgelegt werden, was die Software tun soll und ob diese Zweckbestimmung unter MDR oder IVDR fällt.
Welche Aussagen macht der Hersteller?
Erfüllt die Software eine rechtliche Definition?
Produkt, Zubehör, Bestandteil oder keines davon?
Welche Regeln bestimmen die Risikoklasse?
Ein Risiko allein qualifiziert Software nicht als Medizinprodukt. Eine Cybersicherheitsanwendung kann erhebliche Risiken aufweisen, ohne einen medizinischen Zweck zu haben. Umgekehrt kann relativ einfache Software qualifizieren, wenn sie Informationen für eine medizinische Entscheidung bereitstellt.
Zuerst wird festgestellt, ob die Rechtsvorschriften gelten. Erst danach folgen Klasse und Konformitätsbewertungsverfahren.
02
Was gilt als medizinische Zweckbestimmung? #
Nach der MDR kann Software als Medizinprodukt qualifizieren, wenn der Hersteller sie dazu bestimmt, allein oder in Kombination für einen oder mehrere Zwecke der Medizinproduktedefinition verwendet zu werden.
Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung
Diagnose, Überwachung, Behandlung, Linderung oder Kompensierung
Untersuchung, Ersatz oder Veränderung der Anatomie oder eines physiologischen oder pathologischen Vorgangs oder Zustands
Empfängnisverhütung oder -förderung
Die Software muss einen eigenen medizinischen Zweck haben. Es genügt nicht, dass sie in einem Krankenhaus verwendet wird, Patientendaten speichert, mit einem Medizinprodukt verbunden ist oder allgemein die Gesundheitsversorgung unterstützt.
Die Zweckbestimmung ergibt sich aus der gesamten Produktdarstellung, einschließlich Kennzeichnung, Gebrauchsanweisung, Website, Verkaufsunterlagen, Benutzeroberfläche, technischer Dokumentation und den für Anwender verfügbaren Funktionen.
Eine Aussage wie „identifiziert Patienten mit erhöhtem Risiko einer klinischen Verschlechterung“ kann einen medizinischen Zweck begründen, selbst wenn das Produkt an anderer Stelle lediglich als Workflow-Plattform bezeichnet wird.
03
Was macht die Software mit den Daten? #
Die Art der Daten ist allein nicht entscheidend. Aussagekräftiger ist, was die Software mit den Daten macht und zu welchem Zweck.
Eine Qualifizierung als MDSW ist wahrscheinlicher, wenn die Software Daten über Speicherung, Archivierung, Kommunikation oder einfache Suche hinaus verarbeitet und die daraus entstehenden Informationen dem medizinischen Nutzen eines einzelnen Patienten dienen sollen.
Keine Interpretation oder medizinische Ausgabe wird erzeugt
Patientenspezifische Informationen werden für einen medizinischen Zweck verwendet
Die Verarbeitung kann Berechnungen, Vergleiche, Interpretationen sowie die Erzeugung oder Veränderung medizinisch relevanter Informationen umfassen. Dieselbe mathematische Operation kann je nach Zweckbestimmung zu einem anderen regulatorischen Ergebnis führen.
Eine einfache Suche in einer elektronischen Patientenakte erzeugt normalerweise keine medizinische Information. Eine Anwendung, die Patientendaten kombiniert und einen möglichen Schlaganfall erkennt, eine Insulindosis empfiehlt oder eine klinische Verschlechterung vorhersagt, kann dies hingegen tun.
04
Gilt die MDR oder die IVDR? #
Nicht jede medizinisch bestimmte Software fällt unter die MDR. Sie kann stattdessen MDSW nach IVDR sein, wenn sie die Definition eines In-vitro-Diagnostikums erfüllt.
Die Software erfüllt eine Funktion für einen Zweck, der von der Medizinproduktedefinition der MDR erfasst wird.
Die Software liefert Informationen auf Grundlage der In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben für einen IVDR-Zweck.
IVD-Zwecke umfassen Informationen über einen physiologischen oder pathologischen Vorgang oder Zustand, angeborene körperliche oder geistige Beeinträchtigungen, die Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit, Sicherheit und Verträglichkeit bei potenziellen Empfängern, die voraussichtliche Wirkung einer Behandlung sowie die Festlegung oder Überwachung therapeutischer Maßnahmen.
Dass Laborergebnisse zu den Eingabedaten gehören, führt nicht automatisch zur IVDR. Der Hersteller muss die Quelle der entscheidenden Information, die Art der Ausgabe und die medizinische Zweckbestimmung betrachten.
Software, die einen HbA1c-Wert interpretiert und patientenspezifische diagnostische Informationen liefert, kann unter die IVDR fallen. Kombiniert sie Laborwerte mit Bildgebung und klinischen Beobachtungen für eine umfassendere Therapieentscheidung, ist eine detailliertere Qualifizierungsanalyse erforderlich.
05
Wann Software kein Medizinprodukt ist #
Software wird nicht automatisch zu Medizinproduktesoftware, nur weil sie in einem medizinischen Umfeld eingesetzt wird. Produkte ohne medizinische Zweckbestimmung bleiben normalerweise außerhalb von MDR und IVDR.
- Verwaltung
Terminplanung, Rechnungsstellung, Personaleinsatzplanung und Einrichtungsmanagement
- Kommunikation
Nachrichten und Informationsübertragung ohne medizinische Analyse
- Speicherung
Archivierung, Sicherung und verlustfreie Komprimierung
- Allgemeine Werkzeuge
Textverarbeitung, Tabellenkalkulation und Datenbanken für allgemeine Zwecke
- Schulung
Nachschlage- und Lernwerkzeuge ohne patientenspezifische medizinische Ausgabe
- Wellness
Fitness- und Wohlbefindensanwendungen ohne medizinische Aussagen
Die Grenze kann schmal sein. Eine Wellness-App, die Schritte zählt und zu allgemeiner Bewegung anregt, bleibt normalerweise außerhalb der MDR. Behauptet der Hersteller dagegen, dass die App eine Krankheit überwacht, eine Verschlechterung vorhersagt oder eine Behandlung steuert, kann sich die Qualifizierung ändern.
Auch ein Patientendaten-Dashboard kann nur ein Anzeigeinstrument sein oder als MDSW qualifizieren, wenn es Informationen in einer für Diagnose oder Therapie bestimmten Weise auswählt, verändert oder darstellt.
06
Medizinprodukt, Zubehör oder Bestandteil eines anderen Produkts? #
Sobald Zweckbestimmung und Funktion feststehen, muss der Hersteller die regulatorische Rolle bestimmen, in der die Software auf dem Markt bereitgestellt wird.
Die Software hat einen eigenen medizinischen Zweck und erfüllt selbstständig die Definition der MDR oder IVDR.
Die Software ist in ein Produkt integriert und wird als dessen Teil bewertet, statt separat auf dem Markt bereitgestellt zu werden.
Die Software ist selbst kein Medizinprodukt, wurde aber speziell dazu bestimmt, die bestimmungsgemäße Verwendung eines oder mehrerer bestimmter Produkte zu ermöglichen oder deren medizinische Funktion gezielt und unmittelbar zu unterstützen.
Die Software hat weder einen eigenen medizinischen Zweck noch die spezifische Zweckbestimmung, die für Zubehör erforderlich ist.
Die Bezeichnung als Zubehör macht Software noch nicht zu Zubehör. Ihre vorgesehene Verbindung zu einem oder mehreren bestimmten Produkten muss spezifisch sein. Eine allgemeine Kompatibilität mit Gesundheitssystemen oder der Datenaustausch mit vielen Produkten genügt nicht.
Software, die ein anderes Produkt steuert oder dessen Verwendung beeinflusst, kann dennoch einen eigenen medizinischen Zweck haben. In diesem Fall kann sie selbst als MDSW qualifizieren und nicht lediglich als Zubehör.
Die Qualifizierung ist unabhängig davon, ob die Software eingebettet, cloudbasiert, auf einer Workstation installiert oder als mobile Anwendung bereitgestellt wird.
07
Dieselbe technische Funktion kann zu unterschiedlichen Ergebnissen führen #
Diese Beispiele sind keine automatischen Klassifizierungen. Eine kleine Änderung bei Anwender, Eingabedaten, Ausgabe, Aussage oder klinischem Kontext kann das regulatorische Ergebnis verändern.
08
Klassifizierung von MDSW nach MDR #
Bei MDSW, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, verknüpft Regel 11 die Klasse mit den möglichen Folgen dieser Entscheidungen.
Eine falsche Entscheidung kann zur schwerwiegendsten in Regel 11 beschriebenen Folge führen.
Die Entscheidung kann zu einer schwerwiegenden Verschlechterung des Gesundheitszustands oder zu einem chirurgischen Eingriff führen.
Dies ist die Ausgangsklasse für Software, die Informationen für solche Entscheidungen liefert.
Grundsätzlich IIa, jedoch IIb bei Vitalparametern, deren Veränderung zu einer unmittelbaren Gefahr führen könnte.
Klasse I gilt nur, wenn keine strengere Software- oder andere Klassifizierungsregel anwendbar ist.
Regel 11 ist nicht die einzige mögliche Regel. Je nach Zweckbestimmung und Verbindung mit einem anderen Produkt können auch die Regeln 9, 10, 12, 13, 15 und 22 relevant sein. Gelten mehrere Regeln oder Unterregeln, ist das strengste Ergebnis maßgeblich.
Hat eine Anwendung keine medizinische Zweckbestimmung, liegt sie außerhalb der MDR. Sie wird nicht allein deshalb zu MDSW der Klasse I, weil ihr Risiko gering erscheint.
09
Klassifizierung von IVD-MDSW #
IVD-MDSW wird nach den Regeln in Anhang VIII der IVDR klassifiziert. Zweckbestimmung, Analyt oder Marker, Zielpopulation, klinischer Kontext und Folgen eines falschen Ergebnisses sind dabei relevant.
Eine Zuordnung zu Klasse A, B, C oder D allein anhand einer allgemeinen Bezeichnung wie „Diagnosesoftware“ ist deshalb nicht zuverlässig.
Nur wenn die qualifizierte Software unter die anwendbaren Bestimmungen der Klasse A fällt
Wenn keine höhere oder spezifischere Regel aus Anhang VIII gilt
Beispiele können Software zur Auswertung von HbA1c oder zum Zervixzytologie-Screening sein
Ein Beispiel ist Software zur Bestätigung einer HIV-Infektion
Software, die ausschließlich ein IVD-Instrument steuert oder dessen Verwendung beeinflusst, kann derselben Klasse wie dieses Instrument angehören. Unabhängige IVD-MDSW wird entsprechend ihrer Zweckbestimmung eigenständig klassifiziert.
Reine Speichersoftware ist kein sinnvolles Beispiel für Klasse A. Speichert sie lediglich Ergebnisse und hat keinen IVD-Zweck, qualifiziert sie gar nicht erst als IVD-MDSW.
10
Eine belastbare Qualifizierungsentscheidung dokumentieren #
Ein Qualifizierungsvermerk sollte nicht nur das Ergebnis nennen. Er sollte zeigen, wie sich dieses Ergebnis aus Zweckbestimmung und Funktion des Produkts ableitet.
Von der Bewertung erfasste Softwaremodule, Schnittstellen, Abhängigkeiten und Konfigurationen
Medizinische Aussagen, vorgesehene Anwender, Patientenpopulation, Anwendungsumgebung und klinischer Kontext
Datenquellen, Verarbeitungsschritte sowie dargestellte Informationen oder ausgelöste Handlungen
Anwendung der Qualifizierungskriterien aus MDR, IVDR und MDCG
Eigenständiges Produkt, Zubehör, Bestandteil oder nicht regulierte Software
Anwendbare Regeln, Folgenanalyse und endgültige Klasse
Abgleich von Website, Gebrauchsanweisung, Benutzeroberfläche, Verträgen und technischer Dokumentation
Funktionen, Aussagen, Integrationen und Datennutzungen, die eine erneute Prüfung erfordern
Die Schlussfolgerung sollte neu bewertet werden, sobald eine neue Funktion, Aussage, Anwendergruppe, Datenquelle oder Produktintegration die Zweckbestimmung oder die Verarbeitung von Informationen verändert.
Eine Plattform kann MDSW-Funktionen, nicht regulierte Verwaltungsfunktionen und als Bestandteil eines anderen Produkts bereitgestellte Module kombinieren. Die regulatorische Grenze muss eindeutig sein.
Die praktische Schlussfolgerung
Die Zweckbestimmung bestimmt die regulatorische Grenze
Beginnen Sie nicht mit Risikoklasse oder Technologie. Beginnen Sie damit, was die Software nach dem Willen des Herstellers tun soll, welche Informationen sie erzeugt und wie diese verwendet werden.
Hat die Software einen eigenen medizinischen Zweck, ist zunächst zwischen MDR und IVDR zu unterscheiden und anschließend die einschlägige Klassifizierung anzuwenden. Fehlt ein eigener medizinischer Zweck, ist zu prüfen, ob die Software speziell als Zubehör bestimmt oder in ein anderes Produkt integriert ist. Andernfalls kann sie nicht regulierte Software bleiben.
Welches medizinische Ergebnis erzeugt diese Software, für wen und mithilfe welcher Daten und Funktionen?
Offizielle Quellen
Definieren Sie die regulatorische Grenze?
Qualifizieren Sie die Software, bevor Architektur, Aussagen und Nachweise nur noch schwer zu ändern sind
MDRC unterstützt Software- und KI-Unternehmen dabei, Produktgrenze, Zweckbestimmung, regulatorische Rolle, Klassifizierung und Nachweisstrategie nach MDR und IVDR festzulegen.
Aus dem Wissenszentrum