TI Verbindungen zu den Kartenlesegeräten nicht "stabil" - viele Male pro Tag muss die TI Verbindung erneuert werden

Question

Und wir wissen nicht, woran das liegt.
Zuerst haben wir den screenlock mit Inaktivität vermutet, dann den Bildschirmschoner (bei dem aber kein Ruhezustand des Mac aktiviert wird,..) es gibt keinen offensichtlichen Bezug zu bestimmten Karten...
Manchmal ist es grün oder gelb und reagiert nicht, seit heute ist es nach einiger Zeit (im Regelfall mit Abwesenheit vom Rechner) beim Rückkehr rot (Karten / Weltkugelsymbol).
Was am Arbeitsplatz nur lästig ist und mit einer Erneuerung der Verbindung behebbar ist ist am selbstanmeldeterminal eine Katastrophe: es reagiert nicht, die Patienten beschwerden sich oder stecken die Karte, setzen sich hin und maulen, wenn Sie dann nicht aufgerufen werden..
Hat das noch jemand? Oder ist das ein Bug in unserer Praxis?

Comments

Hallo, das riecht alles nach unterschiedlichen Routen bei nicht fest vergebenen internen Praxis-IP-Adressen (evtl. Serververbindung mal über Kabel, mal über WiFi oder so - immer nett nach durch Updates erzwungenen Neustarts), die kompett gar nicht alle so im Konnektor bzw. Kartenlesegerät zu speichern sind. Die Festvergabe der Adressen müsste noch mit Bordmitteln möglich sein, das (Neu-) Eintragen der Routen ist dann Profi-Arbeit.

Grüße aus dem wilden Harz

Answer 1

Das fällt mir in letzter Zeit tatsächlich auch sehr oft auf. Bei mir wird auch manchmal gemeckert, dass mein Heilberufe Ausweis nicht erkannt wird. Dann muss ich die Verbindung aufbauen und es funktioniert alles wieder.

Answer 2

Wir haben seit vielen Monaten das gleiche Problem. Bisher gint es keine Lösung. Wir mussten das Selbstanmeldeterminal abschaffen..

Answer 3

Wir haben an einem Arbeitsplatz von dreien immer wieder ein gelbes Kärtchen und es wird ein SSL-Fehler gemeldet ‍♂️

Answer 4

Bei uns ein ähnliches Problem. Vorzugsweise an einem Arbeitsplatz, an dem wir das lesegerät nur für eHBA nutzen. Die Komfortsignatur funktioniert aber trotzdem.

Answer 5

Hat sich hier etwas getan? Wollte auch ein Selbstanmeldeterminal installieren, habe aber seit dem Konnectorwechsel zu Secunet vermehrt Probleme.

Comments

Ich habe das Selbstanmeldeterminal wieder auf ein altes Lesegerät ohne TI zurückgebaut. Alles andere war zu instabil.

---

Finde es schade, dass das seitens Zollsoft nur aufs Netzwerk geschoben wird. Welche Latenzen soll man denn erreichen, dass das passt?

---

Wir sind erst seit November bei Tomedo, d.h. Netzwerk und Software wurden kommt neu eingerichtet. Und wir haben das gleiche Problem. Ständig muss die Verbindung zur TI neu gestartet werden. Nicht ganz so toll!

---

Auch bei uns ist das Netzwerk erst ein Jahr alt. Alles neu gemacht.

---

Sehr geehrter Herr Dr. Stößel,

die TI ist eine netzwerkbasierte Anwendung und damit spielt die Netzwerkqualität eine große Rolle. Latenzen sind nicht auschlaggebend. Natürlich gibt es auch andere Fehlerquellen wie konkrete gesteckte Karten, oder das Thema mit den notwendigen Firmware-Updates für Lesegeräte.

Wenn Sie nicht zufrieden sind, würde ich immer eine Prüfung durch den Support empfehlen.

Manche Fehler lassen sich dann auch mit sogenannten Kommandozeilen-Tools unabhängig von tomedo darstellen. Das ist oft ein gutes Erkennungszeichen für Netzwerkprobleme.

---

Ich würde gerne mein Netzwerk zur Überprüfung zur Verfügung stellen. Vielleicht findet man dann für weitere Betroffene eine Lösung.

Answer 6

Guten Tag,

