Rechte: Löschen von Karteikarteneinträgen

[lcer]

Hallo liebes Forum,

gibt es eine Möglichkeit, das Löschen jeglicher Karteikarteneinträge für bestimmte Benutzer zu unterbinden? Habe keine gefunden. Wenn nein, könnte Turbomed das dann vielleicht einbauen?

Grüße

Christoph

[georich53]

lässt sich in der Rechtevergabe unter Sonstiges/Benutzerverwaltung/Benutzer einstellen.
Benutzer auswählen, dann auf Bearbeiten (F7), Karteireiter Rechte: hier kann alles mögliche erlaubt und verboten werden
Gruß georich 53

[lcer]

Hallo,

also den Reiter habe ich natürlich gefunden.

Man kann zwar einige Dinge sperren, aber nicht alles. Z.B. Opthalmologische Einträge (Messungen) oder Textzeilen gehen nicht. Mir schwebt so etwas wie die Deaktivierung des Löschkommandos (Strg-L) vor, damit Einträge zwar gelesen und erstellt, nicht aber von jedem Gelöscht werden können (hilfreich z.B. für: Einarbeitung neuer Mitarbeiter )

Grüße


Christoph

[georich53]

wie ist es mit dem Eintrag: Karteieinträge (fremde) änderbar?
Georich53

[lcer]

Hallo,

ich möchte verhindern, dass jemand eine Fehlbedienung einfach durch Löschen "vertuschen" kann. Dazu muss das Recht "Löschen" für eigene Karteieinträge verwehrt werden können. Alternativ wäre auch eine "Löschhistorie" mit Wiederherstellungsoption eine Lösung.

Grüße

Christoph

[wahnfried]

Man kann zwar einige Dinge sperren, aber nicht alles. Z.B. Opthalmologische Einträge (Messungen) oder Textzeilen gehen nicht. Mir schwebt so etwas wie die Deaktivierung des Löschkommandos (Strg-L) vor, damit Einträge zwar gelesen und erstellt, nicht aber von jedem Gelöscht werden können (hilfreich z.B. für: Einarbeitung neuer Mitarbeiter )

Hallo Icer,

wenn man verbietet, Formularkarteieinträge zu löschen und fremde Karteieinträge zu ändern, müßte doch bereits das Gröbste verhindert sein? Habe allerdings nicht ausprobiert, wie sich das auswirkt.

Voraussetzung wäre eben, daß die/der "minderberechtigte" Neue an einem von mehreren PC der Praxis als eigener Benutzer angemeldet ist und nur an einem PC arbeitet, an dem sie/er mit eigenem eingeschränkten Rechtestatus angemeldet ist.

Natürlich müßte man da den Rechtestatus noch deutlicher ausmisten...

Eine Möglichkeit, arbeitsplatzspezifisch Löschen zu verbieten, kenne ich nicht.

Grüsse, Wahnfried

[lcer]

Hallo wahnfried,

mir geht es um so etwas wie an den Supermarktkassen. Einmal vertippt - und man muss den Chef rufen, damit er die Sache wieder herauslöscht. Sonst gehen immer wieder Fehler unter.

Grüße

Christoph

[Geigenberger]

Alternativ wäre auch eine "Löschhistorie" mit Wiederherstellungsoption eine Lösung.

... ja, ja, ganz generell wäre eine "Undo-Funktion" schon was Schönes!

A. Geigenberger

[Kühl, Telse]

Moin, moin,

es existiert bereits ein Ticket (Entwicklungsaufrag) für ein neues Benutzerrecht "Karteizeile löschen" - ich habe dem Ticket nun das Quartalsupdate 4/2012 zugewiesen - was allerdings nicht bedeutet, dass wir das zwingend zum nächsten Update schaffen werden - wir versuchen es.

Tipp: Sie können innerhalb der turbomed.log-Datei nachsehen, welcher Benutzer welche Zeilen gelöscht hat - ich habe das hier eben nochmal geprüft. Ich weiß aus einigen Praxen, dass es schon ausgereicht hat, diese Auswertungsmöglichkeit zu haben - dann wurde viel vorsichtiger mit dem Löschen von Karteikartezeilen vorgegangen.
Verzeichnis \TurboMed\Programm\turbomed.log:

[09.06.2012 14:21:58.000]
Art=Karteikartenzeile löschen
Benutzer=telse2
Station=TURBO-PC
Patient=PatNum 6, Helga Appeldorn, 02.04.1978
Gültigkeitszeitpunkt=09.06.2012 14:21:29
Typ=Text
Artspalte=test
Inhalt=Neue Zeile zum Testen der LOG-Funktion
Besitzender Arzt=Dr. med. Gynther Frauenarzt

Eine UNDO-Funktion ist leider nicht so ohne weiteres umsetzbar -ich weiß aber, dass das sehr häufig gewünscht wird...

[nmndoc]

Eine UNDO-Funktion ist leider nicht so ohne weiteres umsetzbar -ich weiß aber, dass das sehr häufig gewünscht wird...

Weshalb? Im Prinzip braucht es dazu doch einfach ein Flag/Spalte "deleted" für die Datensätze/Zeilen in der Kartei. Im einfachsten Fall kann man dann über einen Schalter zwischen der normalen Ansicht oder Ansicht inkl. gelöschter Zeilen wechseln (in letzerer kann man ja einfach in der jeweiligen Zeile "wiederherstellen" klicken). Optional erhält der Datensatz/Zeile noch einen Zeitstempel beim löschen, sowie die Info wer gelöscht hat (ggf. in der selben Tabelle oder über eine getrennte die dann datensatz_nr | Zeitstempel | user(id) enthhält.

Über eine (einstellbare) automatische Wartung oder manuell können dann alle Daten die länger als X Tage gelöscht sind dann endgültig gelöscht werden.

Ich kenne ja nicht den TM Quellcode ... aber vom Grundprinzip sollte so eine Art "Papierkorb" nicht so schwierig umzusetzen sein (vgl: Momentan müssen Sie ja auch beim Löschen einer Zeile alle betroffenen Datensätze/Tabellen durchgehen und die Daten löschen - mit Papierkorb wäre der Unterschied lediglich, dass sie statt dessen markiert werden).

[lcer]

Im Prinzip braucht es dazu doch einfach ein Flag/Spalte "deleted" für die Datensätze/Zeilen in der Kartei.

Dazu kommt aber, dass jede Datenabfrage (z.B. für Karteiansicht, Statstik, Abrechnung, Abrechnungsprüfung, Formulareinträge etc = ALLES) diese Spalte berücksichtigen müßte. Also hunderte Quellcodeänderungen im gesamten Programm! Solange Turbomed ständig neue KV-Prüf-Anforderungen umsetzen muss, wird das sicher nix.

Das hat man leider von Anfang an vergessen.

Grüße

Christoph

[Geigenberger]

Dazu kommt aber, dass jede Datenabfrage (z.B. für Karteiansicht, Statstik, Abrechnung, Abrechnungsprüfung, Formulareinträge etc = ALLES) diese Spalte berücksichtigen müßte. Also hunderte Quellcodeänderungen im gesamten Programm!

... vielleicht könnte man die "zu löschenden Karteizeile" nicht löschen, sondern nur verschieben in eine neu zu schaffende Tabelle "Deleted" in der Datenbank. Diese Dateizeilen in "Deleted" sollte man ansehen können und eben auch wieder zurückkopieren können an die ursprüngliche Stelle. Dann müßte man die im Programm befindlichen hunderte Datenabfragen nicht verändern.

A. Geigenberger

[nmndoc]

Dazu kommt aber, dass jede Datenabfrage (z.B. für Karteiansicht, Statstik, Abrechnung, Abrechnungsprüfung, Formulareinträge etc = ALLES) diese Spalte berücksichtigen müßte. Also hunderte Quellcodeänderungen im gesamten Programm!

... vielleicht könnte man die "zu löschenden Karteizeile" nicht löschen, sondern nur verschieben in eine neu zu schaffende Tabelle "Deleted" in der Datenbank. Diese Dateizeilen in "Deleted" sollte man ansehen können und eben auch wieder zurückkopieren können an die ursprüngliche Stelle. Dann müßte man die im Programm befindlichen hunderte Datenabfragen nicht verändern.

das mit dem Verschieben in eine andere Tabelle hatte ich auch überlegt, aber dann den Gedanken verworfen, weil mir der andere Ansatz irgendwie universeller schien. Denn die eigene Tabelle würde ja im Prinzip voraussetzen, dass sie a) die gleiche Struktur hat (evt. möchte ich die Löschfunktion aber auch für andere Inhalte) und b) die Karteieinträge auch wirklich in einer Tabelle stehen und nicht beim Aufruf aus aus mehreren zusammengebaut werden.
Letzteres könnte man allerdings mit mehreren Tabellen umgehen - quasi je eine *_deleted-Tabelle für jede relevante Tabelle (btw: darüber könnte man evtl. sogar eine wirkliche histoty abbilden - also auch wenn z.B. in einer Zeile nur etwas geändert wurde die entsprechende alte Version als "gelöschte" Zeile ablegen. Dann könnte man sich alle Versionen einer Zeile anzeigen lassen und die gewünschte wiederherstellen / aktiv machen).

