Zum Inhalt springen
MARCODES
Abstrakte Formen aus Mattglas: ein kleiner oranger Kern in mehreren ineinanderliegenden Schutzschalen

Gesundheitsdaten in Webanwendungen: Art. 9 DSGVO technisch umsetzen

Eine Webanwendung mit Gesundheitsdaten braucht eine Rechtsgrundlage nach Art. 9 DSGVO, verschlüsselte Datenbankfelder, enge Zugriffsrechte, Protokolle, Löschfristen und einen Vertrag zur Auftragsverarbeitung. Bei umfangreicher Verarbeitung kommt eine Datenschutz-Folgenabschätzung dazu.

11 min Lesezeit Branchen und Praxis

Die Datenschutz-Grundverordnung (DSGVO) verbietet die Verarbeitung von Gesundheitsdaten grundsätzlich und erlaubt sie nur in den Ausnahmen des Art. 9 Abs. 2. Wer eine Anwendung für Patienten, Praxen oder Versicherte baut, muss deshalb zwei Fragen beantworten, bevor die erste Tabelle entsteht: Auf welche Ausnahme stützt sich die Verarbeitung, und mit welchen Maßnahmen wird sie abgesichert? Die zweite Frage ist Aufgabe der Entwicklung, und um sie geht es in diesem Beitrag.

Gesundheitsdaten sind weiter gefasst als Diagnosen und Befunde. Dazu zählen auch ein Termin beim Facharzt, eine Pulsmessung aus einer Fitness-App oder die Notiz im Kontaktformular, dass jemand nach einer Operation keine Treppen steigen kann.

Wo wir im Gesundheitswesen arbeiten, von Patientenportalen bis zu Schnittstellen nach FHIR, steht auf der Seite Software für das Gesundheitswesen.

Schutzniveau

Warum Gesundheitsdaten besonders geschützt sind

Art. 4 Nr. 15 DSGVO definiert Gesundheitsdaten als personenbezogene Daten, die sich auf die körperliche oder geistige Gesundheit einer Person beziehen, einschließlich der Erbringung von Gesundheitsdienstleistungen, und aus denen Informationen über deren Gesundheitszustand hervorgehen. Art. 9 Abs. 1 zählt sie zu den besonderen Kategorien personenbezogener Daten, neben genetischen und biometrischen Daten, religiösen Überzeugungen und einigen weiteren.

Eine offengelegte Diagnose kann Arbeitsplatz, Versicherung und Ruf einer Person treffen und lässt sich nicht zurückholen. Art. 32 DSGVO verlangt Maßnahmen, die dem Risiko angemessen sind, und dieses Risiko ist bei Gesundheitsdaten von vornherein hoch.

Für Deutschland ergänzt § 22 Bundesdatenschutzgesetz (BDSG) die Regeln. Abs. 2 nennt zehn Maßnahmen, die ein Verantwortlicher bei solchen Daten vorsehen muss, darunter Protokollierung, Zugangsbeschränkung, Pseudonymisierung und Verschlüsselung. Für die Entwicklung ist diese Liste die konkreteste Vorgabe.

Auf EU-Ebene laufen zwei Vorhaben, die das Thema berühren. Die Verordnung (EU) 2025/327 über den europäischen Gesundheitsdatenraum (EHDS) ist am 26.03.2025 in Kraft getreten. Ihre Pflichten gelten gestaffelt, der Austausch von Patientenkurzakten und E-Rezepten ab März 2029, weitere Datenkategorien ab März 2031. Daneben hat die EU-Kommission am 19.11.2025 mit dem Digital Omnibus (COM(2025) 837) Änderungen an der DSGVO vorgeschlagen, die auch Art. 9 betreffen. Das Verfahren 2025/0360(COD) läuft, beschlossen ist bis zum 24.06.2026 nichts.

Einwilligung

Rechtsgrundlage und Einwilligung im Ablauf

Für Anwendungen kommen vor allem zwei Ausnahmen infrage. Art. 9 Abs. 2 lit. h erlaubt die Verarbeitung für Gesundheitsvorsorge, Diagnostik und Versorgung, wenn Fachpersonal mit Berufsgeheimnis sie verantwortet (Art. 9 Abs. 3). Das trifft auf die Software einer Praxis oder Klinik zu, § 22 Abs. 1 Nr. 1 lit. b BDSG greift den Gedanken auf. Wer dagegen eine Gesundheits-App direkt für Verbraucher anbietet, stützt sich meist auf die ausdrückliche Einwilligung nach Art. 9 Abs. 2 lit. a.

