Bedienungsanweisung — AOP-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 AOP-Coding-Assistent prüft einen deutschsprachigen OP-Bericht dokumentations­ basiert auf:

• ICD-10-GM- und OPS-Hinweise,
• AOP-Relevanz nach §115b SGB V (ambulantes Operieren),
• Hybrid-DRG-Vorprüfung,
• Dokumentationslücken und Rückfragen an den Operateur,
• eine Vergütungsschätzung (Punkte/€) 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.

Die App wird bei jedem Aufruf frisch vom Server geladen — es werden keine Cookies gesetzt und nichts im Browser-Cache gespeichert (Auslieferung mit Cache-Control: no-store; bewusste Betreiber-Entscheidung für gemeinsam genutzte Rechner, seit 2026-06-09). Dafür ist eine Internetverbindung erforderlich; einen Offline-Modus gibt es nicht mehr. Einstellungen, importierte Kataloge und gelernte Regeln bleiben weiterhin lokal im Browser (localStorage/IndexedDB).

3. Analyse in 4 Schritten

1. Rahmen setzen (linke Spalte):

• Abrechnungsjahr wählen.
• Fachbereich wählen.
• Prüfziel wählen:
• AOP-/Hybrid-DRG-Prüfung — Standard für ambulante OPs.
• Kodieroptimierung — maximale, belegbare Kodierschärfe.
• Stationäre Begründung prüfen — Kontextfaktoren + Setting-/Vergütungsvergleich.
• MD- und Kürzungsrisiko prüfen — strengste Prüfung.

2. OP-Bericht einfügen in das große Textfeld. Deutscher Freitext genügt. Nennen Sie: Diagnose, Prozedur, Seite, Zugang/Technik, Befund, Komplikationen, Anästhesie, Entlassfähigkeit/Überwachung (siehe MUSTER-OP-Bericht.md).

3. „Analyse starten" klicken.

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

Schnell-Kodierung aus Stichwort (ohne OP-Bericht)

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

1. Ein Wort oder kurzer Satz genügt (z. B. „Leistenhernie rechts", „Hoden", „Appendektomie") → „Diagnose & Codes vorschlagen" (oder Enter). 2. Es erscheint eine anhakbare Auswahl-Liste mit bis zu 5 Diagnosen (ICD-10-GM) und 5 Eingriffen (OPS):

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

Hodentorsion N44.-) sind unangehakt und mit „ähnlicher Begriff – bestätigen" markiert.

• Abgeleitete Vorschläge (z. B. Diagnose → typischer Eingriff) 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 („Apendix", „Appendy" → Appendizitis). Mit geladenen Katalogen durchsucht die Schnellsuche zusätzlich den kompletten ICD-/OPS-Katalog volltextlich.

4. Die Auswertung verstehen

