Hallo,wir bräuchten statt der Patientenabhängigen Text-Felder eigentlich noch 1 Ja/Nein-Feld. Da natürlich nicht ewig viele Platz haben würden wir uns ein entweder/oder Szenario wünschen.Der Haken für "Datenschutz" wäre schon wichtig.... aber "Chroniker" dafür zu opfern ist leider auch nicht sinnvoll :)Alternativ wäre eine "Persistenz"-Option bei den Besuchsabhängigen Feldern möglich, so dass der vorherige Wert beim nächsten Besuch übernommen wird.VGJM

Das wort "statt" kannst du getrost vergessen wenn es um Tomedoumbauten geht, das Textfeld Patient wird viel genutzt auch von uns. "noch" Ja/Nein Felder habe ich ich schon mehrmals angefragt. Die Antwort war "nein, weil wie viele sollten es sein?" Die Antworten so viele wir brauchen oder 5 oder 10 oder einige mehr, führte nicht zum ziel. Die Ja/Nein Felder lassen sich super für eine One Button Statitsik nutzen. Ob es ein Ticket gibt weiss ich nicht.

In jedem Fall wäre das Aufbohren der Ja/Nein wirklich sinnvoll. Es gibt keine einfachere Methode in Tomedo schnell einen Status zu setzen, zu entfernen und schnell einen Status abzufragen. Hätte ich mehr von den Feldern und Mehr Platz in der Menü-Icon-Leiste oder eine eigene Leiste würde ich abfragen einrichten wie: Material muss bestellt werden / ist bestellt (2x ja/nein) und dann eine One Button Statistik die die z.B gerade 10 Patienten ausgibt bei denen noch Bestellungen gemacht werden müssen. Ich könnte als bestellende Helferin den Handzettel wegschmeissen den ich sonst immer dabei habe. Natürlich geht da auch über die Kartei aber es gibt nun mal 5-10 Verwaltungstechnische Abläufe in jeder Praxis die so oft vorkommen, dass es mühsam ist dafür einen Eintrag zu generieren. Hört sich komisch an aber Drei Buchstaben eingeben und ENTER und 3-4 konzentrierte Klicks zum Textmakro sind zu anstrengend für eine repetitive Aufgabe. Der Haken ist ein Klick - done.

Eine einfache Möglichkeit schnell einen Patientenstatus zu setzen bieten die Patientenmarker. Warum sind diese für den angesprochenden Fall unpraktikabel?

Die Handhabung ist anders Herr Berg. Mit den Ja/Nein haben sie unbewusst den Vogel abgeschossen mit der einfachsten und simpelsten Statussetzung. Die Bildchen der Patientenmarker sind sehr klein und sagen selten auf den ersten Blick etwas aus, man muss mit der Maus darauf fahren um zu erfahren was los ist, Kartei auf reicht nicht. Und dann das wichtigste: schalten sie mal eins an und wieder aus und zählen sie die Klicks und Scrolls. Ich könnte aber ein Fan werden wenn sie dem ausgewählten Patientenstatus ein aktiv/inaktiv geben (=ja/nein) und ein "immer" also bei jedem Patienten den Zustand geben und sie da listen wo jetzt die Ja/nein Felder sind aber inklusive den beiden Checkboxen. Dann können sie das Selbe wie die Ja/Nein Felder und die Ja/Nein können dann von mir aus weg. Ich gehe jetzt mal davon aus dass sie auch in der Satistik suchbar sind nur derzeit ohne Zustand. Wenn der Patientenstatus noch Listen speichern kann können die Dropdowns unter den Ja/Nein auch weg. Die Ja/Nein hätten gleich so wie die von mir beschriebenen Patientenstati gebaut werden sollen. Derzeit ist es doppel gemoppelt und Ja/Nein kann was was Patientenstatus nicht kann und umgekehrt.

