Konditionale KoGu-Erkennung: Limitations-Text in Sub-Klauseln zerlegen (Stelara MC/CU als Leitbeispiel)

[zdavatz]

Zusammenfassung

Der heute eingebaute Heuristik-Match text =~ /Kostengutsprache|Vertrauensarzt/i
auf dem Limitations-Text einer ClinicalUseDefinition produziert systematisch
falsch-positive KoGu-Markierungen, weil viele Limitationen die KoGu-Pflicht
nur an bestimmte Therapielinien oder Eskalationsschritte knüpfen, nicht
an die Indikation als Ganzes.

Damit ein Chooser-UI (z.B. generikacc#102) die richtige Information anzeigen
kann, müssen wir den Limitations-Text in Sub-Klauseln zerlegen und KoGu
pro Klausel statt pro Indikation kennzeichnen.

Leitbeispiel: Stelara Morbus Crohn / Colitis ulcerosa

CUD-id STELARAMC (Morbus Crohn), Originaltext:

Behandlung erwachsener Patienten mit mittelschwerem bis schwerem aktivem
Morbus Crohn, bei denen konventionelle Therapien oder die Behandlung mit
einem TNFα-Antagonisten ungenügend angesprochen haben, nicht mehr
ansprechen, kontraindiziert sind oder nicht vertragen wurden.

Eine Verkürzung des Dosierungsintervalls auf acht Wochen bei Patienten
mit hoher mukosaler und systemischer Entzündungsaktivität sowie eine
Weiterbehandlung mit STELARA von einem Jahr bedürfen der Kostengutsprache
durch den Krankenversicherer nach vorgängiger Konsultation des
Vertrauensarztes.

Die Verschreibung kann nur durch Fachärzte der Gastroenterologie oder
Universitätskliniken/Polikliniken erfolgen.

STELARACU2 (Colitis ulcerosa) ist semantisch identisch aufgebaut.

Mein Regex labelt beide als KoGu = ja. Klinisch korrekt wäre aber:

Therapielinie	KoGu
Standard-Induktion + Erhaltungstherapie alle 12 Wochen	nein
Verkürzung Dosierungsintervall auf 8 Wochen	ja
Weiterbehandlung über 1 Jahr hinaus	ja

Die einfache Regex pauschalisiert KoGu für die gesamte Indikation und löst
damit das KoGu-Verfahren auch bei regulärem Therapie-Einstieg aus. Das ist
für den Vertrauensarzt-Workflow ein False-Positive.

Ziel

Einen strukturierten Sub-Klausel-Parser für Limitations-Texte einführen,
der pro Klausel ein Mini-Datenobjekt extrahiert:

- clause_text: "Behandlung erwachsener Patienten mit mittelschwerem bis schwerem aktivem Morbus Crohn..."
  applies_to: standard_indication
  requires_kogu: false

- clause_text: "Eine Verkürzung des Dosierungsintervalls auf acht Wochen..."
  applies_to: dose_interval_shortening
  requires_kogu: true
  trigger_keywords: [Verkürzung, Dosierungsintervall]

- clause_text: "Eine Weiterbehandlung mit STELARA von einem Jahr..."
  applies_to: continuation_beyond_1_year
  requires_kogu: true
  trigger_keywords: [Weiterbehandlung, "über ein Jahr", Langzeit]

Das Ergebnis exponieren wir am <INDICATION_CODE>-Element via Sub-Elemente
oder ein zusätzliches Attribut, z.B.:

<INDICATION_CODE code="21754.03" cud_id="STELARAMC" requires_kogu="conditional">
  <CLAUSE applies_to="standard_indication" requires_kogu="false">
    Behandlung erwachsener Patienten...
  </CLAUSE>
  <CLAUSE applies_to="dose_escalation" requires_kogu="true">
    Eine Verkürzung des Dosierungsintervalls auf acht Wochen...
  </CLAUSE>
  <CLAUSE applies_to="continuation" requires_kogu="true">
    Eine Weiterbehandlung mit STELARA von einem Jahr...
  </CLAUSE>
</INDICATION_CODE>

Damit kann der Chooser die richtige Sub-Auswahl (Standard / Eskalation /
Langzeit) anbieten und das KoGu-Badge nur dann setzen, wenn die gewählte
Klausel KoGu erfordert.

Vorgehen

1. Sample-Korpus zusammenstellen — alle 1'419 INDICATION_CODE-Texte aus
   der aktuellen oddb_product.xml, davon die ~796 mit KoGu-Phrase.
2. Klassifikator-Heuristik auf Satz-Ebene:
   • Trigger-Phrasen für „KoGu-only-bei":
     • Verkürzung des Dosierungsintervalls
     • Weiterbehandlung / Langzeitbehandlung / über X Jahr
     • Wiederbehandlung
     • Erhöhung der Dosis / Dosiseskalation
     • nach Versagen einer weiteren Therapie
     • Ausnahmefälle / nur in begründeten Einzelfällen
   • Trigger-Phrasen für „KoGu-pauschal":
     • Die Behandlung bedarf der Kostengutsprache (am Anfang/eigenständig,
       ohne einschränkende Bedingungen davor)
3. Validierung an einem manuell durchgesehenen Sample (~50 CUDs) — mit
   einer/m Fachärztin/-arzt absprechen, falls möglich.
4. Output als zusätzliches Feld pro <INDICATION_CODE> (Vorschlag oben)
   und/oder als separate kogu_clauses.yaml-Datei (analog zum Mapping aus
   FHIR ClinicalUseDefinition: nicht-numerische CUD-IDs (z.B. Stelara) ergeben keinen XXXXX.NN-Code #114).

Akzeptanzkriterien

• Parser-Modul lib/oddb2xml/limitation_clauses.rb (analog
  refdata_cleanup.rb) mit Klausel-Klassifikator + Tests.
• <INDICATION_CODE> trägt entweder ein requires_kogu="true|false|conditional"
  Attribut oder verschachtelte <CLAUSE>-Kinder. Architektur-Entscheidung
  beim Implementieren — Backwards-Compat-Check mit den heutigen Konsumenten
  (rust2xml, generikacc, ywesee-EHR-Backend) durchführen.
• Validierung gegen Stelara MC/CU: standard_indication.requires_kogu = false,
  dose_escalation/continuation.requires_kogu = true.
• Validierung gegen Cyramza (20403.01): pauschale KoGu, da die
  Phrase „Die Behandlung bedarf der Kostengutsprache" alleinstehend folgt.
• Generika.cc-Issue #102
  erhält einen Update-Kommentar, sobald die strukturierte Information
  verfügbar ist.
• BAG-Anfrage erweitern — zusätzlich zur Indikationscode-Mapping-Frage
  aus FHIR ClinicalUseDefinition: nicht-numerische CUD-IDs (z.B. Stelara) ergeben keinen XXXXX.NN-Code #114 noch fragen, ob ein strukturiertes
  medicalReviewRequired/preauthorizationScope-Feld geplant ist.

Verwandte Issues

• oddb2xml #113 — ursprüngliche
  Indikationscode-Implementierung
• oddb2xml #114 — fehlende
  .NN-Codes bei Buchstaben-Suffix-CUDs (Stelara ist auch dort Leitbeispiel)
• generikacc #102 — Chooser
  im KoGu-Formular; konsumiert das Output dieses Issues
• rust2xml #1 — verified vs
  constructed-Trennung, gleiche Struktur sollte für requires_kogu gelten