TI-Bundle "Do-it-yourself"

[hofeBY]

7 Leser? Bekommen Sie die alle gefördert?

Welche Relevanz hat das für Sie ?
Sind halt in einer größeren aufstebenden Praxis mit mehreren Betriebsstätten angesichts längerer Pat.Schlangen einfach notwendig!
Strafzahlungen bei TI Verweigerung wären wesentlich teurer !

[nmndoc]

7 Leser? Bekommen Sie die alle gefördert?

Welche Relevanz hat das für Sie ?

Keine War nur Interesse, weil der normale Schlüssel (glaube bis 3 Ärzte 1 KT) die Realität eher unzureichend abdeckt. Es gibt aber glaube ich auch eine alternative Berechnung...?

Tatsächlich interessiert mich eher die technische Seite:

Haben Sie an jedem Standort eine SMC-B stecken, oder teilen sich alle eine gemeinsam (remote)?
Wie siehts mit der Performance aus?

[hofeBY]

Welche Relevanz hat das für Sie ?

Keine War nur Interesse, weil der normale Schlüssel (glaube bis 3 Ärzte 1 KT) die Realität eher unzureichend abdeckt. Es gibt aber glaube ich auch eine alternative Berechnung...?

Nun Ja, es sind deutlich mehr als 3 Ärzte.
Es wurde nur ein Konnector verbaut, tatsächlich haben aber zwei Betriebsstellen Anspruch auf Erstattung der Inst. Pauschale.
Später kam von der KV eine Komplexitätspauschale (da mehrere Netze/HBS/NBS) hinzu.
Ergo Mischkalkulation.

[bofh]

Link zum Urspurngspost: http://www.vondoczudoc.de/viewtopic.php ... =75#p44405

Vorsicht bei der VPN-Zugangsdienst Kostenabrechnung!
Mithin soll also die erste Berechnung der VPN-Kosten bei Online-Vertragsdurchführung erst ein bis zwei Monate nach Empfang der Geräte erfolgen. Es ist schön, dass das in den AGB und BesBG so klar geregelt ist, nur sollte sich CGM dann auch daran halten und nicht vorzeitig abrechnen und abbuchen.

Die Kommunikation seitens CGM war mal wieder erwartungsgemäß ausführlich und zeitnah. Immerhin kam nun kommentarlos nach 4 Monaten eine Stornorechnung an. Ein "wir bedauern ..." war nicht nötig.

[Sigri.]

TI - Datenschutz - Konnektornutzung im Parallelbetrieb

Guten Morgen,
Mit viel Mühe und Hilfe durch Techniker von TM habe ich, wie andere Kollegen hier auch, die Kocobox eingerichtet und mit der TM-Software verbunden.

Anfang Mai erhielt ich ein Rundschreiben der KV-Bayern, betreffend "Schutzmaßnahmen" in welchem empfohlen wurde, sich vom einrichtenden Techniker bestätigen z lassen, "dass die vorhandenen Schutzmaßnahmen vor möglichen unautorisierten Zugriffen aus dem Internet (wie Firewall, Virenscanner, o.ä.) aktiv sind." Vor allem im Parallelbetrieb.
Da ich die Einrichtung selbst vorgenommen habe, kann ich mir das natürlich nicht von externer Seite bestätigen lassen.

Heute erhielt ich, wie andere Kollegen sicher auch, erneut ein Fax von Medi-Geno Deutschland. Darin wird auf das Haftungsrisiko "wenn die Praxis gehackt wird" hingewiesen. Erneut wird die Schwachstelle: "Parallelbetrieb (ohne Firewall)" beschrieben. Ein serieller Anschluss der KoCobox wird empfohlen. Dieser wiederspricht der Anleitung zur Selbstinstallation der KoCobox.
Ich denke, dass viele Kollegen, die simultan das Internet nutzen einen parallelen Betrieb der KoCobox haben.

Nun laufen ja normalerweise die Windows Firewall und der Windows-Virenscanner automatisch beim Windowsbetrieb.
Soweit man liest sind diese im Vergleich durchaus gut brauchbare Sicherheitstools.

Meine Frage:
Ist ein Parallelbetrieb der Kocobox bei gleichzeitiger Verwendung der Windows-Firewall und des Windows Virenschutzprogrammes möglich oder besteht Handlungsbedarf, d. h. muss eine serielle Einrichtung des Konnektors erfolgen?

[baerdoc]

...Meine Frage:
Ist ein Parallelbetrieb der Kocobox bei gleichzeitiger Verwendung der Windows-Firewall und des Windows Virenschutzprogrammes möglich oder besteht Handlungsbedarf, d. h. muss eine serielle Einrichtung des Konnektors erfolgen?

Das Problem sehe ich nicht im Parallelbetrieb der Kocobox. Wenn Sie vor Installation der TI bereits eine Internetverbindung zu Ihren Praxisrechnern hatten, waren Sie auch damals schon für den Schutz der Praxisdaten verantwortlich und bei entsprechender Fahrlässigkeit auch haftbar. Ob Windows-Bordmittel ausreichen oder zusätzliche Software oder Hardware notwendig ist, darüber kann man ewig streiten. Das Hauptproblem sind meistens nicht die Hacker außerhalb Ihres Netzwerkes sondern die Nutzer (Mitarbeiter und Sie selbst) vor dem PC. Öffnen von Emails, Nutzung von fremden Daten-CD´s (z.B. Radiologie), USB-Sticks,... sind die wirklichen Risikofaktoren für Ihre Datensicherheit.

Hackt jemand aus dem "sicheren Netz" der TI über die Kocobox Ihr System, ist es egal ob parallele oder serielle Installation des Konnektors vorliegt.
Hackt jemand bei paralleler Installation über Ihren Router Ihr System von außen, müssen Sie genauso nachweisen, dass Sie hinreichende Sicherungsmaßnahmen ergriffen haben, sonst sind Sie haftbar.
Haben Sie Datenverlust durch unvorsichtigen Umgang mit Ihren eigenen PC, gilt das gleiche.

Einen 100% Schutz vor einem Angriff geht nur, wenn Sie auf die gute, alte Papierakte setzen. Wenn dann aber Ihr Türschloss nicht den aktuellen Sicherheitsvorgaben entspricht oder die Praxis im Erdgeschoss keine Fenstersicherungen hat, haben Sie aber auch wieder ein Haftungsrisiko.

[nmndoc]

Hallo,

wollten gerade für einen Remote-Standort ein KT über VPN an den Konnktor der zentrale anbinden. Leider hat schon "Kartenleser hinzufügen" im Konnektor nicht funktioniert (und entsprechend natürlich dann auch kein Pairing).
Schließe ich das KT am Hauptstandort an, geht es wie erwartet. Nun die Frage: wo liegt das Problem? Zusätzliche Routen sind im Konnektor eingetragen. Netzwerk + Default GW im KT fest/richtig eingetragen. Meldet sich das KT vielleicht nur im eigenen Segment bzw reagiert nur auf Anfragen aus dem eigenen Netz?

Würde mich mal interessieren, wie Andere das gelöst haben.

Feedback zu meinem eigenen Post/falls Jemand ein ähnliches Problem hat:
Das Problem, dass sich ein KT nicht durch den VPN-Tunnel pingen ließ, konnten wir nicht mehr nachstellen. Lt. ingenico hat das KT aber keine Funktionen, die dies verhindern.
Das Problem, dass das Pairing remote nicht ging konnten wir lösen. Offenbar war noch keine gSMC-KT eingelegt. An sich klar, dass das Pairing nicht geht - nur deutet die Fehlermeldung "Kartenleser nicht erreichbar oder aus" oder so ähnlich, dier der Konnektor bringt, in die falsche Richtung.

[nmndoc]

Nachtrag zu o.g.: Wir haben jetzt an dem Standort, an dem sich auch der Konnektor befindet die SMC-B/Praxisausweis in einem eigenen Leser, und alle anderen Standorte greifen bei Bedarf darauf zu. D.h. eigentlich greift für mein Verständnis ja immer der Konnektor darauf zu, weshalb mir diese Variante die deutlich bessere Performance zu bieten scheint, statt dass jeweils im KT des Standorts eine SMC-B steckt (da sonst die Kommunikation doppelt duch den Tunnel erfolgt).

[avd]

Henrik313:

Schritt 1:
In dem Bundle in der Kurzanleitung den Link zum KoCoGuide-Setup.exe folgen, installieren, den Guide (eine interaktiv geführte Einrichtung der Kocobox mit dem Lesegerät) ausführen und erfolgreich beenden. Dafür sorgen, dass die IPs der beiden Geräte fest sind.

Schritt 2:
Tricky ist die Anbindung an Turbomed.
Zunächst auf die Kocobox zugreifen https://KOCOBOX-IP:9443/administration/start.htm
Benutzerdaten sind im Guide vorher erstellt worden.

Dort unterm Reiter "Infomodell" den CLienten "CS-TI-Assist" löschen. Die "BSNR 01" ersetzen durch die eigene Betriebsstättennummer (zu finden in Turbomed / Sonstiges/Praxisdaten). Bei Arbeitsplatz den "Arbeitsplatz 001" ersetzen durch den Namen des eigenen Arbeitsplatzes (der Netzwerkname, in Grossbuchstaben bei mir). Unter CS-AP Objekte schauen dass dort das Objekt auch angelegt ist.

Als nächstes auf den Reiter "Fachmodul VSDM" klicken und dort unten einen Schlüssel für Prüfungsnachweis erzeugen. Sonst gibt es später einen Fehler beim Stammdatenabgleich.
Kocobox neu starten.

Schritt 3
In Turbomed in den Grundeinstellungen unter Gematik den Haken setzen, unter eKG und eKG-Leser den Haken auf Automatisch Lesen ja und und Online ABgleich VSD auch auf ja. Den Rest lassen.

Jetzt unter Sonstiges / Praxisdaten einen Haken machen bei Anbindung an den Konnektor zulassen. Nun erscheint links ein neuer eKG Reiter. Dort klicken und unter Konnektor eingeben:
Name: KoCoBox
IP: IP der Kocobox
Port: 80
Ereignisport: 45123
die beiden anderen Punkte lassen.
Eventuell TM neu starten.

Jetzt Sonstiges / eKG / eKG Konnektor konfiguration / und auf den Reiter Betriebsbereitschaft. Dort schauen ob alle Punkte grün sind. Ggf. klicken auf Betriebsbereitschaft herstellen. [...]

Liebe Kollegen, versuche mich gerade an dieser Anleitung entlangzuhangeln und scheitere leider...

1. Habe im "Infomodell" der KoCoBox den CLienten "CS-TI-Assist" gelöscht, muss auch der Mandant "M_TI-Assist" gelöscht werden?
2. Der PC an dem gearbeitet wird heißt "Anmeldung-PC" unter Windows und erscheint als "ANMELDUNG-PC" im Netzwerk, welche Schreibweise muss nun unter Punkt Arbeitsplatz in der KoCoBox hin?
3. In TM ist unter Grundeinstellungen alles wie angeraten gesetzt. Wenn ich jetzt aber unter Sonstiges / Praxisdaten einen Haken setze kann ich weiterhin keine SMB-Seriennummer eintragen (muss ich das überhaupt?) es erscheint aber links zumindest der eGK-Reiter.
--> Einstellungen (hier muss wohl nichts eingetragen werden)
--> Konnektorauswahl: hier ist kein Konnektor sichtbar, wenn ich "Neuer Eintrag" drücke erscheint "Der Benutzer Arzt hat kein Recht auf die Aktion EGK: KONFIGURATION KONNEKTOR"
--> Stationenübersicht: erneut "Der Benutzer Arzt hat kein Recht auf die Aktion EGK: KONFIGURATION KONNEKTOR"
Neustarts der KoCoBox und von TM haben nichts gebracht, irgendwie scheint TM beim Starten auch nicht ersichtlich einen Konnektor zu suchen.

Wäre für Hilfe wirklich sehr dankbar

[rfbdoc]

--> Stationenübersicht: erneut "Der Benutzer Arzt hat kein Recht auf die Aktion EGK: KONFIGURATION KONNEKTOR"
Neustarts der KoCoBox und von TM haben nichts gebracht, irgendwie scheint TM beim Starten auch nicht ersichtlich einen Konnektor zu suchen.

Geben Sie dem aktuellen TurboMed Benutzer in der Turbomed Benutzerverwaltung einfach mal alle Rechte (oder zumindest mal alle Rechte die mit der TI Installation in Zusammenhang stehen)

[avd]

@rfbdoc: Besten Dank für die hilfreiche und schnelle Antwort, genau das war der Knackpunkt, anschließend ließ sich die TI erfolgreich anschließen

[avd]

Gibt es keine Möglichkeit die KoCoBox ordnungsgemäß herunterzufahren? Geht tatsächlich nur Stromstecker ziehen, wenn man sie nicht benötigt?

[nmndoc]

Gibt es keine Möglichkeit die KoCoBox ordnungsgemäß herunterzufahren? Geht tatsächlich nur Stromstecker ziehen, wenn man sie nicht benötigt?

Ich meine, dass es in der Weboberfäche so einen Punkt gibt.
Generell sollten Sie die Box aber an lassen - ebenso den Kartenleser und NICHT immer ausschalten, wenn er mal nicht benötigt wird.

[XRAY]

Ich meine, dass es in der Weboberfäche so einen Punkt gibt.
Generell sollten Sie die Box aber an lassen - ebenso den Kartenleser und NICHT immer ausschalten, wenn er mal nicht benötigt wird.

Finde beim besten Willen nichts vergleichbares auf der Weboberfäche, über das Display-Menü lässt sich nur ein Neustart initialisieren.
Weswegen sollen denn der Konnektor und der Kartenleser auch nach Feierabend und im Urlaub laufen? Die Energiebilanz und Sicherheit werden dadurch nicht besser.

[Kasimir]

Auf der Seite "KoCoConnector.com" steht:

Wir empfehlen aus Sicherheitsgründen dringend, den Konnektor ohne Unterbrechung im Dauerstrom zu betreiben. Der Konnektor kann nur im Dauerstrombetrieb regelmäßig aktuelle Zertifikate aus der TI herunterladen. Dafür muss im Übrigen der Internetrouter/DSL-Router im Dauerstrombetrieb laufen. Zudem dauert es nach dem Abschalten einige Minuten, bis das Gerät im Netzwerk vollständig hochgefahren ist, was ggf. zu Verzögerungen im Praxisablauf führt.

[nmndoc]

Hatten hier einen interessanten Fehler / falls Jemand mal ähnliches hat:

Ausgangslage: Mehrere Standorte an einem Konnektor. Teilweise existieren die gleiche Rechnernamen - also zB "Anmeldung" - an mehreren Standorten.
Aktuell nur Jeweils ein Arbeitsplatz (+Kartenleser) an jedem Standort an TI angeschlossen.

Dass jetzt die IT-Arbeitsplätze nicht gleich heißen dürfen (m.E. schon mal ein Design-Fehler), war relativ klar. Also wurden die entsprechend umbenannt.
Nun hat sich aber gezeigt, dass auch eine Überlappung zwischen TI- und Nicht-TI-Plätzen ein Problem ist, wenn der Rechnername gleich ist. Beispiel

Standort A)
Anmeldung1 = alter Leser / USB
Anmeldung2 = Ti-eGK-Leser

Standort B)
Anmeldung = alter USB-Leser
Anmeldung1 = TI-eGK Leser

Man sieht also, dass an A/B der selbe Name vorkommt, allerdings nur einer von beiden einen TI-Leser verwendet und entsprechend im Konnektor eingetragen/gemappt ist.

Was nun aber passiert ist, dass an A-Anmeldung1 Turbomed den - offenbar global/Standortweiten Haken "Verbindung mit Konnektor zulassen" ausliest (obwohl der Arbeitsplatz ja eigentlich den Konnektor nicht verwendet/da alter Leser) und dann das KT/eGK-Leser von B-Anmeldung1 zuweist (kann man schön unter Einstellungen > eGK > Leser sehen).

Um das Problem für den Moment zu umgehen, haben wir nun auch den Nicht-TI-Arbeitsplatz umbenannt.

[baerdoc]

Hatten hier einen interessanten Fehler...

Ich finde hier keinen Fehler der TI. Lesegeräte und Arbeitstationen kommunizieren nicht mehr direkt sondern über den Konnektor.
Wenn ich in einem Netzwerk mehrere Arbeitsstationen mit gleichem Namen habe, woher soll der Postbote dann wissen, wer beliefert werden soll.

[nmndoc]

Hatten hier einen interessanten Fehler...

Ich finde hier keinen Fehler der TI. Lesegeräte und Arbeitstationen kommunizieren nicht mehr direkt sondern über den Konnektor.
Wenn ich in einem Netzwerk mehrere Arbeitsstationen mit gleichem Namen habe, woher soll der Postbote dann wissen, wer beliefert werden soll.

Es handelt sich ja genau nicht um gleiche Namen im selben (lokalen) Netz, sondern in der Gesamtstruktur TI/Konnektor - die eben mehrere Standorte/Netze anbindet.

Da die "Post" um das Problem weiß, benötigt es ja auch mehr als den Namen des Empfängers, um eine Sendung korrekt zu adressieren - zB noch Straße, Hausnr und natürlich PLZ/Ort

In der IT nimmt man hierfür ja i.d.Regel den FQDN - also Rechnername+Domain. Aber auch andere Dinge wie IP-Adresse etc wären denkbar.

