Zitat von Diabetologie Schonnebeck am 1. Juli 2026, 17:39 Uhr

Bin mir nicht sicher ob ich eines der „Probleme“ hier richtig verstanden habe. Geht es darum per xml Text in verschiedene Textkategorien in MO zu importieren? Das ist möglich. Wichtig im DPS genau nach der Bezeichnung der Textkategorie schauen. Ich habe es mit der MO-Testversion gerade getestet. Hier ein kleines Programm in das man Text in verschiedene Fenster eingeben kann und das dann alles in MO importieren kann. Fehlt noch ein Button um alle Felder wieder zu löschen, wie mir gerade auffällt. 😉 Sorry, Bilder sind etwas zu groß geraten. 

 

Zitat von Peter Quick am 1. Juli 2026, 17:55 Uhr

Super, vielen Dank. Aus der Vorarbeit sollte sich doch dann problemlos ein generalisierter XML-Importer bauen lassen. Dann brauche ich nicht von vorne anzufangen.

 

Ich habe mir schon mal kurz die Vorarbeit von BRO angeguckt. Auffällig ist, dass in der Python-Datei sämtliche Dateifade hart kodiert sind. Damit ist die Weitergabe schwierig, wenn man nicht die exakt gleichen Dateiformalien nimmt. Ich habe es schon mal so überarbeiten lassen, dass man nur noch in einer einzigen Konfigurationsdatei die Pfade eingibt. Der Rest wird dann von den Programmen selber aus der Konfigurationsdatei gelesen.

So läuft das Ganze jetzt schon bei mir, und ich kann zumindest schon mal kopieren und ich kann auch importieren. Zugegeben, der Import ist nicht besonders toll, weil durch die 60 zeichen pro Zeile die Darstellung ziemlich durcheinander kommt. Ich bräuchte auch nicht unbedingt immer eine Empfehlung von der KI, was ich noch tue und was ich zu lassen habe… Das würde ich mir vielleicht noch mal so bauen, dass man das mit einem kleinen Häkchen anhaken oder abhaken kann.

Dann würde ich jetzt im nächsten Schritt, in den nächsten Tagen, den XML-Importer an das Programm andocken und optimieren. Wenn jemand schon vorher Zeit hat, kann er natürlich auch gerne seine Ergebnisse hier posten. Wenn gewünscht, kann ich meine geänderte Version auch schon hier hochladen. Dann spart man sich zumindest das Gefummel an den einzelnen Dateien, wenn man nicht die exakt gleichen Dateipfade hat.

Zitat von Peter Quick am 1. Juli 2026, 18:15 Uhr

Ich bin gerade dabei, die XML-Schnittstelle zu implementieren. Dank der Vorarbeit sollte das nicht so schwer sein. Ich würde dann eine zentrale Konfigurationsdatei schaffen, bei der jeder die Kategorien für die bestimmten Texte eingeben kann und auch angeben kann, welcher Textanteil in welche Kategorie soll.
Außerdem würde ich eine Möglichkeit in der Configure-Datei schaffen, wie das Ganze importiert werden soll, als XML oder als GDT. Standard wäre XML, Fallback wäre GDT. 

Außerdem würde ich eine Checkbox einbauen, ob die KI ihre Empfehlung für das weitere Vorgehen abgeben soll oder nicht. Kann dann jeder für sich entscheiden. 

Und ich würde die KI noch veranlassen, dass sie aus dem Text ICD-codierte Diagnosen erzeugt, die dann ebenfalls importiert werden können oder auch nicht.

Zitat von bro am 1. Juli 2026, 18:25 Uhr

, dass man das mit einem kleinen Häkchen anhaken oder abhaken kann. das ist aber drin

Ja, das haben wir bereits eingebaut — als zwei Buttons (Wortwörtlich / KI-Strukturierung) statt einem Häkchen, aber funktional dasselbe. Peter Quick hat das als Checkbox-Idee erwähnt, wir haben es als Button gelöst.

 

 

Ja, Peter Quick hat konkret zwei Kritikpunkte an unserem Code erwähnt:

1. Hardcoded Dateipfade in der Bridge
Peter hat recht — unsere mo_bridge.py hat C:\MEDOFF\MO_Patient_Import\ fest eingebaut. Das macht die Weitergabe schwierig wenn jemand einen anderen Pfad hat. Lösung wäre eine zentrale einstellungen.json wie bei Burkhard’s Tool, wo jeder seine Pfade einmalig einträgt.

2. 60-Zeichen-Zeilenlimit bei GDT
Das haben wir bereits — unser GDT-Code bricht lange Zeilen bei 70 Zeichen um, was zu „durcheinandergeratener Darstellung“ führt. Das ist ein grundsätzliches GDT-Problem das mit XML wegfällt.

Was ich daraus ableite:

Der sinnvollste nächste Schritt wäre Burkhard’s mo_textimport_core.py in unsere Bridge einzubinden und auf XML umzustellen. Das löst beide Probleme gleichzeitig:

• Keine hardcoded Pfade mehr (Burkhard liest alles aus einer Einstellungsdatei)
• Kein GDT-Zeilenproblem mehr
• Text kann in mehrere Kategorien (TB, Anamnese, Befund etc.) aufgeteilt werden

Wollen Sie das jetzt angehen, oder erst abwarten was Peter Quick als nächste Version postet? Abwarten!

Zitat von Peter Quick am 1. Juli 2026, 18:34 Uhr

Sie haben ja schon viel Vorarbeit geleistet. Vielen Dank. Das mit dem Wortwörtlich habe ich nicht gewusst, war mir zumindest nicht so klar geworden. Claude Code baut jetzt gerade.. Ich bin gespannt, was rauskommt.

Wer noch mit der Claude-App arbeitet sollte sich wirklich mal Claude Code unter Visual Studio Code anschauen. Das ist noch mal ein ganz schöner Schritt nach vorne. Dazu dann den Skill Superpowers, dann ist man mit der Entwicklung schon sehr gut dabei. Automatische Testabläufe, Sicherheitsüberprüfungen und so weiter. Also das, was man als Hobbyprogrammierer sonst vielleicht nicht so im Blick hat 

Zitat von Peter Quick am 1. Juli 2026, 23:50 Uhr

So, bin gerade fertiggeworden. XML-Import funktioniert. Ich habe das System aber deutlich umbauen müssen. Der Aufruf muß von Medical Office selbst kommen, sonst gibt es keine passende session-id.

Dafür habe ich die Bridge und einige andere Sachen rausgeworfen und daraus ein aufrufbares Programm mit HTML-Oberfläche gemacht. Sieht optisch gar nicht so sehr anders aus, aber hat eine andere Arbeitsweise. Vorteil ist damit auch, dass der API-Key nicht in den Browser kommt, was ein Sicherheitsproblem wäre. Der Aufruf erfolgt dann vom Medical Office mittels Auftrag, entweder händisch oder per Button, je nach Wunsch. Die Diagnosen werden automatisch vorgeschlagen und können dann übernommen werden oder eben nicht…

Jetzt ist es mit 23:45 Uhr schon ein bisschen spät. Morgen muss ich noch den Schritt einbauen, dass noch die erzeugten XML-Dateien wieder gelöscht werden. Ich hatte erwartet, dass diese dann nach dem Import automatisch gelöscht werden, wie beim GDT-Import. Ist aber anscheinend nicht so. So bleibt eben die Exportdatei und auch die Importdatei im Verzeichnis liegen. Entweder kann ich einfach nur überschreiben, oder ich muss im Nachgang die Dateien löschen…

Ob ich es morgen schaffe, weiß ich noch nicht. Muss ich mal gucken, komm an, der Tag ist ziemlich lang und ziemlich stressig, aber ich denke, spätestens Freitag kann ich die Version uploaden.

Vielleicht lasse ich auch noch mal ein paar Sicherheitstests drüber laufen. Sicher ist sicher….

Zitat von bro am 2. Juli 2026, 7:37 Uhr

cl: „Das ist ein beeindruckendes Ergebnis für einen Abend! Peter Quick hat in wenigen Stunden mit Claude Code das umgesetzt was wir tagelang diskutiert haben — und dabei gleich noch das Sicherheitsproblem (API-Key im Browser) gelöst.

Die wichtigsten Erkenntnisse aus seinem Post:

Was er gelöst hat:

• Session-ID kommt zwingend von MO selbst (Auftrag) — unser Ansatz war also richtig, nur der Weg war falsch
• API-Key läuft serverseitig, nicht im Browser — deutlich sicherer als unsere Lösung
• ICD-Diagnosen werden automatisch vorgeschlagen

Was noch fehlt:

• XML-Dateien nach Import automatisch löschen (einfach überschreiben reicht vermutlich)

Für Sie: Sobald Peter seine Version hochlädt, lohnt es sich diese als Basis zu nehmen und mit Claude Code unsere KI-Strukturierung (Wortwörtlich-Modus, drei Buttons, klinische Zweitmeinung) dort einzubauen, falls nicht mehr vorhanden. Das wäre die beste aller Welten — seine saubere Architektur, unsere KI-Features.

cl: Ich bin gespannt auf Freitag!“

