künstliche intelligenz (KI) – Planungen MO/Integration? – Seite 9 – MEDICAL OFFICE Forum

#81 · 30. September 2026, 21:44

Die (behördlichen?) Vorgaben sind, dass bestimmte Daten nicht automatisch befüllt werden dürfen. Angeblich soll dies sicherstellen, dass die Datenqualität hoch/höher ist. Früher konnte man einfach das alte Formular wiederholen und es wurde automatisch z.B. der HbA1c und RR aktualisiert. Jetzt muss man bestimmte Daten immer wieder neu eingeben, z.B. Raucherstatus bei COPD, jedoch bei T2DM darf es „automatisch wiederholt“ werden.

Daten wie Medikamente werden nicht erkannt. Hier muss man auch unterscheiden z.B. Inhalativa bei Bedarf oder fest etc. – eigentlich kein Hexenwerk.

Aktuell öffne ich den alten DMP Bogen (PDF gespeichert), öffne den Bogen und orientiere mich an dem alten Bogen.

#82 · 30. September 2026, 21:48

Kostet Programmierzeit, die nicht abgezweigt werden kann.

#83 · 30. September 2026, 22:39

wenn mal eine erklären würde, wie man list&label anpasst, könnte man mit php formeln die jeweils letzten relevanten werte ziehen (dauerdiagnosen z.B. ) das mache ich im moment, außer dass ich händisch zwischen einem fast vollständig gefüllten q-brief und dem dmp hin und her schalten muss.

letzte Diagnose mit fraktur für Osteoporose? einfach per php in Diagnosen suchen.

aktuelle Medikation? aus BMP auslesen (wenn der gepflegt ist)

…all das geht schon, nur das übertragen ist zeitaufwändig, sinnlos

meine MO – Tricks Übersicht (wird immermal aktualisiert)

#84 · 30. September 2026, 23:27

Zitat von Peter Quick am 30. September 2026, 23:27 Uhr
Vieles von dem könnte man sicherlich problemlos mit Python Scripts selbst lösen. Um alte Werte aus einem vorhandenen Formular oder der DB auszulesen brauche ich ja keine KI…

Das einzige Problem, was ich für mich hätte, wäre jetzt das Befüllen und Abspeichern des neuen Formulars… könnte man aber vielleicht damit lösen, indem man das List und Label Formular für sich selbst anpasst. Damit hab ich nur keine Erfahrung, es könnte aber sein, dass man so etwas mit Claude zusammen abändern kann.

dann könnte zum Beispiel ein Ablauf so aussehen wie mit dem Dashboard, was der Kollege schon mal hier angerissen hat. Beim Aufruf des Patienten werden alle Daten exportiert und in eine Datei geschrieben. Und aus der Datei entnehme ich dann mittels Python Skript, das, was ich brauche, und trage das dann mit zum Beispiel PHP in das neue Formular ein… dann wäre all das ausgefüllt, was man schon mal hatte… abspeichern, fertig..

dann bräuchte man noch nicht einmal lesend auf die Maria Datenbank zuzugreifen.

ja, wäre natürlich viel einfacher, wenn Indamed das selbst machen würde. Die wissen ja, wo alles liegt… aber ich sage mal so, wenn ich im Quartal mehrere 100 dieser Bögen ausfüllen müsste, dann würde ich mir jetzt einen Weg suchen, mir das selber zu programmieren… Ganz DSGVO konform ohne KI, nur auf dem Rechner

Kurzer Gedankenaustausch mit Gemini zur Machbarkeit meiner Idee oben:

Das ist ein hervorragender und absolut machbarer Lösungsansatz! Da Sie den XML-Export von Medical Office nutzen können, umgehen Sie das Problem, dass List & Label nicht direkt mit einer Datenbank oder einer API sprechen kann.

Die Kette Medical Office (XML) ➔ Python (Verarbeitung & TXT) ➔ List & Label funktioniert in der Praxis sehr zuverlässig.

So setzen Sie die beiden entscheidenden Schritte technisch um:

1. Schritt: Python-Skript (Erstellung der TXT)

