Medizinproduktesoftware · EU-MDR und IVDR · US-FDA
Regulieren Sie die medizinische Funktion, nicht das Format der Software
Eine mobile App, ein Cloud-Dienst, eine eingebettete Funktion oder ein KI-Modell kann zu einem regulierten Medizinprodukt werden, wenn Zweckbestimmung und klinische Rolle die anwendbare Definition erfüllen. Der richtige regulatorische Weg verbindet diese Zweckbestimmung mit Klassifizierung, Evidenz, Lebenszyklussteuerung und jeder freigegebenen Änderung.
An der regulatorischen Grenze beginnen
Die Qualifizierung folgt der Funktion und ihrer medizinischen Zweckbestimmung
Die Plattform allein entscheidet die Frage nicht. Dieselbe Technologie kann eine nicht regulierte Verwaltungsfunktion, eine Wellnessfunktion mit geringem Risiko und eine regulierte Medizinproduktfunktion enthalten. Für jede Funktion sind Eingaben, Verarbeitung, Ausgabe, Nutzer und die beanspruchte klinische Verwendung abzubilden.
Allgemeine, administrative oder Wellnessfunktionen
- Terminplanung, Abrechnung und gewöhnliche Kommunikationswerkzeuge
- Allgemeine Referenzinformationen ohne patientenspezifische Analyse
- Lebensstil- und Wohlbefindensfunktionen mit geringem Risiko ohne medizinische Zweckbestimmung
Andere Rechtsbereiche können dennoch gelten, darunter Datenschutz-, Verbraucher-, Cybersicherheits- und KI-Anforderungen.
Software mit einer definierten medizinischen Rolle
- Diagnose, Vorhersage, Prognose, Überwachung oder Unterstützung einer Behandlung
- Analyse patientenspezifischer oder aus Proben gewonnener Informationen
- Steuerung eines Produkts oder Umwandlung einer allgemeinen Plattform
Die genaue Definition, Ausnahmen, Klassifizierung und Aufsichtspraxis unterscheiden sich zwischen der EU und den USA.
Dokumentieren Sie die Antworten vor der Wahl des regulatorischen Weges
- 01Welche Informationen erhält die Funktion?
- 02Wie verarbeitet die Funktion diese Informationen?
- 03Welche Ausgabe erreicht welchen Nutzer?
- 04Wie beeinflusst die Ausgabe die Versorgung?
- 05Was geschieht bei Fehler oder Nichtverfügbarkeit?
Marktspezifische Wege
Verwenden Sie eine Produktdefinition und bestimmen Sie den Weg für jede Rechtsordnung separat
Eine Softwarefunktion kann in beiden Märkten reguliert sein, ohne dieselbe Klasse zu erhalten oder demselben Bewertungsweg zu folgen. Halten Sie Produktarchitektur und Aussagen konsistent, dokumentieren Sie jedoch jede regulatorische Entscheidung nach dem jeweils anwendbaren EU- oder FDA-Rahmen.
Konformitätsweg nach MDR oder IVDR
Qualifizierung, Risikoklassifizierung und CE-Kennzeichnung
-
01
Software qualifizieren
Bestätigen Sie, ob die Funktion Medizinproduktesoftware ist und ob ihre Zweckbestimmung sie der MDR oder IVDR zuordnet.
-
02
Klassifizierungsregeln anwenden
Wenden Sie Anhang VIII an. MDR-Regel 11 ist für viele Entscheidungs- und Überwachungsfunktionen zentral. Die IVDR-Klassen A–D hängen von der Zweckbestimmung und den anwendbaren IVD-Regeln ab.
-
03
Evidenzsystem aufbauen
Verknüpfen Sie Risikomanagement, Software-Lebenszyklusdokumentation, Gebrauchstauglichkeit, Cybersicherheit und klinische Bewertung oder Leistungsbewertung.
-
04
Konformitätsbewertung abschließen
Richten Sie das QMS ein und erstellen Sie die technische Dokumentation. Beziehen Sie eine Benannte Stelle ein, wenn Klasse und Verfahren dies erfordern, stellen Sie anschließend die Konformitätserklärung aus und bringen Sie die CE-Kennzeichnung an.
-
05
In Verkehr gebrachte Software steuern
Halten Sie Registrierung, PMS, Vigilanz, Cybersicherheit, Korrekturmaßnahmen und die Bewertung jeder vorgesehenen Änderung aufrecht.
FDA-Weg für Medizinprodukt-Softwarefunktionen
Produktstatus, Klassifizierung und Marktzugangsweg
-
01
Softwarefunktionen abgrenzen
Bestimmen Sie, welche Funktionen die Medizinproduktedefinition erfüllen und ob ein gesetzlicher Ausschluss oder eine FDA-Durchsetzungsrichtlinie greift.
-
02
Produkttyp bestimmen
Bestimmen Sie Klasse, Regulation Number, Produktcode, anwendbare Kontrollen und gegebenenfalls die Prädikatenlandschaft.
-
03
Marktzugangsweg wählen
Bestätigen Sie, ob die Funktion freigestellt ist oder eine 510(k), einen De-Novo-Antrag, eine PMA oder einen anderen produktspezifischen Weg erfordert.
-
04
Nachweise für die Einreichung vorbereiten
Stimmen Sie Umfang der Softwaredokumentation, Leistungsnachweise, Human Factors, Cybersicherheit und Kennzeichnung auf das Produktrisiko ab.
-
05
FDA-Compliance aufrechterhalten
Wenden Sie QMS-Kontrollen, Meldepflichten, Corrections and Removals, Cybersicherheitspflege und Änderungsbewertungen an.
Evidenzarchitektur
Machen Sie die freigegebene Software bis zu Aussagen und Kontrollen rückverfolgbar
Die Einreichung oder technische Dokumentation ist ein Ergebnis des Entwicklungssystems. Die Evidenz sollte eine klinische Aussage über Anforderungen, Gefährdungen, Kontrollen, Implementierung, Verifizierung, Validierung und Überwachung nach dem Inverkehrbringen nachvollziehbar machen.
Produktdefinition
Zweckbestimmung, Nutzer, Patientenpopulation, Anwendungsumgebung, Indikationen, Einschränkungen, Konfigurationen und freigegebene Version.
Architektur und Lebenszyklus
Softwareelemente, Schnittstellen, Datenflüsse, Fremdkomponenten, Entwicklungsplanung, Konfigurations- und Freigabesteuerung.
Risiko und Cybersicherheit
Sicherheitsgefährdungen, Cyberbedrohungen, Risikokontrollen, sichere Auslegung, Schwachstellenmanagement und koordinierte Offenlegung.
Verifizierung und Validierung
Anforderungsbasierte Tests, Integrations- und Systemtests, ungelöste Anomalien, Kompatibilität und Validierung im Anwendungskontext.
Klinische Evidenz oder Leistungsnachweise
Valide klinische Assoziation, analytische oder technische Leistung, klinische Leistung und Belege für den beanspruchten Nutzen.
Human Factors und Informationen
Kritische Aufgaben, Schnittstellenrisiken, Validierung der Gebrauchstauglichkeit, Kennzeichnung, Anweisungen, Warnhinweise und transparente Darstellung der Ergebnisse.
Software- und KI-Änderungen
Planen Sie den Aktualisierungsmechanismus vor der ersten regulierten Freigabe
Ein neues Modell, ein Datensatz, eine Schnittstelle, eine Hosting-Komponente oder ein Algorithmus kann Leistung und Risiko verändern, ohne dass sich der Produktname ändert. Der Änderungsprozess muss klären, was geändert wird, wie die Änderung geprüft wird, ob die klinische Evidenz gültig bleibt und ob eine neue regulatorische Bewertung erforderlich ist.
Änderungsrahmen beschreiben
Legen Sie zulässige Eingaben, Ausgaben, Leistungsgrenzen und die Implementierungsmethode fest.
Nutzen und Risiko neu bewerten
Bewerten Sie betroffene Gefährdungen, Nutzer, Populationen, Untergruppen, Cybersicherheit und vorhersehbaren Fehlgebrauch.
Verifizieren und validieren
Verwenden Sie vorab festgelegte Akzeptanzkriterien, repräsentative Daten und Nachweise einer kontrollierten Bereitstellung.
Regulatorische Entscheidung treffen
Bewerten Sie vor der Freigabe die Auswirkungen auf die EU-Konformität und FDA-Einreichungspflichten.
In Verkehr gebrachte Version überwachen
Verfolgen Sie Leistungsdrift, Beschwerden, Vorkommnisse, Schwachstellen und Ergebnisse aus der realen Anwendung.
Stimmen Sie bei KI-gestützten Funktionen Data Governance, Leistung in relevanten Populationen, menschliche Aufsicht, Transparenz und die Kontrolle von Modelländerungen auf den Medizinprodukteweg ab. Prüfen Sie in den USA, ob ein Predetermined Change Control Plan in die Einreichung gehört. Bewerten Sie in der EU das Zusammenspiel von MDR oder IVDR und KI-Verordnung für das konkrete System und den Konformitätsweg.
Primärquellen
Prüfen Sie den Weg anhand aktueller offizieller Materialien
Leitlinien ersetzen weder die Verordnungen noch eine produktspezifische Bewertung. Prüfen Sie die aktuelle Fassung und produktspezifische Anforderungen, bevor Sie sich auf einen Weg oder Einreichungsplan stützen.
MDCG 2019-11 rev.1
Qualifizierung und Klassifizierung von Software nach MDR und IVDR
Leitlinien der Europäischen Kommission zu MDSW
Klinische Evidenz, Cybersicherheit, Zusammenspiel mit KI und aktuelle Fassungen
Medizinprodukt-Softwarefunktionen der FDA
Regulatorischer Umfang und Richtlinien für Software und mobile Anwendungen
Softwaredokumentation vor dem Marktzugang
FDA-Empfehlungen für Einreichungen zu Medizinprodukt-Softwarefunktionen
FDA-Leitlinie zur Cybersicherheit
QMS-Aspekte und Inhalte von Einreichungen vor dem Marktzugang
Änderungspläne für KI-gestützte Produkte
FDA-Empfehlungen für Predetermined Change Control Plans
Häufig gestellte Fragen
Praktische Abgrenzungen für Software
Die abschließende Entscheidung hängt von der tatsächlichen Funktion, den Aussagen, Nutzern, der Bereitstellungsarchitektur, dem Risiko und der Evidenz ab — nicht allein von der Produktbezeichnung.
Ist jede Gesundheitsanwendung ein Medizinprodukt?
Nein. Der regulatorische Status folgt der Softwarefunktion und ihrer vom Hersteller festgelegten Zweckbestimmung. Administrative, allgemeine und viele Wellnessfunktionen mit geringem Risiko können außerhalb des Medizinprodukterechts liegen. Funktionen zur Diagnose, Prävention, Überwachung, Vorhersage, Prognose oder Behandlung können die anwendbare Definition erfüllen.
Ändert eine Cloud- oder mobile Bereitstellung den Produktstatus?
Die Bereitstellung auf einem Smartphone, in einem Browser, auf einer Cloud-Plattform oder einem lokalen Server entscheidet nicht allein über den Status. Funktion, Zweckbestimmung, Eingaben, Ausgabe, klinische Rolle und Ausfallfolgen bleiben maßgeblich. Die Architektur beeinflusst dennoch Cybersicherheit, Validierung und Verantwortlichkeiten.
Wie wird Medizinproduktesoftware in der EU klassifiziert?
MDR-Software wird nach Anhang VIII klassifiziert, wobei Regel 11 für viele Entscheidungs- und Überwachungsfunktionen zentral ist. IVDR-Software wird nach den anwendbaren IVD-Regeln der Klasse A, B, C oder D zugeordnet. Software, die ein anderes Produkt steuert oder beeinflusst, kann dessen Klasse folgen, während eigenständige Software selbstständig klassifiziert wird.
Wovon hängt der FDA-Weg ab?
Bestimmen Sie zunächst, ob die Funktion die Medizinproduktedefinition erfüllt und ob ein Ausschluss oder eine FDA-Richtlinie greift. Ermitteln Sie anschließend Produkttyp, Klasse, Produktcode und Kontrollen. Eine regulierte Funktion kann freigestellt sein oder eine 510(k), einen De-Novo-Antrag oder eine PMA erfordern.
Erfordert jede Änderung eines KI-Modells eine neue Einreichung?
Nicht automatisch, aber jede Änderung benötigt eine kontrollierte Bewertung. Die Antwort hängt von der Rechtsordnung, dem zertifizierten oder zugelassenen Produkt, den Auswirkungen auf Zweckbestimmung, Leistung und Risiko sowie einem akzeptierten Änderungsprotokoll ab. Ein von der FDA geprüfter Predetermined Change Control Plan kann bestimmte künftige KI-gestützte Änderungen und deren Kontrollen abdecken.
Reicht die Einhaltung der IEC 62304 für den Marktzugang aus?
Nein. IEC 62304 strukturiert Software-Lebenszyklusprozesse. Der Marktzugang hängt jedoch auch von Qualifizierung, Klassifizierung, Risikomanagement, klinischer Evidenz oder Leistungsnachweisen, Gebrauchstauglichkeit, Cybersicherheit, QMS und dem anwendbaren Konformitätsbewertungs- oder FDA-Einreichungsweg ab.