Netzwerk-Plattformen und ihre Datenflüsse: Was Klinik-IT prüfen muss

Im Anbieter-Gespräch zu einer Vermittlungs-Plattform, einer Reha-Portal-Anbindung oder einer Hilfsmittel-Bestell-Schnittstelle fällt fast immer dieselbe Antwort, sobald die Datenschutz-Frage gestellt wird: ein Verweis auf das C5-Testat, eine Folie mit europäischem Server-Standort, eine Zeile zur verschlüsselten Übertragung. Drei Antworten, drei Häkchen, weiter im Gespräch. Was die IT-Leitung in dieser Situation eigentlich wissen müsste, bleibt ungesagt: welche Datenfelder die Klinik konkret aushändigt, an welche Empfänger-Klassen, in welcher Jurisdiktion, auf welcher Rechtsgrundlage, mit welcher Audit-Spur und mit welchem Lösch-Beleg. Eine Plattform-Anbindung ist eine Datenfluss-Vereinbarung mit operativer Substanz unterhalb der Zertifikats-Schicht. Sie entscheidet sich an sechs Antworten, nicht an einem Etikett.

Was eine Netzwerk-Plattform per Konstruktion tut

Eine Netzwerk-Plattform — Vermittlungs-Marktplatz für Anschluss-Reha, Reservierungs-Portal für Pflege-Plätze, Multi-Anbieter-System für Hilfsmittel, Schnittstelle in den Sanitätshaus-Verbund — sendet per Konstruktion klinische Daten zwischen Häusern, an Nachversorger, an externe Dienstleister. Das ist ihr Daseinszweck, nicht ihr Nebeneffekt. Eine Vermittlungs-Plattform, die keine klinischen Daten sendet, vermittelt nichts. Die operative Frage ist daher nicht, ob klinische Daten die Klinik-Mandant-Schicht verlassen — diese Frage ist mit dem Anbindungs-Beschluss bereits beantwortet. Die Frage, an der sich die Anbindung entscheidet, ist die nach der Substanz dieses Daten-Versands — Datenfeld, Empfänger, Jurisdiktion, Rechtsgrundlage, Spurbarkeit, Lösch-Beleg. Diese sechs Punkte sind keine Datenschutz-Geste neben dem Vertrag, sondern die Substanz des Vertrags. Ein C5-Testat oder ein ISO-27001-Zertifikat des Plattform-Anbieters bestätigt, dass dessen Plattform-Kontrollen und sein Information Security Management System (ISMS) auditiert wurden. Sie bestätigen nicht, welche Klinik-Datenfelder die konkrete Anbindungs-Funktion sendet, in welche Empfänger-Klasse, mit welcher Lösch-Frist. Diese Aussage trägt nur eine Datenfluss-Karte, die je Anbindungs-Funktion gepflegt ist und die in der Auftragsverarbeitungs-Anlage konkret benannt steht. Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) dokumentiert in seinen Tätigkeitsberichten wiederkehrend, dass abstrakte Formulierungen wie „klinische Daten“ oder „erforderliche Daten“ in geprüften Verträgen die Konkretion ersetzt haben — und dass eine solche Abstraktion in der Aufsichts-Praxis nicht trägt.

Sechs Fragen vor jeder Anbindung

Die erste Frage gilt der Datenfeld-Liste. Welche klinischen Felder verlassen die Mandant-Schicht der Klinik technisch — Diagnose-Codes, Befund-Texte, Pflege-Einschätzungen, Medikations-Listen, Sozialanamnese, Bewegungs-Profile, Anschluss-Versorgungs-Bedarf, Verordnungen? Eine tragfähige Antwort listet die Felder einzeln, nicht als Sammel-Bezeichnung. Eine schwache Antwort spricht von „erforderlichen Daten“ oder „indikationsspezifisch relevanten Inhalten“. Die Datenschutz-Grundverordnung (DSGVO) fordert in Artikel 28 eine konkrete Beschreibung der verarbeiteten Daten in der Auftragsverarbeitungs-Vereinbarung; eine Sammel-Bezeichnung erfüllt diese Anforderung nicht. Wer in der Anbindung die Liste je Anbindungs-Funktion nicht bekommt, hat das, was die Aufsicht später erwarten wird, nicht in der Hand.