Welche Ausnahme gilt, entscheidet der Verantwortliche mit seiner Rechtsberatung. Die Software muss die Entscheidung aber abbilden können:

  • Einwilligung als Datensatz: Wer wann welcher Fassung welches Textes zugestimmt hat, steht in einer eigenen Tabelle, nicht als Häkchen in der Nutzertabelle.

  • Zweck je Einwilligung: Eine Zustimmung zur Terminverwaltung deckt keine Auswertung für Forschung. Die Anwendung speichert den Zweck mit.

  • Widerruf: Nach Art. 7 Abs. 3 muss er so leicht sein wie die Erteilung, also ein Knopf im Konto und ein Ablauf, der die betroffenen Daten sperrt oder löscht.

Ausdrücklich bedeutet in der Umsetzung eine eigene, aktive Erklärung für die Gesundheitsdaten, getrennt vom allgemeinen Häkchen zur Datenschutzerklärung.

Ein Karteikasten mit Patientenkarten, abgeschlossen, im Schloss steckt der orange Schlüssel.

Absicherung

Verschlüsselung, Zugriff und Protokolle

Verschlüsselung, Zugriffsrechte und Protokolle bilden zusammen den Kern der Maßnahmen nach Art. 32 DSGVO und § 22 Abs. 2 BDSG. Sie greifen ineinander: Die Verschlüsselung schützt vor Zugriffen an der Anwendung vorbei, die Rechte regeln den Zugriff durch die Anwendung, und das Protokoll weist nach, wer zugegriffen hat.

Verschlüsselung bis ins Feld

TLS und verschlüsselte Datenträger schützen nicht davor, dass jemand mit Datenbankzugang oder eine kopierte Sicherung Diagnosen im Klartext liest. Felder mit Gesundheitsangaben gehören deshalb zusätzlich verschlüsselt in die Datenbank.

In Laravel 13 erledigen das die Casts encrypted, encrypted:array und encrypted:object im Model. Laravel verschlüsselt mit dem Schlüssel der Anwendung, in der Standardkonfiguration mit AES-256-CBC, und signiert jeden Wert mit einem Message Authentication Code. Die Dokumentation nennt zwei Folgen, die man vorher kennen muss: Die Spalte braucht den Typ TEXT oder größer, weil der verschlüsselte Wert länger ist als der Klartext. Und verschlüsselte Felder lassen sich nicht durchsuchen oder in Abfragen filtern.

Daraus folgt eine Entscheidung im Entwurf. Soll die Anwendung einen Patienten über die Versichertennummer finden, speichert man daneben einen Suchschlüssel, einen mit eigenem Geheimnis gebildeten Hash der normalisierten Nummer. Die Suche vergleicht Hashes, die Nummer selbst bleibt verschlüsselt. Für Freitext wie Anamnese-Notizen gibt es diesen Weg nicht, dort entfällt die Volltextsuche in der Datenbank. Der Schlüssel liegt nie im selben Backup wie die Datenbank. Für einen Schlüsselwechsel kennt Laravel die Einstellung APP_PREVIOUS_KEYS, mit der alte Werte lesbar bleiben, bis sie neu verschlüsselt sind.

Zugriff nach Rolle und Datensatz

Ein Mitarbeiter am Empfang darf Termine aller Patienten sehen, Befunde aber nur dort, wo er an der Behandlung beteiligt ist. In Laravel bilden Policies solche Regeln je Datensatz ab. Dazu kommen Zwei-Faktor-Anmeldung für alle Konten mit Zugriff auf Gesundheitsdaten und ein eigener Datenbankbenutzer für die Anwendung, der Daten lesen und schreiben, aber keine Tabellen löschen oder ändern darf. Migrationen laufen mit einem zweiten Benutzer, der nur beim Ausrollen verwendet wird.

Protokolle, die selbst nichts verraten

§ 22 Abs. 2 Nr. 2 BDSG verlangt, dass sich nachträglich feststellen lässt, ob und von wem Daten eingegeben, verändert oder entfernt wurden. Ein Audit-Trail in einer eigenen Tabelle hält dafür Person, Zeitpunkt, Datensatz und Art der Änderung fest. Der Datenbankbenutzer der Anwendung darf in diese Tabelle nur schreiben, nicht ändern oder löschen. Bei Patientenakten empfiehlt es sich, auch das Öffnen eines Datensatzes zu protokollieren, weil sich unbefugtes Lesen sonst nicht nachweisen lässt.

Umgekehrt dürfen Fehlerprotokolle und Fehlerdienste keine Gesundheitsdaten enthalten. Eine Ausnahme, die den kompletten Request mit Formulardaten mitschreibt, legt Befunde im Klartext in eine Logdatei oder bei einem externen Dienst ab. Sensible Felder werden deshalb vor dem Protokollieren ausgeblendet.

Betrieb

Hosting und Auftragsverarbeitung

