Teil 2 wegen 12000 Zeichen Limit im Forum
Highlight 1: Kapazitäts- und Auslastungsanalyse des Terminplans
Dieser Abschnitt beschreibt eine Analyse, die über Standard-KPIs hinausgeht. Die Bausteine dafür sind im Download enthalten.
Eine der überraschendsten Erkenntnisse betrifft die Frage: Wie ausgelastet sind unsere Therapeuten wirklich? tomedo bietet dafür bisher keine eingebaute Auswertung — und das Datenmodell dahinter ist nicht trivial.
Das Ressourcen-Prinzip in tomedo
tomedo arbeitet im Terminkalender mit einem Gegenspieler-Prinzip: Ein Termin gibt Kapazität frei, ein anderer belegt sie.
Das Feld terminart.infotermin steuert die Unterscheidung:
infotermin = true → Kapazitätsblock (definiert verfügbare Therapiezeit)infotermin = false → Patiententermin (belegt diese Zeit)
Viele Terminarten existieren als Paar mit gleichem Kürzel aber unterschiedlichem Flag — z.B. AP als Ressource UND als buchbarer Termin. Die Ressource sagt "hier sind 30 Minuten verfügbar", der Patiententermin sagt "diese 30 Minuten sind jetzt gebucht".
Auslastungsformel
Daraus ergibt sich eine saubere Formel:
Kapazität = Summe Dauer aller infotermin=true (exkl. Doku, Pausen, Besprechungen)
Sperrzeiten = Urlaub, Feiertage, Blocker (Terminarten UNBEKANNT, Blocker, Urlaub etc.)
Netto-Kapaziät = Kapazität − Sperrzeiten
Belegung = Summe Dauer aller infotermin=false mit patient_ident IS NOT NULL
Auslastung = Belegung / Netto-Kapazität × 100
Besonderheit Gruppentherapie: tomedo erlaubt keine echten parallelen Buchungen über die Terminsuche. Für Gruppentermine wird ein Workaround verwendet: Die Terminart wird auf 1 Minute Länge gesetzt, die Ressource gibt exakt so viele Minuten frei wie Teilnehmerplätze vorhanden sind (z.B. 12 min = 12 Slots). Durch geschickte Rundung erhalten alle Teilnehmer eine Einladung für dieselbe Uhrzeit. Das bedeutet: Auslastung >100% in Raumkalendern ist systembedingt und korrekt.
Warum das relevant ist
Damit lassen sich Fragen beantworten, die bisher nur aus dem Bauchgefühl kamen: Haben wir noch Kapazität für neue Patienten? Welcher Therapeut ist überlastet? Wie viel Zeit geht für Besprechungen und Dokumentation drauf? Die Query-Bausteine §17 und §18 im Download enthalten die vollständige Logik.
Highlight 2: Patientenformulare als Datenquelle
Das ist unsere zweite große Entdeckung — und soweit wir wissen, bisher nirgends dokumentiert.
Wer über tomedo Web-Formulare an Patienten verschickt (arzt-direct Patientenformulare), hat eine strukturierte Datenquelle, die direkt per SQL abfragbar ist — ohne dass ein Karteirückschrieb existieren muss.
Der Datenpfad
angefordertesjsonformular (Versand-Request, mit patient_ident!)
→ angefordertesjsonformular_formulare (Bridge)
→ karteieintrag (dtype='Formular', KE-Typ FOR)
→ karteieintrag_formularelemente (Bridge)
→ formularelement (bezeichner = Feldname, wert = Patientenantwort)
Der Clou: Die Tabelle formularelement enthält die Patientenantworten mit sprechenden Feldnamen im Feld bezeichner und den Werten in wert. Wer z.B. einen Quartalfragebogen verschickt, kann per SQL direkt abfragen: Wie hoch ist der durchschnittliche NRS-Wert meiner Neupatienten? Wie verändert sich der von-Korff-Grad über die Quartale?
Warum das wichtig ist
Die meisten Praxen verschicken bereits Patientenformulare — Erstanamnesen, Quartalfragebögen, Verlaufsfragebögen. Diese Daten liegen strukturiert in der Datenbank, werden aber typischerweise nur als PDF in der Kartei angezeigt. Per HQL-Statistik kann man sie aggregieren, Verläufe berechnen und mit anderen Daten (Segmentierung, Diagnosen, Therapiedauer) verknüpfen.
Einschränkung: Die Feldbezeichner sind versionsabhängig — bei neuen Formularversionen können sich die Namen ändern. Es lohnt sich, die aktuellen Bezeichner einmal explorativ abzufragen (die KI hilft dabei).
Das vollständige Datenmodell inkl. der Formular-Tabellen ist im Download enthalten.
FYI: Für tomedo-Spezialisten
Die folgenden Abschnitte richten sich an Leute, die tief in die HQL-Statistik einsteigen wollen. Der erste erklärt, wie das Datenmodell entstanden ist. Der zweite listet technische Stolperfallen.
Wie wir an das Datenmodell gekommen sind
Das größte Hindernis bei tomedo HQL-Statistik ist nicht SQL — es ist die Frage: Welche Tabellen gibt es, wie heißen die Felder, und wie hängt alles zusammen? Es gibt keine offizielle Dokumentation des Datenmodells.
Unser Ansatz war Reverse Engineering, und der Startpunkt waren die Hersteller-Queries als Rosetta Stone:
- Hersteller-Queries sammeln — Über den tomedo-Support, das Forum und die eingebauten Standard-Statistiken haben wir ~25 fertige Queries zusammengetragen. Diese Queries sind von Zollsoft selbst geschrieben und verwenden die korrekten Tabellen und JOIN-Pfade.
- KI als Analyst — Wir haben diese Queries der KI gegeben mit der Aufgabe: "Analysiere diese Query. Welche Tabellen werden verwendet? Wie sind die JOIN-Pfade? Welche Felder gibt es?" Stück für Stück entstand so eine Tabellen- und Felddokumentation.
- Explorative Validierung — Für jede neue Fragestellung hat die KI zunächst geschaut, ob die bekannten Tabellen und Pfade ausreichen. Wenn nicht, hat sie explorative Queries vorgeschlagen ("Lass uns mal schauen, welche Felder die Tabelle karteieintrag hat"), und wir haben die Ergebnisse zurückgemeldet.
- Inkrementelle Dokumentation — Jede neue Erkenntnis wurde sofort in die Referenzdateien eingetragen: neue Tabelle →
datenmodell.md, neuer JOIN-Pfad → join-pfade.md, neues Pattern → query-bausteine.md. So wurde das Datenmodell mit jeder Session vollständiger. - Skill-Paket als Ergebnis — Nach 8 Sessions hatten wir nicht nur Kennzahlen, sondern ein vollständiges Skill-Paket: Datenmodell (~31 KB), validierte JOIN-Pfade, 27 Query-Bausteine, ZS-Filter-Syntax und eine SKILL.md, die alle kritischen Regeln und Lessons Learned enthält. Dieses Paket ist der Download in diesem Post.
Der entscheidende Punkt: Man braucht kein SQL-Vorwissen. Man braucht die Hersteller-Queries als Ausgangsmaterial — und eine KI, die strukturiert daraus lernen kann. Das Ergebnis (unser Download) macht diesen Schritt für andere Praxen überflüssig.
Hinweis für Zollsoft
Die hier veröffentlichten Dateien basieren ausschließlich auf Reverse Engineering der offiziell verfügbaren HQL-Statistik-Funktion und der von Zollsoft selbst bereitgestellten Beispiel-Queries. Es wurde kein Quellcode eingesehen oder dekompiliert. Wir würden uns freuen, wenn Zollsoft das Datenmodell irgendwann offiziell dokumentiert — das würde den Aufwand für andere Praxen drastisch reduzieren. Bis dahin hoffen wir, dass dieser Beitrag eine nützliche Brücke ist.
Technische Stolperfallen
Diese Punkte sparen jeweils Stunden an Trial-and-Error:
⚠ tomedo HQL kann nur 1 SELECT pro Durchlauf. Das ist die wichtigste Einschränkung für den Workflow. Wenn eine Query mehrere Auswertungen enthält, müsst ihr sie manuell aufteilen. Die KI erzeugt manchmal Multi-SELECT-Queries — dann an der markierten Stelle (-- ============ HIER TRENNEN ============) trennen und separat ausführen.
⚠ ZS-Filter-Tags in Temp-Tables = kaputtes SQL. ZS-Filter sind die parametrisierbaren Eingabefelder in der tomedo-HQL-Oberfläche — Zeitraum-Auswahl, Dropdown-Filter etc. Sie machen Queries wiederverwendbar, besonders für Auto-Statistiken. Aber: ZS-Filter-Tags innerhalb von CREATE TEMPORARY TABLE werden von tomedo komplett entfernt (nicht aufgelöst — gestrichen). Queries immer zuerst ohne ZS-Filter entwickeln, und ZS-Tags nur im finalen SELECT verwenden.
[Screenshot: ZS-Filter-Eingabemaske in tomedo — folgt]
⚠ Temp-Tabellen sterben zwischen Runs. tomedo HQL löscht temporäre Tabellen zwischen Ausführungen. Jede SQL-Datei muss komplett selbstständig sein — alle benötigten Temps neu aufbauen.
⚠ ROUND braucht ::numeric. ROUND(double precision, n) existiert in PostgreSQL nicht: ROUND(wert::numeric, 2) statt ROUND(wert, 2).
⚠ TRIM bei Terminart-Kürzeln. Terminart-Kürzel haben teils trailing Spaces: TRIM(terminart.kuerzel) IN ('AP', 'PHY', ...).
⚠ Jahresscharfer JOIN bei Diagnosen. Der JOIN auf eine Patientenpopulation mit Jahresspalte muss auf Patient UND Jahr erfolgen, sonst werden Diagnosen aus anderen Jahren mitgezählt und man bekommt >100%-Raten.
Fazit
Der eigentliche Durchbruch ist nicht die Technik — es ist die Möglichkeit, als Mediziner menschliche Fragen zu stellen und datengestützte Antworten zu bekommen, ohne erst eine Programmiersprache lernen zu müssen. Die KI ist der Übersetzer zwischen klinischer Intuition und Datenbank.
Das tomedo-Datenmodell ist komplex, aber nicht unzugänglich. Mit den richtigen Referenzdateien und einer KI, die SQL kann und das Datenmodell kennt, lassen sich in überschaubarer Zeit Kennzahlen erheben, die man sonst nur aus teuren BI-Projekten bekommt.
Was uns überrascht hat: Die größten Erkenntnisse kamen nicht aus den Zahlen selbst, sondern aus der Diskrepanz zwischen dem, was wir zu wissen glaubten, und dem, was die Daten zeigten.
Die Dateien sind frei nutzbar. Wenn ihr Verbesserungen habt oder weitere Bausteine ergänzt, teilt sie gerne hier im Forum oder man mich persönlich.