Die Auswertung hat sechs Tabs: Codes (alle Vorschläge, umschaltbar auf „nach Absicherung": sicher vs. Optimierung), Vergütung & Simulation (Erlös, Setting-Vergleich, OPS-Toggles, erlösrelevante Faktoren, DRG-Kennzahlen, QS), Prüfpunkte (Widersprüche + Lücken/To-dos + 11-Punkte-Dokumentationscheck, mit Zähler), Bericht (Empfehlung + idealer OP-Bericht), Audit-Trail (Entscheidungsspur) und Fazit (Kurzfazit, am Ende der Leiste).

• Leitkennzahlen oben: Revisionssicherheit (revisionssicher / mit Auflagen /

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

• Prüfpunkte – 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; Widersprüche und der 11-Punkte-Dokumentationscheck stehen im selben Tab.

• 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 / AOP-Katalog: Datei, Trefferzahl, Code-Liste, Beispiel,
• EBM Anhang 2: Subkodes, GOP, Hygienezuschlag,
• Vergütung (Schätzung): GOP-Kette → € (extrabudgetär hervorgehoben). Enthält

OP-GOP, Überwachung, Behandlung, Anästhesie, Förder- und Hygienezuschlag; erfasste Sachkosten werden fallbezogen extrabudgetär zugerechnet.

• Konfidenz-Logik: Ohne Textbeleg nie „hoch"; KI-Vorschläge nie „hoch".
• Spalte „fehlende Angaben": Jede Kode-Zeile listet die Angaben, die für einen

endständigen bzw. besser belegten Kode noch fehlen (z. B. Seite, Material, Technik). Bei Mittellinien-Eingriffen (z. B. Zirkumzision, Nabelhernie) wird keine Seitenangabe verlangt – dort gibt es anatomisch keine Seite.

• **Stamm-OPS (z. B. 5-791.):* Statt nur des Stammkodes zeigt die Zeile direkt die

endständigen Schlüsselnummern der Gruppe. Nennt der Bericht eine Körperregion (z. B. Klavikula, Humerus), werden die passenden Endstellen vorgefiltert und hervorgehoben; eine im Text erkannte Technik (z. B. Platte, Schraube, Marknagel) verfeinert den Stammkode automatisch zur passenden Endstelle.

• Klick auf OPS-Titel: zeigt die anderen Schlüsselnummern der OPS-Gruppe (Endstellen).
• Klick auf Diagnose-Titel: zeigt mögliche Prozeduren/DRGs (Textähnlichkeit).
• Tab „Vergütung & Simulation" – erlösrelevante Faktoren: Abhängig von der Hauptdiagnose

des Berichts bietet der Tab anklickbare Faktoren in drei Gruppen: Befund/Schweregrad der Hauptdiagnose (z. B. Einklemmung, beidseitiger Eingriff, Rezidiv), Nebendiagnosen mit CC/MCC-Potenzial (Diabetes, Herz-/Niereninsuffizienz, COPD, Adipositas, Gerinnungsstörung) und Kontextfaktoren (Anlage 2) (z. B. Antikoagulanzien-Dauertherapie). Beim Anklicken wird die Wirkung sofort im Szenario gezeigt: möglicher DRG-Split derselben Familie (z. B. G24D → G24B bei schweren CC oder beidseitigem Eingriff), Wegfall der ambulanten Durchführung bei Notfall- konstellationen, Aufhebung der Hybrid-Pflicht durch Kontextfaktoren – jeweils mit dem nötigen Doku-Hinweis (DKR D003). Tags zeigen, ob ein Faktor bereits im Bericht erwähnt oder als ICD vorgeschlagen ist. Schätzung, kein zertifizierter Grouper.

• Bei Prüfziel Stationäre Begründung: Setting-Vergleich ambulant / Hybrid-DRG /

aG-DRG.

• Ausgabe per Kopieren / Drucken / Export (MD, JSON, FHIR) übernehmen.
• Auf dem Smartphone ist die Ansicht einspaltig: Nach der Analyse springt die

Seite automatisch zur Auswertung; die Abschnitte (Fazit, Codes, …) sind als wischbare Chips dargestellt.

5. Kataloge laden & pflegen

• Automatisch: Sind Server-Kataloge vorhanden, lädt die App sie beim Start selbst.
• Manuell: Katalogverwaltung → 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: AOP-Katalog Anlage 1, AOP-Kontextfaktoren Anlage 2, Frakturzuschläge Anlage 3, OPS, ICD-10-GM, EBM Anhang 2, Hybrid-DRG.

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 regelbasiert (ohne KI) erkennbar.

• Regeln gelten lokal sofort. Ist ein Server konfiguriert, wird die Regel

zusätzlich als Vorschlag zur Freigabe übermittelt (Toast: „… als Vorschlag zur Freigabe an den Server übermittelt"). In den geteilten Regelbestand gelangt sie erst, nachdem die Betreiberin/der Betreiber sie in der internen Ansicht angenommen hat (Moderation; abgelehnte Vorschläge werden nicht erneut eingereiht). 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. Implantat,

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

• Anästhesie: Die Anästhesie-GOP (z. B. 31822) ist im AOP-Komplex hinterlegt und

wird in der geschätzten Vergütung mitgerechnet (extrabudgetär). Sie wird in der Praxis i. d. R. vom Anästhesisten abgerechnet – der Wert dient der Gesamtschau.

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

/suggest-codes; akzeptiert werden nur relative, gleiche-Origin-, localhost- oder HTTPS-Adressen). 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.

• Versand-Vorschau: Vor jedem KI-Aufruf zeigt ein Dialog den exakten

anonymisierten Text (Ersetzungen hervorgehoben). Erst der Klick auf „Geprüft – senden" löst den Versand aus; Abbrechen liefert das regelbasierte Ergebnis ohne KI. Ein Häkchen „für diese Sitzung nicht mehr fragen" unterdrückt die Vorschau bis zum nächsten Laden der Seite. 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.

Feedback zur App

Unter den Einstellungen gibt es das Feld „Feedback zur App": Freitext eintippen und absenden – die Rückmeldung geht an die Betreiberin/den Betreiber und fließt in die Weiterentwicklung ein (CAPA-Prozess). Keine Patientendaten in das Feedback schreiben; vor einer etwaigen KI-Auswertung wird der Text serverseitig zusätzlich anonymisiert.

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 – AOP-Coding-Assistent

Dokumentationsbasierte OP-Berichtsprüfung · § 115b SGB V · Hybrid-DRG · EBM (Stand 2026)

Druckfertige Fassung: docs/Handout_AOP-Coding-Assistent.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 Bericht, inkl. Therapie→Diagnose (z. B. Emmert-Plastik → L60.0).
• EBM-Abrechnungskette je OPS: OP-GOP (31.2), Überwachungs-/Behandlungskomplex,

Anästhesie, Förderzuschlag, exakter Hygienezuschlag (31.2.19).

• Vergütungsschätzung (Punkte × regionaler Punktwert), extrabudgetär vs. budgetiert,

mit RLV-Fallwert-Kontext.

• AOP-Prüfung (§ 115b) und Hybrid-DRG-Pflicht (Positivlisten-Abgleich).
• Setting-Vergleich ambulant / Hybrid-DRG / 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 („Hoden") → bis zu 5 passende

Diagnosen + 5 Eingriffe zum Anhaken (inkl. Katalog-Volltextsuche und Tippfehler-/Kurzform-Toleranz: „Appendy", „Apendix").

• Beide Richtungen: Diagnose ↔ Eingriff 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 und Prüfziel wählen. 2. OP-Bericht einfügen. 3. „Analyse starten“. 4. Leitkennzahlen lesen, Lücken schließen, Kodes/Bericht übernehmen.

Datenbasis (offiziell, 2026)

BfArM (ICD-10-GM, OPS) · GKV-SV (AOP-Katalog Anlage 1–3) · KBV (EBM, Anhang 2 OPS→GOP, Hygienezuschläge BA 716) · InEK/BewA (Hybrid-DRG + Vergütung, aG-DRG, Zusatzentgelte, Pflegeerlös). Auto-Import in den Browser, monatlicher Aktualitäts-Scan.

Beispiel: Leistenhernie (TAPP)

• Status: mit Auflagen revisionssicher
• Kette: OP-GOP 31163 + Überwachung 31505 + Behandlung 31609 + Förder 31455 + Hygiene 31068
• ≈ 565,80 € (davon extrabudgetär ≈ 419,29 €) · Hybrid-DRG: PFLICHTIG (Positivliste)

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

Muster-OP-Bericht (Vorlage für den AOP-Coding-Assistenten)

Diese Vorlage zeigt, wie ein OP-Bericht strukturiert sein sollte, damit der AOP-Coding-Assistent alle abrechnungsrelevanten Angaben sicher erkennt (ICD, OPS, AOP-Relevanz nach §115b SGB V, Hybrid-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 (ambulant, AOP-relevant)

OP-BERICHT

Einrichtung:        Muster-Klinik / Praxis für Orthopädie
Operateur:          Dr. med. [Operateur]
Assistenz:          [Assistenz]
Anästhesie:         Dr. med. [Anästhesist]
OP-Datum:           [TT.MM.JJJJ]
Patient:            [anonymisiert – für Analyse nicht erforderlich]

Diagnose (präoperativ):
  Symptomatischer Innenmeniskusriss am rechten Kniegelenk (degenerativer
  Längsriss der Pars intermedia), konservativ über 8 Wochen therapierefraktär.

Indikation:
  Persistierende belastungsabhängige Schmerzen medial, Streckhemmung,
  positiver Steinmann I. MRT-gesichert Innenmeniskusläsion rechts.

Aufklärung:
  Patient ist über Eingriff, Alternativen und Risiken aufgeklärt; schriftliche
  Einwilligung liegt vor. ASA II, nüchtern.

Anästhesie:
  Larynxmaske / Allgemeinanästhesie, komplikationslos.

Operatives Vorgehen:
  Arthroskopische Operation am rechten Kniegelenk. Anlage von anteromedialem
  und anterolateralem Standardportal. Diagnostischer Rundgang: Knorpel
  Grad I-II medial, vorderes Kreuzband intakt. Innenmeniskus mit
  degenerativem Längsriss der Pars intermedia.
  Durchgeführt: arthroskopische Teilmeniskektomie (Resektion) medial,
  Glättung der Rissränder. Kein Befund an Außenmeniskus oder Knorpel, der
  eine zusätzliche Maßnahme erfordert (keine Knorpelmaßnahme).
  Abschließende Spülung, Verschluss der Portale, steriler Verband.

Komplikationen:
  Keine. Blutsperre xx min, regelrechte Blutstillung.

Postoperativer Verlauf / Entlassfähigkeit:
  Patient nach 2-stündiger Überwachung im Aufwachraum kreislaufstabil,
  schmerzarm, mobilisiert an Unterarmgehstützen, Miktion spontan.
  Postoperativ ambulant entlassfähig; Entlassung am OP-Tag.

Procedere:
  Teilbelastung 1 Woche, Lymphdrainage/Physiotherapie, Wiedervorstellung
  zur Wundkontrolle in 2 Tagen, Fadenzug nicht erforderlich.

Voraussichtliche Kodierung (vom Operateur):
  Diagnose: Innenmeniskusriss rechts (ICD M23.- – Detailkode prüfen)
  Prozedur: 5-812.- arthroskopische OP an Meniskus/Gelenkknorpel,
            rechtes Knie, Innenmeniskus, Teilresektion (Endstelle prüfen)

B) Leere Vorlage (zum Kopieren)

OP-BERICHT

OP-Datum:           [TT.MM.JJJJ]

Diagnose (präoperativ):
  [Klartext-Diagnose inkl. Seite, z. B. „... rechts/links"]

Indikation:
  [Beschwerden, Befunde, Vortherapie]

Anästhesie:
  [z. B. Allgemeinanästhesie / Spinalanästhesie / Lokalanästhesie]

Operatives Vorgehen:
  [Zugang/Technik: arthroskopisch / offen]
  [Eingriff im Klartext + Seite + betroffene Struktur]
  [durchgeführte Maßnahmen: Resektion / Naht / Refixation / Knorpelmaßnahme ja-nein]

Komplikationen:
  [keine / konkret benennen]

Postoperativer Verlauf / Entlassfähigkeit:
  [Überwachungsdauer, Kreislauf, Mobilisation]
  [ambulant entlassfähig? Entlassung am OP-Tag? oder stationäre Aufnahme + Grund]

Begründung stationär (nur falls stationär):
  [Kontextfaktor nach AOP-Anlage 2: z. B. relevante Begleiterkrankung,
   Antikoagulation, soziale Faktoren, Alter < 1 Jahr]

Procedere:
  [Nachbehandlung, Wiedervorstellung]

Voraussichtliche Kodierung:
  Diagnose: [ICD]
  Prozedur: [OPS]

Tipps für hohe Trefferquote

• Seite immer ausschreiben („rechtes Knie") – nicht nur „re." abkürzen.
• Technik benennen (arthroskopisch/offen) → der Assistent kann den

endständigen OPS-Detailkode statt nur den Stammkode vorschlagen.

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

Assistent „AOP-Kandidat ohne dokumentierte Entlassfähigkeit".

• Komplikationen aktiv verneinen („keine") – sonst entsteht eine Lücke.
• Bei stationärer Durchführung immer den Kontextfaktor nennen (Anlage 2),

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 AOP-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.

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, /ideal-report, /drg-upgrade), geteilte Kodierregeln (/api/rules, werden beim App-Start automatisch synchronisiert – Server ist maßgeblich; lokal neu gelernte Regeln werden als moderierte Vorschläge hochgeschoben und erst nach Freigabe in der internen Ansicht geteilt) sowie zwei anonymisierte Protokolle (/api/analysis-log, /api/usage-log mit Auswertung token-geschützt über /api/admin/usage). 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 (icdCatalog, opsCatalog, aopCatalog, aopContextCatalog,

fractureSurchargeCatalog, ebmCatalog, ebmAnhang2Catalog, hybridCatalog, hybridVerguetungCatalog, agDrgCatalog, zusatzentgeltCatalog, pflegeErloesCatalog).

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 („Leistenhärnienversorgung") und als Stamm-Korrektur für verstümmelte Kurzformen („Appendy" → Appendizitis; saubere Präfixe wie „Appendix"/„Leisten" bleiben bewusst unangetastet, weil sie legitime Anatomie-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 – 11-Punkte-Dokucheck 2. createIcdSuggestions – ICD-10-GM-Vorschläge 3. createOpsSuggestions – OPS-Vorschläge (inkl. EBM-/Vergütungs-Anreicherung) 4. createDocumentationGaps – Dokumentationslücken (risiko-sortiert) 5. rateCoding – Kodierbarkeit 6. evaluateAop – AOP-Prüfung (§ 115b) 7. evaluateHybrid – Hybrid-DRG-Vorprüfung (Positivliste) 8. createDocumentationSuggestions, createOptimizedDraft, createQuestions, createFinalRecommendation 9. computeAuditReadiness + computeValueEstimate – die beiden Leitkennzahlen

3.1 Faktenextraktion (extractFacts)

FACT_DEFINITIONS definiert je Kategorie einen Finder (Regex-basiert über findEvidence/hasAny). Kategorien u. a.: Hauptdiagnose/Indikation, Prozedur, Seitenlokalisation, Zugang/Verfahren, Intraoperativer Befund, Komplikationen, Ambulante Entlassfähigkeit, Narkose/Lagerung, Material/Implantate/Drainagen, Erschwernisse/Aufwand, Postoperatives Vorgehen. 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 ergeben. Mapping PROCEDURE_TO_ICD verknüpft eindeutige OPS-Regeln mit der zugehörigen ICD-Regel (z. B. emmert-plasty → unguis-incarnatus = L60.0; Hernien, Appendektomie, Meniskus, Karpaltunnel, Varizen, Metallentfernung). 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, AOP-/Hybrid-Kandidat, Seitenrelevanz).
• Importierte Katalogtreffer (AOP-/OPS-Katalog) werden ergänzt.
• Diagnose → Therapie (appendDiagnosisDerivedOpsSuggestions): Wird im Text

KEINE Prozedur erkannt, aber eine Diagnose mit eindeutigem Standardeingriff (invertiertes PROCEDURE_TO_ICD, z. B. Unguis incarnatus → Emmert-Plastik 5-898), erscheint der Eingriff 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 – Treffer im AOP-Katalog (Anlage 1),
• enrichOpsSuggestionWithEbmAnhang2 – EBM Anhang 2 zu Kapitel 31: ordnet dem OPS

Kategorie, OP-GOP (31.2), Überwachungskomplex, Behandlungskomplex, Anästhesie-GOP, Förderzuschlag und – über HYGIENE_BY_OPGOP (aus BA 716, Abschnitt 31.2.19) – den exakten Hygienezuschlag (GOP + Punkte) zu. Katarakt (31350/31351) erhält keinen Hygienezuschlag.

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

3.4 Dokumentationslücken (createDocumentationGaps)

Erzeugt Lücken aus fehlenden Pflichtangaben (Diagnose, Prozedur, Seite – falls sideRelevant –, Zugang, Befund, Material, Komplikationen, Narkose). Danach:

• appendPediatricGaps – Alterslogik (siehe 6),
• appendFallwertContext – RLV-Fallwert der Fachgruppe (KVBB I/2026) als Hinweis,
• 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 AOP-Prüfung (evaluateAop)

Filtert OPS mit aopCandidate und gleicht sie gegen den geladenen AOP-Katalog ab (findAopCatalogMatches). Ergebnis ja/unklar plus Voraussetzungen/Risiken.

3.7 Hybrid-DRG-Vorprüfung (evaluateHybrid)

Positivlisten-Abgleich: dokumentierte/abgeleitete OPS werden gegen die geladene Hybrid-DRG-Positivliste (hybridCatalog, OPS 2026) geprüft. Treffer → „PFLICHTIG", mit dem Hinweis, dass ein Anlage-2-Kontextfaktor dennoch eine stationäre Durchführung begründen kann.

3.8 Schnell-Kodierung aus Stichwort (handleQuickSuggest)

Eigener Pfad NEBEN der Berichts-Analyse: Ein Stichwort („Hoden", „Leistenhernie rechts") 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 OP-Morpheme („-ektomie", „-entfernung", „-plastik" …, QUICK_GENERIC_SUFFIXES) zählen NICHT als Ähnlichkeit – sonst würde „Cholezystektomie" die Appendektomie vorschlagen. Inhaltstragende Endungen wie „-hernie" verbinden dagegen die Hernien-Familie. 3. Katalog-Volltextsuche (quickCatalogCandidates): durchsucht die geladenen ICD-/OPS-Kataloge komplett (z. B. „Hoden" → N44.- Hodentorsion, N50.0 Atrophie, 5-620 ff.). 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 (5-624.* ≙ 5-624.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.

3.9 Erlösrelevante Faktoren in der Simulation (SIM_FACTORS)

Der Tab „Vergütung & Simulation" zeigt neben den OPS-Toggles anklickbare Erlösfaktoren, abhängig von der Hauptdiagnose (simMainDiagnosis: ICD-Vorschlag mit Rolle „Hauptdiagnose", sonst erster realer Vorschlag; Zuordnung über die ICD-Familie, z. B. K40). Drei Gruppen:

1. dx – Befund/Schweregrad der Hauptdiagnose (nur passend zur ICD-Familie): z. B. Einklemmung (blocksAmbulant), beidseitiger Eingriff (bilateral), Rezidiv, Choledocholithiasis, Perforation/Peritonitis. 2. nd – Nebendiagnosen mit CC/MCC-Potenzial (diagnoseübergreifend): Diabetes, Herz-/Niereninsuffizienz, COPD, Adipositas, Gerinnungsstörung. ccl ist eine Heuristik (1 ≈ CC, 2 ≈ schwere CC, 3 ≈ MCC). 3. ctx – Kontextfaktoren (Anlage 2): z. B. Antikoagulanzien-Dauertherapie (Z92.1) – kann stationäre Durchführung begründen und die Hybrid-Pflicht aufheben.

Wirkung beim Anklicken (computeSimFactorImpact, live in renderSimScenarioBody):

• Stationär aG-DRG: simDrgUpgradeCandidates sucht im geladenen aG-DRG-Katalog

einen zum Faktor passenden Split derselben DRG-Familie (z. B. G24D → G24B bei „schwere CC"/„beidseitig") bzw. thematisch verwandte Einträge über den Wortstamm des Treffer-Ankers (findet z. B. G09Z „Beidseitige Eingriffe bei Leisten-…"). „ohne …"-Teilsätze werden entfernt, damit „ohne schwere CC" nicht als CC-Split zählt; außerhalb der DRG-Familie zählen nur faktor-spezifische Schlüssel (nicht die generischen CC-Schlüssel). KEIN Grouping – Textschätzung.

• Ambulant/EBM: Faktoren mit blocksAmbulant (Notfall/Komplikation) setzen die

ambulante Zelle auf „entfällt"; bilateral ergänzt den Hinweis, die EBM-Berechnung je Seite/Sitzung zu prüfen. Der EBM-€-Wert selbst ändert sich durch Nebendiagnosen nicht (EBM ist prozedurbasiert) – das sagt der Effekttext ausdrücklich.

• Hybrid-DRG: gewählte Kontextfaktoren ergänzen den Hinweis, dass die

Hybrid-Pflicht aufgehoben werden kann (Anlage 2 dokumentieren).

• Wirkungsblock: je Faktor Effekt + nötige Dokumentation (DKR D003), Tags

„im Bericht erwähnt" (Pattern-Treffer im Text) bzw. „als ICD vorgeschlagen".

Auswahl (simFactorsSelected) wird je Analyse zurückgesetzt.

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

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

• Positionen: OP-GOP (extrabudgetär), Überwachungskomplex (budgetiert?),

Behandlungskomplex (budgetiert?), Förderzuschlag (extrabudgetär), Hygienezuschlag (extrabudgetär, aus HYGIENE_BY_OPGOP).

• 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-Vorschlag („Geschätzte ambulante Vergütung …, davon extrabudgetär ≈ …; ohne Anästhesie/ Sachkosten; gegen Abrechnung prüfen").

Extrabudgetär vs. budgetiert: AOP-OP-GOP, Hygiene- und Förderzuschlag werden i. d. R. außerhalb der MGV/RLV voll vergütet; Überwachungs-/Behandlungskomplexe sind ggf. RLV-/HVM-budgetiert. Der RLV-Fallwert je Fachgruppe (FALLWERTE_RLV_KVBB) wird als regionaler Kontext eingeblendet.

5. Prüfziel-Logik (appendGoalSpecificGaps)

Das Prüfziel steuert die Auswertung spürbar:

• aop (AOP-/Hybrid-DRG-Prüfung): prüft u. a. die ambulante Entlassfähigkeit.
• kodierung (Kodieroptimierung): meldet nicht endständige (Stamm-)Kodes,

fehlende kodewirksame Detailangaben (Seite/Zugang/Material) und vollständige Nebendiagnosen.

• stationaer (Stationäre Begründung): gleicht die Fall-Kodes gegen **AOP Anlage 2

(Kontextfaktoren) ab (findContextFactorHits: K2 OPS stationär, K6 ICD nicht ambulant, Pflegegrad, Begleiterkrankungen u. a.) und ergänzt einen Setting- Vergütungsvergleich** (appendSettingComparison): ambulant/EBM-€ vs. Hybrid-DRG (pflichtig? + Vergütungs-Kandidat aus hybridVerguetungCatalog) 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. K40) löst keine spezifischen Listeneinträge (K40.10) 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). Regeln aus AOP Anlage 2 (untere Altersgrenze):

• < 1. Lebensjahr → stationäre Durchführung kann begründet sein.
• 1.–12. Lebensjahr + Pflegegrad 2–5 → stationär begründet (Pflegegrad-Erkennung).
• ≤ 16. Lebensjahr + angeborener Herzfehler (Q20–Q26) → stationär begründet.
• < 18 J. → Hinweis auf altersabhängige EBM-GOP-Varianten.
• Fehlt das Alter → niedriger Hinweis (altersabhängige Sonderlogik nicht prüfbar).

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 mit striktem JSON-Output und prüfziel- spezifischem Fokus.

9. Kataloge und Auto-Import

7 vom App-Kern genutzte + weitere Referenzkataloge (insgesamt 12 Typen): icd, ops, aop, aopContext, fractureSurcharge, ebm, ebmAnhang2, hybrid, hybridVerguetung, agDrg, zusatzentgelt, pflegeErloes.

• Format: App-Katalogpaket (kind: "aop-coding-assistant-catalog-package"), 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), build-aopcontext-json.mjs (Anlage 2, mehrere Blätter), build-fallpauschalen-extras.mjs (Zusatzentgelte + Pflegeerlös), build-ebm-anhang2.mjs` (OPS→GOP-Zuordnung).

10. Datenquellen (Stand 2026)

server/catalog-sources.json führt die offiziellen Quellen: BfArM (ICD-10-GM, OPS), GKV-Spitzenverband (AOP-Vertrag + Anlagen 1/2/3), Erweiterter Bewertungsausschuss/KBV/DKG (Hybrid-DRG + Vergütung), InEK/g-drg.de (aG-DRG, Zusatzentgelte, Pflegeerlös), KBV (EBM, Anhang 2 zu Kap. 31, BA 716 für 31.2.19), sowie die KVBB-EBM-Änderungsübersicht (changesPage) für unterjährige GOP-Änderungen.

Bedienung, Betrieb & Katalogpflege – AOP-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 und das Prüfziel wählen:

• AOP-/Hybrid-DRG-Prüfung – Standard für ambulante OPs.
• Kodieroptimierung – maximale, belegbare Kodierschärfe.
• Stationäre Begründung prüfen – Kontextfaktoren + Setting-/Vergütungsvergleich.
• MD- und Kürzungsrisiko prüfen – strengste Prüfung.

2. OP-Bericht einfügen in das große Textfeld (deutscher Freitext genügt; Diagnose, Prozedur, Seite, Zugang, Befund, Komplikationen, Narkose, 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 (GOP, Förder-/Hygienezuschlag, €).
• Bei Stationäre Begründung: Setting-Vergleich ambulant / Hybrid-DRG / aG-DRG.
• Auswertung über Kopieren/Drucken übernehmen.

Schnell-Kodierung aus Stichwort

Unter dem Prüfziel: ein Wort oder kurzer Satz („Leistenhernie rechts", „Hoden") → „Diagnose & Codes vorschlagen". Es erscheint eine anhakbare Liste mit bis zu 5 Diagnosen und 5 Eingriffen (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 („Apendix", „Appendy").

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. Vor jedem Versand zeigt eine Vorschau den anonymisierten Text; erst „Geprüft – senden" löst den Aufruf aus. Ergebnisse sind als „KI-Vorschläge (zu prüfen)" gekennzeichnet.

• Feedback zur App: Freitextfeld unter den Einstellungen; Rückmeldungen gehen

an den Betreiber (keine Patientendaten eintragen).

• Eigene Regeln: wirken lokal sofort; geteilt werden sie erst nach Freigabe

durch den Betreiber (Moderations-Warteschlange in der internen Ansicht).

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.

• Die App lädt bei jedem Aufruf frisch vom Server (keine Cookies, kein

Browser-Cache, no-store); eine Internetverbindung ist erforderlich.

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/aop.newkis.io; try_files $uri $uri/ /index.html;). Der optionale Node-Server (127.0.0.1:3037) liefert zusätzlich /suggest-codes.

Deploy auf dem Server

WEBROOT=/srv/www/aop.newkis.io
git -C /opt/AOP-Coding pull --ff-only origin main      # bzw. clone, s. u.
cp -f /opt/AOP-Coding/web/{index.html,app.js,styles.css,sw.js,colors_and_type.css,aop.css,aop-v2.css,medinnovo_logo.svg} "$WEBROOT/"
cp -f /opt/AOP-Coding/web/{regeln.html,regeln.js} "$WEBROOT/"
cp -rf /opt/AOP-Coding/web/help "$WEBROOT/"          # Hilfe-Website (Bedienung & DSGVO)
cp -f /opt/AOP-Coding/server/public/catalogs/*.json "$WEBROOT/catalogs/"
# (Seit 2026-06-09 ohne Browser-Caching ausgeliefert; der folgende sed greift nur noch ins Leere.)
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/AOP-Coding && gh repo clone medinnovo/AOP-Coding /opt/AOP-Coding

Empfohlen ist das Deploy-Skript (kopiert zusätzlich web/intern/ und stempelt ?v=-Cache-Buster auf den Commit-Hash; Browser-Caching ist ohnehin deaktiviert):

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

Bei Server-/nginx-Änderungen zusätzlich:

nginx -t && systemctl reload nginx        # wenn server/aop-newkis.conf geändert wurde
systemctl restart aop-coding.service      # wenn server/src/ geändert wurde

Prüfen nach dem Deploy

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

KI-Server (optional)

cd /opt/AOP-Coding/server
cp .env.example .env        # OPENAI_API_KEY (+ ggf. OPENAI_MODEL) eintragen
npm install
npm start                   # http://127.0.0.1:3037  (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/AOP-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
# AOP Anlage 2 (Kontextfaktoren, mehrere Blätter):
node src/build-aopcontext-json.mjs --in Anlage_2.xlsx --version 2026 --source GKV-SV --out public/catalogs/aopContext.json
# Zusatzentgelte + Pflegeerlös aus dem Fallpauschalen-Katalog:
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 bereits durchgeführte 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.

1. Grundprinzip

Drei Schichten, in dieser Reihenfolge der Verbindlichkeit:

1. Regelbasierte Analyse (immer, offline) — deterministische Regex-Regeln über den Freitext. 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, AOP, EBM, Hybrid-DRG …) in IndexedDB abgeglichen und angereichert (Klartext, Subkodes, OP-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)            → 11-Punkte-Faktenliste
├─ createIcdSuggestions(context)    → ICD-Vorschläge (+ Therapie→Diagnose)
├─ createOpsSuggestions(context)    → OPS-Vorschläge (+ Katalog-/EBM-/€-Anreicherung)
├─ createDocumentationGaps(...)     → priorisierte Lückenliste (Punch-Liste)
├─ rateCoding(...)                  → Kodierbarkeit (gut/eingeschränkt/schlecht)
├─ evaluateAop(...)                 → AOP-Relevanz (ja/unklar)
├─ evaluateHybrid(...)              → Hybrid-DRG-Pflicht (Positivlistenabgleich)
├─ createDocumentationSuggestions   → konkrete Nachdokumentations-Vorschläge
├─ createOptimizedDraft(...)        → strukturierter OP-Bericht-Entwurf
├─ 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.

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 11-Punkte-Checkliste, 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: "K40.-", label, patterns: [/leistenhernie/i, …],
  role: "Hauptdiagnose", missing: ["Einklemmung/Gangrän", …], 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 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). Beispiel: „Emmert-Plastik" ⇒ L60.0 (Unguis incarnatus), „Gastrostomie" ⇒ R63.3 (Ernährungsschwierigkeiten). 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: "5-530.*", label, patterns, missing, alternatives,
  aopCandidate: true, hybridCandidate: true, sideRelevant: true, impliedIcdId }

Jeder Regel-Treffer durchläuft eine Anreicherungs-Kaskade (drei verschachtelte Funktionen):

enrichOpsSuggestionWithOpsCatalog   → Klartext + Subkodes aus OPS-Katalog
  └─ enrichOpsSuggestionWithAopCatalog → AOP-Katalogtreffer (setzt aopCandidate)
       └─ enrichOpsSuggestionWithEbmAnhang2 → OP-GOP + Hygiene + €-Kette

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

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

OPS-Kodes werden tolerant gematcht: 5-530.* matcht 5-530.0, 5-530.31 etc. (Stamm-→Subkode), Punkte/Sterne werden normalisiert (normalizeOpsCode).

Endstellen-Auflösung von Stamm-OPS

Stammkodes (z. B. 5-791.*) zeigen die endständigen Schlüsselnummern der Gruppe direkt in der Trefferzeile (opsEndstellenIds, opsVariantsForCode):

• Körperregion-Vorfilter: Nennt der Bericht eine Region/einen Knochen, die in

der OPS-Endstelle kodiert ist (z. B. 5-791.02 = Klavikula), werden die passenden Endstellen vorgefiltert und hervorgehoben.

• Technik-Verfeinerung (refineOpsStemByTechnique, OPS_TECHNIQUE_HINTS): Eine

im Text affirmativ genannte Technik (Platte, Schraube, Marknagel, Draht …; Negationen und Anamnese-Sätze werden ignoriert — opsTechniqueIdsAffirmed, isHistoryOnlyMatch) verfeinert den Stammkode automatisch zur passenden endständigen Schlüsselnummer.

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 („Appendy" → Appendizitis); ist das Token sauberes Präfix IRGENDEINES Vokabular-Begriffs („Appendix", „Leisten"), bleibt es unangetastet.

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

Optionen je Gruppe = exakte Treffer + quickFuzzyCandidates (Regelwerk, generische OP-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. Quelle der Wahrheit sind die Notizen der EBM-Anhang-2-Einträge, aus denen per Regex die Abrechnungspositionen geparst werden:

HYGIENE_BY_OPGOP (1674) ist eine fest hinterlegte Tabelle OP-GOP → [Hygiene-GOP, Punkte] aus dem Beschluss BA-716. Katarakt (31350/31351) bekommt keinen Hygienezuschlag.

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 für einen OPS nur eine Position (z. B. nur den Hygienezuschlag = 258 P = 32,87 €), ist das ein Hinweis auf einen unvollständigen Anhang-2-Eintrag — kein vollständiger ambulanter OP-Fall. Vollständige Fälle liegen mit OP-GOP + Überwachung + Behandlung typisch bei 900+ Punkten.

Bewusste Grenzen: kein Grouper, ohne Anästhesie/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 Diagnose/Prozedur (Ablehnungsrisiko)
• mittel — fehlende Seite/Zugang/Befund/Material/Komplikation
• niedrig — Narkose/Lagerung
• 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).

Fehlende Angaben mit Kodewirkung (MISSING_EVIDENCE_RULES, splitMissing): Pro Kode-Vorschlag listet die Spalte „fehlende Angaben" die Details, die für einen endständigen/besser belegten Kode fehlen (Seite, Material, Technik …). Die Seitenangabe wird bei Mittellinien-Eingriffen unterdrückt (MIDLINE_SITE_PATTERN: Zirkumzision, Nabel-/Pilonidal-Eingriffe, Urethra usw. — anatomisch ohne Seite); reine Anamnese-Treffer zählen nicht als aktueller Befund (isHistoryOnlyMatch, hasAnyCurrent).

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 AOP-Kontextfaktoren-Katalog (Anlage 2) 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 K40 löst also nicht den spezifischen Eintrag K40.10 aus.

Setting-Vergütungsvergleich (appendSettingComparison, 2528)

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

• Ambulant/EBM — €-Kette aus Abschnitt 6
• Hybrid-DRG — Pflicht? (Positivlisten-Treffer) + Vergütungskandidat (Textähnlichkeit)
• Stationär aG-DRG — nur bei Kontextfaktor; Kandidat per Textähnlichkeit

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), 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.

Vor jedem Versand zeigt confirmAiSend eine Vorschau des anonymisierten Texts (Ersetzungen hervorgehoben); erst „Geprüft – senden" löst den Aufruf aus, Abbrechen fällt auf das regelbasierte Ergebnis zurück (Session-Skip via AI_PREVIEW_OK_KEY). Eigene Endpunkte aus dem Feld „KI-Endpunkt" werden durch sanitizeAiEndpoint validiert (nur relativ, same-origin, localhost oder HTTPS).

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, „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 (AOP, Hybrid, Kodierbarkeit) und baut Tab-Abschnitte: Fazit · Codes · Vergütung · Dokumentation · Bericht · To-dos. applyGoalFocus springt je Prüfziel auf den passenden Default-Tab. To-dos sind die offenen Lücken; Erledigtes wird in v2Done gemerkt.

13. Bekannte Grenzen (bewusst)

• Kein DRG-Grouper. Stationäre/Hybrid-Vergütung ist Textähnlichkeit + Positivliste, keine

Fallpauschalen-Berechnung.

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

Diagnose-Finder wurde getestet und verworfen (deutsche Komposita erzeugen Falschtreffer, z. B. „Ernährungsschwierigkeiten" → O92 statt R63.3). Neue Befunde kommen daher über neue kuratierte Regeln oder über die KI (zu bestätigen), nicht über automatische Volltextsuche.

• €-Schätzung. Ohne Anästhesie/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.

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. Hygiene allein) 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 (Appendy→Appendizitis), Anatomie-Schutz (Appendix)
• Schnell-Kodierung: Auswahl-Liste, Ähnlichkeits- + Katalog-Volltextsuche
• Anonymisiertes Nutzungs-Log (/api/usage-log, Auswertung token-geschützt)
• 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 — AOP-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 AOP-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 OP-Bericht 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 OP-Bericht 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 OP-Berichts → 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 Keine Cookies, kein Browser-Cache (seit 2026-06-09)

• Die App setzt keine Cookies und wird mit Cache-Control: no-store

ausgeliefert: weder HTML/JS/CSS noch API-Antworten verbleiben im HTTP-Cache des Browsers. Der frühere Service Worker (App-Shell-Cache/Offline-Modus) wurde entfernt; web/sw.js ist nur noch ein Kill-Switch, der Alt-Installationen deregistriert und vorhandene CacheStorage-Einträge löscht. Vorteil auf gemeinsam genutzten Rechnern: Nach dem Schließen des Tabs liegt nichts Abrufbares im Browser-Cache; jeder Aufruf lädt die aktuelle Version.

• Keine externen Font-CDNs (seit 2026-06-09): Der frühere Google-Fonts-

@import wurde entfernt; die App nutzt ausschließlich System-Schriften. Damit entfällt der Drittland-Request an Google-Server beim Seitenaufruf (vgl. LG München I, 3 O 17493/20). Die Content-Security-Policy erlaubt style-src/font-src nur noch 'self' und erzwingt das technisch.

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 /api/rules ist öffentlich (nur Befund→Kode-Muster); POST /api/rules/:kind erzeugt moderierte Vorschläge, die erst nach Freigabe in der internen Ansicht in den geteilten Bestand übernommen werden; PUT/DELETE erfordern das Admin-Token. Muster werden serverseitig validiert (Regex muss kompilieren, ReDoS-Heuristik).

• 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.
• **Die KI-Endpunkte (/suggest-codes, /ideal-report, /drg-upgrade) proxyen an

die OpenAI-API (OPENAI_API_KEY, Modell ausschließlich serverseitig per OPENAI_MODEL, Default gpt-5.4-mini — Clients können kein Modell wählen). Damit verlässt anonymisierter Text die EU Richtung OpenAI (USA)**. Das frühere generische POST /analyze (beliebiger Prompt/Modell) wurde entfernt.

• 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), Qualitäts-/Hybrid-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 token-geschützt GET /api/admin/usage): 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 (§§ 115b, 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,

/ideal-report, /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 dokumentiert (Management-Review 2026-001): KI-Funktion AN (Opt-in,

zweifache Anonymisierung, Versand-Vorschau).

• ☑ AVV/Transfer-Mechanismus dokumentiert (AVV-OPENAI);

Vertragsabschluss durch Produktverantwortung offen → CAPA-2026-002.

• ☑ CORS-Allowlist aktiv seit 2026-06-09 (CORS_ALLOWED_ORIGINS=https://aop.newkis.io).
• ☑ 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 festgelegt (AUFBEWAHRUNG) und per

prune-data.mjs + Cron-Vorlage (server/aop-coding.cron) durchgesetzt.

• ☐ 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 — AOP-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 AOP-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 „AOP-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 Kodierung und Abrechnung ambulanter Operationen (§ 115b SGB V, Hybrid-DRG nach § 115f SGB V). 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-,

AOP-, Hybrid-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 — AOP-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 AOP-Coding-Assistent unterstützt Ärztinnen, Ärzte und Kodierfachkräfte dabei, ambulante Operationen 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

OP-Bericht 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 — AOP-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 AOP-Coding-Assistent ist ein dokumentationsbasiertes Hilfsmittel zur Unterstützung der Kodierung und Abrechnung ambulanter Operationen (§ 115b SGB V, Hybrid-DRG nach § 115f SGB V) in Deutschland. Er

• prüft einen vom Anwender eingegebenen OP-Bericht regelbasiert auf Vollständigkeit und

Dokumentationslücken,

• schlägt ICD-10-GM-, OPS- und EBM-Kodes sowie Abrechnungsketten vor,
• schätzt Revisionssicherheit und Vergütung und
• formuliert Klär-/Optimierungshinweise.

Anwender (Intended Users): Ärztinnen/Ärzte, Kodierfachkräfte, Medizincontrolling. Einsatzumgebung: Verwaltungs-/Abrechnungskontext in Praxis, MVZ, Krankenhaus.

2. Ausdrückliche Nicht-Zweckbestimmung (Limitations)

Der AOP-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 AOP-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-, AOP-, Hybrid-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 — AOP-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 → geschlossen (2026-06-09): Allowlist über CORS_ALLOWED_ORIGINS produktiv aktiv

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 — AOP-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.

Records-Ablage: ausgeführte Nachweise liegen unter docs/records/ (z. B. AUDIT-2026-001, MGMT-REVIEW-2026-001).

Aufbewahrung & Löschkonzept — AOP-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 OP-Berichtstext 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/aop-coding && /usr/bin/node scripts/prune-data.mjs >> /var/log/aop-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) — AOP-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 — AOP-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 AOP-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) — AOP-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 AOP-Coding-Assistenten:

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

OP-Bericht 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: Statische Web-App hinter nginx; der optionale KI-Dienst ist

nicht betriebskritisch (Kernanalyse funktioniert ohne ihn). Browser-Caching ist bewusst deaktiviert (no-store) — die App benötigt bei jedem Aufruf das Netz.

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 gesetzt (2026-06-09): CORS_ALLOWED_ORIGINS=https://aop.newkis.io

in server/.env; Fremd-Origins erhalten keinen Access-Control-Allow-Origin-Header mehr.

• ☑ AVV + Transfer-Mechanismus dokumentiert (AVV-OPENAI, 2026-06-09);

Vertragsabschluss selbst offen → CAPA-2026-002 (Ziel 2026-06-30).

• ☑ Backup-Konzept festgelegt & umgesetzt (BACKUP, 2026-06-09): tägliche

Sicherung + Restore-Test bestanden; offen nur die Offsite-Kopie (BACKUP §5).

• ☐ 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)