leider ist die Telematik sehr von einer guten Netzwerkkonfiguration abhängig. Verbindungsprobleme und Fehler bei Verbindungsaufbau oder Abfragen in das TI Netz kommen hier besonders oft bei unterschiedlichen Konfigurationen auf den Clients vor (wurde auch bereits von anderen Nutzern erwähnt). Die beste Möglichkeit ist hier, anstatt die TI Routen auf jedem Gerät zu setzen, diese zentral über den Router (bestenfalls eine HW Firewall) zu setzen. Dies stellt sicher, dass die Routen auch an der Stelle des Routers (der unbekannte Anfragen korrekt weiterleiten soll) bekannt sind und so Pakete für die Telematik an den Konnektor weitergeleitet werden und nicht in den Untiefen des Internets verschwinden. Zusätzlich verhindert dies, dass bei Änderungen am Betriebssystem oder der Konfiguration der Netzwerkschnittstelle im Rechner (WLAN auf LAN etc.) nicht die Schnittstellenspezifischen Routernkonfigurationen unter den Tisch fallen.

Die Routen können in den meisten Routern / Firewalls in den IPv4 Routing Einstellungen (statische Routen) gesetzt werden. Folgende Routen sollten angelegt werden:

188.144.0.0/15 mit Next Hop: IP Adresse des Konnektors

100.102.0.0/15 mit Next Hop: IP Adresse des Konnektors

Falls eine Firewall verwendet wird, sollten die Firewallregeln für die o.g. Netzwerke entsprechend angepasst werden, so dass ein Zugriff auf diese Netze ohne Proxy und ohne Portfilter (ausgehend) möglich ist. So vermeidet man eine Manipulation der Pakete durch die eigene Firewall und somit ein mögliches Sperren der Kommunikation durch die TI aufgrund einer vermuteten Man-in-the-middle Attacke.

Für die Kartenleser sollten als Gateway Einstellung (falls nicht per DHCP verbunden) die Router / Firewalls in der Praxisumgebung gesetzt werden. Insbesondere bei Praxisnetzwerken über mehrere Standorte, welche den selben Konnektor nutzen, ist hier eine weitere Fehlerquelle durch richtiges Routing durch den Router / Firewall ausgeschlossen.

Für Kartenleser empfiehlt sich ebenfalls das setzen einer festen IP Adresse ausserhalb des DHCP Bereiches, falls nicht bereits durchgeführt.

Comments

Toll erklärt, aber ich verstehe so gut wie gar nichts davon. Bisher konnte uns keiner der Profis helfen und uns sagen, warum die Komfortsignatur mehrmals gestartet werden muss, bis sie denn endlich funktioniert.

Wenn die TI insgesamt so kompliziert ist, dann ist es nicht alltagstauglich!

Irgendwann wird sich das wahrscheinlich, ebenso wie die Krankenhausfinanzierung über das DRG System, als großer Irrtum (Schwachsinn) herausstellen.

---

Hallo Herr Klaproth,

bitte entschuldigen Sie, wenn die Ausführungen nicht sehr gut verständlich sind. Leider begeben wir uns mit der TI sehr tief in die komplizierte Welt der Netzwerktechnik, des Routings und der Verschlüsselung. Selbst uns als Experten in dem Bereich kann es da in dem einen oder anderen Fall schon mal komisch werden.

Aufgrund dieser Komplexität kann es natürlich auch zu Fehlern kommen wie diese die Sie beschreiben. Unsere bisherige Strategie ist die erfolgreiche "Wir reissen alles ab und bauen es neu auf" um solche Probleme anzugehen. Im Falle der TI bedeutet dies, die komplette TI Konfiguration nochmal auf Start zurück zu setzen und nach den aktuellen Anforderungen neu aufzubauen (Kartengeräte neu verbinden / einrichten, Arbeitsplätze in tomedo neu konfigurieren für die TI, Abrufkontexte neu einrichten --> sehr wichtig für Komfortsignatur) und am Ende alle tomedo Clients einmal mit einem lokalen Datenbankreset frisch auf die TI loszulassen. Meistens ist danach (nach Durchführung der Anpassungen in der ersten Antwort) ein Großteil der TI Probleme behoben. Nicht geschützt ist man dadurch natürlich vor den bekannten "Bugs" bestimmter Kartenlesegeräte (ESD) oder einer unterbrochenen Internetverbindung, ausgefallener TI Systemen oder einer Überlastung der Telematik an sich.

---

