GeDIG-Entwurf: Was sich bei C5, Wartungszugriffen und Meldepflichten für Gesundheitssoftware ändert

Am 30. September 2026 hat die Bundesregierung den Entwurf eines Gesetzes für Daten und digitale Innovation im Gesundheitswesen in den Bundestag eingebracht (Drucksache 21/8279, Kurzbezeichnung laut Bundesgesundheitsministerium: GeDIG). Die erste Lesung war am 8. Oktober, die öffentliche Anhörung im Ausschuss für Gesundheit am 14. Oktober 2026. Beschlossen ist das Gesetz noch nicht.

Der Entwurf ist umfangreich, für die Informationssicherheit sind aber vor allem vier Punkte wichtig. Er klärt, wann ein Wartungs- oder Supportzugriff unter die Cloud-Regeln des § 393 SGB V und damit unter die C5-Pflicht fällt. Er erlaubt im Krankenhaus tätigen Leistungserbringern, unter Bedingungen private Endgeräte für die Übermittlung medizinischer und pflegerischer Daten zu nutzen. Er macht Hersteller von Systemen mit Anbindung an die Telematikinfrastruktur gegenüber der gematik meldepflichtig, mit Bußgeldern bei Verstößen. Und er bestimmt das BSI als Marktüberwachungsbehörde für EHR-Systeme. Dieser Beitrag ordnet diese Punkte fachlich ein. Er ist keine Rechtsberatung, und alle Aussagen zu künftigen Pflichten stehen unter dem Vorbehalt des laufenden Verfahrens.

Kontext: § 393 SGB V und was der Entwurf daran ändert

Ausgangslage: C5-Testat für Gesundheitsdaten in der Cloud

§ 393 SGB V regelt, unter welchen Bedingungen Leistungserbringer, Kranken- und Pflegekassen und ihre Auftragsverarbeiter Sozial- und Gesundheitsdaten in Cloud-Diensten verarbeiten dürfen. Verlangt werden unter anderem ein zulässiger Verarbeitungsort, eine Niederlassung im Inland, Maßnahmen nach dem Stand der Technik und ein aktuelles C5-Testat der datenverarbeitenden Stelle. Seit dem 1. Juli 2025 gilt grundsätzlich nur noch ein C5-Typ-2-Testat als aktuell; für Systeme, die nach dem 30. Juni 2025 erstmals in Verkehr gebracht wurden, genügt in den ersten 18 Monaten ein Typ-1-Testat. Was das in der Praxis bedeutet, haben wir in einem eigenen Beitrag zu § 393 SGB V beschrieben.

Nicht ausdrücklich geregelt war bisher, wie Wartung und Support zu behandeln sind. Wenn ein Dienstleister zur Fehleranalyse auf ein Cloud-System zugreift, verarbeitet er dann selbst Gesundheitsdaten im Sinne des § 393, mit allen Anforderungen an Standort, Niederlassung und Testat? Laut Begründung soll der Entwurf hier Rechtssicherheit für etablierte Wartungs- und Supportprozesse schaffen.

Neu: Wartungszugriffe mit technisch verschlossenen Daten

Der Entwurf ergänzt § 393 Abs. 1 um einen Satz 2. Ein Zugriff zu Wartungs- und Supportzwecken gilt danach nicht als Cloud-Verarbeitung, wenn technische Vorkehrungen nach dem Stand der Technik, insbesondere Verschlüsselung, sicherstellen, dass die Daten dabei nicht zur Kenntnis genommen oder anders verarbeitet werden können.

Die Begründung zieht die Grenze genau:

• Den Ausschlag gibt der technische Schutz. Die Ausnahme gilt für Zugriffe zu Wartungs- und Supportzwecken; laut Begründung kommt es dabei allein darauf an, ob die Daten technisch nachweisbar unzugänglich bleiben. Verschlüsselung reicht nur, wenn die zugreifende Stelle keine Mittel zur Entschlüsselung hat. Rein organisatorische oder vertragliche Zusagen genügen nicht.
• Andere Verfahren sind möglich. Genannt werden vertrauenswürdige Ausführungsumgebungen, eine wirksame Trennung der Wartungsumgebung vom produktiven Datenbestand und Tokenisierung. Die Aufzählung ist offen.
• Die Ausnahme reicht nur so weit wie der Schutz. Für technisch verschlossene Zugriffe müssen die Anforderungen der Absätze 2 bis 4 (Verarbeitungsort, Niederlassung im Inland, technische und organisatorische Maßnahmen, C5-Testat) nicht gesondert erfüllt werden; für den Cloud-Dienst selbst gelten sie unverändert. Wartung ist damit nach der Begründung auch standortunabhängig möglich. Die Vorschriften des SGB X und des Bundesdatenschutzgesetzes bleiben unberührt (§ 393 Abs. 8 SGB V), die DSGVO gilt ohnehin. Bleiben die Daten nicht durchgängig verschlossen, gilt § 393 mit allen Anforderungen. Die auf dem C5-Testat beruhende Sicherheitslogik soll ausdrücklich erhalten bleiben.
• Ein Umzug in die Cloud soll keine Neubewertung der Wartung auslösen. Die Migration von On-Premise in die Cloud soll nicht allein wegen des Hosting-Wechsels zu einer anderen sicherheitstechnischen Bewertung etablierter Support- und Wartungsprozesse führen.

Neu: Cloud-Nutzung für bestimmte Abrechnungsstellen

Nach § 295a SGB V-E dürfen Stellen, die mit der Abrechnung von Leistungen aus Verträgen nach §§ 73b, 132e, 132f und 140a SGB V oder von ambulanten Notfallleistungen der Krankenhäuser beauftragt sind, künftig Cloud-Dienste nutzen. Voraussetzung ist, dass sie die Anforderungen des § 393 entsprechend erfüllen, also auch ein C5-Testat vorweisen. Das bisherige generelle Verbot von Unterauftragsverhältnissen entfällt zugunsten der allgemeinen Regeln zur Auftragsverarbeitung.

Neu: Private Endgeräte im Krankenhaus

Mit § 363f SGB V-E schafft der Entwurf eine Rechtsgrundlage dafür, dass im Krankenhaus tätige Leistungserbringer private Endgeräte, etwa das eigene Smartphone, zur Übermittlung medizinischer und pflegerischer Daten nutzen können. Die Nutzung ist an drei Bedingungen geknüpft:

• Die Übermittlung läuft über ein sicheres Übermittlungsverfahren der TI mit zugelassenen Diensten und Anbietern. Als solche Verfahren nennt § 363a SGB V-E insbesondere den Sofortnachrichtendienst (TI-Messenger) und den sicheren E-Mail-Dienst (KIM).
• Die Rahmenbedingungen der gematik für Inhalte und Nutzung des Verfahrens werden eingehalten.
• Für die Nutzung der privaten Geräte sind angemessene technische und organisatorische Maßnahmen nach dem Stand der Technik im Sinne von Art. 32 DSGVO getroffen.

Maßnahmen zur Informationssicherheit gelten als angemessen, wenn die entsprechenden Anforderungen des branchenspezifischen Sicherheitsstandards für die informationstechnische Sicherheit der Gesundheitsversorgung im Krankenhaus nach § 391 Abs. 4 SGB V oder gleichwertige Anforderungen erfüllt sind. Für die datenschutzrechtliche Seite sieht der Entwurf keine solche Vermutung vor. Welche Voraussetzungen die Geräte selbst erfüllen müssen, legt die Deutsche Krankenhausgesellschaft im Benehmen mit dem BSI und der oder dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit fest. Eine Frist dafür nennt der Entwurf nicht.

Hersteller: Meldepflichten gegenüber gematik und BSI

Für Hersteller von Praxisverwaltungs- und Krankenhausinformationssystemen bringt der Entwurf zwei Aufsichtsstränge.

