Das Patientenfeld, das nie in den Logs landete
Wie ein Digital-Health-Team Hotfix-Druck überstand, ohne dass Artikel-9-Daten je ein Klartext-Log erreichten — weil der Check an einem Dienstag nicht müde wird.
Die Hochrisiko-Pflichten der EU-KI-Verordnung Anhang III für gesundheitsnahe KI-Systeme gelten jetzt ab dem 2. Dezember 2027. Der Termin hat sich verschoben — der Vorwand zu warten nicht. Beginnen Sie jetzt mit dem Compliance-Tracking.
DIENSTAG, 09:15 — HOTFIX
Unter Druck, einen Hotfix zu liefern, stellt jemand einen Logger auf Debug. Patientendaten-Felder fließen in Klartext-Logs — heute in Staging, Freitag in Produktion. Der Diff hat 4 Zeilen; das Review dauert 40 Sekunden.
DIENSTAG, 09:15:04 — CI
Das Gate lässt den Pull Request scheitern: unmaskierter Patienten-Identifier in der Log-Ausgabe, Artikel-9-Daten, Regel und Zeile benannt — nur maskierte Evidenz. Der Hotfix shippt 20 Minuten später, ohne den Logger.
Der Hotfix ging an dem Morgen trotzdem raus. Die Patientendaten nicht.
Vor dem Gate gab es den Incident-Report
Wer Gesundheitsdaten verarbeitet, kennt dieses Dokument:
- Logging-Disziplin lebte in einer Review-Checkliste — zuverlässig bis zum ersten dringenden Hotfix.
- Artikel-9-Daten kennen kein „kleines Leck". Ein Patientenfeld in einer Logdatei ist ein meldepflichtiges Ereignis, eine 72-Stunden-Uhr und eine sehr lange Woche.
- Das Review fing, wofür Reviewer Zeit hatten. Ein 4-Zeilen-Hotfix-Diff um 09:15 bekommt 40 Sekunden, keine Prüfung.
- Jedes Audit stellte dieselbe Frage — „wie verhindern Sie PHI in Logs?" — und die ehrliche Antwort war „wir bitten alle, vorsichtig zu sein."
Also hörte „vorsichtig sein" auf, die Kontrolle zu sein — der Merge-Check wurde es.
Die Tour — vom Commit zur Evidenz
Eine Regel, die Ihr DSB lesen kann
Compliance-Regeln sind einfache Deklarationen — was erkannt wird, wo gesucht wird, was bei einem Treffer passiert. Das GDPR-Detective-Paket ist startklar; Ihre Organisation ergänzt eigene Patienten-Identifier-Signaturen, ohne uns zu fragen.
Der Merge, der höflich scheitert
Ein Treffer lässt den Check scheitern — mit Datei, Zeile und Regel, und nur maskierter Evidenz. Der Reviewer sieht genug, um es zu beheben; der Wert selbst verlässt Ihren CI-Runner nie.
Drift, bewertet zwischen den Releases
Stündliche Prozessregeln bewerten Review-Abdeckung, Incident-Hygiene und Dokumentationsgewohnheiten gegen Ihre Jira- und GitHub-Aktivität — nachlassende Standards zeigen sich als Trend, nicht als nächster Incident-Report.
Freigabe, die gesperrt bleibt
Was menschliches Urteil braucht — die klinische Risiko-Checkliste, die DSFA-Bestätigung — bekommt einen benannten Reviewer und ein gesperrtes Gate. Das Ergebnis exportiert signiert und mit Zeitstempel: Evidenz statt Screenshots.
Dasselbe Audit, ein Release später
Vorher
- —„Wie verhindern Sie PHI in Logs?" — „Wir bitten alle, vorsichtig zu sein"
- —Jeder Hotfix war ein Münzwurf unter einer 72-Stunden-Uhr
- —Logging-Disziplin war ein Checklisten-Punkt
- —Audit-Evidenz waren Screenshots aus der Woche davor
Nachher
- ✓Es ist ein blockierender Check — die Antwort ist eine Regel-ID und ein Scan-Register
- ✓Der Hotfix-Pfad hat dasselbe Gate wie alles andere
- ✓Es ist eine benannte Regel, die den Merge scheitern lässt
- ✓Zeitpunkt-Snapshots exportieren signiert, mit einem Klick
Ein ehrlicher Fit-Check
Das passt, wenn
- ✓Sie verarbeiten Patienten- oder Gesundheitsdaten nach DSGVO Artikel 9
- ✓Ihr Team merged über Pull Requests auf GitHub oder GitLab
- ✓Hotfix-Druck ist real — und Reviews werden genau dann dünn, wenn das Risiko am höchsten ist
- ✓Sie blockieren lieber einen Merge, als eine 72-Stunden-Meldefrist zu starten
Und ehrlich gesagt, wenn
- ·Sie brauchen semantisches Urteil — „ist diese klinische Logik sicher?" ist eine menschliche Entscheidung. PulseCheck leitet sie an eine gesperrte, rollenbeschränkte Attestierung weiter, statt Erkennung vorzutäuschen.
- ·Sie mergen nicht über CI — das Gate hat keinen Ansatzpunkt.
- ·Sie wollen Scorecards auf Entwickler-Ebene — bewusst nicht gebaut, und das bleibt so.
Beurteilungsfragen unabhängig anwaltlich prüfen lassen
Manche Fragen bleiben eine menschliche Entscheidung. Mit Expert Review können Sie sie zusätzlich einer unabhängigen, zugelassenen Anwältin oder einem zugelassenen Anwalt vorlegen, und die Einschätzung erscheint neben jeder Regel.
So funktioniert Expert Review →FAQ zur Digital-Health-Compliance
Kann PulseCheck einen Pull Request blockieren?
Ja. Die CI-Action prüft jeden Diff gegen das Regelwerk Ihrer Organisation und lässt die Prüfung fehlschlagen, wenn eine definierte Signatur (ein im Klartext protokollierter Patienten-Identifikator, fest codierte Zugangsdaten) vorhanden ist — als erforderliche Statusprüfung konfiguriert, kann der PR dann nicht gemergt werden.
Liest PulseCheck unseren Quellcode?
Der Scan läuft innerhalb Ihres eigenen CI-Runners. Funde werden maskiert, bevor sie ihn verlassen — PulseChecks Server sehen ein Treffer/Kein-Treffer-Ergebnis und einen maskierten Ausschnitt, niemals Ihren Rohquellcode oder Patientendaten.
Erkennt es fehlerhafte Einwilligungslogik oder klinische Sicherheitsprobleme?
Nein — ehrlich gesagt. Das ist eine Beurteilungsfrage, kein Musterabgleich. PulseCheck leitet sie an eine gesperrte Freigabeaufgabe weiter, die eine benannte Prüfperson ausdrücklich bestätigen muss, mit der Bestätigung in einem audit-fähigen Export festgehalten. Mit Expert Review können Sie diese Frage zusätzlich einer unabhängigen, zugelassenen Anwältin oder einem zugelassenen Anwalt vorlegen.
Wie hilft PulseCheck bei DSGVO Artikel 9?
PulseCheck liefert ein DSGVO-Regelpaket zum Umgang mit besonderen Datenkategorien (Gesundheitsdaten), stündlich gegen Ihre Jira-/GitHub-Aktivität ausgewertet, plus ein Compliance-Gate mit gesperrter Freigabeaufgabe und einem signierten, zeitgestempelten Export für Ihre Audit-Spur.
Welche Compliance-Frameworks gibt es als Vorlagen?
DSGVO, EU-KI-Verordnung, DORA und ein allgemeines QA-/Incident-Management-Paket sind als installationsfertige Regel-Vorlagen verfügbar — installieren Sie eine, und PulseCheck bewertet Ihre bestehenden Daten sofort dagegen.