Krankmeldungen automatisieren - was dabei gilt und wie man es sauber umsetzt

Eine Krankmeldung kommt als Foto ins Postfach: ein Handyfoto von einem Attest, leicht schief. Sie soll eingelesen und strukturiert werden; nach einer Freigabe soll die eAU bei der Krankenkasse abgerufen und der Fall an die Entgeltabrechnung übergeben werden. Der Ablauf dafür ist an einem Nachmittag gebaut. Die eigentliche Arbeit sind die Regeln, die dabei greifen. Wir haben versucht, sie beim Bauen auseinanderzusortieren und sind auf sechs gekommen.

Was ein Workflow überhaupt ist, wo KI hineingehört und warum am Ende ein Mensch entscheidet, steht im Artikel „Wie denkt eigentlich ein Workflow?". Gebaut und getestet haben wir den Ablauf für eine erfundene Firma, mit erfundenen Personen und KI-generierten Attesten; alle Abbildungen stammen aus diesen Läufen.

Vergrößern ⤢

Der Schein, den es nicht mehr gibt

Seit der eAU muss der Großteil der Beschäftigten kein Attest mehr beim Arbeitgeber abgeben. Wer gesetzlich versichert ist und zum Vertragsarzt geht, meldet nur noch, dass er krank ist und voraussichtlich wie lange; den Nachweis holt der Arbeitgeber selbst bei der Krankenkasse.^[1] Vorlagepflichtig bleiben unter anderem Privatversicherte und Krankheiten im Ausland - für den Regelfall würde also eine Mail reichen.

In der Praxis kommt trotzdem noch oft das Foto: die Ausfertigung für Versicherte. Und die trägt die Diagnose. Die frühere Ausfertigung für den Arbeitgeber, die keine trug, gibt es nicht mehr. Im Postfach landet damit regelmäßig eine Diagnose, die der Arbeitgeber nicht verarbeiten darf.

Damit war die erste Regel für diesen Workflow klar. Beim Bauen kamen noch fünf weitere dazu.

Ein Ablauf, sechs Regeln

Drei stecken im Ablauf. Eine ist halb gebaut. Eine erfüllt man, indem etwas fehlt. Und eine lässt sich überhaupt nicht bauen. Sie stehen in verschiedenen Gesetzen und sie unterscheiden sich in zwei Dingen: seit wann sie gelten - und wer sich um sie kümmern muss. Die Liste ist unsere Sortierung für diesen Demo-Fall und keine Rechtsauskunft, Anspruch auf Vollständigkeit hat sie nicht - sie beschreibt die Regeln, die an diesem Bau greifbar wurden.

1 - Diagnosen raus

Gilt heute. Kümmern muss sich der, der den Prozess betreibt.

Der erste Schritt nach dem Lesen verwirft den Diagnose-Block, bevor irgendetwas weitergeht. Nicht schwärzen und aufheben, sondern verwerfen: Der Filter schneidet den Abschnitt aus dem gelesenen Text heraus, und was weitergeht, ist ein Text, in dem er nicht vorkommt. Unter einem schwarzen Balken liegt die Diagnose noch - hier liegt nichts darunter. Auch die Übersicht, in der die Fälle landen, bekommt sie nie zu sehen. Was der Ablauf über einen Fall wissen muss: Zeitraum, Art der Bescheinigung, wer meldet, steht auch ohne sie da. Das Foto selbst liegt danach unverändert im Postfach, aus dem der Ablauf es geholt hat - mitsamt Diagnose. Der Filter räumt den Datenstrom auf, nicht das Postfach; was dort passiert, ist eine Frage des Löschkonzepts.

Vergrößern ⤢

2 - Pseudonymisieren, bevor etwas das Haus verlässt

Gilt heute. Kümmern muss sich der, der den Ablauf baut - und hier steht zum ersten Mal „wir haben entschieden" statt „es gilt": Die technische Umsetzung ist Ermessenssache.

Bevor der erste Cloud-Aufruf passiert, werden Name, Adresse und Geburtsdatum durch Platzhalter ersetzt. Auf einem Foto lässt sich nichts ersetzen - deshalb wird der Schein zuerst im Haus gelesen, auf einem eigenen Server, und erst der Text geht weiter. Wer der Fall ist, weiß der Ablauf aus der Mitarbeiterliste, über den Absender - nie aus dem Foto. Als das Lesen in einem Testlauf aus „Vollmer" ein „VE" machte, war das die Sicherung. Und wenn die Maskierung nicht sicher greift oder das Foto unleserlich ist, geht nichts nach draußen, sondern eine Rückfrage-Mail an den Absender. Wer gar kein Foto schickt, sondern nur schreibt, wie lange er ausfällt, läuft durch denselben Ablauf - nur ohne OCR-Scan.