Die DSGVO schreibt keinen Serverstandort in Deutschland vor. Sie verlangt einen Vertrag nach Art. 28 mit jedem Dienstleister, der Daten im Auftrag verarbeitet, und für Übermittlungen in Drittländer die Voraussetzungen der Art. 44 ff. Einen Auftragsverarbeitungsvertrag braucht deshalb jeder Dienst, der Daten sieht, vom Hoster über Mailversand und Fehlertracking bis zum Backup-Speicher.

Für Ärzte, Krankenhäuser und andere Leistungserbringer der gesetzlichen Krankenversicherung gilt zusätzlich § 393 SGB V. Er erlaubt Cloud-Computing-Dienste für Sozial- und Gesundheitsdaten nur im Inland, in der EU und gleichgestellten Staaten oder in Drittstaaten mit Angemessenheitsbeschluss, und nur mit einer Niederlassung des Anbieters im Inland. Dazu verlangt das Gesetz ein Testat nach dem Kriterienkatalog C5 des Bundesamts für Sicherheit in der Informationstechnik (BSI). Seit dem 01.07.2025 muss es nach § 393 Abs. 4 SGB V grundsätzlich ein C5-Testat vom Typ 2 sein, das die Wirksamkeit der Kontrollen über einen Zeitraum prüft. Für Systeme, die nach dem 30.06.2025 erstmals in Verkehr gebracht werden, genügt in den ersten 18 Monaten ein Testat vom Typ 1, ab dem 19. Monat gilt Typ 2. Derselbe Absatz lässt außerdem Testate oder Zertifikate nach anderen Standards zu, wenn sie ein vergleichbares oder höheres Sicherheitsniveau gewährleisten. Nicht jeder Hoster hat ein solches Testat. Ob ein gemieteter Server als Cloud-Dienst im Sinne der Vorschrift gilt, klärt der Verantwortliche mit seinem Datenschutzbeauftragten.

Die Anwendungen, die wir betreuen, hosten wir bei Hetzner in Deutschland, wie auf der Seite Hosting beschrieben. Hetzner hat laut eigener Mitteilung vom 25.03.2026 ein C5-Testat vom Typ 2 erhalten. Welche Dienste und Standorte es abdeckt, steht im Prüfbericht; prüfen Sie dort, ob der genutzte Dienst dazugehört. Welche Anbieter rechtlich und organisatorisch in der EU bleiben und welche nur Rechenzentren dort haben, erklärt der Beitrag EU-Hosting: Mehr als nur Schrems II.

Datenmodell

Datensparsamkeit schon im Datenmodell

Art. 25 DSGVO verlangt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Im Datenmodell heißt das: Jede Spalte mit Gesundheitsbezug braucht einen Zweck, und was keinen Zweck hat, wird nicht angelegt.

  • Trennen: Stammdaten wie Name und Adresse liegen in anderen Tabellen als medizinische Angaben und sind nur über eine interne Kennung verbunden. Auswertungen arbeiten nur mit der Kennung. Das ist Pseudonymisierung im Sinne des Art. 4 Nr. 5 DSGVO, solange die Zuordnung getrennt geschützt ist.

  • Fristen im Modell: Jede Datenart bekommt eine Löschfrist als Feld oder Regel, und ein geplanter Auftrag löscht nach Ablauf. Für die ärztliche Behandlungsdokumentation gilt dabei eine Aufbewahrung von zehn Jahren nach Abschluss der Behandlung (§ 630f Abs. 3 BGB), für Terminanfragen ohne Behandlung eine deutlich kürzere.

  • Nur abfragen, was gebraucht wird: Das gilt für Formulare ebenso wie für Schnittstellen zu Geräten.

Ein Beispiel für den letzten Punkt: Für KIWI Health haben wir 2025 ein Capacitor-Plugin gebaut, das die Hybrid-App des Kunden an Android Health Connect anschließt. Health Connect vergibt Berechtigungen getrennt nach Datentyp und nach Lesen oder Schreiben, etwa für Herzfrequenz, Schlaf oder Blutzucker. Eine App fragt deshalb nur die Typen an, die ihr Zweck verlangt.

Abgleich

Was das Gesetz verlangt und was die Anwendung tut

Die Übersicht stellt Vorgaben und technische Maßnahmen gegenüber und taugt als Gerüst für die Beschreibung der technischen und organisatorischen Maßnahmen.

