Am 17. April 2020 hat das Bundesgesundheitsministerium die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV) als Referentenentwurf vorgelegt. Die DiGAV bestimmt die Voraussetzungen für eine Erstattung von digitalen Gesundheitsanwendungen (DiGA) durch die Krankenkassen.

Erfahren Sie, welche Anforderungen die Verordnung an die Hersteller stellt. So können Sie entscheiden, ob ein Antrag erfolgsversprechend ist und ob die Kosten dafür im Verhältnis zum erwarteten wirtschaftlichen Nutzen stehen.

Dieses Verständnis hilft Ihnen, einen erfolgreichen Antrag zu stellen und mit Ihrer DiGA zeitnah Geld zu verdienen.

Parallel zur DiGAV hat das BfArM eine Leitlinie veröffentlicht. Diese verrät auch, welchen amerikanischen Tech-Konzern Sie meiden sollten, um die Anforderungen der DiGAV zu erfüllen. Mehr dazu erfahren Sie im Abschnitt 6 „Anforderungen der DiGAV an die Produkte“.

Download

Laden Sie sich hier die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV) und die DiGA-Leitlinie des BfArM herunter.

1. DiGAV: Um was es geht

Der vollständige Name der DiGAV lautet: „Verordnung über das Verfahren und die Anforderungen zur Prüfung der Erstattungsfähigkeit digitaler Gesundheitsanwendungen in der gesetzlichen Krankenversicherung.“

Diese Verordnung legt fest, wie das „Digitale-Versorgung-Gesetz“ (DVG) umzusetzen ist. Das DVG nennt bereits die wichtigsten Anforderungen an digitale Gesundheitsanwendungen:

  • Das Produkt muss ein Medizinprodukt der Klasse I oder IIa (gemäß MDR bzw. MDD) sein.
  • Es muss die Anforderungen u.a. an den Datenschutz und die Interoperabilität erfüllen.
  • Der Hersteller hat positive Versorgungsaspekte nachzuweisen.
  • Der Hersteller muss einen erfolgreichen Antrag beim BfArM zur Aufnahme ins „Verzeichnis erstattungsfähiger digitaler Gesundheitsanwendungen nach § 33a“ stellen.
Weiterführende Informationen

Lesen Sie hier mehr zum Digitale-Versorgung-Gesetz (DVG).

Die DiGAV beschreibt nun genauer als das DVG, wie die Hersteller nachweisen können, dass sie bzw. ihre Produkte die gesetzlichen Anforderungen erfüllen. Beispielsweise enthält die Verordnung konkrete Checklisten, anhand derer die Hersteller überprüfen müssen, ob die Anforderungen an die IT-Sicherheit erfüllt sind.

Die Verordnung regelt im Gegensatz zum Gesetz auch die Kosten, den Verfahrensablauf und die genauen Inhalte des elektronischen Verzeichnisses.

2. DiGAV im Überblick

Die DiGAV umfasst 43 Paragraphen, die in 9 Abschnitte gegliedert sind (s. Abb. 1).

Kapitelstruktur der DiGAV als Mindmap
Abb. 1: Kapitelstruktur der DiGAV (zum Vergrößern klicken)

Besonders relevant für die Hersteller sind die Abschnitte 2, 3 und 5:

  • Abschnitt 2 legt die Anforderungen an die DiGA fest, z.B. bezüglich Datensicherheit, Interoperabilität und Qualität.
  • Abschnitt 3 beschreibt, wie die Hersteller nachweisen müssen, dass ihr Produkt einen „positiven Versorgungsaspekt“ aufweist.
  • Diejenigen Inhalte, die Hersteller im „DiGA-Verzeichnis“ öffentlich machen müssen, bestimmt der Abschnitt 5.
Weiterführende Informationen

Was das Digitale-Versorgung-Gesetz unter einem positiven Versorgungsaspekt versteht und welche Beispiele es gibt, können Sie hier nachlesen.

3. Ab wann man mit DiGA Geld verdienen kann

Die Bundesregierung scheint daran interessiert zu sein, dass Hersteller rasch von der Erstattung ihrer DiGA profitieren können. Das BfArM schreibt: „Das Verfahren ist als zügiger „Fast-Track“ konzipiert.“

Ob „zügig“ nun als Tautologie oder als Relativierung von „Fast“ zu verstehen ist, lässt die Behörde offen.