gematik: Nach § 329 Abs. 2 SGB V-E müssen auch Anbieter und Hersteller von Systemen mit Schnittstellen zur Telematikinfrastruktur (TI) erhebliche Störungen unverzüglich der gematik melden und unverzüglich Maßnahmen zur Beseitigung ergreifen. Erheblich sind insbesondere Störungen, die Integrität, Authentizität, Vertraulichkeit, Funktionsfähigkeit oder Betriebsstabilität der TI beeinträchtigen oder beeinträchtigen können. Die gematik kann Auskunft über Ursachen und Maßnahmen verlangen, Systeme für den TI-Zugang sperren und nach § 333 Abs. 3 verbindliche Anweisungen zur Beseitigung von Sicherheitsmängeln erteilen, die sie oder das BSI festgestellt haben. Verstöße gegen Meldepflicht, Maßnahmenpflicht, Auskunftspflicht oder solche Anweisungen werden für diese Hersteller nach § 397 Abs. 2a SGB V-E bußgeldbewehrt. Der Bußgeldrahmen nach dem unveränderten § 397 Abs. 3 SGB V liegt bei bis zu 300.000 Euro, Bußgeldbehörde ist wie bisher das BSI. Als Anlass nennt die Begründung fehlerhafte Implementierungen in Praxisverwaltungssystemen, die zu Ausfällen etwa beim E-Rezept führen können.

BSI: Nach § 383b SGB V-E wird das BSI Marktüberwachungsbehörde nach der Verordnung (EU) 2025/327 über den europäischen Gesundheitsdatenraum (EHDS). Die Verordnung behandelt EHR-Systeme als Produkte. Gemeint ist Software, mit der Gesundheitsdaten der prioritären Kategorien gespeichert, übermittelt, importiert, exportiert, konvertiert, bearbeitet oder angezeigt werden und die der Hersteller für die Patientenversorgung oder den Patientenzugang bestimmt hat. Hersteller brauchen eine technische Dokumentation, eine EU-Konformitätserklärung, eine CE-Kennzeichnung und eine Registrierung. Schwerwiegende Vorkommnisse sind spätestens drei Tage nach Kenntnis zu melden, NIS2-Meldepflichten bleiben unberührt. Soweit ein EHR-System zugleich ein Produkt mit digitalen Elementen im Sinne des Cyber Resilience Act ist, weist der Hersteller die CRA-Grundanforderungen über das Konformitätsbewertungsverfahren des EHDS nach und erstellt eine gemeinsame technische Dokumentation (Art. 104 EHDS).

Betroffenheit: wen es trifft und ab wann

Cloud- und SaaS-Anbieter mit Gesundheitsdaten betrifft vor allem die neue Wartungsregel. Zwei vereinfachte Beispiele, die keine Prüfung im Einzelfall ersetzen:

• Ein Support-Team kann sich zur Fehleranalyse mit Administratorrechten an der Kundendatenbank anmelden und Datensätze lesen. Die Daten sind dann erreichbar. Nach der Begründung bleibt es in diesem Fall bei § 393 mit allen Anforderungen, also auch bei Verarbeitungsort, Niederlassung und C5-Testat für diesen Zugriff.
• Das Support-Team arbeitet in einer getrennten Wartungsumgebung und sieht nur verschlüsselte oder tokenisierte Daten, die Schlüssel liegen ausschließlich beim Betreiber des Produktivsystems. Dann kommt die neue Ausnahme in Betracht, nach der Begründung auch standortunabhängig. Datenschutzrechtliche Vorgaben, etwa für Übermittlungen in Drittstaaten, bleiben davon unberührt. Der Anbieter muss belegen können, dass dieser Schutz durchgängig greift.

Abrechnungsdienstleister im Anwendungsbereich des § 295a können künftig Cloud-Dienste nutzen, brauchen dafür aber dieselben Nachweise wie Leistungserbringer nach § 393, einschließlich C5-Testat.

Krankenhäuser, die private Endgeräte zulassen wollen, müssen sicherstellen, dass die Bedingungen des § 363f erfüllt sind. Für die Informationssicherheit gibt der Entwurf einen Maßstab vor: Maßnahmen, die dem branchenspezifischen Sicherheitsstandard oder gleichwertigen Anforderungen entsprechen, gelten als angemessen. Die Maßnahmen zum Datenschutz nach Art. 32 DSGVO sind gesondert festzulegen. Die Regelung erfasst nur die sicheren Übermittlungsverfahren der TI mit zugelassenen Diensten und Anbietern; eine Übermittlung über private Messenger-Dienste deckt sie nicht ab.

Hersteller von Praxis- und Kliniksoftware stehen künftig unter der Betriebsaufsicht der gematik und, soweit ihre Produkte EHR-Systeme sind, unter der Marktüberwachung des BSI. Je nach Größe und Tätigkeit können NIS2-Pflichten hinzukommen. Das ergibt drei Meldepflichten mit eigenen Wegen, Schwellen und Fristen.

