CKE Weiche erstellen mit 1000 Möglichkeiten

Question

Ich möchte einen weiteren Versuch starten unsere Praxis zu automatisieren auch wenn es mich jetzt schon vor der CKE Syntax gruselt und der Unübersichtlichkeit beim arbeiten mit den Aktionsketten und Bedingungen ohne Gruppen und Übersicht. Der Tenzer Baukasten und die tolle Unterstützung der Kollegen hier im Forum, vielen Dank dafür, gibt etwas Hoffnung zumindest beim CKE basteln.

Ich scheitere schon am Anfang da ich keine Idee habe wie ich die Eingriffe abbilden soll. Ich habe in der Kopf-Hals Chirurgie vielleicht 100 Eingriffe die ich abbilden muss aber die Plastische meiner Frau hat sicher mehr als 500 ohne gezählt zu haben. Bei den Diagnosen ist es noch schlimmer.

Kein Weg ist es alles in ein CKE Fenster zu packen mit unzähligen Dropdowns da die Arbeit mit so einem Fesnter unübersichtlich und unangenehm wird. Es ist auch ausgeschlossen viele CKE für jede Eingriffsgruppe zu bauen da Änderungen zum Alptraum werden.

Was haben wir für Möglichkeiten uns in die richtige Diagnose und Therpaie zu klicken?  Wie können wir vom Groben ins Detail gehen ohne sinnloses für den Fall darzustellen?

Fehlt dem CKE ein Menübaum?

Answer 1

Solch ein Projekt macht durchaus Sinn. Grundvoraussetzung dafür sind gut pepflegte Diagnosefavoriten, und Abrechnungsziffern. Wenn man weiß in welchem Gebiet man arbeitet, ist es möglich mit 2-3 Klicks den exakten OPS zu generieren. Der genügt aber nur zur Abrechnung im EBM. Die GOÄ müßte man parallel abbilden. Das macht es komplizierter, wenn man so wie Du so viele variable und individuelle Leistungen hat.

Über Auswahlfelder eines CKE kann man sich aber seine Favoriten allerdings so filtern, dass einem nur die Gewünschten angezeigt werden. Hat man für jede Leistung seine Ziffern hinterlegt, auch entsprechende Steigerungen, kann man mit wenigen Feldern eines CKE die Passenden Abrechnungsziffern automatisch aufrufen. Das habe ich mir mit viel Mühe angeeignet. Die CKE habe ich laufend anpassen und optimieren müssen. Weniger Arbeit macht es, wenn man von vornherein weiß wohin man möchte.

Ich denke je komplexer Dokumentation und Abrechnung sind, umso lohnender ist der Aufwand sich letztendlich seine Arbeit zu vereinfachen. Bei Deinem Gebiet besteht die Komplexität in der vielfältigen Kombinationsmöglichkeit und der vielen Simultanleistungen, die alle einzeln dokumentiert und abgerechnet werden sollen. Zunächst sollte man schauen, ob man seine Leistungsziffern nicht nur thematisch sondern nach einer anderen Struktur ordnen kann, die sich über Einträge in Auswahlfeldern ordnen und filtern lassen.

Comments

Danke Christian aber die konkrete Frage lautet:

CKE Baumauswahl - technisch wie?

---

Wenn Du damit dynamische Unterformulare meinst, würde das nach nach Aussage der zuständigen Programmierer einen kompletten Umbau bedeuten.

---

Velleicht sollte man das.

---

Ich fände das toll. Tomedo würde dadurch wertvoller

aber

1. die CKE werden bestimmt nicht einfacher

2. Eine solche Entwicklung würden momentan nur wenige Anwender einsetzen, weshalb der Programmieraufwand erstmal nicht betrieben wird

Answer 2

Ich nutze zur Auswahl möglicher OP-Ziffern bzw. CKEs für OP-Berichte ein Feld in der OP-Anmeldung. Dort gebe ich bei der OP-Anmeldung die geplante OP an. Damit kann man viele Standardeingriffe wie z.B. bei uns Knie-ASK, Karpaltunnelsyndrom, schnellender Finger, Emmert-Plastik usw gut abbilden und automatisieren.

Comments

Hallo,

man kann eine dynamische Struktur mit Akionskettenbedingungen erzeugen. Mit dem Kommando $[karteiEintragValue_withArgs ..]$ kann man prüfen, ob im ersten CKE ein bestimmtes Feld ausgewählt wurde. Davon abhängig kann man über eine Aktionskette einen spezifischen zweiten CKE starten. Also beispielsweise setzt man in CKE1 ein Kreuz bei "Anästhesie notwendig", die Aktionskette wird ausgelöst durch CKE1 und hat die Bedingung $[karteiEintragValue_withArgs CKE1 customKarteiEntries.anaesthesieNotwendig _ N]$  gleich 1 und damit wird CKE2 aufgerufen, was die notwendigen Daten (Körpergewicht, Alter usw.) sammelt um z.B. die geeigneten Medikamente auszuwählen. Da man durch die Aktionskettenbedingungen beliebig viele unterschiedliche Aktionsketten von einem einzelnen CKE starten kann, hat man damit effiktiv ein beliebig verzweigbares Baumdiagramm. Der Vorgang ist allerdings, wie Sie schon geschrieben haben, nicht sehr übersichtlich. Man bräuchte recht detaillierte Notizen dazu, um den Überblick zu behalten. Dafür könnte man vielleicht sogenannte Entity-Relation-Diagramme verwenden. Für das Beisiel sähe es z.B. so aus:

Das Unterfangen wäre vermutlich noch immer recht umfänglich, zumindest aber Änderungen würden dann nur vergleichsweise kleine CKE betreffen.

Mit freundlichen Grüßen,

Christoph Baumbach

---

Danke Herr Baumbach das ist eine Möglichkeit, unübersichtlich und fehleranfällig aber es ist eine Lösung. Das schlimme ist, dass es wie in meinem Eingagspost geschrieben repetitiv arbeitsintensiv ist. Änderungen müssen dann an vielen vielen CKE durchgeführt werden (CKE2,3,4) obwohl sie wahrscheinlich den ähnlichen Inhalt haben der nur einmal vorkommen sollte. 

CKE hopping ist meiner Menung nach keine gute Lösung.

Die Crux ist wohl, dass das CKE nicht neugezeichnet werden kann nach einer Eingabe. 

Die Lösung wäre für die CKE Zeilen die Zeilenoption : Anzeige wenn Variable XY "Beinvene" und ein Neuzeichnen des CKE mit Behalten der bereits eingegeben Variablenwerte und ein Neunzeichnen des CKE.

---

Ohne Frage ist das sehr unübersichtlich. Wir haben das Problem im Produktmanagement zumindest erkannt und überlegen derzeit, wie man den Ablauf übersichtlicher gestalten kann. Eine Idee ist, tatsächlich eine graphische Darstellung wie oben gezeigt zu verwenden, die eine Verschachtelung von CKEs und anderen Elementen zeigt und über die man direkt seine Aktionsketten konfigurieren kann. Die gesammte Konfigurationen würde dann per Drag&Drop erfolgen können inkl. Bedingungen und Auslösern. Allerdings ist das Vorhaben recht komplex.

Ihr Vorschlag die Sichtbarkeit von Elementen abhängig von Eingaben in anderen Feldern zu machen, verspricht zumindest eine Teillösung. Würde man die Sichtbarkeit in der CKE-Verwaltung z.B. über ein Briefkommando kontrollieren können, wäre die Bedienbarkeit aber immer noch lediglich für sehr erfahrene tomedo Nutzer:innen praktikabel. In jedem Fall nehme ich die Idee aber sehr gern mit auf, da sie technisch zumindest vermutlich recht leicht umsetzbar wäre.

Eine wichtige Ergänzung zum obigen Anliegen wollte ich noch machen. Wenn es vorrangig um Abrechnungsvorschläge geht, so kann ich die "Abrechnungsvorschläge" im Admin-Menü empfehlen. Dort lassen sich Regeln definieren, bei welchen Leistunge, Karteieinträgen etc. welche zusätzlichen Leistungen vorgeschlagen werden sollen. Das ist nicht ganz so komfortabel in der Buchung wie Abrechnungsvorschläge via Aktionsketten aber um einiges komfortabler im Anlegen der Regeln insbesondere wenn es um sehr viele Regeln geht.

---

Sind sie von Zollsoft Herr Baumbach? Ist nicht ersichtlich. Sie werden es nicht glauben aber ich denke bei Vorschlägen immer an die Einfachheit der Umsetzung. JE einfacher es ist ein Feature umzusetzen desto wahrscheinlicher ist es das Feature zu bekommen.

Einfacher als Briefkommandos wäre unten bei den Zeilen wo die Breite, sichtbar im Karteitext Checkbox etc angezeigt wird ein Feld für eine Variable oder besser Variablen bei denen die Zeile angezeigt und das CKE neu gezeichnet wird. Anzeigen wenn: Variablename Variableninhalt.

Es geht nicht um Abrechnungsvorschläge sondern um die Fallautomatisierung. Das ist es was alle Praxen wollen. Wir alle hassen repetitive Aufgaben und die Dokumentation von Fällen ist bei uns in 99% repetitiv.

 

Eine Idee ist, tatsächlich eine graphische Darstellung wie oben gezeigt zu verwenden, die eine Verschachtelung von CKEs und anderen Elementen zeigt und über die man direkt seine Aktionsketten konfigurieren kann. Die gesammte Konfigurationen würde dann per Drag&Drop erfolgen können inkl. Bedingungen und Auslösern. Allerdings ist das Vorhaben recht komplex.

Keine gute Idee. CKEs verschachteln an sich ist schlecht. Übersicht, mehrfache Änderungen, ne das ist übel. Christian Klaproth hat sowas mühevoll erstellt, ich weigere mich, ist ein Zeitverbrenner. 

---

Das Schema oben ist sehr übersichtlich. Wenn es so einfach wäre, die Verknüpfungen auf diesem Wege zu erstellen, wäre das schön, weil man sich weniger mit den Schwierigkeiten der Syntax herumschlagen müßte. Dennoch muss man sich auch dabei grundlegende Gedanken über die gewünschten Abläufe und deren Reihenfolge machen.

Auch im Schema oben ist die Verschachtelung von Aktionsketten über Abhängigkeiten (Bedingungen) erkennbar.

So etwas wird dann unübersichtlich wenn man wie bei mir 16 Verschachtelungen hintereinander schaltet und simultan verschiedene Aktionsketten am Laufen hat. Das ist tatsächlich ein Zeitfresser und ich würde mir eine Vereinfachung wünschen.

---

Das Problem Übersicht hast du auch nicht wenn du in einem CKE arbeitest statt in 100. Diese Übersicht kann ja trotzdem im Einzelnen CKE gezeichnet werden als Ansicht. Das Problem ist bei vielen CKE, dass viele Ähnliches beinhalten und du bei Änderungen vieles Ähnliches ändern musst.

---

Ja, das kann ich nachvollziehen. (und ja ich bin von zollsoft und hab das in meinem Profil mal ergänzt).

Haben Sie einen Vorschlag für mich, wie man die Verknüpfungen sinnvoll abbilden könnte? Vielleicht wäre das bedingte Ausblenden von Feldern schon hilfreicher, klingt für mich aber noch nicht nach einer allumfassenden Lösung. Hätten Sie beide noch Vorschläge? Ideal wäre z.B. der Verweis auf eine Software, wo ähnliche Probleme bereits zufriedenstellend gelöst wurden. Die Entity-Relation-Diagramme werden z.B. in der Datenbankentwicklung zur Darstellung komplexer Abläufe verwendet. Andere (gelungene) Beispiele kenne ich leider nicht.

---

So etwas mit den Verknüpfungen hat Microsoft mit dem Datenbankprogramm access schön dargestellt ist allerdings auch nicht gerade einfach zu bedienen.Habe mich vor 20 jahren mal intensiv damit befasst.

In der Ninox Datenbank kann man auch die Tabellenverknüpfungen einstellen.

Sie haben oben sehr schön dargestellt, dass man Felder eines CKE mit anderen CKE verknüpfen kann. Die Bedingung haben sie im Verlauf des Pfeils dargestellt. Nur sind leider unsere Bedingungen sehr viel komplexer, denn man muss definieren welchen Karteieintrag man nimmt, grundsätzlich, den vom gleichen Tag, und/oder den letzten. Gibt es weitere Bedingungen, z.B. dass der abhängige Karteieintrag schon angelegt wurde? Dann ggf. nicht Neuanlage sondern Öffnen des bestehenden Karteieeintrags um noch einmal Bearbeitungen vornehmen zu können usw.

---

Wenn wie oben dargestellt die Verknüpfungen definiert sind, sollte man auch Änderungen vornehmen können, weil die dann automatisch an den verknüpften Stellen durchgeführt werden. Bisher ist das tatsächlich ein riesiges Problem. Man darf möglichst nix mehr nachträglich ändern, dann läuft man den Problemen hinterher und muss sich auf Fehlersuche machen. deshalb funktioniert nichts von Anfang an fehlerfrei, zumindest bei mir.

---

Wenn ich das Problem der Änderungen richtig verstehe, würde man das lösen können, wenn man Elemente aus CKE wiederverwenden könnte. Also man hat z.B: ein Auswahlfeld mit definierten Auswahlmöglichkeiten. Das könnte man dann in CKE1, CKE3 und CKE9 einfügen und wenn man das Auswahlfeld ändert, ändert es sich automatisch in CKE1, CKE3 und CKE9 oder?

Bzgl. der Bedingungen war die Zeichnung nur als Beispiel gemeint. Grundsätzlich würde man beliebig viele Bedingungen für jeden Pfeil zulassen. Und wie bereits jetzt wären dafür alle vorhandenen Briefkommandos verfügbar sowie logische Verknüpfungen (UND und ODER).

Vielen Dank für die beiden Vorschläge. Ich krame mein altes Access gleich nochmal aus. Ich erinnere mich auch dunkel daran, dass das eigentlich ganz gut ging und auch Ninox schaue ich mir mal an.

---

Das wäre wirklich prima, weil man dann nachträglich sinnvolle Änderungen machen könnte, ohne den Rattenschwanz der Einzeländerungen an allen verborgenen Stellen zu haben.

---

Wenn man es einfach halten will arbeitet man alles in einem CKE ab und nicht in vielen. Das kann man aktuell auch schon machen aber das CKE hat ein Darstellungsproblem im Dialog. Der einzige Grund warum die Kollegen viele CKE verwenden ist weil das CKE nichts abhängig von der Auswahl darstellen kann. Aktuell hat man die Möglichkeit alles untereinander zu schreiben oder eben für jede Auswahl ein eigenes CKE damit man den Ballast bei der Darstellung los wird.

Meiner Meinung nach muss man erst die Darstellung der CKE verbessern und dann sehen ob innerhalb der verschiedenen CKE überhaupt Kommunikation notwendig ist. Ich denke nämlich nicht.

Man muss sich die Frage stellen warum mehrere CKE gebaut werden müssen wenn man doch nur einen einzigen Customkarteieintrag generieren will.

Ich denke wirklich, dass mit Abhängigkeiten der Darstellung und Neuzeichnen des Dialogs ein Grossteil unserer Probleme mit den CKE passé sind. Markiert man eine Zeile mit Abhängigkeiten im Editor kann Tomedo die Zeilen mit den abhängigen Variablen farbig markieren. So sieht man auf einem Blick welcher Menüweg zur Auswahl führt. Zudem kann man ja in der Vorschau auch testen und sehen was dargestellt wird je nach Auswahl. Dazu muss das CKE aber erstmal nach jeder Auswahl neu gezechnet werden.

---

kurz noch eine Anmerkung zum bedingten Ausblenden von Feldern:

ich fände das fantastisch!

 

Aber: schon jetzt habe in großen CKE (mit über 300 Variablen) starke Problem mit der Performance: Kontrollkästchen brauchen vom Klick bis zur Aktivierung teilweise über eine Sekunde und das Scrollen geht teils ruckelig --> vermutlich weil im Hintergrund soviel gerechnet werden muss (es werden pro Eintrag teils 5000 Serveranfragen geschickt)

 

Meine Befürchtung ist, dass durch das bedingte Ausblenden die Performance noch weiter leiden würde. So wären dann noch größere CKE, mit denen man mehrere Infopfade flexibler und übersichtlicher abbilden kann, dann schleißlich für mich unbrauchbar.