Damit List & Label die Daten später im Designer einfach auslesen kann, sollte Ihr Python-Skript die Daten am besten zeilenweise oder im klassischen Schlüssel=Wert-Format (wie eine .ini-Datei) in die Textdatei schreiben.

Beispiel für das Format der erzeugten patient_daten.txt:
Vorname=Max
Nachname=Mustermann
Zusatzfeld1=WertA
Zusatzfeld2=WertB
2. Schritt: List & Label Formular anpassen

Im List & Label Designer von Medical Office können Sie nun über die integrierten Formelfunktionen direkt auf diese Textdatei zugreifen. Es ist keine Programmierung in Medical Office selbst notwendig.

Nutzen Sie dafür die Funktion GetIniValue(). Diese liest gezielt Werte aus einer strukturierten Textdatei aus.

Syntax: GetIniValue("Sektion", "Schlüssel", "Standardwert", "Dateiname")

Wenn Sie im Python-Skript (wie oben gezeigt) keine Sektionen verwenden, bleibt der erste Parameter leer.

So binden Sie es in ein Textfeld im Designer ein:
Öffnen Sie das Formular im Designer.

Fügen Sie ein neues Textobjekt ein oder bearbeiten Sie ein bestehendes.
Tragen Sie folgende Formel ein (passen Sie den Pfad an):
GetIniValue("", "Zusatzfeld1", "Fehlt", "C:\MedicalOffice\Schnittstelle\patient_daten.txt")
List & Label schaut nun bei jedem Druck/Vorschau in die Datei, sucht nach Zusatzfeld1= und gibt den dahinterstehenden Wert (WertA) aus.
Wichtige Praxistipps für diesen Workflow:

Timing des Aufrufs: Da Medical Office die XML-Datei beim Aufruf des Patienten schreibt, muss Ihr Python-Skript (z. B. als Hintergrunddienst/Watchdog, der den Ordner überwacht) die TXT-Datei vor dem Klick auf „Drucken“ bereits aktualisiert haben.

Dateipfade: Nutzen Sie für die TXT-Datei am besten einen lokalen Pfad auf dem jeweiligen Client-PC (z. B. unter C:\Caches\), damit sich die Daten verschiedener Arbeitsplätze in der Praxis nicht gegenseitig überschreiben, wenn zwei MFA gleichzeitig unterschiedliche Patienten geöffnet haben.

Möchten Sie Unterstützung bei dem Python-Skript, das die XML-Datei ausliest und in das TXT-Format konvertiert, oder benötigen Sie Hilfe bei der Strukturierung des XML-Inhalts von Medical Office?

Vieles von dem könnte man sicherlich problemlos mit Python Scripts selbst lösen. Um alte Werte aus einem vorhandenen Formular oder der DB auszulesen brauche ich ja keine KI…

Das einzige Problem, was ich für mich hätte, wäre jetzt das Befüllen und Abspeichern des neuen Formulars… könnte man aber vielleicht damit lösen, indem man das List und Label Formular für sich selbst anpasst. Damit hab ich nur keine Erfahrung, es könnte aber sein, dass man so etwas mit Claude zusammen abändern kann.

dann könnte zum Beispiel ein Ablauf so aussehen wie mit dem Dashboard, was der Kollege schon mal hier angerissen hat. Beim Aufruf des Patienten werden alle Daten exportiert und in eine Datei geschrieben. Und aus der Datei entnehme ich dann mittels Python Skript, das, was ich brauche, und trage das dann mit zum Beispiel PHP in das neue Formular ein… dann wäre all das ausgefüllt, was man schon mal hatte… abspeichern, fertig..

dann bräuchte man noch nicht einmal lesend auf die Maria Datenbank zuzugreifen.

ja, wäre natürlich viel einfacher, wenn Indamed das selbst machen würde. Die wissen ja, wo alles liegt… aber ich sage mal so, wenn ich im Quartal mehrere 100 dieser Bögen ausfüllen müsste, dann würde ich mir jetzt einen Weg suchen, mir das selber zu programmieren… Ganz DSGVO konform ohne KI, nur auf dem Rechner

Kurzer Gedankenaustausch mit Gemini zur Machbarkeit meiner Idee oben:

Das ist ein hervorragender und absolut machbarer Lösungsansatz! Da Sie den XML-Export von Medical Office nutzen können, umgehen Sie das Problem, dass List & Label nicht direkt mit einer Datenbank oder einer API sprechen kann.

Die Kette Medical Office (XML) ➔ Python (Verarbeitung & TXT) ➔ List & Label funktioniert in der Praxis sehr zuverlässig.

So setzen Sie die beiden entscheidenden Schritte technisch um:

1. Schritt: Python-Skript (Erstellung der TXT)

Damit List & Label die Daten später im Designer einfach auslesen kann, sollte Ihr Python-Skript die Daten am besten zeilenweise oder im klassischen Schlüssel=Wert-Format (wie eine .ini-Datei) in die Textdatei schreiben.

Beispiel für das Format der erzeugten patient_daten.txt:

Vorname=Max
Nachname=Mustermann
Zusatzfeld1=WertA
Zusatzfeld2=WertB

2. Schritt: List & Label Formular anpassen

Im List & Label Designer von Medical Office können Sie nun über die integrierten Formelfunktionen direkt auf diese Textdatei zugreifen. Es ist keine Programmierung in Medical Office selbst notwendig.

Nutzen Sie dafür die Funktion GetIniValue(). Diese liest gezielt Werte aus einer strukturierten Textdatei aus.

Syntax: GetIniValue("Sektion", "Schlüssel", "Standardwert", "Dateiname")
Wenn Sie im Python-Skript (wie oben gezeigt) keine Sektionen verwenden, bleibt der erste Parameter leer.

So binden Sie es in ein Textfeld im Designer ein:

Öffnen Sie das Formular im Designer.
Fügen Sie ein neues Textobjekt ein oder bearbeiten Sie ein bestehendes.

Tragen Sie folgende Formel ein (passen Sie den Pfad an):

GetIniValue("", "Zusatzfeld1", "Fehlt", "C:\MedicalOffice\Schnittstelle\patient_daten.txt")

List & Label schaut nun bei jedem Druck/Vorschau in die Datei, sucht nach Zusatzfeld1= und gibt den dahinterstehenden Wert (WertA) aus.

Wichtige Praxistipps für diesen Workflow:

Timing des Aufrufs: Da Medical Office die XML-Datei beim Aufruf des Patienten schreibt, muss Ihr Python-Skript (z. B. als Hintergrunddienst/Watchdog, der den Ordner überwacht) die TXT-Datei vor dem Klick auf „Drucken“ bereits aktualisiert haben.
Dateipfade: Nutzen Sie für die TXT-Datei am besten einen lokalen Pfad auf dem jeweiligen Client-PC (z. B. unter C:\Caches\), damit sich die Daten verschiedener Arbeitsplätze in der Praxis nicht gegenseitig überschreiben, wenn zwei MFA gleichzeitig unterschiedliche Patienten geöffnet haben.

Möchten Sie Unterstützung bei dem Python-Skript, das die XML-Datei ausliest und in das TXT-Format konvertiert, oder benötigen Sie Hilfe bei der Strukturierung des XML-Inhalts von Medical Office?

#85 · 1. Oktober 2026, 1:41

Also wenn ich als Patient mitkriegen würde, dass ein Gespräch mit dem Arzt oder auch nur meine Befunde an eine womöglich US-amerikanische Online KI/Spracherkennung/Cloud weitergeleitet wird, erwäge ich eine Strafanzeige (§ 201/203 StGB)

Sorry – wenn KI dann auf einem extra Rechner der ins Internet darf und keinen Zugriff auf die Praxisdaten hat.

Privacy

#86 · 1. Oktober 2026, 10:27

Zitat von bro am 1. Oktober 2026, 10:27 Uhr
Wenn man das auf die Spitze treibt, hat Privacy einen Punkt. So gesehen, können wir eine wirklich sinnvolle Arbeitserleichterung für uns Ärzte durch eine KI vergessen, egal wo die sitzt. Halbe KI nach dem Motto „Wasch mich, aber mach mich nicht nass“, macht keinen Sinn

