Seite wählen

Sogenannte DiGAs (Digitale Gesundheitsanwendungen) können von den gesetzlichen Krankenkassen erstattet werden. Dies wurde erstmals mit Inkrafttreten des Digitale-Versorgung-Gesetz (DVG) am 19. Dezember 2019 möglich.

Doch nicht jede Gesundheits-App oder Medical App erfüllt die Definition einer DiGA und somit erstattungsfähig. In diesem Artikel erklären wir im Detail, welche Kriterien Ihre App erfüllen muss, damit Sie als DiGA gilt.

DiGA-Kriterien im Überblick

Der offizielle DiGA-Leitfaden des BfArM fasst die Definition und Kriterien von DiGAs prägnant zusammen. Damit Ihr Produkt als DiGA für eine Kostenerstattung potentiell in Frage kommt, muss es…

  1. …ein Medizinprodukt der Risikoklasse I oder Klasse IIa sein.
  2. …hauptsächlich auf digitalen Technologien beruhen.
  3. …nicht nur zur Steuerung eines Geräts dienen
  4. …die Erkennung, Überwachung, Behandlung, Linderung, Kompensierung von Krankheiten bzw. Verletzungen unterstützen.
  5. …nicht nur der (Primär-)Prävention dienen.
  6. …vom Patienten genutzt werden.

In Folgendem gehen wir auf jedes dieser Kriterien ein.

Kriterium #1: Medizinprodukt niedriger Risikoklasse

Natürlich ist nicht jede Gesundheits-App ein Medizinprodukt. Eine App, die beispielsweise die reine Dokumentation von medizinischen Daten zum Zweck hat, ist kein Medizinprodukt und damit auch keine DiGA. Falls Ihre App Blutdruck-Werte sammelt, diese jedoch nicht für die Diagnose oder Therapie von Krankheiten auswertet, ist dies kein Medizinprodukt. Mehr Informationen finden Sie in unserem Artikel zum Thema „Ist Ihre App ein Medizinprodukt?“.

Angenommen Ihre App ist ein Medizinprodukt. Nun ist immer noch offen, ob sie ein Medizinprodukt einer niedrigen Risikoklasse (I oder IIa) ist. Um dies innerhalb der Medical Device Regulation (MDR) zu evaluieren, ist vor allem die Regel 11 der MDR relevant:

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.

Neben dem Gesetzestext der MDR hilft auch das MDCG Guidance Dokument bei der korrekten Klassifizierung Ihrer Software.

Falls Sie vorhaben statt unter der MDR noch unter den früheren Regelungen der MDD (Medical Device Direction) bzw. dem Medizinproduktegesetz auf den Markt zu gehen, müssen Sie sich mit dem entsprechenden Klassifizierungs-Regeln der MDD befassen. Hier hilft Ihnen auch das zugehörige MEDDEV Guidance Dokument. Dies kommt allerdings nur in Frage, falls Sie Ihr Produkt vor dem 26. Mai 2021 auf dem Markt platzieren (dank MDR Corrigendum II und III). Der Vorteil ist, dass Sie potentiell weniger Aufwand beim Qualitätsmanagement haben, in eine niedrigere Risikoklasse fallen und so evtl. keine benannte Stelle hinzuziehen müssen.

Falls Sie eine Einschätzung benötigen, ob Ihre App/Software ein Medizinprodukt ist, und wenn ja, welche Risikoklasse, kontaktieren Sie uns jederzeit gern für ein kostenloses Beratungsgespräch.

Kriterium #2: Digitale Technologien

Ihr Produkt muss per Definition hauptsächlich auf digitalen Technologien beruhen. Dieses Kriterium erfüllt Ihre App/Software vermutlich auf natürliche Weise. Es schließt aus, dass z.B. ein Blutdruckmessgerät selbst eine DiGA ist. Hardware ist keine DiGA. Anders formuliert könnte man auch sagen: es muss sich um eigenständige Software (sog. Standalone Software) handeln. Dies ist bei Apps und Web-Anwendungen gegeben.

Kriterium #3: Mehr als eine Steuerung von Geräten

Ihre App muss den medizinischen Zweck wesentlich durch die digitale Hauptfunktion erfüllen. Falls Ihre App nur der Steuerung eines medizinischen Geräts dient, und damit den wesentlichen medizinischen Zweck nicht selbst erbringt, ist sie keine DiGA.

Eine DiGA kann mit medizinischen Geräten kommunizieren und z.B. Sensordaten auslesen. Dies darf jedoch nicht der Hauptzweck sein. Falls Ihre App externe Sensordaten eines medizinischen Geräts ausliest und auf dieser Basis eine Diagnose stellt oder Therapieempfehlungen gibt, ist dieses Kriterium erfüllt. Der wesentliche Zweck ist in diesem Fall Diagnose oder Therapieverbesserung, und der Zweck wird durch einen digitalen Algorithmus in Ihrer App/Software erfüllt.

Kriterium #4: Diagnose oder Therapie von Krankheiten oder Verletzungen

Eine DiGA wird im DVG Gesetzestext definiert als eine Anwendung, welche die „Erkennung, Überwachung, Behandlung oder Linderung von Krankheiten oder die Erkennung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen“ unterstützt.