Bezogen auf die TI: Ich weiß nicht, ob das in der Spezifikation der TI nicht berücksichtigt wurde (man hat ja auch an anderen Stellen den Eindruck, dass man sich etwas Anderes, als eine Einzelpraxis nicht vorstellen konnte) oder nur ein Fehler in der konkreten Implemetierung der KoCoBox bzw. Turbomed ist. Bei den Kartenlesern vergibt der Konnektor ja auch eine eindeutige ID - und verwendet die dann zur Zuordnung und eben nicht den Namen des Lesegerätes. Wäre ja kein Problem, das bei den Arbeitsplätzen auch so zu machen.
Der eigentliche "Witz" am der Sache ist ja, dass es so auch Arbeitsplätze betrifft, die gar nicht an die TI angebunden werden sollen/sind, weil TM dann denkt - oh - den Namen kenn ich doch - da weise ich mal schnell einen anderen Leser zu.

[Forti]

Hatten hier einen interessanten Fehler / falls Jemand mal ähnliches hat:

Ausgangslage: Mehrere Standorte an einem Konnektor. Teilweise existieren die gleiche Rechnernamen - also zB "Anmeldung" - an mehreren Standorten.
Aktuell nur Jeweils ein Arbeitsplatz (+Kartenleser) an jedem Standort an TI angeschlossen.

Dass jetzt die IT-Arbeitsplätze nicht gleich heißen dürfen (m.E. schon mal ein Design-Fehler), war relativ klar. Also wurden die entsprechend umbenannt.
Nun hat sich aber gezeigt, dass auch eine Überlappung zwischen TI- und Nicht-TI-Plätzen ein Problem ist, wenn der Rechnername gleich ist. Beispiel
[...]
Um das Problem für den Moment zu umgehen, haben wir nun auch den Nicht-TI-Arbeitsplatz umbenannt.

Haben die beiden gleichnamigen Geräte denn jeweils auch gleiche Druckereinstellungen verwendet?

Ich sehe hier aber immer noch kein TI-Problem, sondern nur die historisch bedingte und (nur!) in einigen Konstellationen durchaus sinnvolle Kopplung der Stationsnamen an die TM-Einstellungen. Diese greift auch bei der TI. Daran ist aber der Konnektor nicht schuld- Er bekommt die Daten so, wie die CGM das traditionsgemäß "in die DLL gegossen" hat.

[nmndoc]

Hatten hier einen interessanten Fehler / falls Jemand mal ähnliches hat:

Ausgangslage: Mehrere Standorte an einem Konnektor. Teilweise existieren die gleiche Rechnernamen - also zB "Anmeldung" - an mehreren Standorten.
Aktuell nur Jeweils ein Arbeitsplatz (+Kartenleser) an jedem Standort an TI angeschlossen.

Dass jetzt die IT-Arbeitsplätze nicht gleich heißen dürfen (m.E. schon mal ein Design-Fehler), war relativ klar. Also wurden die entsprechend umbenannt.
Nun hat sich aber gezeigt, dass auch eine Überlappung zwischen TI- und Nicht-TI-Plätzen ein Problem ist, wenn der Rechnername gleich ist. Beispiel
[...]
Um das Problem für den Moment zu umgehen, haben wir nun auch den Nicht-TI-Arbeitsplatz umbenannt.

Haben die beiden gleichnamigen Geräte denn jeweils auch gleiche Druckereinstellungen verwendet?

Ich sehe hier aber immer noch kein TI-Problem, sondern nur die historisch bedingte und (nur!) in einigen Konstellationen durchaus sinnvolle Kopplung der Stationsnamen an die TM-Einstellungen. Diese greift auch bei der TI. Daran ist aber der Konnektor nicht schuld- Er bekommt die Daten so, wie die CGM das traditionsgemäß "in die DLL gegossen" hat.

ja, wie gesagt - kann durchaus sein, dass das eher ein TM statt ein Konnektor-Problem ist. Ich nehme an, TM fragt beim Konnektor an, ob zu dem Stationsnamen ein Mapping für ein KT bekannt ist und verwendet das dann - nur leider ist das Mapping dann von einem ganz anderen - aber gleich lautenden Arbeitsplatz. Trotzdem denke ich eigentlich, hätte man hier auch mit IDs arbeiten können - macht man wie gesagt bei den KTs ja auch - und btw - nerviger Weise sogar so konsequent, dass man die ID nicht von Hand editieren kann und alte IDs (von gelöschten KTs) auch nicht wiederverwendet werden, sondern stumpf hochgezählt. Bei Überschreiten der 9999 hilft dann wohl nur noch ein Werksreset - vielleicht gelangt man aber auch in einen geheimen Level