Am 21. April trat die DiGA-Rechtsverordnung in Kraft, und nur einen Tag später gab es mit dem DiGA-Summit des Health Innovation Hub des Bundesgesundheitsministeriums die große, dank COVID-19 natürlich virtuelle Launch-Veranstaltung, bei der vor rund 1700 Zuhörern diverse Referenten und Diskussionspartner aus halb Deutschland zusammengeschaltet wurden. Mit dabei waren vor allem Sophia Matenaar und Lars Hunze vom BMG sowie Karl Broch, Wiebke Löbker und Wolfgang Lauer vom BfArM.
Die Kurzzusammenfassung lautet, dass Hersteller von digitalen Gesundheitsanwendungen (DiGA) voraussichtlich ab Ende Mai 2020 einen Antrag auf Listung ihrer Anwendung beim BfArM stellen können. Denn dann wird das entsprechende Portal freigeschaltet. Gemäß DiGA-RV hat das BfArM drei Monate Zeit für den Bescheid, sodass Richtung August erste regulär erstattungsfähige DiGAs das deutsche Gesundheitswesen erreichen könnten. Noch verhandelt werden muss bis dahin eine Rahmenvereinbarung zwischen GKV Spitzenverband und den DiGA-Herstellerverbänden.
Die dient unter anderem dazu, die Preise der DiGAs im ersten Jahr des Fast-Tracks etwas einzuhegen. In diesem Zeitraum dürfen die Hersteller nämlich, ähnlich wie beim pharmazeutischen G-BA-Prozess, die Preise „frei“ festlegen. Völlig beliebig soll das nicht sein, dafür die Rahmenvereinbarung. Die endgültige Preisverhandlung zwischen GKV Spitzenverband und dem jeweiligen Hersteller erfolgt nach einem Jahr, wenn ein positiver Versorgungseffekt nachgewiesen ist. Einigen sich beide Seiten nicht, gibt es eine Schiedsstelle aus GKV Spitzenverband und Herstellerverbänden.
Nutzennachweis: Minimum retrospektive Studie
Eine der großen Fragen im Zusammenhang mit der DiGA-Listung beim BfArM war immer die des Nutzennachweises. Hier verschaffen DiGA-RV und der BfArM Leitfaden jetzt mehr Klarheit. Ein in Stein gegossenes Evidenzmodell gibt es nicht. Denkbar sind demnach viele verschiedene Arten von vergleichenden Studien in Abhängigkeit von der jeweiligen Anwendung und klinischen Situation. Minimum sei eine retrospektive Studie, und auch intraindividuelle Vorher-Nachher-Vergleiche seien denkbar, so Matenaar. Sie machte aber auch deutlich, dass nichts gegen prospektive oder randomisierte Studien spreche.
Das BfArM bekommt hier sehr viel Macht, denn die Behörde ist es letztlich, die den Studienplan jeder DiGA genehmigen und für verbindlich erklären muss. Gewünscht sind primär quantitative Endpunkte, also statistische Auswertungen von Morbiditäts-/Mortalitätsdaten oder quantitativ auswertbare, validierte Fragebögen zu Lebensqualität, Symptomen oder Adhärenz. Nicht ausreichend seien strukturierte Interviews mit interpretativer Auswertung, so Lauer. Diagnostische DiGAs benötigten außerdem zusätzlich zur vergleichenden Studie eine diagnostische Teststudie, die Rückschlüsse aud Sensitivität und Spezifität erlaube. Dies gelte auch, wenn die DiGA mit bereits validierten Fragebögen arbeite.
Interoperabilitätsvorgaben
Aus übergeordneter Sicht eines digitalen Gesundheitswesens interessant ist die Frage der technischen und semantischen Interoperabilität bei DiGAs. Auch hierauf ging Sophia Matenaar etwas detaillierter ein. Zu den Anforderungen gehört, dass die DiGA es Versicherten erlauben muss, therapierelevante Auszüge zu exportieren. Klassiker sei hier der Pdf-Auszug, der dem Arzt vorgelegt werden könne, so Matenaar.
Darüber hinaus müssen relevante DiGA-Inhalte künftig als maschinenlesbare, interoperable Datensätze exportierbar sein, das nicht zuletzt vor dem Hintergrund einer Schnittstelle zur elektronischen Patientenakte. Hier soll es verschiedene Möglichkeiten gebe. Wenn es ein(en) im Vesta-Verzeichnis der gematik empfohlenes/n Profil oder Standard gibt, ist dieses/r zu nutzen. Auch wenn bereits ein medizinisches Informationsobjekt (MIO) zu der jeweiligen Thematik existiert, soll es verwendet werden. Ist das nicht der Fall, können Datensätze mit Hilfe internationaler Standards definiert werden. Dann muss aber auch die Aufnahme ins Vesta-Verzeichnis beantragt werden.
Ähnliches gilt für die Anbindung medizinischer Geräte und Sensoren. Hier ist primär ISO 11073 als Standard vorgesehen, alternativ ein im Vesta-Verzeichnis niedergelegter Kommunikationsstandard, sofern vorhanden. Wird eine eigene Schnittstelle entwickelt, muss dafür die Aufnahme in Vesta beantragt werden.
