Bedienungsanweisung — Pädiatrie-Coding-Assistent

Vollständige Anleitung für Anwenderinnen und Anwender (Kodierfachkräfte, Ärztinnen und Ärzte). Eine kürzere Betriebs-/Deployment-Variante steht in BEDIENUNG.md; die Funktionsweise der Engine in FUNKTIONSWEISE.md und ENGINE.md.

1. Wozu dient die App?

Der Pädiatrie-Coding-Assistent prüft einen deutschsprachigen Arztbrief / Entlassbrief (oder die Klinikdokumentation) dokumentationsbasiert auf:

• ICD-10-GM- (Haupt-/Nebendiagnosen) und OPS-Hinweise,
• ambulante Abbildbarkeit (EBM/GOP) in der pädiatrischen Sprechstunde,
• stationäre Vorprüfung (aG-DRG) für die Kinderstation,
• Dokumentationslücken und Rückfragen an die behandelnde Ärztin / den Arzt,
• eine Vergütungsschätzung (EBM-Punkte/€ bzw. aG-DRG) und Revisionssicherheit.

Die App ist eine Entscheidungsunterstützung. Sie ersetzt keine Kodierfachkraft, keinen Grouper, keine ärztliche Verantwortung und keine MD-/Rechtsprüfung. Alle Vorschläge sind gegen die aktuelle Jahres-/Katalogversion zu prüfen.

2. Start

Keine Installation nötig.

• Direkt: web/index.html im Browser öffnen, oder
• lokaler Server: python3 -m http.server 8000 im Ordner web/, dann

http://127.0.0.1:8000, oder

• bereitgestellte Adresse des Hauses aufrufen.

