Nebensitz, TM-sync

[hfriedrich]

Hallo,
gibt es denn im Forum niemanden, der einen Nebensitz mit TM versorgt?
Geht das nur über RDP via VPN?
TM-Sync sollte es ja schon letztes Jahr geben, wird das jemals kommen?
Zur Zeit läuft in beiden Praxen (Haupt- und Nebensitz) TM proprietär und die KV meckert (zu Recht !?), dass die Abrechungen Haupt- und Nebensitz nicht auseinander zu halten sind. Abgesehen davon, dass es sehr unvorteilhaft ist, wenn ich Patienten von Haupt- und Nebensitz nicht zusammenführen kann.
Idee ???
Gruss
Friedrich

[wahnfried]

...interessiert mich auch, da ich gerade mit einer der betreuten Freundes-Praxen die Umstellung von (1 Arzt/1 Betriebsstätte) zu (1 Arzt/1 Assi/2 Betriebsstätten) plane.

Da läuft bisher die regelmäßige Hausbesuchs-Export/Import-Übertragung vom am Wochenende zuhause benutzten Notebook incl. eingelesener KVK so problemarm, daß dies als täglicher Datenübertragungsweg zwischen den Betriebsstätten geplant war.

Grüsse, Wahnfried

[hfriedrich]

Nö, nich wirklich oda ???
Sie wollen nicht tatsächlich einen Nebensitz über das Hausbesuchsmodul versorgen?
Ich meine eine voll arbeitende Praxis, die als Nebensitz einem Hauptsitz zugeordnet ist. Das geht sicher nicht mit einem Notebook....
Herzlichst
Friedrich

[wahnfried]

...mal sehen, habe mich erst seit einer Woche in die Planung eingeklinkt, vorerst nur hardwaremäßig und betr. Installation. In der Zweigpraxis wird anfangs sicher nicht viel los sein, daher geht das mit: "morgens Gesamt-PraxisDB in der Hauptpraxis abholen und in der Zweigpraxis einkopieren oder DaSi rücksichern /abends Übertragen der Tagesarbeit mit HB-Export/Import" sicherlich einige Zeit als workaround akzeptabel.

(Ob dort DSL verfügbar ist, muß erst noch geklärt werden, die Hauptpraxis hat bisher keines... Deswegen bin ich auch gespannt auf TM.Sync, das müsste die Arbeit mit dem Hausbesuchsmodul ersetzen können...)

Grüsse, Wahnfried

[wahnfried]

Hallo allerseits,

die ersten Erfahrungen im Probebetrieb der Zweigpraxis sind folgende:

(Der Server der Zweigpraxis hat dieselbe IP und denselben Computernamen wie der Server der Hauptpraxis - er kann dadurch jederzeit als Ersatzserver in der Hauptpraxis eingesetzt werden. Der Client der Zweigpraxis hat eine eigene IP und einen eigenen PC-Namen.)

A) Art der Datenübertragung:

VOR dem Arbeitstag in der Zweigpraxis:
Datenabgleich zwischen Hauptpraxis und Zweigpraxis durch Datenrücksicherung der am vergangenen Arbeitstag zum Abschluß der Arbeit in der Hauptpraxis erstellten geprüften Datensicherung der Hauptpraxis (diese soll an einer Arbeitsstation durchgeführt worden sein, die für TurboMed-interne Datensicherung auf das USB-Laufwerk eingerichtet ist, ggfs direkt nach dem Hausbesuchsimport der Tagesarbeit der Zweigpraxis). Einleitung der Datenrücksicherung über eine Kopie der Verknüpfung "Datenrücksicherung" aus dem Windows-Startmenü: "Start - Programme - TurboMed - Datenrücksicherung", die auf dem Desktop eingefügt wird. (TurboMed darf dafür in der Zweigpraxis noch nirgendwo gestartet sein.)

NACH dem Arbeitstag in der Zweigpraxis:
Tagesarbeit-Export über das Hausbesuchsmodul: "EXPORT nach Hausbesuch" an irgendeinem Rechner der Zweigpraxis, darf bei noch laufendem TurboMed an den anderen Stationen geschehen. Anschließend wird die erzeugte BDT-Datei (im Ordner "TurboMed\BDT\Import" abgespeichert) auf den Datenträger kopiert, der für die Datenübertragung zwischen den Betriebsstätten benutzt wird. Diese Kopieraktion wird über eine Batch-Datei mit xcopy-Befehl durchgeführt, die über Desktopverknüpfung gestartet wird (leider kann dieser Pfad über die Grundeinstellungs-Verzeichnis-Pfade nicht konfiguriert und die Datei insofern nicht direkt auf den externen Datenträger geleitet werden). Danach wird an einem Arbeitsplatz, dessen Sicherung der Praxisdaten so eingestellt wird, daß die TurboMed-eigene Datensicherung ohne Rückfrage beim Beenden von TurboMed auf die Festplatte geschrieben (und ohne Rückfrage geprüft) wird, TurboMed als letztes beendet. Sinnvoll ist es, dies direkt nach dem Hausbesuchs-Export der Zweigpraxisdaten zu tun.

NACH dem Zweigpraxis-Arbeitstag in der Hauptpraxis:
Zusammenführen der Daten durch Hausbesuchsmodul "IMPORT nach Hausbesuch", dabei muß zur Quelle der BDT-Datei jeweils über den Punkt "Dateiauswahl" navigiert werden, was jedes Mal neu erforderlich ist, dafür soll im Ordner "TurboMed\BDT\Import" dieses Rechners der Praxis keine Datei vorhanden sein, damit man gleich die Dateiauswahl starten kann/muss. Nach erfolgreichem Import soll beim Beenden von TurboMed an diesem Rechner die TurboMed-interne Datensicherung (also Gesamt-Datenbestand mit integrierten Abrechnungsdaten des letzten Arbeitstages der Zweigpraxis) auf denselben Datenträger geschrieben werden, der zur Datenübertragung zwischen den Betriebsstätten benutzt wird, sofern am folgenden Tag in der Zweigpraxis wieder gearbeitet wird (in den Grundeinstellungen Datensicherungslaufwerk für Praxisdaten auf USB-Laufwerksbuchstaben setzen).


B) Folgende Schwierigkeiten sind bisher aufgetreten (mit Lösungsangabe):

1) Die Datenübertragung per Hausbesuchsmodul nach dem Arbeitstag in der Zweigpraxis überträgt nicht die Kassenbucheinträge, so daß diese nach jedem Arbeitstag in der Zweigpraxis ausgedruckt werden müssen (sonst sind sie nach der nächsten dortigen Datenrücksicherung futsch...!!). Dadurch ist das elektronische Kassenbuch das der Hauptpraxis, das Kassenbuch der Zweigpraxis wird durch die am Ende jedes Arbeitstages ausgedruckte Kassenbuch-Liste des aktuellen Tages zusammengestellt, die dann (allerdings NUR für den aktuellen Tag!! Für alle zürückliegenden Tage dürften das die Daten aus der Hauptpraxis sein...) noch allein die Einnahmen der Zweigpraxis enthält.
Lösungsidee (noch nicht überprüft): Wenn die Praxisgebührdaten anhand der Ausdruck-Liste der Zweigpraxis in der Hauptpraxis nachträglich eingepflegt werden, könnte dadurch das Kassenbuch der Hauptpraxis zum "gemeinsamen/gesamten" Kassenbuch werden. Dann wäre es ggfs. erforderlich - sofern getrennte Buchhaltung notwendig oder gewünscht ist - auch die Kassenbuch-Tagesausdrucke der Hauptpraxis jeweils vor dem Nach-Erfassen der Zweigpraxis-Daten zu sichern.

2) Die Datenübertragung überträgt anscheinend nicht die auf dem Desktop des Patienten angezeigten Praxisgebührstatus-Einträge. Diese müssen insofern per F9 vom Patienten in der Hauptpraxis nacherfasst werden. Es wird nächstes Wochenende überprüft, ob das nachträgliche Erfassen der Praxisgebühr-Stati per F9 in der Hauptpraxis dort auch das Kassenbuch ergänzt (was anzunehmen ist).

3) Die Zweigpraxis-Station mit eingetragenem Cherry ST-2052 unter "eGK/KVK-Kartenleser ohne Konnektor" (ein Client-Rechner) vergißt nach jedem Rücksichern der Hauptpraxis-Daten den Eintrag des nicht-online-fähigen eGK-Kartenlesers. Das bedeutet: diese Einstellung wird mit der PraxisDB übertragen und somit vom Server aus verwaltet. Das bedeutet wiederum, daß am Server (da gleiche IP und PC-Name wie in der Hauptpraxis) derselbe Lesegerät-Typ angeschlossen werden kann, wie in der Hauptpraxis auch installiert ist - allerdings kann ein über die "Grundeinstellungen - KVK-Leser" definiertes altes Lesegerät unabhängig davon betrieben werden (auch das eGK-fähige Orga MCT 5010/5021 !!, diese jedoch nur mit eGK-Lesefähigkeit, sofern unter "Sonstiges - eGK - Kartenleser ohne Konnektor" NICHTS eingetragen ist). Wenn in der Zweigpraxis ein anderes MKT-plus-Lesegerät installiert ist als in der Hauptpraxis, kann dies am Server nur nach täglicher Umstellung der Einstellung unter "eGK - Lesegeräte ohne Konnektor" betrieben werden. Wenn primär der Anmeldungs-Arbeitsplatz als Client konfiguriert ist, kann also prinzipiell dort ein anderes eGK-fähiges Lesegerät eingetragen werden, aber diese Einstellung geht jeweils nach der Datenrücksicherung wieder verloren (wohl weil in der HauptpraxisDB nicht bekannt...).
Lösungsidee (noch nicht überprüft): Den Lesegerät-bedienenden Zweigpraxis-Client aus der Anmeldung in der Hauptpraxis als Client anschließen und dort für diesen TurboMed-Client die Zweigpraxis-Einstellung unter "Lesegeräte ohne Konnektor" vornehmen. Diese Einstellung sollte dann auch mit der Datensicherungs-Rücksicherung übertragen werden, so dass das Lesegerät an diesem Client in der Zweigpraxis ohne Umstellerei für dieses definierte Lesegerät immer funktionieren sollte. (Das bedeutet aber auch, daß Veränderungen des Lesegerätes fast immer erfordern, daß man dies bei in der Hauptpraxis angeschlossenem Zweigpraxis-Client konfigurieren muss, damit die Einstellung nach der Datenrücksicherung erhalten bleibt.)

4) Die vor Umstellung der Lizenz auf die erweiterte Praxisform hergestellte Einzelplatzfähigkeit des Clientrechners der Zweigpraxis ist nach dem Einspielen der neuen Lizenz nicht mehr funktionsfähig. Das war zu erwarten, da die Lizenz für beide Betriebsstätten jeweils nur am Server eingespielt wurde und das Programm ja auf die alte Lizenz "geprägt" war. Daher erfordert die Möglichkeit, den Client-Rechner per Moduswechselsystem als Einzelplatz betreiben zu können, das nachträgliche Einspielen der Lizenz an diesem Client (oder dies beim Erneuern der Lizenz auch gleich an allen moduswechselnden Arbeitsplätzen ebenfalls durchführen). Wer die Prozedur mit Tagespasswort scheut, kann an diesem(n) Arbeitsplatz(plätzen) den TurboMed-Ordner umbenennen, eine Neuinstallation Einzelplatz vornehmen, diesen VOR DEM ERSTEN START mit Lizenz und PraxisDB ausstatten und nach dem Start die Inhalte der neuangelegten Local.ini/Global.ini mit den Inhalten derer aus dem umbenannten Alt-Ordner TurboMed überschreiben (alternativ die Grundeinstellungen ganz durcharbeiten....). Nur 'rüberkopieren funktioniert (meist?) nicht. (Die Wiederherstellung der Einzelplatzfähigkeit erleichtert die für Rücksicherungen und das Nachsehen alter Tagesstände erforderliche Datenrücksicherung von Festplatte, da im Einzelplatzmodus des Client-Rechners eine Datenrücksicherung die Server-PraxisDB nicht beeinflusst.)


Die vollautomatische Sicherung der Tages-Sicherungen in der Zweigpraxis auf die Festplatte ist wichtig, um bei Fehlern der Datenübertragung den Datenstand des betr. Tages im Einzelplatz-Modus dieses Sicherungsrechners rasch (per "Datenrücksicherung") wiederherstellen und jede Veränderung tagesaktuell nachvollziehen zu können. Dafür ist die Sicherungsdauer (vor Hinweis auf das Vorliegen löschbarer Sicherungen) sehr hoch gesetzt worden. Die Festplatte hat in der Sicherungs-Partition etwa 500GB Platz, daher "1460" entspr. 4 Jahre..., von Zeit zu Zeit auf CD/DVD zu brennen...

Um bei der TurboMed-internen Datensicherungs-Prozedur den USB-Stick nicht für die Prüfung der Datensicherung raus-ok-rein-ok-managen zu müssen, sind alle für die Datensicherung benutzten USB-Sticks per Hitachi-XP-Filter-Driver an allen für die Datensicherung ubzw. Datenübertragung benutzten PC als Festplatte definiert worden.

Grüsse, Wahnfried

p.s.: diese Erfahrungen werde ich hier und bald auch im WIKI weiter mitteilen/ergänzen.

[danspie]

Also ich kann nur raten VPN und RDP einzusetzen: das läuft bei uns seit über zwei Jahren vollkommen problemlos. Auch vom Zeitaufwand ist es sicher sinnvoller einmal ein vernünftiges VPN aufzusetzen und dann nicht ständig die Daten herumkopieren zu müssen. "Nebenbei" ist die Gefahr, dass dabei irgendwann ein Fehler passiert und Daten verloren gehen ist aus meiner Sicht doch sehr groß. Nur bei der Geräteanbindung ist Aufwand erforderlich, aber die dürften bei der von Wahnfried vorgestellten Lösung wohl noch wesentlich größer sein, da die Datenbanken der Gerätesoftware kaum/nicht abgeglichen werden können. Solange die DSL-Leitung steht, ist daher aus meiner Sicht VPN/DSL ideal. Für den Fall einer defekten DSl-Leitung habe ich die PraxisDB des Vortages in den Nebenbetriebsstätten dabei und habe zumindest Zugriff auf die Patientendaten. Die einträge müssen halt nach Beheben der Störung nachgetragen werden (ist bislang 1xpassiert).
A. Spiegl

[nmndoc]

Hallo,

ein interessantes Thema. Auch hier gibt es Praxen, die als "Überörtliche Berufsausübungsgemeinschaft" (heisst das so) zusammenarbeiten. Bin mir nicht sicher ob das so ist wie mit dem Nebensitz - aber auch hier wäre es schön, die Daten untereinander abgleichen zu können - z.B. für den Fall dass ein Patient im Laufenden Quartal schon in Praxen A war kann es offenbar ärger mit der KV geben wenn er nochmals in Praxis B aufgenommen wird. Ganz zu schweigen vom Zugriff auf die Kartei etc.

Bisher sind die Praxen zwar untereinander via VPN vernetzt (wegen zB Abrechnung, Updates etc), aber TM-Seitig im Prinzip völlig selbständig.
TMSync könnte da ja helfen, wenn es dann kommt, aber soweit ich weiß, wird erstmal nur die Synchronisation in EINE Richtung möglich sein. (und ich hoffe dass die dann wirklich sauber läuft...)

komplett über RDP zu arbeiten war auch einmal in der Überlegung, aber da es sich ja um jeweils komplette Praxen handelt, kann ich mir das über eine normale asynchrone DSL-Leitung (auch 16000er DSL hat in die andere Richtung i.d.Regel nur 1000-2000) schlecht vorstellen. Normales TM-Arbeiten, Karten etc geht ja noch, aber was ist z.B. mit EKG, Sono, eingescannten Dokumenten - und das muss dann alles in Echtzeit an TM (via VPN/DSL) übergeben werden...

Zur Ausfallsicherheit: mit steigender Zahl der Praxis steigt natürlich auch die Gefahr, dass an einem der Standorte die Leitung (oder der Router) ausfällt. Noch schlimmer, wenn das am Hauptsitz passiert (d.h. bei allen geht nichts mehr). Bedingt kann man sich da evtl. mit einer zweiten Leitung von einem anderen Provider (am besten z.B. Kabel und DSL) helfen, die man als failover nutzen kann. Gegen den Hardware-Ausfall hilft die Bevorratung eines Ersatzgerätes.

Dennoch: gibt es für o.g. Szenarien wirklich Jemanden, der das komplett via RDP/VPN macht?

@danspie: ich habe es so verstanden, dass Sie von Ihrem Notebook aus (Hausbesuch?) direkt mit dem TM in Ihrer Praxis arbeiten?

[2doc]

...... gibt es für o.g. Szenarien wirklich Jemanden, der das komplett via RDP/VPN macht? ja
derzeit mit 2MBit SDSL in der Hauptpraxis, wird da ja langsam für das gleiche Geld (ca.100€) eine 4MBIT Leitung zu bekommen ist aufgestockt werden...
macht nur mit SDSL am Terminalserverstandort Sinn, da nicht alleine die Geschwindigkeit sondern auch Pingzeit etc. das Geschwindigkeitsverhalten beeinflussen, man ist verblüfft was mit 2MBit alles geht...
SDSL hier von QSC, denkbar auch Versatel etc. bedeutet auch hohe Verfügbarkeit (Ausfall seit mehreren Jahren: keine, Unterbrechungen des Lieferanten nur zu Wartungszwecken in der Nacht, meist Sa/So)

[nmndoc]

hallo,

das klingt interessant: also nur nochmal für mich zum Verständnis: In der Hauptpraxis steht der TM-server und die Zweigstelle arbeitet komplett via RDP.
Können Sie mir evtl. ein wenig Details (eingesetzte Hardware/Software, Anzahl der Clients (jeweils), Sono/EKG/Dokumenten-Scan etc. an der Zweigstelle ja/nein) geben?

Gruss + danke

[danspie]

Genau so ist es: in der Hauptpraxis steht der TM-Server (Windows Server 2003), wir haben noch einen zweiten Windows Server 2003, über den RDP läuft (zudem werden die Datenbanken alle 3 Stunden auf diesen Server gespiegelt). In den Nebenbetriebsstätten haben wir ADSL-Anbindungen, an der Hauptbetriebsstätte eine 4MBit SDSL-Anbindung. In der Stammpraxis haben wir ca. 10 Clients. Weiterhin haben wir 2 Nebenbetriebsstätten mit je ca. 5Clients. In den Nebenbetriebsstätten laufen digitale EKG, Sonographe, Spiro, (fast) alles an die Hauptbetriebsstätte angebunden. Die in den Nebenbtriebsstätten angebundenen Geräte hängen an PCs die nicht über RDP verbunden sind, vielmehr läuft Turbomed lokal und holt sich die Daten über VPN vom Server in der Hauptbetriebsstätte. Diese Rechner sind sehr langsam (Aufrufen eines Pats. ca. 2min). Aber für das Schreiben eines EKGs ist dies ausreichend: zunächst Pat aufrufen, bis dieser aufgerufen ist, die Elektroden anlegen, und dann das EKG schreiben. Ausgewertet wird dann wieder über RDP-Rechner. Funktioniert bei uns wirklich sehr gut. Auch die Anbindung der Sonogrphie ist dadurch gut gelöst, das Abspeichern eines Bildes dauert ca. 5sek. - dann hat man diese Bilder aber in allen Betriebsstätten verfügbar. Gescant wird bei uns nur in der Hauptbetriebsstätte. Das macht für uns aber auch Sinn: die Nebenbetriebsstätten sind nur geöffnet zu Sprechstundenzeiten für die Patienten, sie sind medizinisch gut ausgestattet, nicht aber auf organisatorische Arbeiten optimiert. Die Hintergrundarbeiten sollen zentral in der dafür optimal ausgestatteten Hauptbetriebsstätte durchgeführt werden (z.B. leistungsfähiger Scanner in einem Büro mit einem Arbeitsplatz mit 2 Bildschirmen).
Spezielle Rückfragen gerne auch mittels PN
A. Spiegl

[Geigenberger]

Hallo Danspie,

sehr eindrucksvoll, was Sie da hier berichten.

Wir sollten vielleicht im Sommer ein Treffen in Ihrer wunderschönen Heimat (Walchensee!!) organisieren.
Netter Samstag-Abend im Hotel, vielleicht hat Frau Ramm auch Zeit.
Und am Sonntag morgen zeigen Sie uns Ihre tolle Praxis

Viele herzliche Grüße
Alfons Geigenberger

P.S.: Und das sollte dann ja auch durchaus als betriebliche Ausgabe beim Finanzamt durchgehen.

[danspie]

Lieber Herr Geigenberger,
ich würde mich sehr freuen, Sie persönlich kennen zu lernen. Eine Praxis lebt aber nicht von der Technik, sondern vom Praxisteam - und trotz gutem Team haben wir genug Probleme wie jeder andere auch - zum Glück gehört die Anbindung der Nebenbetriebsstätten nicht zu den Problemen. Gerne zeige ich Ihnen aber die Dinge, die funktionieren ) und insbesondere unsere schöne Umgebung.
Herzliche Grüße
Andreas Spiegl

[Geigenberger]

Lieber Herr Spiegl,

das mit dem Biergarten haben wir ja schon vereinbart; ich melde mich heuer auf jeden Fall 'mal bei Ihnen.

Aber was halten Sie - und andere Forums-User - ganz grundsätzlich von einer Art Forum-Treffen in netter Umgebung?

Viele Grüße
A. Geigenberger

[danspie]

Lieber Herr Geigenberger,
ich fände es eine sehr gute Idee, wenn sich daraus ein ein Forum-Treffen entwickeln würde. Es gibt sicher viele Dinge, die man noch besser im persönlichen Gespräch austauscht. Ansonsten warte ich auf Ihren Anruf )
Viele Grüße
Andreas Spiegl

[nmndoc]

@Hr Spiegl: Hatten Sie bei den langsamen Clients (EKG etc) evtl einmal geprüft, ob es nicht möglich ist TM per RDP zu starten und das jeweilige Gerät legt die Daten (also Bild, Video etc) auf einer entsprechenden Freigabe ab, auf die der TM-Client Zugriff hat (oder alternativ: über RDP lokale (HDD-)Laufwerke druchreichen)?

Ansonsten würde mich die Dimensionierung des Servers interessieren (CPU, HDDs, RAM)

In unserem Fall käme als mögliche Hürde dazu, dass die Daten der einzelnen (momentan 5-6) Praxen, ja erst einmal in einer gemeinsamen DB zusammengefasst werden müssten (Turbomed, EKG, etc). Geht das so ohne Weiteres? (wobei TM Sync das ja auch machen müsste - und ob das als Dauerlösung dann immer so reibungslos läuft...?).

In Murnau gibt es doch auch eine Unfallklinik? Die sagt mir beruflich etwas (IT-Security).

Zu o.g. Anregung: zu bestimmten Themen/Austausch könnte ein persönliches Treffen durchaus sinnvoll sein.

[danspie]

Hatten Sie bei den langsamen Clients (EKG etc) evtl einmal geprüft, ob es nicht möglich ist TM per RDP zu starten und das jeweilige Gerät legt die Daten (also Bild, Video etc) auf einer entsprechenden Freigabe ab, auf die der TM-Client Zugriff hat (oder alternativ: über RDP lokale (HDD-)Laufwerke druchreichen)

Nein, das habe ich nicht geprüft, da ich die Datenrate der USB-Geräte nicht kenne und Probleme im Betrieb sah durch die beschränkte Datenbreite des VPN. Bezüglich lokalen HDD muss ich dann ja wieder die Daten in die zentrale Datenbank bekommen - und da sehe ich keinen einfachen Weg.