Die zweite Frage gilt den Empfänger-Klassen. An wen geht das Datenpaket — an einen einzelnen Nachversorger, an alle in einem Vermittlungs-Pool eingetragenen Häuser, an einen Hilfsmittel-Anbieter und sein Subunternehmer-Netz, an einen Sanitätshaus-Verbund, an einen Träger im Konzern-Ausland? Die Empfänger-Klasse entscheidet, ob die Übermittlung in den Rahmen einer Auftragsverarbeitung passt, ob eine Übermittlung an einen anderen Verantwortlichen vorliegt oder ob ein Drittstaaten-Transfer ausgelöst wird. Eine Plattform, die ein Datenpaket „in den Pool“ sendet, hat damit nicht notwendig eine Empfänger-Klasse benannt — der Pool ist eine Vermittlungs-Schicht, der konkrete Empfänger ist eine andere Stelle. Wer in der Beschaffung diese Stelle nicht in der Auftragsverarbeitungs-Anlage findet, hat eine Lücke gefunden, keine Antwort.

Die dritte Frage gilt der Jurisdiktion. In welchem Rechtsraum sitzt der Empfänger, in welchem sein Konzern-Mutter-Unternehmen, in welchem die für die Plattform genutzte Cloud-Region? Diese drei Antworten fallen häufig auseinander: ein deutscher Empfänger in einem deutschen Pool über eine US-headquartered Cloud-Plattform mit europäischer Region ist ein anderer Datenfluss als ein deutscher Empfänger über einen deutschen Plattform-Anbieter mit deutscher Cloud-Region. Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) verpflichtet in den USA ansässige Cloud-Anbieter zur Daten-Herausgabe an US-Behörden auf richterlichen Beschluss — unabhängig vom Speicher-Ort. Das EuGH-Urteil Schrems II (C-311/18, 2020) hat den damaligen US Privacy Shield für ungültig erklärt; das nachfolgende EU-US Data Privacy Framework bleibt rechtlich umstritten. Diese Bezugsgrößen sind keine Architektur-Frage; sie sind eine eigene Spalte in der Plattform-Beurteilung, neben der Architektur, nicht an deren Stelle. Eine Plattform-Beschaffung, die diese Spalte ungeprüft lässt, lagert die Frage in die nächste Aufsichts-Prüfung aus.

Die vierte Frage gilt der Einwilligungs-Kette. Auf welcher Rechtsgrundlage geht das Datenpaket aus der Klinik-Mandant-Schicht in die Plattform — und auf welcher aus der Plattform an den konkreten Empfänger? Im Reha-Vermittlungs-Fall ist häufig die Einwilligung der Patient:innen in die Vermittlung dokumentiert; selten gleich gut dokumentiert ist, ob diese Einwilligung die spätere Übertragung an alle Empfänger im Pool und die Speicherung im Plattform-System für die Dauer X mit der Zweckbestimmung Y konkret abdeckt. Die Einwilligung ist nicht der einzige denkbare Rechtsgrund — Vertrags-Erfüllung, gesetzliche Grundlage, berechtigtes Interesse kommen je nach Konstellation in Betracht — aber jede Anbindungs-Funktion braucht eine benannte Rechtsgrundlage je Übermittlungs-Schritt. Eine Anbindung, die ihre Rechtsgrundlage nicht je Schritt benennt, ist eine Übertragung ohne benannten Grund — und damit ein Risiko in der Auftragsverarbeitungs-Anlage, das der Aufsicht später auffällt.

