AI Product Prototype

Medical Coding Copilot

Ich prototypisierte einen AI-Assistenten für die Erfassung und Verarbeitung verrechenbarer medizinischer Leistungen mit agentischem Workflow über Fallkontext, Berichte, Tarifdaten und deterministische Validierung.

Rolle: Product Engineering, AI-Workflow-Design, Prototyp-Umsetzung
Ergebnis: Der Prototyp prägte einen produktionsorientierten Weg, bei dem AI Discovery und Reasoning unterstützt, während Menschen entscheiden und deterministische Validatoren Korrektheit erzwingen.

Workflow: Human in the loop
Output: strukturierte Vorschläge
Validierung: deterministische Grenze

Problem

Tarifrelevante Informationen liegen selten an einem sauberen Ort. Sie können über Berichte, Verlaufsnotizen, Diagnosen, Termine und frühere Fälle desselben Patienten verteilt sein.

Heute passiert ein großer Teil der Suche, Gegenprüfung und Interpretation dieses Kontexts im Kopf der Person, die Leistungen erfasst.

Der vorhandene Validator prüft bereits, ob erfasste Leistungen technisch gültig sind. Das ist wichtig, löst aber nur den nachgelagerten Teil des Workflows: Sobald eine Leistung eingegeben wurde, kann sie validiert werden.

Die schwierigere vorgelagerte Frage ist, ob das System tarifrelevante Evidenz in der Patientenreise erkennen kann, bevor die Nutzerin oder der Nutzer alle Punkte manuell verbunden hat.

Es kostet Zeit, den relevanten Kontext vor der Leistungserfassung zusammenzutragen.
Plausible verrechenbare Leistungen können übersehen oder zu spät erkannt werden.
Nutzerinnen und Nutzer brauchen Unterstützung bei Discovery und Interpretation, ohne Verrechnungsentscheidungen in opake Automatisierung zu verschieben.

Produktthese

Die nützlichste AI-Erfahrung ist hier kein generischer Chatbot. Sie ist ein kontrollierter Vorschlagsworkflow.

Der Assistent soll relevanten Fallkontext sammeln, ihn in den passenden Tarif- und Suchraum übersetzen, Leistungskandidaten vorschlagen, Evidenz anzeigen und die Entscheidung bei der Nutzerin oder beim Nutzer lassen.

Validierung bleibt dadurch deterministisch und auditierbar, statt in einer Modellantwort versteckt zu werden. Kurz gesagt: AI für Discovery und Reasoning Support nutzen, nicht als ungeprüfte Verrechnungsinstanz.

AI-gestützter Leistungsvorschlag Der Assistent verbindet verteilten Kontext mit Tarif-Skills und liefert einen prüfbaren Vorschlag, statt direkt eine Leistung zu erfassen.


                          flowchart TD
    documents[Berichte, Verlaufsnotizen, Diagnosen] --> context[Gemeinsamer Fallkontext]
    activity[Termine und vorhandene Leistungssessions] --> context

    context --> skills[Tarif- und Domain-Skills]
    skills --> loop[Agentischer Vorschlagsloop]
    loop --> suggestion[Prüfbarer Leistungsvorschlag]

    suggestion --> decision{Entscheidung}
    decision -->|Akzeptieren| create[One-click Leistungserstellung]
    decision -->|Ablehnen oder bearbeiten| review[Manueller Review]

    create --> validation[Deterministische Validierung]
    validation --> service[Erfasste verrechenbare Leistung]
    review --> validation

Technische Struktur

Der Prototyp wurde um eine einfache Grenze herum gestaltet: probabilistische AI darf Kandidaten finden und erklären, aber deterministische Applikationslogik bleibt für Validierung und Persistenz verantwortlich.

Strukturierte Ausgabe behandelte ich als Produktanforderung, nicht nur als Implementierungsdetail. Ein Vorschlag muss maschinenlesbar genug für UI und Validator sein, aber klar genug für den Review durch Domain-Expertinnen und -Experten.