Die Patientenmarker sind in der Tat noch nicht sehr praktikabel, wir haben uns auch noch nicht damit anfreunden können. Noch mehr administrative Felder sind aber auch keine Lösung, sonst brauchen wir irgendwann ´nen 50-Zoll-Monitor... Wäre es nicht möglich, die "fachgruppenspezifische Ansicht im rechten oberen Teil der Kartei" zu ergänzen? Wir nutzen das derzeit für die Familienmitglieder, wäre aber verzichtbar, dort ein zusätzliches Ja/Nein-Feld möglich zu machen sollte doch recht einfach zu programmieren sein?

Das wäre ja aber auch wieder nur eine Lösung für Praxen, für die die Fachgruppenansicht nicht unbedingt notwendig ist (wie z.B. bei Gynäkologen, Pyschotherapeuten und Radiologen)

Aber eine Lösung ;-) Den Datenschutz-Haken wollen sicherlich auch nicht alle Praxen machen, ich brauche den z.B. nicht. Eine Flexibilisierung dieses Feldes würde aber vermeiden, noch mehr zusätzliche Felder zu bekommen, tomedo soll bitte "schlank" bleiben (a bissl Speck hat´s ja schon angesetzt...)!

>> Und dann das wichtigste: schalten sie mal eins an und wieder aus und zählen sie die Klicks und Scrolls. Die Anzahl der Klicks zum Aktivieren bwz. Deaktivieren eines häufig benutzen Markers (d.h. die Marker sollten so sortiert sein, dass Sie ohne Scrollen sichtbar sind) beträgt drei - inkusive des Klicks zum Schließen des Popover per OK, was man nicht unbedingt per Klick machen muss, da man bei offenem Popover einfach die nächste gewünshte Aktion ausführen kann und das Popover schliesst sich automatisch ). Im Hinblick auf z.B. Dokumentation von DSGVO oder Chroinoker empfinde ich das als zumutbar, dies einmal für jeden Patienten durchzuführen. Der Marker wird ja nicht ständig geändert.

>> Die Bildchen der Patientenmarker sind sehr klein und sagen selten auf den ersten Blick etwas aus, man muss mit der Maus darauf fahren um zu erfahren was los ist.Die Marker sind so konfigurierbar, dass der entsprechende Text immer mit angazeigt wird (darunter leidet dann natürlich die Sichtbarkeit des Patientenbildes).

Ich muss Peter leider mit dem Patientenbildchen zustimmen... das ist irgendwie unpraktikabel... unsere MFA's sehen auch nicht mehr so gut....Retinaauflösung auf 24" ist zwar klar, aber alles auf dem Desktop ist winzig...ganz zu schweigen von nem 13" Macbook... was spricht denn dagegen dem besuchsspezfischen Feld einen "Persistenz-Status" angedeihen zu lassen? Das wäre die eleganteste Lösung.

Patientenabhängige Felder - Umwandeln

[gelöscht]

Für Platz am macbook12" brauchen wir Schriftgröße kleiner 13

Johannes Müller

Mit "Persistent" meine ich, dass das Häckchen im besuchabhängigen Feld beim nächsten Besuch auch noch da ist. Also persistent.... und nicht wie jetzt "gone with the wind"...

[gelöscht]

Ich denke mit Patientenmarkern die so funktionieren wie sie eigentlich sollten wäre uns beiden geholfen oder nicht? Ich denke Andreas hat schon verstanden was das Problem ist.

Was nicht in meinen Kopf will ist das wir in das Erstellen nicht einbezogen werden. Wenn Programmierzeit = Geld ist würden wir Zollsoft viel Geld sparen wenn Features nicht nur fast richtig gut geschrieben wären. Weil" fast richtig gut" auch unbrauchbar sein kann. In einigen Fällen sogar irreversibel. Mit der Dokumentenverwaltung weiss ich nicht was man machen könnte um die für QM brauchbar zu machen. Doch ich weiss es schon: Nix.

« Vorherige Seite