Hilfe bei Aktionskettenbedingung

Question

$[d S dd.MM.yyyy]$  liefert folgendes Ergebnis 12.12.2023

sofern heute eine Leistung eingetragen wurde liefert $[l %d]$ ebenfalls das gleiche Ergebnis  12.12.2023

folgende Bedingung funktioniert aber trotzdem nicht und löst fälschlich aus, auch wenn beide Bedingungen erfüllt sind.

Erkennt jemand meinen Fehler?

Comments

Ich könnte mir vorstellen, dass es nicht funktioniert, weil das eine ein Datum ist und das andere (l-Kommando) eine Zeichenkette ist

---

Ich kann nur das LogLevel für Aktionskettenbedingungen empfehlen, da sieht man es direkt in der log-Datei.

---

Vielen Dank für die Tipps.

Datum und Zeichenkett erscheint als einziges plausibel.

#Hermman Burau  "enthält" liefert das gleiche Ergebnis

# Andres Tenzer an die versteckten Blanks habe ich auch als erstes gedacht,

---

Hallo Herr Thierfelder

Leider hilft mir das nicht weiter.

So sieht der Abschnit in der log Datei aus.

2023-12-13 11:22:03.820 GUIActionController.m:181[lvl=50]   GUIActionController: 2023-12-13 10:22:00 +0000  =>  PFV, KarteiFenster, Schließen
2023-12-13 11:22:04.407 ZSActiveKarteiKetteModalWindowController.m:646[lvl=50] KarteiEintragKetteEintrag:  4  'Aktionskettenbedinung'
2023-12-13 11:22:04.408 GuiActionCondition.m:204[lvl=94]
evaluiere:  13-Folgerezept
 -> "$[l %d  ]$" != "$[d S dd.MM.yyyy]$" AND "$[patient_versichertenstatus]$" == "privat"
 => "$[l %d  ]$" != "$[d S dd.MM.yyyy]$" AND "$[patient_versichertenstatus]$" == "privat"

Ich kann da keinen Fehler erkennen.

Alle anderen angesprochenen Möglichkeiten habe ich als Fehlerquelle ausgeschlossen.

---

genau die zeile danach ist die wichtige

---

Jetzt etwas mehr, die folgende bedingung mit dem Hausverbot funktioniert.

2023-12-13 11:22:03.820 GUIActionController.m:181[lvl=50]   GUIActionController: 2023-12-13 10:22:00 +0000  =>  PFV, KarteiFenster, Schließen
2023-12-13 11:22:04.407 ZSActiveKarteiKetteModalWindowController.m:646[lvl=50] KarteiEintragKetteEintrag:  4  'Aktionskettenbedinung'
2023-12-13 11:22:04.408 GuiActionCondition.m:204[lvl=94]
evaluiere:  13-Folgerezept
 -> "$[l %d  ]$" != "$[d S dd.MM.yyyy]$" AND "$[patient_versichertenstatus]$" == "privat"
 => "$[l %d  ]$" != "$[d S dd.MM.yyyy]$" AND "$[patient_versichertenstatus]$" == "privat"
 => "13.12.2023" != "13.12.2023" AND "privat" == "privat"
 ==> nope
2023-12-13 11:22:04.428 GuiActionCondition.m:204[lvl=94]
evaluiere:  72-Hausverbot
 -> "$[istMarkerGesetzt Hausverbot]$" == "1"
 => "$[istMarkerGesetzt Hausverbot]$" == "1"
 => "0" == "1"
 ==> nope

 

Das Problem ist das die Aktionskette auch auslöst wenn eine Leistung am Tage erbracht wurde. Sie soll aber nur starten wenn sonst keine leistungen am Tag erbracht wurden. So startet die Aktionskette immer wieder aufs neue, wenn man die karteikarte schließt.

---

Ich denke das funktioniert. Wollen sie wirklich "ist nicht" testen ... aus ihrem Text kommt heraus das sie die gleichheit testen wollen

---

Hallo Herr Klaproth,

ich habe heute nochmal genauer geschaut. Also bei mir wird diese AK-Bedingung

bei Aufruf dieser AK

 und dann der AK hb0

ausgelöst und zeigt folg:

UND sie löst nicht aus wenn ich auf "enthält nicht" setze!

Oder ich verstehe ihr Problem nicht :-) Sorry

---

Guten Abend Herr Thierfelder

ich möchte, dass die Kette  bei Privatversicherten auslöst, wenn am gleichen Tag keine Leistung abgerechnet wurde.

Sobald eine Leistung eingetragen wurde, erscheint mit diesem Kommando $[l %d]$ das Systemdatum im Format dd.MM.yyyy

Die Kette löst immer aus, auch wenn eine Leistung abgerechnet wurde. Da ich als Auslöser das Schließen des Karteifensters gewählt habe, löst die Aktion immer wieder aus.

So sieht die Bedingung insgesamt aus:

Sobald irgendeine Verordnung (MED, Heilmittel, KrPfl) ausgestellt wurde ohne abzurechnen, soll die Aktion auslösen.

Habe ich da einen Denkfehler? oder liegt es am Aktionsketten auslöser indem ich die Karteikarte schließe.

---

Hallo,

also laut Logdatei steht dieses nette "==> nope" ... das sagt das keine Aktionskette ausgelöst wird ... also konkret die die am Anfang steht "PFV, KarteiFenster, Schließen". Wenn bei Ihnen doch eine Aktionskette ausgelöst wird, dann muss das an einer anderen Stelle in der Log stehen (ich bin mir da ziemlich sicher ;) ).

Ich denke mal über Ihre Bedingung nach...

---

Mich interessiert das auch, denn bei uns läuft auch vieles über ähnliche Bedingungen. Zuvor noch die Frage: was fragen Sie mit den x Kommados ab? Das da ein Eintrag war als Zeichen, dass der Pat. da war? Oder was Spezielles?

Bei mir reichen nur die beiden Bedingungen (l Kommendo und Abfrage des Vers.status) und dann löst die Kette aus wenn es an dem Datum eine Leistung eingetragen wurde und löst NICHT aus wenn keine Leistung. Kann es Ihnen gerne per TV zeigen ...

---

Noch ein Vorschlag:

statt des/r nackten x-Kommandos "$[if x MED 1 _ 0-0 NJ NJJN NNNN invTimemitICD U 0 zs_not_equal <leer> DA]$" -> ist "DA" als Bedingung testen.

---

aller guten Dinge... :-)

 

mit dieser Bedingung

löst bei mir die Kette aus wenn entweder heute kein Eintrag "OCT" oder/und keine Leistung heute geziffert wurde. Sonst löst sie nicht aus. Hilft das?

 

---

Habe jetzt mein Tomedo nicht greifbar. Werde morgen, weiter schauen und versuchen das einzugrenzen.

Im Prinzip ist das keine wichtige Sache. Wäre nur schön wenn es wie all die anderen Bedinguungen funktionieren würde.

---

Viel Erfolg!

---

Guten Abend Herr Burau,

Die  Bedingungen mit dem x-Kommando sollen nur berücksichtigen, wenn am selben Tag ein entsprechender Karteeintrag angelegt, also irgendeine Verordnung ausgestellt wurde. Wenn meine MFA das mal eben schnell machen, wird die entsprechende Ziffer leicht vergessen, weil dafür keine sonst übliche Aktionskette gestartet wird. Deshalb soll beim Schließen die Ziffer aufgerufen werden.

Das funktioniert auch, leider aber auch wenn bereits abgerechnet wurde. Die Idee von Herrn Thierfelder kann ich jetzt nicht überprüfen, ist allerdings sehr unwahrscheinlich, denn beim Schließen der Kartei habe ich nur ganz wenige Aktionsketten.

Im Prinzip habe ich nur eine gewaltige Aktionskette, die alles kaskadenartig abarbeitet und dabei je nach Ausgangsvoraussetzung unterschiedliche Wege einschlägt. Durchaus schon etwas KI.

---

Ja, das hatte ich auch mal versucht und leider verworfen. Einer der Gründe war, dass tomedo damals da leider nicht robust genug war (habe es in letzter Zeti nicht nochmal versucht), d.h. kleinere AKs mit entspr. rel. simplen Bedingungen gehen ganz ok, aber sobald es komplexer wird, gibt es VIEL Probleme und da hat Zollsoft außer dem Log kaum Instrumente für mich als Benutzer, um auf Fehlersuche zu gehen. Und ich bin immernoch hauptberiflich Arzt und nicht Bugjäger. Dazu kam damals, dass die tomedo Updates mir die Aktionsketten-Auslöser mehr als einmal "zerschossen" hatten - bei jedem Update davor und danach zu testen, ob diese unverändert bleiben kann (und will) ich zeitlich nicht leisten. Daher bleibt LEIDER das theoretisch enorme Potential der AKs inkl. Bedingungen und Auslöser fast nur zur Spielerei geeignet. Dabei wäre das DAS Argument für das PVS wenn man - natürlich mit entsprechender Überlegung und Einrichtung - eine Art individuelles "Dr.Clever"-Modul selbst bauen könnte, dass dann möglichst lückenlos klärt, ob aller Abrechnungsmöglichkeiten anhand der dokumentierten Sachverhalte (Karteieintrag über Befund, Verordnungen, gemachte technische Untersuchungen). GENAU das will doch eigentlich jeder Arzt! Sich nicht mit dem bürokratischen Sch... rumärgern. Und zumindest in der Augenheikunde sind ja die EBM-Ziffern, aber auch die GOÄ Ziffern sehr übersichtlich. Meiner Meinung nach ist aber tomedo auch momentan nicht robust genug um als Anwender mit den beschränkten Möglichkeiten der "Meta"-Ebene der tomedo-Programmierung dies umzusetzen. Ich würde mir wünschen, dass Zollsoft konsequenter in Richtung "Low-Code" denkt. Klar, ist das bisherige "organisch" gewachsen, aber es ist so nicht zukunftsträchtig. Schauen Sie doch die ganzen Reiter bei dem Briefkommandos an!

Sorry, jetzt bin ich etwas vom Thema abgekommen. Würde mich freuen,wenn Sie mir Rückmeldung geben, ob der o.g. Vorschlag klappt. Viele Grüße

---

Moin Herr Burau,

Rückmeldung gebe ich hier sobald es klappt und ich hoffentlich die Ursache gefunden habe.

Mit dem Log habe ich noch nie gearbeitet, kann damit nichts anfangen.

Ich habe aus meinen anfänglichen Fehlern gelernt. Entscheidend ist die thematische bzw. Inhaltliche Ordnung von Aktionsketten und Bedingungen. Dann ist es sehr viel einfacher, sowohl grundlegende Änderungen durchzuführen, indem man das System auf seine Bedürfnisse konfiguriert und es ist leichter, die Fehler zu finden. Dennoch ist die Fehlerbehebung die nervigste Arbeit.

Wenn man diese Mühen auf sich nimmt, lohnt es am Ende doch. Dann hat man seine gesamten Abläufe automatisiert und es wird nichts mehr vergessen.

Abrechnung, sämtliche Verordnungen, bis hin zur Befundauswertung und Befunderstellung bis hin zu Gutachten und Stellungnahmen  lassen sich dann in nur einer Aktionskette darstellen.

Ich habe nur ein paar wenige Ausnahmen, wie dieses Problem hier, das ausnahmsweise außerhalb der Kette durch einen Aktionskettenauslöser gestartet wird.

---

Moin Herr Thierfelder,

Problem ist nicht gelöst aber eingekreist und möglicherweise auch die Ursache gefundenb. Mit folgender Aktionskette lasse ich ganz zum Schluss die Karteieinträge auf bestimmte Fehler prüfen.

 

Grundsätzlich funktioniert die Bedingung dann einwandfrei, solange ich diese innerhalb meiner Aktionskette aufrufe.

 

 

Sobald ich aber als Aktionsketten-Auslöser das Schließen der Karteikarte definiere 

scheitert die Bedingung und löst grundsätzlich immer aus.

Ich vermute, dass sobald die Karteikarte geschlossen wird,  der Eintrag für die Leistungen nicht mehr ausgewertet werden kann und damit als leer erkannt wird. Sobald keine Leistungen vorhanden sind soll Tomedo für die Folgeverordnung aber eine Ziffer eintragen. Sobald das der Fall ist, wird die Aktionskette gestartet.

Das ist ein gutes beispiel dafür, dass die Aktionskettenauslöser eben nicht immer geeignet sind.

Answer 1

Guten Abend Herr Klaproth,

versuchen Sie es mit "enthält" statt "ist".

Answer 2

Ich tippe auf ein ungewolltes Leerzeichen hinter einer der beiden Syntaxen