Die MDR enthält speziell für Software eine Klassifizierungsregel: Regel 11. Diese Regel 11 hat Sprengkraft! Sie hat das Potenzial, die Innovationskraft in Europa weiter zu schwächen.
Hersteller sollten die Interpretation der MDCG kennen, um Fehlklassifizierungen von Software zu vermeiden und um der Argumentation benannter Stellen und Behörden folgen zu können. Diese Interpretation lernen Sie in diesem Beitrag kennen.
1. Inhalt der MDR Regel 11
Die Rule 11 des Kapitels III im Anhang VIII der MDR 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.“
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Video 1: Das Video erläutert die Konsequenzen der Regel 11 insbesondere für kleine Hersteller. (Anmerkung: Im Video wird noch von „Regel 10a“ gesprochen. So wurde die Regel während der Entwurfsphase der MDR nummeriert)
Die Regel 11 wirft erneut die Frage auf, was „physiologische Prozesse“ sind. Eine Definition des Begriffs liefert die MDR nicht.
Lesen Sie hier mehr zum Thema vitale Körperfunktionen. Dieser Beitrag liefert die fehlende Definition nach.
2. Welche standalone Software fällt gemäß Regel 11 NICHT in Klasse I?
a) 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 […]
b) 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!
Beachten Sie unseren Beitrag zur Klasse-I-Software. Er nennt die Ausnahmen.
(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.
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.“
EK-MED 1934/16
Die ehemalige Regel 10a ist nun in Regel 11 fast wortwörtlich übernommen worden.
c) 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!?
3. 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 |
a) 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.
b) 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!
c) 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.
4. MDCG zur Regel 11
a) Anwendbarkeit der Regel 11
Die MDCG definiert den Begriff „Medical Device Software“. Sie schreibt zusätzlich:
Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.
Quelle: MDCG 2019-11
Durch den Zusatz „regardless of whether the software is independent or is driving or influencing the use of a device“ könnte der Eindruck entstehen, dass die Regel 11 sowohl für die stand-alone Software als auch für die Steuerungssoftware gelten soll.
Das ist jedoch nicht der Fall: Aus der Tatsache, dass beide Typen von Software als Medizinprodukt klassifiziert werden, darf nicht geschlossen werden, dass für beide die Regel 11 anwendbar ist. Vielmehr sind zwei Fälle bei der Klassifizierung nach MDR (nicht Klassifizierung als Medizinprodukt) zu unterscheiden:
- Die Software „drives a device or influences the use of a device“: Die Klassifizierung der Software entspricht der des „beeinflussten Medizinproduktes unabhängig von der Regel 11.
- „Independent of any other device“ ist: Die Klassifizierung der Software geschieht durch Anwender der Regel 11.
Die Klassifizierung nach MDR erfolgt daher nicht „regardless of“ sondern „depends of whether the software is independent or is driving or influencing the use of a device.“
b) Konsequenzen für die Klassifizierung
Aus dem MDCG Dokument folgt:
Die Regel 11 gilt nicht nur für standalone Software! Damit muss einer Software innerhalb eines physischen Geräts eine eigene Klasse zugewiesen werden, zumindest wenn diese Software mehr tut, als nur das Gerät anzusteuern. Falls diese Software in eine Klasse fällt, die höher ist als die des „sonstigen“ Geräts, muss der Hersteller das Gerät hochklassifizieren.
Der Gedanke dahinter ist wahrscheinlich, dass eine Software in einer Hardware, die nichts mit der Steuerung der Hardware und damit dem Gerät zu tun hat, wie eine standalone Software zu betrachten ist, die „zufälllig“ in einer Hardware läuft, deshalb aber nicht als embedded Software reguliert werden sollte. Ob das dem Geist des Gesetzes entspricht oder gar diesem widerspricht, werden möglicherweise Richter entscheiden müssen.
Eine „Kleine Anfrage“ an die Bundesregierung, ob man die verschärften Anforderungen der MDR insbesondere an digitale Medizinprodukte abschwächen oder verschieben könnte, wurde abschlägig beantwortet (Antwort der Bundesregierung).
Überlegungen der MDCG
Die MDCG betont, dass immer die höchste Regel greift. Das gibt allerdings bereits die Regel 3.5 vor. Interessanter ist das Beispiel, das die MDCG ausführt:
Wenn ein Software einen Infrarot-Scanner (Klasse IIa) ansteuert, die zudem die Bilder dieses Scanners auf ein Melanom hin untersucht, greifen zwei Regeln:
- Regel 3: Die Software kontrolliert und beeinflusst den Scanner. Demnach fiele sie auch in Klasse IIa.
- Regel 11: Weil es um die Krebserkennung geht, geht die MDCG von einer Einteilung in die Klasse III aus.
Weil die höhere Regel greift, wäre diese Software in die Klasse III einzuteilen!
Die MDCG läutet indirekt auch das (befürchtete) Aus für alle Klasse-I-Software ein. Sie schreibt mit Bezug zum Satz „Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden“ das Folgende:
Therefore it will be necessary to consider this sub-rule for all MDSW.
Entwurf des MDCG-Dokument zu „Medical Device Software“ (MDCG)
Damit fiele alle Software in die Klassen IIa, IIb oder III.
Interessanterweise ergänzt die MDCG in der Regel 11 das Wort „serious“:
„death or an irreversible serious deterioration of a person’s state of health, in which case it is in class III; or
Entwurf des MDCG-Dokument zu „Medical Device Software“ (MDCG)
Diese Ergänzung ist zu begrüßen. Gleichzeitig stellt sich die Frage, weshalb im Gesetz eine Korrektur möglich ist, man aber bei der Klassifizierung selbst nicht nachbessert und auf das IMDRF Guidance-Dokument (s.o.) verweist.
c) Abschwächung der Regel 11 durch MDCG 2019-11
Brüssel hat erkannt, dass die Regel 11 nicht zu den besonders gelungenen Teilen der MDR zählt. Die Tatsache, dass deren Klassifizierung nur den Schweregrade berücksichtigt, aber nicht das Risiko, führt dazu, dass zu viele Software-Anwendungen in der Klasse III eingeteilt werden müssten. Schließlich kann im ungünstigsten Fall immer etwas Schlimmes passieren. Damit ist der Gedanke einer risikobasierten Klassifizierung ad absurdum geführt.
Das MDCG Dokumment hat auf Seite 26 eine Tabelle ergänzt, die sich auf eine Klassifizierung des IMDRFs bezieht. Dadurch gelingt es unter Umständen, Software niedriger zu klassifizieren.
| Significance of Information | |||||
|
|
| |||
| Disease type / Patient condition | Intervention type | Treat or diagnose | Drive clinical mgt. | Inform clinical mgt. | |
|
| Critical | IMDRF IV
MDR III | IMDRF III
MDR IIb | IMDRF II
MDR IIa |
|
| Serious | IMDRF III
MDR IIb | IMDRF II
MDR IIa | IMDRF I
MDR IIa |
| Non-serious | IMDRF II
MDR IIa | IMDRF I
MDR IIa | IMDRF I
MDR IIa | |
Dieser neue Ansatz bringt Vorteile, löst aber sich nicht alle Probleme.
Vorteile
- Diese Klassifizierung erfolgt wieder risikobasiert und nicht (einzig) anhand der Schweregrade möglicher Schäden. Die Einbeziehung der Gesundheitszustände und der möglicher Interventionen hilft hierbei.
- Die Anzahl der Produkte, die sinnwidrig in den Klasse IIb oder III eingestuft werden müssten, wird dadurch deutlich sinken. Das ist ebenso gut wie richtig.
- Die Klassifizierung folgt einer Logik. Die Herleitung ist nachvollziehbar.
(Neue) Herausforderungen
- Ungeeignete Fehlerbehebung
Die Regel 11 ist schlicht ungeeignet. Es ist nicht nachvollziehbar, dass man diesen Fehler nicht behebt, sondern über ein „Erläuterungsdokument“ (MEDDEV?) die Regel wieder teilweise aushebelt. Fehler in Gesetzen müssen in Gesetzen behoben werden, nicht in Erläuterungen. Uns Herstellern würde man so einen Murks nicht durchgehen lassen. - Verwirrende Beispiele
Die Beispiele werfen neue Fragen auf: Wann dient eine Software dem Zweck „diagnosis“, wann „aid in diagnosis“, wann „aid to making a definitive diagnosis“ und wann „inform of options for diagnosis“? Welche Software gibt schon eine direkte Diagnose im Sinne eines ICD-Codes aus? (Fast) alle Software-Anwendungen im Kontext von Diagnosen liefern Informationen, die für eine Diagnose mehr oder weniger entscheidend ist. Weshalb hat man nicht einmal die Definitionen des Begriffs „direkte Diagnose“ in der MDR übernommen? Diese findet sich im Anhang VIII 3.7. - Ein Hauptproblem bleibt ungelöst
Die IMDRF hat bewusst eine Klasse I für die ganz unkritischen Produkte eingeführt. Diesen unkritischen Produkten weist die MDR aber die Klasse IIa zu. Damit bleibt ein großes Problem bestehen: Es gibt kaum noch Software, die gemäß MDR in die Klasse I fällt. Selbst bei unkritischen Produkten ist die Konformitätsbewertung ohne benannte Stelle nicht mehr möglich und ein zertifiziertes Qualitätsmanagementsystem wird notwendig.
Während die FDA dereguliert, schwächen wir Europäer unsere Wettbewerbsfähigkeit, indem wir kleine innovative Firmen, die unkritische Produkte entwickeln, mit Auflagen ersticken. Offensichtlich hat Brüssel die Hausaufgabe nicht erledigt, die sie den Herstellern auferlegt: Im Risikomanagement die Risiken und den Nutzen abzuwägen: Wieviele Menschen retten wir durch die neuen Regeln? Wie viele Menschenleben gefährden wir dadurch, dass die neuen Regeln innovative Produkte verhindern?
d) Völlige Verwirrung durch MDCG 2021-24
Mit der Leitlinie MDCG 2021-24 unternimmt Brüssel einen weiteren Versuch, um Klarheit bei der Klassifizierung zu schaffen. Das gelingt im Fall von Software nicht vollständig:
- Die neue Leitlinie löst die Widersprüche zwischen Regel 11 und MDCG 2019-11 nicht auf. Sie adressiert sie nicht einmal.
- Sie nennt auch Beispiele, die nicht weiterhelfen.
- Beispiele scheinen sogar im Widerspruch zu MDCG 2019-11 zu stehen.
- Die eigentliche Problematik geht die neue Leitlinie nicht an, nämlich, dass die Regel 11 schweregradbasiert und nicht risikobasiert ist. Wie sollen die Hersteller damit umgehen, dass im schlimmsten und unwahrscheinlichen Fall die Patienten immer „irreversible deterioration“ haben? Wie sollen die Hersteller gegen eine offensichtlich unangemessene Einteilung in Klasse III argumentieren?
Die folgende Tabelle kommentiert die Beispiele der MDCG.
| Class | Rule 11 | Examples | Kommentar |
| IIa | Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: | MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics, for example, MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals.Cognitive therapy MDSW where a specialist determines the necessary cognitive therapy based on the outcome provided by the MDSW. | Die Beispiele sind in Übereinstimmung mit MDCG 2019-11. Weshalb aber eine BRCA-positive Patientin, also eine Person, die mit hoher Wahrscheinlichkeit an einem hochaggressiven Krebs leidet, beim Vorschlag einer falschen Chemotherapie keine „serious deterioration“ erleiden soll und damit zumindest die Software in die Klasse IIb befördert, bleibt unklar. |
| III | — death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or | MDSW intended to perform diagnosis by means of image analysis for making treatment decisions in patients with acute stroke. | Dieses Beispiel ist als eines der wenigen eindeutig und nachvollziehbar, zumindest wenn falsche „treatment decisions“ aufgrund der Software vulnerable Patienten töten oder schwer schädigen würden. |
| IIb | — a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb. | A mobile app intended to analyse a user’s heartbeat, detect abnormalities and inform a physician accordingly. MDSW intended for diagnosing depression based on a score resulting from inputted data on patient symptoms (e.g. anxiety, sleep patterns, stress etc.). | Es ist unklar, ob es sich um ein oder zwei Beispiele handelt. Die Formatierung deutet darauf hin, das fehlende Aufzählungszeichen spricht dagegen. Falls es zwei Beispiele sind, fehlen nachvollziehbare Gründe. Entweder man hält sich an die MDCG 2019-11; dann wäre der erste Fall zu klassifizieren in „Aid in diagnosis“ und „often curable“ und somit in Klasse IIa. Oder man nimmt die Regel 11; dann wäre die Software ggf. in Klasse III, weil mit einer beliebig geringen Wahrscheinlichkeit immer ein Tod möglich ist. Dass die Regel 11 eine schweregradbasierte Klassifizierung ist und keine risikobasierte, ist genau die Kritik. Hier hilft MDCG 2021-24 leider nicht weiter. Vergleichbare Überlegungen gelten auch im zweiten Fall. Hier wäre der Suizid der schlimmste Fall. |
| IIa | Software intended to monitor physiological processes is classified as class IIa, | MDSW intended to monitor physiological processes that are not considered to be vital. Devices intended to be used to obtain readings of vital physiological signals in routine check-ups including monitoring at home. | Das ist kein Beispiel, sondern eine Rephrasierung des Textes. Jetzt wechseln die Autoren zu Geräten(?), sodass die Rolle der SW unklar wird. Software, die nur abspeichert, wird durch die MDCG 2019-11 nicht als Medizinprodukt qualifiziert. |
| IIb | except if it is intended for monitoring of vital physiological parameters , where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. | Medical devices including MDSW intended to be used for continuous surveillance of vital physiological processes in anaesthesia, intensive care or emergency care. | Diese Beispiele sind naheliegend. Die Bewertung stimmt mit MDCG 2019-11 überein. |
| I | All other software is classified as class I. | MDSW app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm. The user inputs health data including basal body temperature (BBT) and menstruation days to track and predict ovulation. The fertility status of the current day is reflected by one of three indicator lights: red (fertile), green (infertile) or yellow (learning phase/cycle fluctuation). | Während sich die Regel 15 „alle Produkte, die zur Empfängnisverhütung […] eingesetzt werden sollen“ der Klasse IIb zugeordnet, erlaubt das MDCG-Dokument für die Empfängnisförderung zumindest bei Software die Klasse I. |
5. Fazit
Es bleibt also dabei: Der Gesetzgeber will anscheinend Software hochklassifizieren und damit den umgekehrten Weg wie die FDA gehen, die die Digitalprodukte bewusst dereguliert.
Wenn Sie unsicher sind, wie Sie Ihre Software klassifizieren müssen, hilft Ihnen unser Micro-Consulting mit kostenlosen Tipps.
Änderungshistorie
- 2023-03-04: Link auf Fachartikel zu Klasse-I-Software ergänzt
- 2021-10-11: Kapitel 4.d) mit Diskussion der MDCG 2021-24 ergänzt
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
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
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
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
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.
Guten Morgen,
vielen Dank für die Aufarbeitung dieses Themas und dass Sie die neuesten Erkenntnisse veröffentlichen.
Ich glaube in Ihrem Artikel hat sich leider ein kleiner Tippfehler eingeschlichen. Müsst es in der Tabelle unter Serious-Treat or diagnose nicht IMDRF III statt II heißen, wie in Kapitel 7.2 des SaMD-Dokumentes?
Mit freundlichen Grüßen
Timo Fuchs
Sie haben absolut Recht, lieber Herr Fuchs!
Ich konnte Dank Ihrer Hilfe den Fehler gleich beheben.
Mit bestem Dank und herzlichen Grüßen, Christian Johner
Sehr geehrter Herr Prof. Johner,
nachdem es mir vor zwei Jahren gelungen ist, eine App einer Forschungsstiftung nach langen und unsagbar zähen Verhandlungen als Klasse I zertifizieren zu lassen, weil sonst Stiftungsgelder, die primär aus Spenden resultieren, für die Einbeziehung einer benannten Stelle anstatt für Forschung verpulvert worden wären. Fangen wir dort wieder von vorne an. Aus meinen Gesprächen mit den zustänigen Stellen in D, A, CH komme ich zu den Schluß dass primär blankes Unverständnis für sowohl die Risikobeurteilung als auch das Wesen von Software besteht. Diese Behörden entsenden ihre „fähigsten“ Mitarbeiter nach Brüssel und dann muss es nicht wundern, das soetwas wie die Regel 11 herauskommt.
Als gelernter Jurist weiß ich dass ein verunglücktes Gesetz nur durch die Legislative geändert werden kann. Das heisst den Abgeordneten muss klar gemacht werden worin der Fehler liegt und wie die Konsequenzen des Mißstandes in Arbeitsplätzen, Wirtschaftswachstum und Wissenschaft liegen werden. Die Startup Szene bietet eine grosse Menge Arbeitsplätze mit einem höhen Wachstumspotential, sowohl personell als auch wirtschaftlich. Sie benötigt hochqualifizierte Arbeitnehmer und bildet sie auch heran.
Es bleibt m.E. nur Wissen an die heranzuführen, die hier eine Verbesserung herbeiführen können.
Mit freundlichen Grüssen
Klaus Starch
Danke für Ihre Anmerkung, sehr geehrter Herr Starch!
Wenn wir beim „Zulassen“ eine App helfen können, dann geben Sie Bescheid. Wir unterstützen fast täglich auch kostenlos, um die Folgen nicht nur der Klassifizierungen etwas zu mildern.
Beste Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
ich muss Ihnen Recht geben, die MDR ist eine Innovationsbremse und ein Jobvernichter. Dies vor allem, weil wir in der Bundesrepublik Norman auch tatsächlich einhalten, was leider nicht in allen europäischen Ländern ganz so genau genommen wird.
Beim letzten Audit bei einem meiner Kunden sprachen wir ungezwungen in der Mittagspause und der Auditor pflichtete mir bei: die Neuklassifizierung von Software ist eines der großen Probleme.
Aber auch die weiteren Neuregulierungen bringen nichts Gutes. Während in den USA alles wieder einfacher wird, machen wir es in Deutschland komplexer, als es je in den USA war. Die Regeln, der wir uns in der Hard- und Softwareentwicklung unterwerfen sorgen für ein Unmöglichsein von Innovationen.
Mittlerweile haben wir eine Abteilung geschaffen, die nur dazu da ist, Third Party Software im Nichtregulierten Bereich zu erstellen, welche danach validiert wird. Die dabei anfallenden Dokumentationsaufgaben sind deutlich geringer, als die Entwicklung innerhalb der Norm. Und auch diese sind deutlich höher, als bei einer Konformitätsbewertung innert der USA.
Ganz deutlich wird dies vor allem dann, wenn klar wird, dass gleichzeitig die Menge an benannten Stellen deutlich abnimmt. Die benannten Stellen werden kaum Zeit haben, die notwendigen Zertifikate für die bestehenden Produkte alle auf einen Schlag auszustellen. Geschweige denn die neuen Produkte mit entsprechenden Zertifikaten in den Markt zu lassen.
Kunden mit nur wenigen Produkten wird das sehr schwer fallen. Die tatsächlichen Bedingungen sind deutlich schwieriger geworden.
Im Bereich der aktiven Medizinprodukte der Klasse IIa werden teils aufgrund der Klasseneinordnung seit je her Spatzen mit Pershings beschossen. So sind beispielsweise Bioresonznztherapiegeräte in der selben Klasse, wie Reizstromgeräte und viele andere.
Das Risiko, welches von beispielsweise Mikrostromgeräten oder auch Bioresonanzgeräten ausgeht ist =0! Es sei denn, man schlüge jemandem ein solches Gerät auf den Kopf. Aber selbst dann, wenn man weiß, dass ein gerät ungeführlich ist, verbleibt die Aufgabe dieselbe. Das macht für keinen der Beteiligten irgendeinen Sinn.
Hoffen wir also, dass es möglichst bald zu einer neuerlichen Deregulierung kommt.
Mit freundlichen Grüßen
Thorsten Stüker
Danke für Ihre wichtigen Gedanken, lieber Herr Stüker! Ihre Hoffnung auf eine Deregulierung oder/und wirklich risikobasierte Regulierung teile ich. Beste Grüße, Christian Johner
Lieber Herr Johner,
Sie gehen von diesem Szenario aus:
„Software zum Berechnen von Medikamentendosen, zur Auswahl von Medikamenten, zum Planen von Therapien wie Bestrahlungen und Operationen fällt wahrscheinlich in die Klasse III!“
Wie kommen Sie zu dieser Einschätzung?
Mir persönlich fällt es schwer diese Einschätzung zu teilen.
Ich würde dieser Einschätzung unter Bezug auf folgende Artikel in der MDR entgegentreten:
In Artikel 2. (Begriffsbestimmung) Abs 1 wird eine Software dann als „Medizinprodukt“ bezeichnet, wenn diese „dem Hersteller zufolge für Menschen bestimmt ist und allein […] folgenden spezifischen medizinischen Zwecke erfüllen soll: Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung und Linderung.
Als weiterführendes zwingend zu erfüllendes Kriterium um als „Medizinprodukt“ zu gelten, sieht die oben genannte Verordnung in Artikel 2 Abs. 1 vor, dass „… dessen bestimmungsgemäße Hauptwirkung im oder am menschlichen Körper weder durch pharmakologische oder immunologische Mittel noch metabolisch erreicht wird, dessen Wirkungsweise aber durch solche Mittel unterstützt werden kann.“
Ich kann mir nicht vorstellen, dass eine Software zur Dosisberechnung eine Hauptwirkung im oder am menschlichen Körper erzielt, der nicht durch pharmakologische Mittel (Chemotherapeutikum) erzielt werden kann.
Weiterhin führt eine Dosisberechnung nicht zu einer Diagnose, dient nicht der Verhütung im Sinne von Prävention,trifft keine Prognose und führt auch keine Behandlung z.B. im Sinne einer Software zur Steuerung eines Reizstromgerätes durch.
Ich ziele insbesondere auf den Artikel 2 Abs. 1 mit meiner Argumentation ab.
Was meinen Sie dazu?
Mit freundlichen Grüßen
Rüdiger Freudenberg
Sehr geehrter Herr Freudenberg,
danke für Ihre Rückmeldung und Ihre Frage!
Dass Software zum Berechnen von Medikamentendosen, zur Auswahl von Medikamenten inkl. Kontraindikationsprüfungen ein Medizinprodukt ist, war eigentlich unbestritten. Die entsprechenden Software-Pakete mussten und müssen die Hersteller entsprechend klassifizieren.
Sie haben völlig Recht, dass die Wirkung der Software nicht pharmakologisch ist. Genauso wirkt eine Spritzenpumpe nicht pharmakologisch, auch wenn ihr Hauptzweck der Abgabe von Medikamenten dient.
Beide, die Software und die Spritzenpumpe, dienen der Unterstützung der medikamentösen Behandlung. Daher fallen sie in die Klasse der Medizinprodukte. Es geht also um die Behandlungsunterstützung, nicht um die Diagnose oder Überwachung. Auch hier teile ich Ihre Meinung.
Wenn bei einer Fehlfunktion einer standalone Software ein schwerer Gesundheitsschaden resultieren kann, dann fällt diese in die Klasse III (bei MDR). Ob das der Fall ist, hängt v.a. vom klinischen Kontext und vom Medikament ab.
Argumente, dass Software kein Medizinprodukt sei, weil die Software direkt gar keinen Schaden anrichten kann oder/und weil ja ein Arzt die Medikamente verschreibt und verabreicht, erkennt die Kommission spätestens mit der Änderungsrichtlinie 2007/47 nicht mehr an.
Konnte ich Ihre Frage beantworten? Falls nicht, bleiben Sie einfach hartnäckig.
Viele Grüße, Christian Johner
Guten Tag,
Ich finde die IMDRF Tabelle mit den „gemappten“ MDR Klassen (IIa, IIb, III) sehr hilfreich, besten Dank dafür.
Allerdings wäre es interessant zu verstehen, wie dieses Mapping zustandekommt (die IMDRF N12 stammt aus dem Jahr 2014, kann die MDR bzw. deren Klassifizierungen gar nicht enthalten). Vielleicht können Sie den Artikel dahingehend noch erweitern.
Besten Dank und freundliche Grüsse
Peter Egli
Lieber Herr Egli,
das Mapping erfolgte anders herum: Die MDCG hat überlegt, wie man die Klassen der MDR auf die Klassen des IMDRF-Dokuments mappen kann, um die MDR-Klassen gemäß Regel 11 etwas zu entschärfen.
Ihre Erkenntnis, dass das IMDRF-Dokument die MDR gar nicht kennen kann, ist absolut zutreffend.
Ich grüße Sie vielmals, Christian Johner
Hallo Prof. Johner,
eine Medical App wurde unter der MDD in die Risikoklasse I eingestuft und in den Markt eingeführt. Nach der MDR fällt sie in die Risikoklasse IIa. Wann muss eine MDR-relevante Konformitätsbewertung durch eine benannte Stelle erfolgen?
Liebe Grüße
Jacek Cecek
Sehr geehrter Herr Cecek,
für Produkte, die durch die MDR höher klassifiziert werden, dazu zählt auch Software, gibt es Übergangsfristen, wie in diesem Artikel dargelegt. Demnach könnten Sie die App bis 2024 im Verkehr lassen (s. Entscheidungsdiagramm). Dann dürften aber keine signifikanten Änderungen durchgeführt werden. Was signifikante Änderungen sind, beschreibt ein weiterer Artikel. Lesen Sie insbesondere Abschnitt 3.b).
Viele Grüße, Chrisitan Johner
Hallo zusammen,
mir scheint in dem Artikel eine stillschweigende Annahme zu sein: Ein Arzt oder HCP nutzt die Software auch.
Reine standalone Software, die nur ein Anwender (Patient) nutzt, ist m.E. in der Regel „nur“ Klasse 1. Eine therapeutische und diagnostische Entscheidung trifft immer der Arzt. Viele DiGAs sind damit Klasse 1
Sehe ich das richtig?
Gruß
Sehr geehrter Herr Müller,
mir ist unklar auf welcher Basis Sie diese Schlussfolgerung ziehen. Innerhalb der Medizinprodukteverordnung (MDR) 2017/745 wird nach meinem Kenntnisstand im Rahmen der Klassifizierung keine Unterscheidung hinsichtlich der vorgesehenen Anwender getätigt. Auch in weiteren Leitlinien (MDCG, IMDRF) ist mir eine derartige Differenzierung nicht bekannt. Hätten Sie mir einen Hinweis auf welche Basis Sie diese Schlussfolgerung stützen?
Herzliche Grüße
Die Tabelle am Ende von Kapitel 4 beschreibt für alle Klasse >1 in den Beispielen immer ärztlichen „Tun“; folgt man der Tabelle bleibt für MPs, die nur ein Anwender nutzt, die Klasse 1 über.
Therapie und Diagnose sind die Hoheit des ärztlichen/professionellem Schaffens.
Sehr geehrter Herr Müller,
vielen Dank für die Erläuterung Ihrer Schlussfolgerung, welche ich nicht Teile. Die Spalten der Matrix in Kapitel 4 c) dieses Artikels beziehen sich lediglich auf die Bedeutung der Information in der jeweiligen Kategorie. Hierbei wird nicht hinsichtlich der Anwender-/Nutzergruppe differenziert.
Insbesondere im Rahmen des technologischen Fortschrittes werden zunehmend Softwareanwendungen entwickelt und in Verkehr gebracht, welche direkt (ohne Einbezug eines Arztes, weil bspw. nicht vorgesehen) eine Therapieempfehlung oder gar eine Diagnose stellen. Derartige Produkte müssen aufgrund des einhergehenden Risikos entsprechend (hoch) klassifiziert werden.
Herzliche Grüße
Herzliche Grüße
Sehr geehrter Herr Prof. Johner,
in der MDCG 2019-11 heißt es auf Seite 13 „Accordingly, MDSW that is intended to provide information which is used to take decisions with diagnosis and therapeutic purposes, is at a higher risk class where such decisions, if based on incorrect information from the MDSW, are reasonably likely to have an impact that may cause:…“ während es in der Regel 11 lediglich heißt „…es sei denn, diese Entscheidungen haben Auswirkungen, die Folgendes verursachen können:…“ Hat die MDCG-2019 durch das Hinzufügen der Worte „reasonably likely“ ein Wahrscheinlichkeitskriterium geschaffen durch welches die Regel 11 eingegrenzt wird? Schließlich ist in Regel 11 nichts davon zu lesen, dass die Auswirkungen wahrscheinlich sein müssen.
Mit freundlichen Grüßen
Georg Kleiber
Sehr geehrter Herr Kleiber,
in der Tat hat das MDCG Dokument 2019-11 die Wahrscheinlichkeit hinsichtlich der Auswirkungen in dieser Definition einfließen lassen. Leider gibt es hierzu keine weitere Erläuterung innerhalb des MDCG-Dokuments.
Herzliche Grüße