Kurze Antwort: Wenn Software einen medizinischen Verwendungszweck hat (Diagnose, Prävention, Überwachung, Vorhersage, Prognose, Behandlung), ist sie ein Medizinprodukt gemäß der EU-Medizinprodukteverordnung (MDR, 2017/745) und erhält eine Risikoklasse: I, IIa, IIb oder III, meistens nach Regel 11 von Anhang VIII. Die Klasse entscheidet, ob Sie eine Selbsterklärung abgeben können (nur Klasse I) oder eine benannte Stelle benötigen, wie tief die klinische Bewertung sein muss und wie die Marktüberwachung abläuft. Separat gibt der technische Standard IEC 62304 der Software eine Sicherheitsklasse: A (keine Verletzung möglich), B (nicht schwerwiegende Verletzung möglich) oder C (Tod oder schwerwiegende Verletzung möglich), was den Aufwand für Dokumentation, Design und Tests im Lebenszyklus bestimmt. Die beiden Klassifizierungen sind miteinander verbunden, aber unabhängig, und beide werden durch den Schaden bestimmt, den die Software verursachen könnte, nicht durch ihre Komplexität.
Schritt 1: Ist es überhaupt ein Gerät?
Software gilt gemäß der EU-MDR als Medizinprodukt, wenn ihr bestimmungsgemäßer Zweck medizinisch ist: Diagnose, Prävention, Überwachung, Vorhersage, Prognose oder Behandlung (Artikel 2(1)). Software, die Daten nur speichert, archiviert, kommuniziert, anzeigt oder durchsucht, ist kein Medizinprodukt; Software, die medizinische Informationen zur Unterstützung einer Diagnose- oder Behandlungsentscheidung erstellt oder modifiziert, ist es laut MDCG 2019-11.
Die MDR-Definition (Artikel 2(1)) dreht sich um den Verwendungszweck. Software, die Daten speichert, archiviert, kommuniziert, anzeigt oder einfache Suchen durchführt, ist kein Gerät (MDCG 2019-11 nennt diese). Software, die medizinische Informationen erstellt oder modifiziert, um eine Diagnose oder eine Behandlungsentscheidung zu unterstützen, ist ein Gerät. Ein Datensatz, der einen Laborwert mit dem Referenzbereich des Labors anzeigt, ist es nicht; Software, die einem Benutzer mitteilt, dass der Wert eine Erkrankung anzeigt oder eine Dosis empfiehlt, ist es. Siehe Ist eine Gesundheits-App ein Medizinprodukt? für die Qualifizierung im Detail.
Schritt 2: Die MDR-Risikoklasse, Regel 11
Die MDR-Regel 11 klassifiziert Software für Medizinprodukte nach dem Schaden, den eine falsche Entscheidung verursachen könnte. Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, ist standardmäßig Klasse IIa, Klasse IIb, wenn solche Entscheidungen zu einer schweren Verschlechterung oder einer Operation führen können, und Klasse III, wenn sie zum Tod oder zu einer irreversiblen Verschlechterung führen können. Überwachungssoftware ist Klasse IIa oder für Vitalparameter Klasse IIb.
| Software, die dazu dient... | MDR-Klasse |
|---|---|
| Informationen bereitzustellen, die für Entscheidungen zu Diagnose- oder Therapiezwecken verwendet werden (Standardfall) | IIa |
| ...bei denen solche Entscheidungen zum Tod oder zu einer irreversiblen Verschlechterung des Gesundheitszustands führen können | III |
| ...bei denen solche Entscheidungen zu einer schwerwiegenden Verschlechterung des Gesundheitszustands oder zu einem chirurgischen Eingriff führen können | IIb |
| physiologische Prozesse zu überwachen (Standardfall) | IIa |
| ...lebenswichtige physiologische Parameter zu überwachen, bei denen Schwankungen zu einer unmittelbaren Gefahr für den Patienten führen könnten | IIb |
| alles andere (Software, die ein Gerät ist, aber keine der oben genannten Kategorien) | I |
Regel 11 hat die meisten bisherigen Klasse-I-Software in die Klassen IIa oder höher verschoben, was der Hauptgrund dafür ist, dass die MDR als ein bedeutender Schritt für digitale Gesundheit empfunden wurde. MDCG 2019-11 und das IMDRF-Risikorahmenwerk (Bedeutung der Informationen × Zustand der Gesundheitssituation) helfen bei der Einordnung von Grenzbereichen. Software, die ein Hardwaregerät steuert oder beeinflusst, übernimmt die Klasse dieses Geräts (Regel 3.3 der Durchführungsbestimmungen).
Konsequenzen nach Klasse: Klasse I ist selbsterklärt mit einer technischen Dokumentation und Registrierung, keine benannte Stelle (außer Im, Is, Ir); IIa benötigt eine Bewertung des Qualitätssystems durch eine benannte Stelle und eine Stichprobe der technischen Dokumentation; IIb dasselbe mit strengerer Prüfung der Dokumentation; III eine vollständige Prüfung der technischen Dokumentation und, wo relevant, die Konsultation eines Expertengremiums. Alle Klassen benötigen ein Qualitätsmanagementsystem, eine klinische Bewertung, die der Klasse entspricht, eine verantwortliche Person für die Einhaltung gesetzlicher Vorschriften, UDI, Registrierung in EUDAMED, Marktüberwachung und Vigilanz.
Schritt 3: Die IEC 62304 Software-Sicherheitsklasse
Die IEC 62304 Software-Sicherheitsklasse bewertet Software für Medizinprodukte nach dem schlimmsten Schaden, zu dem sie nach externen Risikokontrollen beitragen könnte: Klasse A, wenn keine Verletzung möglich ist, Klasse B, wenn eine nicht schwerwiegende Verletzung möglich ist, Klasse C, wenn Tod oder schwerwiegende Verletzung möglich ist. Die Klasse legt fest, wie viel Design, Verifizierung und Dokumentation der Software-Lebenszyklus erfordert.
IEC 62304 (2006, geändert 2015) ist der harmonisierte Standard für Software-Lebenszyklusprozesse von Medizinprodukten. Ihre Sicherheitsklasse ergibt sich aus der schlimmsten Gefahrensituation, zu der die Software beitragen kann, nachdem externe Risikokontrollmaßnahmen berücksichtigt wurden:
| Klasse | Gefahrensituation könnte zu... führen | Was der Lebenszyklus erfordert |
|---|---|---|
| A | keiner Verletzung oder Gesundheitsschädigung | Software-Entwicklungsplan, Anforderungen, Freigabe; Problemlösung; Konfigurationsmanagement |
| B | nicht schwerwiegender Verletzung | A: plus Architekturdesign, Verifizierung der Integrations- und Systemtests, dokumentierte Einheitsprüfung |
| C | Tod oder schwerwiegender Verletzung | B: plus detailliertes Design für jede Einheit, zusätzliche architektonische Trennung, strengere Verifizierung |
Klassen werden pro Softwaresystem zugewiesen und können pro Software-Element nach Zerlegung zugewiesen werden, sodass nur die risikoreichen Teile die Klasse-C-Anforderungen erfüllen; der Standard erklärt die dafür erforderliche Begründung der Trennung. ISO 14971 (Risikomanagement) fließt in die Klassifizierung ein; IEC 82304-1 fügt produktbezogene Anforderungen für Gesundheitssoftware hinzu, die auf Allzweckplattformen (Telefone, Cloud) läuft.
Wie die beiden interagieren
Die MDR-Risikoklasse und die IEC 62304-Sicherheitsklasse sind unabhängig voneinander: Die MDR-Klasse (I bis III) bestimmt den regulatorischen Weg und die Einbeziehung einer Benannten Stelle, während die IEC 62304-Klasse (A bis C) die Strenge des Entwicklungsprozesses bestimmt. Eine App der Klasse IIa kann je nach Schaden, den eine falsche Ausgabe verursachen könnte, der IEC 62304-Klasse B oder C angehören.
Die MDR-Klasse betrifft die regulatorische Vorgehensweise; die IEC 62304-Klasse betrifft den Entwicklungsprozess. Eine Klasse-IIa-App nach Regel 11 könnte IEC 62304-Klasse B sein (falsche Informationen könnten zu einer nicht schwerwiegenden Verzögerung der Behandlung führen) oder Klasse C (wenn ein falscher Dosisvorschlag tödlich sein könnte). Ein Klasse-I-Gerät ist normalerweise 62304-Klasse A, aber nicht unbedingt. Benannte Stellen erwarten, dass die technische Dokumentation die 62304-Klasse mit ihrer Begründung, die Lebenszyklusdokumente auf diesem Niveau und die Verbindung zur Risikomanagementakte zeigt. Cybersicherheit (MDCG 2019-16, IEC 81001-5-1) wird parallel bewertet.
Ausgearbeitetes Beispiel
Ein ausgearbeitetes Beispiel für SaMD: Eine App zur Symptomverfolgung, die Symptome protokolliert, anzeigt und teilt, ist kein Medizinprodukt. Das Hinzufügen einer Funktion, die Symptome anhand einer validierten Skala bewertet und dem Benutzer mitteilt, wann er ärztliche Hilfe suchen soll, macht sie zu einem Medizinprodukt, standardmäßig MDR-Klasse IIa, mit IEC 62304 Klasse B oder Klasse C für einen kardialen Anwendungsfall.
Eine App zur Symptomverfolgung, mit der Benutzer Symptome protokollieren, Trends anzeigen und diese mit ihrem Arzt teilen können: kein Gerät (Speicherung, Anzeige, Kommunikation). Dieselbe App fügt eine Funktion hinzu, die die protokollierten Symptome anhand einer validierten Skala bewertet und dem Benutzer mitteilt, wann die Punktzahl darauf hindeutet, dass er ärztliche Hilfe suchen sollte: jetzt ein Gerät, Standard Klasse IIa nach Regel 11 (Informationen für eine diagnostische Entscheidung; ein falsches "keine ärztliche Hilfe nötig" könnte die Behandlung verzögern, schwerwiegend, aber nicht typischerweise irreversibel, also nicht IIb oder III, es sei denn, die Zielerkrankung macht es dazu). IEC 62304: Eine falsche Beruhigung könnte zu einer Verzögerung der Behandlung führen, nicht schwerwiegend bis schwerwiegend, je nach Erkrankung, also Klasse B, möglicherweise C für einen kardialen Anwendungsfall. Vorgehensweise: ISO 13485 QMS, benannte Stelle, klinische Bewertung der Skala, Usability Engineering (IEC 62366-1), Marktüberwachung.
Die Vereinigten Staaten, kurz
In den Vereinigten Staaten reguliert die FDA Software als Medizinprodukt nach dem bestimmungsgemäßen Gebrauch mit den Klassen I, II und III sowie den Zulassungswegen 510(k), De Novo und PMA. Der 21st Century Cures Act schließt administrative Software, Produkte für das allgemeine Wohlbefinden, elektronische Gesundheitsakten und bestimmte klinische Entscheidungsunterstützungssysteme vom Status eines Medizinprodukts aus. Die FDA erkennt die IEC 62304 als Konsensstandard an.
Die FDA reguliert Software als Medizinprodukt nach derselben Logik des Verwendungszwecks, mit den Klassen I, II und III und den Zulassungswegen 510(k), De Novo und PMA. Der 21st Century Cures Act (Abschnitt 3060) hat mehrere Kategorien vom Geräte-Status ausgenommen: Verwaltungssoftware, allgemeine Wellness-Produkte, elektronische Gesundheitsakten und klinische Entscheidungsunterstützung, die es dem Kliniker ermöglicht, die Grundlage der Empfehlung unabhängig zu überprüfen (die CDS-Leitlinie der FDA von 2022 interpretiert dies eng). Die FDA erkennt IEC 62304 als Konsensstandard an und verlangt seit 2023 Cybersicherheitsdokumentation für "Cyber-Geräte". ISO 13485 wurde 2026 zur Grundlage der US-Qualitätssystemverordnung (QMSR).
In Anpheros
Anpheros Daily speichert, zeigt und teilt; es bewertet, interpretiert oder empfiehlt nicht, und sein Verwendungszweck besagt dies. Daher ist es kein Medizinprodukt nach Regel 11 oder den Ausnahmen des Cures Act, und das Team wendet ISO 27001-ähnliche Sicherheit und dokumentierte Softwarepraxis ohne den Geräte-Weg an. Wenn jemals eine Funktion mit medizinischem Zweck hinzugefügt würde, würde sie nach Regel 11 klassifiziert und unter IEC 62304 entwickelt, bevor sie veröffentlicht wird. Siehe Gesundheitstransparenz.
Diese Seite erklärt die Regulierung für Produkt- und Entwicklungsteams. Sie ist keine Rechtsberatung; die unter Quellen verlinkten Texte sind maßgeblich, und Ihr Datenschutzbeauftragter, Ihre benannte Stelle oder Ihr Anwalt entscheiden für Ihren Fall. Letzte Überprüfung: Oktober 2026.
Verwandte Seiten
- Ist eine Gesundheits-App ein Medizinprodukt? EU MDR Regel 11
- MDR vs IVDR
- CDS Hooks erklärt
- Karte der Regulierung von Gesundheitsdaten
- Der EU AI Act und KI im Gesundheitswesen
Quellen
- Verordnung (EU) 2017/745 (MDR), Anhang VIII, EUR-Lex
- MDCG 2019-11: Qualifizierung und Klassifizierung von Software
- IEC 62304:2006+AMD1:2015, Prozesse für den Lebenszyklus von Medizinprodukte-Software
- IEC 82304-1:2016, Produktsicherheit von Gesundheitssoftware
- FDA: Clinical Decision Support Software guidance (2022)
- FDA: Software as a Medical Device
Häufige Fragen
Kann Software unter der MDR Klasse I sein?
Ja, aber selten: nur Software mit medizinischem Zweck, die weder diagnostische oder therapeutische Entscheidungen informiert noch physiologische Prozesse überwacht. Die meisten Apps, die als Geräte gelten, fallen in die Klasse IIa.
Benötigt ein Klasse-IIa-Gerät klinische Studien?
Es benötigt eine klinische Bewertung, die sich auf Literatur, Gleichwertigkeit und Leistungsdaten stützen kann; eine klinische Untersuchung ist erforderlich, wenn vorhandene Beweise nicht ausreichen. Software, die eine diagnostische Leistung beansprucht, benötigt in der Regel eine eigene Leistungsstudie.
Ist IEC 62304 obligatorisch?
Es ist ein harmonisierter Standard, daher ist die Einhaltung die Vermutung der Konformität mit den Softwareanforderungen der MDR (Anhang I, 17). Sie können einen anderen Ansatz wählen, müssen dann aber die Gleichwertigkeit nachweisen, was in der Praxis niemand tut.
Was ist mit KI-Funktionen?
Es gelten die gleichen Regeln, plus der EU AI Act: Ein Gerät mit einer Bewertung durch eine benannte Stelle ist ein Hochrisiko-KI-System gemäß Anhang I, mit Anforderungen an Daten, Protokollierung, Transparenz und menschliche Aufsicht, die zusammen mit der MDR bewertet werden.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →