API Dokumentation für Tomedo

Question

Vor dem Hintergrund einer Verknüpfung mit externen Programmen habe ich die Frage, ob es für Tomedo eine API und dafür eine Beschreibung gibt. Wenn ja kann man mir den Link dafür zur verfügung stellen?

Answer 1

Guten Tag Herr Dr. Klaproth,

wir wollen mit der Herausgabe der API-Dokumentation noch vorsichtig sein, bis wir die initiale Testphase (welche hoffentlich im nächsten Quartal beginnt) überstanden haben.

Wir halten es nicht für unmöglich, dass wir im Laufe dieser noch feststellen, dass wir noch größere Änderungen durchführen müssen. Außerdem fehlen noch wichtige Anteile - zum Beispiel die Authentifizierung.

An sich hören wir aber gerne, was für Anforderungen an die API gestellt werden. Wollen wir hierfür ggf. ein Meeting einrichten? Alternativ können Sie hier natürlich auch grob Ihr vorhaben beschreiben.

Mit freundlichen Grüßen,

Toni Ringling

Comments

Guten Abend Herr Ringling,

herzlichen Dank für die rasche Antwort. Ich befasse mich gerade damit, die Funktionalität von Tomedo mit KI (ChatGPT) zu verknüpfen. Ich kann wesentliche Informationen meiner CKE extrahieren und mit einer dezidierten Fragestellung versehen, an ChatGPT schicken.

Das funktioniert bereits mit selbst gebastelten Aktionsketten voll automatisiert. In dem externen Programm muss ich jedoch händisch per Tastaturbefehl cmd+v die in der Zwischenablage gespeicherte Frage eingeben, anschließend mit einem Mausklick die Antwort kopieren und an gewünschter Stelle in einem bestimmten Variablefeld oder Karteieintrag wieder mit cmd+v einfügen.

Diese Schritte wären alle nicht nötig, wenn die Komunikation automatisiert wäre und die Antwort von ChatGPT automatisch an der richtigen Stelle in Tomedo übrnommen wird.

Auf diesem Wege wäre auch die Auswertung von Anhängen und pdf. Dokumenten im Handumdrehen zu erledigen. Bereits jetzt ist auch das möglich, benötigt aber immer noch unnötige Befehle.

Gern können wir mal ein Meeting vereinbaren, damit ich Ihnen die Schritte demonstrieren kann. Für die Umsetzung meiner persönlichen Wünsche hätte ich Unterstützung im Bekanntenkreis.

---

Dass Zollsoft überhaupt eine API plant ist schon mal ein sehr erfreuliche Nachricht! Für mich persönlich wäre es am wichitgsten, dass es eine Dokumentation über das Handbuchniveau gibt, speziell über die Keypath-Komponenten. Als weiteres würde ich mir eine Möglichkeit wünschen, auf diese Komponenten mit besseren Mitteln "zugreifen" zu können, als tomedo momentan mit den Briefkommendos zur Verfügung stellt. Ganz sicher sind viele dieser Briefkommandos sehr komfortabel zu benutzen (zB das x, l oder d Kommando), aber es ist damit doch eine teils dtl. Einschränkung, zB in CKEs oder CKs da. Sicher, das alles erfordert dann ein gewissen programmiertechnische know-how, VIEL Zeit und Willen zum Einarbeiten. Dennoch ist der aktuelle Stand mMn inzwischen sehr chaotisch geworden und eine "saubere" API wäre wahrsch. auch für Zollsoft intern besser. So wäre ein besserer Zugriff zB mit Python (bisher SEHR rudimentär) oder eine anderen "richtigen" Programmiersprache auf das API top.

Daher begrüße ich ausdrücklich diese Pläne!

---

Guten Tag Herr Dr. Burau,

ein wichtiger Punkt, den ich hier glaube ich noch nennen müsste, wäre, dass es sich hier um eine Web-REST-API handeln wird, welche (über einen Zwischenserver) Endpunkte auf dem tomedo-Server ansteuert. Für eine direkte Kommunikation mit bestimmten Clients gibt es bisher noch kein Konzept. Lediglich zur Beobachtung von Änderungen, sodass man ggf. sofort reagieren könnte.

Mir ist aufgefallen, dass dies glaube ich nie öffentlich erläutert wurde, als ich den Teil zu Programmiersprachen gelesen habe.

Die API basiert auch nicht auf dem tomedo-Datenmodell, sondern auf einem Custom-Modell mit einer Übersetzungsschicht. Da die API am besten längerfristig stabil bleiben soll, würden wir uns ja sonst davon abhalten, ernsthafte Änderungen am Datenbankmodell vorzunehmen.

Mit freundlichen Grüßen,
Toni Ringling

---

Falls eine API in dieser Form ihren Anforderungen nicht genügt, würden wir trotzdem gerne hören, was sie vorgehabt hätten.

Wie gesagt gibt es zwar kein Konzept für die Kommunikation mit bestimmten Clients, aber vollkommen technisch unmöglich klingt das nicht. Eine interessante Frage wäre hier, was genau für Signale man überhaupt austauschen müsste. (Z.B. Text in die Zwischenablage oder das momentan markierte Textfeld einfügen, einen Infotext anzeigen etc.)

---

Ich kann mir vorstellen, dass das Erstellen der (wünschenswerten) tomedo-API ein großes Projekt ist. Für sehr viele Anwendungsfälle, die man mit externen Programmen z.B. in Python außerhalb von tomedo, lösen möchte, wäre die Funktion: "Übernahme der Zwischenablage" in ein CKE-/Customformular-Feld eine vermutlich (?) einfache Lösung. Ein Traum wäre die Aktionskettenbedingung: Auslesen/Überwachen der Zwischenablage auf bestimmte Trigger-Texten hin. 

$[if $[clipboard]$ zs_contains 'Rückschrieb von ChatGPT' '$[clipboard]$']$

Mit dieser simplen Methode könnte ein "Lauscher" über das ClipBoard wachen und bei entsprechenden Trigger-Texten eine AK initiieren, die den Inhalt des Clipboards an verschiedene, vordefinierte Orte verteilen. Das würde es sogar erlauben, durch externe Eingaben von externen Programmen via Clipboard Abläufe in tomedo zu starten/steuern. 

---

Moin Hans Jörg,

Genau das schwebt mir vor. Jetzt sind das 2 Tastaturbefehle, 2 x Enter und Zwei Klicks mehr.

---

Guten Tag,

mit "Beobachten" habe ich hier die serverseitige Beobachtung von Änderungen in der Datenbank gemeint. Die API ist wie beschrieben nicht dafür ausgelegt direkt Aktionen an Clients auszuführen, sondern eher voll im Hintergrund zu arbeiten - zum Beispiel für Onlinekalender, Telefonassistenten, Callcenter, Dashboards, etc..

Bei genügender Anfrage können wir auch schauen, wie gut eine Verknüpfung mit den Clients möglich wäre. Da die Anforderungen jetzt schon auftauchen, würden wir versuchen wollen diese auch frühzeitig aufzusammeln.

@Dr. Burau - sind ihre Wünsche auch gleichartig gestaltet? Es geht darum, ob wir möglicherweise versuchen ein gemeinsames Meeting zu organisieren oder das aufzuspalten. Bzw. wären Sie nicht an einem Meeting zu der Sache interessiert?

@Dr. Baumann - sind Sie auch grundsätzlich an einem Meeting zu der Sache interessiert?

Mit freundlichen Grüßen,

Toni Ringling

---

Ja, gerne.

---

Hallo Herr Ringling,

das sind super Nachrichten. Gibt es schon eine Übersicht welche API Endpunkte verfügbar sein werden ?

Wünschenswert wären aus unserer sicht vor allem (schreibender) Zugriff auf folgende Resourcen:

* Kalender (Terminplanung)
* Schemaverwaltung
* Terminsuche Favoriten
* Termine: erstellen/löschen/ändern
* Patienten: Neuepatienten anlegen
* Urlaubs/Sperrtagsverwaltung
* Karteieinträge erstellen inkl. CKEs und Anhängen
* Wenn möglich: Endpunkt um die arbeitsplatzspezifischen Einstellungen zu überschreiben. Hintergrund: ab einer gewissen Skalierung (mittlere + große Praxen) ist die arbeitsplatzbezogene Konfiguration sehr "nervig" und im Endeffekt nicht mehr handelbar. Hier würde ich im Hintergrund lieber eine eigene Anwendung bauen die die Konfiguration zentral in unseren GIT Repos verwalten kann.

* Authentifizierung: idealerweise etwas "einfaches" wie statische Bearer-Token. Alternativ X509 basierte Client Authentifizierung.

Beste Grüße aus Bremen,
Andi Dittrich

---

Guten Tag Herr Dittrich,

die API wird initial nur die Endpunkte enthalten, welche unsere Testpartner brauchen. Falls wir in der Testphase auf größere Probleme stoßen, müssen wir ja sonst sehr viele Endpunkte überarbeiten, die noch nicht nötig sind. Natürlich planen wir die Struktur aber auch so, dass andere erwünschte Endpunkte plausibel angeboten werden können.

Nach dem Release werden wir schauen, welche Endpunkte am meisten gefragt sind und überlegen, wie wir diese am bsten konstruieren.

Initial wird es sich fast um eine reine Kalender-API handeln.

Termine sollen gelesen und (mit Neupatientendaten) geschrieben, Terminsuchen ausgeführt und z.B. Patientenmatching zum finden von Bestandspatienten ausgeführt werden können. Einige Eigenschaften von Terminen wie z.B. den Zeitraum soll man auch beobachten können (i.e. automatische Rückmeldung bei Änderungen). Man soll man auch die Rahmendaten verschiedener Verwaltungsgegenstände wie Terminarten, Terminsuchen etc. lesen können, jedoch nicht die genauen Inhalte (z.B. welche Ressourcen eine Terminsuche braucht).

Allgemein ist eher nicht der Plan, dass die API für Konfigurationszwecke genutzt wird. Hierfür müssten wir einen viel zu tiefen Einblick in das Innere von tomedo geben, was uns entsprechend Flexibilität nimmt, dort schwerwiegende Änderungen vorzunehmen. Immerhin soll die API ja stabil bleiben und wir müssten so enorm viel Arbeit in die Kompatibilität stecken.

Eine richtige Übersicht gibt es nur im Sinne der Dokumentation, welche wir wie oben beschrieben vorerst noch nicht veröffentlichen wollen.

Ressourcen zum lesen und schreiben freizugeben scheint plausibel. Bei den Schemata müsste man vermutlich nochmal diskutieren, in welchem Rahmen wir das machen. Ob man diese z.B. bearbeiten kann oder nur übertragen. Dem bearbeiten stehen nämlich größere technische Hürden im Weg.

Richtig neue Patienten anlegen statt nur Neupatientendaten an Terminen zu haben scheint plausibel.

Arbeitsplatzeinstellungen zu überschreiben scheint leider nicht realistisch. Diese liegen ja nicht in der Datenbank, sondern werden lokal in .plist-Dateien gespeichert.

Urlaubs- und Sperrtage sind eine schwierige angelegenheit, weil wir da momentan größere technische Umbauten planen. Entsprechend ist die Frage, ob wir soetwas schon einbauen und dann später Kompatibilitätsmaßnahmen für ältere API-Versionen haben, oder ob wir eher warten.

Karteieinträge sind ein viel schwierigeres Thema. Die API geht vom Kalender-Team aus, von daher können wir schlecht die Schwierigkeiten bei Karteieinträgen einschätzen und die Karteiverantwortlichen können noch schwer die API einschätzen. Grundsätzlich scheint die Anforderung plausibel und wir hatten da schon interne Gespräche zu, aber wie genau das freigegeben wird ist noch fragwürdig (übersetzt man zum Beispiel die Inhalte von CKEs in eine Liste aus Key-Value-Paaren? Müssen wir Karteieinträge eher auf verschiedene Endpunkte aufteilen (z.B. einer extra für CAVE)?).

Mit freundlichen Grüßen,

Toni Ringling

---

Hallo Herr Ringling und danke für die ausführlichen und interessanten Einblicke!

@ "Meeting": ja, auch sehr gerne.

---

Hallo,

gerade für die Nutzung von externen Programmen wäre die unkomplizierte Verarbeitbarkeit von Eingaben und Ausgaben (zB Karteieinträge, aber auch Informationen aus CKE) von hohem Nutzen...ähnliche wie Pipes bei Unix, wo man sehr einfach die Ausgabe eines Programmes als Eingabe für das nächste Programm nutzen kann.

Als Beispiel --> externer Arztbrief wird gescannt --> PDF --> Textextraktion --> Regex/ML mit Aufarbeitung der Informationen (zB ICD Codes oder Zusammenfassungen) --> Tomedo --> Übernahme von ICDs oder import der Zusammenfassung in ein Karteieintrag.

Oder auch die automatisierte Verarbeitung von eAB, da kommt ja auch ein xml mit, in denen ein Haufen gut verarbeitbare Informationen sind.

Meiner Meinung nach ist es sehr wichtig, dass wir als Ärzte auch weiterhin ähnlich bei bei CKE und AK die Möglichkeit haben, selbstständig Automatisierungen zu bauen. Niemand wird sich für jede Kleinigkeit einen ITler holen, und das Erlernen eine Programmiersprache ist halt echt zeitaufwändig.

