MEDICAL OFFICE - Anwenderforum

Sehr geehrter Herr Ruß
Nachdem Sie ja nun klargestellt haben, was entscheidend für die Performance ist, so stellt sich bei mir noch viel eher die Frage, die ich bereits in einem anderen Thread aufgeworfen habe: Misst Ihr Test wirklich, was er messen soll? Und wenn ja, was läuft da schief , dass z.B. gerade Systeme mit extrem hoher IO-Leistung wie ich selbst einen Server mit einer solchen besitze (SAS 12 GB Server SSD, Cached IO über Megaraid 12GB Controller sowie sowieso extrem hoher IO seitens der Platten..) so miserabel schlecht dabei abschneiden. Wenn die CPU zweitrangig ist, RAM im Überfluss da ist und ich Firebird dank 16 Cores einen beliebigen Kern exclusiv zur Verfügung stellen kann, kapiere ich das ehrlich gesagt nicht.
Insbesondere, da Server und Clients im IBExpertBenchmark für Firebird, der Ihnen ja sicherlich als Standardreferenz etwas sagt, gar nicht so schlecht abschneiden.

Ich wäre da für eine bessere Ausleuchtung des Sachverhaltes sehr dankbar.
Freundliche Grüße

Holger Suffel

Hallo Herr Suffel,
entscheidend sind die Zugriffszeiten des Storage. RAM, Prozessor usw, sind zweitrangig. Der IBExpertBenchmark für Firebird wird im Vergleich das selbe Ergebnis liefern. Er misst auch nur die Zeiten für Insert-/Update-/Delete-/Select-Anweisungen. Wir machen mit unserem Test nichts anderes.
H.Rügen

Hallo BurkhardStr,

Sie sagen es ja selber, Nachteil: der Server ist da, wo der größte Publikumsverkehr ist...
Dies würde aber bedeuten, dass jeder AP ein "Server" ist und i.d.R. zugänglich. (Fraglich wie Datenschutzkonform dies wäre.)

Auch müsste jeder "Client" über die benötigten Festplattenkapazitäten/Festplatten verfügen.
Das Update müsste dann vollständig an jedem "Client" eingespielt werden.
Die Einrichtung der "Clients" ist immens. Vom Support, wenn die Datenbank betroffen ist, möchte ich gar nicht sprechen.

Wir sind dabei, Funktionalitäten eher auf den Server auszulagern und nur noch das "Ergebnis" am Client anzuzeigen.
Damit wird das Netzwerk auch entsprechend entlastet.

Danke!

Problem:
Netzwerkzugriff ist so viel langsamer als eigener Festplattenzugriff. Beispiel:
eine exedatei auf dem Server, die ich auf einem Client ausführe dauert trotz Gigabit Netzwerk ca 10x so lange. das Netzwerk ist der Flaschenhals. auf der eigenen Client-Festplatte öffnet die exe stets zügig.

kurz eingehend auf Ihre Bedenken: dass jeder client ein server wird, das würde ich auch gerne vermeiden.
ob man über die clients oder den server die daten klaut, ist egal. da kann man auch eine meiner mobilen arbeitsstationen mitgehen lassen. (gott bewahre). Der Datenschutz ist m.E. der gleich hohe überall.
wer heute mangelnde Festplattenkapazität hat, der hat was verpasst. auf 500GB SSD hat man seeehr lange speicherspaß, selbst mit vielen pdfs. Videos und speicherintensive Dateien gibt es nicht in der HAusarztpraxis (Ausnahmen bestätigen die regel. witzigerweise hat mein MOserver die kleinste Festplatte von allen, da ich die SSD partitioniert habe.)

Lösung
die clients haben auf ihren Festplatten immer ein Abbild des MO-Servers und greifen darauf zu, nicht direkt auf die Server-Dateien über das Netzwerk (zu langsam, siehe screenshots oben. ERfolgreiche Beispiele: Dropbox, onedrive - ist immer aktuell, ich lade beim zugriff nicht erst herunter, es ist schon auf meiner lokalen Festplatte.). Ich dachte MO funktioniert so, aber irgendwie hat MO die Notwendigkeit, immer erst den Server zu fragen, kurz bevor die Daten benötigt werden. DAs ist das Nadelöhr. Das könnte doch (sogar mit low-speed) permanent im Hintergrund erfolgen?
- die offline mobile Arbeitsstation arbeitet so zügig wie der MOserver. das in verbindung mit einem permanenten Abgleich unabhängig im Hintergrund wäre die Lösung. (ich weiß dass MO nicht so funktioniert. Die Frage ist, wie wäre das möglich? das wäre so ein gewaltiger Geschwindigkeitsgewinn an den Clients, gerade in einem Wlan.)
ich bin auf Ihre Antwort gespannt - viele Grüße

