Darstellung von Standardisierungsicons, welche von einem Finger angetippt werden
Murrstock / stock.adobe.com
06.04.2022 Fachinformation

Klassifizierung von Medizinprodukten nach MDR: Regel 11 für Software

Die "Regel 11" scheiden sich die Geister. Sie gilt als schwer interpretierbar.

Kontakt

Dipl.-Ing. Hans Wenner

Damit an einem Medizinprodukt rechtmäßig die CE-Kennzeichnung angebracht werden darf, muss der Hersteller ein Konformitätsbewertungsverfahren durchlaufen. Die Auswahl des Konformitätsbewertungsverfahrens ist nicht willkürlich. Die möglichen „Wege zur CE-Kennzeichnung“ werden durch die Klassifizierung des Produkts nach Verordnung (EU) 2017/745 (MDR) (“Medizinprodukteverordnung”) vorgegeben (Artikel 51 in Verbindung mit Anhang VIII), wobei ein gewisser Handlungsspielraum verbleibt.

Doch momentan herrscht Unsicherheit, insbesondere bei Software als Medizinprodukt (Medical Device Software (MDSW)). Ist es mit Blick auf „Regel 11“ (MDR, Anhang VIII, Abs. 6.3) noch möglich, Medizinische Software in Klasse I einzuordnen? Wir geben Ihnen hier Hilfestellung und Argumentation an die Hand, die Sie bei der Klassifizierung Ihrer Software unterstützt!

Medical Device Software (MDSW)

Damit die „Regel 11“ angewendet werden kann, müssen zwei Voraussetzungen erfüllt sein:

  1. Die Software muss ein Medizinprodukt sein;
  2. Die Software darf andere Medizinprodukte nicht steuern oder in der Anwendung beeinflussen.

Frage 1: Ist die Software ein Medizinprodukt?

Die Definition „Medizinprodukt“ ist hinlänglich bekannt (siehe MDR, Artikel 2, Abs. 1 „Medizinprodukt“).

Ist die Software nicht Bestandteil eines Medizinprodukts (z.B.: „Embedded Software“) beschreibt die Leitlinie der „Koordinierungsgruppe Medizinprodukte (MDCG)“ MDCG 2019-11 explizit, dass die Software selbst einen medizinischen Zweck erfüllen muss, um als Medizinproduktesoftware (MDSW) qualifiziert zu werden. Dabei ist die vom Hersteller der Software beschriebene Zweckbestimmung relevant (siehe weiter unten).

Die Leitlinie MDCG-2021-24 präzisiert, dass Software, die in Verbindung mit Medizinprodukten verwendet wird und lediglich Informationen aufzeichnet, speichert oder anzeigt, im Allgemeinen nicht als Medizinprodukt gilt.

Beispiel: Software, die mit Tagebüchern zur Aufzeichnung von Insulindosen vergleichbar ist, ist nicht als Medizinprodukt anzusehen, es sei denn, die Daten werden analysiert oder das Gerät verändert in irgendeiner Weise die Behandlung, Verschreibung, Dosierung usw. des Patienten.

Frage 2: Steuert oder beeinflusst die Software ein Medizinprodukt?

In den Durchführungsvorschriften (MDR, Kapitel II, Abs. 3.3) heißt es:

"Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt.

Ist die Software von anderen Produkten unabhängig, so wird sie für sich allein klassifiziert"  (MDR, Kapitel II, Abs. 3.3).

Anmerkung: gemeint sind „andere Medizinprodukte“.

Zur Anwendung der „Regel 11“ muss die Software also unabhängig[1] ausgeführt werden. Häufig wird dafür der Begriff „Stand-Alone-Software“ verwendet, auf einem Smartphone ist der Begriff „APP“ geläufiger.

Die „Regel 11“

Sofern die genannten Voraussetzungen erfüllt sind, kann die „Regel 11“ (MDR, Anhang VIII, Abs. 6.3) angewendet werden. Sie sieht anschaulich so aus:

