In Devlog #8 habe ich die Indikationsprofile vorgestellt, in Devlog #14 Gruppen und Vergleich. Beides baut auf normalisierten Indikationen auf: fachlich vereinheitlichte Verdachtsdiagnosen, unter die die IVENA-Rohcodes einsortiert werden. Solange diese Zuordnung unsauber ist, stimmen Fallzahlen in Profilen, Gruppen und Benchmarks nicht. In Devlog #11 ging es bereits um sichtbare Datenqualität. Der Review-Workflow ist der nächste Schritt: nicht nur messen, dass etwas fehlt, sondern die Zuordnung gezielt und nachvollziehbar verbessern.

Jeder Import bringt Verdachtsdiagnosen als sie im Krankenhausssystem stehen: PCZ-Code und Bezeichnung. Viele Codes lassen sich automatisch einer normalisierten Indikation zuordnen, andere sind neu, ungewöhnlich formuliert oder passen zu mehreren Zielen. Bisher war die Zuordnung oft eine Einzelentscheidung ohne klaren Prozess. Fehler oder Uneinigkeit blieben unsichtbar, bis sie in den Statistiken auffielen.

Unter Explore → Indications gibt es jetzt (für freigeschaltete Benutzer) einen Tab Review-Worklist. Dort erscheinen alle Roh-Indikationen, die Aufmerksamkeit brauchen, sortiert und filterbar nach Status: offen, ungeprüft, zur Freigabe anstehend, neu, zugeordnet, nicht zuordenbar oder ignoriert. Jede Zeile zeigt Code, Bezeichnung und wie oft die Indikation in den Allocations vorkommt. So lässt sich priorisieren, welche Zuordnungen den größten Effekt auf die Statistiken haben.

Von der Worklist aus startet man in den Review-Modus für eine einzelne Roh-Indikation. Dort sieht man Kontext: Anzahl der Vorkommen, Beispiel-Allocations und automatische Zuordnungsvorschläge für passende normalisierte Indikationen. Wer zuordnen oder freigeben darf, hängt von den Berechtigungen ab, welche an einen Nutzer vergeben werden. In dem Punkt werde ich vorerst nur einzelne Personen gezielt freischalten, um diesen Review Prozess durchzuführen.

Der Workflow unterscheidet zwischen Zuordnung vorschlagen und Freigabe. Ein Reviewer wählt eine normalisierte Indikation und reicht den Vorschlag zur Prüfung ein. Der Status wechselt auf „zur Freigabe anstehend". Ein zweiter Reviewer, nicht dieselbe Person, kann den Vorschlag bestätigen oder ablehnen. Bei Ablehnung landet die Indikation wieder bei „ungeprüft", der Vorschlag wird verworfen.

Das ist bewusst so gebaut: Eine fachliche Zuordnung, die später in Tausenden von Fällen auftaucht, soll nicht von einer einzelnen Person ohne Kontrolle festgeschrieben werden. Administratoren können in Ausnahmefällen zuordnen und direkt freigeben, wenn es schnell gehen muss.

Neben Bestätigung und Ablehnung gibt es weitere Entscheidungen. Nicht zuordenbar markiert Indikationen, für die es bewusst kein sinnvolles Ziel gibt. Ignorieren nimmt irrelevante Codes aus der aktiven Warteschlange. Beide lassen sich später wieder öffnen, falls sich die fachliche Einschätzung ändert.

Ist eine Zuordnung freigegeben, startet im Hintergrund ein Backfill: Alle Allocations mit dieser Roh-Indikation bekommen die normalisierte Indikation nachgetragen, die Projektionsschicht wird mitaktualisiert. Das läuft asynchron, damit der Review-Dialog schnell bleibt. Erst danach fließen die Fälle vollständig in Indikationsprofile, Gruppen und Vergleiche ein.

Jede Entscheidung wird protokolliert: wer zuerst zugeordnet hat, wer freigegeben oder abgelehnt hat, optional mit Kommentar. Für Admins gibt es zusätzlich einen Audit-Health-Check per Konsolenbefehl, um den Bestand auf Auffälligkeiten zu prüfen.

Indikationsstatistiken sind nur so belastbar wie die Zuordnung darunter. Ein falsch gemappter IVENA-Code kann Hunderte Fälle in die falsche Diagnosegruppe schieben, ohne dass es in der Oberfläche sofort auffällt. Der Review-Workflow macht diesen Schritt sichtbar, priorisierbar und gemeinschaftlich überprüfbar.

Das passt zur Richtung der letzten Devlogs: mehr Transparenz bei Datenqualität (#11), feinere Filter in Auswertungen (#18) und jetzt ein strukturierter Prozess für die fachliche Grundlage der Indikationsanalysen selbst.

Die Worklist wächst mit jedem Import. Ich erwarte, dass sich mit der Nutzung zeigt, wo Vorschläge noch zu schwach sind und welche Status-Übergänge in der Praxis häufiger gebraucht werden. Wenn ihr den Review-Workflow ausprobiert, freue ich mich wie immer über Feedback über die Sprechblase in der Anwendung.