Zitat von »Lucas11«

... . Wenn die CPU zweitrangig ist, RAM im Überfluss da ist und ich Firebird dank 16 Cores einen beliebigen Kern exclusiv zur Verfügung stellen kann, kapiere ich das ehrlich gesagt nicht.
...

Ich konnte nicht widerstehen

Hallo,

mehr Geschwindigkeit ist immer das Ziel und Indamed arbeitet darum ja immer an Optimierungen. Insgesamt bin ich ich mit der Geschwindigkeit zufrieden.

Die Idee einer Datenbank-Kopie ist verlockend, Indamed hat mit dem Notfall-Server viel Erfahrung und es funktioniert, aber ist doch einiges an Aufwand. Ob das den Aufwand wert ist?
Langfristig geht der Trend in Richtung mehr Vorverarbeitung auf dem Server und intelligentes nachladen, das bringt auch mehr Geschwindigkeit und ist viel weniger Aufwand und Fehlerquelle auf dem Client.
Analoges Beispiel aus dem Web wäre vielleicht die Google-Suche? Die liefern rasend schnell Daten ohne jegliche Kopie auf meinem PC, die haben das auch extrem intensiv optimiert und Unmengen Geld ausgegeben. Indamed hat ja in Dynamic Viel auch schon Web-Elemente eingebaut.

LG C.Schnell

Alleine die Komplexität und Fehleranfälligkeit einer beständigen Synchronisation zwischen so vielen Clients, die alle ihre eigenen Datenbestände halten, macht das Vorhaben aus meiner Sicht kaum durchführbar.
Ich bin davon überzeugt, dass, sobald MO völlig zentralisiert auf dem Server ausgeführt wird und auf den Clients nur noch im Webbrowser läuft, keiner sich mehr über netzwerkbedingte Performanceprobleme beklagen wird, sodass ich es vernünftig finde, die Entwicklungsenergie/-zeit allein auf dieses Ziel zu konzentrieren.

VG Julian Hartig

Hallo,

genau in diese Richtung, "Hauptarbeit" am Server und Webapplikation, wird es gehen.
Der Formulareditor steht demnächst als Webkomponente zur Verfügung.

@ BurkhardStr, bei Ihrem WLAN Arbeitsplatz, welcher keinen Netzwerkanschluss hat, empfehle ich Ihnen einen USB to Ethernet Adapter.

Zitat von »BurkhardStr«

Zitat von »Lucas11«

Ich konnte nicht widerstehen

MVZ ? : )

Zitat von »BurkhardStr«

- die offline mobile Arbeitsstation arbeitet so zügig wie der MOserver. das in verbindung mit einem permanenten Abgleich unabhängig im Hintergrund wäre die Lösung. (ich weiß dass MO nicht so funktioniert. Die Frage ist, wie wäre das möglich? das wäre so ein gewaltiger Geschwindigkeitsgewinn an den Clients, gerade in einem Wlan.)

Hallo,
das gibt es doch bereits... Mit dem Modul "MEDICAL OFFICE Mobil" können Sie sowas machen. Sie müssen nur die Registrykeys (wurden hier bereits gepostet) setzen, damit offline gearbeitet wird und die Synchronisation im Hintergrund (asynchron) läuft. Aber wie hier bereits geschrieben wurde: man hat höhere Aufwände beim Update (man hat letztlich ja mehrere Datenbanken), man hat ein zusätzliches Sicherheitsrisiko (mobile Geräte sind Langfingern ungeschützter ausgesetzt, können verloren gehen...), da das Gerät offline arbeitet "merkt" man nicht so schnell, falls die Verbindung mal abbricht - dann werden die Daten nicht synchronisiert. Ansonsten ist das ein gangbarer Weg...
VG H.Rügen