Regel 11 MDR, Anhang VIII, Abs. 6.3
VDE

Es ist klar erkennbar: sofern die Software keine Informationen liefert, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden und die Software nicht für die Kontrolle von physiologischen Prozessen bestimmt ist, dann fällt sie in die Klasse I.

Aber ist es tatsächlich ganz so einfach? Weshalb wird „Regel 11“ derart leidenschaftlich diskutiert?

Der „möglichst einfache Weg“ zur CE-Kennzeichnung

Um nun möglichst „einfach“ die CE-Kennzeichnung („das CE-Zeichen“) anzubringen, könnte die Zweckbestimmung vom Hersteller derart formuliert werden, dass die Medizinische Software gemäß der Regel 11 in Klasse I eingestuft werden kann.

Durch den Ausschluss, keine Informationen zur Entscheidungsfindung für diagnostische oder therapeutische Zwecke zu liefern und auch keine physiologischen Prozesse zu kontrollieren, kann der Entscheidungsbaum in der gezeigten Art durchlaufen werden. Resultat: Klasse I. Die zur Konformitätsbewertung und anschließende „CE-Kennzeichnung“ könnte dann ohne die Beteiligung einer Benannten Stelle erfolgen!

Doch hier ist Vorsicht angebracht!

Regel 11 MDR, Anhang VIII, Abs. 6.3 MDSW der Klasse 1
VDE

Stolpersteine

Unter der Annahme, es handelt sich tatsächlich um eine eigenständige Software kann sich die Beantwortung der Fragen „Ist die Software ein Medizinprodukt?“ und „In welche Risikoklasse fällt die Software?“ als sehr schwierig herausstellen. Dabei ist die Zweckbestimmung das grundlegende Kriterium.

Die Zweckbestimmung muss klar, eindeutig und ohne Interpretationsspielraum für den vorgesehenen Anwenderkreis formuliert werden! (In unserem Beitrag haben wir das so dargestellt: „Die Zweckbestimmung ist wie ein Patentanspruch. Hier wird festgelegt, wofür das Produkt sein soll, also was sein Zweck ist (wie der Name schon sagt).“)

Da alle zutreffenden Klassifizierungsregeln anzuwenden sind, gilt es zunächst, eine Messfunktion zu vermeiden. Denn gemäß den Durchführungsvorschriften (MDR, Kapitel II, Abs. 3.5) gilt immer die höchste gefundene Klasse, und Produkte mit Mesfunktion sind (mindestens) Klasse Im und erfordern zur Konformitätsbewertung die Beteiligung einer Benannten Stelle.

Auch der in der Zweckbestimmung formulierte Ausschluss, keine Informationen zur Entscheidungsfindung für diagnostische oder therapeutische Zwecke zu liefern und auch keine physiologischen Prozesse zu kontrollieren, ist kritisch zu hinterfragen.

Die Zweckbestimmung darf nicht willkürlich erscheinen! Denn durch die tatsächlich zur Verfügung gestellte Funktionalität des Produkts könnte beim Anwender ein anderer Eindruck erweckt werden. Sollte es sich quasi „aufdrängen“, die Software doch zur zitierten Entscheidungsfindung zu verwenden, ist darin keine „anormale Verwendung“ zu sehen, sondern eine „vernünftigerweise vorhersehbare Fehlanwendung“! Diese „subjektive Zweckbestimmung“ muss vom Hersteller im Rahmen der Konformitätsbewertung berücksichtigt werden!

Folgerung: ein Ausschluss in der Zweckbestimmung im Stil von „Das Produkt liefert keine Informationen, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden dürfen und ist nicht für die Kontrolle von physiologischen Prozessen bestimmt“ könnte in der Praxis unwirksam sein. Die fatale Folge: das gewählte Konformitätsbewertungsverfahren ist nicht angemessen, das Produkt müsste (kurzfristig) vom Markt genommen werden, im schlimmsten Fall drohen gerichtliche Auseinandersetzungen[2].