---

Nach meiner Auffassung geht das bei komplexen Abläufen nicht mit nur einem CKE für alles. Da teile ich die einschätzung von Andreas Tenzer.
Mein CKE für die Ananese steuert, ob eine Voruntersuchung laufen soll, ob eine Behandlung stattfindet und wenn ja, wird erst geprüft ob der Behandlungsvertrag unterzeichnet ist, ein ausreichender Versicherungsstatus oder Kostendeckung über einen IV-Vertrag oder Sondervereinbarung existiert. Ist das nicht der Fall, werden alle erforderlichen Vertragsunterlagen, Kostenvoranschlag und Aufklärungsunterlagen erstellt. Sind dagegen Behandlungsvertrag und OP Einwilligung unterzeichnet, wird das entsprechende CKE für die Dokumentation geöffnet. Dieses wird anschließend ausgewertet, ein Bericht erstellt, und die Leistungen je nach Eintrag im OP Dokument abgerechnet. Es werden auch gleich alle notwendigen Verordnungen und Überweisungen ausgelöst. Das dürfte etwa dem Beispiel von David Stenger entsprechen.

Derart komplexe Abläufe können nicht in einem einzigen CKE abgearbeitet werden. Das wäre dann derart überladen und nicht mehr übersichtlich zu bearbeiten. Gewünscht hätte ich mir Untermenüs z.B nur 1 CKE für die gesamte Sonographie. So aber muss ich für jedes Organgebiet einen eignen CKE basteln. Solche dynamischen CKE erfordern,  wie Herr Thierfelder kommentiert hat,  eine komplexe Neuprammierung. Da macht es ejher Sinn die Bearbeitung der vorhandenen Instrumente zu erleichtern. Diese Diskussion bringt vielleicht doch ein Umdenken der Programmierer in Gang damit die Erstellung von CKE, die Verknüpfung untereinander über Bedingungen zu vereinfachen und übersichtllicher zu gestalten.

---

Herr Tenzer, dann hat das CKE aber ein Architekturproblem. Das darf doch nicht rechenintensiv sein?!

Christian das sind verschieden Abläufe die solltest du natürlich weiterhin in verschiedenen CKE laufen lassen. Es gibt hier um die fragwürdige Aufteilung eines CKE mit vielen Möglichkeiten weil sie nicht gleichzeitig dargestellt werden sollen. Anders als aufteilen ist es aktuell nicht möglich.

Nach dem Performanceeinwand von Herrn Tenzer läuft mit dem CKE etwas schief.

---

300 Variablen sind enorm viel und dürfte auch unübersichtlich in der Konfiguration werden. Mein größter hat knapp 120 Variablen.

Habe auch das Problem, dass am Ende meiner Aktionsketten sehr viele Änderungen an den Server übertragen werden und mitunter die Peformance leidet. Wir merken das immer daran, dass halbautomatisch generierte Kalendereinträge länger brauchen und solange kein Terminzettel ausgedruckt oder Erinnerungsmail rausgeht.

---

Mit einem OP-Bericht CKE meiner Frau und mir  komme ich locker auf 300 Variablen, eher mehr. In der Konfiguration wäre eben nicht unübersichtlich wenn nach Auswahl nur relevantes eingeblendet wird. Genau das hält mich davon ab unsere Praxis zu automatisieren. Ich kann weder unsere Diagnosen noch unsere Eingriffe, noch Op Berichte mit jeweils einem CKE vernünftig abbilden. Der Dialog wird so unübersichtlich da findet man nichts mehr. Nur Standardeingriffe wie Herr Stenger es macht das mir den Aufwand nicht wert.

Was ich abbilden konnte sind die Kostenvoranschläge für ästhetische Eingriffe weil das recht wenige sind.

---

Wird die Darstellungsabhängigkeit  irgendwann mal eingebaut werden sollte man auch an das Pflichtfeld denken das dann möglich wird. Checkbox Pflichtfeld (bei Darstellung).

Beispiel wird ein Medikament benutzt darf das Charge Textfeld nicht leer sein und bei Klick auf OK wird das textfeld rot hintelegt.

Darstellen wenn: VARIABLE WERT Pflichtfeld X