VonDoczuDoc.de

Diese Version läuft bei uns seit gut einer Woche stabil.

Einzige aber wichtige Einschränkung: Die Wartezimmerliste bitte nur über den untypischen Schließen-Button beenden, sonst stürzt TurboMed ab.

Viele Grüße von DocET.

Hallo!

Ich habe vor 1 Woche von 24.1.1 auf 24.2.2 geupdatet. Update problemlos und relativ schnell. Bisher keine neuen Probleme. Das eMuster-Center ist ein wenig geschmeidiger geworden.
Wartezimmerliste lässt sich nicht mehr mit dem Klick auf das Kreuz schließen, mit Esc geht es aber noch.

Viele Grüße,
SL

Dass die Wartezimmerliste nicht mehr über das X geschlossen werden kann, ist Absicht und in "Das ist neu" dokumentiert (Punkt 3.20.10: Wartezimmerliste bleibt im Hintergrund geöffnet).
Übrigens ist das schon seit 24.2.1. so.

Danke für die Tips. nach update auf 24.2.2 läuft alles.
Weiterhin gelegentliche Abstürze beim Tippen in die F3. Hängt anscheinend davon ab, mit welcher TM-Version der Rechner erstinstalliert wurde.
eAU und e Rezept nutzen wir nur sporadisch zum Nachweis gegenüber der KV, da viel zu zeitraubend! Läuft aber. Nicht vergessen: bei Start der Abrechnung die Kreuze bei ePA NFDM etc. setzen! Sonst Abzug der Förderung!!
Gruß

Heilberger hat geschrieben: ↑Samstag 15. Juni 2024, 12:34 Danke für die Tips. nach update auf 24.2.2 läuft alles.
Weiterhin gelegentliche Abstürze beim Tippen in die F3. Hängt anscheinend davon ab, mit welcher TM-Version der Rechner erstinstalliert wurde.

Interessante These...

Heilberger hat geschrieben: eAU und e Rezept nutzen wir nur sporadisch zum Nachweis gegenüber der KV, da viel zu zeitraubend! Läuft aber. Nicht vergessen: bei Start der Abrechnung die Kreuze bei ePA NFDM etc. setzen! Sonst Abzug der Förderung!!
Gruß

Tatsächlich? Nach anfänglicher Skepsis finden alle es immer besser. Außer dem entrüsteten "wie, ihr schickt das nicht automatisch an den Arbeitgeber?" sehen wir (wenn es funktioniert) eine Verbesserung des workflow.

Da, möchte ich @scottsdalegirl ausdrücklich zustimmen. Wir sind kein "Vorreiter" bei der Implementierung dieser TI gewesen, weil es viel zu lange mit Instabilitäten behaftet war. Haben auch erst Ende Januar 2024 die e-Module eingesetzt.Jetzt können wir den workflow durchaus akzeptieren, ist zeitlich kaum nachteiliger, und spart doch Papier und Druckermaterial. Auf der anderen Seite stehen die unsäglichen Kosten für diese TI, welche die Solidargemeinschaft für die TI-Industrie incl. CGM und aller Ableger finanziert.
Sehr positiv möchte ich unseren KIM Zugang über "kv-dox" erwähnen, klappt vom ersten Tag an problemlos. Da hat man tollen Support, welchen wir faktisch nur ein einzigstes Mal zur Erst-Installtion mit benötigt haben. Somit trägt wohl KV-dox auch wesentlich zur Stabilität unseres Systems mit bei und gewährleistet wohl mit , unsere kaum vorhandenen TI Probleme .
Auf der anderen Seite steht der medisign -SMCB Account, welcher stabil, immer noch am "Montag-Vormittag" weiterhin zu Verbindungsproblemen führen kann.

Meine Beobachtung zum Sonderupdate:

es ist wohl wesentlicher netzwerkstabil, weniger Verbindungsabbrüche.

Bei mir gibt es einem PC der seit jeher durch ein selbstgekrimptes Netzwerkkabel (Ethernet Cat 5) Abbrüche beim Ping-befehl zeigt; d.h jedes 3. bis 5. Paket geht verloren.
Das führte bislang dazu das TurboMed regelmäßig nach einer gewissen Zeit abstürzte. Während es an den anderen PC mit ordentlich gekrimpten Kabel keine Abstürze oder sehr selten Abstürze gab.

Jetzt nach dem Sonderupdate 24.2.2 sind auch an diesem betreffenden PC die Turbomed-Abstürze selten geworden, z.B. heute keinen einzigen Absturz,