Der o.g. Einwand weg. Anpassung der Datenabfragen (im Fall von nur gemarkten Datensätzen) stimmt sicher bzw. abhängig vom Programmaufbau. Allerdings würde sich ja die Änderung auf ein Hinzufügen von "... AND deleted=0" o.ä. auf die entsprechenden Abfragen beschränken - das könnte man schon fast mit suche/ersetzen machen (suche nach "select from <name der tabelle>"

[wahnfried]

Allerdings würde sich ja die Änderung auf ein Hinzufügen von "... AND deleted=0" o.ä. auf die entsprechenden Abfragen beschränken - das könnte man schon fast mit suche/ersetzen machen (suche nach "select from <name der tabelle>"

...wie sollte das gehen bei hunderten exotisch anmutender Passworte (und nochmal soviel "tmtest"), um den Quelltext bearbeiten zu können?

Wahnfried?

[nmndoc]

Allerdings würde sich ja die Änderung auf ein Hinzufügen von "... AND deleted=0" o.ä. auf die entsprechenden Abfragen beschränken - das könnte man schon fast mit suche/ersetzen machen (suche nach "select from <name der tabelle>"

...wie sollte das gehen bei hunderten exotisch anmutender Passworte (und nochmal soviel "tmtest"), um den Quelltext bearbeiten zu können?

Wahnfried?

Hallo,

ich meinte ja nicht dass die Änderungen der Anwender macht, sondern die TM-Entwickler.

[wahnfried]

Allerdings würde sich ja die Änderung auf ein Hinzufügen von "... AND deleted=0" o.ä. auf die entsprechenden Abfragen beschränken - das könnte man schon fast mit suche/ersetzen machen (suche nach "select from <name der tabelle>"

...wie sollte das gehen bei hunderten exotisch anmutender Passworte (und nochmal soviel "tmtest"), um den Quelltext bearbeiten zu können?

Wahnfried?

ich meinte ja nicht dass die Änderungen der Anwender macht, sondern die TM-Entwickler.

... das habe ich auch verstanden, insofern wollte ich anmerken, daß da eben doch jedes Formular persönlich geöffnet und bearbeitet werden muß, da kann ich mir nicht vorstellen, daß das automatisiert werden kann - und dies wollte ich hinterfragen.

Wenn das Öffnen aller Formular-Dateien nämlich nicht automatisiert werden kann, um dann wiederum automatisiert nach diesen zu ergänzenden Stellen zu suchen, ist es abzusehen, daß irgendwelche Abhängigkeiten "vergessen" werden. Und es bindet die Entwicklungskapazität für Wichtigeres. Da fand ich den Vorschlag einer zweiten Datenbanktabelle (die alle bisherigen Formulare ignorieren) in meinem laienhaften Verständnis richtig gut.

Grüsse, Wahnfried