-js

---

Guten Tag Herr Dr. Smid,

die Zielaudienz bei der Entwicklung dieser API sind leider eher eigenständig laufende externe Programme - Onlinekalender, Telefonassistenten, Callcenter-Anbindungen etc.. So wie sie konzipiert ist, ist sie leider nicht wirklich für die direkte Nutzerinteraktion geeignet, sondern eher für ständige Hintergrundprozesse. Hauptsächlich, weil Datenbank/tomedo-Server- und nicht Nutzeraktionen/tomedo-Client-zentriert ist.

Für ihren Wunsch müsste der Scan praktisch in ein gesondertes Programm geliefert werden, welches dann die Verarbeitung durchführt und die ICDs/Karteieinträge nach tomedo schreibt. Dort müsste man auch ausreichende Patientendaten eintragen, damit der tomedo-Patient gefunden werden kann. (Bzw. bei ICDs weiß ich gar nicht, ob wir die automatisiert schreiben lassen dürfen.)

Ich die Anforderungen die in diesem Thread gestellt werden, erfordern vermutlich etwas komplett anders strukturiertes. Wir werden wie oben angesprochen wohl nochmal Besprechen, was diese Anforderungen angeht und überlegen, was man für diese Zwecke im Rahmen dieser API anbieten könnte.

Möglicherweise ist dies aber einfach leider nicht das richtige Feature für die hier im Thread beschriebenen Anfragen (außer ggf. die von Herr Dittrich) .

Mit freundlichen Grüßen,

Toni Ringling

---

Tja, es ist für den Softwareanbieter sicher immer eine Gratwanderung - Flexibilität möglichst nicht mit den Kosten der Komplexität. Ich habe den Eindruck, dass tomedo / Zollsoft in den Anfängen - daher wohl auch der Name "Briefkommandos" - da gar nicht so weit vorgeplant hatte und erstmal tatsächlich nur für die Vereinfachung der Briefschreibung die "einfachen Platzhalter" eingeführt hatte. Ich vermute auch stark, dass es damals kein größeren Konzept dazu gab, wie man dem (geneigten) Anwender ein Zugriff auf (Teile des) Datenmodel(s) erlauben wollte, sondern hat eine rel. simple "Zwischenschicht mal eben programmiert". Dann kamen immer mehr Möglichkeiten hinzu und mit dem Erfolg von tomedo wuchs auch der Wunsch - sicher nicht beim Großteil der Anwender! - auch auf andere Teile des Datenmodels zuzugreifen (v.a. mit Einführung der CKEs und CFs). Ich finde einige der geschaffenen Zwischenschichten, allen voran die custom Statistiken EXTREM hilfreich. Liegt sicher auch daran, dass ich 1. SQL in der Tiefe nicht so beherrsche und 2. nicht die Zeit / Muße habe, der Aufbau der Postgres Datenbank "reverse ingieneeren" kann / will. Es gibt aber auch keine Doku dazu, genau so wenig wie zu den Keypath-Kommandos. Maches kann man schon rel. offensichtlich herleiten, aber vieles eben auch nicht. Den Vorschlag, per Export in die Zwischenablage und dann Verarbeitung extern finde ich zu kurz gedacht, da man den Arbeitsaufwand nur verlagert. Statt sich in die, nennen wir es mal TomedoScript Sprache einzuarbeiten macht man es eben extern für Python oder was auch immer. Auch wäre sicher nicht alle Daten so einfach als Texte zu ex- bzw. importieren. Ich persönloch fände eine API - natürlich als Zwischenschicht - VERBUNDEN mit einer ordentlichen Dokumentation mit Zugriff auf einen Großteil des Datenmodels wünschenswert. Die Frage ist, inwiefern Zollsoft dieses Datenmodell offen legen will / kann. Ich bin auch weiterhin der Meinung, dass es für Zollsoft langfristig einfacher sein sollte, eine konsistente API zu pflegen, als an mehreren Baustellen (bestehende Platzhalter ohne und mit Text, komplexe Kommandos wie das x-Kommando usw.) das Bisherige zu pflegen und zu erweitern. Mir ist aber auch bewusst, dass dies mit hiher Wahrscheinlichkeit ein Großteil der Nutzer so nicht sieht, da der Einarbeitungsaufwand ganz sicher nicht zu unbterschätzen sein wird. Aber mal ehrlich - um die jetzigen Möglichkeiten zu nutzen war dieser für mich auch enorm.