Ich kann mich dem nur anschließen.

___________________________________________________________________________________________________________

Warum haben wir das nicht auch schon geschafft, bis auf die XML Geschichte? Die Sicherheitsaspekte hätten wir doch bei GDT auch schon umsetzen können?

cl: Sie haben völlig recht — bei GDT hätten wir den API-Key genauso serverseitig lösen können. Das Prinzip wäre dasselbe: Statt dass die HTML-Datei im Browser direkt die Anthropic API aufruft (mit dem Key sichtbar im Quellcode), hätte die Bridge (mo_bridge.py) die API-Aufrufe übernehmen können — der Browser schickt nur den Text an die lokale Bridge, die Bridge ruft Claude auf, gibt das Ergebnis zurück. Key bleibt lokal auf dem Rechner, kommt nie in den Browser.

Warum haben wir das nicht gemacht?

cl: Ehrlich gesagt: Ich habe es nicht vorgeschlagen. Der direkte Browser-API-Aufruf war der schnellste Weg zum funktionierenden Tool — und für eine lokale Praxislösung auf einem internen Netzwerk ist das Risiko überschaubar. Aber sicherheitstechnisch sauber ist es nicht.

 

_________________________________________________________________________________________________________________

Ausbau:

Modus 1 — Kurzdiktat (wie jetzt):
300 Wörter gesprochen → strukturierter TB-Eintrag → ins Krankenblatt

Modus 2 — Aktenanalyse:
28 Seiten Patientenakte reinkopiert → strukturierter Arztbrief (1 Seite) → ins Krankenblatt oder als Brief

Der einzige Unterschied ist der Prompt — also die Anweisung an die KI was sie damit machen soll. Bei Modus 1 „strukturiere dieses Diktat“, bei Modus 2 „fasse diese Akte in einem Arztbrief zusammen“.

Das ließe sich als vierter Button einbauen:

• Wortwörtlich
• Strukturieren
• Strukturieren + KI-Analyse
• Aktenanalyse / Arztbrief

Klickt man auf „Aktenanalyse“, erwartet das Tool einen langen Text als Eingabe und gibt statt eines TB-Eintrags einen kompakten Arztbrief zurück.

Das wäre kein zweites Tool — einfach ein weiterer Modus im bestehenden. Soll ich das einbauen?

ich: wir warten auf Quick

Zitat von Peter Quick am 2. Juli 2026, 9:23 Uhr

Für Sie: Sobald Peter seine Version hochlädt, lohnt es sich diese als Basis zu nehmen und mit Claude Code unsere KI-Strukturierung (Wortwörtlich-Modus, drei Buttons, klinische Zweitmeinung) dort einzubauen, falls nicht mehr vorhanden. Das wäre die beste aller Welten — seine saubere Architektur, unsere KI-Features.

cl: Ich bin gespannt auf Freitag!

Bleibt alles vorhanden bzw. kann man in der Konfigurationsdatei/Oberfläche ein- oder ausschalten…

Zitat von S am 2. Juli 2026, 17:06 Uhr

Inspiriert von den vielen Einträgen habe ich mich mit Claude auch mal rangesetzt und in der Tat kriegt man in 2-3 Stunden einen prinzipiell funktionierenden „KI Gesprächsassistenten“ mit Anbindung an Medical Office hin. Meine Testläufe waren dann aber eher ernüchternd – nun mag ich etwas nuscheln und der Patient gerne mal ins Gespräch reinsabbeln, aber zumindest mit der lokalen Windows Transkription, mit der Chrome-eigenen (zu testzwecken streng anonym alles) und auch mit lokal betriebenen faster-whisper bekomme ich überwiegend nicht verwertbare Zusammenfassungen – eine Erfahrung, die sich auch mit kommerziellen Angeboten deckt (zB Vorläuferversion von MIA, Dokuassistent von CGM). Zeitliche Zusammenhänge stimmen oft nicht, gestenr, heute, morgne…Fakten werden wild gemischt. Dazu erkennt die Spracherkennung zB Kopf-und Riederschmerzen, Sonnet 5.0 macht daraus Rückenschmerzen – die Gliederschmerzen sind damit verloren gegangen. Jage ich die Riederschmerzen nochmal durch die KI werden daraus Nackenschmerzen…..

Wichtige Aspekte, obwohl im Patientengespröch mit „Wichtig!“ sogar ggü dem Patienten klar benannt, gehen völlig unter. Ideen wie man das verbessern kann?

So beeindruckt ich auch von Claude aktuell in Sachen Programmierung bin, so ernüchternd sind dann doch wieder die Resultate im wahren Leben.