In seinem Leitfaden zeigt das BfArM jedenfalls auf, dass im August die ersten DiGA ins Verzeichnis aufgenommen sein können.

Zeitstrahl mit der Umsetzung des Fast-Track-Verfahrens (Quelle: Leitfaden BfArM Seite 10)
Abb. 2: Umsetzung des Fast-Track-Verfahrens. Quelle: DiGA-Leitfaden des BfArM, S. 10 (zum Vergrößern klicken)

4. Was die Antragsstellung kostet (§§ 24 ff.)

Die DiGAV benennt die Kosten für eine Antragsstellung. Diese belaufen sich typischerweise auf 3.000 bis 9.900 EUR.

  • 3000 bis 9900 EUR für die Entscheidung über die dauerhafte Aufnahme in das Verzeichnis für digitale Gesundheitsanwendungen nach § 139e Absatz 3 Satz 1 und für die Entscheidung über die vorläufige Aufnahme in das Verzeichnis für digitale Gesundheitsanwendungen zur Erprobung nach § 139e Absatz 4 Satz 1 und 3
  • 1500 bis 6600 EUR für Entscheidung über die dauerhafte Aufnahme in das Verzeichnis nach Abschluss der Erprobung nach § 139e Absatz 4 Satz 6  
  • 1500 bis 4900 EUR für Entscheidung über die Verlängerung der Erprobungszeit nach § 139e Absatz 4 Satz 7.

Beratungen kosten zwischen 250 und 5.000 EUR, wobei „im Umfang geringfügige allgemeine mündliche, schriftliche oder elektronische Auskünfte hiervon ausgenommen sind“.

Auf Antrag darf das BfArM die Gebühren bis auf ein Viertel reduzieren, beispielsweise wenn der Hersteller keinen angemessenen wirtschaftlichen Nutzen erwarten kann. Das wäre bei sehr kleinen Zielgruppen der Fall.

5. Verzeichnis für digitale Gesundheitsanwendungen (§§ 20 ff.)

5.1 Inhalte des Verzeichnisses („Hosen runterlassen?“)

Die DiGAV beschreibt im § 20, welche Inhalte im Verzeichnis für digitale Gesundheitsanwendungen veröffentlicht werden müssen. Eine noch genauere Vorgabe findet sich im Leitfaden des BfArM, Kapitel 2.2 (s. Abbildung 3).

Mindmap, die die Inhalte des DiGA-Verzeichnisses zusammenfasst, wie sie die DiGAV vorschreibt.
Abb. 3: Die DiGAV verpflichtet die Hersteller, umfangreiche Informationen im Verzeichnis für digitale Gesundheitsanwendungen zu veröffentlichen (zum Vergrößern klicken)

In einigen Fällen genügt es jedoch, einen Link auf eigene Webseiten zu hinterlegen, auf denen die Informationen zu finden sind.

Die Hersteller müssen sich damit ziemlich entblößen: Gerade die Pflicht, auch die Studien und ihre Ergebnisse zu veröffentlichen, dürfte vielen aufstoßen. Mancher Hersteller mag befürchten, dass damit Geschäftsgeheimnisse offenbart werden müssen. Das BfArM schreibt dazu:

Der Hersteller kann im Antragsverfahren die Angaben kennzeichnen, bei denen rechtliche Anforderungen einer Veröffentlichung entgegenstehen. Beispiele hierfür sind der Schutz von Betriebs- und Geschäftsgeheimnissen, der Schutz personenbezogener Daten Dritter oder der Schutz von geistigem Eigentum.

DiGA-Leitfaden des BfArM

Das BfArM besteht aber in jedem Fall auf einem vollständigen Antrag.

5.2 Schnittstellen des Verzeichnisses

Das Verzeichnis soll öffentlich zugänglich sein. Es sind zwei Schnittstellen vorgesehen:

  1. „Nutzerfreundliches und zielgruppenspezifisch strukturiertes Webportal“
  2. Programmierschnittstelle (Application Programming Interface, API)

Das Webportal soll „Versicherten oder Ärzten in unterschiedlichen Ansichten die für sie besonders relevanten Informationen in übersichtlicher Darstellung bereitstellen“.