Die Maskierung selbst hat zwei Lagen: Eine Liste ersetzt, was wir kennen - die Angaben des Mitarbeiters. Dahinter prüft ein zweites Netz statistisch auf alles Unbekannte. Im Testlauf fing es etwas, das wir zunächst nicht mitgeplant hatten: die Daten des Arztes - Praxis, Telefon, Name. Auf dem Schein steht eben noch eine zweite Person.

Zwei Dinge zur Klarstellung: Erstens arbeitet auch der OCR-Scan (Tesseract) mit einem neuronalen Netz. Wir unterscheiden die Schritte danach, was sie mit dem Fall machen, nicht danach, was in ihnen steckt: Er wandelt Pixel in Zeichen und sagt nichts über den Fall aus. Eine inhaltliche Aussage über den Fall trifft ein Modell an genau einer Stelle, und dort liest es den maskierten, diagnosefreien Text und zieht die Felder heraus. In unserem Fall Claude Opus 4.6, betrieben auf AWS-Servern in der EU, angebunden über die Region Frankfurt. Damit wir uns nicht allein auf Auftragsverarbeitungsvertrag und Serverstandort verlassen müssen, sind die Daten vorher maskiert. Zweitens ist das alles nur pseudonymisiert, nicht anonymisiert: Die Zuordnung zum Namen bleibt im Haus, aber es gibt sie - der Personenbezug ist nicht verschwunden.

Vergrößern ⤢

3 - Ein Mensch gibt frei

Gilt in dieser Fassung seit 2018, dem Grunde nach länger.^[2] Kümmern muss sich der, der den Prozess verantwortet.

Der Workflow endet nicht mit einer automatischen Aktion, sondern in einer Freigabe: Der Fall kommt als Mail - freigeben oder verwerfen; beim Verwerfen wird der Grund erfragt und mit dem Fall gespeichert. Damit hat die Entscheidung die drei Eigenschaften, auf die es ankommt: geprüft, überstimmbar, dokumentiert. Die Mail trennt sichtbar, was aus der Meldung gelesen wurde und was daraus berechnet - etwa Tag 7 von 42 der Entgeltfortzahlung.^[3]

Fehler entstehen beim Lesen; geprüft werden muss dort. Der Bau hat das vorgeführt: Das Lesen verwechselte einmal den Monat, und beim Ankreuzkästchen verschwand das gesetzte, während das leere als Markierung gelesen wurde. Daran hängt, ob die Frist weiterläuft oder neu beginnt - bis zu 42 Tage Entgeltfortzahlung. Deshalb leitet der Ablauf Erst- oder Folgebescheinigung nicht vom Kästchen ab, sondern daraus, ob die Meldung an einen offenen Fall anschließt.

Im Demo-Fall ist das vereinfacht: Rechtlich hängt die Frist daran, ob dieselbe Krankheit zugrunde liegt, nicht am zeitlichen Anschluss^[3] - das klärt sich über die Vorerkrankungszeiten der Krankenkasse. Der Ablauf rechnet deshalb einen Vorschlag, den ein Mensch bei der Freigabe bestätigt.

Vergrößern ⤢

Vergrößern ⤢

Nach der Freigabe endet dieser Bau - die Übersicht steht stellvertretend für die Systeme des Unternehmens. eAU-Abruf und Übergabe an die Entgeltabrechnung wären der Vollzug einer Entscheidung, die ein Mensch getroffen hat.

4 - Löschen

Gilt heute. Kümmern müssen sich zwei: der, der baut, und der, der die Plattform bzw. den Workflow am Ende betreibt.

Die erste Hälfte ist offensichtlich: Jede Zeile der Übersicht trägt ein Löschdatum. Die Frist dahinter ist im Demo-Fall ein Platzhalter - welche gilt, ist eine Rechtsfrage, keine Bau-Frage.

Die zweite Hälfte kann man schnell übersehen. Die Plattform, auf der der Workflow läuft, protokolliert jede Ausführung - und diese Protokolle enthalten den Klartext aus der Zeit vor Filter und Maskierung. Diese Schraube sitzt nicht im Ablauf, sondern in der Konfiguration des Servers. Im Demo-Fall haben wir darauf verzichtet; im Betrieb gehört dieser Schritt dazu.

5 - Mitbestimmung

Gilt heute. Kümmern müssen sich Geschäftsführung oder Personalabteilung und der Betriebsrat - die einzige Regel auf dieser Liste, die man nicht bauen kann.

Die Übersicht, in der die Fälle landen, listet Namen und Ausfallzeiten. Sie bewertet nichts, sie zählt nichts zusammen, sie markiert niemanden. Und sie wäre trotzdem geeignet, Verhalten zu überwachen.

Genau dafür gibt es eine Regel und sie ist älter als jede KI-Debatte. Seit 1972 steht im Betriebsverfassungsgesetz, dass der Betriebsrat mitbestimmt bei technischen Einrichtungen, die dazu „bestimmt sind", das Verhalten oder die Leistung der Arbeitnehmer zu überwachen.^[4] Im Gesetz steht „bestimmt", unser System ist nur „geeignet". Das Bundesarbeitsgericht liest den Satz seit den siebziger Jahren weit: Es genügt, dass eine Einrichtung objektiv zur Überwachung geeignet ist - auf eine Absicht des Arbeitgebers kommt es nicht an.^[4] Damit fällt auch eine Übersicht darunter, die nicht zum Zweck der Überwachung gebaut wurde.

