Regeln für die Zahlen. Sprache für den Rest.
Ein generisches, MDR-konformes System, das TDM-Befunde entwirft: eine deterministische Regel-Engine verantwortet jede Zahl und jeden Sicherheits-Schwellenwert, ein LLM schreibt die Interpretation, und eine ärztliche Fachperson zeichnet jeden Befund ab.
Direkt auf dem Proof-of-Concept von medicalvalues aufgebaut
Eine Entscheidung trägt das gesamte Design
Der Proof-of-Concept hat gezeigt, wie genau LLMs im TDM scheitern — falscher Steady-State, oszillierende Bereiche, halluzinierte Zahlen. Also gehen die Zahlen an Regeln, die Prosa an das Modell, die Unterschrift an einen Menschen.
Strikte Trennung Regel / LLM
Ist eine Ausgabe vollständig durch die Eingaben plus eine zitierbare Regel bestimmt, wird sie deterministisch berechnet. Nur Synthese, Narrativ und Lückensuche gehen an das LLM — und jede LLM-Aussage ist in einer zitierten Quelle geerdet.
Generische Engine, Wirkstoff-Module
Die Engine ist wirkstoffunabhängig; Bereiche, Halbwertszeiten und Interaktionen liegen in versionierten Wirkstoff-Modulen. Engine einmal validieren, dann jedes Modul vor Freischaltung qualifizieren.
Enge Zweckbestimmung
Das System erzeugt einen Entwurf, den eine qualifizierte Fachperson prüft und abzeichnet. Es informiert die Entscheidung; es trifft sie nie. Das hält das Produkt unter MDR beherrschbar.
AI Act & DSGVO by design
Wir behandeln es als Hochrisiko-KI-System. Nachverfolgbares Logging und eine On-Premise-Option für Gesundheitsdaten (DSGVO) sind von Tag eins eingebaut.
Eine TDM-Interpretation ist nicht „der Wert ist X“
Die Interpretation — nicht die Zahl — ist das Ergebnis, und sie läuft in fester Reihenfolge. Ich nutze diese Reihenfolge, um zu trennen, was eine Regel berechnen muss von dem, was ein LLM formulieren darf.
Die Reihenfolge, die ich nutze
- Zuerst die Pharmakokinetik klären — Steady-State und Tal vs. Peak. deterministisch · Regel
- Gegen den einen kanonischen Referenzbereich klassifizieren: niedrig · therapeutisch · erhöht · toxisch. deterministisch · Regel
- Über Ursachen & Kontext nachdenken — Adhärenz, Organfunktion, Interaktionen, Metabolisierer-Status. interpretativ · LLM, menschlich bestätigt
Sie bedingen jede nachgelagerte Bewertung — und genau hier stolperten die Modelle des PoC. Deshalb werden sie deterministisch berechnet, bevor ein Wort geschrieben wird.
Ich behandle Adler et al., Tabelle 1 als die zu reverse-engineernde Ausgabe-Spezifikation, nicht als etwas neu Herzuleitendes (siehe §03).
Der Proof-of-Concept ist unsere Spezifikation
Adler et al. bewerteten eigenständige GPT-4o und Gemini 2.0 Flash an 10 fiktiven TDM-Fällen (kuratiertes RAG, CLEAR-Framework): strukturiert, aber nur „durchschnittlich“ (12–18 / 25). Die Studie zeigte, wo sie scheitern — und jedes Versagen wird zur Designregel. Vorbehalt, den ich nenne: n = 10, ein Bewerter — hypothesengenerierend, nicht bestätigend.
CLEAR-Scores nach Kategorie (Skala 1–5)
Größte Lücken: Vollständigkeit und keine Falschinformation — genau das, was ein deterministischer Kern und Vollständigkeitsprüfungen schützen.
Beobachtetes Versagen → Designantwort
| Zahlen falsch behandelt — Levetiracetam Steady-State & Talspiegel falsch eingeschätzt | → deterministische Regeln |
| Widersprüchliche RAG-Quellen — 43 mg/L als normal und erhöht gelesen | → eine kanonische Quelle |
| Variation von Lauf zu Lauf — Vorbehalte variieren je Lauf | → Template + Checks |
| Halluzinationsrisiko | → Provenienz + Freigabe |
Wie ich den medizinischen Workflow herleite
Den Befund reverse-engineeren, den das Labor ohnehin erstellt, jeden Schwellenwert in einer zitierbaren Quelle verankern und Deterministisches vom Interpretativen trennen. Die Reihenfolge: Eingang → Berechnung → Klassifikation → Interpretation → Prüfung → Unterschrift.
Quellen
- Bestehende Befundstrukturen
- Leitlinien: AGNP, DEGAM S1 (AWMF)
- Fachinformationen, PSIAC, CYP/P-gp-Referenzen
- Experten-Think-Aloud an realen Fällen
- Labor- / LIS-Prozesse & Datenlücken
Stakeholder
- Klinische Pharmakolog:innen (Autoren)
- Behandelnde Ärzt:innen (Nutzer)
- Laborwissenschaftler:innen / LIS-Verantwortliche
- Qualität & Regulatory + Sicherheitsbeauftragte:r
- Software- / ML-Engineers
Validierung
- Nachverfolgbarkeit: Schwellenwert ↔ Quelle
- Experten-erstellter Gold-Fallsatz
- Regeln: ~100 % exakt auf Gold-Set
- LLM: CLEAR + Halluzinationsrate, ≥2 Reviewer
- Klinische Bewertung + Usability (IEC 62366-1)
Workflow-Anatomie — die Teile, nach denen die Aufgabe fragt
Patient:in (Alter/Geschlecht/Gewicht, Nieren- & Leberfunktion), Wirkstoff + Dosis + Schema, Messwert + Einheit, Metabolit/MPR falls vorhanden, Probenzeitpunkt, Datum der letzten Dosisänderung, letzte Einnahme, Komedikationen, Komorbiditäten.
Ein abgezeichneter TDM-Befund: deterministisches Faktenblatt, Interpretations-Narrativ mit Zitaten, gerankte Ursachen, Monitoring-Vorschläge, markierte Unsicherheit & fehlende Daten — plus vollständiges Audit-Log.
Kritisches Feld fehlt? · Steady-State erreicht? · Tal vs. Peak? · im / außerhalb des Bereichs? · toxisch? · Retrieval-Konfidenz ausreichend?
Nicht unterstützter Wirkstoff → manueller Pfad. Fehlendes kritisches Datum → konditionaler Befund + Anforderung. Unplausibler Wert → markieren, nicht interpretieren. Geringe Retrieval-Konfidenz → „nicht bewertbar“.
Toxischer / kritischer Spiegel → dringende ärztliche Eskalation, Befund markiert. Geringe Konfidenz oder Abweichung von der Standardempfehlung → Oberärztl. Pharmakologie, beschleunigte Prüfung.
Entwirft einen TDM-Befund, den eine qualifizierte Fachperson prüft, bearbeitet und abzeichnet. Es informiert; es entscheidet oder veröffentlicht nie selbst. (Klasse IIa, Human-in-the-Loop.)
Im Umfang: Interpretation einer gemessenen Konzentration im Kontext. Außerhalb: Anforderung des Tests, Verordnung, Ausgabe einer Dosis als Anordnung, jeder Fall ohne Messwert.
Der Trennungs-Test
Eine Frage entscheidet, wo jedes Reasoning-Element liegt: ist die Ausgabe vollständig durch die Eingaben plus eine feste, zitierbare Regel bestimmt?
Standardisieren
Eingabeschema · alle deterministischen Berechnungen · Befundstruktur · verpflichtende Sicherheitsvorbehalte · Klassifikationssprache · Eskalationsauslöser. Variabilität ist hier ein Defekt.
Der ärztlichen Person überlassen
Die finale Dosisentscheidung · patientenspezifische Gewichtung der Ursachen · Integration in das vollständige klinische Bild · jede Abweichung von der Standardempfehlung (mit Begründung). Die ärztliche Person zeichnet ab; das System nie.
Wie es medizinisch validiert wird
Zwei Spuren. Deterministischer Teil: Unit-Tests gegen das Gold-Set — exakte Übereinstimmung bei Schwellenwerten, Klassifikation, Steady-State, Flags. Interpretativer Teil: verblindetes CLEAR- + Halluzinationsraten-Scoring durch ≥2 Pharmakolog:innen, plus Usability und klinische Bewertung. Jeder Schwellenwert ist auf seine Quelle nachverfolgbar; der vollständige V&V- und Monitoring-Stack ist in §08.
Prototyp-Workflow — live
Antiepileptika-Monitoring (Levetiracetam), verankert in AGNP & Patsalos. Der Ablauf ist wirkstoffunabhängig; das Modul liefert die Zahlen — Eingaben ändern und das Faktenblatt rechnet neu.
Wichtigste Eingabedaten (nach Adler et al.)
Der Workflow
Latenz: Regel-Engine + Faktenblatt < ~50 ms (sync) · Retrieval ~100–400 ms · LLM-Synthese + Schutzprüfung ~2–8 s (async). Der Toxizitäts-Fast-Path feuert auf dem synchronen Rückgrat, unabhängig vom LLM.
Regel-Engine-Demo
Design des LLM-Agenten
Der Agent ist die Sprach- und Syntheseschicht über einem deterministischen Rückgrat. Er verfasst, erklärt und markiert — er ist nie der Rechner, der Klassifikator oder der Entscheider.
Herleitung der Agenten-Rolle
Die Rolle ergibt sich aus fünf Treibern.
Befunde sind langsam & wissensschwer → den Entwurf automatisieren, nicht die Entscheidung.
Ausgabe muss der Standard-Befundstruktur entsprechen → eingeschränkte, templatebasierte Generierung.
Experten klären zuerst den PK-Zustand, dann das Reasoning → Regeln zuerst; LLM erst nach dem Faktenblatt.
Strukturierter Fall + kuratierte Wissensbasis → retrieval-geerdet, kein freies Erinnern.
Halluzination & Zahlenfehler sind die Versagensmodi des PoC → keine Zahlen vom LLM, Provenienz + Freigabe.
Was er darf · nicht darf · wo ein Mensch verpflichtend ist
| Erlaubt — LLM | Nicht erlaubt — muss Regel sein | Verpflichtende menschl. Prüfung |
|---|---|---|
| Narrativ aus dem Faktenblatt entwerfen | Steady-State-Bestimmung | Jeder Befund |
| Reasoning in klinischer Prosa erklären | Tal vs. Peak; Bereichs-Klassifikation | Jedes toxische / kritische Flag |
| Ursachen für Werte außerhalb des Bereichs aufzählen | Toxizitäts-Schwellen & Sicherheits-Flags | Jedes fehlende kritische Datum |
| Fehlende / mehrdeutige Eingaben identifizieren | MPR-Berechnung; Interaktionserkennung | Jede Abweichung von Standardempf. |
| Monitoring-Hinweise als Vorschläge formulieren | Einheiten-Umrechnung | Jeder Fall mit geringer Retrieval-Konfidenz |
| Abgerufenes Wissen mit Zitaten zusammenfassen | alles Numerische / Schwellen — die Versagenszone des PoC | Nichts wird automatisch freigegeben |
Wissensquellen identifizieren & auswählen
Die Wissensbasis ist kuratiert und geschlossen — nicht das offene Web. Auswahlkriterien: Autorität (Leitliniengremium, Fachinfo, peer-reviewed), Jurisdiktion (Deutschland / EU), Aktualität & Version und Abdeckung des aktiven Wirkstoff-Moduls — jede Quelle getaggt mit Autorität, Version, Jurisdiktion und Gültigkeitsdatum.
RAG aus medizinischer Experten-Sicht
Der entscheidende Schritt: Konfliktauflösung ist vorab entschieden. Für jeden Parameter gibt es eine kanonische Quelle, sodass der Agent nicht oszillieren kann.
Jeder abgerufene Fakt zeigt seine Provenienz; numerische Aussagen sind im Faktenblatt geerdet, nicht in abgerufener Prosa; fehlendes Wissen ergibt „nicht bewertbar“, keine Vermutung; geringe Retrieval-Konfidenz eskaliert an einen Menschen.
Der RAG-Konflikt — und die Lösung
Ein Levetiracetam-Talspiegel von 43 mg/L:
Human-in-the-Loop
Entwürfe erscheinen asynchron in einer priorisierten Reviewer-Worklist (toxisch/kritisch zuerst). Die prüfende Person sieht das Faktenblatt (mit Provenienz), den LLM-Entwurf (mit Zitaten & markierter Unsicherheit), die Liste fehlender Infos und alle Alarme; sie bearbeitet, bestätigt Sicherheits-Flags und zeichnet ab. Routine → eine prüfende Person; toxisch / geringe Konfidenz → Oberärztl., beschleunigt. Edits werden zu Trainings- & Eval-Daten.
Evaluation & Monitoring nach Deployment
Jeder Fall durchgängig geloggt. Tracking der Edit-Rate (Proxy für Entwurfsqualität), Überschreibungen von Sicherheits-Flags, Halluzinations-Vorfälle, Retrieval-Konfidenz und Drift. Periodisches Re-Scoring gegen Goldstandard, striktes Change-Control. Der vollständige Assurance-Stack ist in §08.
Der Agent, Schritt für Schritt
Acht Schritte (Levetiracetam-Instanz). Die Regel-Engine läuft zuerst und erzeugt das Faktenblatt; das LLM ist immer nachgelagert — und läuft asynchron, nie im blockierenden Pfad der ärztlichen Person.
Implementierungs-Blueprint — eine portable Referenz-Agentenarchitektur
Dasselbe Agenten-Design als framework-unabhängiges Projekt: ein Orchestrator, der an Sub-Agenten delegiert, provider-unabhängige JSON-Tool-Schemas, wiederverwendbare Skills, RAG über eine kuratierte Wissensbasis und Multi-Provider-Modell-Routing. Es bildet auf das Claude Agent SDK, LangGraph oder das OpenAI Agents SDK ab — nur die Bindings ändern sich.
Warum nicht „überall Agenten“
Multi-Agenten-Systeme können rund 15× so viele Tokens kosten wie ein einzelner Chat (publizierte Multi-Agenten-Benchmarks) und helfen nur, wenn die Arbeit wirklich parallel ist. Deshalb ist der sequentielle klinische Kern ein einzelner abgesicherter Agent; Sub-Agenten sind der parallelen Retrieval-Breite und der Offline-Evaluation vorbehalten. Komplexität wird nur dort ergänzt, wo sie ihre Kosten verdient.
Evaluation & Assurance — der Nachweis, dass das System funktioniert
Vertrauen entsteht durch einen geschichteten Assurance-Stack: deterministische Tests, RAG-Metriken, Agenten-/Orchestrator-Checks, ein gegen Menschen kalibrierter LLM-Judge, Guardrails und Live-Monitoring — jeweils auf MDR / IEC 62304 / AI-Act-Verifikation abgebildet.
Der Assurance-Stack
Unit- + Integrationstests führen das Gold-Set durch die Regel-Engine und prüfen exakte Übereinstimmung bei Schwellenwerten, Klassifikation, Steady-State, Tal/Peak und jedem Sicherheits-Flag — alles unter ~100 % blockiert den Build.
RAGAS bewertet Retrieval + Erdung: Faithfulness (Anti-Halluzination), Context Precision & Recall, Context-Entity-Recall, Response Relevancy und Noise Sensitivity. Faithfulness ist ein hartes Freigabe-Gate bei ≥0,90 — eine unbelegte numerische Aussage in einem TDM-Befund kann eine falsche Dosis auslösen, die Kosten einer Falschaussage sind klinisch, nicht kosmetisch.
Über den finalen Text hinaus: Tool-Call-Accuracy + F1 (richtiges Tool, richtige Argumente, richtige Reihenfolge), Agent-Goal-Accuracy (wurde das Ziel erreicht) und Topic Adherence (im TDM-Umfang geblieben). End-State und Trajektorie werden bewertet, denn ein Agent kann über einen unsicheren Pfad richtig liegen.
Ein LLM-Judge bewertet jeden Entwurf nach dem CLEAR-Raster (G-Eval-Stil) gegen den Referenzbefund. Er ist gegen ≥2 menschliche Pharmakolog:innen kalibriert, nutzt eine andere Modellfamilie als der Verfasser (begrenzt Selbstbevorzugung) und randomisiert die Reihenfolge gegen Positions-Bias. Der Judge ergänzt die menschliche Prüfung; er ersetzt nie die Freigabe.
Guardrail-Unit-Tests (jede Zahl gegen das Faktenblatt, jede Aussage gegen ein Zitat geprüft), Groundedness-/Halluzinations-Detektion, Eskalations-Tests (ein toxischer Spiegel muss die Freigabe immer blockieren) und adversariale / Red-Team-Prompts (Prompt-Injection, Out-of-Scope-Anfragen).
Jeder Fall wird durchgängig getract. Wir tracken Edit-Rate (Proxy für Entwurfsqualität), Override-Rate von Sicherheits-Flags, Retrieval-Konfidenz, Entwurfs-Latenz p50/p95, Eskalations-SLA-Einhaltung und Score-Drift; ein 20 %-Live-Sample wird mit RAGAS re-bewertet. Nach einem Alarm rollen wir auf die letzte validierte Konfiguration zurück, erweitern das Gold-Set oder re-kalibrieren den Judge — unter Change-Control; die ≥2-Menschen-Judge-Re-Kalibrierung läuft quartalsweise. Kein stilles Modell-/Prompt-/Modul-Update.
RAGAS-Metrik-Explorer
Die Metriken, gegen die wir gaten, was jede misst, und das Ziel für einen TDM-Befund in klinischer Qualität.
Tool-Call-Verifikation — wurden die richtigen Tools wirklich aufgerufen?
Der Tool-Trace jedes Laufs wird gegen den Referenz-Trace geprüft (konform vs. fehlerhaft unten). Dieselbe Prüfung läuft online bei jedem Produktivfall: ein Lauf, der vom Tool-Vertrag abweicht — falsches Tool/Args/Reihenfolge oder ein fehlender Pflichtaufruf wie interaction_check — wird aus der Worklist blockiert und an einen Menschen geleitet.
Erwarteter (Referenz-)Trace
Tatsächlicher Trace
Freigabe-/Readiness-Gates (illustrativ)
Bereitschaft für interne Tests ist ein grünes Board. Eine einzelne Regression — eine Metrik unter Ziel — blockiert die Freigabe; eine steigende, aber bestehende Metrik (Amber) löst eine Prüfung aus.
Der Faden zurück zur MDR: dieser Stack ist die Software-Verifikation & -Validierung (IEC 62304), der AI-Act-Nachweis für Genauigkeit/Robustheit (Art. 15), die klinischen Leistungsdaten (MDCG 2020-1) und der Post-Market-Plan (Art. 72) — ein Assurance-System für die Medizinprodukte-Akte und das Engineering-Vertrauen zugleich.
Pragmatisch unter Regulierung
Die Zweckbestimmung ist der größte Hebel. Das Produkt so fassen, dass es informiert, und einen Menschen im Loop halten — dann bleibt die regulatorische und Validierungslast beherrschbar.
MDR-Klassen-Explorer
Das IMDRF-Signifikanz-Framework (übernommen in MDCG 2019-11) bildet ab: was die Ausgabe bewirkt × wie ernst die Situation ist. Die Selektoren ändern:
(IMDRF-Raster)
Der Text von MDR-Regel 11 stuft Entscheidungsunterstützungs-Software per Default als Klasse IIa ein. Wir nehmen IIa als konservative Basis und halten den Human-in-the-Loop, sodass das Produkt nur informiert — ein Modul mit engem therapeutischem Index in kritischer Umgebung kann in seiner eigenen Risiko-Akte Richtung IIb neu bewertet werden.
Der deutsche + EU-Regulierungs-Stack
MDR — Reg. (EU) 2017/745
Regel 11: Entscheidungsunterstützungs-Software ist Klasse IIa (→ IIb/III je nach Schadensschwere). Klasse IIa+ ⇒ Konformitätsbewertung durch Benannte Stelle.
MPDG (national)
Das Medizinprodukterecht-Durchführungsgesetz flankiert die unmittelbar geltende MDR — Behörden, Sprache, Verfahren klinischer Prüfungen, Sanktionen. Es ersetzte das MPG.
BfArM — zuständige Behörde
Die Bundesoberbehörde für Medizinprodukte (DIMDI wurde 2020 ins BfArM überführt).
Klinische Bewertung (MDR Anhang XIV)
Bei begrenzten Daten: ein Äquivalenz-/Literatur-Weg, gestützt auf Gold-Set-Performance + den PoC, mit Eskalation zu einer fokussierten klinischen Prüfung (ISO 14155) nur dort, wo die Literaturlücke es erfordert.
Keine DiGA
Der DiGA-Fast-Track (DVG/DiGAV, §139e SGB V) gilt für patientenseitige Apps. Ein ärztlich genutztes TDM-Tool bleibt schlicht CE-gekennzeichnetes SaMD — die DiGA-Tür ist die falsche.
EU AI Act — Reg. (EU) 2024/1689
SaMD mit Benannter Stelle ⇒ Hochrisiko über Art. 6(1) + Anhang I. Pflichten ab 2. Aug. 2027; der Digital Omnibus (vorläufig, Mai 2026) verschiebt produkt-eingebettetes Hochrisiko auf 2. Aug. 2028.
DSGVO / BDSG + §203 StGB
Wirkstoffspiegel sind besondere Gesundheitsdaten (Art. 9). Drittlandtransfer + Schweigepflicht drängen zu EU-gehosteter / On-Premise- / lokaler Modellverarbeitung — unsere Routing-Policy.
Benannte Stellen (DE)
TÜV SÜD, TÜV Rheinland, DEKRA, mdc — deutsche Benannte Stellen integrieren AI-Act-Erwartungen bereits in MDR-Prüfungen, also designen wir jetzt für beides.
MDCG 2019-11 Rev.1 (2025)
Die Revision von Juni 2025 der Leitlinie zur Software-Qualifizierung/-Klassifizierung deckt jetzt explizit KI, modulare Software und EHR-Interoperabilität ab.
EU AI Act — die Pflichten
Als Hochrisiko-KI-System trägt das Produkt: Risikomanagement (Art. 9), Daten-Governance (Art. 10), technische Dokumentation (Art. 11), Logging (Art. 12), Transparenz (Art. 13), menschliche Aufsicht (Art. 14) — unser Prüf-und-Unterschreib-Schritt — Genauigkeit/Robustheit/Cybersicherheit (Art. 15) und Post-Market-Monitoring (Art. 72). Diese überschneiden sich stark mit MDR/ISO 13485/14971 — einmal designen, für beide nachweisen.
Normen, gegen die wir entwickeln
HITL + enge Zweckbestimmung sind die zentralen Risikokontrollen in der ISO-14971-Akte: „falscher Steady-State → falsche Interpretation“ wird durch deterministische Berechnung, Provenienz, die Schutzprüfung und ärztliche Freigabe gemindert.
Entwicklungsphasen & Readiness-Gates
Discovery & Spec
Erhebung, Befund-Reverse-Engineering, Zweckbestimmungs- & Risiko-Akte, Gold-Fallsatz.
Deterministischer Kern
Regel-Engine + erstes Wirkstoff-Modul.
Gate: ~100% auf GoldLLM + RAG + Guardrail
Kuratierte KB, geerdete Generierung, Output-Verifizierer.
Gate: CLEAR + FaithfulnessInterne Validierung
End-to-End auf Gold-Set, ≥2 Pharmakolog:innen, Usability.
Shadow-Mode-Pilot
System entwirft; Experten vergleichen mit eigenen Befunden.
Gate: Edit-Rate / SicherheitKonformität & Release
Dann Modul-für-Modul-Erweiterung.
Gate: Neu-Modul-Qual.Die Abwägungen balancieren
Enge Zweckbestimmung
Senkt die Klasse, verkleinert die Validierungsfläche, beschleunigt den Weg — und erhöht die Sicherheit. Der größte Einzelhebel.
Trennung Regel / LLM
Schnell beim risikoarmen Narrativ; der sicherheitskritische Kern ist deterministisch, testbar, beweisbar.
Modulare Architektur
Skalieren ohne Validierungs-Explosion: die Engine einmal validieren, Module inkrementell qualifizieren.
Nicht zuerst fine-tunen
Context Engineering + Function Calling + geerdetes RAG + Guardrails. Fine-Tuning & lokale Modelle (MedGemma, Meditron) sind ein Phase-2-Hebel für Performance & On-Premise-Datenschutz.
HITL als Enabler
Sicherheitskontrolle, regulatorischer Enabler (hält es bei „informierend“ → IIa) und eine Daten-Engine über erfasste Edits.
Was wir eintauschen
Weniger Automatisierung und engere Abdeckung jetzt — im Tausch gegen Sicherheit, Tempo und Validierbarkeit. Vorab-Kuration zahlt auf Validierung und Monitoring ein.