Die API soll „anderen interessierten öffentlichen und gemeinnützigen Institutionen“ zur Verfügung gestellt werden. Das BfArM denkt dabei an „Fachgesellschaften, Krankenkassen, Ärzteverbände, Forschungsinstitutionen, Stiftungen, Kommunen, Patientenverbände und weitere Akteure“.

Diese API ist allerdings noch nicht spezifiziert. „Details zu der Programmierschnittstelle und deren Nutzung (Registrierung, Testzugänge etc.) wird das BfArM im Laufe des Jahres über seine Website veröffentlichen.“

6. Anforderungen der DiGAV an die Produkte

6.1 Datensicherheit und Datenschutz

Vorgaben

Die Bedeutung, die der Gesetzgeber der Datensicherheit und dem Datenschutz beimisst, sollten Hersteller nicht unterschätzen. Das machen die entsprechenden Veröffentlichungen klar:

  1. Digitale-Versorgung-Gesetz
  2. Digitale-Gesundheitsanwendungen-Verordnung (DiGAV)
  3. Technische Richtlinie BSI TR-03161: Sicherheitsanforderungen an digitale Gesundheitsanwendungen.

Die BSI-Richtlinie verweist wiederum auf weitere Vorgaben:

  1. BSI Standard 200-1, BSI Standard 200-2, BSI Standard 203
  2. BSI IT-Grundschutz-Kompendium
  3. BSI TR-02102-1: Kryptographische Verfahren: Empfehlungen und Schlüssellängen
  4. BSI TR-02102-2: Kryptographische Verfahren: Verwendung von TLS
  5. TR-03107-1: Elektronische Identitäten und Vertrauensdienste im E-Government Teil 1

Konkretisierung durch Checklisten – und Probleme damit

Die DiGAV konkretisiert die Anforderungen (zum Glück), indem sie in Anlage 1 konkrete Checklisten anbietet. Leider scheinen diese Checklisten nur bedingt mit dem BSI TR-03161 des BSI abgestimmt zu sein.

Die Anlage enthält auch weiterhin nur bedingt sinnvolle Anforderungen, wie XML oder JSON-Dateien gegen definierte Schemata zu prüfen, um DDoS-Angriffe abzuwehren.

Das kann helfen, es kann aber auch genau das Gegenteil bewirken: Wer alle Nachrichten eines DDoS-Angriffs erst gegen Schemata prüft, wird seinen Server noch schneller in die Knie zwingen.

Unterscheidung von hohen und sehr hohen Schutzanforderungen

Die Checkliste der DiGAV enthält Punkte, die nur bei DiGA mit „sehr hohem Schutzbedarf“ zu beachten sind. Beispielsweise besteht die Verordnung nur bei sehr hohem Schutzbedarf auf Penetrationstests oder einer 2-Faktor-Authentifizierung.

Was ein sehr hoher Schutzbedarf ist, definiert das BSI im BS 200-2 auf Seite 24. So liegt ein sehr hoher Schutzbedarf vor, wenn „der Schutz personenbezogener Daten unbedingt gewährleistet sein muss. Anderenfalls kann es zu einer Gefahr für Leib und Leben oder für die persönliche Freiheit des Betroffenen kommen.“

Daten auf den Servern von Amazon

Nicht die DiGAV, sondern der Leitfaden des BfArM ringt sich erstmal zu halbwegs konkreten Aussagen durch, ob Hersteller die Cloud-Dienste amerikanischer Tech-Giganten nutzen dürfen:

Apple fällt derzeit nicht unter das EU-US Privacy Shield. Amazon (einschließlich Amazon AWS), Microsoft (einschließlich Azure) und google (einschließlich aller von google LLC angebotenen Dienste) fallen derzeit unter das EU-US Privacy Shield und erfüllen die Regeln für Non-HR-Daten.

DiGA-Leitfaden des BfArM

Damit dürfen personenbezogene Daten nicht in der Apple Cloud gespeichert werden. Wer glaubt, man könne einfach auf Amazon ausweichen, ggf. in einem deutschen Rechenzentrum, sollte das Dokument weiterlesen:

Sofern Backend-Dienste in einer kommerziellen Cloud eines amerikanischen Anbieters laufen, reicht es nicht aus, dass der Cloud-Anbieter unter das EU-US Privacy Shield fällt. Da die Nutzung der Cloud in diesem Fall über einen AV-Vertrag erfolgt, muss auch die Kontrolle des DiGA-Herstellers über die Datenverarbeitung durch den Cloud Provider abgesichert sein. Hier enthalten die AGB der Cloud-Anbieter oftmals Klauseln, die dieses erschweren, sodass hier in jedem Fall eine genauere Analyse der konkreten Formen der Cloud-Nutzung im Rahmen einer Risikobewertung erforderlich ist.