Agentischer Vorschlagsloop Schwache Kandidaten können verfeinert werden, bevor der Assistent einen strukturierten Vorschlag für den Review zurückgibt.


                          flowchart TD
    start[Nutzerfrage oder Vorschlagslauf] --> scope[Coding-Aufgabe definieren]
    scope --> gather[Multi-source Fallkontext sammeln]
    gather --> extract[Tarifrelevante Hinweise extrahieren]
    extract --> map[Hinweise auf aktivierte Skills mappen]
    map --> search[Tarif- und Regelraum durchsuchen]
    search --> candidates[Leistungskandidaten generieren]
    candidates --> evidence[Evidenz und Annahmen anhängen]
    evidence --> score[Plausibilität und Confidence bewerten]

    score --> decision{Genug Evidenz?}
    decision -->|Nein| refine[Query oder Kontext verfeinern]
    refine --> search

    decision -->|Ja| output[Strukturierter Vorschlag]
    output --> user[User Review]
    user --> validation[Deterministische Validierung]

Vorschlagsvertrag Der Assistent liefert ein maschinenlesbares Objekt, das die UI anzeigen und der Validator verarbeiten kann.

{
  "candidateService": {
    "code": "TARIFF_CODE",
    "label": "Human-readable service name"
  },
  "confidence": 0.82,
  "evidence": [
    {
      "sourceType": "report | note | appointment | diagnosis | service-session",
      "summary": "Why this source supports the suggestion"
    }
  ],
  "assumptions": ["Context that should be checked by the user"],
  "missingInformation": ["Information needed before safe acceptance"],
  "recommendedAction": "accept | review | reject"
}

Strukturiertes Feld	Zweck
candidateService	Code und lesbares Label der vorgeschlagenen Leistung
confidence	Plausibilitätssignal für Review und Priorisierung
evidence	Quellenzusammenfassungen, warum der Kandidat unterstützt wird
assumptions	Kontext, den die Nutzerin oder der Nutzer explizit prüfen sollte
missingInformation	Offene Informationen, die vor sicherer Annahme fehlen
recommendedAction	Accept-, Review- oder Reject-Empfehlung für die UI

Context Assembly sammelt relevante Informationen aus Falldokumentation, Terminen, Diagnosen und bestehenden Leistungsdaten.
Die Skill-Schicht grenzt die Aufgabe auf den passenden Tarif-, Sprach- und Domain-Suchraum ein.
Der agentische Loop sucht, schlägt vor, prüft Evidenz, verfeinert schwache Kandidaten und liefert strukturierte Ausgabe.
Die Review UI zeigt Vorschlag, Confidence, Evidenz und Annahmen, bevor eine Nutzerin oder ein Nutzer handelt.
Die Validierungsgrenze prüft akzeptierte Vorschläge mit deterministischen Geschäfts- und Tarifregeln vor der Erfassung.

Was ich gebaut habe

Ich baute einen Prototyp für einen Medical Coding Copilot mit zwei Interaktionsmodi: Freitextfragen zu Fall, Tariflogik oder möglichen Leistungen und einen agentischen Vorschlagsloop, der aktiv nach verrechenbaren Leistungskandidaten sucht.

Der Assistent arbeitet über einem gemeinsamen Multi-case-Kontext, der Berichte, Verlaufsnotizen, Diagnosen, Termine und vorhandene Leistungssessions enthalten kann. Darauf aufbauend können Skills für bestimmte Tarif- oder Wissensdomains aktiviert werden, etwa TARDOC oder zukünftige sprach- und mandantenspezifische Regelräume.

Jeder Vorschlag wird als prüfbares Objekt behandelt, nicht als lose Textantwort.

Welche Leistung könnte relevant sein?
Welche klinischen Hinweise stützen sie?
Woher kommt die Evidenz?
Welche Annahmen wurden getroffen?
Wie sicher ist der Assistent?
Welche Validierung oder menschliche Prüfung ist noch nötig?