Beispiele

Der „Idealzustand“

Eine APP auf dem Smartphone des Patienten unterstützt ihn bei der Behandlung seiner Krankheit dadurch, dass sie ihm Übungen anzeigt, die der Patient dann unter Anleitung der APP durchführt. Um ihn zu motivieren, enthält die APP ein Tagebuch, in dem sie die Trainingseinheiten protokolliert.

Gemäß MDCG-2021-24 gilt Software, die lediglich Informationen aufzeichnet, speichert oder anzeigt, in der Regel nicht als Medizinprodukt (siehe Leitlinie MDCG 2019-11, Abschnitt 3.3). Dies trifft auf Tagebücher, etwa zur Aufzeichnung von Medikationen, zu.

Die hier beschriebene APP hingegen analysiert zudem die Daten und zeigt entsprechend Übungen an. Dadurch ist die APP ein Medizinprodukt (da sie die Behandlung seiner Krankheit unterstützt) und ist mit dem CE-Kennzeichen versehen.

Die Diagnose hingegen hat im Vorfeld bereits beim Arzt stattgefunden, er hat die APP daraufhin empfohlen. Die APP liefert gemäß Zweckbestimmung keine Informationen, die zu Entscheidungen für diagnostische oder therapeutische Zwecke verwendet werden sollen und sie kontrolliert keine physiologischen Prozesse.

Die „reale Welt“

Im Laufe der Verwendung hat der Patient nun Fragen bzgl. der Übungen, die er durchführt. Und da es sich um eine chronische Erkrankung handelt, wird er turnusgemäß beim Arzt vorstellig.

Neben der routinemäßigen Untersuchung befragt der Arzt seinen Patienten auch nach den Erfahrungen mit der APP.

Da diese auch ein Übungstagebuch enthält nimmt der Arzt Einblick. Basierend auf den Einträgen im Übungstagebuch ändert der Arzt die Therapieempfehlung: er empfiehlt, einige Übungen nicht durchzuführen.

Nun hat die APP also doch Informationen geliefert, die zu Entscheidungen für diagnostische oder therapeutische Zwecke verwendet wurden!

Ergo: die APP ist nicht mehr in Klasse I sondern (gemäß Regel 11) in Klasse IIa!

Zusammenfassung

Wie Sie sehen können, ist die Zweckbestimmung das grundlegende Element bei der Bewertung eines Produkts. Sie entscheidet zunächst einmal darüber, ob das Produkt überhaupt ein Medizinprodukt ist.

Und erst mit einer sauber formulierten Zweckbestimmung, die auch einer kritischen Überprüfung standhält und der tatsächlichen Verwendung des Produkts entsprechen muss, lässt sich eine verlässliche Aussage treffen, in welche Risikoklasse es fällt und welches Konformitätsbewertungsverfahren anwendbar ist.

Glücklicherweise sind Sie dabei nicht allein auf sich gestellt!

Kontaktieren Sie uns. Wir erarbeiten dann gemeinsam mit Ihnen die notwendigen Vorgehensweisen, stellen Vorlagen zur Verfügung, begleiten Sie bei der Umsetzung und unterstützen Sie bei allen Fragen.

_________________________________________________________________________________

[1] Die „Unabhängigkeit“ bezieht sich auf die Steuerung oder Beeinflussung eines Medizinprodukts. Denkbar ist, die Software auf einem Medizinprodukt zu installieren, ohne dieses zu steuern oder zu beeinflussen. Beispiel: eine Software, die auf einem Medizinprodukt läuft, Daten sammelt und im Rahmen einer eigenen medizinischen Zweckbestimmung verarbeitet.

[2] Wie eine solche Auseinandersetzung aussehen kann: siehe EuGH v. 22.11.2012 – C-219/11 – Brain Products