Sie bestätigen gerade wie kompliziert das ist. Ich müsste mich intensiv damit beschäftigen um die Materie zu durchdringen und Ihre Ausfürhungen genau zu verstehen. Dazu fehlt mir die Zeit, aber dafür gibt es ja Spezialisten wie Sie.

Seit Einführung der TI sind in regelmäßigen Abständen am System Ergänzungen vorgenommen worden. Dafür jedes Mal alles Neu aufzusetzen ist doch ein Irrsinn. Das betrifft doch jede Praxis, die zwangsweise mit der TI arbeiten muss. Das ist zwar für versierte Spezialisten wie Sie gut, nützt aber uns Ärzten wenig. Wir brauchen ein alltaugstaugliches Arbeitsmittel. Je komplizierter das aber gemacht wird, umso störanfälliger wird es und benötigt Spezialisten wie Sie. Die Kunst besteht in der Vereinfachung. Und erst wenn es einfach ist, darf es m.E. Erst in die breite zwangsweise Anwendung gelangen.

Fazit wir sind auf Dauer gezwungen, Profis zu beschäftigen, die uns von den Systemfehlern befreien.

---

Wir haben 1:1 das beschriebene Problem. Wir nutzen eine Hardwarefirewall (Sophos). Die Routen sind über diese eingerichtet. Die Clients haben feste IPs.

Interessanterweise funktioniert es am Client A ohne Probleme, am Client B im Zimmer nebenan tritt das Problem auf. Bei Clients sind über den gleichen Switch ins Netzwerk eingebunden. Beide haben gleiche Ping Zeiten. Die Verkabelung ist neu.

---

Leider lässt sich in der aktuellen Iteration der TI die Komplexität nicht reduzieren. Ob und wie sich dies in späteren TI Erweiterungen oder in einer TI 2.0 ändert lässt sich leider aktuell noch nicht sagen.

Mein Vorschlag mit einem Neuaufbau / einer Neukonfiguration sollte nicht als Pflicht bei jeder Änderung empfunden werden. Vielmehr ist die Herstellung eines funktionstüchtigen und akzeptablen Status der Hintergedanke. Ausgehend von einem funktionstüchtigen System können auch zukünftige Änderungen besser implementiert werden ohne sich mit "Altlasten" herum zu schlagen.

@David Stenger: Sie können einmal an Ihrem zweiten Client prüfen, ob dieser separat gesetzte Telematik Routen hat (und nicht nur die Standardroute zu Ihrer Firewall verwendet). Dies können Sie im Terminal mit dem Befehl netstat -r anzeigen hier sollten nur Ihre Routen zur Firewall sowie Adressen aus ihrem internen Netzwerk auftauchen. Routen zu Telematiknetzen sollten auf den lokalen Clients in Ihrer Konfiguration nicht vorhanden sein.

Beispiel:

default            192.168.123.1       UGScg            en10       

127                127.0.0.1          UCS               lo0       

127.0.0.1          127.0.0.1          UH                lo0       

169.254            link#4             UCS              en10      !

169.254.72.31      c2:de:62:b7:97:3a  UHLSW            en10      !

192.168.123         link#4             UCS              en10      !

192.168.123.1/32    link#4             UCS              en10      !

 

Falls dort Routen zur TI auftauchen können Sie diese mit dem Befehl sudo route -n delete Netz/Netzmaske löschen.

Beispiel:

sudo route -n delete 188.144.0.0/15  (löscht die Route zur Telematik aus dem lokalen macOS Client falls vorhanden)

Hinweis: Falls Sie sich unsicher sind bei der Ausführung dieser Befehle und deren Auswirkungen, kontaktieren Sie bitte Ihren IT Betreuer oder die tomedo Support Hotline. Änderungen an den Konfigurationen dieser Systeme können im schlimmsten Fall dazu führen, dass Ihr Gerät keine Netzwerk oder Internetverbindung mehr aufbaut.

---

Hallo Herr Hillebrandt,

vielen Dank, dass Sie so ausführlich zu diesem Thema hier schreiben.

Wir haben in unserer Praxis dieses Problem ebenfalls, permanent. Es gab bereits zahlreiche Versuche, dessen Herr zu werden. Praktisch alle erfolglos.