Was die DSGVO verlangt Umsetzung in der Webanwendung
Verschlüsselung Art. 32 Abs. 1 lit. a DSGVO und § 22 Abs. 2 Nr. 7 BDSG nennen Verschlüsselung als Maßnahme TLS für alle Verbindungen, Casts encrypted in Laravel 13 für Befund- und Freitextfelder, verschlüsselte Backups, Schlüssel getrennt von der Datenbank
Pseudonymisierung Art. 32 Abs. 1 lit. a DSGVO und § 22 Abs. 2 Nr. 6 BDSG Stammdaten und medizinische Daten in getrennten Tabellen, Auswertungen nur über interne Kennungen
Zugriff Art. 25 Abs. 2 DSGVO, § 22 Abs. 2 Nr. 5 BDSG beschränkt den Zugang Policies je Datensatz, Zwei-Faktor-Anmeldung, eigener Datenbankbenutzer ohne Rechte zum Löschen von Tabellen
Protokolle § 22 Abs. 2 Nr. 2 BDSG verlangt nachprüfbare Eingaben, Änderungen und Löschungen Audit-Log mit reinem Schreibrecht, Protokoll auch für das Öffnen von Akten, keine Gesundheitsdaten in Fehlerprotokollen
Löschung Art. 5 Abs. 1 lit. e und Art. 17 DSGVO, Aufbewahrung nach § 630f Abs. 3 BGB Löschfrist je Datenart im Datenmodell, geplanter Löschauftrag mit Protokoll, Backups mit begrenzter Laufzeit
Wiederherstellung Art. 32 Abs. 1 lit. b und c DSGVO verlangen Verfügbarkeit und rasche Wiederherstellung Tägliche Sicherung an einem zweiten Standort, regelmäßig geprobte Rücksicherung
Hosting Art. 28 und Art. 44 ff. DSGVO, für Leistungserbringer der GKV § 393 SGB V Server in der EU, Vertrag zur Auftragsverarbeitung mit jedem Dienst, C5-Testat prüfen, wo § 393 SGB V greift
Folgenabschätzung Art. 35 Abs. 3 lit. b DSGVO und Muss-Liste der Datenschutzkonferenz Datenflüsse, Risiken und diese Maßnahmen vor dem Bau dokumentieren und bei Änderungen fortschreiben

Kurz beantwortet

Häufige Fragen

  • Die DSGVO verbietet das nicht, sie verlangt einen Vertrag zur Auftragsverarbeitung, angemessene Sicherheit und bei Anbietern außerhalb der EU die Regeln für Drittlandübermittlungen. Für Leistungserbringer der gesetzlichen Krankenversicherung setzt § 393 SGB V engere Grenzen: Standort in der EU oder gleichgestellten Staaten, Niederlassung im Inland und seit dem 01.07.2025 grundsätzlich ein C5-Testat vom Typ 2, für neu in Verkehr gebrachte Systeme in den ersten 18 Monaten Typ 1. Prüfen Sie deshalb zuerst, ob Ihre Organisation unter diese Vorschrift fällt.

  • Sobald Besucher im Formular Beschwerden oder Befunde schildern können, landen Gesundheitsdaten auf Ihrem Server und in Ihrem Postfach. Fragen Sie im Formular deshalb nur ab, was Sie für die Rückmeldung brauchen, übertragen Sie es verschlüsselt und löschen Sie Anfragen nach einer festen Frist. Für Terminbuchungen mit Angabe des Behandlungsgrunds gelten dieselben Maßnahmen wie für eine Anwendung.

  • Das ist eine dokumentierte Prüfung vor dem Start einer Verarbeitung: welche Daten wohin fließen, welche Risiken für die Betroffenen entstehen und welche Maßnahmen sie senken. Art. 35 DSGVO verlangt sie unter anderem bei umfangreicher Verarbeitung von Gesundheitsdaten. Die Muss-Liste der Datenschutzkonferenz nennt zusätzlich Telemedizin mit Sensoren und die zentrale Speicherung von Messdaten aus Fitnessarmbändern, auch wenn die Verarbeitung nicht umfangreich ist.

  • Die Verschlüsselung der Festplatte schützt vor dem Diebstahl eines Datenträgers, nicht vor einem Zugriff über Anwendung oder Datenbank, denn dort liegen die Daten entschlüsselt vor. Für Gesundheitsangaben empfehlen wir zusätzlich die Verschlüsselung einzelner Felder.

Anwendung mit Gesundheitsdaten planen

Wir prüfen mit Ihnen Datenmodell, Rechte, Protokolle und Hosting Ihrer Anwendung, bevor Patientendaten darin landen.

Mehr zu Software für das Gesundheitswesen

Nachweise

Quellen und Stand

Stand: 24.06.2026. Der Beitrag beschreibt technische Maßnahmen zu den genannten Vorschriften in der Fassung zu diesem Datum und ist keine Rechtsberatung. Ob und auf welcher Grundlage Ihre Organisation Gesundheitsdaten verarbeiten darf, klären Sie mit Ihrem Datenschutzbeauftragten oder einem Rechtsanwalt.

Weiterlesen: Passkeys in Webanwendungen vom 06.07.2026.

Artikel teilen