“Die Nutzung meiner App ist völlig ungefährlich. Sie fällt bestimmt in die niedrigste Risikoklasse.” – Das sieht die MDR vermutlich anders.
Wer seine Software als Medizinprodukt nach der Medical Device Regulation (MDR) zertifizieren möchte, muss sich intensiv mit der Frage nach der Risikoklasse beschäftigen. Nicht umsonst definiert die MDR sogar eine eigene Regel für Software-Medizinprodukte. Eine fehlerhafte Einstufung kann zu erheblichem nachträglichen Mehraufwand führen und rechtliche Konsequenzen nach sich ziehen. Aus dem Grund unterstützt Sie unser Leitfaden bei diesem komplexen Thema.
Im Folgenden leiten wir Sie durch den Entscheidungsprozess für die MDR-Klassifizierung Ihrer Software. Wir helfen Ihnen dabei, die richtige Klasse zu finden.
Falls Sie noch nicht wissen, ob Ihre Software überhaupt ein Medizinprodukt ist, lesen Sie zuerst unseren Artikel zu dem Thema.
- Ist Ihre App überhaupt ein Medizinprodukt?
- MDR-Risikoklassifizierung: kurz und knapp
- Die Zweckbestimmung entscheidet
- In welche Risikoklasse fällt meine App?
- Wer trifft die finale Entscheidung?
- Risikoklasse I, IIa & IIb = DiGA?
- Fazit
Ist Ihre App überhaupt ein Medizinprodukt?
Die Zweckbestimmung entscheidet, ob Ihre App überhaupt als Medizinprodukt einzustufen ist. Erst wenn das der Fall ist, können Sie sich mit der Risikoklassifizierung beschäftigen. Der Artikel 2 (1) der MDR definiert klar, welche Produkte als Medizinprodukte einzustufen sind. So kann eine App zur Analyse der Herzleistung zum Beispiel entweder als Fitness Tracker vorgesehen sein, oder einen Kardiologen bei der Diagnostik unterstützen. Nur im zweiten Fall gilt die App als Medizinprodukt.
Als Hersteller entscheiden Sie selbst, welchen Zweck Ihre Software hat. Sie wollen wissen, ob Ihre Software ein Medizinprodukt ist? Dann erhalten Sie in unserem Leitfaden einen genaueren Überblick: zum Leitfaden.
MDR-Risikoklassifizierung: kurz und knapp
Die Quintessenz der MDR Klassifizierungsregeln in aller Kürze:
Die MDR unterscheidet 4 Risikoklassen: I, IIa, IIb & III
Abbildung 1: die vier Risikoklassen der MDR.
Als Daumenregel lässt sich sagen: Je größer der mögliche Schaden durch den Einsatz einer Medizinprodukt-Software ist, desto höher ist tendenziell die Klasse.
Sobald Ihre Software Entscheidungen zu Therapie und Diagnostik eines Patienten beeinflusst, oder physiologische Prozesse (z.B. Schlafrhythmus) überwacht, fällt diese bereits mindestens in Klasse IIa (Regel 11). Wenn ein Patient dabei in großer Gefahr schwebt, steigt die Risikoklasse weiter an (z.B. Ihre App unterstützt nach einem Herzinfarkt). Eine Software, die vitale Parameter überwacht (Herz, Lunge, etc.) fällt ebenfalls in eine höhere Klasse. Sobald mehrere Regeln auf Ihre Software zutreffen, gilt die strengste Regel (die höchste Risikoklasse).
Eine besonders hilfreiche Ergänzung zu diesem Leitfaden bietet das Guidance-Dokument der MDCG.
Die Zweckbestimmung entscheidet
Lassen Sie uns mit einem Beispiel beginnen, welches verdeutlicht, welchen Einfluss die medizinische Zweckbestimmung auf die Risikoklasse hat.
- Ihre App überwacht den Zyklus einer Frau, um die Wahrscheinlichkeit einer gewollten Schwangerschaft zu erhöhen. – Risikoklasse I
- Ihre App überwacht den Zyklus einer Frau, um das Risiko einer ungewollten Schwangerschaft zu verringern. – Risikoklasse IIb
Eine Steigerung um zwei Risikoklassen, auch, wenn es sich um ein und dasselbe Produkt handelt? Ja, tatsächlich macht die Zweckbestimmung einen immensen Unterschied. Demnach sollten Sie sich zunächst genau überlegen, wie die Zweckbestimmung Ihrer App lauten soll. Es kann gut sein, dass Sie Ihre Zweckbestimmung noch anpassen, nachdem Sie diesen Artikel zu Ende gelesen haben. Unser Artikel zur Zweckbestimmung beschreibt die genauen Inhalte und hilft Ihnen bei der Formulierung.
Ob Ihre App überhaupt ein Medizinprodukt ist, erfahren Sie in diesem Artikel.
Standalone-, Steuerungssoftware, und Zubehör
Jede Software mit einer eigenen medizinischen Zweckbestimmung wird gesondert klassifiziert. Insgesamt gibt es drei verschiedene Arten von Software, die wir zu Beginn unterscheiden möchten:
- Eigenständige Software / Standalone Software
- Software, die in Verbindung mit einem anderen Medizinprodukt verwendet wird
- Software als Teil eines Medizinprodukts
Wichtig an dieser Stelle ist für Sie, dass Sie Ihre Software nicht gesondert klassifizieren müssen, wenn
- sie integraler Bestandteil eines anderen Medizinprodukts ist (z.B. Embedded Software, wie Firmware eines Blutdruck-Messgeräts). Dies ist für mobile Apps fast nie zutreffend.
- sie ausschließlich zur Steuerung eines anderen Medizinprodukts dient (z.B. UI zur Bedienung eines Defibrillators). Dann fällt sie automatisch in dieselbe Klasse, wie das gesteuerte Produkt. Falls die Software aber noch eine weitere Zweckbestimmung hat, müssen Sie prüfen, ob sie in eine höhere Klasse fällt.
In allen anderen Fällen gilt es, die richtige Klasse für Ihre Software zu finden. Erfahren Sie hier mehr über die Arten von Software als Medizinprodukt.
In welche Risikoklasse fällt meine App?
Wie bereits erwähnt, liefert die Zweckbestimmung Ihrer App die Grundlage zur Frage, in welche der vier Risikoklassen sie fällt. Sobald die Zweckbestimmung klar ist, finden Sie mit den Regeln in Anhang VIII zur MDR die richtige Klasse für Ihre Software.
Wir empfehlen, die Suche nach der Klasse bei Regel 11 zu beginnen, da diese speziell Software adressiert. Gleichzeitig lohnt sich ein Blick in das Guidance-Dokument der MDCG. Dessen Kerninhalte sind in diesem Artikel zusammengefasst.
Die Regel 11 der MDR
Für medizinische Software ist in den meisten Fällen die Regel 11 entscheidend. Hier wird zwischen Software unterschieden, die Informationen für Therapie- und Diagnostik-Entscheidungen liefert und jener, die physiologische Prozesse überwacht.
Eine App kann natürlich auch mehrere Zwecke haben.
Gemäß Regel 11 müssen Sie folgende Entscheidungen treffen:
1. Ist Ihre App dazu bestimmt, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Entscheidungen herangezogen werden?
Wenn ja, beantworten Sie im Folgenden diese Fragen:
Können diese Entscheidungen den Tod oder eine irreversible Verschlechterung des Gesundheitszustands herbeiführen? Wenn das zutrifft, fällt Ihre App in die Risikoklasse III.
💡 Beispiel:
Ihre Software liefert durch Bildanalysen die Entscheidungsgrundlage für einen Notarzt, wie er einen Patienten mit akutem Schlaganfall behandeln soll.
Können diese Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff herbeiführen? Wenn das zutrifft, fällt Ihre App in die Risikoklasse IIb.
💡 Beispiel:
Ihre App liefert die Entscheidungsgrundlage für einen Physiotherapeuten, ab welchem Punkt ein verletztes Knie wieder belastet werden kann. Eine Überbelastung könnte zu einer Operation führen.
Wenn Sie beide Fragen mit “Nein” beantworten können, fällt Ihre App vorerst in die Risikoklasse IIa.
💡 Beispiel:
Ihre App misst mittels Fragebogen den Schweregrad einer ADHS-Symptomatik bei Erwachsenen.
Abbildung 2: Grafische Darstellung des Entscheidungsbaums des ersten Teils der Regel 11.
2. Ist Ihre App zur Überwachung von physiologischen Prozessen bestimmt?
Wenn ja, beantworten Sie im folgenden diese Fragen:
Ist die App zur Überwachung vitaler physiologischer Prozesse (Herz-, Lungen-, Hirnfunktion, etc.) bestimmt, wobei die Art der Änderung dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen kann? Wenn das zutrifft, fällt Ihre App vorerst in die Risikoklasse IIb.
💡 Beispiel:
Ihre App überwacht die Herzfrequenz einer Person, während diese im Koma liegt. Bei gesundheitskritischen Messwerten wird das medizinische Personal alarmiert, um rechtzeitig eingreifen zu können.
Wenn Sie diese Frage mit “Nein” beantworten können, fällt Ihre App vorerst in die Risikoklasse IIa.
💡 Beispiel:
Ihre App überwacht den Schlafrhythmus eines Patienten zu Hause, um den Erfolg einer Therapie von Schlafstörungen zu messen.
Abbildung 3: Grafische Darstellung des Entscheidungsbaums des zweiten Teils der Regel 11.
3. Hat Ihre App einen anderen Zweck?
Die Regel 11 besagt im letzten Satz eindeutig: “Sämtliche andere Software wird der Klasse I zugeordnet.” Somit haben Sie auch für diesen Fall Ihre Antwort – oder doch nicht?
Leider nein, denn dann stellt sich die Frage, ob eine andere Regel auf Ihre App angewandt werden kann. Relevant sind dabei insbesondere die Regeln 15 und 22:
- Regel 15 richtet sich an aktive Produkte, die der Empfängnisverhütung oder dem Schutz vor sexuell übertragbaren Krankheiten dienen. Software in diesem Bereich fällt in Klasse IIb.
💡 Beispiel:
Ihre mobile App ist zur Empfängnisverhütung bestimmt. Dafür erinnert sie eine Nutzerin an die tägliche Einnahme der Anti-Baby-Pille. Wenn die Einnahme bis zu einer bestimmten Uhrzeit nicht bestätigt wurde, erzeugt die App ein Warnsignal.
- Regel 22 richtet sich an aktive therapeutische Produkte mit integrierter oder eingebauter diagnostischer Funktion, die das Patientenmanagement durch das Produkt erheblich bestimmt, wie etwa geschlossene Regelsysteme oder automatische externe Defibrillatoren. Software in diesem Bereich fällt in Klasse III.
💡 Beispiel:
Ihre Software ist zur weiteren Begleitung nach einer psychotherapeutischen Behandlung von Depression bestimmt. Durch die eingebaute Diagnostikfunktion wird die Behandlung durch die Software angepasst und die Notwendigkeit einer erneuten Psychotherapie bestimmt.
Wichtig: Wenn Ihre Software gemäß Regel 11 in die Risikoklasse IIb oder niedriger fällt, müssen Sie sich alle anderen Regeln ansehen – denn vielleicht ist noch eine strengere dabei, welche die Risikoklasse erhöht. Wenn mehrere Klassifizierungsregeln auf Ihre Software angewandt werden können, ist immer die strengste Regel zutreffend!
Was fällt überhaupt noch in Klasse I?
Bei strenger Auslegung der Klassifizierungsregeln der MDR werden die meisten medizinischen Softwareprodukte in die Risikoklasse IIa oder höher eingestuft. Es scheint nur noch wenig Software-Produkte zu geben, die unter der MDR noch in Klasse I fallen und bei denen es sich nicht um reine Primärpräventionsangebote handelt. Doch mit einem Blick ins DiGA-Verzeichnis wird klar, dass diese strenge Interpretation in der Praxis nicht immer gegeben ist – dort sind viele Anwendungen gelistet, die nach MDR in Klasse I fallen und keine reine Primärprävention darstellen.
Gemäß MDCG dürften auch Apps zur Empfängnisunterstützung in die Risikoklasse I fallen. Als Beispiel wird dort eine mobile App angeführt, welche den Eisprung einer Frau durch die Eingabe von Basaltemperatur und Menstruationstagen vorhersagen soll.
In letzter Zeit kursieren auch immer mehr Gerüchte darüber, dass eine Zulassung von Software-Medizinprodukten unter Risikoklasse I in Zukunft nicht mehr möglich sei. Ob das wirklich der Fall ist und wie sich die Grauzone zwischen Klasse I und IIa interpretieren lässt, erfahren Sie in unserem Fachbeitrag zur Software der Risikoklasse I.
Fallbeispiele zur Bestimmung der Risikoklasse
Diese Fallbeispiele sollen den Prozess der Entscheidungsfindung veranschaulichen. Es handelt sich hierbei um fiktive Beispiele.
Fallbeispiel 1: App zur Begleitung von Expositionstherapie
Ihre App soll die Expositionstherapie eines Patienten mit Höhenangst begleiten. Dazu wird gemeinsam mit seiner Therapeutin eine Liste mit Situationen erarbeitet, die dem Patienten Angst machen (z.B. 5 Minuten auf dem Balkon seiner Wohnung stehen.). Diese Situationen werden von “wenig angsteinflößend” bis “sehr angsteinflößend” geordnet. Nun soll er selbstständig zu Hause versuchen, eine dieser Situationen aufzusuchen und auszuhalten. Im Nachgang erfasst die App mittels Fragebogen, wie sich der Patient in der Situation gefühlt hat. Auf Basis dieser Daten entscheidet der Therapeut wöchentlich, wann der richtige Zeitpunkt für eine Steigerung des Schwierigkeitsgrades ist.
Wir beginnen bei Regel 11:
- Die App liefert Informationen, die therapeutische Entscheidungen beeinflussen. Wir könnten argumentieren, dass durch diese Entscheidungen weder der Tod, noch ein irreversibler oder ernsthafter Schaden entstehen kann. Demnach wäre das Produkt in Klasse IIa einzustufen.
Da keine andere Regel zutrifft, bleibt die App in Klasse IIa.
Es ließe sich evtl. auch argumentieren, dass der Patient durch Therapieempfehlungen in eine Gefahrensituation gelangen könnte, die einen Tod hervorrufen kann (z.B. eine steile Klippe eines Berges). Somit würde das Produkt in Klasse III fallen. Wir entscheiden uns hier aber ausdrücklich derartige Empfehlungen nicht in der App abzugeben. Dies zeigt jedoch gut den Argumentationsspielraum bei der Klassifizierung eines Medizinprodukts.
Fallbeispiel 2: App für die Therapie nach einem Herzinfarkt
Sie haben eine App entwickelt, die die Herzleistung eines Patienten nach einem Herzinfarkt zu Hause überwacht, nachdem die Behandlung abgeschlossen ist. Auf Basis der Messwerte informiert die App den Patienten, sobald die Einnahme eines lebensnotwendigen Medikaments notwendig ist und wann er wieder zur Nachsorgeuntersuchung gehen soll.
Wir beginnen bei Regel 11:
- Die App überwacht vitale physiologische Prozesse (Herzleistung). Demnach wäre die App ein Medizinprodukt der Klasse IIb.
Wir müssen uns auch die anderen Regeln anschauen, um herauszufinden, ob auch eine strengere Regel angewandt werden muss.
Bei Regel 22 sehen wir:
- Ihre App passt die Therapie an und entscheidet selbst, welche Therapiemaßnahmen notwendig sind. Somit beeinflusst sie das Patientenmanagement.
Daher fiele Ihr Produkt in Risikoklasse III, weil immer die strengste Regel angewandt wird.
Achtung: Bei beiden Beispielen ließe sich sicherlich belebt einen ganzen Nachmittag diskutieren, ob diese Einschätzungen schlussendlich richtig sind. Wichtig für uns ist es hier Ihnen einige greifbare Beispiele zum weiteren Verständnis zu geben. Eine glasklare Einstufung in eine Klasse ist nicht immer möglich, da das Gesetz unterschiedlich interpretiert werden kann. Es bleibt also Argumentationsspielraum. Genießen Sie diese Einschätzungen daher mit Vorsicht.
Wer trifft die finale Entscheidung?
Sie.
Die Entscheidung, ob eine Software ein Medizinprodukt ist, trifft der Hersteller. Auch die Einstufung in eine Risikoklasse wird vom Hersteller vorgenommen. Dabei sollten Sie aber gewissenhaft vorgehen, denn die benannte Stelle kann die Zertifizierung verhindern, falls das Produkt fälschlicherweise in Klasse IIa oder höher eingestuft wird.
Hier erfahren Sie mehr über die Medizinprodukt-Zertifizierung: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)
Bei einer zugewiesenen Risikoklasse I haben Sie zwar keine benannte Stelle, aber auch hier kann die zugewiesene Aufsichtsbehörde auf eine falsche Klassifizierung aufmerksam machen und Sie potenziell auffordern Ihr Produkt nachträglich vom Markt zu nehmen.
Wenn Sie unsicher sind, holen Sie am besten ein Gutachten oder eine Einschätzung einer dritten Partei ein. Die Möglichkeiten hierfür sind:
- Ein spezialisierter Anwalt, der Ihnen ein Gutachten ausstellt
- Ein Regulatory-Berater, der eine Einschätzung abgibt
- das BfArM (leider lange Antwortzeiten und daher kaum praktikabel)
Anmerkung: Weder eine Experten-Einschätzung, noch ein Gutachten schützen Sie rechtlich! Jedoch können solche Dokumente im Falle eines späteren Gerichtsverfahrens entscheidend sein.
Risikoklasse I, IIa & IIb = DiGA?
Eine digitale Gesundheitsanwendung (DiGA) ist eine App, die von ÄrztInnen und PsychotherapeutInnen verschrieben wird und deren Kosten von den gesetzlichen Krankenkassen übernommen werden. Damit eine App zur DiGA werden kann, muss sie in Risikoklasse I, IIa oder IIb fallen. Heißt das im Umkehrschluss, dass alle Apps, die diesen Risikoklassen angehören, auch automatisch DiGA sind? Nein!
Um ins DiGA-Verzeichnis aufgenommen zu werden, müssen Apps einen dicken Anforderungskatalog erfüllen. DiGA sollen die Versorgung optimieren oder strukturelle Erleichterungen für PatientInnen schaffen. Apps, deren Nutzer vorrangig ÄrztInnen sind, scheiden zum Beispiel bereits aus.
Zudem dürfen DiGA auch keine reinen Primärprävention darstellen. Da unter Risikoklasse I jedoch überwiegend solche Angebote fallen, sind auch deshalb viele Apps von der DiGA-Regelung ausgenommen. Alle Kriterien für eine DiGA finden Sie in diesem Artikel.
Digitalen Medizinprodukten, die in Deutschland aufgrund der Risikoklasse III im Moment von der DiGA-Definition ausgenommen sind, wird nun in Frankreich eine Chance eröffnet. Alles über DiGA in Frankreich erfahren sie in diesem Blogartikel.
Fazit
Um die richtige Risikoklasse für Ihre Anwendung zu finden, beginnen Sie am besten bei der Regel 11 der MDR. Fällt Ihre App nach dieser Regel nicht in die Risikoklasse III, sollten Sie noch einmal alle anderen Regeln überprüfen, um herauszufinden, ob eine strengere Regel für Ihr Produkt anzuwenden ist. Zusätzlich lohnt sich ein Blick in das Guidance Dokument der MDCG, um anhand von weiteren Beispielen ein Gefühl für die Klassifizierung von medizinischer Software zu bekommen.
Wichtig zu wissen ist, dass Sie als Hersteller die finale Entscheidung in der Frage nach der Risikoklasse Ihres Produkts treffen. Seien Sie sich dieser Verantwortung bewusst und holen Sie auch Meinungen von Experten ein.
Falls Sie eine Medical App, DiGA oder DiPA planen und Unterstützung bei der Entwicklung benötigen, setzen Sie sich gerne mit uns in Verbindung und wir besprechen das Ganze zusammen unverbindlich. Wir entwickeln Medical Apps für Unternehmen und Forschungseinrichtungen auf Auftragsbasis.
Weitere Fragen? Rufen Sie uns gerne an (+49 (0) 89 54998380) oder schreiben uns eine E-Mail (kontakt@quickbirdmedical.com).
Abonnieren Sie unseren Newsletter, um auf dem Laufenden zu bleiben.