Ansonsten würde mich die Dimensionierung des Servers interessieren (CPU, HDDs, RAM)

Unsere Server sind sicher keine Speedmeister: CPU Xeon 2,4GHz, 8GB Ram, 120GB Platten (RAID 1)

In unserem Fall käme als mögliche Hürde dazu, dass die Daten der einzelnen (momentan 5-6) Praxen, ja erst einmal in einer gemeinsamen DB zusammengefasst werden müssten (Turbomed, EKG, etc). Geht das so ohne Weiteres? wobei TM Sync das ja auch machen müsste - und ob das als Dauerlösung dann immer so reibungslos läuft...?).

Wir haben unsere Nebenbetriebsstätten erst seit 4 bzw. 3 Jahren und sind gleich mit der Konzeption eines zentralen Servers gestartet. Zu diesem Problem kann ich nicht viel sagen, da wurde ja schon einiges diskutiert hier im Forum. Läuft TMsync eigentlich schon?

In Murnau gibt es doch auch eine Unfallklinik? Die sagt mir beruflich etwas (IT-Security).

Ja genau, wächst ständig. War mit einigen chirurgischen Kollegen letzte Woche beim Skifahren - die haben mich wirklich fertig gemacht, meine Oberschenkel brennen allein wenn ich daran denke

Viele Grüße
A. Spiegl

[hfriedrich]

Hallo. Am Thema Praxisnebensitz beiße ich mir auch gerade die Zähne aus. TMsync wurde mir vor > 1 Jahr von Turbomed versprochen, zur Zeit gibt es da nichts Neus, so dass ich inzwischen auch mit der RDP via VPN Lösung liebäugel. Und dann ergibt sich bei mir das gleiche Problem: Hat schon einmal jeman zwei FOS-Turbomed-Datenbanken zusammengefügt zu einer Datenbank? Geht das reibungslos? Über Erfahrungen könnte man evtl einen neuen Thread aufmachen.
Gruss
Friedrich

[Roland_Colberg]

Sehr interessanter Thread hier. Die ÜÖBAG's (überörtliche Berufsausübungsgemeinschaften) scheinen ja wie die Pilze aus dem Boden zu schießen. Sehr schade, dass es da von Turbomed selbst noch keine funktionierenden Lösungen gibt. Ich hoffe aber mal, die arbeiten bereits mit Hochdruck daran, weil das ein ganz wichtiges Thema werden wird. Viele Datenbanken haben Möglichkeiten zur (a)synchronen Replikation, meines Wissens nach auch Fastobjects....

Auch wir betreiben seit 1. Januar eine Zweigpraxis, die ich in einer sehr ähnlichen Weise wie Herr Spiegl angebunden habe: SDSL 2MBit an der Hauptbetriebsstätte, 16 MBit ADSL an der Nebenbetriebsstätte, dort derzeit 4 lüfterlose "Igel"-ThinClients (bei ebay für je 30€) + 2 normale XP-PCs für angebundene Geräte (Scanner, PC-EKG). Ferner 2 Brother-Netzwerkdrucker mit je 3 Schächten für zentralen Druck, 1 Nadeldrucker mit externem Printserver.

Bei uns greifen aber alle Clients per RDP auf einen Terminalserver in der Hauptpraxis zu. Das Vetter-PC-EKG läuft lokal ohne TM-Anbindung (Patient muss manuell aufgerufen werden), speichert ohne Probleme über die VPN-Verbindung in der Datenbank in der Hauptpraxis (Windows-Freigabe). Geplant ist aber noch eine scriptgesteuerte Übergabe der Patientendaten per GDT-Datei aus der RDP-Sitzung an das lokale EKG-Programm.

Als Linuxer läuft bei mir natürlich in beiden Praxen noch je eine Asterisk-Telefonanlage, die auch über den VPN-Tunnel miteinander verbunden sind.

Fazit bisher:

• 90% der Probleme sind gelöst,
  flüssiges Arbeiten fast ohne Unterschied zur Hauptpraxis an lautlosen Arbeitsplätzen,
  kaum nennenswerte Hard- und Softwarekosten,
  ein mittlerweile nicht mehr völlig gestresster Administrator

