Sogenannte DiGA (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 DiGA prägnant zusammen. Damit Ihr Produkt als DiGA für eine Kostenerstattung potentiell in Frage kommt, muss es…

  1. …ein Medizinprodukt der Risikoklasse I, IIa oder IIb 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 oder höherer 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?”.

Ihre App ist ein Medizinprodukt? Super! Allerdings ist dann aber noch offen, ob sie auch ein Medizinprodukt einer niedrigen oder höheren Risikoklasse (I, IIa oder IIb) ist.

Zur Bestimmung der Risikoklasse ist insbesondere 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 unser Praxis-Leitfaden, sowie das MDCG Guidance Dokument bei der korrekten Klassifizierung Ihrer Software.

Einen ausführlichen Leitfaden zur Bestimmung der Risikoklasse finden Sie hier: Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden

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 definitionsgemäß 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 zwar 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.

Mehr Informationen zur Zweckbestimmung erhalten Sie in unserem Artikel “Formulierung der Zweckbestimmung für (Software-)Medizinprodukte”

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, oder reine (Primär-)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 könnte demnach auch eine DiGA sein.

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 (Primär-)Präventions-Apps sind potentiell Medizinprodukte, jedoch damit noch keine DiGA. Denn eine DiGA wird z.B. vom Arzt im Falle einer Krankheits-Diagnose verschrieben und richtet sich damit immer an Personen mit einer bestimmten Indikation (ICD-10 Code).

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 DiGA 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. In Zukunft werden auch Datensicherheits- und Datenschutz-Zertifikate für DiGA gefordert.

Selektivverträge – Eine Alternative zu DiGA

Sollte sich Ihre digitale Lösung nicht als DiGA qualifizieren, gibt es in Deutschland auch die Möglichkeit, Selektivverträge mit einzelnen Krankenkassen abzuschließen. Dies ermöglicht Ihnen einen Weg in die Erstattung, der auf Ihre Anwendung zugeschnitten ist.

In unserem Leitfaden zu Selektivverträgen geben wir Ihnen einen Überblick über diese alternative Form der Kostenerstattung: Zum Leitfaden – Selektivverträge für digitale Lösungen

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.

Durch das Digitale-Versorgung-und-Pflege-Modernisierungs-Gesetz ist außerdem eine Abgrenzung zur digitalen Pflegeanwendung (DiPA) interessant. Die DiPA beleuchten wir in diesem Artikel genauer. 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 Start-ups ist dieses Gebiet meist Neuland.

Allen voran sollten Sie vorab eine vernünftige Umsatz- & Kosten-Prognose Ihres DiGA-Vorhabens erstellen. Hierzu zeigen wir Ihnen in diesem Beitrag, wie Sie den möglichen Umsatz in Ihrem gewählten Indikationsgebiet berechnen können (inkl. Excel-Template zur Berechnung).

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”.