Gesundheits-Apps barrierefrei: DiGA-Pflichten nach SGB V

Der Leistungsanspruch entsteht eng geführt. Nach § 33a Absatz 1 SGB V haben Versicherte Anspruch auf Medizinprodukte niedriger und höherer Risikoklasse, deren Hauptfunktion wesentlich auf digitalen Technologien beruht, und der Anspruch umfasst nur solche Anwendungen, die vom Bundesinstitut für Arzneimittel und Medizinprodukte in das Verzeichnis nach § 139e SGB V aufgenommen wurden und entweder ärztlich verordnet oder von der Krankenkasse genehmigt sind. Wer eine DiGA in die Erstattung bringen will, führt also ein Verwaltungsverfahren, kein Marketingprojekt – mit denselben Nachweispflichten, die auch sonst im Gesundheitswesen gelten.

Parallel dazu läuft eine zweite Linie, die mit dem Verzeichnis nichts zu tun hat. Das Barrierefreiheitsstärkungsgesetz gilt nach § 1 Absatz 3 BFSG für Dienstleistungen, die für Verbraucher nach dem 28. Juni 2025 erbracht werden, und führt in Nummer 5 der dortigen Aufzählung die Dienstleistungen im elektronischen Geschäftsverkehr auf. Eine Gesundheits-App mit Registrierung, Einwilligung, Abonnementverwaltung oder Direktkauf bewegt sich damit in beiden Rechtskreisen zugleich. Welche Pflichten daraus für native Anwendungen folgen, ist im Beitrag zu den BFSG-Pflichten für iOS und Android im Detail beschrieben.

Das Sozialgesetzbuch selbst ist an anderer Stelle deutlicher als die DiGAV. § 341 Absatz 1 SGB V bestimmt für die elektronische Patientenakte, dass den Versicherten Informationen zu Befunden, Diagnosen, durchgeführten und geplanten Therapiemaßnahmen sowie zu Behandlungsberichten barrierefrei elektronisch bereitgestellt werden sollen. Das Wort steht im Normtext, nicht in einer Begründung. Sobald eine DiGA Daten in die Akte einstellt oder aus ihr liest, berührt sie diese Linie.

Noch konkreter wird § 342 SGB V zur Benutzeroberfläche der Akte. Absatz 7 verpflichtet die Krankenkassen, spätestens bis zum 1. Januar 2022 sicherzustellen, dass Versicherte ihre Rechte und das Auslesen der Protokolldaten barrierefrei mittels einer Benutzeroberfläche sowohl eines geeigneten mobilen Endgeräts als auch eines geeigneten stationären Endgeräts wahrnehmen können. Zwei Endgerätearten, ausdrücklich benannt: Die Anforderung ist damit nicht auf die Handyansicht beschränkt. Für das Antragsverfahren gilt zugleich die Frist aus § 139e Absatz 3 SGB V, nach der das BfArM innerhalb von drei Monaten nach Eingang der vollständigen Antragsunterlagen entscheidet und die Frist in begründeten Einzelfällen um bis zu weitere drei Monate verlängert werden kann.

Eine DiGA hat eine Eigenheit, die sie von einem gewöhnlichen Onlineangebot unterscheidet: Der wertvollste Teil liegt hinter der Anmeldung. Die Einlösung des Freischaltcodes, die Einwilligung in die Datenverarbeitung, die tägliche Dokumentation und der Export für die Behandlerin sind Strecken, die ein Prüfwerkzeug von außen nicht sieht. Wie man solche Bereiche systematisch erfasst, beschreibt der Beitrag zum Prüfen von Login-Bereichen.

Der zweite Unterschied ist die Anmeldung selbst. Gesundheitsdaten verlangen ein Verfahren mit hohem Sicherheitsstandard, und genau dort entstehen typischerweise die härtesten Barrieren: Einmalcodes mit knapper Frist, Bildrätsel, Wischgesten zur Identifikation. Welche Alternativen sich ohne Absenkung des Schutzniveaus umsetzen lassen, ist im Beitrag zu barrierefreier Authentifizierung beschrieben. Ob die Strecke am Ende trägt, zeigt in der Regel erst ein Screenreader-Test auf beiden Plattformen.

Die häufigsten Befunde in Gesundheits-Apps entstehen an der Werteingabe. Ein Feld ohne verknüpfte Beschriftung, eine Einheit, die nur visuell danebensteht, und eine Fehlermeldung, die weder mit dem Feld verbunden noch angekündigt wird: Diese drei Fehler zusammen machen eine tägliche Dokumentation für Screenreader-Nutzer unbrauchbar. Das folgende Muster verbindet Beschriftung, Einheit, Hinweis und Fehler mit dem Feld und meldet den Fehler zusätzlich an assistive Technik.

Drei Punkte tragen dieses Muster. Die Beschriftung ist über das Attribut for mit dem Feld verbunden, sodass sie beim Fokus vorgelesen wird. Die Einheit steht sichtbar daneben und zusätzlich im Hinweistext, weil ein rein visuelles Kürzel für die Sprachausgabe verloren geht. Die Fehlermeldung nennt den unzulässigen Wert und den erlaubten Bereich, statt nur auf einen Fehler hinzuweisen; mit der Rolle alert erreicht sie den Bildschirmausleser auch dann, wenn der Fokus im Feld bleibt. Der zweite häufige Befund liegt daneben in der Darstellung: Gesundheits-Apps setzen Schriftgrößen gern fest, damit Diagramme und Skalen nicht verrutschen, und verhindern damit die Vergrößerung, auf die ein Teil der Zielgruppe angewiesen ist. Der folgende Ansatz koppelt die Typografie an die Nutzereinstellung des Systems, gibt Tippzielen eine Mindestgröße und respektiert die Systemeinstellung für reduzierte Bewegung.

Beide Muster sind bewusst schlicht gehalten, weil sie im Audit nicht durch Eleganz überzeugen müssen, sondern durch Nachvollziehbarkeit. Ein Prüfbericht ordnet jeden Befund einer Stelle im Code zu; je einfacher die Stelle, desto kürzer der Weg von der Feststellung zur Behebung. Wer Barrierefreiheit erst nach dem Bescheid angeht, verhandelt dieselben Änderungen unter Zeitdruck und mit einem laufenden Anzeigeverfahren im Rücken. Wer vertragliche Folgen mitdenken will, findet die Abnahme- und Mängelseite im Beitrag zu Barrierefreiheit im Vertrag; wie dieselbe Logik in einer ganz anderen Branche wirkt, zeigt der Beitrag zur barrierefreien Hotelbuchung.