Diese Regel lässt sich nicht programmieren. Sie ist ein Verfahren: Die Übersicht gehört auf den Tisch, bevor sie in Betrieb geht. Unsere erfundene Firma hat keinen Betriebsrat; eine echte hätte einen - dann ist diese Zeile ein gemeinsamer Termin, kein Bauteil.

6 - Keine Muster auswerten

Grenze heute - und ab Ende 2027 eine Pflicht mit Datum. Kümmern muss sich der, der den Zweck festlegt.

Die Frage „wer ist eigentlich auffällig oft montags krank?" beantwortet dieser Workflow nicht. Nicht, weil ein Schalter sie sperrt - der Zweig existiert nicht. Nachweisen lässt sich das nur an einer Stelle: auf der Zweck-Karte des Baus, einem Ein-Seiter, der Zweck und Grenzen des Ablaufs festhält. Dort steht das Nicht-Auswerten als Zweckgrenze. Es ist der einzige Teil des Baus, den man nicht vorführen kann, weil er fehlt.

Die Auslassung wirkt zweimal. Heute zieht sie die Linie zwischen Verwalten und Bewerten: Solange der Zweig fehlt, hält die Übersicht Fälle fest und sagt nichts über Menschen aus. Ab Ende 2027 entscheidet dieselbe Auslassung über die Risikoklasse: Die KI-Verordnung stuft Systeme, die das Verhalten und die Leistung von Beschäftigten beobachten und bewerten, dann als hochriskant ein^[6] - mit Pflichten, die ein eigenes Projekt wären. Wer den Zweig heute nicht baut, hat 2027 nichts nachzurüsten. Dass daneben ein eigenes Beschäftigtendatengesetz angekündigt ist, ändert an der Sortierung nichts: Ein Entwurf ist in Arbeit, verabschiedet ist noch nichts.

Was diesem Bau noch fehlt

Der Workflow tut, was er soll - in einer Demo-Umgebung, mit erfundenen Fällen. Bis zum echten Betrieb fehlt vor allem Papier:

• Die dokumentierte Rechtsgrundlage: die schriftlich festgehaltene Antwort darauf, worauf sich die Verarbeitung der Falldaten stützt.
• Der Eintrag im Verzeichnis der Verarbeitungstätigkeiten und die Prüfung, ob eine Datenschutz-Folgenabschätzung fällig wird - bei Gesundheitsdaten keine akademische Frage.
• Die Betriebsvereinbarung, die Information an die Beschäftigten und ein Löschkonzept, das den Namen verdient.
• Ein Test-Workflow, der die Funktion regelmäßig prüft und das Ergebnis dokumentiert. Einen Fehler-Workflow, der bei Störungen Alarm schlägt, hat der Bau.

Und einen Ablauf zu betreiben - ihn zu pflegen, wenn sich das Postfach, das Formular oder die Zuständigkeit ändert - ist etwas anderes, als ihn einmal vorzuführen. Vollständig ist diese Liste vermutlich auch nicht.

Was wirklich neu ist

Man könnte diese Regeln als Beleg lesen, dass Automatisierung bei Personaldaten zu heikel ist. Der Payroll-Alltag legt jedoch eine andere Lesart nahe. Ein Lohnlauf lebt seit Jahrzehnten mit mehreren Regelwerken, die gleichzeitig ticken - Steuer, Sozialversicherung, Arbeitsrecht, Tarif, jedes mit eigenen Stichtagen und eigenen Zuständigen. Das Auseinanderhalten ist nicht die Ausnahme, es ist der Alltag. Neu ist daran auch nicht der Datenschutz - für Personaldaten galt er längst, und betrieben werden musste ein Abrechnungssystem ebenfalls.

Neu ist, dass die Umsetzung nicht mehr mitgeliefert wird. Wer ein Abrechnungsprogramm einsetzt, bleibt verantwortlich - aber die Entscheidungen sind getroffen: was gespeichert wird, wie gerechnet wird, wann etwas gelöscht wird. Ändert sich ein Gesetz, kommt ein Update. Wer selbst baut, trifft diese Entscheidungen selbst und zieht sie selbst nach. Deshalb trägt jede der sechs Regeln oben eine Zeile, wer sich kümmern muss. Ein Hersteller steht in keiner.

Ob so ein Ablauf trägt, entscheidet sich deshalb weniger am Werkzeug als an der Umsetzung innerhalb des Unternehmens. Die erste Frage ist damit nicht, wer so etwas bauen kann, sondern wer im Haus sagen kann, welche Regeln greifen - und wer für sie geradesteht.