Für lokale Treffen wäre ich natürlich immer zu haben

R. Colberg

[danspie]

Das Vetter-PC-EKG läuft lokal ohne TM-Anbindung (Patient muss manuell aufgerufen werden), speichert ohne Probleme über die VPN-Verbindung in der Datenbank in der Hauptpraxis (Windows-Freigabe).

Das hatte ich mir auch überlegt, aber ann haben sie das "Problem", dass der Link auf das vom Vetter-EKG geschriebene EKG nicht in der Karteikarte erscheint -> beim Wiederaufrufen des EKG muss dieses auch wieder per Hand gesucht werden. Auch PCs, auf denen TM in den Nebenbetriebsstätten läuft (wir haben alte Laptops) kosten kaum Geld - der Aku muss ja nichts mehr leisten - so dass es kein Problem ist, zu jedem Gerät einen PC aufzustellen (bei uns 1 PC für Sono und einer für EKG, Spiro, etc) - dann ist die Anbindung halt wirklich perfekt. Und bis man die Daten ins Vetter-EKG eingetragen hat, kann man auch 2-3min warten, bis der Pat in TM auf diesen PCs aufgerufen wurde.

Die ÜÖBAG's (überörtliche Berufsausübungsgemeinschaften) scheinen ja wie die Pilze aus dem Boden zu schießen

Dabei gibt es aber nicht nur das Problem, die Datenbanken zusammen zu führen, sondern auch das Problem, dass verschiedene Praxen unterschiedliche Bezeichnungen in der "Art"-Spalte verwenden. Das technische Zusammnführen der Datenbanken macht doch nur Sinn, wenn man gleichzeitig eine Vereinheitlichung der Art-Bezeichnungen erreichen kann! Genau das ist der Grund, weshalb ich den Vorschlag http://www.vondoczudoc.de/viewtopic.php?f=33&t=3451 gemacht habe. Ich versuche derzeit für dieses Problem Interesse zu wecken im BHAEV und KV! Offensichtlich ist das Thema bei KV/BHAEV/Softwareherstellern oder Unis bislang uninteressant - Ich habe einiges herumtelefoniert aber keiner meiner Gesprächspartner hatte sich damit auseinander gesetzt. Derzeit schreibe ich mit meinem Bruder einfach mal einen Artikel - vielleicht interessiert sich ja dann doch jemand dafür. Ich halte dieses Thema jedenfalls für sehr wichtig - weil ohne ÜÖBAG werden wir kaum auf Dauer in unseren kleinen Praxen überleben.........
A. Spiegl

[Roland_Colberg]

Das hatte ich mir auch überlegt, aber ann haben sie das "Problem", dass der Link auf das vom Vetter-EKG geschriebene EKG nicht in der Karteikarte erscheint -> beim Wiederaufrufen des EKG muss dieses auch wieder per Hand gesucht werden. Auch PCs, auf denen TM in den Nebenbetriebsstätten läuft (wir haben alte Laptops) kosten kaum Geld - der Aku muss ja nichts mehr leisten - so dass es kein Problem ist, zu jedem Gerät einen PC aufzustellen (bei uns 1 PC für Sono und einer für EKG, Spiro, etc) - dann ist die Anbindung halt wirklich perfekt. Und bis man die Daten ins Vetter-EKG eingetragen hat, kann man auch 2-3min warten, bis der Pat in TM auf diesen PCs aufgerufen wurde.

Ablauf bei uns derzeit:

• 1. In RDP-Sitzung Patient in TM aufrufen, F3, EKG-Programm wie gewohnt aus TM aufrufen (damit wird der Pat. ggf. in der Vetter-DB angelegt)
  2. RDP-Sitzung verlassen, EKG-Programm lokal starten, Pat. suchen, EKG schreiben und speichern
  3. EKG-Programm wieder beenden, zurück in RDP-Sitzung
  4. Dort das geschriebene EKG öffnen (PC-EKG läuft ja noch), EKG-Programm schließen.... voila, Verknüpfung in F3 ist gesetzt!

R. Colberg