DiGA-Leitfaden des BfArM

Hier lässt uns das BfArM etwas allein. Eine detailliertere Handlungsleitung wäre wünschenswert gewesen; beispielsweise durch Informationen dazu, auf welche Passagen Hersteller in den Standardverträgen mit AWS achten sollten.

6.2 Interoperabilität

Ziel der Interoperabilität

Auch die Interoperabilität der DiGA liegt dem Gesetzgeber am Herzen. Das hat mehrere Gründe:

  1. Patienten sollen Versicherungen wechseln und dabei ihre Daten mitnehmen können. Andernfalls wäre ein Wettbewerb zwischen den Versicherungen erschwert.
  2. Die Gesundheitsversorgung muss sektorenübergreifend gelingen. Sonst fallen unnötige Kosten an, z.B. für Doppeluntersuchungen, für die Übertragung von einem System in ein anderes, für manuelle Tätigkeiten usw.

Die Interoperabilität soll den durchgängigen Informationsfluss zwischen allen am Gesundheitswesen Beteiligten und deren IT-Systemen und (Medizin-) Geräten ermöglichen. Dazu gehören:

  • Krankenhäuser
  • Niedergelassene Ärzte
  • Apotheken
  • Therapeuten
  • Krankenkassen
  • Patienten (inkl. deren eigene Messgeräte, auch Wearables)

Daher formuliert die DiGAV genaue Anforderungen an die Interoperabilität.

„Ausgezeichnete Interoperabilitätsstandards“ verwenden

Die Hersteller sind nicht frei in der Wahl der Interoperabilitätsstandards.

  1. Sie müssen ein von der KBV definiertes MIO oder einen im Verzeichnis vesta Standards als empfohlen ausgezeichneten Standard oder ein ebensolches Profil umsetzen.
  2. Falls es dort keinen passenden Standard gibt, muss der Hersteller eine der folgenden Optionen wählen:
    1. Existierende offene, international anerkannte Standards nutzen, z.B. ein von HL7 definiertes FHIR-Profil
    2. Eigenes Profil für einen bestehenden offenen, internationalen Standard entwickeln bzw. ein Profil erweitern. Das setzt aber voraus, dass „der Hersteller bei der gematik die Aufnahme der so entstandenen Schnittstellenspezifikation im vesta Verzeichnis“ beantragt.
    3. Eigenes Profil für einen im vesta-Verzeichnis gelisteten Standard weiterentwickeln bzw. ein Profil erweitern. Das setzt ebenfalls voraus, dass der Hersteller „bei der gematik die Aufnahme der so entstandenen Schnittstellenspezifikation ins vesta Verzeichnis“ beantragt.
Beachten Sie!

Entweder Sie nutzen einen Standard (wenn es einen gibt) oder Sie tragen dazu bei, einen Standard zu erweitern oder neu zu schaffen.

Ausgezeichnete Interoperabilitätsstandards auch bei Medizingeräten

Diese Pflicht zur Verwendung von ausgezeichneten Standards findet sich auch bei Medizingeräten, Wearables und Sensoren. Die DiGAV stellt den Herstellern drei Optionen zur Verfügung.

  1. Sie implementieren „ein offengelegtes und dokumentiertes Profil des ISO/IEEE 11073 Standards“.
  2. Sie verwenden einen im „vesta Verzeichnis verzeichneten Standard bzw. ein dort verzeichnetes Profil“.
  3. Der Hersteller entwickelt ein „eigenes Profil bzw. einen eigenen Standard und beantragt die Aufnahme dieser Spezifikation im vesta Verzeichnis“.

Diese Forderungen gelten aber nur, wenn der Hersteller die Daten direkt von einem Gerät und nicht nur indirekt über eine Plattform wie Apples Health Kit bezieht.

Dass das BfArM ausgerechnet Apple Health erwähnt, überrascht. Denn die Behörde hat doch selbst festgestellt, dass Apple nicht unter den Privacy Shield fällt.

Fazit: Die DiGAV treibt die „Standardisierung der Standards“ voran, was zu begrüßen ist. Dies wird das Ende vieler proprietärer Standards sein.