Grüsse aus Kiel
Johnny

der seit jeher durch ein selbstgekrimptes Netzwerkkabel (Ethernet Cat 5) Abbrüche beim Ping-befehl zeigt; d.h jedes 3. bis 5. Paket geht verloren.

Oh-mein-Gott... das ist ja wie Mensch der sagt "ja, sicher, ich habe wunde Fußsohlen und jeder Schritt tut höllisch weh, aber seit ich vor 3 Jahren am Strand war habe ich halt so viele kleine Steinchen in den Schuhen". Oder der Kettenraucher, der sich im Sprechzimmer über häufigen krampfartigen Husten beschwert... Braucht's noch mehr Beispiele??? MACH DAS KABEL GANZ!

-------------

Thomas hat geschrieben: ↑Freitag 21. Juni 2024, 07:19
der seit jeher durch ein selbstgekrimptes Netzwerkkabel (Ethernet Cat 5) Abbrüche beim Ping-befehl zeigt; d.h jedes 3. bis 5. Paket geht verloren.
Oh-mein-Gott... das ist ja wie Mensch der sagt "ja, sicher, ich habe wunde Fußsohlen und jeder Schritt tut höllisch weh, aber seit ich vor 3 Jahren am Strand war habe ich halt so viele kleine Steinchen in den Schuhen". Oder der Kettenraucher, der sich im Sprechzimmer über häufigen krampfartigen Husten beschwert... Braucht's noch mehr Beispiele??? MACH DAS KABEL GANZ!

Hallo Thomas,

ich glaube Johnny meinte, dass trotz des weiterhin genutzten selbstgekrimpten Kabels alleine durch das Update die Abstürze nicht mehr auftreten ... hat also offenbar NICHTS mit dem Crimpen zu tun ---> bevor ich Jemanden direkt angehe vielleicht erst vorher richtig lesen !
Sollte ICH falsch liegen darf Johnny jederzeit korrigierend eingreifen ...

Nur um sicherzugehen: Mein Kommentar war mit einem fetten Schmunzeln versehen - ich befürchte, diese Nuance ist leider untergegangen. Sorry, wirklich mein Fehler. (Das ohne Ironie!)

Was ich aber auf jeden Fall sagen wollte: Mein Prinzip ist, dass die untersten Level der Infrastruktur einfach funktionieren müssen. Nicht 70 oder 90%, sondern 100%. Zuverlässig. Immer. Das kostet im Verhältnis zum Ärger, den latent vorhandene Probleme verursachen, nichts - absolut nichts! Beispiel: Ein Netzwerkkabel, bei dem nur der kleine Plastiknippel abgebrochen ist, kommt in den Müll. Wenn das Kabel wegen des fehlenden Nippels etwas rausrutscht, man das nicht sieht aber lange nach dem Grund für ein Netzwerkproblem sucht, ist das Verschwendung von Zeit, Nerven und Geld. Wenn also eine Verbindung nicht dauerhaft 100% der Daten durchlässt, muss der Fehler gesucht und eliminiert werden. Das ist alternativlos! (Und das ist alles meine Meinung, jeder mag das anders handhaben.)

Also, wie gesagt, ich wollte niemanden angehen, nur mit ein wenig Ironie in den Tag starten

Bin dann mal weg...
Tschüss und schönes Wochenende

Off-topic

Sicher ließe sich vortrefflich mutmaßen, ob beim Update eine heilende Bewegung im Kabel aufgetreten ist etc.
Vielleicht ist die Schirmung weggefackelt und überträgt keine eingetragenen Störungen mehr.
Rein VDE-mäßig ist Selbercrimpen keine tolle Idee. Gilt auch für eventuelle Haftpflicht- oder andere Versicherungsschäden.

Aber das ist ja nicht das Thema. Und es ist auch nicht relevant, "was man davon halten soll". Denn offenbar war der Leidensdruck nicht allzu hoch. Ist doch fein - die innere Ruhe hätte ich auch manchmal gern.

Wahrscheinlicher als ein Kabelbruch bleibt eine möglicherweise unsaubere Verdrahtung (Belegung, Schirmung etc.).
Dabei ist es erstaunlich, wie konstant semi-stabil so eine Verbindung arbeitet.
Übrigens kann man bei Gigabit genau diesen Fall selbst ohne Testgeräte oder Zerlegen eingrenzen: Auf 100 mbps setzen: Wenn es dann stabil läuft, ist es zu 95% ein "falsch gebundener Zopf".