Wir haben inzwischen das dritte Netzwerk, nunmehr nur noch "vom Feinsten" alles UniFi-Komponenten von der UDM bis zum kleinsten USW. Clients und Geräte waren zuwischenzeitlich mit festen IPs versorgt worden, ohne Erfolg. Die Konfiguration des Netzwerkes mit DHCP ist allerdings ein erprobtes und sehr zuverlässiges Verfahren, sodass auch nicht zu erwarten ist, dass die Ursache in der Verwendung dieser Technik gelegen ist. Die Verwendung der WLAN-Verbindung ist an den Clients mit verkabeltem Netwerk deaktiviert, um parallele Wege ins Netz und potentielle Probleme auszuschließen. Die Routen in die Bestandsnetze werden, wie bereits in einem anderen Beitrag beschrieben, im Router (UDM) bereitgestellt.

Unser Selbstanmeldeterminal ist inzwischen auch wegen Unbrauchbarkeit im Archiv gelandet.

Ich bin ein wenig beruhigt, dass dieser Thread zeigt, dass wir mit diesem Problem nicht alleine sind und dass es auch bei anderen keine Patentlösung dafür zu geben scheint.

Unlogisch scheint mir bei der ganzen Diskussion um potenzielle Netzwerkprobleme, dass diese - sofern real vorhanden - ausschließlich bei der TI Auswirkungen haben sollen. Die anderen betroffenen KollegInnen werden sicher bestätigen, dass im übrigen keine Probleme im Netz bemerkt wurden.

SSL-Verbindungen werden in allen Bereichen der Netzwerkkommunikation eingesetzt. Fehlererkennungs- und behandlungsroutinen sorgen dafür, dass alles reibungslos klappt und auch bei/nach Verbindungsunterbrechung die Kommunikation fortgesetzt wird. Sollte der TI diese Fähigkeit etwa fehlen?

---

Moin Herr Wuenscher

ich sehe das ganze nur aus der Froschpersektive, weil ich davon so gut wie nichts verstehe und auf Spezialisten angewiesen bin. Vermutlich trifft aber Ihre letzte Vermutung zu.

Answer 7

Sehr geehrter Herr Dr. Müller,

für das Thema mit der TI am Kiosk existiert bei uns ein Ticket.

Bei Karten einlesen über die TI kann es zu Pflicht-Rückmeldungen an die Nutzer:innen kommen. Z.b. wenn die eGK abgelaufen/gesperrt ist. Von der Konzeption ist das mit dem Kiosk schwer unter einen Hut zu bekommen, weil in den Fällen die Patienten doch an die Anmeldung müssten.

Über das angesprochene Ticket - TI Verbindung ist weg und muss von Hand neu aufgebaut werden, z.b. nach Konnektor-Neustart - denken wir bereits nach. Die Patienten sollten keinen direkten Zugriff auf TI Funktionen / Fehlermeldungen erhalten und nicht nach belieben die Verbindung neu aufbauen dürfen.

Die Aussage, bei TI Problemen müsste immer alles neu installiert werden, handhaben wir nicht so. Fehler lassen sich in der Regel schnell auf konkrete Komponenten (meistens Netzwerkswitches) zurückführen.

Wenn es doch (selten) notwendig ist, lassen sich Konnektor und Lesegeräte schnell neu einrichteten. Wenn ein Konnektor-Backup vorliegt, geht es noch schneller.

TI Routen sind zum Karten einlesen nicht notwendig, sondern nur für Zugriff auf Bestandsnetze (KV-Safenet, Krebsregister) und offene Fachdienste (KIM, EU-Zertifikate)

Comments

Sehr geehrter Herr Hesse,

da die Routen nicht notwendig sind, verstehe ich es umso weniger, dass es bei mir am Client A ohne Probleme läuft und an Client B (gleicher Switch, gleiche Config, alles gleich) zu Problemen kommt und andauernd das TI-Symbol rot ist. Durch Klick mit CMD kann direkt wieder eine Verbindung aufgebaut werden.

---

Sehr geehrter Herr Dr. Stenger,

der hier angesprochene "SSL-Fehler" bedeutet, dass die Verschlüsselung zwischen tomedo und Konnektor "aufgebrochen" wurde. Wodurch, kann tomedo nicht ermitteln. Die möglichen Ursachen reichen von harmlos (fehlerhaftes Netzwerkkabel, Datenverlust) bis hin zu absichtsvoll (jemand will Informationen "mitlesen"). Leider kann die Fehlerursache durch tomedo nicht beseitigt werden. Wir können nur eine entsprechende Meldung anzeigen.