MDR Regel 11 / Rule 11: Der Klassifizierungs-Albtraum
Donnerstag 2. März 2017
Die MDR enthält speziell für Software eine Klassifizierungsregel: Die Regel 11 (ehemals Regel 10a). Diese Regel 11 hat Sprengkraft: Sie hat das Potenzial, die Innovationskraft in Europa weiter zu schwächen.
Update: Auch der EK-Med („Erfahrungsaustauschkreis der nach dem Medizinproduktegesetz benannten Stellen“) sieht eine Höherklassifizierung von Software, insbesondere Apps als wahrscheinlich (siehe unten).
Inhalt der MDR Regel 11 / Rule 11
Die Rule 11 besagt Folgendes:
„Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, es sei denn, diese Entscheidungen haben Auswirkungen, die Folgendes verursachen können::
- den Tod oder eine irreversible Verschlechterung des Gesundheitszustands einer Person; in diesem Fall wird sie der Klasse III zugeordnet, oder;
- eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person oder einen chirurgischen Eingriff; in diesem Fall wird sie der Klasse IIb zugeordnet.
Software, die für die Kontrolle von physiologischen Prozessen bestimmt ist, gehört zur Klasse IIa, es sei denn, sie ist für die Kontrolle von vitalen physiologischen Parametern bestimmt, wobei die Art der Änderung dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen könnte; in diesem Fall wird sie der Klasse IIb zugeordnet.
Sämtliche andere Software wird der Klasse I zugeordnet.“
Welche standalone Software fällt gemäß Regel 11 NICHT in Klasse I?
Definition Medizinprodukt
Laut der MDR sind Medizinprodukte weiterhin Instrumente, Apparate, Software usw. die vom Hersteller zu einem der folgenden Zwecke vorgesehen sind:
- Diagnose, Verhütung, Überwachung, Vorhersage, Behandlung oder Linderung von Krankheiten
- Diagnose, Überwachung, Behandlung, Linderung oder Kompensation einer Verletzung oder Behinderung,
- Untersuchung, Ersetzung oder Änderung des anatomischen Aufbaus oder eines physiologischen oder pathologischen Prozesses oder Zustands,
- Bereitstellung von Informationen mittels in-vitro Untersuchungen von Proben vom menschlichen Körper einschließlich Organ-, Blut- und Gewebespenden […]
Die Folgen
Gleicht man diese Liste mit dem ab, was die Regel 11 adressiert, wird eines klar:
Es wird kaum noch standalone Software geben, die in die Klasse I fällt!
(Fast) jede Software, die der Diagnose, der Überwachung, der Vorhersage oder der Behandlung dient, stellt auch Informationen bereit, die der Entscheidungsfindung mit einer diagnostischen oder therapeutischen Zielsetzung dient. Genau solche Software klassifiziert die Regel 11 als IIa oder höher.
Die Ausnahmen
Höchstens folgende Zweckbestimmungen könnten eine Klasse I rechtfertigen:
- Prävention, z.B. eine App für den Kardiosport, die Trainingsempfehlungen gibt
- Monitoring, wenn nicht bei vitaler Bedrohung bzw. zur Diagnose. Z.B. eine Software überwacht einen physiologischen Parameter, auf dessen Basis man keine Diagnose stellt und nur Handlungen indiziert, die keine Therapie darstellen. Ein etwas an den Haaren herbeigezogenes Beispiel wäre eine Software für den Flüssigkeitshaushalt mit Trinkempfehlungen.
- Prognosen, die nicht der Entscheidungsfindung dienen
- Linderung, ggf. Biofeedbacksysteme, die nicht als Therapie gelten, da diese „nur“ Symptome lindern.
Einen weiteren Versuch eines Auswegs beschreibt dieser Beitrag, der die Trennung von Daten und Informationen diskutiert. Demnach würde ein PACS keine Informationen liefern!?
Was sind die Folgen der Regel 11?
Die Software wird in der Regel höher klassifiziert. Hier einige Beispiele:
| Produkt | Klasse MDD | Klasse MDR |
|---|---|---|
| App zur Auswahl und zur Dosisberechnung von Cytostatika | I | III |
| Stand-alone Software-Anwendung für die AMTS | I | III (je nach Medikament) |
| Software zum Vorschlagen von Diagnosen basierend auf Laborwerten | I | IIb oder höher (bis III) |
| PDMS | I oder IIa | IIb oder III |
| App zur Diagnose von Schlafapnoe | I | IIa (oder höher) |
| Software für die Therapie- bzw. Bestrahlungsplanung | IIb | IIb oder III, je nach Argumentation |
Folge 1: Kosten und Aufwände explodieren für unkritische Anwendungen
Sobald Software nicht mehr in Klasse I fällt, müssen die Hersteller
- benannte Stellen einbeziehen und
- i.d.R. ein Qualitätsmanagementsystem aufbauen und zertifizieren lassen.
Damit vervielfachen sich die Aufwände und Kosten für die Hersteller. Das trifft insbesondere kleinere Hersteller wie App-Entwickler, Start-ups und universitäre Ausgründungen massiv.
Folge 2: Die Klassifizierung spiegelt nicht immer das Risiko wider
Während in der Vergangenheit sogar eine hochkritische Software zur Berechnung von Zytostatika in Klasse I fiel, haben wir jetzt das Gegenteil: Nun kann es dank Regel 11 passieren, dass sogar unkritische Anwendungen der Klasse III zugeordnet werden müssen.
Das liegt daran, dass die Klassifizierung entweder nur den Schweregrad (z.B. „der Tod könnte verursacht werden“) oder nur die Dauer berücksichtigt („ist irreversibel“).
- Muss jedes Produkt der Klasse III zugeordnet werden, wenn ein Produktfehler im noch so unwahrscheinlichen Fall zum Tod führen kann?
- Führt jede noch so kleine irreversible Schädigung zur gleichen Klassifizierung?
Die Klassifizierung sollte das Risiko widerspiegeln. Risiken sind Kombinationen aus Schweregraden und Wahrscheinlichkeiten. Genau das berücksichtigt die Regel 11 nicht.
Software zum Berechnen von Medikamentendosen, zur Auswahl von Medikamenten, zum Planen von Therapien wie Bestrahlungen und Operationen fällt wahrscheinlich in die Klasse III!
Fazit: Regel 11 wird zur Innovationsbremse
Die Sicherheit von Patienten hat höchste Priorität. Die Gesundheit von Patienten ebenfalls. Die Regel 11 wird die Entwicklung von Software-Produkte in einem Maß erschweren, dass kleine Hersteller die regulatorischen Hürden kaum noch überwinden können.
Produkte, die nicht auf den Markt kommen, gefährden die Sicherheit nicht. Aber Produkte, die nicht auf den Markt kommen (können), fehlen, um Krankheiten und Verletzungen zu diagnostizieren, zu lindern und zu behandeln.
Man kann Menschen nicht nur mit Medizinprodukten töten, sondern auch dadurch, dass Medizinprodukte fehlen. Die Autoren der Regel 11 werden sich daran messen lassen müssen.
Aktuelles zur Regel 11 (ex Regel 10a)
Auch der EK-Med sieht die Gefahr eine Höherstufung: Konkret schreibt er: „Diese Regelung wird – insbesondere für Apps – tendenziell eine Höherklassifizierung zur Folge haben und infolge dessen u.a. vermehrt die Involvierung Benannter Stellen sowie die Durchführung klinischer Prüfungen erfordern.“
Sie können sich das Dokument „EK-MED 1934/16“ hier herunterladen, das auch weitere Auswirkungen der MDR diskutiert.
Die ehemalige Regel 10a ist nun in Regel 11 fast wortwörtlich übernommen worden.
Kategorien: Regulatory Affairs
Dienstag 13. Dezember 2016 um 09:51
Lieber Herr Prof. Johner,
ich stimme Ihnen hier absolut zu, zumal diese Regel 10a im direkten Widerspruch zum Amendment 1 der IEC 62304 steht. Wie soll man mit dieser Konstellation zu einer plausiblen Einigung zwischen der Sicherheitsklasse und der Klassifizierungsregel 10a kommen, wenn man in dem einen Fall die Wahrscheinlichkeit(en) berücksichtigen darf und in dem anderen nicht? Man kann nur hoffen, dass über zukünftige Guidances oder auch Delegation Acts nochmal nachgebessert wird.
LG
Oliver Hilgers
Dienstag 13. Dezember 2016 um 14:21
Lieber Herr Prof. Johner,
Ihren Mut zu diesem Video kann ich nur bewundern! Ich bin auch wirklich kein Freund von Verschwörungstheorien. Allerdings stellt sich doch die Frage nach der tatsächlichen Intention dieser MDR Regel 10a. Ist es tatsächlich nur ein Produkt nicht ausreichend kompetenter Autoren, oder ist es doch der finale Schlag von Lobbyisten mit dem Ziel, sämtliche alternative Medizin komplett zu verbieten bzw. vom Markt zu nehmen?
So oder so bleibt die Frage: Was können wir tun?
LG Holger Heinemeyer
Dienstag 13. Dezember 2016 um 22:08
Lieber Herr Heinemeyer,
ich glaube auch nicht im geringsten an Verschwörung. Der Ansatz, die Produkte sicherer zu machen, ist ja ein löblicher. Dass bei jeder Verschärfung die Sensitivität und Spezifität bei der Diskriminierung nicht bei 100% ist, versteht sich auch. Es ist auch okay, vom Hersteller den Beweis zu verlangen, dass das Produkt sicher ist und den versprochen Nutzen liefert.
Aber bei der jetzigen Regel 10a gibt es einfach unverhältnismäßig viel Kollateralschaden. Dagegen wehre ich mich.
viele Grüße, Christian Johner
Mittwoch 18. Januar 2017 um 21:45
Lieber Herr Professor Johner,
in den letzten zwei Monaten habe ich mit unzähligen Startups gesprochen von denen viele die ein oder andere App entwickeln, die mit Sicherheit in IIa fallen, die aber absolut keine Ahnung davon haben, dass sie im Grunde vor dem Aus stehen, weil sie die Anforderungen gar nicht erfüllen können!
Die Existenz und die Auswirkungen der MDR sind in diesen Kreisen völlig unbekannt und erzeugen ein ungläubiges Kopfschütteln.Selbst wenn es sich um „Streber“ handelt, die aus eigenem Antrieb schon in funktionierendes QMS aufgesetzt haben, dass nach ISO-13485:2016 zertifizierbar wäre: Es gibt nach meiner Recherche noch nicht ein einziges von der DAKKS akkreditiertes Unternehmen, was die Zertifizierung durchführen könnte.
Meine Frage ist: Wie können wir diese Unternehmen erreichen und unterstützen?
Viele Grüße,
Eckhard Jokisch
Mittwoch 18. Januar 2017 um 21:59
Ich stimme Ihrer kritischen Sicht auf die Entwicklung absolut zu. Was können wir tun? Mein Team und ich tun dies:
Natürlich können wir damit nicht eine MDR ungeschehen machen. Wir können nur dazu beitragen, dass die Innovation nicht abgetötet und sichere Produkte weiterhin auf dem Markt gebracht werden.