Welche Daten ausgetauscht werden müssen

Die Hersteller müssen nicht alle Daten über die standardisierten Schnittstellen anbieten. Beispielsweise dürften Log-Dateien, Rohdaten oder Nutzungsstatistiken auch über proprietäre Schnittstellen „ausgespielt“ werden.

Das BfArM formuliert die folgende Faustregel:

Die Forderung nach einem interoperablen, maschinenlesbaren Export ist ausschließlich eine Anforderung an die Interoperabilität. Interoperabilität geht vor Vollständigkeit. Wenn ein MIO oder ein im vesta Verzeichnis empfohlener Standard/Profil/Leitfaden bekannt ist, worüber sich 80 Prozent der eigentlich zu exportierenden Inhalte abdecken lassen, dann muss dieser verwendet werden.  

DiGA-Leitfaden des BfArM

6.3 Robustheit

Die DiGAV und der Leitfaden formulieren noch klarer als das DVG, was der Gesetzgeber unter „Robustheit“ versteht: Es geht um die Fähigkeit des Systems, mit beispielsweise folgenden Ereignissen umgehen zu können:

  • Ausfall der Stromversorgung
  • Störung der Internetverbindung
  • Abschalten des Mobilgeräts
  • (Versehentliches) Entkoppeln eines Geräts
  • Falsche und unvollständige Systemeinstellungen
  • Problem mit Hardware, Sensorik, Aktoren
  • Fehleingaben durch Benutzer

Der BfArM-Leitfaden nennt auch Konsequenzen, die bei den o.g. Ereignissen vermieden werden müssen:

  • Verfälschung von Daten
  • Verlust von Daten
  • Falsche (unwahrscheinliche, unmögliche) Daten
  • Daten mehrfach vorhanden
  • System in inkonsistentem Zustand
  • Unnötige Aufwände für Anwender

Selbst mögliche Maßnahmen nennt der Leitfaden:

  • Prüfung von Daten auf Plausibilität
  • Verwerfen falscher Daten
  • Hinweise bzw. Warnungen an Benutzer
  • Nutzen von Referenz- bzw. Testdaten (z.B. Bilder)
  • Möglichkeit eines Resets

6.4 Nutzerfreundlichkeit (§ 5 Absätze 5 und 6)

Leider arbeiten die DiGAV und das BfArM mit dem nicht definierten Begriff „Nutzerfreundlichkeit“. Es ist nicht klar, ob damit die Gebrauchstauglichkeit gemeint ist oder eher die Benutzbarkeit.

Zumindest ein starker Fokus auf die Barrierefreiheit lässt vermuten, dass es um die Benutzbarkeit geht. Die DiGAV unterscheidet in der Anlage 2 allerdings zwischen den beiden Begriffen.

Hinweise im Leitfaden auf „Styleguides“ und auf die „Durchführung von Fokusgruppen“ deuten Richtung Gebrauchstauglichkeit im weiteren Sinn. Diese müsste im Rahmen der „Zulassung“ als Medizinprodukt aber bereits nachgewiesen sein.

6.5 Qualitätsgesichertes Wissen (§ 5 Absatz 8)

Die DiGAV fordert:

Die von digitalen Gesundheitsanwendungen verwendeten medizinischen Inhalte müssen dem allgemein anerkannten Stand der medizinischen Erkenntnisse entsprechen.

DiGAV § 5 (8)

Das BfArM schließt daraus, dass „sich die medizinisch-fachliche Grundlage der DiGA aus akzeptierten und belastbaren Quellen wie z.B. medizinischen Leitlinien, etablierten Lehrbüchern, vergleichbaren anerkannten Quellen oder zumindest veröffentlichten Studien ableiten muss.“

7. Nachweis der positiven Versorgungsaspekte

Wahrscheinlich immer noch das größte Bauchweh dürfte den Herstellern der Abschnitt 3 „Anforderungen an den Nachweis positiver Versorgungseffekte“ bereiten.

Die Definitionen der Begriffe „positiver Versorgungseffekt“, „medizinischer Nutzen“ und „patientenrelevante Struktur- und Verfahrensverbesserungen“ sowie Beispiele dafür finden sich im Beitrag zum DVG, auch wenn erst die DiGAV bzw. das BfArM diese Beispiele nennt.