Nach dem ersten Laden ist die App dank Service Worker offline lauffähig (Statusanzeige „Offline bereit").

3. Analyse in 4 Schritten

Oben links wählt eine Moduskarte den Eingabeweg: Voller OP-/Arztbericht (kompletter Workflow) oder Schnell-Kodierung (nur Stichwort → ICD/OPS-Vorschläge, ohne Bericht). Über das Darstellungs-Menü (☰ oben rechts) lässt sich zudem die Experten-Ansicht zuschalten — sie zeigt zusätzlich Katalogverwaltung, Simulations-Schalter und Audit-Trail; die einfache Ansicht (Standard) hält den klinischen Arbeitsweg frei davon.

1. Rahmen setzen (linke Spalte):

• Abrechnungsjahr wählen.
• Fachbereich/Setting wählen.
• Prüfziel wählen:
• Ambulant/EBM-Prüfung — Standard für die pädiatrische Sprechstunde.
• Kodieroptimierung — maximale, belegbare Kodierschärfe (inkl. Nebendiagnosen für die aG-DRG).
• Stationäre Begründung prüfen — Kontextfaktoren + Setting-/Vergütungsvergleich (aG-DRG).
• MD- und Kürzungsrisiko prüfen — strengste Prüfung.

2. Arztbrief / Entlassbrief einfügen in das große Textfeld. Deutscher Freitext genügt. Nennen Sie: Haupt-/Nebendiagnosen, Anamnese, Aufnahme-/Entlassbefund, Verlauf, durchgeführte Maßnahmen, Medikation/Therapie, Entlassfähigkeit/Überwachung (siehe MUSTER-ENTLASSBRIEF.md).

3. „Analyse starten" klicken.

4. Auswertung lesen (rechte Spalte) — siehe nächster Abschnitt.

Schnell-Kodierung aus Stichwort (ohne Arztbrief)

Unter dem Prüfziel gibt es das Feld „Schnell-Kodierung aus Stichwort":

1. Ein Wort oder kurzer Satz genügt (z. B. „Fieberkrampf", „RSV-Bronchiolitis", „Gastroenteritis Exsikkose") → „Diagnose & Codes vorschlagen" (oder Enter). 2. Es erscheint eine anhakbare Auswahl-Liste mit bis zu 5 Diagnosen (ICD-10-GM) und 5 Maßnahmen (OPS):

• Exakte Treffer sind vorangehakt.
• Ähnliche Begriffe (Wortstamm-/Katalog-Treffer, z. B. „Krampf" →

Fieberkrampf R56.0) sind unangehakt und mit „ähnlicher Begriff – bestätigen" markiert.

• Abgeleitete Vorschläge (z. B. Diagnose → typische Maßnahme) tragen den

Hinweis „abgeleitet – bestätigen". 3. Aktionen: „Auswahl übernehmen & prüfen" schreibt die angehakten Einträge als Mini-Bericht ins Berichtsfeld und startet die Vollanalyse; „Auswahl kopieren" kopiert die Liste als Text; „Schließen" blendet sie aus.

Tippfehler und Kurzformen werden toleriert („Bronchiolitiss", „Fieberkrmpf"). Mit geladenen Katalogen durchsucht die Schnellsuche zusätzlich den kompletten ICD-/OPS-Katalog volltextlich.

4. Die Auswertung verstehen

• Leitkennzahlen oben: Revisionssicherheit (revisionssicher / mit Auflagen /

Kürzungsrisiko / nicht abrechnungsreif) und geschätzte Vergütung.

• Lücken / To-dos: oben steht das höchste Kürzungsrisiko. Zu jeder Lücke gibt

es die konkrete Rückfrage, mit der sie geschlossen wird.

• Kodevorschläge (ICD/OPS): jede Zeile zeigt **Code · Klartext · Konfidenz ·

Beleg. Aufklappen (Pfeil rechts) öffnet die Abrechnungskette**.

• Aufgeklappte OPS-Zeile zeigt strukturiert in Tabellenform:
• OPS-Katalog: Datei, Trefferzahl, Code-Liste, Beispiel,
• EBM-Zuordnung: Subkodes, GOP,
• Vergütung (Schätzung, ambulant): EBM-GOP-Kette → € (extrabudgetär hervorgehoben);

erfasste Sachkosten werden fallbezogen extrabudgetär zugerechnet.

• Konfidenz-Logik: Ohne Textbeleg nie „hoch"; KI-Vorschläge nie „hoch".
• Klick auf OPS-Titel: zeigt die anderen Schlüsselnummern der OPS-Gruppe (Endstellen).
• Klick auf Diagnose-Titel: zeigt mögliche Maßnahmen/DRGs (Textähnlichkeit).
• Bei Prüfziel Stationäre Begründung: Setting-Vergleich ambulant/EBM vs.

stationär/aG-DRG.

• Ausgabe per Kopieren / Drucken / Export (MD, JSON, FHIR) übernehmen.
• Auf dem Smartphone ist die Ansicht einspaltig mit einer durchgehenden

Scrollachse: Nach der Analyse springt die Seite automatisch zur Auswertung; die Abschnitte sind als wischbare Chips dargestellt. Ein fester Aktionsknopf am unteren Rand startet vor der Analyse die Prüfung und springt danach zur nächsten offenen Lücke.

5. Kataloge laden & pflegen

• Automatisch: Sind Server-Kataloge vorhanden, lädt die App sie beim Start selbst.
• Manuell (Experten-Ansicht): Katalog & Optionen → Erweiterte Einstellungen

→ Katalogtyp wählen → Katalog importieren (XLSX/XLS/CSV/TXT/JSON). Der Import bleibt lokal im Browser (IndexedDB), die Datei wird nicht hochgeladen.

• „Kataloge aktualisieren" zieht erneut vom Server.
• Paket exportieren/importieren: sichert alle lokalen Kataloge als JSON bzw. lädt

sie in einem anderen Browser.

Katalogtypen (pädiatrisch maßgeblich): ICD-10-GM, OPS, EBM (inkl. Anhang 2 OPS→GOP), aG-DRG, Zusatzentgelte/Pflegeerlös.

Ohne geladene Kataloge sind Vorschläge mit „Vorläufiger Vorschlag, Referenzkatalog nicht geprüft" gekennzeichnet.

6. Eigene Regeln anlegen

• Button „Als Regel speichern" an einer Kode-Zeile macht ein Befund→Kode-Muster

künftig offline erkennbar.

• Regeln werden lokal gespeichert und (falls Server konfiguriert) geteilt

synchronisiert. Keine Patientendaten in Regeln aufnehmen.

• Verwaltung der Regeln über regeln.html.

7. Optionale Einstellungen

• Regionaler Punktwert (ct/Punkt): Default ist der Orientierungswert 12,7404 ct.

Eigenen KV-/Regionalwert eintragen, damit die €-Schätzung regional passt.

• Sachkosten / Material (€): optional. Fallabhängige Sachkosten (z. B. Material,

bestimmte Medikamente) stehen in keinem EBM-Katalog. Wird hier ein €-Betrag erfasst, rechnet ihn die Schätzung extrabudgetär (außerhalb MGV/RLV) hinzu.

• KI-Ergänzung (optional, opt-in): Häkchen setzen + Endpunkt (z. B.

/suggest-codes). Wird nur für nicht ableitbare Kodes und nur online aufgerufen. Vor dem Versand wird der Text anonymisiert; bei unsicherer Anonymisierung wird der Aufruf blockiert. Ergebnisse sind „KI-Vorschläge (zu prüfen)". Datenschutzhinweise: SICHERHEIT-DSGVO.md.

8. Datenschutz im Alltag

• Die Standardanalyse läuft lokal – der Bericht verlässt das Gerät nicht.
• Der eingegebene Berichtstext wird bewusst NICHT gespeichert: Ein Neuladen der

Seite leert das Berichtsfeld (Datenschutz an gemeinsam genutzten Rechnern). Einstellungen (Prüfziel, Kataloghaken, Punktwert) bleiben erhalten.

• Zur Verbesserung der App wird ein anonymisiertes Nutzungs-Protokoll geführt

(Stichwörter der Schnellsuche mit maskierten Ziffern, benutzte Funktionen, Geräteklasse). Niemals wird Berichtstext übertragen; die IP-Adresse wird nur als gekürzter Hash verarbeitet. Details: SICHERHEIT-DSGVO.md.

• Für Tests keine echten Patientendaten verwenden.

9. Fehlerbehebung

10. Grenzen

• Keine verbindliche Kodierung, kein Grouper, keine Rechtsverbindlichkeit.
• Vergütungswerte sind Schätzungen (× Punktwert) und gegen die Abrechnung zu prüfen.
• Stationäre DRG werden nicht simuliert; bei stationärer Begründung dient der

Setting-Vergleich nur der Orientierung.

• Maßgeblich bleiben die aktuelle Jahresversion, Kodierfachkraft, ärztliche

Verantwortung sowie MD-/Rechtsprüfung.

Handout – Pädiatrie-Coding-Assistent

Dokumentationsbasierte Kodierung aus Arztbrief/Entlassbrief · Pädiatrie · ambulant EBM & stationär aG-DRG (Stand 2026)

Druckfertige Fassung: docs/Handout_Peds-Coding.html im Browser öffnen → Drucken → Als PDF speichern (A4).

Zwei Leitziele

• Revisionssicher – kein Kode wird in der MD-Prüfung beanstandet/gekürzt; jede

risikoreiche Lücke wird mit der konkreten Schließfrage angezeigt.

• Bestmögliche Vergütung – vollständige, belegbare Kodierung, richtiges Setting und

eine geschätzte Vergütung je Fall.

Was die Software leistet

• ICD-10-GM & OPS aus dem Arztbrief/Entlassbrief, inkl. Haupt-/Nebendiagnosen und

Therapie→Diagnose (z. B. Phototherapie → Neugeborenen-Hyperbilirubinämie).

• EBM-Abrechnungskette je Leistung (ambulant): passende EBM-GOP, € (Punkte ×

regionaler Punktwert), extrabudgetär vs. budgetiert.

• aG-DRG-Kontext (stationär): Haupt-/Nebendiagnosen, OPS, DRG-Optimierung,

Verweildauer-Kontext (OGVD/UGVD), Schätzung (Bewertungsrelation × Landesbasisfallwert).

• Setting-Vergleich ambulant/EBM vs. stationär/aG-DRG (regelbasiert).
• Lücken-Punch-Liste (höchstes Kürzungsrisiko zuerst), Pädiatrie- und Kontextfaktor-Logik.
• Optionale KI-Ergänzung nur für nicht ableitbare Kodes (geerdet, als Vorschlag).

Neu (Juni 2026)

• Schnell-Kodierung aus Stichwort: ein Wort genügt („Fieberkrampf") → bis zu 5 passende

Diagnosen + 5 Maßnahmen zum Anhaken (inkl. Katalog-Volltextsuche und Tippfehler-/Kurzform-Toleranz: „Fieberkrmpf", „Bronchiolitiss").

• Beide Richtungen: Diagnose ↔ Maßnahme werden wechselseitig abgeleitet und klar

als „abgeleitet – bestätigen" markiert.

• Datenschutz verschärft: Berichtstext wird nicht mehr im Browser gespeichert;

Server-Protokolle nur anonymisiert (IP-Hash, maskierte Suchbegriffe).

• Gehärtet: Rate-Limit 8 Anfragen/Min./IP auf KI-Endpunkten, CSP/HSTS,

Code-/Konfigurationsdateien über den Browser nicht erreichbar.

• Mobil optimiert: automatischer Sprung zur Auswertung, Abschnitts-Chips.

Ablauf in 4 Schritten

1. Abrechnungsjahr, Fachbereich/Setting und Prüfziel wählen. 2. Arztbrief / Entlassbrief einfügen. 3. „Analyse starten“. 4. Leitkennzahlen lesen, Lücken schließen, Kodes/Bericht übernehmen.

Datenbasis (offiziell, 2026)

BfArM (ICD-10-GM, OPS) · KBV (EBM inkl. pädiatrierelevanter GOP, Anhang 2 OPS→GOP) · InEK (aG-DRG, Zusatzentgelte, Pflegeerlös). Auto-Import in den Browser, monatlicher Aktualitäts-Scan.

Beispiel: RSV-Bronchiolitis mit Exsikkose (stationär, Säugling 14 Monate)

• Status: mit Auflagen revisionssicher
• Hauptdiagnose J21.0 + Nebendiagnosen Exsikkose (E86.-), Fieber (R50.-)
• Maßnahmen: Sauerstoffgabe + i. v. Rehydratation + kontinuierliches Monitoring
• Setting: stationär begründet (Alter < … , Sauerstoffbedarf, unzureichende orale Zufuhr) ·

aG-DRG: Kandidat mit Grouper verifizieren

Entscheidungsunterstützung – alle Aussagen gegen die aktuelle Katalog-/Vertragsversion prüfen. Kein zertifizierter Grouper; Vergütungswerte sind Schätzungen.

Muster-Entlassbrief (Vorlage für den Pädiatrie-Coding-Assistenten)

Diese Vorlage zeigt, wie ein Arztbrief / Entlassbrief strukturiert sein sollte, damit der Pädiatrie-Coding-Assistent alle abrechnungsrelevanten Angaben sicher erkennt (ICD-10-GM Haupt-/Nebendiagnosen, OPS, ambulante EBM-Abbildbarkeit vs. stationäre aG-DRG, Dokumentationslücken).

Wichtig: Verwenden Sie für Tests keine echten Patientendaten. Die unten stehenden Namen/Nummern sind frei erfunden. Für die Analyse selbst genügt der medizinische Freitext – Name, Geburtsdatum und Fallnummer können entfallen.

Was der Assistent im Text sucht

Je vollständiger diese Punkte im Text stehen, desto höher die Revisionssicherheit und desto weniger Rückfragen erzeugt der Assistent.

A) Ausgefülltes Muster (stationär, aG-DRG-relevant)

ENTLASSBRIEF (Kinderklinik)

Einrichtung:        Muster-Kinderklinik / Pädiatrie
Stationsarzt:       Dr. med. [Stationsarzt]
Aufnahme:           [TT.MM.JJJJ]   Entlassung: [TT.MM.JJJJ]   Verweildauer: 3 Tage
Patient:            [anonymisiert – für Analyse nicht erforderlich], männlich, 14 Monate

Diagnosen
  Hauptdiagnose:
    Akute Bronchiolitis durch Respiratory-Syncytial-Virus (RSV-Schnelltest positiv)
    mit respiratorischer Beeinträchtigung.
  Nebendiagnosen:
    - Exsikkose bei Trinkschwäche (leicht- bis mittelgradig).
    - Fieber.

Anamnese:
  14 Monate alter Säugling, seit 3 Tagen zunehmender Husten, Rhinitis und Fieber bis
  39,2 °C. Seit dem Vortag deutlich reduzierte Trinkmenge (< 50 % der üblichen Menge),
  zunehmende Atemnot. Vorstellung über die Notaufnahme. Keine Vorerkrankungen, kein
  Frühgeborenes, Impfungen altersgerecht.

Aufnahmebefund:
  Reduzierter AZ, Tachypnoe (AF 56/min), sub-/interkostale Einziehungen, beidseits
  feinblasige RGs und exspiratorisches Giemen. SpO₂ 90 % unter Raumluft. Kapilläre
  Rekap-Zeit 2–3 s, trockene Schleimhäute. Temperatur 38,9 °C. Gewicht 10,2 kg.

Verlauf / Therapie:
  Stationäre Aufnahme zur Überwachung und Therapie. Sauerstoffgabe über Nasenbrille
  (initial 1–2 l/min), kontinuierliches Monitoring (SpO₂/HF/AF). Wegen unzureichender
  oraler Trinkmenge intravenöse Rehydratation/Infusionstherapie über 36 h. Inhalation
  mit NaCl 0,9 %, Antipyrese bei Bedarf, Nasentoilette. RSV-Schnelltest aus Nasen-
  sekret positiv. Im Verlauf rückläufige Atemnot; ab Tag 2 sauerstofffrei, Trinkmenge
  steigend, ab Tag 3 vollständige orale Flüssigkeitsaufnahme.

Komplikationen:
  Keine. Keine bakterielle Superinfektion, keine Beatmungspflicht.

Entlassungsbefund / Entlassfähigkeit:
  Afebril, AZ gut, SpO₂ 97 % unter Raumluft, keine Einziehungen, trinkt vollständig,
  Schleimhäute feucht. Kreislaufstabil. Entlassung in die ambulante kinderärztliche
  Weiterbetreuung.

Medikation bei Entlassung:
  Bei Bedarf Antipyrese (Paracetamol gewichtsadaptiert), Nasentropfen NaCl,
  ausreichende Flüssigkeitszufuhr.

Procedere:
  Wiedervorstellung beim Kinderarzt in 2–3 Tagen bzw. sofort bei erneuter Atemnot,
  Trinkverweigerung oder Fieber > 3 Tage.

Voraussichtliche Kodierung (vom Stationsarzt):
  Hauptdiagnose:  RSV-Bronchiolitis (ICD J21.0)
  Nebendiagnosen: Exsikkose (E86.-), Fieber (R50.-)
  Prozeduren:     Sauerstoffgabe, i. v. Rehydratation/Infusionstherapie,
                  kontinuierliches Monitoring (OPS endständig prüfen)

B) Leere Vorlage (zum Kopieren)

ENTLASSBRIEF / ARZTBRIEF (Pädiatrie)

Aufnahme:    [TT.MM.JJJJ]   Entlassung: [TT.MM.JJJJ]   Alter: [z. B. 14 Monate]
Setting:     [stationär (Station) / ambulant (Sprechstunde)]

Diagnosen:
  Hauptdiagnose:  [Klartext, z. B. „akute RSV-Bronchiolitis"]
  Nebendiagnosen: [z. B. Exsikkose, Trinkschwäche, Fieber]

Anamnese:
  [Beschwerden, Dauer, Trinkmenge, Vorerkrankungen, Impfstatus]

Aufnahmebefund:
  [AZ, Atemfrequenz, SpO₂, Auskultation, Hydratationszustand, Temperatur, Gewicht]

Verlauf / Therapie:
  [durchgeführte Maßnahmen: Sauerstoff / Inhalation / i. v. Rehydratation /
   Monitoring / Lumbalpunktion / Phototherapie …]
  [Ansprechen, Verweildauer-Begründung]

Komplikationen:
  [keine / konkret benennen]

Entlassungsbefund / Entlassfähigkeit:
  [AZ, SpO₂ unter Raumluft, Trinkverhalten, Kreislauf]
  [ambulant weiterführbar? oder weiterhin stationärer Bedarf + Grund]

Begründung stationär (nur falls stationär):
  [Kontextfaktor: z. B. Alter < 1 Jahr, Sauerstoffbedarf, unzureichende orale Zufuhr,
   relevante Begleiterkrankung]

Medikation bei Entlassung:
  [Wirkstoff gewichtsadaptiert, Dauer]

Procedere:
  [Wiedervorstellung, Warnzeichen]

Voraussichtliche Kodierung:
  Hauptdiagnose:  [ICD]
  Nebendiagnosen: [ICD]
  Prozeduren:     [OPS]

Tipps für hohe Trefferquote

• Alter immer angeben – in der Pädiatrie ist es kodier- und erlösrelevant

(altersabhängige ICD/OPS, DRG-Splits, EBM-GOP).

• Nebendiagnosen vollständig dokumentieren – sie bestimmen in der aG-DRG den

Schweregrad (PCCL) und sind für die richtige DRG entscheidend.

• Durchgeführte Maßnahmen benennen (Sauerstoff, i. v. Therapie, Monitoring,

Lumbalpunktion) → der Assistent kann den endständigen OPS-Detailkode vorschlagen.

• Entlassfähigkeit explizit dokumentieren – fehlt sie, markiert der Assistent eine

Lücke beim Setting (ambulant vs. stationär).

• Komplikationen aktiv verneinen („keine") – sonst entsteht eine Lücke.
• Bei stationärer Versorgung immer den Kontextfaktor nennen (z. B. Alter < 1 Jahr,

Sauerstoffbedarf), sonst droht ein Kürzungsrisiko bei der MD-Prüfung.

Alle vom Assistenten erzeugten Kodes sind Vorschläge und gegen die aktuelle Katalog-/Jahresversion, einen Grouper und die ärztliche/kodierfachliche Verantwortung zu prüfen.

Funktionsweise – exakte Logik des Pädiatrie-Coding-Assistenten

Dieses Dokument beschreibt die Analyse-Engine genau so, wie sie in web/app.js implementiert ist. Reihenfolge, Funktionsnamen und Datenflüsse entsprechen dem Code. Die Engine ist domänenneutral aufgebaut (Regeln + Kataloge); für Peds-Coding sind die Regeln und Kataloge pädiatrisch gefüllt (Arztbrief/Entlassbrief, ambulant EBM und stationär aG-DRG).

1. Architektur

• PWA / Frontend (web/) – enthält die gesamte Analyse-Logik. Es gibt kein

serverseitiges Rechnen für die regelbasierte Auswertung; alles läuft im Browser.

• Kataloge – liegen in der IndexedDB des Browsers. Sie werden entweder manuell

importiert (XLSX/CSV/TXT/JSON) oder beim Start automatisch vom Server geladen (./catalogs/manifest.json). Kataloge verlassen den Browser nicht.

• Server (server/, optional) – Node/Express. Liefert die statischen Dateien aus

und stellt bereit: KI-Endpunkte (/suggest-codes, /drg-upgrade), geteilte Kodierregeln (/api/rules, werden beim App-Start automatisch synchronisiert – Server ist maßgeblich, Offline-Änderungen werden hochgeschoben) sowie zwei anonymisierte Protokolle (/api/analysis-log, /api/usage-log mit Auswertung /api/usage-stats). Die Kernanalyse funktioniert offline ohne Server. Der nginx-Proxy davor härtet die App (Rate-Limit 8/min/IP auf KI-Endpunkten, CSP/HSTS, Dotfile-Sperre – server/aop-newkis.conf).

• Monatsjob – ein geplanter Remote-Agent (Routine) hält die Kataloge aktuell

(siehe BEDIENUNG.md).

2. Eingabe und Kontext

Beim Klick auf „Analyse starten" (handleAnalyze) wird der Bericht zusammen mit readMeta() an analyzeReport(text, meta) übergeben. meta enthält u. a.:

• billingYear, department (Fachbereich), reviewGoal (Prüfziel),
• references (welche Referenzen geladen sind),
• punktwert (regionaler Punktwert in ct, Default 12,7404 = Orientierungswert 2026),
• alle geladenen Kataloge. Die Feldnamen im Code sind aus der Engine-Historie generisch

benannt; pädiatrisch belegt werden insbesondere icdCatalog, opsCatalog, ebmCatalog, ebmAnhang2Catalog, agDrgCatalog, zusatzentgeltCatalog, pflegeErloesCatalog (die übrigen Slots aopCatalog, aopContextCatalog, fractureSurchargeCatalog, hybridCatalog, hybridVerguetungCatalog bleiben als optionale Container erhalten, werden in der Pädiatrie aber i. d. R. nicht befüllt).

createContext(text, meta) wendet zuerst die Schreibfehler-Toleranz an (applySpellingCorrections): unbekannte Wörter werden gegen das Vokabular aller Regel-Muster geprüft und bei geringer Editierdistanz korrigiert – auch in Komposita („Bronchiolitiss") und als Stamm-Korrektur für verstümmelte Kurzformen („Fieberkrmpf" → Fieberkrampf; saubere Präfixe wie „Pneumo"/„Gastro" bleiben bewusst unangetastet, weil sie legitime medizinische Nennungen sind). Alle Korrekturen werden im Kurzfazit ausgewiesen; das Original bleibt erhalten. Danach zerlegt die Funktion den Text in lines und sentences (für die Fundstellensuche) und hängt meta an.

3. Analyse-Pipeline (analyzeReport)

Die Funktion ruft – in dieser Reihenfolge – auf:

1. extractFacts – Dokucheck (Pflichtangaben des Arztbriefs/Entlassbriefs) 2. createIcdSuggestions – ICD-10-GM-Vorschläge (Haupt-/Nebendiagnosen) 3. createOpsSuggestions – OPS-Vorschläge (inkl. EBM-/Vergütungs-Anreicherung) 4. createDocumentationGaps – Dokumentationslücken (risiko-sortiert) 5. rateCoding – Kodierbarkeit 6. evaluateAop – Setting-/Abrechenbarkeitsprüfung (in der Pädiatrie: ambulant abrechenbar?) 7. evaluateHybrid – stationäre Vorprüfung (aG-DRG-Kontext / Settingvergleich) 8. createDocumentationSuggestions, createQuestions, createFinalRecommendation 9. computeAuditReadiness + computeValueEstimate – die beiden Leitkennzahlen

Hinweis zu den Funktionsnamen: evaluateAop/evaluateHybrid stammen aus der ursprünglichen Engine (ambulante Chirurgie). In Peds-Coding tragen sie die Setting-Logik der Pädiatrie: „ambulant (EBM) abrechenbar" gegen „stationäre Aufnahme (aG-DRG) begründet/erforderlich". Die Namen bleiben aus Kompatibilitäts- gründen unverändert.

3.1 Faktenextraktion (extractFacts)

FACT_DEFINITIONS definiert je Kategorie einen Finder (Regex-basiert über findEvidence/hasAny). Kategorien u. a.: Hauptdiagnose/Aufnahmegrund, Nebendiagnosen, Anamnese, Aufnahmebefund, Verlauf, durchgeführte Prozeduren/Maßnahmen (z. B. Infusionstherapie, Lumbalpunktion, Monitoring), Komplikationen, Entlassbefund/ Entlassfähigkeit, Verweildauer-Kontext, Medikation/Therapie. Jeder Fakt erhält present (ja/nein), documented (Wert) und evidence (Fundstelle).

3.2 ICD-Vorschläge (createIcdSuggestions)

• Direkt: ICD_RULES (Regex-Muster → ICD-Stamm/Endkode, Rolle, fehlende Angaben,

Alternativen). Treffer per hasAny(context, rule.patterns).

• Therapie → Diagnose: appendProcedureDerivedIcdSuggestions ergänzt ICDs, die sich

aus einer dokumentierten Prozedur/Maßnahme ergeben. Das Mapping PROCEDURE_TO_ICD verknüpft eindeutige OPS-Regeln mit der zugehörigen ICD-Regel (pädiatrische Beispiele: Phototherapie → Neugeborenen-Hyperbilirubinämie P59.-; Lumbalpunktion bei V. a. Meningitis; Inhalations-/Sauerstofftherapie bei RSV-Bronchiolitis). Solche Vorschläge sind mit „aus Prozedur abgeleitet" gekennzeichnet, Sicherheit „mittel".

• Fehlt alles: Fallback „Nicht ableitbar".

3.3 OPS-Vorschläge (createOpsSuggestions) und Anreicherung

• OPS_RULES (Regex → OPS-Stamm, Setting-Kandidat, Seitenrelevanz). Pädiatrisch belegt

mit Maßnahmen wie Lumbalpunktion, Infusions-/Rehydratationstherapie, Phototherapie, Atemunterstützung/Sauerstoff, kontinuierliches Monitoring.

• Importierte Katalogtreffer (OPS-Katalog) werden ergänzt.
• Diagnose → Therapie (appendDiagnosisDerivedOpsSuggestions): Wird im Text

KEINE Prozedur erkannt, aber eine Diagnose mit eindeutiger Standardmaßnahme (invertiertes PROCEDURE_TO_ICD, z. B. Exsikkose bei Gastroenteritis → Infusions-/Rehydratationstherapie), erscheint die Maßnahme als Verdachtsvorschlag (source: "diagnosis-derived", „abgeleitet – bestätigen"). Solche Vorschläge werden nicht bepreist (computeValueEstimate filtert sie) und lösen keine Widerspruchsprüfungen aus.

• Anreicherungskette je Vorschlag:
• enrichOpsSuggestionWithOpsCatalog – Treffer im OPS-Katalog,
• enrichOpsSuggestionWithAopCatalog – optionaler Treffer im AOP-Container (in der

Pädiatrie i. d. R. ungenutzt; Funktion bleibt aus Kompatibilität bestehen),

• enrichOpsSuggestionWithEbmAnhang2 – EBM-Zuordnung: ordnet dem OPS bzw. der

Maßnahme die passenden EBM-GOP (ambulante pädiatrische Leistungen) zu, soweit der EBM-/Anhang-Katalog geladen ist.

• €-Schätzung: estimateAmbulantBilling/computeAmbulantChain (siehe Abschnitt 4).

3.4 Dokumentationslücken (createDocumentationGaps)

Erzeugt Lücken aus fehlenden Pflichtangaben (Hauptdiagnose, Nebendiagnosen, Prozedur/ Maßnahme, Seite – falls sideRelevant –, Befund, Verlauf, Komplikationen, Entlassbefund/ Entlassfähigkeit). Danach:

• appendPediatricGaps – Alterslogik (siehe 6),
• appendRegelwerkChecks – Regelwerk-Prüfungen: DKR 1001 (CPAP-/High-Flow-

Beatmungsstunden bei Kindern, 8-h/24-h-Regel), MDC-15-Aufnahmegewicht (§-301-Pflichtfeld, P61–P67-Splits), Mindestmengen/QFR-RL (< 1.250 g → 25 Fälle/PNZ Level 1; < 1.500 g → Pflegeschlüssel), OPS 8-98d (Aufwandspunkte + MD-Strukturprüfung § 275d), Begleitpersonen-Entgelt (60 €/Berechnungstag, < 9 J. regelhaft), Hybrid-DRG- Kinderausschluss 2026 und FPV-§-2-Fallzusammenführung,

• appendFallwertContext – regionaler Fallwert-Kontext (KVBB) als Hinweis (sofern eine

Fachgruppe gesetzt ist),

• appendGoalSpecificGaps – prüfzielspezifische Prüfungen (siehe 5).

Zum Schluss sortGapsByRisk: Sortierung hoch → mittel → niedrig → Hinweis (Punch-Liste). Jede Lücke hat gap, why, risk, question.

3.5 Kodierbarkeit (rateCoding)

Bewertet gut / eingeschränkt / schlecht aus dem Vorhandensein belastbarer ICD/OPS und der Zahl kritischer Lücken. Beim Prüfziel MD gilt eine strengere Schwelle (0 kritische Lücken für „gut").

3.6 Ambulante Abrechenbarkeit (evaluateAop)

Filtert OPS/Maßnahmen mit aopCandidate und gleicht sie gegen den geladenen Katalog ab (findAopCatalogMatches). In der Pädiatrie dient dieser Schritt der Frage, ob der Fall ambulant über EBM abgebildet werden kann. Ergebnis ja/unklar plus Voraussetzungen/Hinweise.

3.7 Stationäre Vorprüfung (evaluateHybrid)

Setting-Abgleich: dokumentierte/abgeleitete OPS/Diagnosen werden geprüft, ob eine stationäre Aufnahme (aG-DRG) naheliegt oder erforderlich ist (z. B. Überwachungs-/ Therapiebedarf, Alter, Verweildauer). Funktionsname aus der Engine-Historie; die Logik zeigt für Peds-Coding den stationären Pfad statt einer Hybrid-DRG-Pflicht.

3.8 Schnell-Kodierung aus Stichwort (handleQuickSuggest)

Eigener Pfad NEBEN der Berichts-Analyse: Ein Stichwort („Fieberkrampf", „RSV-Bronchiolitis") läuft durch analyzeReport und wird als anhakbare Auswahl-Liste gerendert (renderQuickResults, bis zu 5 Optionen je Gruppe):

1. Exakte Regel-Treffer (vorangehakt). 2. Ähnlichkeitssuche über das Regelwerk (quickFuzzyCandidates): Wortstamm-, Präfix-, Enthaltensein- und Endungs-Vergleich plus Editierdistanz. Generische Morpheme (QUICK_GENERIC_SUFFIXES) zählen NICHT als Ähnlichkeit; inhaltstragende Endungen (z. B. „-bronchiolitis", „-gastroenteritis") verbinden dagegen die jeweilige Krankheits-Familie. 3. Katalog-Volltextsuche (quickCatalogCandidates): durchsucht die geladenen ICD-/OPS-Kataloge komplett (z. B. „Fieberkrampf" → R56.0; „Bronchiolitis" → J21.-). Ranking: Treffer am Beschreibungsanfang vor Treffern tief im Text; je Code-Stamm (ICD 3-stellig, OPS 5-stellig) nur der beste Eintrag.

Dedupliziert wird über den Code-Stamm (8-831.* ≙ 8-831.0). „Auswahl übernehmen & prüfen" schreibt die Auswahl als Mini-Bericht ins Berichtsfeld (Codes wörtlich → werden von der Vollanalyse als dokumentiert übernommen) und startet handleAnalyze.

4. €-Engine (Punkt-/€-Abrechnungskette)

computeAmbulantChain(anhangEntry, ebmCatalog, punktwertCt) baut die ambulante EBM-Kette aus den strukturierten Notizen des EBM-Eintrags:

• Positionen: die zur Leistung gehörenden EBM-GOP (Grund-/Versicherten-/

Komplexpauschalen und pädiatrierelevante Einzelleistungen), je nach Notiz als extrabudgetär oder budgetiert (RLV/HVM) markiert.

• Punkte je GOP aus ebmCatalog (ebmPoints, Feld „Punktzahl").
• € = Punkte × Punktwert / 100; Punktwert = regionaler Wert oder Default 12,7404 ct.
• Ausgewiesen werden Gesamtsumme und extrabudgetäre Teilsumme.

estimateAmbulantBilling formatiert daraus den Hinweistext am OPS-/Leistungsvorschlag („Geschätzte ambulante Vergütung …, davon extrabudgetär ≈ …; ohne Sachkosten; gegen Abrechnung prüfen").

Extrabudgetär vs. budgetiert: Welche GOP außerhalb der MGV/RLV vergütet werden, hängt von der EBM-/Vertragslage ab; die Engine übernimmt die Einordnung aus den Katalognotizen. Der regionale Fallwert je Fachgruppe (FALLWERTE_RLV_KVBB) wird, sofern hinterlegt, als Kontext eingeblendet.

Die stationäre Seite (aG-DRG) wird nicht über diese Punkt-/€-Kette berechnet, sondern als Bewertungsrelation × Landesbasisfallwert geschätzt (siehe Abschnitt 5, Setting-Vergleich) – ausdrücklich ohne zertifizierten Grouper.

5. Prüfziel-Logik (appendGoalSpecificGaps)

Das Prüfziel steuert die Auswertung spürbar:

• aop (Setting-/Abrechenbarkeitsprüfung): prüft u. a. die Entlassfähigkeit und ob

der Fall ambulant (EBM) abgebildet werden kann.

• kodierung (Kodieroptimierung): meldet nicht endständige (Stamm-)Kodes,

fehlende kodewirksame Detailangaben (z. B. Seite, Schweregrad, ätiologische Zusatzkodes) und vollständige Nebendiagnosen (in der aG-DRG erlös-/schweregradrelevant).

• stationaer (Stationäre Begründung): gleicht die Fall-Kodes gegen die hinterlegten

Kontextfaktoren ab (findContextFactorHits: stationär erforderliche OPS, nicht ambulant abbildbare ICD, Begleiterkrankungen, Alter u. a.) und ergänzt einen Setting- Vergütungsvergleich (appendSettingComparison): ambulant/EBM-€ vs. stationär aG-DRG (Textkandidat; Vergütung = Bewertungsrelation × Landesbasisfallwert).

• md (MD-/Kürzungsrisiko): strengere Schwellen, markiert unvollständige

Pflichtangaben und Stammkodes als kürzungsrelevant.

Der Matching-Grundsatz für Kontextfaktoren (findContextFactorHits): ein Treffer gilt nur, wenn der Fall-Kode gleich spezifisch oder spezifischer ist als der gelistete Kode – ein allgemeiner Stamm (z. B. J21) löst keine spezifischen Listeneinträge (J21.0) als Treffer aus (Vermeidung von Falsch-Positiven).

6. Pädiatrische Alterslogik (detectAgeBand / appendPediatricGaps)

detectAgeBand erkennt aus dem Text die Altersgruppe (Neugeborenes ≤ 28. Lebenstag, Säugling < 1 J., Kleinkind, Kind/Jugendliche, Erwachsene). In der Pädiatrie ist das Alter kodier- und erlösrelevant (altersabhängige ICD/OPS, DRG-Splits, EBM-GOP-Varianten):

• Neugeborenes/Säugling → Hinweis auf neonatale/altersspezifische Kodes und

potenziell höhere Überwachungs-/Aufnahmeindikation (stationär).

• < 1. Lebensjahr → stationäre Aufnahme/Überwachung kann begründet sein.
• Kleinkind/Kind + relevante Begleiterkrankung → stationäre Versorgung begründet.
• < 18 J. → Hinweis auf altersabhängige EBM-GOP-Varianten und Pädiatrie-spezifische

Pauschalen.

• Fehlt das Alter → niedriger Hinweis (altersabhängige Sonderlogik nicht prüfbar; in der

Pädiatrie ist die Altersangabe nahezu immer kodierrelevant).

7. Leitkennzahlen (Headline-Readouts)

• computeAuditReadiness(coding, gaps) → Revisionssicherheit:

zählt revisionsrelevante Lücken (Risiko enthält „Risiko"), nicht reine Hinweise.

• hohe Risiken vorhanden oder Kodierbarkeit „schlecht" → „Rückfrage-/Kürzungsrisiko",
• sonst Lücken vorhanden → „mit Auflagen revisionssicher",
• sonst → „revisionssicher". Inklusive Zahl offener Lücken.
• computeValueEstimate(context, opsSuggestions) → Geschätzte Vergütung:

€-Kette des primären OPS (gesamt + extrabudgetär).

Beide erscheinen oben im Kurzfazit (renderHeadlineReadouts) und im Kopier-/Druck-Bericht.

8. KI-Ergänzung (optional, /suggest-codes)

Nur wenn aktiviert und online: maybeFetchAiSuggestions ruft den Server-Endpunkt ausschließlich für Lücken (nicht ableitbare ICD/OPS) auf und erdet das Modell mit Auszügen aus den geladenen Katalogen (buildCatalogHints). Ergebnisse erscheinen in einem separaten Block „KI-Vorschläge (zu prüfen)". Server-Prompt (server/src/server.js) ist ein deutsches Medizincontrolling-Prompt (pädiatrischer Kontext) mit striktem JSON-Output und prüfzielspezifischem Fokus.

9. Kataloge und Auto-Import

Die Engine kennt 17 Katalog-Typen: die 12 Kode-Kataloge aus der Engine-Historie (icd, ops, aop, aopContext, fractureSurcharge, ebm, ebmAnhang2, hybrid, hybridVerguetung, agDrg, zusatzentgelt, pflegeErloes) sowie fünf Regelwerk-Kataloge (dkr, drgDefinitionen, nub, strukturRegeln, entgeltRegeln; codeKind regel), die aus DKR 2026, aG-DRG-Definitionshandbuch/Abschlussbericht, NUB-Aufstellung, QFR-RL/Mm-R/ PpUGV/LOPS und FPV/KHEntgG extrahierte Abrechnungsregeln als nachschlagbare Tabellen enthalten (Quelltabellen: server/src/data/regelwerke/*.entries.json, Build: server/src/build-regel-kataloge.mjs). Für die Pädiatrie maßgeblich sind icd, ops, ebm, ebmAnhang2, agDrg, zusatzentgelt, pflegeErloes plus die Regelwerk- Kataloge; die übrigen Slots bleiben als optionale Container erhalten.

• Format: App-Katalogpaket (kind: "peds-coding-assistant-catalog-package"; aus

Kompatibilität wird auch "aop-coding-assistant-catalog-package" akzeptiert, damit Exporte des AOP-Coding-Assistenten direkt importierbar sind), Einträge mit code, codeKind (icd/ops/ebm/drg/ze), description, optional ebmCodes/notes.

• Auto-Import (autoSyncCatalogsFromServer): beim Start wird ./catalogs/manifest.json

gelesen; Kataloge mit autoImport: true und neuerer version werden in die IndexedDB geladen. Ein Downgrade-Schutz verhindert, dass ein deutlich kleinerer Katalog einen größeren bereits geladenen ersetzt.

• Erzeugung: build-catalog-json.mjs (delimited/XLSX, mit `--sheet/--code-col/

--desc-col/--note-col) für ICD/OPS/EBM, build-fallpauschalen-extras.mjs (Zusatzentgelte + Pflegeerlös aus dem Fallpauschalenkatalog), build-ebm-anhang2.mjs (OPS→GOP-Zuordnung). Das Skript build-aopcontext-json.mjs` bleibt für optionale Kontextfaktor-Tabellen verfügbar.

10. Datenquellen (Stand 2026)

server/catalog-sources.json führt die offiziellen Quellen: BfArM (ICD-10-GM, OPS), InEK/g-drg.de (aG-DRG, Zusatzentgelte, Pflegeerlös), KBV (EBM inkl. pädiatrierelevanter GOP, Anhang 2 zur OPS→GOP-Zuordnung), sowie die KVBB-EBM-Änderungsübersicht (changesPage) für unterjährige GOP-Änderungen.

Bedienung, Betrieb & Katalogpflege – Pädiatrie-Coding-Assistent

Alle Anweisungen auf Deutsch. Drei Teile: A) Bedienung, B) Betrieb/Deployment, C) Katalogpflege & Monatsjob.

A) Bedienung (für Kodierfachkräfte / Ärztinnen und Ärzte)

Auswertung in 4 Schritten

1. Rahmen setzen (linke Spalte): Abrechnungsjahr, Fachbereich/Setting und das Prüfziel wählen:

• Ambulant/EBM-Prüfung – Standard für die pädiatrische Sprechstunde.
• Kodieroptimierung – maximale, belegbare Kodierschärfe (inkl. Nebendiagnosen für die aG-DRG).
• Stationäre Begründung prüfen – Kontextfaktoren + Setting-/Vergütungsvergleich (aG-DRG).
• MD- und Kürzungsrisiko prüfen – strengste Prüfung.

2. Arztbrief / Entlassbrief einfügen in das große Textfeld (deutscher Freitext genügt; Haupt-/Nebendiagnosen, Anamnese, Aufnahme-/Entlassbefund, Verlauf, durchgeführte Maßnahmen, Medikation und Entlassfähigkeit nennen). 3. „Analyse starten" klicken. 4. Auswertung lesen (rechte Spalte):

• Oben die zwei Leitkennzahlen Revisionssicherheit und Geschätzte Vergütung.
• Lücken/To-dos abarbeiten (oben = höchstes Kürzungsrisiko): zu jeder Lücke gibt es

die konkrete Frage, mit der sie geschlossen wird.

• Kodevorschläge (ICD/OPS) inkl. Abrechnungskette (ambulant: EBM-GOP, €).
• Bei Stationäre Begründung: Setting-Vergleich ambulant/EBM vs. stationär/aG-DRG.
• Auswertung über Kopieren/Drucken übernehmen.

Schnell-Kodierung aus Stichwort

Unter dem Prüfziel: ein Wort oder kurzer Satz („Fieberkrampf", „RSV-Bronchiolitis") → „Diagnose & Codes vorschlagen". Es erscheint eine anhakbare Liste mit bis zu 5 Diagnosen und 5 Maßnahmen (exakte Treffer vorangehakt, ähnliche Begriffe und abgeleitete Vorschläge markiert). „Auswahl übernehmen & prüfen" erstellt daraus einen Mini-Bericht und startet die Vollanalyse. Tippfehler/Kurzformen werden toleriert („Bronchiolitiss", „Fieberkrmpf").

Optionale Einstellungen (unter „Katalognotizen")

• Regionaler Punktwert (ct/Punkt): Default ist der Orientierungswert 12,7404 ct.

Eigenen KV-/Regionalwert eintragen, damit die €-Schätzung regional passt.

• KI-Ergänzung: Häkchen + Endpunkt (z. B. /suggest-codes). Wird nur für nicht

ableitbare Kodes und nur online aufgerufen; Ergebnisse sind als „KI-Vorschläge (zu prüfen)" gekennzeichnet.

Kataloge laden

• Automatisch: Sind Server-Kataloge vorhanden, lädt die App sie beim Start selbst.
• Manuell: Katalogverwaltung → Katalogtyp wählen → Katalog importieren

(XLSX/CSV/TXT/JSON). „Kataloge aktualisieren" zieht erneut vom Server.

• Status „Offline bereit": die App ist lokal zwischengespeichert und läuft ohne Internet.

Alle Vorschläge sind gegen die aktuelle Katalog-/Vertragsversion zu prüfen.

B) Betrieb / Deployment

Die PWA wird als statische Dateien über nginx ausgeliefert (root /srv/www/kind.newkis.io; try_files $uri $uri/ /index.html;). Der optionale Node-Server (127.0.0.1:3038) liefert zusätzlich /suggest-codes.

Hinweis: Host-/Pfadnamen (kind.newkis.io, Service-Worker-Cache-Präfix aop-coding-assistant-) sind technische Bezeichner der Deployment-Umgebung und bleiben aus Kompatibilität unverändert; nur das Repository heißt jetzt Peds-Coding.

Deploy auf dem Server

WEBROOT=/srv/www/kind.newkis.io
git -C /opt/Peds-Coding pull --ff-only origin main      # bzw. clone, s. u.
cp -f /opt/Peds-Coding/web/{index.html,app.js,styles.css,sw.js,colors_and_type.css,aop.css,aop-v2.css,be_logo.png} "$WEBROOT/"
cp -f /opt/Peds-Coding/web/{regeln.html,regeln.js} "$WEBROOT/"
cp -rf /opt/Peds-Coding/web/help "$WEBROOT/"          # Hilfe-Website (Bedienung & DSGVO)
cp -f /opt/Peds-Coding/server/public/catalogs/*.json "$WEBROOT/catalogs/"
# Service-Worker-Cache erneuern, damit Clients die neue app.js laden:
sed -i -E 's/(aop-coding-assistant-)[A-Za-z0-9._-]+/\1'"$(date +%Y%m%d%H%M)"'/' "$WEBROOT/sw.js"

Danach im Browser hart neu laden (Strg/Cmd + Umschalt + R).

Erstklon / nach Historien-Rewrite (falls git pull nicht durchläuft):

sudo rm -rf /opt/Peds-Coding && gh repo clone medinnovo/Peds-Coding /opt/Peds-Coding

Alternativ steht scripts/deploy-static.sh bereit:

sudo WEBROOT=/srv/www/kind.newkis.io bash /opt/Peds-Coding/scripts/deploy-static.sh

Prüfen nach dem Deploy

curl -s https://kind.newkis.io/app.js | grep -c autoSyncCatalogsFromServer   # >= 1
curl -s https://kind.newkis.io/catalogs/manifest.json | head -c 60           # JSON, kein HTML

KI-Server (optional)

cd /opt/Peds-Coding/server
cp .env.example .env        # OPENAI_API_KEY (+ ggf. OPENAI_MODEL) eintragen
npm install
npm start                   # http://127.0.0.1:3038  (hinter nginx reverse-proxien)

server/.env ist gitignored und darf nie committet werden.

C) Katalogpflege & Monatsjob

Manuell einen Katalog erzeugen

Quelldatei beschaffen (offizielle Quelle, siehe server/catalog-sources.json) und konvertieren, z. B.:

cd /opt/Peds-Coding/server
# ICD/OPS aus BfArM-Metadaten (TXT/CSV):
node src/build-catalog-json.mjs --type icd --in icd10gm2026syst_kodes.txt --version 2026 --source BfArM --out public/catalogs/icd.json
node src/build-catalog-json.mjs --type ops --in ops2026syst_kodes.txt --version 2026 --source BfArM --out public/catalogs/ops.json
# Zusatzentgelte + Pflegeerlös aus dem Fallpauschalen-Katalog (aG-DRG):
node src/build-fallpauschalen-extras.mjs --in Fallpauschalenkatalog_2026.xlsx --version 2026 --source InEK --out-dir public/catalogs
# EBM Anhang 2 (OPS→GOP):
node src/build-ebm-anhang2.mjs --in 2026-01-01-anhang2.csv --version 2026 --source KBV --out public/catalogs/ebmAnhang2.json

Anschließend den passenden Eintrag in public/catalogs/manifest.json aktualisieren (version, entryCount, file, autoImport). Quelldateien nicht committen (.zip, .xlsx, .csv, .pdf sind gitignored).

Monatlicher Auto-Scan (geplante Routine)

Eine geplante Routine (aop-catalog-update, monatlich am 2. um 07:00 UTC) prüft alle offiziellen Quellen aus catalog-sources.json – inkl. der KVBB-EBM-Änderungsübersicht (changesPage) für unterjährige GOP-Änderungen –, erzeugt geänderte Kataloge neu, aktualisiert manifest.json und das Register, eröffnet einen Pull Request und ein GitHub-Issue „Catalog status <YYYY-MM>" mit einer Tabelle der Änderungen. Sie merged nicht selbst. Verwaltung der Routine über die /schedule-Routinen in claude.ai.

Git-Historie schlank halten

Quelldateien gehören nicht in die Historie. Eine Bereinigung (git filter-repo --invert-paths --path <datei> … + force-push) hält .git klein; danach müssen vorhandene Klone neu geklont werden (kein git pull auf altem Stand).

Technischer Report: Funktionsweise der Analyse-Engine

Stand: 2026-06-02 · Quelle: web/app.js (~3.700 Zeilen) + server/src/server.js

Dieser Report beschreibt, wie die Engine im aktuellen Code arbeitet — nicht wie sie konzipiert ist, sondern was tatsächlich ausgeführt wird. Für Peds-Coding sind Regeln und Kataloge pädiatrisch belegt; die Funktions- und Feldnamen stammen aus der ursprünglichen Engine (ambulante Chirurgie) und bleiben aus Kompatibilität unverändert.

1. Grundprinzip

Drei Schichten, in dieser Reihenfolge der Verbindlichkeit:

1. Regelbasierte Analyse (immer, offline) — deterministische Regex-Regeln über den Freitext (Arztbrief/Entlassbrief). Das ist der verbindliche Kern. Erfindet nichts: Was nicht im Text steht, wird als Lücke markiert, nicht geraten. 2. Katalog-Erdung (wenn Kataloge geladen) — die Regel-Treffer werden gegen die importierten Originalkataloge (ICD, OPS, EBM, aG-DRG …) in IndexedDB abgeglichen und angereichert (Klartext, Subkodes, EBM-GOP, €-Kette). 3. KI-Ergänzung (optional, online) — nur wenn die Regeln eine Lücke lassen und der Nutzer es aktiviert. Liefert ausschließlich Vorschläge, die als „zu prüfen" gekennzeichnet sind.

Alles läuft als Vanilla-JS-PWA im Browser. Der Server (/suggest-codes) wird nur für die optionale KI gebraucht.

2. Pipeline (analyzeReport, app.js:1427)

Ein Lauf ist eine feste Sequenz reiner Funktionen — kein State, kein Netz:

analyzeReport(text, meta)
├─ createContext(text, meta)        → { text, lower, lines[], sentences[], meta }
├─ extractFacts(context)            → Faktenliste (Pflichtangaben Arztbrief/Entlassbrief)
├─ createIcdSuggestions(context)    → ICD-Vorschläge (Haupt-/Nebendiagnosen, Therapie→Dx)
├─ createOpsSuggestions(context)    → OPS-Vorschläge (+ Katalog-/EBM-/€-Anreicherung)
├─ createDocumentationGaps(...)     → priorisierte Lückenliste (Punch-Liste)
├─ rateCoding(...)                  → Kodierbarkeit (gut/eingeschränkt/schlecht)
├─ evaluateAop(...)                 → ambulante Abrechenbarkeit/EBM (ja/unklar)
├─ evaluateHybrid(...)              → stationäre Vorprüfung (aG-DRG-Kontext)
├─ createDocumentationSuggestions   → konkrete Nachdokumentations-Vorschläge
├─ createQuestions(...)             → offene Rückfragen
├─ createFinalRecommendation(...)   → Fazit
├─ computeAuditReadiness(...)       → Headline 1: Revisionssicherheit
└─ computeValueEstimate(...)        → Headline 2: geschätzte Vergütung

Der zurückgegebene report ist ein reines Datenobjekt; das Rendering (Abschnitt 11) ist strikt getrennt. evaluateAop/evaluateHybrid sind historische Namen; in Peds-Coding tragen sie die Settinglogik ambulant (EBM) vs. stationär (aG-DRG).

createContext (1495)

Normalisiert den Text einmalig: zeilenweise (lines), satzweise (sentences, Split an .!?) und lowercase (lower, deutsche Locale). Alle Finder arbeiten auf dieser Struktur.

3. Faktenextraktion (FACT_DEFINITIONS, app.js:372 / extractFacts, 1515)

Eine feste Pflichtangaben-Checkliste des Arztbriefs/Entlassbriefs, jeder Punkt hat einen finder(context):

Jeder Finder liefert { value, evidence, present }. present=false ⇒ später eine Lücke. Die Finder nutzen findByLinePrefix (Zeilen wie „Diagnose: …"), findEvidence (Regex-Suche mit Textbeleg) und hasAny (Existenzprüfung). markAbsentIfExplicitlyMissing erkennt aktiv verneinte Angaben („keine Komplikationen").

4. ICD-Vorschläge

Regelbasis (ICD_RULES, app.js:35)

Array von Objekten, jede Regel:

{ id, code: "J21.-", label, patterns: [/bronchiolitis/i, …],
  role: "Hauptdiagnose", missing: ["Erreger (RSV?)", "respiratorische Insuffizienz?", …], alternatives }

createIcdSuggestions (1528): filtert alle Regeln, deren patterns im Text matchen, und baut pro Treffer einen Vorschlag. Sicherheit ist heuristisch: Stammkode (enthält - oder /) ⇒ „mittel", endständig ⇒ „hoch"; > 2 offene Pflichtangaben drücken auf „mittel". enrichMissing (2092) erweitert die Pflichtangabenliste kontextabhängig.

Therapie → Diagnose (appendProcedureDerivedIcdSuggestions, 1572)

Schlüsselmechanismus: Eine dokumentierte Prozedur/Maßnahme kann die Diagnose nahelegen, auch wenn die Diagnose nicht im Text steht. OPS-Regeln tragen dafür impliedIcdId; zusätzlich gibt es die Tabelle PROCEDURE_TO_ICD (355). Pädiatrische Beispiele: „Phototherapie" ⇒ Neugeborenen-Hyperbilirubinämie (P59.-), „Rehydratations-/Infusionstherapie" ⇒ Exsikkose bei Gastroenteritis. Diese Ableitungen werden als Verdachtsdiagnose mit Sicherheit „mittel" markiert.

Findet keine Regel etwas, liefert die Engine bewusst „Nicht ableitbar" statt zu raten.

5. OPS-Vorschläge (createOpsSuggestions, app.js:1602)

Regelbasis (OPS_RULES, 173)

{ id, code: "8-831.*", label, patterns, missing, alternatives,
  aopCandidate: true, hybridCandidate: true, sideRelevant: false, impliedIcdId }

(Pädiatrische OPS-Beispiele: Lumbalpunktion 1-204, Infusions-/Rehydratationstherapie, Phototherapie 8-560, Atemunterstützung/Sauerstoff, kontinuierliches Monitoring.) Jeder Regel-Treffer durchläuft eine Anreicherungs-Kaskade (drei verschachtelte Funktionen):

enrichOpsSuggestionWithOpsCatalog   → Klartext + Subkodes aus OPS-Katalog
  └─ enrichOpsSuggestionWithAopCatalog → optionaler Container-Treffer (i. d. R. ungenutzt)
       └─ enrichOpsSuggestionWithEbmAnhang2 → EBM-GOP-Zuordnung + €-Kette (ambulant)

Zusätzlich erzeugt die Engine Vorschläge aus im Text genannten Kodes: Wenn der Arztbrief/Entlassbrief selbst OPS-Kodes enthält (extractOpsCodes), werden diese gegen den OPS-Katalog aufgelöst (createImportedCatalogOpsSuggestions / createImportedOpsCatalogSuggestions).

Kode-Matching (findOpsCatalogMatches, createOpsCodeMatchers, 1997/2009)

OPS-Kodes werden tolerant gematcht: 8-831.* matcht 8-831.0 etc. (Stamm-→Subkode), Punkte/Sterne werden normalisiert (normalizeOpsCode).

5b. Bidirektionale Ableitung & Schnell-Kodierung

• Therapie → Diagnose (appendProcedureDerivedIcdSuggestions): dokumentierte

Prozedur legt die ICD nahe (PROCEDURE_TO_ICD, nur eindeutige Paare).

• Diagnose → Therapie (appendDiagnosisDerivedOpsSuggestions): greift NUR, wenn

sonst kein OPS erkannt würde; Vorschlag source: "diagnosis-derived", wird nicht bepreist und von Widerspruchsprüfungen ausgenommen.

• Stamm-Korrektur in correctSpellingToken: Token mit Editierdistanz GENAU 1 zum

Begriffs-Anfang wird expandiert („Fieberkrmpf" → Fieberkrampf); ist das Token sauberes Präfix IRGENDEINES Vokabular-Begriffs („Pneumo", „Gastro"), bleibt es unangetastet.

• Schnell-Kodierung (handleQuickSuggest → renderQuickResults): bis zu 5

Optionen je Gruppe = exakte Treffer + quickFuzzyCandidates (Regelwerk, generische Morpheme QUICK_GENERIC_SUFFIXES ausgeschlossen) + quickCatalogCandidates (Volltext über die geladenen ICD-/OPS-Kataloge, Ranking nach Trefferposition, Dedup je Code-Stamm).

6. €-Vergütungskette (computeAmbulantChain, app.js:1879)

Das Herzstück der „bestmögliche Vergütung"-Logik auf der ambulanten (EBM-)Seite. Quelle der Wahrheit sind die Notizen der EBM-(Anhang-2-)Einträge, aus denen per Regex die Abrechnungspositionen geparst werden. Pädiatrisch sind das die einschlägigen EBM-GOP (z. B. Versicherten-/Grund-/Komplexpauschalen und Zusatzleistungen), je nach Katalognotiz als extrabudgetär oder RLV/HVM-budgetiert markiert.

HYGIENE_BY_OPGOP (1674) und vergleichbare chirurgische Zuschlagstabellen bleiben aus Kompatibilität im Code, werden in der Pädiatrie aber i. d. R. nicht angesteuert.

Punkte → Euro: Für jede GOP holt ebmPoints (1868) die Punktzahl aus dem EBM-Katalog (Notiz Punktzahl: N). Summe × Orientierungswert (Default 0,127404 €/Punkt = 12,7404 ct, Wert 2026, regional überschreibbar via Punktwert-Feld). Ausgegeben werden Gesamtsumme und extrabudgetärer Anteil getrennt.

Wichtige Eigenschaft: Findet die Kette nur eine Position, ist das ein Hinweis auf einen unvollständigen EBM-Eintrag — die Kette ist gegen die geladene Vertragslage zu prüfen. Die stationäre Seite (aG-DRG) wird nicht über diese Punkt-/€-Kette, sondern als Bewertungsrelation × Landesbasisfallwert geschätzt (Setting-Vergleich, Abschnitt 8) — ausdrücklich ohne Grouper.

Bewusste Grenzen: kein Grouper, ohne Sachkosten, Schätzung — explizit „gegen Abrechnung prüfen".

7. Dokumentationslücken (createDocumentationGaps, app.js:2135)

Erzeugt die Punch-Liste. Basis-Lücken werden aus den fehlenden Fakten abgeleitet, jede mit makeGap(titel, warum, risiko, rückfrage). Risikostufen steuern alles Weitere:

• hoch — fehlende Haupt-/Nebendiagnose oder Prozedur/Maßnahme (Ablehnungsrisiko)
• mittel — fehlender Befund/Verlauf/Schweregrad/Komplikation/Entlassbefund
• niedrig — Anamnese-/Kontextangaben
• Hinweis — Kontext, Optimierung, regionale Faktoren (zählen nicht als Mangel)

Danach hängen sich drei Erweiterungen an:

• appendPediatricGaps (2250) — alters­spezifische Hinweise (detectAgeBand)
• appendFallwertContext (2207) — regionaler RLV-Fallwert je Fachgruppe *(deaktiviert, seit

das Fachbereich-Feld entfernt wurde — FALLWERTE_RLV_KVBB[""] ist leer, Funktion kehrt ohne Hinweis zurück)*

• appendGoalSpecificGaps (2319) — prüfzielabhängig, siehe Abschnitt 8

Zum Schluss sortiert sortGapsByRisk (2188) stabil nach Risiko (hoch → … → Hinweis).

8. Prüfziel-Logik (appendGoalSpecificGaps, app.js:2319)

Vier Ziele (getReviewGoal), jedes ändert Lücken, Fokus und Bewertungs-Schwellen:

Kontextfaktor-Abgleich (findContextFactorHits, 2426)

Gleicht Fall-Kodes gegen den (optionalen) Kontextfaktoren-Katalog ab. Präzisionsregel: Ein Treffer zählt nur, wenn der Fall-Kode genauso oder spezifischer ist als der gelistete Kode (entryCode === c || c.startsWith(entryCode + ".")). Ein Stammkode J21 löst also nicht den spezifischen Eintrag J21.0 aus.

Setting-Vergütungsvergleich (appendSettingComparison, 2528)

Stellt die Settings gegenüber (als Hinweis, kein Grouper):

• Ambulant/EBM — €-Kette aus Abschnitt 6
• Stationär aG-DRG — Kandidat per Textähnlichkeit; Vergütung = Bewertungsrelation ×

Landesbasisfallwert. (Der historische Hybrid-DRG-Pfad ist in der Pädiatrie nicht belegt.)

Die stationären Kandidaten (appendStationaryBillingHints, 2474) sind reine Textähnlichkeit (Token-Overlap ≥ 2, billingTokens mit Stoppwortliste) gegen die aG-DRG-/ZE-/Pflege-Kataloge — ausdrücklich als „mit Grouper verifizieren" gekennzeichnet.

9. Bewertungen & Headline-Readouts

Die zwei Headlines bilden die Nordstern-Fragen ab: „Ist der Fall revisionssicher?" und „Was ist er wert?".

10. Katalog-Subsystem (IndexedDB + Auto-Sync)

• Speicher: IndexedDB (aop-coding-assistant-catalogs – interner DB-Name, aus

Kompatibilität unverändert), ein Store, ein Eintrag je Katalogtyp. Geladen beim Start (loadAllCatalogs), offline verfügbar.

• Auto-Sync (autoSyncCatalogsFromServer, 513): zieht beim Start ./catalogs/manifest.json

und lädt jeden Katalog, dessen version neuer ist als die lokale. Zwei Schutzmechanismen: autoImport:false wird übersprungen; ein lokaler Katalog wird nicht durch eine Server-Version mit < 50 % der Einträge ersetzt (Schutz gegen unvollständige Veröffentlichung).

• Manueller Import: XLSX/CSV/JSON über parseCatalogFile; XLSX via vendored SheetJS.

buildCatalogFromRows erkennt Code-Spalten heuristisch (extractOpsCodes / …IcdCodes / …EbmCodes / …DrgCodes) und merged Duplikate.

• Typen (CATALOG_TYPES, 9): icd, ops, aop, aopContext, fractureSurcharge, ebm,

ebmAnhang2, hybrid, hybridVerguetung, agDrg, zusatzentgelt, pflegeErloes.

• Die eigentlichen Konvertierungs-Skripte (build-*.mjs) erzeugen die JSON-Kataloge aus den

amtlichen Quelldateien; der Monatsjob (aop-catalog-update) aktualisiert Manifest + Dateien.

11. KI-Ergänzung (maybeFetchAiSuggestions, app.js:709 + Server)

Wird nur aufgerufen, wenn: 1. „KI-Ergänzung" angehakt ist (aiEnabled), und 2. die Regeln eine Lücke lassen (hasCodeGap für ICD oder OPS), und 3. das Gerät online ist.

Dann POST an /suggest-codes (Default; Feld „KI-Endpunkt" überschreibt die URL) mit: text, meta {billingYear, reviewGoal}, gaps, bereits erkannte ruleCodes (zum Nicht-Doppeln) und catalogHints.

buildCatalogHints (668) liefert seit dem letzten Update alle geladenen Kataloge: ein vollständiges Inventar (welche Kataloge, Versionen, Eintragszahl) plus die zum Bericht passenden Einträge aus jedem Katalog (Code- oder Stichworttreffer, max. 40/Katalog, Gesamtbudget 60.000 Zeichen). Volltextkataloge passen nicht komplett ins Prompt — daher Inventar + relevante Treffer.

Server (server/src/server.js): baut System-Prompt (deutscher Medizincontroller, pädiatrischer Kontext, „nichts erfinden", JSON-Schema), fügt ein zielspezifisches GOAL_FOCUS hinzu, hängt die catalogHints (bis 60.000 Zeichen) an, ruft OpenAI (Default-Modell gpt-5.4-mini, response_format: json_object, Temperatur 0,1). Antwort: {icd[], ops[], hints}. Im UI landet das in einem separaten, als „zu prüfen" markierten Abschnitt — es überschreibt nie die regelbasierten Vorschläge.

12. Rendering (v2-Layer, app.js ab ~2989)

Strikt vom Datenmodell getrennt. renderReport füllt zwei persistente Headline-Karten (Revisionssicherheit, geschätzte Vergütung mit Aufschlüsselungs-Balken) + drei Verdikt-Tiles (ambulant/EBM, stationär/aG-DRG, Kodierbarkeit) und baut Tab-Abschnitte: Codes · Vergütung & Simulation · Prüfpunkte · Audit-Trail · Fazit. applyGoalFocus springt je Prüfziel auf den passenden Default-Tab. Prüfpunkte bündelt Dokumentations-Check, Widersprüche, offene Lücken/To-dos und die Kodier-QS; Erledigtes wird in v2Done gemerkt. Bei stationären Fällen (kein EBM-Anhang-2-Treffer) zeigen Kennzahlen-Kopf und Vergütungs-Tab die aG-DRG-Schätzung (BR × BBFW + Päd.-Zuschlag) statt der ambulanten Kette. Das Fazit ist ein Prioritäten-Dashboard (buildSummary): Topzeile mit fünf Status (Revisionssicherheit/Vergütung/AOP/Hybrid/Kodierbarkeit) plus Punch-List mit Tab-Sprüngen und One-Tap-Kopien (Operateur-Rückfrage, MD-Kurzbegründung, Kodier-Notiz). Die Eingabe kennt zwei Modi (voller Bericht vs. Schnell-Kodierung, setInputMode), und applyDisplayPrefs schaltet zwischen einfacher Ansicht (Default) und Experten-Ansicht (.expert-only: Katalogverwaltung, Sim-Schalter, DRG-Grouper, Audit-Trail).

13. Bekannte Grenzen (bewusst)

• Kein DRG-Grouper. Die stationäre aG-DRG-Vergütung ist Textähnlichkeit, keine

Fallpauschalen-Berechnung.

• Regex-Präzision. Die Regelbasis ist kuratiert; eine Katalog-Volltextsuche als

Diagnose-Finder wurde getestet und verworfen (deutsche Komposita erzeugen Falschtreffer). Neue Befunde kommen daher über neue kuratierte Regeln oder über die KI (zu bestätigen), nicht über automatische Volltextsuche.

• €-Schätzung. Ohne Sachkosten, Orientierungswert statt regionalem Punktwert

(überschreibbar), explizit als Schätzung gekennzeichnet.

• KI = Vorschlag. Nie verbindlich, immer gegen Katalog zu prüfen, nur bei Lücke + online.

Governance-Engine — Entwicklerdoku

Erweiterung der bestehenden analyzeReport-Pipeline (web/app.js) um Revisions- sicherheit, Best-Code-Selektion, Scoring, Widerspruchsprüfung und Readiness. Regelbasiert + offline bleibt führend; KI ist nachgelagert und überschreibt nie.

Funktionsnamen stammen aus der ursprünglichen Engine (ambulante Chirurgie) und bleiben aus Kompatibilität unverändert; Regeln/Kataloge sind für Peds-Coding pädiatrisch belegt.

Pipeline (erweitert)

analyzeReport(text, meta): 1. createContext → 2. extractFacts → 3. createIcdSuggestions → 4. createOpsSuggestions → detectCodingContradictions → annotateSuggestions (Provenienz/Score/Endständigkeit) → 5. createDocumentationGaps (+ appendPediatricCodingChecks) → 6. rateCoding → 7. evaluateAop → 8. evaluateHybrid → evaluateAopContextSafety → 9.–12. documentation/draft/questions/finalRecommendation → selectBestCodingCandidates → 13. computeAuditReadiness (erweitert) → 14. computeValueEstimate (erweitert).

Report-Objekt zusätzlich: contradictions, aopContext, bestCoding.

Neue Funktionen

Erweiterte Funktionen

• computeAmbulantChain → complete, completenessLevel, missingBillingElements, warning, budgeted/extrabudgetary. Nur-Einzelposition (z. B. eine einzelne GOP) wird als Warnung markiert.
• computeAuditReadiness(coding, gaps, opts) → status (revisionssicher|mit Auflagen|Kürzungsrisiko|nicht abrechnungsreif), score, topRisks, blockingIssues, requiredBeforeBilling, safeToBill (+ alte Felder).
• computeValueEstimate → status, bestAvailablePath, safeValue, optimizationValue, warnings, requiredCatalogs (+ €/Summen). Stationäre DRG wird NICHT simuliert.
• maybeFetchAiSuggestions → anonymisiert vor Versand, blockiert bei unsicherer Anonymisierung; KI-Vorschläge bleiben „zu prüfen", überschreiben nie.

UI

Neue Tabs Sicher / Optimierung (section-best) und Widersprüche (section-issues). Jede Code-Zeile zeigt Quelle · Konfidenz · Score · Endständigkeit · Beleg + Widerspruchs-Warnung. Fazit zeigt Audit-Readiness, Vergütung zeigt Value-Readiness.

Rückwärtskompatibilität

Bestehende Felder (security, evidence, missing) bleiben; security = neue confidence. Defensive Defaults für neue Felder. „Nicht ableitbar" → notCodable:true (gültiges Ergebnis).

Neuere Erweiterungen (2026-06-04)

• Dx→OPS-/OPS→Dx-Ableitung (diagnosis-derived ohne Bepreisung/Widerspruchsprüfung)
• Stamm-Korrektur für Kurzformen (Fieberkrmpf→Fieberkrampf), Begriffs-Schutz (Pneumo/Gastro)
• Schnell-Kodierung: Auswahl-Liste, Ähnlichkeits- + Katalog-Volltextsuche
• Anonymisiertes Nutzungs-Log (/api/usage-log, /api/usage-stats)
• nginx-Härtung: Rate-Limit 8/min/IP (KI), CSP/HSTS, Dotfile-Sperre

Tests

node test/engine.test.mjs — 26 Checks (15 Fälle + Querschnitt + Anonymisierung), headless via vm + echte Kataloge. Lokal: node test/engine.test.mjs (Exit 0 = grün).

Sicherheits- & DSGVO-Bericht — Pädiatrie-Coding-Assistent

Stand: 2026-06-04 · Bezug: web/ (PWA) und server/ (optionaler Node-Dienst)

Dieser Bericht beschreibt die tatsächlichen Datenflüsse, die Speicherorte und die datenschutzrechtliche Einordnung des Pädiatrie-Coding-Assistenten. Er ist eine technische Grundlage für die Verarbeitungsverzeichnisse und die Datenschutz-Folgenabschätzung (DSFA) des verantwortlichen Hauses – er ersetzt keine Rechtsberatung.

1. Kurzfazit

• Die Kernanalyse läuft zu 100 % lokal im Browser (regelbasiert, ohne Netzwerk).

Der Arztbrief/Entlassbrief verlässt das Gerät dabei nicht.

• Es gibt drei optionale, ausdrücklich zu aktivierende KI-Funktionen, die Text an

einen Server senden. Vor jedem Versand wird der Text automatisch anonymisiert; bei unsicherer Anonymisierung wird der Versand blockiert.

• Der mitgelieferte Server proxyt KI-Anfragen an die OpenAI-API (Drittland USA).

Werden die KI-Funktionen genutzt, ist dieser Übermittlungspfad DSGVO-relevant und vertraglich abzusichern (AVV + Transfer-Mechanismus).

• **Patientenidentifikatoren werden weder als gelernte Regel noch beim Regel-Sync

übertragen** – dort fließen nur Befund→Kode-Muster.

• Speicherung: Der eingegebene Arztbrief/Entlassbrief wird bewusst NICHT persistiert –

ein Neuladen leert das Berichtsfeld (Privacy by Design; Altbestände früherer Versionen werden beim Start automatisch aus dem localStorage entfernt). Nur Einstellungen und gelernte Regeln bleiben lokal; Kataloge liegen in IndexedDB.

• Server-Protokolle: Es gibt zwei anonymisierte Protokolle (Analyse-Log mit

Kodes/Bewertungen, Nutzungs-Log mit Schnellsuche-Begriffen und Funktionsnutzung). Beide arbeiten mit serverseitiger Whitelist-Sanitisierung; Berichtstext wird nie übertragen, die IP nur als gekürzter Hash verarbeitet (Abschnitt 2.7).

• Härtung (umgesetzt): Rate-Limit 8 Anfragen/Minute/IP auf KI-Endpunkten,

CSP/HSTS/Security-Header, Sperre versteckter Dateien (/.git u. a.), privates Quellcode-Repository (Abschnitt 4.5).

2. Datenflüsse im Detail

2.1 Lokale Analyse (Standardbetrieb) — kein Datenabfluss

• Eingabe des Arztbriefs/Entlassbriefs → regelbasierte Extraktion in web/app.js

(analyzeReport), reine Verarbeitung im Browser-Tab.

• Es findet kein Netzwerk-Request mit Berichtsinhalt statt.
• Ergebnis (Kodevorschläge, Lücken, Vergütungsschätzung) wird im DOM gerendert und

kann lokal kopiert/gedruckt/als Datei exportiert werden (MD/JSON/FHIR).

2.2 Katalog-Versorgung — keine personenbezogenen Daten

• Auto-Update: Beim Start lädt die App ./catalogs/manifest.json und die

Katalog-JSONs vom selben Origin (fetch, GET). Es werden nur Referenzkataloge geladen, keine Berichtsdaten gesendet.

• Manueller Import: XLSX/CSV/TXT/JSON werden lokal im Browser geparst

(vendor/xlsx.full.min.js) und in IndexedDB gespeichert. Die Datei wird nicht hochgeladen.

2.3 Service Worker (Offline-Fähigkeit) — kein Datenabfluss

• web/sw.js cached ausschließlich die App-Shell (eigene HTML/JS/CSS, same-origin

GET). Fremde Origins und Nicht-GET-Requests werden ignoriert. Keine Berichtsinhalte im Cache.

2.4 Gelernte Kodierregeln (/api/rules) — keine Patientendaten

• „Als Regel speichern" erzeugt ein Befund→Kode-Muster (Stichwortmuster + Zielkode).
• Diese Regeln liegen lokal im localStorage und werden optional mit dem Server

synchronisiert (GET/PUT/POST/DELETE /api/rules, CORS offen).

• Keine Patientenidentifikatoren in den Regeln – so auch im Code dokumentiert.

Dennoch gilt: Freitext-Muster sind sorgfältig zu wählen, damit kein Fallbezug entsteht.

2.5 Optionale KI-Funktionen — DSGVO-relevanter Pfad

Drei Funktionen, nur aktiv bei gesetztem Häkchen „KI-Ergänzung" und konfiguriertem Endpunkt, nur online, und nur wenn die Regeln eine Lücke offen lassen:

Schutzmechanismen vor dem Versand (anonymizeClinicalText):

• Entfernt/ersetzt: E-Mail, Telefon, Datums-/Geburtsangaben, Fall-/Patienten-/

KIS-Nummern, lange Ziffernfolgen, Namenszeilen, Anrede + Eigenname, Adressen.

• Erkennt unsichere Restmuster (z. B. „Nachname, Ziffer") und **blockiert dann den

Versand** mit Hinweis „Patientendaten manuell entfernen".

• Übertragen werden nur: anonymisierter Text, Abrechnungsjahr, Prüfziel,

Kode-Kandidaten/Hinweise. KI-Ergebnisse sind als „zu prüfen" markiert und überschreiben die regelbasierte Analyse nie.

Restrisiko: Anonymisierung ist heuristisch (regelbasiert), keine Garantie. Seltene Namensformen ohne Anrede o. Ä. können theoretisch verbleiben. Daher ist die KI-Funktion nur mit organisatorischer Freigabe und auf einem abgesicherten Endpunkt einzusetzen.

2.6 Server-Komponente (server/src/server.js)

• Liefert das Frontend statisch aus, stellt /api/rules und die KI-Endpunkte bereit.
• POST /analyze und die KI-Endpunkte proxyen an die OpenAI-API (OPENAI_API_KEY,

Default-Modell gpt-5.4-mini). Damit verlässt anonymisierter Text die EU Richtung OpenAI (USA).

• API-Key liegt serverseitig in .env (nicht im Browser).

2.7 Anonymisierte Server-Protokolle — designgemäß ohne Patientendaten

Analyse-Log (POST /api/analysis-log): Nach jeder Analyse werden ausschließlich Kodes (ICD/OPS/EBM/aG-DRG), Qualitäts-/Setting-Bewertungen, generische Lücken-Titel und Schreibkorrektur-Wortpaare gespeichert – serverseitige Whitelist in server/src/analysis-log.js; Berichtstext wird nie übertragen.

Nutzungs-Log (POST /api/usage-log, Auswertung GET /api/usage-stats): Zur Verbesserung der App werden Events gespeichert (server/src/usage-log.js):

• Schnellsuche-Begriffe (kleingeschrieben, Ziffernfolgen maskiert –

Geburtsdaten/Fallnummern werden zu # –, max. 60 Zeichen) mit Trefferzahl,

• Funktionsnutzung (Tabs, Export, Druck, Regel-Speichern – nur feste Bezeichner),
• Sitzungsdaten (App-Version, Viewport, Sprache, Geräteklasse mobil/desktop).

Herkunft ohne Personenbezug: Die IP-Adresse wird nicht gespeichert, sondern zu sha256(IP + Salt) gehasht und auf 12 Zeichen gekürzt – distinct-Zählung möglich, Rückrechnung nicht. Der Berichtstext und das große Eingabefeld sind von diesem Logging vollständig ausgenommen.

3. Wo werden Daten gespeichert?

Konsequenz: Seit Version 2026-06-04 hält der Browser keinen Berichtstext mehr vor – das frühere Hauptrisiko (Klartext im localStorage) ist konstruktiv beseitigt. An Gemeinschafts-PCs bleibt ein eigenes/abgemeldetes Browserprofil empfehlenswert.

4. DSGVO-Einordnung

4.1 Rechtsgrundlagen (typisch im Krankenhaus/MVZ)

• Verarbeitung zu Behandlungs-/Abrechnungszwecken: **Art. 9 Abs. 2 lit. h i. V. m.

Art. 6 Abs. 1 lit. b/c DSGVO** und § 22 BDSG, ergänzt durch SGB V (u. a. §§ 295, 301) und landesrechtliche/kirchliche Datenschutzregelungen.

• Verantwortlicher i. S. d. Art. 4 Nr. 7 DSGVO ist das einsetzende Haus, nicht der

Software-Hersteller.

4.2 Datenminimierung & Privacy by Design (Art. 5, Art. 25)

• ✅ Standardpfad ohne Datenübermittlung (lokale Verarbeitung).
• ✅ KI opt-in, nur bei Lücken, nur online, mit vorgeschalteter Anonymisierung und

Block bei Unsicherheit.

• ✅ Regel-Sync ohne Patientenidentifikatoren.
• ✅ Kein Persistieren des Berichtstexts (seit 2026-06-04; Altbestände werden

beim Start bereinigt).

• ✅ Server-Protokolle nur anonymisiert mit Whitelist + IP-Hash (Abschnitt 2.7).

4.3 Auftragsverarbeitung & Drittlandübermittlung (Art. 28, 44 ff.)

Nur relevant, wenn die KI-Funktion genutzt wird:

• AVV mit OpenAI (bzw. dem konfigurierten Endpunkt-Betreiber) abschließen.
• Transfer-Mechanismus (EU-US Data Privacy Framework und/oder Standardvertrags-

klauseln + TIA) dokumentieren.

• Alternativ einen EU-gehosteten / On-Prem-Endpunkt konfigurieren, um die

Drittlandübermittlung zu vermeiden.

4.4 Betroffenenrechte (Art. 15–21)

• Auskunft/Löschung lokal: Browserdaten bzw. „Zurücksetzen".
• Serverseitig sind nur nicht-personenbezogene Regeln gespeichert.

4.5 TOM (Art. 32) — Stand der Umsetzung

Umgesetzt (nginx, server/aop-newkis.conf):

• TLS (Let's-Encrypt) + HSTS (1 Jahr, includeSubDomains).
• Rate-Limit pro Client-IP: KI-Endpunkte (/suggest-codes, /analyze,

/drg-upgrade) strikt 8 Anfragen/Minute (429 darüber); App-API (/api/) 30/min; max. 20 parallele Verbindungen/IP (Slowloris-Schutz).

• Content-Security-Policy (nur eigene Skripte, keine Inline-Skripte → XSS-Schutz),

X-Frame-Options DENY, Referrer-Policy, Permissions-Policy, nosniff.

• Versteckte Dateien gesperrt (location ~ /\. → 404): .git, .env & Co.

sind über den Browser nicht erreichbar; das Deploy-Skript kopiert sie zusätzlich gar nicht erst in den Webroot. Das Quellcode-Repository ist privat.

• OPENAI_API_KEY ausschließlich serverseitig in .env, nie im Frontend.

Offen / organisatorisch:

• CORS für /api/ einschränken (derzeit *) auf die bekannten Origins.
• KI-Endpunkt ggf. zusätzlich authentifizieren/IP-beschränken.
• Geräte-Härtung an Gemeinschafts-PCs (automatische Abmeldung, Browserprofile).

5. Risikoübersicht

6. Empfohlene Maßnahmen (Checkliste)

• ☐ Entscheidung dokumentieren: KI-Funktion an oder aus.
• ☐ Bei KI an: AVV + Transfer-Mechanismus oder EU/On-Prem-Endpunkt.
• ☐ CORS-Allowlist statt * für /api/.
• ☑ TLS + HSTS + CSP/Security-Header am Reverse-Proxy (umgesetzt).
• ☑ Rate-Limit 8/min/IP auf KI-Endpunkten (umgesetzt).
• ☑ Kein Berichtstext im localStorage (umgesetzt 2026-06-04).
• ☐ Aufbewahrungsfristen für data/analyses/ und data/usage/ festlegen.
• ☐ In Verarbeitungsverzeichnis/DSFA aufnehmen.
• ☐ Nutzer schulen: keine echten Patientendaten in Testläufen; „Zurücksetzen" nutzen.

Grundlage: Quellcode-Analyse web/app.js, web/sw.js, web/regeln.js, server/src/server.js, server/src/usage-log.js, server/aop-newkis.conf (Stand 2026-06-04). Rechtliche Einordnung durch die Datenschutzbeauftragte/den Datenschutzbeauftragten des Hauses zu verifizieren.

Qualitätsmanagement-Handbuch — Pädiatrie-Coding-Assistent

Dok-ID: QMH-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Dieses Handbuch beschreibt das Qualitätsmanagementsystem (QMS) für die Entwicklung und den Betrieb des Pädiatrie-Coding-Assistenten. Es ist an ISO 9001:2015 ausgerichtet und bildet die Klammer über die mitgeltenden Einzeldokumente. Es ist eine Selbstauskunft des Hauses und ersetzt keine Zertifizierung; es ist die Grundlage, auf der ein externes Audit aufsetzen kann.

Geltungsbereich (Scope): Entwicklung, Pflege, Auslieferung und Betrieb der Webanwendung „Pädiatrie-Coding-Assistent" (PWA web/, optionaler Node-Dienst server/, Referenzkataloge, Dokumentation). Nicht im Geltungsbereich: die ärztliche Kodier-/Abrechnungsentscheidung beim einsetzenden Haus (das ist Anwenderprozess).

1. Was dieses Produkt ist (und was nicht)

Dokumentationsbasierte Entscheidungsunterstützung für die pädiatrische Kodierung und Abrechnung – ambulant (EBM/GOP) und stationär (aG-DRG) – auf Basis des Arztbriefs/ Entlassbriefs. Die Kernanalyse läuft regelbasiert und offline im Browser. Details und die rechtliche Einordnung stehen in der Zweckbestimmung:

• Kein Medizinprodukt im Sinne der MDR/IVDR — der Zweck ist administrativ

(Abrechnung/Kodierung), nicht Diagnose oder Therapie. Daher ist ISO 13485 nicht der einschlägige Standard; maßgeblich sind ISO 9001 (Qualität), DSGVO (Datenschutz) und ISO-27001-Prinzipien (Informationssicherheit).

• Kein zertifizierter Grouper. Vergütungswerte sind Schätzungen; alle Kode-, GOP-,

aG-DRG- und €-Aussagen sind gegen die aktuelle Katalog-/Vertragsversion zu prüfen.

2. Qualitätspolitik & Ziele

Die Qualitätspolitik und die messbaren Qualitätsziele (KPIs) sind in der Qualitätspolitik festgelegt. Kurz: revisionssicher kodieren und die bestmögliche, regelkonforme Vergütung je Fall ermöglichen — bei strenger Datenminimierung.

3. Prozesslandschaft (Process Approach, ISO 9001 Kap. 4.4)

4. ISO 9001:2015 — Kapitel-Abdeckung

5. Mitgeltende Dokumente

• Qualitätspolitik & Ziele (QM-POL-01)
• Zweckbestimmung & regulatorische Einordnung (QM-ZWB-01)
• Risikomanagement (QM-RIS-01)
• Dokumenten- & Änderungslenkung (QM-DOK-01)
• Aufbewahrung & Löschkonzept (QM-AUF-01)
• Fehler- & Korrekturmaßnahmen (CAPA) (QM-CAPA-01)
• Internes Audit & Management-Review (QM-AUD-01)
• Informationssicherheit (ISO 27001) (QM-ISO27-01)
• Sicherheit & DSGVO
• Repo: CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md, CHANGELOG.md

6. Rollen & Verantwortung (RACI, ISO 9001 Kap. 5.3)

Im Ein-/Kleinteam-Betrieb können mehrere Rollen in Personalunion liegen; die Verantwortlichkeit pro Aufgabe bleibt dennoch eindeutig benannt.

7. Pflege dieses Handbuchs

Mindestens jährlich sowie bei wesentlichen Änderungen zu überprüfen (siehe DOKUMENTENLENKUNG). Änderungen werden in CHANGELOG.md und im Git-Verlauf nachvollziehbar geführt.

Qualitätspolitik & Qualitätsziele — Pädiatrie-Coding-Assistent

Dok-ID: QM-POL-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

1. Unsere Qualitätspolitik

Der Pädiatrie-Coding-Assistent unterstützt Ärztinnen, Ärzte und Kodierfachkräfte dabei, pädiatrische Fälle (ambulant EBM und stationär aG-DRG) revisionssicher zu kodieren und die bestmögliche, regelkonforme Vergütung je Fall zu erreichen. Qualität bedeutet für uns:

• Korrektheit vor Vollständigkeit: Lieber ein konservativer, belegbarer Kode als ein

optimistischer, der in der MD-Prüfung gekürzt wird. Ohne Beleg nie „hohe" Konfidenz; KI schlägt nur vor und überschreibt die regelbasierte Analyse nie.

• Transparenz: Jede Aussage ist nachvollziehbar (Quelle · Konfidenz · Score ·

Endständigkeit · Beleg). Die Funktionsweise ist offen dokumentiert.

• Datenminimierung als Standard: Die Kernanalyse läuft lokal ohne Datenabfluss; der

eingegebene Arztbrief/Entlassbrief wird nicht persistiert; Protokolle sind anonymisiert.

• Aktualität: Kataloge und Regeln werden gegen die jeweils gültige Jahres-/Vertrags-

version gepflegt.

• Ständige Verbesserung: Fehler werden erfasst, analysiert und abgestellt

(CAPA); Audits und Management-Review steuern die Weiterentwicklung.

Die Leitung verpflichtet sich, die für diese Politik nötigen Ressourcen bereitzustellen und die Politik regelmäßig auf Eignung zu überprüfen.

2. Messbare Qualitätsziele (KPIs)

Die Ziele werden im jährlichen Management-Review bewertet.

3. Bezug zu den Risiken

Die Ziele adressieren direkt die in RISIKOMANAGEMENT geführten Top-Risiken (Fehlkodierung, veraltete Kataloge, Datenschutz, Sicherheit). Abweichungen vom Zielwert lösen eine CAPA aus.

Zweckbestimmung & regulatorische Einordnung — Pädiatrie-Coding-Assistent

Dok-ID: QM-ZWB-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Dieses Dokument legt die Zweckbestimmung (Intended Purpose) fest und ordnet das Produkt regulatorisch ein (MDR/IVDR, ISO 13485). Es ist die Grundlage dafür, welche Normen einschlägig sind und welche nicht. Es ersetzt keine Rechtsberatung; die endgültige Einordnung trifft der Hersteller bzw. das einsetzende Haus.

1. Zweckbestimmung (Intended Purpose)

Der Pädiatrie-Coding-Assistent ist ein dokumentationsbasiertes Hilfsmittel zur Unterstützung der Kodierung und Abrechnung in der Pädiatrie in Deutschland – sowohl ambulant (EBM/GOP in der pädiatrischen Sprechstunde) als auch stationär (aG-DRG auf der pädiatrischen Station). Er

• prüft einen vom Anwender eingegebenen Arztbrief / Entlassbrief (bzw. die Klinik-

dokumentation) regelbasiert auf Vollständigkeit und Dokumentationslücken,

• schlägt ICD-10-GM- (Haupt-/Nebendiagnosen), OPS-, aG-DRG- und EBM-Kodes sowie

Abrechnungsketten vor,

• schätzt Revisionssicherheit und Vergütung (ambulant EBM, stationär aG-DRG) und
• formuliert Klär-/Optimierungshinweise.

Anwender (Intended Users): Ärztinnen/Ärzte, Kodierfachkräfte, Medizincontrolling. Einsatzumgebung: Verwaltungs-/Abrechnungskontext in pädiatrischer Praxis/MVZ und Kinderklinik/-station.

2. Ausdrückliche Nicht-Zweckbestimmung (Limitations)

Der Pädiatrie-Coding-Assistent ist nicht bestimmt für und nicht geeignet als:

• Diagnose, Screening, Prävention, Überwachung, Vorhersage, Prognose, Behandlung oder

Linderung einer Krankheit;

• Steuerung oder Beeinflussung einer therapeutischen oder diagnostischen Maßnahme am Patienten;
• Ersatz der ärztlichen Entscheidung oder der Prüfung durch eine Kodierfachkraft;
• zertifizierter DRG-Grouper. Vergütungswerte sind Schätzungen.

Alle Ausgaben sind Vorschläge zur menschlichen Prüfung und gegen die jeweils gültige Katalog-/Vertragsversion zu verifizieren.

3. MDR/IVDR-Einordnung — kein Medizinprodukt

Schlussfolgerung: Der Pädiatrie-Coding-Assistent ist nach derzeitiger Bewertung kein Medizinprodukt im Sinne der Verordnung (EU) 2017/745 (MDR) und kein In-vitro-Diagnostikum nach (EU) 2017/746 (IVDR). Folglich ist ISO 13485 (QMS für Medizinprodukte) nicht der einschlägige Standard; das QMS richtet sich nach ISO 9001 (Qualität), DSGVO (Datenschutz) und ISO-27001-Prinzipien (Informationssicherheit).

Wichtige Grenze (Re-Klassifizierungs-Trigger): Würde das Produkt künftig erweitert um Funktionen, die klinische Entscheidungen unterstützen (z. B. Therapieempfehlungen, Diagnose-Vorschläge auf Basis von Patientenbefunden, Risiko-Scores zur Behandlungssteuerung), ist die MDR-Einordnung neu zu bewerten — dann könnten ISO 13485 und ein MDR-Konformitäts- bewertungsverfahren erforderlich werden. Solche Änderungen sind über die Dokumenten- & Änderungslenkung als wesentliche Änderung zu behandeln.

4. Pflichtangaben am Produkt

Der Hinweis-/Disclaimer-Charakter ist in der App und der Dokumentation sichtbar zu halten (Footer/Hilfe): „Entscheidungsunterstützung — alle Kode-, GOP-, aG-DRG- und €-Aussagen sind gegen die aktuelle Katalog-/Vertragsversion zu prüfen. Kein zertifizierter Grouper; Vergütungswerte sind Schätzungen." Diese Anforderung ist umgesetzt (docs/index.html, Hilfe-Website, App-Footer).

5. Verweise

• QM-Handbuch · Qualitätspolitik ·

Risikomanagement · Sicherheit & DSGVO

• MDR (EU) 2017/745, Art. 2 · MDCG 2019-11 · IVDR (EU) 2017/746

Risikomanagement — Pädiatrie-Coding-Assistent

Dok-ID: QM-RIS-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Risiken & Chancen nach ISO 9001:2015 Kap. 6.1. Während sich der Sicherheits- & DSGVO-Bericht auf Datenschutz-/Sicherheitsrisiken (R1–R8) konzentriert, erfasst dieses Dokument zusätzlich Produkt- und Qualitätsrisiken (Fehlkodierung, Aktualität, Anwendung). Bewertung über eine einfache FMEA-Logik.

1. Bewertungsskala

• W (Wahrscheinlichkeit): 1 selten · 2 gelegentlich · 3 häufig
• A (Auswirkung): 1 gering · 2 spürbar · 3 schwer (z. B. Kürzung/Regress, Datenschutzverstoß)
• RPZ = W × A (Risikoprioritätszahl). RPZ ≥ 6 ⇒ Maßnahme verpflichtend und im

Management-Review zu verfolgen.

2. Produkt- & Qualitätsrisiken (FMEA)

3. Sicherheits- & Datenschutzrisiken

Geführt im Sicherheits- & DSGVO-Bericht, Abschnitt 5 (R1–R8) und in der Informationssicherheit (SoA). Wesentliche offene Punkte:

• R2 Drittlandübermittlung via OpenAI (nur bei KI-Opt-in) → AVV + Transfer-Mechanismus.
• R4 Offener CORS auf /api → adressiert: Allowlist über CORS_ALLOWED_ORIGINS

konfigurierbar (Default unverändert *; produktiv eng setzen).

4. Chancen (ISO 9001 Kap. 6.1)

• Anonymisierte Nutzungs-/Analyse-Logs → datengetriebene Verbesserung der Regelbasis

(Suchbegriffe ohne Treffer = Regel-Lücken).

• Offene, prüfbare Dokumentation → Vertrauen, leichtere Audits, leichteres Onboarding.

5. Steuerung

Risiken mit RPZ ≥ 6 werden im jährlichen Management-Review bewertet; neu auftretende Fehler laufen über das CAPA-Register und können neue Risikozeilen erzeugen. Wesentliche Produktänderungen lösen eine Neubewertung dieser Tabelle aus.

Dokumenten- & Änderungslenkung — Pädiatrie-Coding-Assistent

Dok-ID: QM-DOK-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Lenkung dokumentierter Information (ISO 9001:2015 Kap. 7.5) und Änderungs-/Release- Management (Kap. 8.5.6). Ziel: gültige Dokumente sind eindeutig identifizierbar, freigegeben, auffindbar und versioniert; Änderungen am Produkt sind nachvollziehbar.

1. Dokumentenkennung

Jedes QM-Dokument trägt im Kopf: Dok-ID, Version, Stand (Datum), Freigabe (Rolle) und Nächste Prüfung. Verbindlich ist immer die Fassung im main-Branch des Repositories; ältere Stände sind über den Git-Verlauf rekonstruierbar.

2. Lebenszyklus eines Dokuments

• Erstellen/Ändern → Pull Request mit Beschreibung der Änderung (CONTRIBUTING.md).
• Prüfen → Review durch eine zweite Rolle bzw. dokumentierte Selbstprüfung im Solobetrieb.
• Freigeben → Merge nach main durch die Freigabe-Rolle; Versionsnummer im Kopf erhöht.
• Veröffentlichen → ggf. Hilfe-Website neu bauen (node scripts/build-help-site.mjs).
• Überprüfen → spätestens zum Termin „Nächste Prüfung" oder bei Anlass.

Versionsregel: redaktionell ⇒ +0.1; inhaltlich wesentlich ⇒ +1.0.

3. Dokumentenregister (Stand 2026-06-09)

4. Änderungs- & Release-Management (Produkt)

• Versionierung: Semantische Versionierung (MAJOR.MINOR.PATCH) in package.json.

Aktuelle Produktversion in CHANGELOG.md.

• Branches: Arbeit erfolgt auf Feature-Branches, niemals direkt auf main (außer

triviale Doku). PR + grüne CI sind Voraussetzung für Merge.

• Tests als Tor: .github/workflows/ci.yml führt test/*.mjs aus; rote Tests blockieren

den Release (Ziel Q1).

• Wesentliche Änderungen (Engine-Logik, Datenflüsse, Zweck): zusätzlich Risiko-

(RISIKOMANAGEMENT) und ggf. Zweck-Neubewertung (ZWECKBESTIMMUNG).

• Nachvollziehbarkeit: Jede Änderung ist über aussagekräftige Commit-Messages

(feat/fix/…) und CHANGELOG.md belegt.

5. Aufzeichnungen (Records)

Aufbewahrungspflichtige Aufzeichnungen (Audit-Protokolle, Management-Reviews, CAPA-Einträge, Release-Notes) und deren Fristen sind im Aufbewahrungs- & Löschkonzept geregelt.

Aufbewahrung & Löschkonzept — Pädiatrie-Coding-Assistent

Dok-ID: QM-AUF-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung / DSB des Hauses · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Aufbewahrungsfristen und Löschregeln für Aufzeichnungen und Betriebsdaten (ISO 9001 Kap. 7.5.3, DSGVO Art. 5 Abs. 1 lit. e, ISO 27001 A.5.33/5.34). Schließt den offenen DSGVO-Punkt „Aufbewahrungsfristen für data/analyses/ und data/usage/ festlegen" (SICHERHEIT-DSGVO, Kap. 6).

1. Grundsätze

• Datenminimierung: Der eingegebene Arztbrief-/Entlassbrieftext wird nicht gespeichert (Privacy by Design).
• Anonymität vor Aufbewahrung: Server-Protokolle enthalten designgemäß keine

Personenbezüge (Whitelist, maskierte Begriffe, IP nur als Hash).

• Begrenzte Speicherdauer: Betriebsdaten werden nur so lange aufbewahrt, wie sie dem

Zweck (Verbesserung, Nachvollziehbarkeit, QM-Nachweis) dienen, danach automatisiert gelöscht.

2. Aufbewahrungs-/Löschmatrix

Die Fristen sind Vorgaben des Herstellers; das einsetzende Haus kann aufgrund eigener Aufbewahrungs-/Abrechnungspflichten abweichende Fristen festlegen und in seinem Verarbeitungsverzeichnis dokumentieren.

3. Automatisierte Durchsetzung

Das Skript scripts/prune-data.mjs löscht Dateien in den Daten-Verzeichnissen, die älter als die konfigurierte Frist sind:

# Vorschau (löscht nichts):
node scripts/prune-data.mjs --dry-run

# Anwenden (Standardfristen: analyses/usage 180 Tage, feedback 365 Tage):
node scripts/prune-data.mjs

# Fristen überschreibbar per Umgebungsvariable (Tage):
RETENTION_ANALYSES_DAYS=90 RETENTION_USAGE_DAYS=90 RETENTION_FEEDBACK_DAYS=180 node scripts/prune-data.mjs

Empfehlung Betrieb: als täglichen Cron-Job einrichten, z. B.

15 3 * * *  cd /opt/Peds-Coding && /usr/bin/node scripts/prune-data.mjs >> /var/log/peds-coding-prune.log 2>&1

4. Betroffenenrechte & Löschung auf Verlangen

Da die Server-Protokolle anonym sind, besteht kein Personenbezug, der gelöscht werden müsste. Lokale Daten (Einstellungen/Regeln/Kataloge) löscht der Anwender selbst über „Zurücksetzen" bzw. die Browser-Datenlöschung. Siehe SICHERHEIT-DSGVO, Kap. 4.4.

Fehler- & Korrekturmaßnahmen (CAPA) — Pädiatrie-Coding-Assistent

Dok-ID: QM-CAPA-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Umgang mit Nichtkonformitäten und Korrekturmaßnahmen (ISO 9001:2015 Kap. 10.2) sowie Vorfallbehandlung (ISO 27001 A.5.24 ff.). CAPA = Corrective and Preventive Action.

1. Was ist eine Nichtkonformität?

Jede Abweichung von Anforderung, Ziel oder Erwartung, u. a.:

• Fehlkodierung / falscher Vorschlag der Engine (auch via Anwender-Feedback gemeldet),
• veralteter Katalog / verpasste Jahresaktualisierung,
• Sicherheits-/Datenschutzvorfall (z. B. unbeabsichtigter Datenabfluss),
• Verfehlen eines Qualitätsziels (Qualitätspolitik, KPIs),
• fehlgeschlagener Release / roter CI-Lauf, der Nutzer erreicht.

2. Ablauf

• Erfassen: Eintrag im Register (Abschnitt 4) oder als GitHub-Issue mit Label

nonconformity. Quelle kann Anwender-Feedback, Test, Audit oder Betrieb sein.

• Sofortmaßnahme (Containment): unmittelbare Eindämmung (z. B. Funktion deaktivieren,

Hinweis schalten, Rollback).

• Ursachenanalyse (Root Cause): 5-Why / einfache Ursache-Wirkung; warum trat es auf

und warum wurde es nicht früher erkannt?

• Korrekturmaßnahme: Behebung der Ursache (Code-Fix + Regressionstest, der den

Fehler künftig fängt).

• Vorbeugung (Preventive): ähnliche Fälle ausschließen (Regel, Test, Doku, Checkliste).
• Wirksamkeitsprüfung: im nächsten Management-Review bestätigen,

dass die Maßnahme wirkt; erst dann „geschlossen".

Zielzeiten: kritisch (Patientendatenschutz, Fehlkodierung mit Regressrisiko) ≤ 14 Tage bis Korrektur (KPI Q7); übrige nach Priorität.

3. Schweregrade

4. CAPA-Register (Vorlage)

Neue Einträge unten anhängen. Bei Schließung Datum + Ergebnis der Wirksamkeitsprüfung eintragen.

5. Verknüpfungen

Wiederkehrende oder schwere CAPA-Fälle aktualisieren das Risikomanagement und ggf. die Qualitätsziele. Sicherheitsmeldungen von außen kommen über SECURITY.md herein.

Internes Audit & Management-Review — Pädiatrie-Coding-Assistent

Dok-ID: QM-AUD-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Programm für interne Audits (ISO 9001:2015 Kap. 9.2) und Managementbewertung (Kap. 9.3). Zweck: regelmäßig prüfen, ob das QMS umgesetzt, wirksam und aktuell ist, und daraus Verbesserungen ableiten.

1. Audit-Programm

• Frequenz: mindestens jährlich (Vollaudit) plus anlassbezogen nach wesentlichen

Änderungen oder schweren CAPA-Fällen.

• Unabhängigkeit: Prüfer auditiert nicht ausschließlich eigene Arbeit; im Solobetrieb ist

die Selbstprüfung anhand der Checkliste zu dokumentieren (mit Datum/Befund).

• Ergebnis: Audit-Bericht mit Befunden (konform / Hinweis / Nichtkonformität).

Nichtkonformitäten werden als CAPA eröffnet.

2. Interne-Audit-Checkliste

3. Management-Review (jährlich)

Eingaben (Inputs): Status der KPIs, Audit-Befunde, offene/geschlossene CAPA, Risikolage, Anwender-Feedback, Katalog-/Sicherheitslage, Status früherer Maßnahmen, Änderungen im Umfeld (Kataloge, Recht, Zweck).

Ergebnisse (Outputs): Entscheidungen zu Verbesserungen, Ressourcen, Zieländerungen, neuen/aktualisierten Risiken, Freigaben.

Protokoll-Vorlage

Management-Review Pädiatrie-Coding-Assistent
Datum:            ____   Teilnehmende: ____
1. KPI-Status (Q1–Q8):        Ziel erreicht? Abweichungen?
2. Audit-Befunde:             Anzahl Hinweise/NC, Schwerpunkte
3. CAPA:                      offen/geschlossen, Zielzeiten gehalten?
4. Risiken:                   neue/geänderte, RPZ ≥ 6 Status
5. Feedback der Anwender:     Tenor, abgeleitete Maßnahmen
6. Sicherheit/Datenschutz:    Vorfälle, AVV/Transfer, Abhängigkeiten
7. Zweckbestimmung:           weiterhin „kein Medizinprodukt"? Trigger?
8. Beschlüsse & Maßnahmen:    Wer / Was / Bis wann
Nächstes Review:  ____

4. Aufbewahrung

Audit-Berichte und Review-Protokolle werden gemäß AUFBEWAHRUNG (mindestens 3 Jahre) im Repository bzw. Git-Verlauf geführt.

Informationssicherheit (ISO-27001-orientiert) — Pädiatrie-Coding-Assistent

Dok-ID: QM-ISO27-01 · Version: 1.0 · Stand: 2026-06-09 · Freigabe: Betrieb / Produktverantwortung (Newkis) · Nächste Prüfung: 2027-06-09

Autoren: Galapagensis · Carlos A. Reck-Burneo · drcarlos@burneo.com · Herausgeber: Newkis

Dieses Dokument fasst die Informationssicherheits-Leitlinie und eine schlanke Anwendbarkeitserklärung (Statement of Applicability, SoA) an den Maßnahmenzielen aus ISO/IEC 27001:2022 Anhang A zusammen. Es ergänzt den Sicherheits- & DSGVO-Bericht um die organisatorische ISMS-Sicht. Es ist eine Selbstauskunft, keine ISO-27001-Zertifizierung.

1. Leitlinie zur Informationssicherheit

Schutzziele für den Pädiatrie-Coding-Assistenten:

• Vertraulichkeit: Keine Patientendaten verlassen unkontrolliert das Gerät; der

Arztbrief/Entlassbrief wird nicht persistiert; Protokolle sind anonymisiert (Whitelist, IP-Hash).

• Integrität: Kodierlogik ist deterministisch und versioniert; Kataloge stammen aus

amtlichen Quellen; Änderungen sind über Git nachvollziehbar.

• Verfügbarkeit: Offline-fähige PWA; der optionale KI-Dienst ist nicht

betriebskritisch (Kernanalyse funktioniert ohne ihn).

Die Leitung benennt eine verantwortliche Rolle für Informationssicherheit (siehe QM-Handbuch, Kap. 6) und überprüft die Leitlinie jährlich.

2. Werte (Assets) & Schutzbedarf

3. Anwendbarkeitserklärung (SoA-lite) — ISO/IEC 27001:2022 Anhang A

4. Offene Punkte / Empfehlungen

• ☐ CORS-Allowlist aktiv setzen: CORS_ALLOWED_ORIGINS in server/.env auf die

bekannten Origins statt Default * (Mechanismus umgesetzt — siehe .env.example).

• ☐ AVV + Transfer-Mechanismus mit OpenAI dokumentieren, falls KI genutzt wird.
• ☐ Backup-Konzept für server/data/ und Katalogquellen schriftlich festlegen.
• ☐ Strukturiertes Logging (z. B. Pino) erwägen, falls Audit-Trail-Anforderungen steigen.

5. Verweise

• Sicherheit & DSGVO (technische Datenflüsse, Risiken R1–R8) ·

Risikomanagement · CAPA · SECURITY.md · server/aop-newkis.conf (nginx-Härtung)