Die fünfte Frage gilt dem Audit-Log auf Aussage-Ebene. Wenn ein klinischer Vorgang nach einer Plattform-Übertragung später beanstandet wird — eine fehlerhafte Vermittlungs-Zuordnung, eine versehentlich übertragene Befundzeile, ein Hilfsmittel-Auftrag mit falscher Diagnose-Code — muss die Klinik die Übertragungs-Spur lückenlos rekonstruieren können: wann, durch wen, mit welchem Datenpaket, an welchen Empfänger, mit welchem Bestätigungs-Beleg. Die Logs müssen der Anbieter nicht nachträglich verändert haben können — Append-only-Strukturen mit kryptografischer Verkettung, gespiegelt in eine Klinik-eigene Senke oder in eine vertraglich gepinnte Anbieter-Senke mit Klinik-Lese-Recht. Die European Union Agency for Cybersecurity (ENISA) empfiehlt für Plattform-Anbindungen im Gesundheitssektor genau diese mehrschichtige Audit-Log-Architektur; die Tätigkeitsberichte des BfDI benennen die fehlende Klinik-seitige Audit-Spur als wiederkehrendes Aufsichts-Thema. Wer das Log nur beim Anbieter findet und nur auf Anbieter-Anfrage liest, hat keine Audit-Spur, sondern eine Anbieter-Auskunft.

Die sechste Frage gilt der Lösch-Frist und dem Lösch-Beleg. Wann wird ein Datenpaket auf der Plattform und beim Empfänger gelöscht — nach Abschluss der Vermittlung, nach Ablauf einer Pool-Speicher-Frist, nach Ende einer Vertragsbeziehung, nach Widerruf der Einwilligung? Und woran ist die Löschung beweisbar — an einer System-Bestätigung mit Zeitstempel, an einer kryptografisch signierten Lösch-Quittung, an einem Audit-Eintrag der Lösch-Aktion? Artikel 17 DSGVO fordert die Lösch-Mechanismen; die operative Übersetzung in Plattform-Kontexten bleibt häufig unscharf. Die gematik hat in ihren Vereinbarungen zur Cloud-Nutzung die Lösch-Frist und den Lösch-Beleg als prüfbare Vertrags-Eigenschaft strukturiert; die DSK fordert dieselbe Prüfbarkeit. Eine Plattform, die zur Lösch-Frist auf eine allgemeine Datenschutz-Erklärung verweist und keinen Lösch-Beleg dokumentiert, hat die Frage nicht beantwortet — sie hat sie an eine andere Folie verschoben.

Datenfluss-Karte als Beschaffungs-Artefakt

Die sechs Antworten sind kein Datenschutz-Anhang. Sie sind das Beschaffungs-Artefakt, das vor der Schnittstellen-Aktivierung steht und nach der Aktivierung gepflegt bleibt. Operativ: eine Datenfluss-Karte je Anbindungs-Funktion, sechs Spalten, eine Zeile pro klinischer Anwendungsfall. Die Karte gehört in die Auftragsverarbeitungs-Anlage als prüfbare Anlage, nicht in eine separate Datenschutz-Akte. Sie ist die Stelle, an der zwei Plattformen mit demselben C5-Testat sich substantiell trennen — die eine kann die Karte je Funktion vorlegen, die andere verweist auf das Testat. Eine Beschaffung, die in der Liste der Lastenheft-Punkte eine Spalte „Datenfluss-Karte je Funktion liegt vor“ einträgt, hat den Mindeststandard codiert. In einem früheren Stück zur Datensouveränität in der Klinik-IT haben wir diese Trennung als Architektur-Frage gegen die reine Standort-Frage geführt; hier reicht die Knapp-Form: Architektur-Disziplin entscheidet die Anbindung, das Testat ist die Eintritts-Bedingung.

Eine Vermittlungs-Plattform, ein Reha-Portal, eine Hilfsmittel-Schnittstelle sind nützliche Werkzeuge in der Klinik-Versorgungs-Kette. Sie tun ihren Dienst, wenn die Datenflüsse, die sie tragen, im Detail beschrieben und im Detail kontrolliert sind. Sie tun ihn nicht, wenn die Datenfluss-Frage durch ein Zertifikats-Etikett ersetzt wird. Wer als Klinik-IT die Anbindung trägt, liest das Zertifikat als Eintritts-Bedingung und schreibt die sechs Antworten daneben. Sie sind der Ort, an dem zwei zertifizierte Plattformen sich in der Praxis unterscheiden — und der Ort, an dem die Klinik die Verantwortung behält, die mit der Anbindung nicht abgegeben wird.