Hersteller aller Medizinprodukte müssen nachweisen, dass ihre Produkte zumindest den Stand der Technik reflektieren und damit einem alternativen Produkt oder Verfahren gleichwertig sind.

Die DiGAV legt die Latte höher, wie Sie im Folgenden ausgeführt finden.

Herausforderung 1: Die DiGA muss besser sein

Der Hersteller muss nachweisen, dass die DiGA besser(!) ist als deren Nichtanwendung. Dabei versteht man unter Nichtanwendung, dass ein Patient

  • ohne die entsprechende DiGA, aber mit etwas anderem behandelt wird,
  • gar nicht behandelt wird oder
  • mit einer vergleichbaren und bereits gelisteten DiGA behandelt wird.
Vorsicht!

Das hat zur Folge, dass es nicht möglich sein wird, eine gleichwertige DiGA in das Verzeichnis der DiGA-Anwendungen aufnehmen zu lassen. Für Hersteller bedeutet das, dass der erste gewinnt!?

Es ist daher nicht ganz nachvollziehbar, wie eine Situation auftreten kann, die das BfArM hier schildert:

Sofern für den verordnenden Arzt in Bezug auf die angestrebte Therapieunterstützung im konkreten Behandlungsfall kein Unterschied zwischen zwei oder mehr DiGA erkennbar ist, kann es im Einzelfall geboten sein, die kostengünstigere DiGA zu verordnen.

Diga-Leitfaden des BfArM

Herausforderung 2: Der Nachweis muss in Form einer Studie erfolgen

Die MDR bzw. MDD erlauben es, im Rahmen der klinischen Bewertung den Nachweis des Nutzen-Risiko-Verhältnisses anhand von Literatur und ggf. sogar „nur“ anhand von Leistungsdaten zu führen.

Die DiGAV hingegen besteht immer auf einer wissenschaftlichen Studie.

Herausforderung 3: Der Studie muss mit der DiGA selbst durchgeführt werden

Auch bei Produkten, mit denen die Nachweise im Rahmen der Studien erbracht werden, zeigen sich MDR und MDD großzügiger: Solange das Äquivalenzprodukt klinisch, technisch und biologisch vergleichbar ist, dürfen damit gewonnene Daten zum Nachweis genutzt werden.

Die DiGAV geht einen Schritt weiter. Das BfArM umschreibt die Forderung wie folgt:

Alleinige Verweise auf andere Primärliteratur und Studien auch von anderen gleichartigen DiGA sind nicht zulässig.

DiGA-Leitfaden des BfArM

Herausforderung 4: Die Studien müssen in Deutschland durchgeführt werden

Das BfArM kommt zu dem Schluss: „Durch die Begrenzung auf Deutschland ist gewährleistet, dass die Studienergebnisse ausreichend aussagekräftig sind.“

Dieser Schlussfolgerung kann das Johner Institut nicht folgen: Gerade durch die Begrenzung auf Deutschland kann es vorkommen, dass nicht ausreichend Daten gesammelt werden können und die Studienergebnisse gerade nicht ausreichend aussagekräftig sind.

Ob Studienergebnisse aussagekräftig sind, hängt von Art und Güte der Studie und von der Vergleichbarkeit der Population ab, aber nicht primär vom Land.

Würden andere Länder solche Forderungen erheben, würde man das als Wettbewerbsbeschränkung brandmarken. Dass also gegen diesen Punkt der Verordnung geklagt werden wird, halten wir für wahrscheinlich.

Herausforderung 5: Veröffentlichungspflicht

In der DiGAV ist vorgeschrieben, dass die Studien registriert und deren Ergebnissen publiziert werden. Das BfArM schreibt:

Die Studien müssen in einem öffentlichen Studienregister registriert werden. Das Studienregister muss ein Primärregister oder ein Partnerregister der World Health Organisation International Clinical Trials Registry Platform oder ein Datenlieferant der World Health Organisation International Clinical Trials Registry Platform sein. […] Das anerkannte Primärregister für Deutschland ist das Deutsche Register klinischer Studien (DRKS) beim Deutschen Institut für Medizinische Dokumentation und Information (DIMDI).

Studien, die für die Aufnahme ins Verzeichnis vorgelegt werden, [müssen] spätestens zwölf Monate nach Studienabschluss vollständig mit den Ergebnissen im Internet veröffentlicht werden. […]