Zeitlich gilt: Das GeDIG soll grundsätzlich am Tag nach der Verkündung in Kraft treten; wann das sein wird, hängt vom weiteren Verfahren ab. Die EHDS-Verordnung gilt allgemein ab dem 26. März 2027. Ihre Herstellerpflichten für EHR-Systeme greifen gestaffelt: ab dem 26. März 2029 für Systeme, die Patientenkurzakten, elektronische Verschreibungen und elektronische Abgaben verarbeiten sollen, ab dem 26. März 2031 für Bildgebung, Untersuchungs- und Laborergebnisse sowie Entlassungsberichte. Für EHR-Systeme, die als Dienst angeboten oder in einer Gesundheitseinrichtung selbst hergestellt und genutzt werden (Art. 26 Abs. 2 EHDS), gilt Kapitel III einheitlich ab dem 26. März 2031.

Readiness: was sich jetzt vorbereiten lässt

Die endgültige Fassung steht noch nicht fest. Einige Vorbereitungen hängen davon aber nicht ab. Aus unserer Sicht bieten sich sechs Schritte an:

1. Wartungs- und Supportwege erfassen. Listen Sie auf, wer zu welchem Zweck auf Cloud-Systeme mit Gesundheitsdaten zugreift: eigene Teams, Dienstleister, Unterauftragnehmer, Standorte. Halten Sie für jeden Weg fest, ob die Daten dabei technisch erreichbar sind.
2. Schlüsselhoheit belegen. Die neue Ausnahme greift nur, wenn die zugreifende Stelle nicht entschlüsseln kann. Dokumentieren Sie, wo die Schlüssel liegen, wer sie verwaltet und wie das technisch durchgesetzt wird. Ein Vertrag allein reicht nach der Begründung nicht.
3. C5-Testat und Wartungskonzept abgleichen. Prüfen Sie, ob Ihr C5-Testat die Wartungs- und Supportprozesse abdeckt, die weiter unter § 393 fallen, und ob die Kriterien für Kunden aus dem Prüfbericht umgesetzt sind. Abrechnungsdienstleister im Anwendungsbereich des § 295a sollten jetzt planen, wie sie zu einem C5-Testat kommen.
4. Private Endgeräte im Krankenhaus vorbereiten. Klären Sie, für welche Abläufe private Geräte sinnvoll wären, gleichen Sie Ihre Maßnahmen für solche Geräte mit dem branchenspezifischen Sicherheitsstandard ab und legen Sie mit Ihrem Datenschutzbeauftragten die Maßnahmen nach Art. 32 DSGVO fest. Halten Sie die Regeln in einer Richtlinie fest und ergänzen Sie sie, sobald die Deutsche Krankenhausgesellschaft die Gerätevoraussetzungen festgelegt hat.
5. Einen Meldeprozess für mehrere Empfänger aufbauen. Hersteller sollten Störungen, Schwachstellen und Vorkommnisse in einem gemeinsamen Ablauf erkennen, bewerten und melden: an die gematik, an die Marktüberwachung und gegebenenfalls nach NIS2. Der Ablauf gehört in das ISMS, mit klaren Zuständigkeiten und eingeübten Fristen.
6. Produkte einordnen und Dokumentation aufsetzen. Klären Sie, welche Produkte als EHR-Systeme gelten, welche Datenkategorien sie verarbeiten und ob Sie sie als Dienst anbieten. Davon hängt ab, ob für Sie 2029 oder 2031 gilt. Fällt ein Produkt zugleich unter den Cyber Resilience Act, lässt sich die technische Dokumentation für beide Verordnungen gemeinsam aufbauen.

Blackfort Technology begleitet diese Schritte: mit C5-Beratung von der Readiness-Analyse bis zur Vorbereitung des Testats, mit Beratung zum Cyber Resilience Act zur Vorbereitung der Konformitätsbewertung und zur technischen Dokumentation und als externer Informationssicherheitsbeauftragter beim Aufbau eines ISMS mit eingeübter Vorfallbehandlung und den nötigen Richtlinien, etwa für private Endgeräte. Mehr dazu auf www.blackfort-tec.de.