Anonymisierung: Die Person ist nicht mehr identifizierbar, auch nicht mit Zusatzwissen. Dann gilt die DSGVO nicht mehr. Bei Gutachten ist das praktisch nicht erreichbar, weil Unfallhergang, Beruf, Medikation und Verlauf zusammen einen Menschen erkennbar machen.
Pseudonymisierung: Namen und Stammdaten werden durch Platzhalter ersetzt, die Zuordnung bleibt bei in der Praxis. Das senkt das Risiko, die Daten bleiben aber rechtlich personenbezogen. Die Anforderungen des Datenschutzes und der Schweigepflicht entfallen damit nicht.
Warum beides bei Gutachten/Fragebogen nicht trägt: Je vollständiger der Fall, desto besser das Gutachten/Fragebogen, aber desto eher ist der Patient erkennbar. Eine Anonymisierung, die den Fall unkenntlich macht, nimmt dem Gutachten den Sinn.

Rechtlich ist eine Einwilligung des Pat. zur KI‑Verwendung wohl nicht zwingend, praktisch ist sie die einfachste Absicherung. Ein Satz im Formular zur Schweigepflichtentbindung („Zur Erstellung kann ein datenschutzkonformer KI-Dienst in Deutschland unterstützen“) genügt, kostet nichts ….

… und gibt jedem Patienten das Opt-out, das wir vorhin besprochen haben. Ohne diesen Satz bleibt ein Restrisiko, mit ihm ist das Thema für die Praxis erledigt,

denn der Patient wird in der Mehrzahl nein sagen.

Bisschen KI ist keine KI.

Das ist „bisschen KI“, was ich bisher mache, wenig komfortabl, KI könnte mehr.

Kein Upload: Keine PDFs, Scans, Screenshots oder Berichte hochladen, auch nicht geschwärzt.

OCR lokal: Texterkennung nur auf dem eigenen Rechner, nicht über Online-Dienste.

Reintext-Abschrift: Erkannten Text in einem einfachen Editor öffnen (keine Metadaten) und als eingefügten Text in den Chat kopieren.

Identifikatoren entfernen: Namen, Initialen, Alter/Geburtsdatum, alle Datumsangaben, Orte, Praxis-/Klinik-/Arztnamen, Aktenzeichen, Kontaktdaten.

Zeitangaben neutralisieren: Platzhalter verwenden und in der fertigen Antwort selbst einsetzen.

Seltene Details weglassen: Nur das eingeben, was für die Antwort nötig ist. (nic für aufwendige Gutachten)

Ein Chat pro Fall: Nichts aus früheren Chats mitführen, Memory-Funktion aus.

Sauberer Zugang: Training mit Eingaben ausschalten (Team schließt meine Daten standardmäßig vom Training aus) und Team-Zugang mit Auftragsverarbeitungsvertrag (ist da mit drin, sicher nicht so, wie der deutsche Gesetzgeber das möchte)

Wenn man das auf die Spitze treibt, hat Privacy einen Punkt. So gesehen, können wir eine wirklich sinnvolle Arbeitserleichterung für uns Ärzte durch eine KI vergessen, egal wo die sitzt. Halbe KI nach dem Motto „Wasch mich, aber mach mich nicht nass“, macht keinen Sinn

Anonymisierung: Die Person ist nicht mehr identifizierbar, auch nicht mit Zusatzwissen. Dann gilt die DSGVO nicht mehr. Bei Gutachten ist das praktisch nicht erreichbar, weil Unfallhergang, Beruf, Medikation und Verlauf zusammen einen Menschen erkennbar machen.
Pseudonymisierung: Namen und Stammdaten werden durch Platzhalter ersetzt, die Zuordnung bleibt bei in der Praxis. Das senkt das Risiko, die Daten bleiben aber rechtlich personenbezogen. Die Anforderungen des Datenschutzes und der Schweigepflicht entfallen damit nicht.
Warum beides bei Gutachten/Fragebogen nicht trägt: Je vollständiger der Fall, desto besser das Gutachten/Fragebogen, aber desto eher ist der Patient erkennbar. Eine Anonymisierung, die den Fall unkenntlich macht, nimmt dem Gutachten den Sinn.

Rechtlich ist eine Einwilligung des Pat. zur KI‑Verwendung wohl nicht zwingend, praktisch ist sie die einfachste Absicherung. Ein Satz im Formular zur Schweigepflichtentbindung („Zur Erstellung kann ein datenschutzkonformer KI-Dienst in Deutschland unterstützen“) genügt, kostet nichts ….

… und gibt jedem Patienten das Opt-out, das wir vorhin besprochen haben. Ohne diesen Satz bleibt ein Restrisiko, mit ihm ist das Thema für die Praxis erledigt,

denn der Patient wird in der Mehrzahl nein sagen.

Bisschen KI ist keine KI.

Das ist „bisschen KI“, was ich bisher mache, wenig komfortabl, KI könnte mehr.

Kein Upload: Keine PDFs, Scans, Screenshots oder Berichte hochladen, auch nicht geschwärzt.
OCR lokal: Texterkennung nur auf dem eigenen Rechner, nicht über Online-Dienste.
Reintext-Abschrift: Erkannten Text in einem einfachen Editor öffnen (keine Metadaten) und als eingefügten Text in den Chat kopieren.
Identifikatoren entfernen: Namen, Initialen, Alter/Geburtsdatum, alle Datumsangaben, Orte, Praxis-/Klinik-/Arztnamen, Aktenzeichen, Kontaktdaten.
Zeitangaben neutralisieren: Platzhalter verwenden und in der fertigen Antwort selbst einsetzen.
Seltene Details weglassen: Nur das eingeben, was für die Antwort nötig ist. (nic für aufwendige Gutachten)
Ein Chat pro Fall: Nichts aus früheren Chats mitführen, Memory-Funktion aus.
Sauberer Zugang: Training mit Eingaben ausschalten (Team schließt meine Daten standardmäßig vom Training aus) und Team-Zugang mit Auftragsverarbeitungsvertrag (ist da mit drin, sicher nicht so, wie der deutsche Gesetzgeber das möchte)

#87 · 1. Oktober 2026, 10:45

Aus meiner Sicht hat Privacy hier einen „halben“ Punkt. Ja, im Fall einer „offenen“ Ki ausserhalb Europa/ Deutschland. „Jein“ vermutlich bei einer spezialisierten, zertifizierten KI im DSGVO Raum. Das bedarf sicherlich einer Betrachtung des Begriffes „Geheimnisses“ auf das sich hier bezogen wird.

Ich glaube nicht, dass sich das Problem mit einer Einwilligung des Patienten lösen lässt.

#88 · 1. Oktober 2026, 12:16

Abseits von direkten Patientendaten finde ich sehr spannend, daß Mistral.ai jetzt ZDR (Zero data retention) bietet. Kann man zum Beispiel für Geschäftsdokumente sehr gut nutzen.

https://docs.mistral.ai/admin/monitor-comply/zero-data-retention

Alle Daten, die per API übergeben werden, werden direkt nach der Antwort wieder gelöscht, ebenso wie die Anfrage selbst. Trainingsdaten werden ebenso nicht gespeichert bei Pay-as-you-go-Kunden. Damit gibt es eine gute europäische Alternative zu den US-Cloud-Anbietern… die ich für mich z.B. für Finanzdaten gerne nutze.

#89 · 1. Oktober 2026, 12:45

IMHO verwächst sich das, wie bei allen technischen Neuerungen der letzten 300 Jahre. Und wer heute von seinem HA verlangt das er mit dem Pferdefuhrwerk oder mit dem Rad zu Hausbesuch eilt, ist erstens noch nicht im heute angekommen und wird diese Wünsche, wie Alles, in Euro honorieren müssen. Und der Doktor, der über jedes Stöckchen hüpft was ihm von Patienten, KV/GKV und Politikern hingehalten wird, braucht einen guten Seelenklmpner oder eine Frühbestattung.

Privacy und bro haben auf diesen Beitrag reagiert.

#90 · 1. Oktober 2026, 12:53

MISTRAL
diese Europäische Superrakete habe ich auch mal getestet und die Ergebnisse ware qualitativ nicht mit den anderen Anbietern konkurrenzfähig, obwohl die rein technischen Daten dazu Hoffnung gaben.