Warum Validierung wichtig ist

Medical Coding ist kein Ort für opake Automatisierung. Ein plausibler Vorschlag muss weiterhin Domain-Regeln, Tarifgrenzen und professionellen Review überstehen.

Diese Trennung macht den Assistenten sicherer, einfacher zu debuggen und leichter gegenüber nicht-technischen Stakeholdern erklärbar.

Der Assistent findet und erklärt mögliche Leistungen.
Die Nutzerin oder der Nutzer entscheidet, ob der Vorschlag sinnvoll ist.
Der Validator prüft technische und tarifliche Korrektheit.
Das Produkt hält die Evidenzkette sichtbar.

Potenzielle Wirkung

Der Prototyp zielt auf Effizienz und Vollständigkeit.

Auf der Effizienzseite reduziert er den manuellen Aufwand für Suche, Gegenlesen und Übersetzen klinischer Informationen in Verrechnungslogik. Auf der Ertragsseite kann vollständigere Leistungserfassung Teams helfen, plausible Leistungen früher und konsistenter zu erkennen.

Eine zukünftige Produktionsversion könnte Vorschläge proaktiv ausführen, aber nur als auditierbare Entwürfe mit sichtbarer Evidenz und deterministischer Validierung.

Zeit bis zur Leistungserfassung
Akzeptanzrate von Vorschlägen
Ablehnungs- und Korrekturrate
Leistungen, die nach erster Dokumentation identifiziert wurden
Validierungsfehler nach One-click-Erstellung
Lücke zwischen dokumentierter Arbeit und erfassten Leistungen

Skalierbarkeit

Der Kernworkflow ist über klinische Umgebungen hinweg wiederverwendbar, weil Dokumentation verteilt ist, Coding-Expertise spezialisiert bleibt und Leistungserfassung korrekt und erklärbar sein muss. Die Skill-basierte Architektur lässt Tariflogik, Sprache, Mandantenkonfiguration und domainspezifische Suche variieren, ohne den grundlegenden Assistenten-Workflow zu verändern.

Die wichtigste Grenze ist Dokumentationsqualität: unvollständige oder vage klinische Notizen reduzieren die Verlässlichkeit von Vorschlägen. Gleichzeitig ist das ein nützliches Produktsignal, weil schwache Vorschläge Dokumentationslücken sichtbar machen können, die Teams upstream beheben möchten.

Was das über meine Arbeit zeigt

Interessant an diesem Projekt war, dass der Wert nicht darin lag, AI Text schreiben zu lassen. Der Wert lag darin, einen Workflow um eine reibungsreiche Entscheidung zu formen: Was soll erfasst werden, warum, und wie kann das System diese Entscheidung leichter prüfbar machen?

Ich übersetze uneindeutige Domain-Probleme in konkrete Produktflows.
Ich gestalte AI-Features rund um Kontext, Evidenz, Validierung und User Control.
Ich verbinde technische Machbarkeit mit UX und geschäftlichem Wert.
Ich baue Prototypen, die über eine Demo hinaus nützlich sind und eine Produktionsumsetzung informieren können.

Ergebnis

Der Medical Coding Copilot zeigte einen praktischen Weg, klinische Dokumentation mit verrechenbarer Leistungserfassung zu verbinden. Statt blinde Automatisierung in einen sensiblen Workflow zu drücken, nutzt der Prototyp AI, um Evidenz sichtbar zu machen, Aktionen vorzuschlagen und Validierung deterministisch zu halten.

Die Kernidee ist einfach: Wenn relevante Evidenz bereits in der Dokumentation existiert, sollte das Produkt Nutzerinnen und Nutzer dabei unterstützen, sie zu finden, zu bewerten und in eine validierte Leistung zu überführen, ohne die ganze Patientenreise jedes Mal manuell rekonstruieren zu müssen.

Wichtige Kennzahlen