Es hängt oft auch von der Toleranz der angebundenen Elemente ab. So habe ich in einem lange bestehenden Netz plötzlich Paketverluste erlebt, nachdem ein VoIP-Telefon mit PoE-Injektor hinzukam. Es lag aber nicht am Telefon selbst oder am Cat7-Kabel, sondern an der Verkabelung zwischen Wanddose und Patchfeld im Serverraum. Zwar half als Sofortlösung lediglich der Umstieg von SFTP- auf ein UTP-Kabel zum Telefon und Umstellung des Telefons auf 100mbps, aber am Ende hat der elektrische Ausrüster das Patchfeld einmal neu an die Kabel angeschlossen. Seitdem ist dort alles mustergültig und stabil.

Anyway: Was spielt´s für eine Rolle, wenn wir mal eine spontane Heilung am Kabel beiseite lassen, so es denn überhaupt jemals an genau diesem Kabel gelegen hat?
Seit Update kein "Broken Link Kernel Error Gedöns" mehr lässt doch eine neuartige Resilienz vermuten. Und das ist nicht abwegig angesichts des bekannt sensiblen Verhaltens von Turbomed: Es gibt Beispiele, in denen andere Software mit dem FOS über VPN-Tunnel per holprigem LTE stabil und schnell funktioniert. Und warum sollte nicht jemand die entsprechenden Codezeilen bei TurboMed dahingehend angepasst haben, dass die Timeouts wesentlich relaxter eingestellt sind.
Paketverlust bei TCP erzeugt zunächst "nur" Latenzen durch Mehrfachübertragungen. Wenn das zuverlässig im Netz kompensiert werden kann und die beteiligten Softwaresysteme das ertragen, ja, dann ist es halt langsamer als möglich - aber stabil(er).

@Johnny : Sind die Paketverluste denn noch messbar?

Hallo,
Wir haben dass Problem, dass wir das Sonderupdate( trotz mehrfachen herunterladen vom TM-Server) nicht gestartet bekommen

Es tut sich einfach nichts

nach dem Start mit der re Maustaste.
Hat jemand aus dem Forum eine Lösung für uns?
Liebe Grüsse
Leo

leo hat geschrieben: ↑Freitag 21. Juni 2024, 10:59 Hallo,
Wir haben dass Problem, dass wir das Sonderupdate( trotz mehrfachen herunterladen vom TM-Server) nicht gestartet bekommen
Es tut sich einfach nichts nach dem Start mit der re Maustaste.
Hat jemand aus dem Forum eine Lösung für uns?
Liebe Grüsse
Leo

Wahrscheinlich sinnlos die Frage bei geübten Nutzern, trotzdem... laden Sie mit einem Download-Manager? Ist die Datei entpackt worden? Rechtsklick auf die im Ordner befindliche exe-Datei? Falls vom Stick aus gestartet Punkte-Striche ersetzen?
Ich lade die Datei grundsätzlich zu Hause mit FDM, ziehe diese auf die Platte in der Praxis und entpacke auch dort lokal.

... und vorsichtshalber immer den Hashwert der heruntergeladenen Datei prüfen!

leo hat geschrieben: ↑Freitag 21. Juni 2024, 10:59 Hallo,
Wir haben dass Problem, dass wir das Sonderupdate( trotz mehrfachen herunterladen vom TM-Server) nicht gestartet bekommen
Es tut sich einfach nichts nach dem Start mit der re Maustaste.
Hat jemand aus dem Forum eine Lösung für uns?
Liebe Grüsse
Leo

Re. Maustaste, Eigenschaften, rechts unten das Häkchen bei Zulassen setzen, dann geht es.
Wenn da kein Häkchen gesetzt werden kann, dann war es einen Versuch wert. Wahrscheinlichkeit, dass es daran lag: 80%.

Hi,
wir haben im April das Update von 24.2.1 auf 24.2.2 mit Build-Nummer 6538 durchgeführt (wg. ePa-Fehlern an die Pilot-Praxen verteilt). In diesem Update war der FOS-Wechsel von 12 auf 14 bereits integriert und lief problemslos ab. Jetzt bin ich verunsichert, was ein Update von 6538 auf 6550 (=2 mal Update auf unterschiedliche Versionen von 25.2.2) dann womöglich anrichtet. Hat irgendjemand das schon mal durchexerziert?

6550 hat diesen seltsamen Bug bei der Datensicherung nicht. Wenn es bis jetzt gut gegangen ist, sollte es so bleiben.
Demnächst kommt ohnehin die Version 25.3.

VonDoczuDoc.de

Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2

Re: Sonderupdate 24.2.2