S.g. H. Rügen, danke für die Anwort! nehmen Sie bitte noch Bezug zu folgendem:
wenn das so gut funktioniere, möchte ich mir das einrichten, brauche aber genaue Infos, worauf ich dann aufpassen sollte:
- beim update (mehrere Datenbanken - einfach abgleichen lassen? ich hatte einmal ein Abgleich Problem der mobilen stationen, was meine Performance dtl negativ beeinflusst hatte)
- Impfdoc Lagerabgleich sei gestört - wie kann ich das umgehen?
- ist das bei allen clients dann möglich - damit ich endlich flüssig den Kalender nutzen kann? (nicht nur den mobilen stationen)
- warum wird so eine praktische Funktion statt in der registry nicht in der Einstellung des Arbeitsplatzes untergebracht? für alle MO-käufer zugänglich? Denn Registry-Änderungen sind prinzipiell nur für sehr erfahrene-Nutzer.
Für Abgleich-Meldungen kann MO weiter das rote oder blaue "verbunden" symbol nutzen.


Zitat aus Performance: Clientausstattung :
hier nochmal die Registry Anpassung:
Bei 64-Bit Betriebssystemen: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\INDAMED
-Bei 32-Bit Betriebssystemen: HKEY_LOCAL_MACHINE\SOFTWARE\INDAMED
neue Zeichenfolge mit namen Offline, Wert 1
neue Zeichenfolge mit namen NoWrapper, Wert 1 (bei Mobil-DK steht Wert 2 drin)

https://forum.indamed.de/index.php?page=…c734517818cb804
VPN-Verbindung zwischen Praxis und Notebook zu Hause?
...
das Lager von Impfdoc funktioniert dann nicht korrekt.

Das Lager von ImpfDoc wird mit der Konfiguration nicht funktionieren. Soweit ich weiß ist auch beim Support von ID nicht geplant, das aktuell zu ändern. Das Synchronisieren der Lager ist eben nicht trivial…

Sonst hätte ich meinen Ersatz-Server am Tresen längst so umgestellt… viel Erfolg…

Ich denke, der Web-Ansatz von Indamed wird auf Dauer eine mögliche Performance-Lösung bieten

Zitat von »Sascha Ruß«

Hallo,

genau in diese Richtung, "Hauptarbeit" am Server und Webapplikation, wird es gehen.
Der Formulareditor steht demnächst als Webkomponente zur Verfügung.

@ BurkhardStr, bei Ihrem WLAN Arbeitsplatz, welcher keinen Netzwerkanschluss hat, empfehle ich Ihnen einen USB to Ethernet Adapter.

Das halte ich für eine partiell gute Idee. Wir nutzen intensiv die mobilen Clients - da wir die überwiegende Zahl unserer Patienten in stationären Pflegeeinrichtungen betreuen.

Es ist schon toll die Daten der Patienten vor Ort parat zu haben - aber ich arbeite aber vor Ort IMMER Offline und will das auch auch Sicherheitsgründen nicht ändern.

Aber mE könnte die Funktionalität der mobilen Clients eingegrenzt werden - insbesondere im Bezug auf die zu verwaltenden Patienten.
wir haben in der gesamten Praxisgemeinschft (mit Mandantentrennung) im Quartal ca 3000 Patienten. Jeder mobil Arbeitsplatz betreut zwischen 100 - 500 Patienten.

D.h. auf diesen Rechnern brauche ich nur etwa 1/10 der Patienten - und vielleicht auch nicht die Funktionen des DPS - die eh nur vom Admin
genutzt werden. Die Patstamm sollte allerdings mitgeführt werden, damit die Pat nicht auf diversen mobilen Clients mehrfach angelegt und dann müsam vereinigt werden müssen.

D.h. neben "Volll-DB-Clients" (wie einem Notfallserver), die natürlich den gesamten Datenbestand synchronisieren und vorhalten müssen, wäre ein abgespeckter Mobil_Client mit den Daten einiger selektierter Patienten (und evtl auch nur Teilfunktionen) sinnvoll. Wichtig - die Möglichkeit auch in diesen Clients neue Patienten anlegen zu können.

Gruß

BM

Zitat von »Privacy«

Das halte ich für eine partiell gute Idee. Wir nutzen intensiv die mobilen Clients - da wir die überwiegende Zahl unserer Patienten in stationären Pflegeeinrichtungen betreuen.

Es ist schon toll die Daten der Patienten vor Ort parat zu haben - aber ich arbeite aber vor Ort IMMER Offline und will das auch auch Sicherheitsgründen nicht ändern.

Aber mE könnte die Funktionalität der mobilen Clients eingegrenzt werden - insbesondere im Bezug auf die zu verwaltenden Patienten.
wir haben in der gesamten Praxisgemeinschft (mit Mandantentrennung) im Quartal ca 3000 Patienten. Jeder mobil Arbeitsplatz betreut zwischen 100 - 500 Patienten.

D.h. auf diesen Rechnern brauche ich nur etwa 1/10 der Patienten - und vielleicht auch nicht die Funktionen des DPS - die eh nur vom Admin
genutzt werden. Die Patstamm sollte allerdings mitgeführt werden, damit die Pat nicht auf diversen mobilen Clients mehrfach angelegt und dann müsam vereinigt werden müssen.

D.h. neben "Volll-DB-Clients" (wie einem Notfallserver), die natürlich den gesamten Datenbestand synchronisieren und vorhalten müssen, wäre ein abgespeckter Mobil_Client mit den Daten einiger selektierter Patienten (und evtl auch nur Teilfunktionen) sinnvoll. Wichtig - die Möglichkeit auch in diesen Clients neue Patienten anlegen zu können.

Hallo Privacy,
das würde den Komfort sehr einschränken. Wer legt fest, welche Funktionen gehen sollen und welche nicht. Es gibt durchaus Nutzer, die ihre Briefvorlagen am Wochenende zu Hause überarbeiten wollen, oder die Autotexte. Außerdem müsste sich jeder Nutzer überlegen, welche Patienten sollen denn auf die mobile Version und welche nicht. Alles wahnsinnig aufwendig und aus meiner Sicht nicht praxistauglich.
VG H.Rügen

Zitat von »BurkhardStr«

- beim update (mehrere Datenbanken - einfach abgleichen lassen? ich hatte einmal ein Abgleich Problem der mobilen stationen, was meine Performance dtl negativ beeinflusst hatte)
- Impfdoc Lagerabgleich sei gestört - wie kann ich das umgehen?
- ist das bei allen clients dann möglich - damit ich endlich flüssig den Kalender nutzen kann? (nicht nur den mobilen stationen)
- warum wird so eine praktische Funktion statt in der registry nicht in der Einstellung des Arbeitsplatzes untergebracht? für alle MO-käufer zugänglich? Denn Registry-Änderungen sind prinzipiell nur für sehr erfahrene-Nutzer.

Hallo BurkhardStr,
"- beim update (mehrere Datenbanken - einfach abgleichen lassen? ich
hatte einmal ein Abgleich Problem der mobilen stationen, was meine
Performance dtl negativ beeinflusst hatte)"
Ja, vorher vollständig abgleichen lassen


- Impfdoc Lagerabgleich sei gestört - wie kann ich das umgehen?
Das kann man nicht umgehen. Wir sind stolz, dass wir ImpfDoc überhaupt in einer synchronisierenden Umgebung einsetzen können. Das war schon teuer und harte Arbeit.

- ist das bei allen clients dann möglich - damit ich endlich flüssig den Kalender nutzen kann? (nicht nur den mobilen stationen)
Ja, aber die Synchronisation erfolgt asynchron. Das bedeutet, dass je nach Leitungsqualität und Bandbreite, der Abgleich auch mal dauern kann.



- warum wird so eine praktische Funktion statt in der registry nicht in
der Einstellung des Arbeitsplatzes untergebracht? für alle MO-käufer
zugänglich? Denn Registry-Änderungen sind prinzipiell nur für sehr
erfahrene-Nutzer.

Weil dieses Vorgehen nicht der vorgesehene UseCase ist. Der UseCase der mobilen Version ist, dass der Nutzer seinen Laptop mitnimmt, überall offline arbeiten kann und wenn er den Laptop anschließend in der Praxis wieder anschließt ohne Verzögerung (weil dann sofort auf der Datenbank in der Praxis) weiterarbeiten kann, während die offline erfassten Daten im Hintergrund mit den Daten der Praxis abgeglichen werden.
Außerdem haben die überwiegende Anzahl aller Praxen schnelle und stabile Netze in denen die Nutzer arbeiten.

VG H.Rügen

[wuote]
Hallo Privacy,
das würde den Komfort sehr einschränken. Wer legt fest, welche Funktionen gehen sollen und welche nicht. Es gibt durchaus Nutzer, die ihre Briefvorlagen am Wochenende zu Hause überarbeiten wollen, oder die Autotexte. Außerdem müsste sich jeder Nutzer überlegen, welche Patienten sollen denn auf die mobile Version und welche nicht. Alles wahnsinnig aufwendig und aus meiner Sicht nicht praxistauglich.
VG H.Rügen[/quote]

Was das Arbeiten amm Volsystem von zu Hause aus angeht - dazu brauche ich keinen mobilen Client - hier nutze ich einen VPN-Tunnel und arbeite per RDP auf einem Client / Server in der Praxis.

Die Selektion der Patienten ist natürlich aufgabe des Mobilteil Nuezters. Hier könnten zB Markierungen oder ein neues Kriterium genutzt werden. Ich selbst nutze MO unterwegs NUR um loakl die eGK einzlesen und deren Daten anschießend an mein eigenes System zu übergeben - in dem die gezielte Patienten Selektion erfolgt.

Um die mobilen Cliets nicht zu überlasten, nutzen wir auch nicht das Dokumentenarchiv von MedOff, legen keine arztbriefe in MedOff ab. Besser ich organisiere eine sinnvolle Selektion, als ich verbreite zig überflüssige Daten an kleine mobile Rechner.

Sicher müsste sorgfältig austariert werden, welche selektierten Funktionen auf diesen "Mini_Mobil-Cliets" verfügbar sein sollen. Aber die Diskussion lohnt sich m.E:

Gruß Privacy
(nutzt ihre mobilen Cleints nur um die Medidatenbank nachzuschlagen und eGK einzulesen ... )

Hallo Privacy,

easymed hat(te) so eine Funktion, wo nur die benötigten Patienten übertragen werden konnten.
Reaktion der Praxen war durchweg negativ. Einerseits, weil das Synchronisieren unglaublich lange gedauert hat, anderseits weil auch wirklich nur die Patienten offline verfügbar waren.
Einige Praxen wissen vorher nicht, welche Patienten sie im Heim behandeln dürfen oder es kommt doch noch ein Patient "um die Ecke".

Wie muss ein mobiler client aufgestell sein, dass MO da flott arbeitet auch unterwegs. Sicher muss da mehr rein, als im Testteil. Oder? WEnn Geld fast keine Rolle spielt.
Falls ich das mal mache, soll das wenigstens wie in der Praxis laufen.
bro

Zitat von »Sascha Ruß«

Hallo Privacy,

easymed hat(te) so eine Funktion, wo nur die benötigten Patienten übertragen werden konnten.
Reaktion der Praxen war durchweg negativ. Einerseits, weil das Synchronisieren unglaublich lange gedauert hat, anderseits weil auch wirklich nur die Patienten offline verfügbar waren.
Einige Praxen wissen vorher nicht, welche Patienten sie im Heim behandeln dürfen oder es kommt doch noch ein Patient "um die Ecke".

Ich hatte oben geschreiben, dass die Patstamm auf jeden Fall in die moblien Clients gehört, damit man keinen Pat. doppelt anlegt.
Ansonsten abere nur eine Auswahl an Pat - das trifft nsbesondere alles was an Fremdbefunden und sonstigen Blobs die Datenbank aufbläht.

90% der Patienten bei jeder Heimvisite sind vorher bekannt - d.h. die Liste ändert sich wenig.

Weil wir nicht alles ver-x-fachen wollen verzichten wir komplett auf die Nutzung des Dokumentenarchives.

Viele FUnktionen von MedOff sind unterwegs entbehrlich - wenn ich sie brauche, dann von zu Hause, wo ich per VPN Tunnel auf den "dummen Clients" bzw dem Server arbeites.

Gruß

Privacy