Regel 11 ist die Klassifizierungsregel des Anhangs VIII der MDR für Medizinprodukte-Software. Sie ordnet Software nach der Bedeutung der von ihr bereitgestellten Information für Diagnose- oder Therapieentscheidungen und nach den Folgen einer Fehlentscheidung ein. Damit kann dieselbe technische Plattform je nach Zweckbestimmung in unterschiedliche Risikoklassen fallen.
Entscheidungsunterstützende Software
Software, die Informationen bereitstellt, auf deren Grundlage diagnostische oder therapeutische Entscheidungen getroffen werden, wird grundsätzlich der Klasse IIa zugeordnet. Steht eine Entscheidung im Raum, die Tod oder eine irreversible Verschlechterung des Gesundheitszustands verursachen kann, führt die Regel zur Klasse III. Kann die Entscheidung eine schwere Gesundheitsverschlechterung oder einen chirurgischen Eingriff verursachen, lautet die Zuordnung Klasse IIb.
Für die Bewertung genügt es nicht, dass eine Anwendung Daten anzeigt. Entscheidend ist, ob die bereitgestellte Information tatsächlich für eine diagnostische oder therapeutische Entscheidung verwendet werden soll. Die Zweckbestimmung muss daher konkret beschreiben, welche Information die Software erzeugt, wer sie nutzt, welche Entscheidung sie beeinflusst und welche Folgen eine falsche, verspätete oder fehlende Information haben kann. Allgemeine Produktnamen oder Marketingaussagen ersetzen diese Analyse nicht.
Überwachung physiologischer Prozesse
Software zur Überwachung physiologischer Prozesse gehört nach Regel 11 grundsätzlich in Klasse IIa. Überwacht sie vitale physiologische Parameter, bei denen Art der Veränderungen eine unmittelbare Gefahr für den Patienten hervorrufen kann, ist Klasse IIb vorgesehen. Die Einstufung verlangt deshalb eine medizinische Betrachtung des überwachten Parameters, der erwartbaren Veränderungsgeschwindigkeit und der Reaktionsmöglichkeit des Anwenders.
Alle übrige Software fällt in Klasse I. Dieser Auffangtatbestand ist nicht für Software gedacht, die Entscheidungen vorbereitet oder physiologische Prozesse überwacht, deren Risikobedeutung aber unpräzise beschrieben wurde. Vor der Anwendung von Regel 11 ist außerdem zu klären, ob die Software überhaupt eigenständig die Definition einer Medizinprodukte-Software erfüllt. Verwaltungs-, Lebensstil- oder allgemeine Kommunikationsfunktionen werden nicht allein durch ihre Nähe zum Gesundheitswesen zu Medizinprodukte-Software.
Abgrenzung zu Regeln für aktive Produkte
Regel 11 knüpft nicht an Energie- oder Stoffaustausch an. Die Regeln 9, 10 und 12 des Anhangs VIII bewerten dagegen bestimmte aktive Produkte und berücksichtigen deren Abgabe oder Austausch von Energie und Stoffen. Für Software ist die relevante Risikobrücke die Information und ihr Einfluss auf die Versorgung, nicht die Frage, ob das zugrunde liegende Gerät elektrische Energie verwendet.
Das ist besonders wichtig für Software, die mit Hardware kombiniert wird. Ein Sensor, ein Monitor und eine Analyseanwendung können zusammenwirken, ohne dass die Klassifizierung der Software einfach aus der Klasse der Hardware abgeleitet wird. Die Funktionen müssen getrennt beschrieben werden. Liefert die Software eine eigene Information für Entscheidungen, wird ihre Rolle nach Regel 11 bewertet; eine reine Steuerungsfunktion kann eine andere Betrachtung erfordern.
Die Klassifizierung ist auch bei Änderungen relevant. Wird ein Algorithmus so angepasst, dass er nicht mehr nur informiert, sondern eine Therapiepriorisierung ausgibt, kann sich die Risikobedeutung der Funktion ändern. Hersteller müssen deshalb ihre Zweckbestimmung und die Folgen einer Fehlfunktion bei wesentlichen Softwareversionen erneut gegen Regel 11 prüfen. Ein Update ist regulatorisch nicht allein deshalb unerheblich, weil es technisch über dieselbe Benutzeroberfläche ausgeliefert wird.
Bedeutung für klinische Studien
Bei einer klinischen Prüfung von Medizinprodukte-Software beeinflusst Regel 11 die regulatorische Strategie, den Umfang der klinischen Evidenz und die Einbindung einer Benannten Stelle. Studien müssen die behauptete Informationsleistung in der vorgesehenen Nutzungssituation prüfen. Für entscheidungsunterstützende Anwendungen ist daher wichtig, welche Referenzmethode verwendet wird, wie Fehlklassifikationen erfasst werden und welche Konsequenz ein falscher Output für die diagnostische oder therapeutische Entscheidung haben kann.
Full-Service-CROs wie Mediconomics unterstützen bei der Überführung der Software-Zweckbestimmung in klinische Endpunkte, bei der Planung von Validierungsstudien, beim Datenmanagement für Softwareversionen und bei der Erstellung klinischer Bewertungsunterlagen. Sie können die Dokumentation so strukturieren, dass Algorithmusversion, Datenquelle, Benutzerrolle und beobachtete Leistungsgrenzen der untersuchten Konfiguration zugeordnet bleiben.
Die MDCG gliedert Regel 11 in die Teilbereiche Entscheidungsinformation, Überwachung physiologischer Prozesse und übrige Software. Diese Reihenfolge hilft, die Funktion zunächst präzise zu beschreiben, statt von einer vermeintlich naheliegenden Klasse aus rückwärts zu argumentieren.
Häufig gestellte Fragen (FAQ)
Wann wird Software nach Regel 11 Klasse III?
Wenn ihre Information für diagnostische oder therapeutische Entscheidungen bestimmt ist und diese Entscheidungen Tod oder eine irreversible Verschlechterung des Gesundheitszustands verursachen können.
Ist jede Monitoring-App Klasse IIa?
Nicht jede App wird überhaupt als Medizinprodukte-Software eingestuft. Für qualifizierte Software zur Überwachung physiologischer Prozesse ist Klasse IIa der Ausgangspunkt, bei vitalen Parametern mit unmittelbarer Gefährdung Klasse IIb.
Warum ist die Zweckbestimmung für Regel 11 so wichtig?
Sie legt fest, ob und wie die Information für Entscheidungen oder Überwachung verwendet werden soll. Erst daraus lässt sich das Schadenspotenzial einer fehlerhaften Information bewerten.
Regulatorische Referenzen
- Verordnung (EU) 2017/745, Anhang VIII Regel 11 – legt die Klassifizierung von Software fest.
- Verordnung (EU) 2017/745, Anhang VIII Regeln 9, 10 und 12 – bilden die Abgrenzung zu anderen aktiven Produkten.
- MDCG 2019-11 Rev.1 – erläutert Qualifizierung und Klassifizierung von Software unter MDR und IVDR.
- Verordnung (EU) 2017/745, Artikel 51 – verankert die Risikoklassen als Grundlage der Konformitätsbewertung.