Wichtig ist, dass auch negative Ergebnisse veröffentlicht werden.

DiGA-Leitfaden des BfArM

Diese Informationen sind auch für die Konkurrenz interessant. Wenn aus den Ergebnissen Rückschlüsse auf Geschäfts- und Betriebsgeheimnisse gezogen werden können, dürfen entsprechende Stellen geschwärzt werden.

8. Fazit

Zusammenfassung

Für die Hersteller mag es verlockend klingen, ihre DiGA von den Krankenkassen erstattet zu bekommen. Doch die DiGAV legt die Latte dafür sehr hoch:

  1. Die Hersteller müssen die Anforderungen an den Datenschutz anhand einer Checkliste nachweisen.
  2. Ihre Produkte müssen die Interoperabilität i.d.R. durch allgemein anerkannte Standards gewährleisten. Jemand, der noch nie von MIOs oder einer vesta-Liste gehört hat, wird sich damit sicher schwertun.
  3. Die Pflicht zur Durchführung von Studien mit der eigenen DiGA sowie die Pflicht, besser als alternative Produkte oder Verfahren zu sein, bedeutet für die Hersteller hohe Aufwände. Die Anforderungen durch die DiGAV sind höher als die Anforderung der MDR an die klinische Bewertung. Doch bereits bei der MDR klagen die Hersteller über die Aufwände.

Zustimmung und Kritik

Wer Geld von der Gesellschaft, sprich den Versicherten will, muss etwas leisten. Das ist gut so. Es ist zu befürworten, dass

  • relativ präzise Anforderungen an den Datenschutz gestellt werden,
  • der Zwang zu „standardisierten Standards“ zum Einreißen der Sektorengrenzen im Gesundheitswesen führen und damit dessen Effizienz (und hoffentlich auch Effektivität) erhöhen wird,
  • der Nutzen nachgewiesen sein muss und dass für Anwendungen mit fraglichem Nutzen kein öffentliches Geld ausgegeben wird – zumindest nicht dauerhaft.

Es bleiben aber Fragen offen:

  • Aus welchem Grund werden Produkte der Klassen IIb und III ausgeschlossen, die oft einen besonders hohen Nutzen haben?
  • Weshalb sind die Checklisten-Punkte zur IT-Sicherheit in der Anlage I der DiGAV nicht mit dem BSI TR-03161 abgeglichen?
  • Weshalb glaubt man, dass die Aussagekraft von Studien höher ist, wenn diese nur in Deutschland durchgeführt werden?
  • Wie soll ein Wettbewerb zwischen DiGA möglich sein, wenn es nicht erlaubt ist, eine „gleich gute“ DiGA ins Verzeichnis aufzunehmen?
  • Weshalb muss ein Hersteller besser als der Stand der Technik sein? Hersteller von Medizinprodukten müssen den medizinischen Nutzen bereits nachgewiesen haben.
  • Weshalb besteht die DiGAV auch bei Produkten, die nur einen medizinischen Nutzen und keine sonstigen positiven Versorgungsaspekte in Anspruch nehmen, auf neuen Studien?

Dass die Hürden so hoch gelegt wurden, ist eine politische Entscheidung, die mit Blick auf die Sicherheit von Patienten und sinnvolle Nutzung öffentliche Gelder nachvollziehbar ist.

Wer aber glaubt, dass die DiGAV dazu beitragen wird, dass kleine, innovative Startups rasch ein tragfähiges Geschäftsmodell entwickeln, wird enttäuscht werden. Die Anforderungen der Digitale-Gesundheitsanwendungen-Verordnung sind immens – und sie kommen on top zu den MDR-Anforderungen.

Danke an die Fachanwältin Sonia Seubert von Dierks + Company

Prof. Dr. Christian Johner
Das Johner Institut unterstützt Hersteller bei der Konzeption und Durchführung wissenschaftlicher Studien, die alle Anforderungen der DiGAV erfüllen. Nehmen Sie gleich Kontakt auf.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 5 / 5. Anzahl Bewertungen: 2

Geben Sie die erste Bewertung!


Kategorien: Gesundheitswesen, Regulatory Affairs
Tags:

6 Kommentare

  1. Hannes Meeves | Dienstag, 21. April 2020 um 11:03 Uhr - Antworten

    Lieber Herr Dr. Johner,
    sehr gern mache ich von Ihrem Angebot Gebrauch, Ihnen eine Frage zu stellen. Und ich möchte Ihnen danken, dass Sie uns mit Ihrem Newsletter mit wichtigen Informationen versorgen.

    Aussage:
    BSI TR-03161 Sicherheitsanforderungen an digitale Gesundheitsanwendungen
    Gegenstand der Technischen Richtlinie:

    Diese Technische Richtlinie wendet sich an Hersteller von digitalen Gesundheitsanwendungen für mobile Endgeräte. …

    Frage: immer wieder lese ich in Verordnungen, dass DiGa’s mit digigitalen Endgeräten verbunden werden und explizit auch so benannt werden. Das sind überwiegende Handys, manchmal auch Tablets.

    Wunsere DiGa ist aber eine Desktop-Anwendung (Browser-Software), funktioniert zwar auch auf dem Handy, da es aber erst ab 10“ Bildschirmgröße Sinn macht, sind Handy’s ungeeignet.
    Jetzt die genaue Frage:
    Wie umfassend oder ausschließend meint der Gesetzgeber hier „für mobile Endgeräte“? Sind Desktop-Computer nicht dabei? Werden Online-Anwendungen anders behandelt als Apps aus dem App-Shop?

    Danke vorab und mit besten Wünschen aus Hamburg
    Hannes Meeves
    040 72104688


    • Prof. Dr. Christian Johner | Dienstag, 21. April 2020 um 11:43 Uhr - Antworten

      Sehr geehrter Herr Meeves,

      danke für die spannende Frage!

      DiGAs umfassen definitiv auch „Nicht-Apps“ wie beispielsweise browserbasierte Anwenndungen.

      Dass die TR-03161 nur DiGAs für mobile Endgeräte adressiert, ändert daran nichts. Es ist nicht einmal gesagt, dass damit überhaupt DiGAs per definitionem des DVGs gemeint sind. Beispielsweise wäre für eine Klasse-III-App dieser Leitfaden ebenso anzuwenden.

      Danke für die Frage, die diese Klarstellung ermöglicht!

      Viele Grüße, Christian Johner


  2. Stefan Glaus | Dienstag, 21. April 2020 um 11:42 Uhr - Antworten

    Ein dickes Lob, Herr Johner !

    Auch wenn ich nur bedingt mit Ihrer Zielgruppe zu tun habe, leisten mir Ihre vorzüglich recherchierten Newsletter immer wieder gute Dienste bei Interpretation und Bewertung von regulativen Sachverhalten im engeren oder weiteren Kontext der jeweiligen Gesetzgebung.

    Mit freundlichem Gruss,

    Stefan Glaus


    • Prof. Dr. Christian Johner | Dienstag, 21. April 2020 um 11:45 Uhr - Antworten

      Danke, lieber Herr Glaus, für Ihre Rückmeldung!

      Ich freue mich riesig darüber! Das gibt Kraft und Motivation!

      Nochmals vielen Dank!


  3. Raimund Mödlhammer | Freitag, 18. September 2020 um 09:32 Uhr - Antworten

    Sehr geehrter Herr Johner,

    die DiGAV löst mMn auch die Anwendung der IEC 82304 aus – wie sehen Sie das? Haben Sie ggf. schon analysiert, ob/wo sich die DiGAV und die IEC 82304 ergänzen (oder vielleicht widersprechen)?

    Viele Grüße

    Raimund Mödlhammer


    • Prof. Dr. Christian Johner | Samstag, 19. September 2020 um 14:55 Uhr - Antworten

      Sehr geehrter Herr Mödlhammer,

      die DiGAV löst im Wesentlichen drei Dinge aus:

      1. Die Anforderungen der MDR
      2. Die Anforderungen an die IT-Security
      3. Die Anforderungen an den Nachweis positiver Versorgungseffekte

      Wenn, dann wäre es die MDR, die die IEC 82304 „auslöst“. Da es momentan aber keine harmonisierte Normen gibt, ist diese Frage umstritten. Die IEC 82304 ist allerdings im letzten Entwurf der Liste der zu harmonisierten Normen nicht mehr enthalten.

      Ein Auditor kann somit nur mit allgemeiner Bezugnahme zum Stand der Technik Anforderungen der IEC 82304 einbeziehen. Aber eine Konformität mit der Norm kann er nicht verlangen.

      Viele Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.