Damit sind z.B. Verhütungs-Apps, Zyklus-Tracking-Apps, Meditations-Apps oder Krankheit-Präventions-Apps (Kriterium #5) keine DiGA. Eine Applikation, die beispielsweise Patienten mit diagnostizierter Sehschwäche durch digitale Sehübungen bei der Therapie unterstützt, erfüllt dieses Kriterium und wäre eine DiGA.

Kriterium #5: Keine reine (Primär-)Prävention

Der DiGA Leitfaden formuliert es folgendermaßen:

Voraussetzung ist, dass ein Risikofaktor im Sinne einer Erkrankung vorliegt, die als Diagnose verschlüsselbar ist.

Eine App, die einen gesunden Menschen bei der Prävention von Krankheiten unterstützt, ist keine DiGA. Auch Präventions-Apps sind potentiell Medizinprodukte, jedoch damit noch keine DiGA. Die DiGA wird z.B. vom Arzt im Falle einer Krankheits-Diagnose verschrieben.

Kriterium #6: Nutzer ist der Patient

Eine App, die hauptsächlich den Arzt bei seiner täglichen Arbeit unterstützt, ist keine DiGA. Eine DiGA muss für die Nutzung durch den Patienten bestimmt sein. Dabei kann die App durchaus den Arzt mit einbeziehen solange der Patient der Hauptnutzer bleibt.

Die Anforderungen bei Erfüllung der Kriterien

Natürlich wird Ihre App bei Erfüllung dieser Kriterien nicht automatisch in das DiGA-Verzeichnis aufgenommen und erstattet. Falls Sie grundsätzlich jedes dieser Kriterien erfüllen, müssen Sie sich im nächsten Schritt mit den Anforderungen an DiGAs befassen. Diese Anforderungen regelt die Digitale Gesundheitsanwendungen-Verordnung (DiGAV).

Dazu gehören zum einen die „Anforderungen an Sicherheit, Funktionstauglichkeit, Datenschutz und -sicherheit sowie Qualität digitaler Gesundheitsanwendungen“. Zusammengefasst umfasst dieser Punkt folgende Anforderungen:

  1. Anforderungen an Sicherheit und Funktionstauglichkeit
  2. Anforderungen an Datenschutz und Datensicherheit
  3. Anforderungen an Qualität und Interoperabilität
  4. Anforderungen an Robustheit
  5. Anforderungen an Verbraucherschutz
  6. Anforderungen an Nutzerfreundlichkeit
  7. Anforderungen an die Unterstützung der Leistungserbringer
  8. Anforderungen an die Qualität der medizinischen Inhalte
  9. Anforderungen an die Patientensicherheit

Viele dieser Anforderungen muss Ihre Medical App als Medizinprodukt ohnehin schon erfüllen (nach MDR oder MDD). Mehr Infos finden Sie auch in unserem Leitfaden zur DiGAV. Wie Sie eine App/Software als Medizinprodukt entwickeln, erfahren Sie in unserem Leitfaden zur Entwicklung von Medical Apps.

Die DiGAV enthält auch einen konkreten Fragebogen, der all diese Anforderungen im Detail behandelt. Innerhalb Ihres Antrags zur Aufnahme in das DiGA Verzeichnis, müssen Sie jeden Punkt dieses Fragebogens beantworten. Diesen finden Sie in Anlage 1 und Anlage 2 der DiGAV.

Außerdem müssen Sie mit Ihrer DiGA einen positiven Versorgungseffekt nachweisen. Ein positiver Versorgungseffekt ist laut DVG entweder ein medizinischer Nutzen oder patientenrelevante Struktur- und Verfahrensverbesserungen in der Versorgung. Diesen positiven Versorgungseffekt müssen Sie innerhalb wissenschaftlicher Studien belegen. Falls Sie derartige Studien zum Antragszeitpunkt nicht vorliegen haben, müssen Sie zumindest ein wissenschaftliches Evaluationskonzept vorlegen, mit dem Sie zu einem späteren Zeitpunkt die Versorgungseffekte nachweisen möchten.

Fazit

Ob Ihre App potentiell eine DiGA ist, wird durch die genannten Kriterien definiert. Dabei ist jedoch nicht immer sofort klar, ob Ihre App z.B. ein Medizinprodukt ist und, wenn ja, unter welcher Risikoklasse sie klassifiziert werden muss. Falls Sie Unterstützung bei dieser Auswertung benötigen, kontaktieren Sie uns gerne für ein kostenloses Beratungsgespräch.

Der aufwendigste Teil bei der Entwicklung einer DiGA ist neben der Software-Entwicklung selbst sicherlich die zusätzlichen Anforderungen an Qualitätsmanagement im regulatorischen Rahmen eines Medizinprodukts zu erfüllen. Gerade für Startups ist dieses Gebiet meist Neuland. Um einen Überblick zu bekommen, was Sie genau bei der Entwicklung von Apps als Medizinprodukt beachten müssen, lesen Sie unseren Artikel zum Thema „Medical App Entwicklung“.

Sie wollen eine App-Idee realisieren?

Kontaktieren Sie uns erstmal unverbindlich. Wir schauen uns gemeinsam an, mit welchem Aufwand und in welchem Zeitrahmen eine Umsetzung möglich wäre. Außerdem können wir schon mal technisches Feedback für mögliche Vorgehensweisen zur Entwicklung der App geben.

QuickBird Medical 

eine Abteilung von
QuickBird Studios GmbH
Nymphenburgerstr. 13-15 
80335 München

Kontakt

+49 (0) 89 54998380 kontakt@quickbirdmedical.com