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.
Stand: 17. September 2026.
1. Wozu dient die App?
Der AOP-Coding-Assistent bietet eine Schnell-Kodesuche in den geladenen Katalogen und prüft einen deutschsprachigen OP-Bericht dokumentationsbasiert 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 mögliche Prüfrisiken.
Nach der Analyse lassen sich ein OP-Bericht oder ein Entlassungsbrief als prüfpflichtiger Entwurf erstellen.
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 bereitgestellte App wird ohne dauerhaften Offline-App-Cache ausgeliefert; zum erneuten Laden muss der Server erreichbar sein. In einer bereits geladenen App bleiben Kodesuche, regelbasierte Analyse und lokale Dokumententwürfe ohne KI-Verbindung verfügbar. Einstellungen, importierte Kataloge, gelernte Regeln und Suchpräferenzen bleiben lokal in diesem Browser gespeichert.
Die Statuszeile zeigt den Katalog-Ladestand. Darunter steht die dauerhaft erreichbare Checkbox KI vollständig deaktivieren; ihre Wirkung ist in Abschnitt 7 beschrieben.
3. Suchen oder einen Bericht prüfen
Die erste Option Schnell-Kodesuche ist beim Start ausgewählt. Die zweite Option OP-Bericht prüfen öffnet die Berichtsanalyse.
Schnell-Kodesuche
- Unter Begriff oder Kode beispielsweise
Leistenhernie, Analatresie, L60.0, 5-530.31 oder 31241 eingeben. Nach einer kurzen Schreibpause startet die Suche; Suchen oder Enter startet sie sofort. - Die Kataloggruppen prüfen und bei Bedarf mit ICD, OPS, EBM, AOP oder DRG filtern. Jede Gruppe nennt ihre Trefferzahl. Alle Treffer sind durch Scrollen erreichbar; die Liste wird nicht auf eine feste Anzahl gekürzt. Mit der Tastatur helfen Pfeiltasten, Bild auf/ab, Pos1 und Ende.
- Kode, Originalbezeichnung, Quelle und Treffertyp lesen. ICD-/OPS-Einträge bei Bedarf selbst anhaken. Auswahl kopieren kopiert sie; Auswahl übernehmen & prüfen fügt sie als Mini-Bericht ein und startet die Analyse. Die Auswahl muss dem tatsächlichen Fall entsprechen.
Tippfehler und zusammengesetzte Begriffe werden berücksichtigt. Ausgewählte deutsche, englische und lateinische Suchbegriffe führen ebenfalls zu vorhandenen Katalogeinträgen, etwa Analatresie, imperforate anus, anus imperforatus oder appendectomy. Begriffszuordnung und verwandter Eingriff sind unterschiedliche Trefferhinweise: Eine Diagnosebezeichnung belegt keine durchgeführte Operation. Ein Oberbegriff wie anorektale Malformation kann mehrere Varianten umfassen. Angaben wie mit Fistel, without fistula oder sine fistula grenzen die Suche ein; fehlende Angaben werden nicht ergänzt. Der Wortschatz ist begrenzt, keine allgemeine medizinische Übersetzung. Begriffe, Quellen und Abgrenzungen: Suchbegriffe und Synonyme.
Mit ☆ Merken wird ein Treffer zum Favoriten; ★ Favorit entfernt die Markierung wieder. Erfolgreiches Kopieren oder Übernehmen zählt als Nutzung; das bloße Anzeigen oder Anhaken zählt nicht. Bei der nächsten Suche stehen passende Favoriten und häufiger verwendete Kodes innerhalb derselben Trefferqualität weiter vorn. Eindeutige Kode- und Bezeichnungstreffer behalten Vorrang. Gespeichert werden lokal Kodeidentität, Favorit, Nutzungshäufigkeit und letzter Nutzungszeitpunkt; kein Such- oder Berichtstext. Favoriten & Nutzung zurücksetzen löscht diese Präferenzen.
OP-Bericht prüfen
- Die zweite Option OP-Bericht prüfen wählen, den Katalogstand kontrollieren und das Prüfziel festlegen: AOP/Hybrid-DRG, Kodieroptimierung, stationäre Begründung oder MD-/Kürzungsrisiko.
- Den Bericht einfügen. Hilfreich sind Diagnose, Prozedur, Seite, Zugang/Technik, Befund, Komplikationen, Anästhesie und Entlassfähigkeit/Überwachung; siehe Muster-OP-Bericht.
- OP-Bericht analysieren anklicken.
- Die Auswertung lesen, Belege und offene Zuordnungen prüfen und dokumentierte Angaben bei Bedarf ergänzen. Danach erneut analysieren.
Die lokale Prüfung berücksichtigt auch Aussagen im Fließtext. Eine eigene Zeile Diagnose: oder Eingriff: ist dafür nicht erforderlich: Die App sucht nach ausdrücklich beschriebenen Erkrankungen und tatsächlich ausgeführten Maßnahmen, etwa einer Organentfernung, Abszessentlastung, Sehnennaht oder Stomaanlage. Die erkannte Angabe und ihre Textstelle erscheinen im Dokumentationscheck. Das funktioniert auch mit KI vollständig deaktivieren.
Unter Prüfpunkte die Übersicht Erkannte Diagnosen und Maßnahmen · Textbelege aufklappen: Sie zeigt die Originalaussage und ihre Einordnung als dokumentiert, geplant, Vorgeschichte, verneint oder unklar/Verdacht. Ausdrücklich genannte Nebendiagnosen werden dort separat gekennzeichnet.
Entscheidend ist der Zusammenhang: Die Gallenblase wurde entfernt beschreibt einen ausgeführten Eingriff; Die Entfernung der Gallenblase ist geplant tut dies nicht. Verneinte Angaben, Verdachtsdiagnosen, frühere Eingriffe und Nachsorgeanweisungen werden nicht als Beleg einer aktuell gesicherten Diagnose oder durchgeführten Prozedur übernommen. Ein routinemäßiger Hautverschluss allein beschreibt noch nicht den Haupteingriff.
Diese Erkennung arbeitet mit lokalen Sprach- und Fachregeln. Sie versteht nicht jede mögliche Formulierung. Den angezeigten Textbeleg deshalb mit dem Bericht abgleichen. Eine erkannte klinische Angabe ist noch keine bestätigte ICD-/OPS-Zuordnung: Fehlt eine passende Kodierregel, bleibt die Zuordnung offen; fehlende Einzelheiten werden nicht ergänzt.
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 + OP-Bericht oder Entlassungsbrief), 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".
- Dokumentation und Kodezuordnung unterscheiden: Eine im Bericht ausdrücklich
genannte Diagnose oder Prozedur kann dokumentiert sein, obwohl noch kein belastbarer ICD-/OPS-Kode zugeordnet wurde. Eine offene Kodezuordnung bedeutet nicht automatisch, dass die klinische Angabe fehlt. Vorhandene Nebendiagnosen bleiben erhalten; eine Ersatzdiagnose darf nicht aus dem typischen Eingriff erfunden werden.
- Komplikationshinweise prüfen:
Keine Verletzung ist eine verneinte
Verletzung und widerspricht für sich allein keinem komplikationslosen Verlauf. Ein echter Konflikthinweis nennt den nicht verneinten Auslöser und die betreffenden Textstellen, damit der Zusammenhang geprüft werden kann.
- 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) hilft, die Endstellen einzugrenzen. Die endgültige Auswahl bleibt anhand der Dokumentation und des Katalogs zu prüfen.
- 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.
OP-Bericht oder Entlassungsbrief erstellen
Nach der Analyse den Tab Bericht öffnen und unter Vorlage den OP-Bericht oder Entlassungsbrief wählen. Anschließend die Schaltfläche zum Erstellen anklicken. Mit vollständig deaktivierter KI entsteht ein lokaler, regelbasierter Entwurf. Bei einem KI-Aufruf gilt die Versandvorschau aus Abschnitt 7.
Der Entlassungsbrief gliedert dokumentierte Angaben in Behandlungszeitraum, Diagnosen, Behandlung, Befunde, Verlauf, Entlassungszustand, Entlassungsmedikation und Nachsorge. Für die lokale Übernahme helfen beschriftete Abschnitte wie Nebendiagnosen:, Verlauf:, Entlassungsmedikation: und Weiterbehandlung:. Namen, Dosierungen und Einnahmeschemata ausdrücklich dokumentierter Entlassungsmedikation bleiben erhalten. Intraoperative Medikamente werden nicht als Entlassungsmedikation übernommen.
Fehlende Angaben bleiben als (prüfen: …) markiert. Der Entwurf ergänzt keine Medikamente, Dosierungen, Kontrolltermine oder einen komplikationslosen Verlauf als vermeintliche Fakten. Nach fachlicher Prüfung mit Bericht kopieren übernehmen. Ein Wechsel der Vorlage leert den bisherigen Entwurf; danach neu erstellen.
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 vollständig deaktivieren: Die Checkbox unter der Statuszeile sperrt
alle KI-Aufrufe: Kode-Ergänzungen, DRG-Hinweise und beide Dokumentvorlagen. Die Einstellung bleibt in diesem Browser erhalten und gilt auch in anderen geöffneten App-Tabs. Offene Versandvorschauen und laufende Browseranfragen werden abgebrochen; bereits versandte Daten können nicht zurückgeholt werden. Suche und regelbasierte Analyse bleiben nutzbar; Dokumente und DRG-Checkliste lassen sich über die mit lokal bezeichneten Schaltflächen erstellen. Auch die KI-Auswertung in der geschützten internen Ansicht ist in diesem Browser gesperrt. Das Aufheben der Sperre sendet nichts automatisch und aktiviert die automatische Kode-Ergänzung nicht erneut.
- KI-Ergänzung für Kodelücken (optional, opt-in): Bei aufgehobener Gesamtsperre
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.
- Manuelle KI-Aktionen: Die Schaltflächen für DRG-Hinweise und Dokumente
können bei aufgehobener Gesamtsperre auch dann einen KI-Aufruf starten, wenn die automatische Kode-Ergänzung ausgeschaltet ist.
- Versand-Vorschau: Vor dem 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. Für diese Sitzung nicht erneut fragen unterdrückt die Vorschau in diesem Tab, bis die Sitzung endet oder KI vollständig deaktiviert wird. Ergebnisse sind „KI-Vorschläge (zu prüfen)". Datenschutzhinweise: SICHERHEIT-DSGVO.md.
8. Datenschutz im Alltag
- Die regelbasierte Analyse läuft lokal. Ein KI-Aufruf ist eine separate
Funktion; die Gesamtsperre verhindert diese Aufrufe.
- 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.
- Das Such-Nutzungsprotokoll enthält Suchtyp, Katalog, Ladestatus und
Trefferzahl, keine Suchtexte oder eingegebenen Kodes. Funktionsnutzung und strukturierte Analysemetadaten werden getrennt protokolliert; Details zu diesen Serverfunktionen: Datenschutz.
- 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
| Symptom | Ursache / Lösung |
|---|
| „Referenzkatalog nicht geprüft" | Katalog importieren oder „Kataloge aktualisieren". |
| Vorschläge fehlen / nur Stammkode | Katalogstand und Zuordnung prüfen. Nur tatsächlich fehlende Angaben zu Technik/Seite ergänzen; eine vorhandene klinische Angabe kann dennoch eine offene Kodezuordnung haben. |
| Nur ein Teil der Treffer sichtbar | Innerhalb der jeweiligen Katalogliste scrollen; Trefferzahl und Pos1/Ende helfen beim Navigieren. |
| Favoriten erscheinen nicht zuerst | Die fachliche Trefferqualität hat Vorrang. Nur passende Treffer derselben Qualitätsstufe werden persönlich sortiert. |
| Neue Version wird nicht geladen | Seite neu laden und Erreichbarkeit des bereitgestellten Servers prüfen. |
| App lädt nicht / weiße Seite | Netzwerk-/Serververbindung prüfen; ein vollständiger Offline-Neustart wird nicht bereitgestellt. |
| Dokument-Schaltfläche zeigt „lokal“ | KI ist vollständig deaktiviert; der regelbasierte Entwurf bleibt verfügbar. |
| Entlassungsbrief enthält „(prüfen: …)“ | Die Angabe fehlt oder wurde nicht sicher erkannt. Im Quelltext ausdrücklich beschriften, erneut analysieren und den neuen Entwurf prüfen. |
| „KI-Ergänzung blockiert" | Anonymisierung unsicher – Patientendaten manuell entfernen und erneut starten. |
| KI-Dialog erscheint vor jedem Versand | Gewollt (Versand-Vorschau). „Für diese Sitzung nicht mehr fragen" anhaken. |
| Geteilte Regel erscheint nicht bei Kollegen | Regel wartet auf Freigabe durch die Betreiberin/den Betreiber (Moderation). |
| „KI-Endpunkt nicht erreichbar" | Offline oder Endpunkt falsch – die regelbasierte Analyse bleibt gültig. |
| Vergütung = „—" | EBM Anhang 2 + Punkte laden bzw. Eingriff nicht ambulant abrechenbar. |
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
Schnell-Kodesuche und dokumentationsbasierte Berichtsprüfung · Stand: 17. September 2026
Die App unterstützt die Suche in ICD-10-GM, OPS, EBM, AOP und DRG sowie die Prüfung dokumentierter Angaben. Kodes, Abrechnungsvoraussetzungen und Dokumententwürfe bleiben fachlich zu prüfen; Vergütungswerte sind Schätzungen.
1. Schnell-Kodesuche – direkt nach dem Öffnen
- Unter Begriff oder Kode einen Suchbegriff oder Kode eingeben, etwa
Leistenhernie, Analatresie, L60.0 oder 5-530.31. Die Suche startet nach einer kurzen Schreibpause; Suchen oder Enter startet sie sofort. - Treffer nach Katalog filtern und in den Ergebnisgruppen scrollen. Alle Treffer bleiben erreichbar, ohne feste Obergrenze der Liste.
- Kode, Originalbezeichnung, Quelle und Treffertyp prüfen. Passende ICD-/OPS- Einträge selbst anhaken, dann Auswahl kopieren oder Auswahl übernehmen & prüfen wählen.
Ausgewählte deutsche, englische und lateinische Begriffe werden unterstützt, zum Beispiel imperforate anus, anus imperforatus und appendectomy. Begriffszuordnung und verwandter Eingriff sind verschieden: Eine Diagnose belegt keine durchgeführte Operation. Oberbegriffe können mehrere Varianten liefern; Angaben wie mit Fistel oder without fistula grenzen ein. Der Wortschatz ist bewusst begrenzt: Suchbegriffe und Quellen.
☆ Merken setzt einen Favoriten, ★ Favorit entfernt ihn. Erfolgreiches Kopieren oder Übernehmen zählt als Nutzung. Bei der nächsten passenden Suche stehen Favoriten und häufiger verwendete Kodes innerhalb derselben Trefferqualität weiter vorn; eindeutige Kode-/Bezeichnungstreffer haben Vorrang. Diese Präferenzen speichern nur Kodeidentität, Favorit, Nutzung und Zeitpunkt lokal in diesem Browser. Favoriten & Nutzung zurücksetzen löscht sie.
2. OP-Bericht prüfen
- Die zweite Option OP-Bericht prüfen wählen, Katalogstand kontrollieren und das Prüfziel festlegen.
- Bericht einfügen: Diagnose, Eingriff, Seite, Technik, Befund, Komplikationen und Überwachung möglichst ausdrücklich benennen.
- OP-Bericht analysieren anklicken.
- Kodevorschläge, Belege, Prüfpunkte und offene Zuordnungen lesen. Tatsächlich fehlende Angaben ergänzen und erneut analysieren.
Eine dokumentierte klinische Angabe kann vorhanden sein, obwohl ihre ICD-/OPS-Zuordnung offen bleibt. Vorhandene Nebendiagnosen bleiben erhalten; Ersatzdiagnosen dürfen nicht aus einem typischen Eingriff erfunden werden. Keine Verletzung allein ist kein Widerspruch zu einem komplikationslosen Verlauf. Ein echter Konflikthinweis nennt den nicht verneinten Auslöser und die betreffenden Textstellen zur Prüfung.
3. KI vollständig deaktivieren
Die Checkbox KI vollständig deaktivieren steht unter der Statuszeile. Sie bleibt nach dem Neuladen erhalten und sperrt Kode-Ergänzungen, DRG-Hinweise und Dokumenterstellung über KI. Offene Versandvorschauen und laufende Browseranfragen werden abgebrochen; bereits versandte Daten können nicht zurückgeholt werden.
Suche und regelbasierte Analyse bleiben verfügbar. Die Dokumentvorlagen und DRG-Checkliste funktionieren über die mit lokal bezeichneten Schaltflächen. Das Aufheben der Sperre sendet nichts automatisch. Bei freigegebener KI können manuelle Dokument-/DRG-Aktionen auch ohne automatische Kode-Ergänzung einen Aufruf starten; die Versandvorschau zeigt den anonymisierten Inhalt.
4. OP-Bericht oder Entlassungsbrief erstellen
Nach der Analyse: Bericht → Vorlage → Entlassungsbrief (oder OP-Bericht) wählen und erstellen. Bei vollständig deaktivierter KI entsteht ein lokaler Entwurf. Beschriftete Angaben wie Verlauf:, Entlassungsmedikation: und Weiterbehandlung: erleichtern die Übernahme aus dem Quelltext.
Fehlende Informationen bleiben als (prüfen: …) markiert. Medikamente, Dosierungen, Nachsorge und ein komplikationsloser Verlauf werden nicht als Fakten erfunden. Ausdrücklich dokumentierte Entlassungsmedikation bleibt mit Namen und Dosierungen erhalten; intraoperative Medikamente werden nicht zur Entlassungsmedikation. Entwurf prüfen und Bericht kopieren wählen. Ein Vorlagenwechsel leert den Entwurf; danach neu erstellen.
Weitere Hilfe
Ausführliche Bedienungsanweisung · Muster-OP-Bericht · Datenschutz
Der eingegebene Bericht wird nicht dauerhaft im Browser gespeichert; Neuladen leert ihn. Suchpräferenzen enthalten keinen Such- oder Berichtstext. Für Übungen ausschließlich synthetische Falldaten verwenden.
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
| Angabe | Warum sie zählt | Beispiel-Formulierung |
|---|
| Diagnose (Klartext) | ICD-Ableitung, Hauptdiagnose | „Innenmeniskusriss rechts" |
| Prozedur (Klartext) | OPS-Ableitung | „arthroskopische Teilmeniskektomie" |
| Seite | Seitenangabe ist GOP-/OPS-Pflicht | „rechtes Kniegelenk" |
| Zugang / Technik | endständiger OPS-Detailkode | „arthroskopisch", „offen" |
| Befund | Beleg für Diagnose & Schweregrad | „degenerativer Längsriss Pars intermedia" |
| Komplikationen | Widerspruchs-/Schweregradprüfung | „keine" oder konkret benennen |
| Anästhesie | Abrechnungskette, Setting | „Larynxmaske, ITN, Spinalanästhesie" |
| Entlassfähigkeit / Überwachung | AOP-Kernkriterium §115b | „postoperativ ambulant entlassfähig nach 2 h Überwachung" |
| Begründung stationär (falls zutreffend) | Kontextfaktoren Anlage 2 | „stationär wegen Antikoagulation/Begleiterkrankung" |
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 „OP-Bericht analysieren" (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): Wörter aus den geladenen Katalogen bleiben unverändert. So wird etwa „Arthrolyse“ nicht in „Arthrodese“ oder „Stents“ in „Stenosans“ verändert. Unbekannte Wörter werden gegen das Vokabular der Regel-Muster geprüft und bei geringer Editierdistanz korrigiert, auch in Komposita („Leistenhärnienversorgung“). Mehrdeutige Kurzformen belegen dabei keine Diagnose; etwa darf eine Appendektomie allein keine akute Appendizitis erzeugen. 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. Eine unscharfe Vervollständigung kurzer Wörter zu längeren Diagnosen oder Eingriffen findet nicht statt. Medizinisch bedeutungstragende Endungen bleiben geschützt; RegEx-Zeichenklassen werden nicht als abgeschnittene Wortstämme verwendet. Diese Schutzmechanismen gelten auch vor dem Laden der Kataloge.
3. Analyse-Pipeline (analyzeReport)
Die Funktion ruft – in dieser Reihenfolge – auf:
extractFacts – 11-Punkte-DokucheckcreateIcdSuggestions – ICD-10-GM-VorschlägecreateOpsSuggestions – OPS-Vorschläge (inkl. EBM-/Vergütungs-Anreicherung)createDocumentationGaps – Dokumentationslücken (risiko-sortiert)rateCoding – KodierbarkeitevaluateAop – AOP-Prüfung (§ 115b)evaluateHybrid – Hybrid-DRG-Vorprüfung (Positivliste)createDocumentationSuggestions, createOptimizedDraft, createQuestions, createFinalRecommendationcomputeAuditReadiness + computeValueEstimate – die beiden Leitkennzahlen
FACT_DEFINITIONS definiert je Kategorie einen regelbasierten Finder. Diagnose und Prozedur nutzen die klinischen Belege aus getClinicalEvidence; weitere Kategorien verwenden unter anderem 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).
Diagnose- und Prozedur-Finder prüfen zusätzlich bejahte Aussagen im Fließtext. Beschriftete Abschnitte sind hilfreich, aber nicht zwingend. Die lokale Erkennung verbindet Erkrankungsbegriffe beziehungsweise konkrete Maßnahmen mit dem Satzkontext; sie kann beispielsweise eine ausgeführte Organentfernung, Abszessentlastung, Sehnennaht oder Stomaanlage auch ohne Eingriffs-Kopfzeile als dokumentierte Prozedur erfassen. Die Fundstelle bleibt eine Textstelle des eingefügten Berichts.
Aktuelle, positive Aussagen werden getrennt von Negation, Verdacht, Planung, Vorgeschichte und Nachsorge bewertet. Eine geplante Entfernung, ein früherer Eingriff oder routinemäßiger Hautverschluss belegen keine aktuell ausgeführte Hauptprozedur. Aus einer Prozedur wird durch diese Faktenextraktion keine Diagnose erfunden. Ebenso beweist die Nennung einer Erkrankung keine Operation. Die Prüfung arbeitet vollständig lokal und benötigt keine KI-Verbindung.
report.clinicalEvidence enthält getrennte Listen diagnoses und procedures. Jeder Beleg behält Originaltext, Textposition und Abschnitt sowie einen Status (documented, planned, historical, negated, uncertain). Diagnosen tragen zusätzlich die Rolle main, secondary oder unspecified. Eine ausdrücklich dokumentierte Nebendiagnose bleibt erhalten und füllt keine fehlende Hauptdiagnose aus. Die Kodevorschläge werden mit diesen Belegen abgeglichen.
Faktenerkennung und Kodezuordnung sind getrennte Schritte. Ein positiver Textbeleg kann present: true ergeben, ohne dass eine ICD-/OPS-Regel greift. Der Vorschlag bleibt dann mappingStatus: "unmapped" (Zuordnung offen), statt die dokumentierte Tatsache als fehlend zu melden. Die Regeln decken häufige Formulierungen ab, bieten aber kein allgemeines semantisches Verständnis beliebiger Arztbriefe. Spezifische Kodes, Seiten, Zugänge und Schweregrade benötigen weiterhin einen eigenen Beleg.
3.2 ICD-Vorschläge (createIcdSuggestions)
- Direkt:
ICD_RULES (Regex-Muster → ICD-Stamm/Endkode, Rolle, fehlende Angaben,
Alternativen). clinicalRuleEvidence verlangt einen aktuellen, bejahten Textbeleg der passenden Regel; eine ausdrücklich angegebene Nebendiagnose behält ihre Rolle.
- 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").
Dokumentierte Diagnosen und Prozeduren ohne automatische Kodezuordnung werden gesondert als Kodierung offen behandelt. Ein unbekannter Begriff ist keine fehlende Dokumentation. Beim Malone-Zugang wird eine OPS-Familie nur mit belegter Neuanlage, gastrointestinalem Kontext, dokumentiertem Kontinenzmechanismus und vorhandener Katalogreferenz vorgeschlagen. Die Neuanlage kann auch durch die ausgeführte Appendix-Haut-Anastomose im Operationsverlauf belegt sein; eine separate Eingriffs-Kopfzeile ist dafür nicht erforderlich. Planung, ein bestehender Zugang oder ein bloßer Katheterwechsel belegen keine Neuanlage. Zugang und Endstelle werden nicht aus „laparoskopisch assistiert“ angenommen. Die zugrunde liegende ICD-Diagnose wird nicht aus dem Eingriff hergeleitet.
Ein Komplikationswiderspruch benötigt eine aktuelle, bejahte Komplikationsangabe und eine Aussage zur Komplikationsfreiheit. Verneinte, historische oder geplante Angaben reichen dafür nicht. Die Auswertung nennt den auslösenden Begriff und die Textstellen; das Analyseprotokoll erhält weiterhin nur die Widerspruchszahl.
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 Begriff oder Kode (handleQuickSuggest, searchCatalogs)
catalogSearchQuery erkennt und normalisiert Kodes vor der Textsuche (Groß-/ Kleinschreibung, Leerzeichen, alternative Bindestriche, ICD ohne Punkt). Literal-Kodes werden ausschließlich gegen entry.code abgeglichen. Freitext wird gegen entry.description aller geladenen Kataloge gesucht; Schreibkorrekturen, Synonyme und begrenzte Editierdistanz unterstützen die Begriffssuche.
Ein gesondertes Suchwörterbuch ergänzt gebräuchliche deutsche, englische und lateinische Mehrwortbegriffe. Es verknüpft erkannte Begriffe mit überprüften Kodebereichen, beschränkt auf die passende Kodeart und tatsächlich geladene Katalogzeilen. Weitere Suchwörter und Beziehungen wie mit/ohne werden weiterhin per UND geprüft; auch with/without und cum/sine werden dafür berücksichtigt. Ein Oberbegriff darf mehrere Varianten zur Navigation öffnen, ohne eine davon als klinisch gegeben anzunehmen. Diagnosebegriffe und dazu passende Eingriffe werden unterschiedlich gekennzeichnet. Diese Erweiterung betrifft ausschließlich die Katalogsuche; sie erweitert weder die Diagnose-/OPS-Regeln noch die Textkorrektur oder Abrechnungslogik der Berichtsanalyse. Quellen und Zuordnungsgrenzen stehen in Suchbegriffe und Synonyme.
Exakte Kodes, Kodepräfixe und exakte Bezeichnungen behalten Vorrang vor ähnlichen Bezeichnungen, Begriffszuordnungen und markierten Teiltreffern. Endstellen bleiben einzeln auffindbar. Jede Gruppe ist vollständig scrollbar; die Darstellung hält nur die sichtbaren Karten mit einem kleinen Vorlauf im DOM. Gemessene Kartenhöhen und ein vollständiger Scrollbereich erlauben auch sehr große Treffermengen ohne Ergebnisobergrenze. Auswahl und Tastaturfokus bleiben beim Scrollen erhalten. Gruppen und Filter berücksichtigen auch die OPS→GOP-Zuordnungen, AOP-Anlagen 2/3, Hybrid-Vergütung und den Pflegeerlöskatalog. Version und Herkunft bleiben sichtbar.
Die persönliche Sortierung greift ausschließlich innerhalb derselben Trefferart: Favorit → Nutzungshäufigkeit → letzte Nutzung → ursprüngliche Relevanz. Als Nutzung zählen erfolgreiches Kopieren und ausdrückliches Übernehmen; reines Suchen oder Anhaken zählt nicht. Favoriten erzeugen keine zusätzlichen Treffer und ändern keine Kodierregeln. aopQuickPreferences.v1 speichert lokal nur Kodeart/Kode, Favoritenstatus, Zähler und letzten Nutzungszeitpunkt. Such- und Berichtstexte werden nicht übernommen; die Daten werden nicht synchronisiert oder übertragen.
Die Suche verwendet einen invertierten Wortindex, Teilwort-/Stammindex, einen direkten Bezeichnungsindex und sortierten Kodeindex pro Kataloggeneration. OPS-Querverweise greifen ebenfalls auf den Kodeindex zu und werden begrenzt zwischengespeichert. Katalogwechsel oder Versionsänderungen erneuern den Index; ein überholter asynchroner Aufbau darf keinen neueren Index überschreiben. Die Indizes werden während des Katalogladens in kleinen Teilstücken vorbereitet, mit Freigabe des UI-Threads dazwischen. Erst danach wird der jeweilige Katalog für die Suche bereitgestellt; das gilt auch für lokal gespeicherte Kataloge und manuelle Importe. Die erste Suche muss daher nicht alle Indizes auf einmal aufbauen. Vollständige Katalogbezeichnungen bleiben auch mit enthaltenen Kodeverweisen auffindbar. Exakte Bezeichnungen verdrängen keine passenderen Kode-Treffer und verbergen keine spezifischeren OPS-Untergruppen. Mehrere Begriffe werden per UND verknüpft, alternative Schreibweisen und Synonyme nur innerhalb desselben Begriffs per ODER. Medizinische Mehrwort-Synonyme behalten ihre Bedingungen, etwa Hernia inguinalis statt eines beliebigen inguinalen Eingriffs. Deutsche Komposita und numerische Typangaben werden berücksichtigt. Rein diagnostische Teiltreffer bei fehlenden Zusatzangaben sind gesondert markiert; die OPS-Suche lockert ihre Bedingungen nicht stillschweigend. Die Suche verwendet eine eigene Liste grammatischer Füllwörter, nicht die Filterliste der Vergütungsschätzung. Klinische Einschränkungen wie akut/chronisch, laparoskopisch, beidseitig und mit/ohne bleiben erhalten. Mit/ohne-Beziehungen werden innerhalb der Bezeichnung geprüft; Typ, Stadium, Grad und Klasse bleiben mit ihrem Zahlenwert verbunden. Teilwörter müssen zu einem belegten Wortbestandteil passen: „Lungen“ ist kein Treffer in „misslungene“, und „Zystitis“ ist nicht gleichbedeutend mit „Cholezystitis“.
Nach 250 ms Schreibpause startet eine neue Suche; Enter und Button starten sofort. Die Schnell-Kodesuche führt keine vollständige Berichtsanalyse aus und hängt keine freien Regelvorschläge an. So können unpassende Regelableitungen die Katalogtreffer nicht überlagern. Originalberichte bleiben bei Schreibkorrekturen unverändert. Eine allgemeine Arthroskopie belegt weder eine Meniskusoperation noch eine Knie-Diagnose; ohne konkrete Maßnahme fragt die Berichtsprüfung nach Gelenk, Seite und diagnostischem oder therapeutischem Vorgehen. opsSearchReferences unterscheidet exakte OPS-Mitgliedschaft, reine Kodefamilien und fehlende Kataloge. Die EBM-Kette stammt aus dem passenden Zuordnungseintrag; bei einer Familie wird keine beliebige Endstelle als verbindliche Kette angezeigt.
Ladevorgänge aktualisieren die letzte noch geöffnete Suche automatisch. Auch ein fehlgeschlagener oder offline beendeter Ladevorgang beendet den Ladestatus. ICD-/OPS-Auswahlen werden ausdrücklich bestätigt und als Mini-Bericht an vorhandenen Berichtstext angehängt; anschließend startet handleAnalyze im Berichtsmodus.
Suchtelemetrie enthält nur queryType, catalogType, readiness und hitCount neben den Ereignis-Metadaten. Client und Server übertragen/speichern keine Suchtexte oder Kodes als Suchereignisse. Treffer und Fehlschläge werden nach Katalog und Ladestatus aggregiert; alte Suchereignisse ohne gültige Metadaten werden verworfen.
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:
- dx – Befund/Schweregrad der Hauptdiagnose (nur passend zur ICD-Familie): z. B. Einklemmung (
blocksAmbulant), beidseitiger Eingriff (bilateral), Rezidiv, Choledocholithiasis, Perforation/Peritonitis. - 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). - 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.
Kuratierte Suchbegriffe und Sprachvarianten
Stand: 17. September 2026.
Die Katalogsuche berücksichtigt ausgewählte deutsche, englische und lateinische Bezeichnungen. Die Auswahl ist eine begrenzte, im Anwendungscode gepflegte Suchhilfe. Sie ist kein allgemeines Übersetzungswörterbuch und keine automatische Zuordnung von Diagnosen oder durchgeführten Eingriffen.
Die Suchbegriffe werden gegen tatsächlich geladene Einträge aufgelöst. Die Diagnoseschlüssel stammen aus dem veröffentlichten ICD-Katalog, Eingriffe aus dem veröffentlichten OPS-Katalog. Weitere Kataloge dürfen ihre eigenen vorhandenen Referenzen auf dieselbe Kodeart zeigen. Ein verwandter OPS-Treffer ist kein Nachweis eines durchgeführten Eingriffs und keine automatische Abrechnungszuordnung. Die amtlichen Katalogbezeichnungen bleiben unverändert sichtbar.
Fachliche Grenzen
- Eine passende Sprachvariante erweitert den Zugang zum gleichen Begriff.
Ein Oberbegriff kann mehrere unterschiedliche Fehlbildungen oder Varianten umfassen. Diese Treffer sind Auswahlmöglichkeiten und kein Beleg für einen bestimmten endständigen Kode.
- Verwandte Operationen sind gesonderte Suchhinweise. Beispielsweise belegt
eine Suche nach einer Fehlbildung nicht, dass eine Rekonstruktion durchgeführt wurde oder welches Verfahren angewandt wurde.
- Zusätze wie
mit Fistel, ohne Fistel, with fistula, without fistula,
cum fistula und sine fistula müssen ihre Bedeutung behalten. Ein Alias darf die noch nicht verbrauchten Suchangaben nicht auslassen.
- Kurze mehrdeutige Wörter werden nicht global umgedeutet:
ARM bleibt ohne
zusätzlichen Kontext mehrdeutig. Auch atresia, hernia, fistula, cuff und ring allein begründen keine bestimmte Lokalisation oder Diagnose.
- Treffermengen werden aus den vorhandenen Katalogzeilen gebildet. Favoriten
oder häufige Nutzung dürfen weder fehlende Treffer erzeugen noch fachlich schwächere Treffer vor eindeutige Kode- oder Bezeichnungstreffer setzen.
Unterstützte Begriffsgruppen
Die Tabelle nennt Suchbeispiele und den zugehörigen ICD-Suchbereich. Bereiche mit mehreren Kodes werden erst durch zusätzliche Angaben enger. Die deutschen Zielbegriffe erläutern die Bedeutung; angezeigt wird jeweils die Originalzeile des geladenen Katalogs.
| Suchbeispiele | Deutscher Zielbegriff | ICD-Suchbereich | Fachliche Quelle |
|---|
| Analatresie; anal atresia; imperforate anus; anus imperforatus | Analatresie | Q42.2, Q42.3 | NIDDK: anorektale Fehlbildungen, BfArM |
| Rektumatresie; rectal atresia; rectum imperforatum | Rektumatresie | Q42.0, Q42.1 | BfArM |
| anorektale Malformation; anorectal malformation | Oberbegriff für anorektale Fehlbildungen | Q42.0–Q42.3; Q43.5–Q43.7 | NIDDK, BfArM |
| Hirschsprung disease; congenital aganglionic megacolon | Hirschsprung-Krankheit | Q43.1 | NIDDK: Hirschsprung, BfArM |
| esophageal atresia; oesophageal atresia | Ösophagusatresie | Q39.0, Q39.1 | CDC: Esophageal Atresia, BfArM |
| congenital tracheoesophageal fistula | Angeborene Verbindung zwischen Speise- und Luftröhre | Q39.1, Q39.2 | CDC, BfArM |
| infantile hypertrophic pyloric stenosis | Infantile hypertrophische Pylorusstenose | Q40.0 | MedlinePlus: Pyloric stenosis, BfArM |
| biliary atresia | Gallengangsatresie | Q44.2 | NIDDK: Biliary Atresia, BfArM |
| tongue tie; ankyloglossia | Verkürztes Zungenbändchen | Q38.1 | Cambridge University Hospitals, BfArM |
| Meckel diverticulum | Meckel-Divertikel | Q43.0 | MedlinePlus, BfArM |
| inguinal hernia | Leistenhernie | K40 | NIDDK: Inguinal Hernia |
| umbilical hernia | Nabelhernie | K42 | NHS: Hernia |
| incisional hernia | Narbenhernie | K43.0, K43.1, K43.2 | Leeds Teaching Hospitals: Hernia Repair |
| gallstones | Gallensteine | K80 | NIDDK: Gallstones |
| acute appendicitis | Akute Appendizitis | K35 | NIDDK: Appendicitis |
| anal fissure | Analfissur | K60.0, K60.1, K60.2 | NHS: Anal fissure |
| anal fistula | Analfistel | K60.3 | NHS: Anal fistula |
| pilonidal sinus | Pilonidalzyste/Pilonidalsinus | L05 | NHS: Pilonidal sinus |
| carpal tunnel syndrome | Karpaltunnel-Syndrom | G56.0 | NIAMS: Carpal Tunnel Syndrome |
| trigger finger | Schnellender Finger | M65.3 | NHS: Trigger finger |
| tennis elbow; lateral epicondylitis | Tennisellenbogen | M77.1 | NIAMS: Sports Injuries |
| golfer's elbow; medial epicondylitis | Golferellenbogen | M77.0 | NIAMS: Sports Injuries |
| clubfoot; talipes equinovarus | Angeborener Klumpfuß | Q66.0 | MedlinePlus: Clubfoot |
| undescended testicle; undescended testis; cryptorchidism | Hodenhochstand | Q53.1, Q53.2, Q53.9 | MedlinePlus, BfArM |
| tight foreskin; phimosis | Phimose | N47 | Alder Hey: Foreskin information, BfArM |
| kidney stone; kidney stones | Nierenstein, auch mit gleichzeitigem Ureterstein | N20.0, N20.2 | NIDDK: Kidney Stones |
| hypospadias | Hypospadie | Q54 | Alder Hey: Hypospadias, BfArM |
Bei anorektalen Fehlbildungen sind Anal- und Rektumatresie sowie Fisteln, Fehllagen und eine persistierende Kloake unterschiedliche Varianten. Der breite Suchbegriff schließt diese Varianten ein, ohne sie als gleichbedeutend auszugeben. Eine Choanalatresie betrifft eine andere Anatomie und gehört nicht in diese Treffermenge. NIDDK, BfArM
Die amtliche ICD-10-GM führt Anus imperforatus unter Q42.3 und Rectum imperforatum unter Q42.1, also bei den jeweiligen Varianten ohne Fistel. Die unqualifizierte Begriffssuche zeigt bewusst beide Fistelvarianten als Prüfmöglichkeiten. Dies ist kein geänderter amtlicher Einschluss und kein automatischer Standardkode. Eine ausdrückliche Angabe mit oder ohne Fistel grenzt die Suchergebnisse ein. BfArM
Entsprechende Grenzen gelten auch bei anderen Begriffen: Ein Nierenstein ist nicht jeder beliebige Harnstein; ein Pendelhoden oder ein fehlender Hoden ist nicht gleichbedeutend mit Hodenhochstand. Eine einfache Suche nach Gallensteinen belegt weder eine Entzündung noch eine Obstruktion. NIDDK: Kidney Stones, BfArM, NIDDK: Gallstones
Direkte Bezeichnungen von Eingriffen
Diese englischen Begriffe bezeichnen selbst einen Eingriff. Anders als die anschließenden Diagnoseverknüpfungen dienen sie als direkte Suchvarianten des OPS-Begriffs. Zusätzliche Angaben zu Zugang und Umfang bleiben erforderlich.
| Suchbeispiele | OPS-Suchbereich | Deutscher Zielbegriff | Fachliche Quelle |
|---|
| appendectomy; appendicectomy | 5-470 | Appendektomie | NIDDK, Guy's and St Thomas' |
| cholecystectomy | 5-511 | Cholezystektomie | NIDDK |
| circumcision | 5-640.2 | Zirkumzision | MedlinePlus |
| orchiopexy; orchidopexy | 5-624 | Orchidopexie | MedlinePlus, NHS |
| gastrostomy | 5-431 | Gastrostomie | MedlinePlus |
| thyroidectomy; total thyroidectomy; partial thyroidectomy; hemithyroidectomy | 5-061, 5-062, 5-063, je nach Umfang | Schilddrüsenresektion; Umfang prüfen | NHS: Thyroid cancer treatment |
Die unqualifizierte Suche thyroidectomy zeigt 5-061, 5-062 und 5-063 als Prüfmöglichkeiten. total thyroidectomy grenzt auf 5-063 ein, partial thyroidectomy auf 5-061 und 5-062 und hemithyroidectomy auf 5-061. Eine Teilentfernung darf nicht als vollständige Thyreoidektomie übernommen werden. Eine Gastrostomie ist keine Gastrektomie. Auch direkte Eingriffsbegriffe in der Suche belegen für sich allein weder eine Indikation noch einen tatsächlich durchgeführten Eingriff.
Verwandte Eingriffe
Diese Verknüpfungen sind ausdrücklich als verwandte Eingriffe gekennzeichnet. Sie zeigen nur passende vorhandene OPS-Katalogzeilen; Diagnose und Eingriff werden dadurch nicht gleichgesetzt. Technische Einzelheiten müssen weiterhin aus der tatsächlichen Dokumentation hervorgehen.
| Ausgangsbegriff | OPS-Suchbereich | Bedeutung |
|---|
| Anorektale Fehlbildung/Atresie | 5-495, 5-496 | Rekonstruktion anorektaler Strukturen |
| Hodenhochstand | 5-624 | Orchidopexie |
| Phimose | 5-640.2 | Zirkumzision |
| Leistenhernie | 5-530 | Verschluss der Leistenhernie |
| Gallensteine | 5-511 | Cholezystektomie |
| Akute Appendizitis | 5-470 | Appendektomie |
| Infantile hypertrophische Pylorusstenose | 5-432.0 | Pyloromyotomie |
| Hypospadie | 5-645 | Rekonstruktion bei männlicher Hypospadie |
Die Kodebereiche und Bezeichnungen werden aus dem veröffentlichten OPS-Katalog aufgelöst. Ein verwandter Eingriff darf keine automatische Diagnoseannahme, Indikation, Verfahrenswahl oder Behauptung einer bereits erfolgten Operation auslösen.
Quellen und Pflege
Die Zuordnungen werden einzeln anhand der amtlichen ICD-10-GM und offizieller medizinischer Informationsquellen geprüft. Suchbegriffe und erwartete Kodebereiche müssen zusätzlich gegen die im Repository enthaltenen Kataloge geprüft werden. Abgrenzungen wie Fistelstatus, Anatomie und angeboren/erworben gehören zur Prüfung; eine Übersetzung allein genügt nicht.
Für diese Erweiterung wurde kein MeSH-, SNOMED- oder anderes vollständiges Fremdwörterbuch importiert.
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)
Die App öffnet sich bei jedem Start mit der Schnell-Kodesuche als erster Option. Für die Berichtsanalyse die zweite Option OP-Bericht prüfen auswählen.
KI vollständig deaktivieren: Die Checkbox oberhalb der beiden Optionen sperrt sämtliche KI-Anfragen, auch für Kode-Ergänzungen, DRG-Hinweise und Dokumententwürfe. Die Einstellung bleibt in diesem Browser gespeichert und gilt auch in anderen geöffneten App-Tabs. Kodesuche und regelbasierte Analyse bleiben nutzbar. Die Schaltflächen für Dokumententwürfe und DRG-Hinweise wechseln auf lokal. Beim Ausschalten werden noch laufende Browseranfragen und offene Versandvorschauen abgebrochen. Bereits versandte Daten lassen sich dadurch nicht zurückholen. Das Aufheben der Sperre sendet nichts automatisch; die automatische KI-Ergänzung muss bei Bedarf erneut aktiviert werden.
Auswertung in 4 Schritten
- OP-Bericht prüfen als Eingabemodus wählen und links das Prüfziel setzen:
- 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.
- OP-Bericht einfügen in das große Textfeld (deutscher Freitext genügt; Diagnose, Prozedur, Seite, Zugang, Befund, Komplikationen, Narkose, Entlassfähigkeit nennen).
- „OP-Bericht analysieren" klicken.
- 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.
OP-Bericht oder Entlassungsbrief erstellen
Nach der Analyse im Tab Bericht unter Vorlage zwischen OP-Bericht und Entlassungsbrief wählen und Erstellen anklicken. Der Entlassungsbrief gliedert die dokumentierten Angaben in Diagnosen, Behandlung, Befunde, Verlauf, Entlassungszustand, Entlassungsmedikation und Weiterbehandlung. Nicht dokumentierte Angaben bleiben als (prüfen: …) markiert. Es werden insbesondere keine Medikamente, Dosierungen, Kontrolltermine oder ein komplikationsloser Verlauf ergänzt.
Bei aktivierter KI erscheint vor dem Versand dieselbe Anonymisierungsvorschau wie beim OP-Bericht. Bei vollständig abgeschalteter KI oder offline wird die Vorlage lokal befüllt. Für den lokalen Entlassungsbrief helfen ausdrücklich beschriftete Abschnitte wie Entlassungsmedikation:, Verlauf: und Weiterbehandlung:; diese werden wörtlich übernommen. Der Entwurf ist vor der Verwendung ärztlich zu prüfen und lässt sich über Bericht kopieren übernehmen.
Schnell-Kodesuche: Begriff oder Kode
Im Eingabemodus Schnell-Kodesuche einen Begriff oder Kode eingeben, z. B. Leistenhernie, L60.0, 5-530.31, 31241 oder G24B. Die Suche startet nach einer kurzen Schreibpause automatisch; Suchen oder Enter startet sofort. Die Treffer sind nach ICD, OPS, EBM, AOP, Hybrid-DRG, aG-DRG und Zusatzentgelt gruppiert. Filterchips grenzen die Kataloge ein; Alle ist voreingestellt. Kleinschreibung und Präfixe wie 5-530 oder das gesamte OPS-Kapitel 5- funktionieren ebenfalls.
Auch gebräuchliche Bezeichnungen und ausgewählte englische oder lateinische Begriffe führen zu passenden Katalogeinträgen, etwa Analatresie, imperforate anus oder anorektale Malformation. Die Suche kennzeichnet Begriffszuordnungen und dazu passende Eingriffe. Eine Diagnosebezeichnung belegt dabei keine durchgeführte Operation. Zusätze wie mit Fistel, without fistula oder sine fistula bleiben Suchbedingungen. Ohne diese Angabe werden die möglichen Varianten zur Auswahl angeboten; die Suche ergänzt keine fehlenden Angaben. Die hinterlegten Begriffe und ihre Quellen sind in Suchbegriffe und Synonyme dokumentiert. Es handelt sich um einen kuratierten Wortschatz, keine allgemeine Übersetzung beliebiger medizinischer Texte.
Mehrere Stichwörter werden gemeinsam berücksichtigt: Schulter Arthroskopie, Schulterarthroskopie, schulter atrhoscopie und schulter athrosocpie finden passende Katalogeinträge statt beliebiger Eingriffe an der Schulter oder Hernien. Auch gemischte Eingaben wie L60.0 Nagel priorisieren den ausdrücklich genannten Kode. Zusätze wie akut, chronisch, laparoskopisch, beidseitig, mit/ohne und numerische Typ-/Stadiumangaben bleiben Suchbedingungen. Beispielsweise darf Migräne ohne Aura keinen Treffer „mit Aura“ als passenden Volltreffer ausgeben. Vollständige Katalogbezeichnungen lassen sich ebenfalls nachschlagen. Bekannte Katalogwörter werden weder bei der Suche noch in der Berichtsanalyse umgeschrieben. Bei einem diagnostischen Stichwort mit zusätzlichen, im ICD-Titel nicht enthaltenen Angaben können ausdrücklich markierte Teiltreffer erscheinen. Diese belegen die zusätzlichen Angaben nicht. Die Suche ist keine Diagnosefeststellung.
Exakte Kodes stehen vor Kodefamilien, exakten Bezeichnungen und ähnlichen Begriffen. Alle Treffer bleiben in einer scrollbaren Liste je Kataloggruppe erreichbar, auch bei mehreren Tausend Ergebnissen. Die Liste lässt sich per Tab fokussieren und mit Pfeiltasten, Bild ↑/↓, Pos1 und Ende durchlaufen; Tab erreicht auch die Bedienelemente weiterer Treffer. OPS-Treffer enthalten den AOP-/Hybrid- Abgleich, die zugeordnete GOP-Kette und die jeweiligen Katalogversionen. Fehlende Kataloge und reine Familientreffer bleiben ausdrücklich gekennzeichnet. Während „Katalog wird geladen …“ wird die letzte Suche automatisch aktualisiert.
Jeder Treffer bietet Kode kopieren und Kode + Bezeichnung kopieren. Mit ☆ Merken wird ein Treffer zum Favoriten; ★ Favorit hebt dies wieder auf. Beim nächsten Suchen stehen innerhalb derselben Trefferart zuerst Favoriten, danach häufiger erfolgreich kopierte oder übernommene Kodes. Exakte Kodes und Bezeichnungen behalten ihren Vorrang vor schwächeren Treffern; unpassende Kodes werden durch die persönliche Sortierung nicht hinzugefügt. Das reine Anhaken zählt noch nicht als Nutzung. Die laufende Liste springt beim Merken nicht um. Favoriten und Nutzung bleiben ausschließlich in diesem Browser und überstehen ein Neuladen. Favoriten & Nutzung zurücksetzen löscht beides. Berichtstext und Suchbegriffe werden dafür nicht gespeichert.
ICD-/OPS-Treffer lassen sich anhaken und mit Auswahl übernehmen & prüfen zur Berichtsprüfung hinzufügen. Bestehender Berichtstext bleibt erhalten. Die Schnell-Kodesuche zeigt ausschließlich Treffer aus geladenen Katalogen, keine freien Regelvorschläge. Es wird nichts automatisch ausgewählt. Abgeleitete Vorschläge in der Berichtsprüfung bleiben gesondert gekennzeichnet und sind zu bestätigen.
Ergebnis-Tabs sind mit Pfeiltasten, Home und End bedienbar. MD-, JSON- und FHIR-Exporte stehen im Menü Exportieren; Kopieren und Drucken bleiben direkt erreichbar.
Diagnose und Eingriff passen nicht zusammen
Die Berichtsprüfung kennzeichnet unter anderem unbelegte S92-Fußfrakturvorschläge und eine ungeklärte Zuordnung von S92 zu einer Gastrostomie. Betroffene Vorschläge werden nicht als sichere Kodierung übernommen. Dokumentierte Begleiterkrankungen und tatsächlich parallel durchgeführte Eingriffe bleiben möglich. Die App ersetzt keine Diagnose automatisch durch eine vermutete andere Diagnose. Originaltext und Belegstellen bleiben erhalten; unter Prüfpunkte stehen die Klärfragen. Diese Prüfung deckt nicht sämtliche möglichen ICD-/OPS-Kombinationen ab.
Dokumentiert, aber noch nicht automatisch kodierbar
Stehen Diagnose und Eingriff im Text, ohne dass die App einen passenden Kode zuordnen kann, zeigt sie Kodierung offen und benennt die offene ICD-/OPS-Zuordnung. Die dokumentierten Angaben bleiben sichtbar. Eine allgemeine Darmentleerungsstörung wird dabei nicht automatisch als bestimmter Obstipations-Untertyp kodiert. Beim Malone-Zugang kann eine belegte Neuanlage mit Kontinenzmechanismus eine OPS-Familie zur Prüfung liefern; Zugang und Endstelle bleiben fachlich zu bestätigen.
Verneinte Angaben wie „keine Verletzung“ oder „ohne Verletzung“ begründen keinen Komplikationswiderspruch. Wenn ein tatsächlich bejahter Komplikationsbegriff einer Aussage zur Komplikationsfreiheit gegenübersteht, nennt die Prüfung den konkreten Begriff und die beiden Textbelege. Diese Angaben bleiben lokal in der Auswertung und werden nicht als Textstellen in die Nutzungsprotokolle übernommen.
Optionale Einstellungen (unter „Erweiterte Einstellungen“)
- 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,simple-view.js,simple-view.css,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).
Nutzungsstatistik
Die interne Ansicht unter /intern/#usage zeigt nach Eingabe des bestehenden ADMIN_TOKEN die Nutzung für 7, 30 oder 90 Kalendertage. Der laufende Tag ist enthalten; Tagesgrenzen sind UTC. „Aktualisieren“ lädt die aktuellen Summen. Es werden keine externen Analysedienste oder Tracking-Cookies eingebunden.
Kennzahlen
- Seitenstarts: einmal beim Initialisieren der App, auch beim Neuladen.
Keine Personen- oder Sitzungszählung. IP-Hashes eignen sich dafür nicht und werden im Dashboard nicht als Besucherzahl dargestellt.
- Analysen: abgeschlossene lokale Analyse einschließlich Ergebnisdarstellung.
Eine spätere KI-Anfrage ist ein eigener Vorgang und erhöht diesen Zähler nicht.
- Katalogsuche: eine Beobachtung pro ausgewertetem Katalog. Auch die
verzögerte Suche während des Tippens kann mehrere Beobachtungen erzeugen. Die Trefferquote ist der Anteil bereiter Katalogabfragen mit mindestens einem Treffer. Ladende und fehlende Kataloge sind ausgeschlossen und separat sichtbar. Eine hohe Quote belegt nicht die fachliche Richtigkeit der Treffer.
- Ansichten und Geräte: Ansicht bei Seitenstart und Analyse; Geräteklasse
aus dem Browser bei Seitenstart. Wechsel zählen unter Funktionsaufrufen.
- Ergebnisaktionen: bestätigtes Kopieren, Übernehmen von Kodes, gestartete
Downloads. Drucken zählt nur die Anforderung des Druckdialogs. Ein tatsächlich gespeichertes Dokument oder ein Papierausdruck ist nicht beobachtbar.
- Fehler und Laufzeiten: lokale Suche, lokale Analyse und KI-HTTP-Anfragen.
Fehlgeschlagene Kopiervorgänge stehen gesondert bei Ergebnisaktionen. Abbrüche sind von der Fehlerquote ausgeschlossen. Median (unterer Wert bei gerader Anzahl) und 95. Perzentil nach dem Rangverfahren beschreiben nur erfolgreiche Vorgänge. KI-Zeiten enthalten Netzwerk und JSON-Verarbeitung. Es werden ausschließlich technische Fehlerklassen/HTTP-Status, keine Fehlermeldungen, URLs oder Texte übertragen.
- Funktionsaufrufe: zusätzliche Aktivierungen einschließlich alter
Klickzählungen. Sie belegen keinen erfolgreichen Abschluss. Die einfachen Optionen und Akkordeons werden bei tatsächlicher Betätigung gezählt.
Die neuen Messungen tragen schemaVersion: 2. Der angezeigte Beginn bezeichnet das erste solche Ereignis im gewählten Zeitraum. Ältere Ereignisse bleiben nutzbar, erhalten aber keine erfundene Ansicht, Laufzeit oder Abschlussmeldung. Ohne geeignete Messungen erscheinen Quoten und Laufzeiten als „—“.
Suchthemen ohne Originaleingaben
Für jeden ausgewerteten, bereiten ICD-/OPS-Katalog wird aus dessen erstem Treffer höchstens eine Gruppe abgeleitet, beispielsweise K40 oder 5-530. Der Client überträgt dafür weder Suchtext noch Trefferbeschreibung oder Einzelkode. Der Server akzeptiert nur Gruppen, die im öffentlichen Katalog unter server/public/catalogs/ enthalten sind. Bezeichnungen werden aus diesem Katalog gelesen; vom Client mitgesendete Bezeichnungen werden ignoriert.
Diese Beobachtungen landen ausschließlich in server/data/usage/topics-YYYY-MM-DD.json als Tageszähler pro Kataloggruppe. Die Dateien enthalten keine IP-Hashes, Geräte, Ansichten, Nutzerkennungen oder genauen Zeitstempel. Schreibvorgänge sind für den einzelnen Dienstprozess serialisiert und werden atomar ersetzt. Bei einem Betrieb mit mehreren schreibenden Prozessen wäre stattdessen ein gemeinsamer transaktionaler Speicher erforderlich.
Die API zeigt bis zu 30 häufige Gruppen, erst ab fünf Beobachtungen im gewählten Zeitraum. Seltene Gruppen werden bereits auf dem Server herausgefiltert. Diese Schwelle bezieht sich auf Beobachtungen, nicht auf verschiedene Nutzer; wiederholte Auswertungen derselben Person können mitzählen. Die Themen beschreiben mögliche Suchtreffer und keine gesicherte Suchabsicht. Es findet keine nachträgliche Rekonstruktion früherer Suchtexte statt.
Zugriff und Speicherung
Das Dashboard verwendet GET /api/admin/usage?days=N&summary=1. Der Token wird als x-admin-token gesendet; Antworten werden nicht gecacht. Ohne summary=1 enthält der vorhandene interne Endpunkt weiterhin technische Rohereignisse. Diese liegen in usage-YYYY-MM-DD.jsonl und enthalten wie bisher gekürzte IP-Hashes: Sie sind pseudonymisiert, nicht vollständig anonym. Themenereignisse werden nie in diese Dateien aufgenommen. Such- und Berichtstexte werden für die Nutzungsstatistik nicht übertragen. Analyse-Protokolle und aktiv gesendetes Feedback sind separate Datenbestände.
Die optionale KI-Auswertung ist eine ausdrückliche Schaltfläche. Bei Auswahl von „Nutzung“ erhält sie dieselben aggregierten Kennzahlen inklusive der freigegebenen Themen und des ausgewählten Zeitraums, keine Rohereignisse. Die übergreifende KI-Deaktivierung gilt weiterhin.
Die bestehenden Aufbewahrungsregeln für usage/ erfassen auch die Themendateien. npm run prune:data:dry prüft, npm run prune:data löscht abgelaufene Dateien (Standard 180 Tage). Das Skript muss durch den Betreiber regelmäßig ausgeführt werden; durch diese Änderung wird kein Zeitplan eingerichtet.
Messungen erfolgen bestmöglich: geschlossene Tabs, Netzfehler, Browserblocker und abgebrochene Übertragungen können zu Unterzählung führen. Öffentliche Ereignisse sind kein manipulationssicherer Audit-Nachweis.
Prüfung
npm run test:usage prüft Zeitfenster, Quoten, Datenbegrenzung, Themenvalidierung, parallele Zählerupdates und die Unterdrückung seltener Gruppen. npm run test:server prüft HTTP-Zugriff und getrennte Speicherung in temporären Testverzeichnissen. Die Browserprüfungen test:browser:usage und test:browser:simple fangen API-Zugriffe ab; sie schreiben keine Testereignisse in den laufenden Dienst.
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:
- 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.
- 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).
- 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.
Eine feste 11-Punkte-Checkliste, jeder Punkt hat einen finder(context):
| Kategorie | Finder | Zweck |
|---|
| Hauptdiagnose/Indikation | findDiagnosis | ICD-Grundlage |
| Prozedur | findProcedureFact | OPS-Grundlage |
| Seitenlokalisation | findSide | rechts/links/beidseits |
| Zugang/Verfahren | findAccess | offen/laparoskopisch/… |
| Narkose/Lagerung | findAnesthesiaAndPosition | Plausibilität |
| Intraoperativer Befund | findIntraoperativeFinding | Schweregrad |
| Material/Implantate/Drainagen | findMaterial | Sachkosten/Subkode |
| Komplikationen | findComplications | AOP/stationäre Begründung |
| Postoperativer Verlauf | findPostoperative | — |
| Ambulante Entlassfähigkeit | findDischarge | AOP-Abrechnung |
| Erschwernis/Aufwand | findDifficulty | nur wenn dokumentiert |
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:
| Position | Parse aus Anhang-2-Notiz | Budget |
|---|
| OP-GOP | OP-GOP ambulant (\d+) | extrabudgetär |
| Überwachung | Überwachungskomplex (\d+) | ggf. budgetiert (RLV/HVM) |
| Behandlung | Behandlungskomplex \d+/(\d+) | ggf. budgetiert |
| Förderzuschlag | Förderzuschlag (\d+) | extrabudgetär |
| Hygiene | HYGIENE_BY_OPGOP[opGop] (BA 716, EBM 31.2.19) | extrabudgetär |
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) — altersspezifische 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:
| Ziel | Zusatzlücken |
|---|
| aop (AOP/Hybrid-DRG) | ambulante Entlassfähigkeit prüfen |
| kodierung | Stammkodes → endständig präzisieren; fehlende Detailangaben; Nebendiagnosen vollständig? |
| stationaer | Anlage-2-Kontextfaktoren-Abgleich (findContextFactorHits) + stationäre Abrechnungshinweise |
| md | erhöhte Prüfschärfe: alle Pflichtangaben + endständige Kodes als „hoch (MD-Kürzungsrisiko)" |
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
| Funktion | Ergebnis | Logik |
|---|
rateCoding (2574) | gut / eingeschränkt / schlecht | ICD+OPS vorhanden? kritische Lücken ≤ Schwelle (bei Ziel „md" = 0, sonst 1) |
evaluateAop (2601) | ja / unklar | AOP-Kandidat mit Katalogtreffer; ohne geladenen AOP-Katalog → „unklar" |
evaluateHybrid (2650) | Pflicht-Abgleich | Fall-OPS gegen Hybrid-DRG-Positivliste 2026 |
computeAuditReadiness (1464) | Headline 1 | revisionssicher / mit Auflagen / Kürzungsrisiko — aus „Risiko"-Lücken + Kodierbarkeit |
computeValueEstimate (1483) | Headline 2 | €-Kette des ersten bepreisbaren OPS |
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:
- „KI-Ergänzung" angehakt ist (
aiEnabled), und - die Regeln eine Lücke lassen (
hasCodeGap für ICD oder OPS), und - 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):
- 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
| Funktion | Zweck |
|---|
ERROR_CLASSES | zentrale Fehlerklassen |
checkTerminalCode(cand, catalog) | Endständigkeit (Stamm-Marker + Katalog-Subkodes) |
detectCodingContradictions({...}) | Seiten-/Zugangs-/Komplikations-/Gastrostomie-/Hernien-/Hodenhochstand-/AOP-/Stationär-Widersprüche |
scoreCandidate(cand) / classifyCandidate(score, cand) | deterministisches Scoring + confidence/risk (Schutzregeln: ohne Beleg nie „hoch", KI nie „hoch") |
annotateSuggestions(list, type, {...}) | stempelt source, evidenceList, terminal, catalogHit, ebmComplete, score, scoreBreakdown, confidence, risk, errorClasses, contradictionsForCode |
selectBestCodingCandidates({...}) | trennt safeCoding vs. optimizationCandidates |
evaluateAopContextSafety({...}) | aopStatus/hybridStatus/stationaryJustification/contextFactors |
appendPediatricCodingChecks({...}) | kinderchirurgische Zusatz-Lücken |
anonymizeClinicalText(text) | entfernt Namen/DOB/Fallnr./Adresse/Tel./E-Mail vor KI |
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
- Nutzungsmetadaten (
/api/usage-log, Auswertung token-geschützt): technische
Ereignisse mit IP-Hash; Suchthemen separat als Tageszähler ohne Kennungen oder Originaleingaben (siehe Nutzungsstatistik).
- 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-09-24 · 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, gelernte Regeln und persönliche Suchpräferenzen bleiben lokal; Kataloge liegen in IndexedDB.
- Server-Protokolle: Analyse- und Nutzungsprotokolle arbeiten mit serverseitiger
Whitelist-Sanitisierung. Das Nutzungsprotokoll enthält Suchmetadaten und Funktionsnutzung, keine Such- oder Berichtstexte. Technische Ereignisse mit gekürztem IP-Hash sind pseudonymisiert. Suchthemen werden separat als Tageszähler ohne Kennungen gespeichert (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.
Persönliche Suchpräferenzen (seit 2026-09-17): Unter aopQuickPreferences.v1 speichert die App im lokalen Browser Kodeart/Kode, Favoritenstatus, Nutzungshäufigkeit und letzten Nutzungszeitpunkt. Dies dient ausschließlich der Sortierung passender Suchtreffer. Suchbegriffe, Katalogbezeichnungen und Berichtstexte werden dafür nicht gespeichert. Es gibt keinen Server-Sync und keine Übertragung dieser Präferenzen. Auf gemeinsam genutzten Browserprofilen sind sie für nachfolgende Nutzer sichtbar; Favoriten & Nutzung zurücksetzen entfernt sie aus dem Browserspeicher.
2.5 Optionale KI-Funktionen — DSGVO-relevanter Pfad
Die sichtbare Checkbox KI vollständig deaktivieren sperrt alle folgenden KI-Funktionen. Der Zustand wird unter aopAiDisabled.v1 im lokalen Browser gespeichert und zwischen geöffneten App-Tabs synchronisiert. Beim Ausschalten werden offene Versandvorschauen geschlossen und laufende Browseranfragen abgebrochen; schon versandte Daten werden dadurch nicht zurückgeholt. Die Sperre gilt auch nach dem Neuladen. Ein erneutes Freigeben startet keinen KI-Aufruf. Dokumententwürfe und DRG-Checklisten bleiben als lokale, regelbasierte Funktionen verfügbar. Suchbegriffe und die neuen Sprachzuordnungen benötigen keine KI.
Drei Funktionen können bei freigegebener KI einen konfigurierten Endpunkt aufrufen. Die automatische Kode-Ergänzung benötigt zusätzlich das Häkchen „KI-Ergänzung" und eine offene Kodezuordnung. Die Schaltflächen für DRG-Hinweise und Dokumententwürfe lösen einen manuellen KI-Aufruf aus, auch ohne dieses Häkchen. Bei fehlender Verbindung bleiben lokale Entwürfe verfügbar.
| Funktion | Endpunkt | Zweck |
|---|
| Kode-Ergänzung | POST /suggest-codes | Vorschläge für nicht ableitbare Kodes |
| DRG-Höhergruppierung | POST /drg-upgrade | Trigger-Prüfung für höhere DRG |
| OP-Bericht / Entlassungsbrief | POST /ideal-report | Formulierungsentwurf anhand der gewählten Vorlage; documentType bestimmt die Dokumentart |
Die KI-Sperre gilt auch für die KI-Auswertung in der internen Ansicht desselben Browsers. Sie ersetzt keine serverweite Abschaltung für andere Browser oder direkte API-Zugriffe.
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 Server-Protokolle und Nutzungsstatistik
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):
- Suchmetadaten: Katalog, Suchtyp (Text/Kode), Trefferzahl und
Ladezustand. Originaleingaben werden nicht übertragen oder gespeichert.
- Funktionsnutzung: feste Bezeichner für Ansicht, Optionen und Aktionen;
Erfolgs-/Fehlerstatus beim Kopieren und Exportieren, Anforderung des Druckdialogs.
- Technische Daten: App-Version, Viewport, Sprache, Geräteklasse,
Ereigniszeitpunkt, Ansicht sowie Laufzeit und feste Fehlerklassen für Suche, lokale Analyse und KI-Anfragen. Keine Fehlermeldungstexte oder URLs.
Suchthemen: Aus dem ersten Treffer eines bereiten ICD-/OPS-Katalogs wird eine Kodegruppe abgeleitet. Der Server prüft sie gegen den öffentlichen Katalog und speichert nur Tageszähler pro Gruppe, getrennt von technischen Ereignissen. Diese Dateien enthalten keine IP-Hashes, Nutzerkennungen, genauen Zeitstempel oder Originaleingaben. Die Auswertung zeigt Gruppen erst ab fünf Beobachtungen im gewählten Zeitraum. Wiederholte Suchen können mitzählen; die Schwelle steht nicht für fünf verschiedene Personen.
Technische Herkunft: Die Nutzungsereignisse enthalten statt der IP-Adresse einen gesalzenen, gekürzten SHA-256-Hash. Diese Daten sind pseudonymisiert, nicht vollständig anonym. Der Hash ist keine verlässliche Besucherkennung und wird im Dashboard nicht zur Personenzählung verwendet. Suchthemen werden nicht mit diesen Ereignissen verknüpft. Details zu Messung, Zugriff und Aufbewahrung stehen unter Nutzungsstatistik.
3. Wo werden Daten gespeichert?
| Ort | Inhalt | Personenbezug | Lebensdauer |
|---|
Browser localStorage (App-State) | nur Einstellungen (Prüfziel, Haken, Punktwert) — Berichtstext wird nicht gespeichert | nein | bis Browserdaten gelöscht |
Browser localStorage (Regeln) | gelernte Befund→Kode-Muster | nein (designgemäß) | bis gelöscht |
| Browser IndexedDB | importierte Referenzkataloge | nein | bis gelöscht |
| Browser-HTTP-Cache / Cookies | nichts (no-store, keine Cookies seit 2026-06-09) | — | — |
| Server (Datei) | gelernte Regeln (rules-store) | nein (designgemäß) | bis gelöscht |
| OpenAI (nur bei KI-Nutzung) | anonymisierter Text + Meta | minimiert | nach Anbietervorgaben/AVV |
Server (data/analyses/) | Analyse-Log: Kodes/Bewertungen (Whitelist) | nein (designgemäß) | bis gelöscht |
Server (data/usage/usage-*.jsonl) | Suchmetadaten, Feature-Events, Status/Laufzeiten, IP-Hash | pseudonymisiert | bis Aufbewahrungsskript ausgeführt wird |
Server (data/usage/topics-*.json) | Tageszähler für öffentliche Kataloggruppen, keine Originaleingaben | ohne gespeicherte Nutzerkennungen | bis Aufbewahrungsskript ausgeführt wird |
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).
- ✅ Nutzungsstatistik mit Whitelist, ohne Originaleingaben; technische Ereignisse
pseudonymisiert, Suchthemen separat ohne Kennungen (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
| # | Risiko | Eintritt | Wirkung | Maßnahme |
|---|
| R1 | ~~Klartext-Bericht im localStorage~~ behoben: Bericht wird nicht mehr persistiert | – | – | konstruktiv beseitigt (2026-06-04) |
| R2 | Drittlandübermittlung via OpenAI bei KI-Nutzung | nur bei Opt-in | hoch | AVV + Transfer-Mechanismus oder EU/On-Prem-Endpunkt |
| R3 | Anonymisierung unvollständig (seltene Muster) | gering | hoch | Block-Logik vorhanden; org. Freigabe, manuelle Sicht |
| R4 | Offener CORS auf /api/rules | mittel | gering–mittel | Origin-Allowlist setzen |
| R5 | KI-Endpunkt/Key kompromittiert | gering | hoch | nicht-öffentlich, Auth, Key-Rotation, TLS |
| R6 | Veraltete Katalog-/Jahresversion → Fehlkodierung | mittel | mittel | Katalogpflege-Job, „gegen Jahresversion prüfen" |
| R7 | Missbrauch/Flooding der KI-Endpunkte | gering | mittel | umgesetzt: Rate-Limit 8/min/IP + Verbindungslimit (429) |
| R8 | Code-/Konfigurationsabfluss über Webserver | gering | hoch | umgesetzt: Dotfile-Sperre, kein .git im Webroot, privates Repo |
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)
| Prozess | Beschreibung | Mitgeltendes Dokument |
|---|
| Kernprozess: Analyse-Engine | Regelbasierte OP-Bericht-Prüfung, Kode-/Vergütungslogik | FUNKTIONSWEISE, ENGINE, GOVERNANCE |
| Katalogpflege | Monatliche Pflege von ICD/OPS/EBM/AOP/Hybrid aus amtlichen Quellen | BEDIENUNG, server/catalog-sources.json |
| Entwicklung & Release | Versionierung, Tests, Code-Review, Auslieferung | DOKUMENTENLENKUNG, CONTRIBUTING.md, .github/workflows/ |
| Informationssicherheit | TOMs, Härtung, Zugriff, Schwachstellen | INFORMATIONSSICHERHEIT, SICHERHEIT-DSGVO, SECURITY.md |
| Datenschutz | Datenflüsse, Anonymisierung, Betroffenenrechte | SICHERHEIT-DSGVO, AUFBEWAHRUNG |
| Unterstützung & Schulung | Anwenderhilfe, Bedienung | BEDIENUNGSANWEISUNG, HANDOUT, Hilfe-Website |
| Überwachung & Verbesserung | Audits, Management-Review, Fehler/CAPA | INTERNES-AUDIT, CAPA |
| Risikomanagement | Produkt-, Prozess- und Sicherheitsrisiken | RISIKOMANAGEMENT |
4. ISO 9001:2015 — Kapitel-Abdeckung
| Kapitel | Anforderung | Umsetzung | Nachweis |
|---|
| 4 Kontext | Geltungsbereich, interessierte Parteien, Prozesse | umgesetzt | dieses Handbuch, Kap. 1+3 |
| 5 Führung | Politik, Rollen, Verantwortung | umgesetzt | QUALITAETSPOLITIK, Kap. 6 |
| 6 Planung | Risiken & Chancen, Qualitätsziele | umgesetzt | RISIKOMANAGEMENT, QUALITAETSPOLITIK |
| 7 Unterstützung | Kompetenz, dokumentierte Information | umgesetzt | Kap. 6, DOKUMENTENLENKUNG |
| 8 Betrieb | Design-/Änderungslenkung, Lieferanten | umgesetzt | DOKUMENTENLENKUNG, CONTRIBUTING.md, Tests |
| 9 Bewertung | Internes Audit, Monitoring, Management-Review | umgesetzt | INTERNES-AUDIT |
| 10 Verbesserung | Nichtkonformität & Korrekturmaßnahmen | umgesetzt | CAPA |
5. Mitgeltende Dokumente
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.
| Rolle | Verantwortung |
|---|
| Produktverantwortung / QMB | Qualitätspolitik, Freigaben, Management-Review, Audit-Auslösung |
| Entwicklung | Code, Tests, Code-Review, Release nach CONTRIBUTING.md |
| Katalog-/Fachpflege | monatliche Katalogaktualisierung, fachliche Regelprüfung |
| Betrieb / Informationssicherheit | Deployment, Härtung, Schwachstellen, Backups |
| Datenschutz (DSB des Hauses) | DSFA, Verarbeitungsverzeichnis, Betroffenenrechte |
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.
| # | Ziel | Kennzahl | Zielwert | Messung |
|---|
| Q1 | Fehlerfreie Releases | Bestandene automatisierte Tests vor jedem Release | 100 % grün | CI (.github/workflows/ci.yml) |
| Q2 | Test-Abdeckung der Engine | Anzahl automatisierter Checks | ≥ 140, nicht sinkend | Test-Ausgabe (test/*.mjs) |
| Q3 | Katalogaktualität | Tage von amtlicher Veröffentlichung bis Übernahme | ≤ 30 Tage | Katalog-Manifest + catalog-sources.json |
| Q4 | Revisionssicherheit | Anteil „hoch"-Konfidenz-Kodes ohne Textbeleg | 0 % | Engine-Schutzregel + Test |
| Q5 | Datenschutz | Persistierter Berichtstext / Roh-IP in Protokollen | 0 (keiner) | Anonymisierungs-Tests, Code-Review |
| Q6 | Sicherheitsupdates | Offene kritische Abhängigkeits-Schwachstellen | 0 | npm audit / Security-Workflow |
| Q7 | Fehlerbearbeitung | Median-Zeit von Fehlermeldung bis Korrektur (kritisch) | ≤ 14 Tage | CAPA-Register |
| Q8 | Reaktion auf Anwender-Feedback | Bearbeitetes Feedback je Review-Zyklus | ≥ 90 % gesichtet | Feedback-Log, Management-Review |
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
| Frage | Bewertung |
|---|
| Verarbeitet das Produkt medizinische Daten zu einem medizinischen Zweck (Art. 2 MDR)? | Nein — der Zweck ist administrativ (Kodierung/Abrechnung). |
| Liefert die Software Informationen für diagnostische oder therapeutische Entscheidungen? | Nein — sie liefert Informationen für Abrechnungs-/Kodierentscheidungen. |
| Greift „Software for administrative/billing purposes" als Ausschluss? | Ja — gemäß MDCG 2019-11 (Qualification/Classification of Software) sind Software für Verwaltung und Abrechnung ausdrücklich keine Medizinprodukte. |
| Einordnung als In-vitro-Diagnostikum (IVDR)? | Nein — keine Untersuchung von Proben/IVD-Bezug. |
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
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)
| # | Risiko / Fehlermöglichkeit | Folge | W | A | RPZ | Maßnahme (Mitigation) | Status |
|---|
| P1 | Engine schlägt nicht durch Doku gedeckten Kode mit „hoch" vor | Kürzung in MD-Prüfung | 1 | 3 | 3 | Schutzregel „ohne Beleg nie hoch", KI nie „hoch"; Test Q4 | beherrscht |
| P2 | Veraltete Katalog-/Jahresversion | Fehlkodierung, Regress | 2 | 3 | 6 | Monatliche Katalogpflege, catalog-sources.json, „gegen Jahr prüfen" | überwacht |
| P3 | Falsch-positiver Vergütungswert wird als gesichert verstanden | Fehlerwartung, Beschwerde | 2 | 2 | 4 | Disclaimer „Schätzung/kein Grouper" in UI + Doku | beherrscht |
| P4 | Fehler in Regel-/Ableitungslogik (Regressionsfehler) | Falsche Vorschläge | 2 | 3 | 6 | 140+ automatisierte Tests, CI vor Release, Code-Review | überwacht |
| P5 | Anwender verlässt sich blind auf KI-Vorschlag | Fehlkodierung | 2 | 2 | 4 | KI bleibt „zu prüfen", überschreibt nie; Schulung/Handout | beherrscht |
| P6 | Fehlerhafter Katalog-Import (Format) | Lücken/fehlende Treffer | 1 | 2 | 2 | Manifest-Prüfung, Konverter-Skripte, Stichprobe | beherrscht |
| P7 | Re-Klassifizierung als Medizinprodukt durch Funktionsänderung | Regulatorische Lücke | 1 | 3 | 3 | Zweckbestimmung als Änderungs-Trigger | überwacht |
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)
| Dok-ID | Titel | Datei | Version | Nächste Prüfung |
|---|
| QMH-01 | QM-Handbuch | docs/QM-HANDBUCH.md | 1.0 | 2027-06-09 |
| QM-POL-01 | Qualitätspolitik & Ziele | docs/QUALITAETSPOLITIK.md | 1.0 | 2027-06-09 |
| QM-ZWB-01 | Zweckbestimmung & Einordnung | docs/ZWECKBESTIMMUNG.md | 1.0 | 2027-06-09 |
| QM-RIS-01 | Risikomanagement | docs/RISIKOMANAGEMENT.md | 1.0 | 2027-06-09 |
| QM-DOK-01 | Dokumenten- & Änderungslenkung | docs/DOKUMENTENLENKUNG.md | 1.0 | 2027-06-09 |
| QM-AUF-01 | Aufbewahrung & Löschkonzept | docs/AUFBEWAHRUNG.md | 1.0 | 2027-06-09 |
| QM-CAPA-01 | Fehler- & Korrekturmaßnahmen | docs/CAPA.md | 1.0 | 2027-06-09 |
| QM-AUD-01 | Internes Audit & Management-Review | docs/INTERNES-AUDIT.md | 1.0 | 2027-06-09 |
| QM-ISO27-01 | Informationssicherheit | docs/INFORMATIONSSICHERHEIT.md | 1.0 | 2027-06-09 |
| QM-BCK-01 | Backup & Wiederherstellung | docs/BACKUP.md | 1.0 | 2027-06-09 |
| QM-AVV-01 | Auftragsverarbeitung & Lieferanten | docs/AVV-OPENAI.md | 1.0 | 2027-06-09 |
| — | Sicherheit & DSGVO | docs/SICHERHEIT-DSGVO.md | — | 2027-06-04 |
| — | Funktionsweise / Engine / Governance | docs/FUNKTIONSWEISE.md u. a. | — | bei Änderung |
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
| Datenkategorie | Ort | Zweck | Regelfrist | Löschung |
|---|
| OP-Berichtstext | Browser (flüchtig) | Analyse | keine Speicherung | beim Neuladen weg |
| App-Einstellungen, gelernte Regeln | Browser localStorage | Komfort | bis Nutzer löscht | „Zurücksetzen" / Browserdaten |
| Referenzkataloge | Browser IndexedDB | lokale Analyse im Browser | bis Update/Löschung | Neuimport |
| Analyse-Log (anonymisiert) | server/data/analyses/ | Qualität/Verbesserung | 180 Tage | scripts/prune-data.mjs |
| Nutzungs-Log (anonymisiert) | server/data/usage/ | Verbesserung | 180 Tage | scripts/prune-data.mjs |
| Anwender-Feedback | server/data/feedback/ | Verbesserung | 365 Tage | scripts/prune-data.mjs |
| Gelernte Regeln (Server) | server/data/rules.json | geteilte Regelbasis | dauerhaft (kein PB) | manuell bei Bedarf |
| QM-Aufzeichnungen (Audit, Review, CAPA) | Repo docs/ / Git | Nachweis ISO 9001 | min. 3 Jahre | i. d. R. dauerhaft im Verlauf |
| Release-/Änderungshistorie | CHANGELOG.md / Git | Nachvollziehbarkeit | dauerhaft | — |
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.
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
| Grad | Bedeutung | Beispiel |
|---|
| Kritisch | Datenschutz/Sicherheit oder systematische Fehlkodierung | Roh-IP geloggt; Engine schlägt falschen Kode „hoch" vor |
| Hoch | Funktionsfehler mit Abrechnungswirkung | EBM-Kette unvollständig für häufigen Fall |
| Mittel | Funktionsfehler ohne Abrechnungswirkung | UI-Anzeige fehlerhaft |
| Niedrig | Kosmetik / Doku | Tippfehler, unklare Beschriftung |
4. CAPA-Register (Vorlage)
Neue Einträge unten anhängen. Bei Schließung Datum + Ergebnis der Wirksamkeitsprüfung eintragen.
| ID | Datum | Quelle | Beschreibung | Grad | Ursache (Root Cause) | Korrektur-/Vorbeugemaßnahme | Verantwortlich | Status | Geschlossen am |
|---|
| CAPA-2026-001 | 2026-06-09 | Audit | Beispiel-Eintrag: Aufbewahrungsfristen nicht definiert | Mittel | QMS-Lücke | AUFBEWAHRUNG + prune-data.mjs erstellt | Produktverantwortung | geschlossen | 2026-06-09 |
| CAPA-2026-002 | 2026-06-09 | Audit (AUDIT-2026-001, NC-1) | KI aktiv ohne abgeschlossenen AVV mit OpenAI Ireland | Mittel | Vertrag fehlt | Sofortmaßnahme: zweifache Anonymisierung + Versand-Vorschau aktiv; Doku AVV-OPENAI; DPA-Abschluss + DPF-Verifikation | Produktverantwortung | offen | Ziel 2026-06-30 |
| CAPA-2026-003 | 2026-06-09 | Anwendermeldung (Feedback-Funktion „offline") | KI-/API-Dienst 20:28–20:46 UTC nicht erreichbar (502): Prozess durch externes SIGTERM beendet; Restart=on-failure startet bei sauberem TERM nicht neu | Mittel | Unit-Restart-Policy deckte TERM nicht ab | Restart=always in aop-coding.service gesetzt; Feedback-Versand end-to-end verifiziert; Quelle des TERM unklar (Syslog ohne Befund) — bei Wiederholung Prozess-Monitoring ergänzen | Betrieb | geschlossen | 2026-06-09 |
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
| # | Prüfpunkt | Nachweis | Befund (✓/Hinweis/NC) |
|---|
| 1 | Qualitätspolitik aktuell & bekannt | QUALITAETSPOLITIK, Kopf-Datum | |
| 2 | Qualitätsziele gemessen & bewertet | KPI-Tabelle Q1–Q8, CI-Ausgaben | |
| 3 | Tests grün, in CI durchgesetzt | .github/workflows/ci.yml, Test-Output | |
| 4 | Keine kritischen Abhängigkeits-Schwachstellen | npm audit / Security-Workflow | |
| 5 | Kataloge aktuell (≤ 30 Tage) | Manifest, catalog-sources.json | |
| 6 | Engine-Schutzregel „ohne Beleg nie hoch" wirkt | Test Q4, Stichprobe | |
| 7 | Kein Berichtstext / keine Roh-IP in Protokollen | Anonymisierungs-Tests, Stichprobe data/ | |
| 8 | Aufbewahrungsfristen eingehalten (Prune läuft) | prune-data.mjs-Log / Cron | |
| 9 | Dokumentenregister vollständig & versioniert | DOKUMENTENLENKUNG | |
| 10 | Offene CAPA verfolgt, Zielzeiten gehalten | CAPA-Register | |
| 11 | Risiken RPZ ≥ 6 mit Maßnahme hinterlegt | RISIKOMANAGEMENT | |
| 12 | Zweckbestimmung weiterhin gültig (kein MDR-Trigger) | ZWECKBESTIMMUNG | |
| 13 | TOMs/SoA umgesetzt (TLS, CSP, CORS, Rate-Limit) | INFORMATIONSSICHERHEIT, nginx-Conf | |
| 14 | AVV/Transfer-Mechanismus, falls KI aktiv | SICHERHEIT-DSGVO 4.3 | |
| 15 | Anwender-Feedback gesichtet & verarbeitet | Feedback-Log, CAPA | |
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.
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.
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
| Asset | Schutzbedarf | Bemerkung |
|---|
| OP-Berichtstext (Eingabe) | sehr hoch (Art. 9 DSGVO) | wird nicht gespeichert; lokal im Browser |
Anonymisierte Protokolle (server/data/) | mittel | ohne Personenbezug (designgemäß) |
| OPENAI_API_KEY / ADMIN_TOKEN | hoch | nur serverseitig in .env, nie im Frontend |
| Quellcode | mittel | privates Repository |
| Referenzkataloge | mittel (Integrität) | amtliche Quellen, versioniert |
3. Anwendbarkeitserklärung (SoA-lite) — ISO/IEC 27001:2022 Anhang A
| A.5 Organisatorisch | Status | Umsetzung / Nachweis |
|---|
| Leitlinien (A.5.1) | ✅ | dieses Dokument, Qualitätspolitik |
| Rollen & Verantwortung (A.5.2/5.3) | ✅ | QM-Handbuch Kap. 6, CODEOWNERS |
| Lieferanten (A.5.19–5.22) | ⚠️ | OpenAI: AVV + Transfer-Mechanismus erforderlich, wenn KI aktiv (DSGVO 4.3) |
| Schwachstellen-Meldung (A.5.7) | ✅ | SECURITY.md (Coordinated Disclosure) |
| Umgang mit Vorfällen (A.5.24–5.28) | ✅ | CAPA als Vorfall-/Korrekturprozess |
| Aufbewahrung/Löschung (A.5.33/5.34) | ✅ | AUFBEWAHRUNG, scripts/prune-data.mjs |
| A.6 Personell | Status | Umsetzung / Nachweis |
|---|
| Verhaltensregeln (A.6.x) | ✅ | CODE_OF_CONDUCT.md, CONTRIBUTING.md |
| A.7 Physisch | Status | Umsetzung / Nachweis |
|---|
| Endgeräte/Gemeinschafts-PCs (A.7.x) | ⚠️ | organisatorisch beim Haus: Browserprofile/Abmeldung (DSGVO 4.5) |
| A.8 Technologisch | Status | Umsetzung / Nachweis |
|---|
| Zugriffskontrolle (A.8.2/8.3/8.5) | ✅ | Admin-API token-geschützt (timingSafeEqual), Dotfile-Sperre |
| Kryptografie/Transport (A.8.24) | ✅ | TLS + HSTS (nginx), IP nur als SHA-256-Hash |
| Sichere Entwicklung (A.8.25–8.29) | ✅ | Code-Review (CONTRIBUTING.md), automatisierte Tests, CI |
| Härtung/Konfiguration (A.8.9) | ✅ | CSP, Security-Header, CORS-Allowlist (CORS_ALLOWED_ORIGINS) |
| Schadbegrenzung Eingaben (A.8.x) | ✅ | Input-Limit (2 MB), JSON-Schema-Antworten, Anonymisierungs-Block |
| Schutz vor Überlastung (A.8.6) | ✅ | Rate-Limit 8/min (KI) bzw. 30/min (/api), Verbindungslimit |
| Schwachstellenmanagement (A.8.8) | ✅ | npm audit im Security-Workflow, Abhängigkeits-Review |
| Protokollierung (A.8.15) | ⚠️ | console.error + Reverse-Proxy-Logs; strukturiertes Logging optional |
| Backup (A.8.13) | ⚠️ | Repo via Git remote; server/data/ & Kataloge: Backup beim Haus festzulegen |
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
Risikomanagement · CAPA · SECURITY.md · server/aop-newkis.conf (nginx-Härtung)