Kategorien
Allgemein Lies die Anleitung...

TI-Installation – erster Versuch *Update 2*

Wer es eilig hat – am Ende gibt’s die technischen Details!

Es begab sich im November, als ich das erste Mal über die Telematikinfrastruktur schrieb. Ursache damals war eine Infoveranstaltung der Kassenärztlichen Vereinigung in Dortmund. Die durchaus informativen Inhalte waren aber letztlich nur eine mangelhafte Vorbereitung auf die erste TI-Installation.

Der Wahnsinn nimmt seinen Lauf

Am vergangenen Freitag war es dann so weit. Im dritten Anlauf tauchten ohne weitere Bestätigung, gleich zwei Techniker in der Praxis auf. Vollgepackt mit diversen Kartons, haben die Herren sich im Büro ausgebreitet. Als ich wenige Minuten später dazugestoßen bin, machte ich nach der obligatorischen Begrüßung direkt klar, dass ich in der Thematik relativ unwissend bin. Bis auf die bereits erwähnte Infoveranstaltung und meiner Menge, frei verfügbaren Infomaterials, entspricht das auch den Tatsachen. Immerhin war das meine erste Installation die ich begleiten durfte. Wie sich herausstellte, waren mir die Herren, gemessen an der Anzahl der Installationen, aber nicht sehr weit voraus.

 … ich bin auch erst 14 Tage dabei…

Es ging also schnell an den temporären Aufbau der mitgebrachten Geräte. Namentlich waren dass: Eine KoCoBox und ein Orga 6141online. Was schon mal schade war, denn die Praxis hatte zwei eGK-Lesegeräte an der Anmeldung. Nun… hatte. Aber auf Einzelschicksale konnte keine Rücksicht genommen werden. Kurz irritiert von dem Umstand, dass die Kollegen kein Notebook dabei hatten (Vermutung), haben wir also geklärt, wie man denn nun an die KoCoBox kommt. DHCP war der Wunsch, dem ich gerne nachgekommen bin. War leicht, denn in der selbstverständlich vorhandenen Firewall, kann ich nicht nur den Range leicht bestimmen, sondern auch recht komfortabel sehen, wer welche IP bekommen hat. Spannend ist dieser Umstand, da trotz kostenpflichtiger Vorabbesichtigung der Praxis, niemand mit mir als Systembetreuer, Kontakt aufgenommen hat. Ohne Notebook und ohne Kenntnis der Infrastruktur, hätten die Herren also ziemlich hilflos aus der Wäsche geguckt. Aber auf meinen eindringlichen Wunsch, war ich nun mal anwesend, und konnte die Herren mit den notwendigen Infos versorgen.

Papier ist ganz wesentlich… nicht alles.

Am Praxisrechner machten sich die beiden Herren also über die gerade eingebundene KoCoBox her. Nachdem man die URL (https://IPADRESSE-KoCoBox:9443/administration/start.htm) der Box schön behutsam aus der umfangreichen Dokumentation abgetippt hatte, stellte ich die erste unangenehme Frage.

…welche Ports braucht die Box denn ausgehend?

Hätte ich gewusst, dass ich mit dieser Frage ein zehnminütiges (vergebliches) Blättern in der umfangreichen Dokumentation auslöse, hätte ich damit gewartet. Wusste ich aber nicht, und sah mich plötzlich mit zwei ziemlich ratlosen, zertifizierten Technikern konfrontiert. Aber nach dem ersten Schock erklärte man mir dann, dass die Box keine Ports bräuchte. Das ginge alles von alleine. Da ich an dieser Stelle das erste Mal das Lachen kaum zurückhalten konnte, sah ich mich genötigt, dringend meine Kaffeetasse wegzustellen. In einen anderen Raum. Am liebsten in einer anderen Praxis.
Für die technisch nicht ganz so bewanderten Leser – das ich eine Firewall benutze – was ja bereits Bestandteil der Unterhaltung war – sollte dem gemeinen Techniker suggerieren, dass eben nicht alle Ports pauschal offen sind, wie das beispielsweise bei dem NAT in einer Fritz!Box oder einem Telekom Speedport der Fall ist.
Ich erklärte dann, dass ich bereits die üblichen Standardports plus IPSec freigegeben hätte. Damit war das Thema bis auf weiteres abgeschlossen, und die Kollegen widmeten sich erneut dem alles andere als übersichtlichen Webinterface.

Bürokratie wohin man schaut

Das eher kleine Büro war voll mit Papier. Und damit meine ich nicht die ausladenden Papierberge, die naturgemäß in einer Arztpraxis anfallen. Nein, ich meine damit den mittelgroßen Wald in verarbeiteter Form, den die Kollegen in Gestalt von Verträgen, Berichten, Dokumentation und diversen Hilfezetteln mitgebracht hatten. Und jedes Blatt wollte genutzt werden. Man muss den zuständigen Stellen zu dem erdachten Sicherheitskonzept der TI-Anbindung, vollumfänglich gratulieren. Derart viel Dokumentation, Abgleich von Nummern und vollkommen bekloppten Sicherungsmaßnahmen – das Kartenlesegerät macht Geräusche, wenn jemand die Einstellungen bearbeitet – habe ich noch nie gesehen. Dazu passt auch mein gescheiterter Versuch, ein weiteres Kartenlesegerät (wenigstens theoretisch) zu beschaffen. So ergab eine Recherche bei Firma Ingenico, dass man derzeit mit einer großen Anzahl von Partnern zusammenarbeitet… Okay, die umfangreiche Liste beschränkt sich aktuell ausschließlich auf die CGM… aber das wird bestimmt noch. Interessanter ist da, dass es die “sichere Lieferkette” unmöglich macht, dass man mir als Kunden von Ingenico, ein solches Kartenlesegerät zuschickt. Ich bin ja kein zertifizierter Partner. Wer aber den Text aufmerksam liest, wird bemerken, dass ein Versand direkt an die Praxis durchaus möglich wäre. Also ließ ich das telefonisch abklären… Der Hotliner begann das Gespräch quasi mit “Wir haben keine 6141online auf Lager…”. Und ja, er kenne die Regelung. Aber der Versand in die Praxis müsse erst einmal zertifiziert werden. Und wann damit zu rechnen sei, wüsste er nicht. Wir haben – Stand heute – also ein staatlich gefördertes Duopol. Und wer ein entsprechendes Kartenlesegerät erwerben möchte, kann ausschließlich bei der CGM kaufen. Zu den entsprechenden Preisen.
Aber selbst wenn man ein entsprechendes Gerät bekommt, muss man nicht glauben, dass die Einrichtung irgendwie auf dem gewohnten technischen Weg machbar ist. Ohne die TI Hotline scheint da nichts zu gehen. Das wenigstens legen die entsprechenden Schritte bei der Einrichtung nahe. Ich habe die Frage gestellt, aber der “Ich bin seit 14 Tagen dabei” Kollege, war noch nicht in der Verlegenheit, ein solches Kartenlesegerät tauschen zu müssen.
Es bleibt also abzuwarten, wie umständlich der Austausch eines Kartenlesers wird. Aber ich ahne nichts gutes.

Sind denn alle wahnsinnig?

Nach dem was ich gesehen habe, würde ich mal unterstellen, dass die unnötig komplexe Wartung der Gerätschaften in erster Linie den gesetzlichen Vorgaben geschuldet ist. Der Gesetzgeber hat versprochen, ein sicheres Netz aufzubauen… Auf jeden Fall dürfte er ein unbedienbares Netz geschaffen haben. Bleibt abzuwarten, ob andere Hersteller das eleganter hinkriegen. Und natürlich, ob der Anspruch an die Sicherheit auch nur entfernt erfüllt wird. Erfahrungsgemäß sind komplexe Systeme eher anfällig für menschliche Fehler, als einfache. Aber man muss auch sagen, dass die Umsetzung der vorgegebenen Maßnahmen, alles andere als einfach ist.
Für die Arztpraxen allerdings, ist es ein gewaltiger Schritt in die falsche Richtung. Über die Auswirkungen auf entfernte Standorte und ähnliche Konstrukte, muss ich erst nochmal nachdenken. Festhalten kann man aber schon mal, dass die Ausfallzeiten sich deutlich erhöhen dürften wenn denn mal ein Gerät den Geist aufgibt.
Aber kommen wir nochmal auf die Installation zurück. Nachdem dann die umfangreichen Abschreibearbeiten abgeschlossen waren, ging es an den ersten Verbindungsversuch. Und auch die Frage nach einem Anschluss an das KV-Safenet, wurde mittlerweile von der Hotline beantwortet. Denn auch das wusste der Kollege leider nicht. Das ist wichtig, denn ein zusätzlicher KV-Safenet-Router ist mit Anbindung an die TI, nicht mehr zwingend notwendig. Und angesichts der komplexen technischen Einrichtung, auch nicht empfehlenswert. Aber, und das muss man wissen (als ausführender Techniker), braucht es dafür weitere Arbeitsschritte. Das Netz der KVen muss nämlich “manuell” in der KoCoBox eingerichtet werden. Aber auch das haben wir gemeistert… Natürlich – ich hatte das kommen sehen – war die KoCoBox nicht in der Lage, eine Verbindung zur TI aufzubauen. Anstatt aber im Interface deutlich darauf hinzuweisen, dass es ein Verbindungsproblem gibt, dessen Ursache vermutlich irgendwo im Netzwerk zu suchen ist, gibt es kryptische Java-Fehlermeldungen. Ähhh… ja. Okay. Kann man so machen… Anfangs hatten die Kollegen, die erst kurz zuvor freigeschaltete SMC-B-Karte (“Karte” ist hier redundant, aber ansonsten versteht es keiner) in Verdacht. Denn auch dieser Vorgang ist eher kompliziert und wohl gegebenenfalls eher langwierig. Das war es aber nicht, wie ein kurzes Monitoring an der Firewall zeigte. Die KoCoBox sehnt sich nämlich neben den IPsec Standardports, noch nach TCP 8443. Was einem ja niemand sagen konnte, weil es ja “von alleine funktioniert”. Während ich also amüsiert Port 8443 der entsprechenden Firewallregel hinzugefügt habe, sah ich in den aktuellen Verbindungen etwas, dass mich wieder die Kaffeetasse wegbringen lassen wollte. Wie so ziemlich jedes andere Gerät auch, benötigt die KoCoBox ein funktionierendes DNS. Das bezieht die Kiste aber nicht von den vielen, vielen offenen DNS-Servern (9.9.9.10 z.B.), sondern von den Google Public DNS-Servern. Ja richtig, in dieser super sicheren Infrastruktur, bezieht man die Namensauflösung von Google. Ich habe nichts gegen Google! Im Gegenteil. Aber ich muss mich schon wundern, dass bei der Größe des Projektes keine eigenen DNS-Server mit entsprechender Absicherung (DNSSEC / DANE) mehr drin waren. Aber sei es drum.

Tatsächlich hat sich der Router irgendwann verbunden. Und auch den Zugriff aufs KV-SafeNet konnte ich noch erfolgreich testen. Wie genau die Nummer nun im Produktivbetrieb läuft, lässt sich noch nicht abschätzen. Prinzipiell gehe ich davon aus, dass es einigermaßen rund laufen wird. Abgesehen von dem Wegfall eines eGK-Lesers. Da selbst ein Ausfall der KoCoBox nicht dazu führt, dass die Praxis keine Karten mehr einlesen könnte, bleibe ich entspannt. Trotzdem habe ich Zweifel daran, wie praxistauglich dieses System abseits des Regelbetriebs ist. Aber das wird sich zeigen.

***Update 1a***
URL zur Box im Fließtext korrigiert. Da fehlte was.

Ich hatte technische Details versprochen was Ports und ähnliches angeht. Weil ich es gerade für jemanden zusammengeschrieben habe, hier nun eine Zusammenfassung:

  • TCP/UDP 53 (DNS)
  • TCP 80
  • TCP 443
  • UDP 123 (NTP wenn man intern keine Zeitquelle hat)
  • UDP 500 (IPSec)
  • UDP 4500 (IPSec)
  • AH / ESP (IPSec nix Ports)
  • TCP 8443 (TI / KV-SafeNet Provisionierung)
  • TCP 9443 (Zugriff von intern auf’s Webinterface bei der CGM – NICHT ausgehend!!!)
  • TCP 8500 (Zugriff von intern auf’s Webinterface bei secunet – NICHT ausgehend!!!)
  • https://IPADRESSE-KoCoBox:9443/administration/start.htm (muss bei der KoCoBox anscheinend genau so sein, sonst wird man vom Webserver (Jetty) lediglich beschimpft)
  • https://IPADRESSE-KONNEKTORvonSECUNET:8500/management

Alle Ports sind ausschließlich ausgehend konfiguriert. Kein Portforwarding, keine DMZ oder sonstige Unanständigkeiten! Wofür auch? Ist das VPN aufgebaut, kann darüber alles in beide Richtungen getunnelt werden.

*** Ende Update 1a***

*** Update 2 ***

Ich musste gerade wieder recherchieren, und habe mal alles was von Interesse sein könnte, wild zusammengeschrieben. Vielleicht findet jemand was hilfreiches. Außerdem habe ich Infos zum Secunet Konnektor zum Update 1 hinzugefügt

DNS Server TI:

100.97.139.47

100.97.139.48

100.97.148.71

100.97.148.73

===============

DNS Server KV Safennet:

188.144.7.140

188.144.15.4

===============

NTP Server TI:

100.97.139.46

100.97.139.45

===============

VPN Konzentratoren TI:

185.188.2.16 (CGM)
83.137.38.5 (DGN)

================

URL unter der ein CGM Konnektor seine Provisonierung abholt. Erfordert gültiges Konnektor-Zertifikat zum abholen!

https://register.f-vpnzugd.telemed-ti.net:8443/RegistrationServer/services/provisioningPort

================

Netzbereiche:

TI Primär:
–> 100.96.0.0/14
TI Sekundär:
— > 100.80.0.0/12
Fachdienste:
–> 100.102.0.0/16 (offen / unsicher)
–> 100.100.0.0/16 (sicher)

===============

Port Konnektor -> Kartenterminal (Orga 6141): 4742

==============

125 Antworten auf „TI-Installation – erster Versuch *Update 2*“

Hallo,

ich bin einigermaßen froh, hier diesen Artikel gefunden zu haben -). Ich schlage mich auch schon seit vielen Monaten mit mehreren TI-Installationen herum, habe Höhen und Tiefen erlebt. Grunsätzlich läuft das Alles, aber manches hat etwas von „Vodoo“ -).

Aktuell haben wir eine Neueinrichtung, erstmalig hinter einer UTM Firewall. Aus Bequemlichkeit habe ich eine ANY Regel eingerichtet, vom Konnektor in Richtung Internet. Ich habe deine Liste der Ports oben gesehen, welche von denen verwendet der Konnektor für die Kommunikation in Richtung Internet ?.
Er baut ja wohl ein VPN auf, dann sollten es maximal 53,80,443,123,500,4500,8443 sein. Dafür lohnt es sich sicher, eigene Regeln zu schreiben -)

Viele Grüße

Tom

Manches? HAHAHA. Ich könnte da mehrere „magische“ Installation zeigen. ; )
Nach Außen (vom Konnektor ins Internet) braucht es nur das Minimalprogramm: NTP, DNS, IPSec. NICHT MEHR! Das Ding guckt ggfs. nach der Uhrzeit (sofern du nichts lokales dafür einträgst). Er braucht DNS – auch hier könntest du was lokales hinterlegen. TI Provisionierung via 8443 und ab geht’s mit IPSec. Alles per NAT ausschließlich ausgehend. Danach läuft der ganze „Spaß“ über das VPN.

Danke -)). Eine eingehende NTP Regel gibt es schon ins interne Netz, ebenso DNS. IPSEC eingehend gibt es auch schon, da die UTM auch zwei VPN Verbindungen aufbaut.

Also erlaube ich ausgehend für den Konnektor IPSEC und dann sollte das laufen -). Was meinst du mit TI Provisionierung ?. Meinst du den internen Verkehr zu den Lesern damit ?

Ich glaube (hoffe) wir mißverstehen uns was ein und ausgehend angeht. Warum solltet ihr eingehendes NTP erlauben? Betreibt ihr einen Zeitserver? Und wenn die UTM nicht gerade das VPN Ziel ist, wäre „eingehend“ auch hier verkehrt. Und du schreibst, die UTM baut die Verbindungen auf. Also ist ausgehend alles was du brauchst. Es ist ein NAT: Wird intern ein Port aufgemacht, bleibt er auch für authentifizierte Antworten von extern geöffnet (stark vereinfacht).
Der Konnektor muss ausgehend IPSec machen dürfen. Entsprechende Regeln in der UTM sind (sehr wahrscheinlich) immer individuelle. Die UTM darf IPSec machen. Dein Notebook z.B. Und, so du es erlaubst, der Konnektor. Die Regeln sind normalerweise nicht allgemeingültig.
8443 geht an externe Webserver. Da registriert sich der Konnektor damit er in der TI mitspielen darf. Ohne 8443 baut er (glaube ich) schon gar nicht das VPN auf.
Die Kommunikation Konnektor mit KTs erfolgt via 80 und und 4742 rein intern. Da muss nix ins Internet dürfen.

Du hast recht, es war ein langer Tag -((((. Die UTM macht IPSEC, das tut sie sehr zuverlässig. Aber ich muß dem Konnektor doch ausgehend (Richtung Internet) IPSEC erlauben und den Port 8443 (Richtung Internet) für diese freigeben.

Ja, bezüglich ein- und ausgehend habe ich mich falsch ausgedrückt, aber es ist prima, dass du mich korrigierst, damit andere keine falschen Infos bekommen.

Hat jemand eine Empfehlung für eine HW-Firewall, um die Kocobox per Zusatz-Subnetz vom lokalen Netzwerk zu trennen, wenn sie im Parallelbetrieb betrieben wird?

Ich mag die LANCOM UF (ehemals Rhode & Schwarz ehemals Gateprotect). Das UI ab Version 10 ist Mist, aber sie arbeiten dran. Und im Zweifelsfall läuft auch noch die alte 9.8. Aber alles was man heute kaufen kann, macht den Job mehr oder weniger gut. Wichtigster Unterschied ist immer die Bedienbarkeit.
Generell gilt: In kritischen Strukturen richtet man nicht zum ersten Mal eine Firewall ein!!! Dafür holt man dann jemanden der das übernimmt und lernt dabei.

Ich will es nicht Empfehlung nennen, aber wir betreiben zwei UTM „Firewall as a Service“ in zwei Praxen und wollen eigentlich auch die anderen umstellen. Die UTM hat aus meiner Sicht eine Lernkurve wie der Aufstieg zum Mount Everest, aber einen prima Support.

Vielen Dank für die Tipps. Ich habe mich jetzt für einen Mikrotik-Router entschieden, weil er für kleines Geld volle Firewall-Funktionalität bietet und auch gutes Logging für blockierte Pakete hat.
Damit konnte ich die Kocobox vom internen Subnetz separieren, so dass nur noch das PVS, der Kartenleser und die TI (per IP-Range Whitelisting) angesprochen werden können.

Hallo Benni,

Du schreibst, dass Du ESET im Einsatz hast. Dazu habe ich eine Frage:
Welche Einstellungen hast Du in der Firewall von ESET vorgenommen?

In meinem Praxisnetz (Kunde) ist ebenso ESET Endpoint Security im Einsatz bzw soll!
Problem ist, das die Kartenterminals nicht wollen – wie sie sollen.
Als Praxissoftware läuft dort CGM Z1. Der Konnektor (KoCoBox) läuft im Parallelbetrieb mit einer Hardware-Firewall davor.
Ohne ESET funktioniert das korrekt – also Verbindung zum Konnektor bzw. Einlesen von Karten auch.
Sobald ich ESET installiere zeigt mir Z1 die Verbindung zum Konnektor sei korrekt, aber das Einlesen der Karten funktioniert nicht. An welchen Schrauben hast Du gedreht?
In den Logs von ESET sind keine weiteren Einträge zu dieser Thematik vorhanden – auch im Detaillierten Modus nicht.

Ich hoffe, Du kannst hier auch helfen.

Hallo Sven.
Ich installiere generell auf Produktivsystemen keine AV-Software mit „Firewall“. Ich bin nicht gerade Fan von Softwarefirewalls. Von daher ist dieses Problem an mir vorbeigegangen.
Die Kommunikation zwischen PVS und Konnektor erfolgt i.d.R. über Port 80. Hier könnte es mit dem ESET zu Problemen kommen. Ansonsten kommunizieren nur KTs mit Konnektor via 4742, 80 u. evtl. 443 TCP. Hier kann sich die Softwarefirewall naturgemäß nicht einmischen. Ich vermute also, dass eher die Verbindung PVS zu Konnektor gestört ist. Deaktivier mal die TLS-Prüfung (zum Test). Sofern es dass nicht schon ist, trag mal den Konnektor als vertrauenswürdige Domain in ESET ein.
Die CGM liefert doch bei ihren Programmen ein supidupi Prüftool mit?! Probier das mal von einem Client mit scharf geschalteter Firewall. Vielleicht liefert dass noch einen Anhaltspunkt. Und wenn dass alles nicht hilft: Versetz die Firewall von ESET in den Trainingsmodus. Wenn alles erfolgreich getestet wurde (oder nach einem normalen Arbeitstag) schaltest du sie wieder in den normalen Modus, exportierst die Konfig und verteilst sie an die anderen Plätze. Natürlich kannst du auch mit einem Portmonitor schauen, was von Z1 geöffnet wird. Hilft dir aber nicht, wenn vielleicht die eledige TLS-Interception dazwischen funkt.

Das fällt mir spontan dazu ein. Würde mich über eine Rückmeldung freuen. Solche Probleme kommen ja immer wieder…

Hallo Benni,
danke für Deine Anregungen.
Ich war ja eigentlich auch nicht von Softwarefirewalls überzeugt, aber seit Win10 soviel nach aussen funkt, habe ich mir dass mal genauer angesehen. Die integrierte Win10-Firewall habe ich versucht anzupassen – aber vergiß es, danach lief das System absolut instabil. Zumal bei jedem größeren Update alle Einstellungen wieder zurückgesetzt waren (zumindest was die „tollen“ Win10-Apps betrifft!). OK, mit GPO’s könnte man das auch lösen – aber Thema „instabil“.
Daher nun der Griff zum ESET mit Firewall. Hab das auch in der externen Hardware-Firewall natürlich konfiguriert (block Win-Telemetrie), aber der Traffic im Netz ging dadurch auch etwas runter.
Übrigens habe ich bei ESET das Multicast sowie alte SMB-Proto unterbunden – wäre vielleicht auch noch ein Schalter zum drehen!

Ich probiere weiter und berichte!
Danke erstmal.

@SvenS:
Konntest du dein Problem lösen?

Ich habe ein ähnliches Problem mit Z1.PRO in einer Filiale, wo die Anbindung mit dem Konnektor per VPN realisiert wird.

Die Ampel zeigt grün und „aktive“ Zugriffe auf den Konnektor sind erfolgreich. Nach einem manuellen Verbindungsaufbau mit gesteckter eGK lassen sich die Patientendaten von der Karte lesen. Aber Z1.PRO reagiert nicht automatisch auf das Stecken von eGKs, wie es soll.

Ich vermute, dass die Benachrichtigung (CARD/INSERTED), die der Konnektor an den Arbeitsplatz sendet, aus irgendeinem Grund nicht ankommt. Wenn ich in der Verwaltungsoberfläche der KoCoBox die IP-Adresse des Arbeitsplatzes zum Testen eingebe, läuft der Test erfolgreich. Daher denke ich, dass es an einer Firewall liegt.

Leider konnte ich nirgendwo herausfinden, über welches Port der Konnektor mit Z1.PRO kommuniziert. In Dampsoft DS-WIN lässt sich das Port einstellen, in Z1 anscheinend nicht.

Ich habe es selbst hinbekommen. Ich lag mit meiner Vermutung richtig, dass der Konnektor keine Verbindung zum Arbeitsplatz aufbauen kann. In die andere Richtung ging es problemlos.

Die Lösung war in meinem Fall mehrteilig:

1. Feste IP für den Arbeitsplatz im VPN definieren (also nicht nur im LAN!)
2. Statische Route vom Konnektor hin bis zum Arbeitsplatz anlegen (Router im LAN des Konnektors, VPN-Server)
3. Eingehende Verbindungen von der IP des Konnektors in der Firewall zulassen

Windows blockiert eingehende Verbindungen aus dem Subnetz der VPN-Verbindung standardmäßig und behandelt Clients aus dem entfernten Netzwerk nicht wie Client aus dem eigenen LAN. Deshalb ist Punkt 3 wichtig!

Hoffe, das hilft jemandem.

Kämpft hier sonst noch jemand mit Verzögerung beim Einlesen der Gesundheitskarten?

Wir arbeiten mit einem RISE Konnektor.
Das Einlesen einer Gesundheitskarte dauert bei uns jedes mal konstant 24 Sekunden.
Sobald wir im PVS auf Karte einlesen klicken, tut sich erst einmal nichts. Erst nach ca 20 Sekunden erscheint bei uns auf dem Kartenlesegerät der Hinweis „Daten werden gelesen..“ und anschließend erscheint auch der korrekte Patient im PVS.
Sowohl der Support vom Konnektor als auch vom PVS weisen alle Fehler von sich und lassen uns im Regen stehen.

Hat jemand Erfahrung mit ähnlichen Problemen? Ich habe die Einrichtung des Konnektors selbst vorgenommen. Übertragung unverschlüsselt Port 80, ist soweit auch im PVS eingestellt.

Baut der Konnektor vielleicht das VPN zur TI sofort wieder ab und muss es entsprechend beim nächsten Einlesevorgang erst wieder aufbauen? Kam mir jetzt als erstes in den Sinn.

Laut Weboberfläche nicht. Kennt jemand eine Möglichkeit um herauszufinden, wann der Konnektor angesprochen wird bzw ab wann der Konnektor versucht online den Datenabgleich zu starten?
Für mich wäre es ja schon ein Anfang zu wissen auf welchem Weg (PVS -> Konnektor oder Konnektor -> TI) mein Problem liegt.

Wir benutzen Telekom VDSL mit einer Fritzbox. Die MTU lässt sich in der Fritzbox manuell nicht ändern.

Lieber Jan,
bei mir dauert es etwa 10 bis 15 Sekunden, bis die Karte vom Praxisverwaltungsystem Elefant von Hasomed, Secunet-Konektor, gelesen wird. Beim Einstecken der Karte, ich verwende die Cherry-Tastatur G1505 mit integriertem Lesegerät, erscheinen in der Statusleiste vom Elefanten drei blickende Punkte im Sinne eines Fortschrittbalkens und das Feld eGK wird in Grün angezeigt.
Bei Notfallpatienten, deren eGK ich nicht mir der Cherry-Tastatur einlese, bleibt das eGK-Feld in der Statusleiste rot, da kein Stammdatenabgleich erfolgt; die Daten erscheinen aber im Praxisverwaltungsystem. Einmal hatte ich den Fall mit der Cherry-Tastatur, dass beim Einlesen der eGK das eGK-Feld die Farbe Gelb annahm. Hier lag vermutlich ein Problem mit dem zentralen Zertifikatsserver bevor. Die Daten erschienen auch hier im Praxisverwaltungssystem.
Ich vermute, die Verzögerung ist üblich, da ja der Stammdatenabgleich mit dem zentralen Server erfolgen muss. Lieber Jan,
bei mir dauert es etwa 10 bis 15 Sekunden, bis die Karte vom Praxisverwaltungsystem Elefant von Hasomed, Secunet-Konektor, gelesen wird. Beim Einstecken der Karte, ich verwende die Cherry-Tastatur G1505 mit integriertem Lesegerät, erscheinen in der Statusleiste vom Elefanten drei blickende Punkte im Sinne eines Fortschrittbalkens und das Feld eGK wird in Grün angezeigt.
Bei Notfallpatienten, deren eGK ich nicht mir der Cherry-Tastatur einlese, bleibt das eGK-Feld in der Statusleiste rot, da kein Stammdatenabgleich erfolgt; die Daten erscheinen aber im Praxisverwaltungsystem. Einmal hatte ich den Fall mit der Cherry-T
Ich vermute, die Verzögerung ist üblich, da ja der Stammdatenabgleich mit dem zentralen Server erfolgen muss.
Jetzt betreibe ich eine Psychotherapie-Praxis, wo es ruhiger zugeht. In einer Praxis mit hohem Patientenaufkommen, etwa einer Hausarztpraxis, kann die Verzögerung sicher den Betrieb behindern.

Jetzt betreibe ich eine Psychotherapie-Praxis, wo es ruhiger zugeht. In einer Praxis mit hohem Patientenaufkommen, etwa einer Hausarztpraxis, kann die Verzögerung sicher den Betrieb behindern.
Meine TI-Installation erfolgte Anfang Juli 2019, Ende August 2019 hat Hasomed die 3000 Euro abgebucht, die Erstattung erfolgt regulär mit der Quartalsabrechnung III/2019, also Ende Januar 2020, wobei man auch einen Eilantrag bei der Kassenärztlichen Vereinigung zur schnelleren Erstattung einreichen kann. Von Psychotherapeuten, die mit Psyprax arbeiten, hörte ich, dass dort noch nichts abgebucht wurde.
Insgesamt läuft die TI bei mir problemlos, wobei ich keinen Vorteil für mich oder die Patienten erkennen kann.

Freitagnachmittag, 25 Oktober, traf bei mir eine Rundmail von Hasomed bei mir ein. Man sei für die Telematik als Praxisinhaber selbst verantwortlich, man empfehle ein Sicherheitspaket eines lokalen Partners und eine Cyberrisk-Versicherung. Die Details der Angebote finden sich hier:
https://sichere-praxis-it.de/
Wenn ich das empfohlene Komplett-Paket annehmen würde, kämen zusammen mit der Cyberrisk-Versicherung im ersten Jahr rund 3000 Euro, in den Folgejahren rund 2200 jährlich auf mich zu. Diese Kosten werden nicht von der Kassenärztlichen Vereinigung erstattet.
Wie leider üblich, werden auf der Seite keine Details, wie etwa zu der Hardware-Firewall, genannt.
Mich stört die Salami-Taktik von Hasomed, erst wird ein Preis genannt und dann wird immer mehr drauf geschlagen.

Über den IT-Fachmann Jens Ernst wurde ich auf folgende Sendung von heute Abend im NDR-Fernsehen aufmerksam:

https://www.ndr.de/fernsehen/sendungen/panorama3/Panorama-3,sendung964440.html

https://www.ndr.de/fernsehen/sendungen/panorama3/Sensible-Patientendaten-in-Gefahr,patientendaten110.html

Herr Ernst zeigt den Angriff über einen Trojaner in ein Praxisnetz eines HNO-Arztes bei parallel angeschlossenen Konnektor.
Die so positiv dargestellte IT-Sicherheit in Kliniken sehe ich allerdings kritischer als die Redaktion. So kommen immer wieder Meldungen zu Ransomware in Krankenhäusern mit erheblichen Auswirkungen.

Hallo,

meine Netzwerktopologie sieht wie folgend aus:
Internet -> Speedport Pro (Hybrid) -> Hardware-Firewall -> Switch -> LAN
Alle Clients im LAN (Server+Rechner+Drucker) haben als Gateway die Firewall.

Nun hat der TI-Techniker folgendes eingerichtet mit der Begründung „doppeltes NAT mag die KoCoBox nicht“:
Internet -> Speedport Pro (Hybrid) -> Konnektor (WAN-Anschluß) – Konnektor (LAN-Anschluß) -> Switch -> LAN
Sozusagen einen Bypass um die Firewall für den Konnektor.

Leider ist seitens der Praxis WLAN am Speedport noch eingerichtet bzw. gewünscht, was ich nun vorerst deaktivieren werde!
Den Speedport in den Modem-Betrieb zu setzen ist möglich, dann funktioniert aber die Umschaltung zwischen DSL/LTE meines Wissens nicht mehr.

Für mich stellen sich nun folgende Fragen:
– blockt der Konnektor jeglichen Traffic von Außen (wenn der Speedport „überwunden ist“)?
– blockt der Konnektor den unerwünschten Traffic von Innen?

Ich hoffe Ihr könnt mir folgen und mich erleuchten! 😉

Vielen Dank, Sven

Doppeltes NAT mag kein IPSec. Manchmal nicht mal einfaches. Ich vermeide die Diskussion, in dem ich die (schmutzigen) Details einfach weglasse. ; )
Der Konnektor verfolgt eine Deny-All Strategie was Traffic von intern angeht. Von extern ist klar – einfaches NAT. Der Speedport ist irrelevant, weil dass alles über VPN läuft und der Speedport von dem getunnelten Kram eh nichts mitkriegt.
Von intern nach extern ist schon schwieriger. So weit ich weiß (Achtung – reine Spekulation!) verhält sich der Konnektor aus Gründen der Kompatiblität wie ein normaler NAT-Router. Alles von intern nach extern ist erlaubt sofern nicht anders konfiguriert.
Du hast eine (UTM?!)Firewall. Imho ist es unnötig mit dem Konnektor ein weiteres Netz aufzuspannen. Der Sicherheitsgewinn dadurch dürfte sich arg in Grenzen halten. Einfach ausprobieren ob das IPSec korrekt aufgebaut wird wenn der Konnektor als Client im Netz unterwegs ist (Parallelbetrieb). Ich gehe davon aus. Und dann einfach weiter wie bisher.

Hallo Benny,

danke für die Mühe alle Infos zum TI-Chaos zusammen zu tragen. Bei uns läuft die K.O.-Box soweit, allerdings droppt sie laut Sicherheitsprotokoll alle Pakete in Richtung KV-SafeNet, somit ist keine Webseite von denen aufrufbar. Gibts es hier einen Fallstrick?

K.O.-Box läuft als Client mit, alle Anfragen in Richtung KV-Safenet werden mittels statischer Route zu ihr geschickt. Das Netz ist allgemein durch eine UTM gesichert.

Danke im Voraus

Nein, ich kenne keinen Trick. Wenn das entsprechende Bestandsnetz aktiv ist, sollte das Routing problemlos laufen. Sofern das IPSec die UTM passieren darf, sollte das klappen. Sofern die Pakete tatsächlich an der Firewall des Konnektors scheitern, würde ich schauen ob das Bestandsnetz wirklich funktional ist…

Hallo zusammen,

hier meine Dokumentation meiner Selbstinstallation des „Do-it-yourself“ TI-Bundles der KoCoBox (KoCo Konnektor).

Insgesamt vielleicht nicht perfekt ausgearbeitet, aber es sind bestimmt viele Punkte dabei, die es sich lohnt zu dokumentieren und die für andere vielleicht von Interesse sein können.

Ausgangspunkt ist eine virtuelle Windows-Maschine, auf welcher das AIS läuft. Dies ist der einzige Windows-Rechner im Netz, und dieser hat normalerweise keinerlei Zugang zum Internet. Nur zum Einspielen aller Sicherheitsupdates wird dieser Rechner einmal pro Monat vom Administrator „ins Internet gelassen“. Die restliche Infrastruktur drumherum basiert vollkommen auf Linux.

Ziel war es, den Konnektor in einem eigenen Subnetz zu isolieren, so dass aus dem „sicheren“ VPN keinerlei Zugriff auf das Intranet und auf relevante Datenbestände erfolgen kann. Das AIS und das normale Intranet soll aber vollen Zugriff auf den Konnektor haben.

Erreicht habe ich das Ziel in mehreren Etappen. Ich beschreibe das ganze hier eher chronologisch mit allen Fehlschlägen. Gesamter Zeitaufwand mit vielen Fallstricken, einer gewissen Lernkurve und ohne Support: ca. 5 Arbeitstage.

1. Etappe: Konnektor in eigenem Subnetz, KoCo-Guide auf (Linux-)Drittrechner
Zuviel für den ersten Versuch gewollt! Der Konnektor akzeptiert erstmal nur Verbindungen aus dem eigenen Subnetz. Dies läßt sich aber durch NAT und Masquerading zwischen Intranet und eigenem Konnektor-Subnetz umgehen, welches man im Router/in der Firewall einrichten kann. Um den einzigen Windows-PC nicht mit dem KoCo-Guide zu kompromittieren, sollte der Guide auf einem anderen Rechner ausgeführt werden. Da aber kein weiterer Windows-Rechner zur Verfügung stand, habe ich versucht, den KoCo-Guide unter Wine laufen zu lassen. Dies funktioniert leider nicht, da Wine dem KoCo-Guide nicht die richtigen Benutzerrechte in der richtigen Reihenfolge vorspielt. Interessanter Weise beschwert sich der KoCo-Guide unter Wine, dass er mit Administrator-Rechten gestartet wurde und das nicht möchte. Unter Windows gestartet – dazu gleich mehr – wird der KoCo-Guide nach dem Start aber als erstes Administrator-Rechte anfordern.

2. Etappe: Konnektor in eigenem Subnetz, KoCo-Guide auf Produktiv-Windowsrechner, der erstmal per Firewall vom Internet abgeschnitten ist
Gut, also muß doch der einizge Windows-Rechner herhalten. Der KoCo-Guide wird also auf dem Produktiv-Rechner unter einem normalen Benutzer-Account installiert. Wenn man den KoCo-Guide nun startet, braucht er volle Administrationsrechte – für was auch immer. Der Rechner hat erst einmal *keinen* Internetzugang. Ziel ist es, in der Firewall mitzuverfolgen, welche Verbindungen angefordert werden, und diese dann selektiv freizugeben. Im Ergebnis müssen folgende IP-Adresse/Protokolle ausgehend freigegeben werden, damit die Verbindungs-Überprüfung erfolgreich durchläuft:

8.8.8.8,any IPv4-Traffic:
Also alle Protokolle incl. ICMP. Hier pingt der KoCo-Guide erstmal hin, um zu sehen, ob das Internet überhaupt erreicht werden kann, danach benutzt er diesen Google-Server als DNS-Server.

185.188.0.0/22,any IPv4-Traffic:
In diesem Subnetz liegt irgendwo der „Registrierungsserver“.

84.17.168.192/27, any IPv4-Traffic:
Hier wird nach Zertifikaten gesucht.

Any host, IPv4-UDP, Port 123:
Der KoCo-Guide traut der System-Zeit nicht und will selbst auf NTP-Dienste im Internet zugreifen. Da ich hier jedesmal wo anders rauskam (unter anderem irgendwelche deutschen Unis), nehme ich an, dass die Anfragen hier über irgend einen NTP Loadbalancer laufen und man schwer vorhersagen kann, wo er denn beim nächsten mal hin möchte. Deswegen habe ich hier den ganzen Port überall hin freigegeben.

Insgesamt hätte man diese Regeln bestimmt noch restriktiver gestalten können. Für jede angeforderte IP habe ich immer gleich das gesamte Subnetz freigegeben, zu welchem diese laut RIPE gehört.

Damit verläuft die Verbindungs-Überprüfung erfolgreich durch.

Als nächstes sucht der KoCo-Guide den Konnektor und findet ihn nicht. Das liegt daran, dass der Guide nur das eigene Subnetz abscannt. Das ist in diesem Fall eine Einschränkung des KoCo-Guides und nicht des Konnektors! Man kann zwar die IP-Adresse des Konnektors von Hand eingeben, aber das funktioniert schlicht und ergreifend nicht. Auch hier glaube ich am ehesten an einen Bug im KoCo-Guide. Also doch erstmal mit dem Konnektor ins gleiche Subnetz wie der Rest.

3. Etappe: Konnektor und Kartenlesegerät im gleichen Subnetz, KoCo-Guide auf Produktiv-Windowsrechner, Internet selektiv freigegeben
Hier läuft der Guide nun mal mehr mal weniger klaglos durch. Manchmal bleibt der Guide hängen oder beschwert sich, dann einfach nochmal starten. Auf Stolpersteine gehe ich später noch ein. Damit ist der Konnektor durchkonfiguriert und läuft im gleichen Subnetz wie das restliche Intranet. Jetzt kann man schonmal probeweise mit der AIS Anbindung spielen. Und vor allem kann man sich jetzt mal auf dem Konnektor einloggen und schauen, was da alles vorkonfiguriert wurde.

4. Etappe: Once more with feeling: Konnektor und Kartenlesegerät in eigenes isoliertes Subnetz, Werksreset, kein KoCo-Guide sondern alles von Hand
Nachdem man jetzt weiß, was einen erwartet und wie das Ergebnis ungefähr auszusehen hat, kann man sich jetzt daran wagen, den Konnektor sauber von Null weg von Hand aufzusetzen. Dazu sollte man sich das Administrationshandbuch herunterladen, das eigentlich ganz gut ist. Also erstmal Werksreset und dem Handbuch folgend alles einrichten. Sollte irgendetwas nicht passen, dann sind die Fehlermeldungen und Protokolleinträge im Konnektor viel (sehr viel) hilfreicher als jede Meldung, die der KoCo-Guide oder das AIS von sich gibt. Das Kartenlesegerät ist nun auch im isolierten Netz. Ursprünglich wollte ich das Kartenlesegerät im normalen Intranet aufhängen und dessen IP für ausgehende Internetverbindungen sperren. Nach etwas nachdenken wird aber klar, dass das Kartenlesegerät für den Konnektor erreichbar sein muss, also der Konnektor muss aktiv Verbindungen zum Kartenlesegerät aufbauen können. Gleichzeitig soll aber der Konnektor keinerlei Zugriff auf das Intranet haben. Also ist es doch schlauer, den Konnektor und das Lesegerät gemeinsam in das gleiche isolierte Subnetz zu hängen, hier können sich die beiden verbindungstechnisch austoben und das Intranet bleibt isoliert.

Topologie der Netze:
Es gibt jetzt zwei Subnetze, welche nur über eine Firewall miteinander kommunizieren können. In dem einen Subnetz („Intranet“) ist alles, was vorher auch schon da war. Hier hat man seine Geräte, welchen man vertraut und erlaubt selektiv den Internet-Zugang oder auch nicht. Im zweiten Subnetz hängt nur die TI-Infrastruktur, also der Konnektor und das Kartenlesegerät. Dieses TI-Subnetz hat ausgehend vollen Zugriff auf das Internet, hat aber per Firewall keinerlei Zugriff auf das Intranet. Umgekehrt hat aber das Intranet vollen Zugriff auf das TI-Subnetz. Vom Internet her gesehen ist natürlich alles hinter der eigenen Firewall. Hier muß Incoming auch nichts aufgemacht werden. Für die Bestandsnetze muss man noch eine statische Route in Router einrichten und dafür die Konnektor-IP als Gateway eingeben. Für das KV Safenet wäre das Target z.B. 188.144.0.0/15. Und schon hat das gesamte Intranet Zugriff auf das KV Safenet.

Vorteile (vor allem, wenn man gleich bei Etappe 4 einsteigt):
-Man muss keine Löcher in die Firewall für den KoCo-Guide machen und man muss keine potentiell kompromittierende Software installieren. Dies läßt sich natürlich auch dadurch erreichen, dass man zur Konfiguration einen unabhängigen Windows-Laptop im TI-Subnetz für den KoCo-Guide nutzen würde.
-Die Fehler- und Statusmeldungen der Konnektors sind oft aussagekräftiger als die des KoCo-Guides.
-Der KoCo-Guide macht einige „interessante“ Konfigurationsentscheidungen, die vielleicht nicht jeder in dieser Form möchte (siehe unten).
-Sollte das TI-VPN kompromittiert werden, so hat der Angreifer keinerlei Zugriff auf das Praxisnetzwerk (Intranet).

Nachteile:
-„Abonnements“ funktioneren nicht. Es gibt wohl die Möglichkeit, dass sich das AIS diverse Status-Meldungen vom Konnektor abonniert: Karte gesteckt, Update verfügbar, … Hier initiiert aber nach meinem Verständnis der Konnektor eine Verbindung in Richtung AIS, und genau das haben wir aber gesperrt. Im Alltag haben wir aber bis jetzt keinerlei Einschränkungen dadurch erlebt. Die aktive Statusabfrage geht trotzdem, und alle wichtigen Meldungen sollte man eh in regelmäßigen Abständen im Konnektor-Webinterface nachschauen.
-Zu guter Letzt die volle Paranoia: Sollte das AIS kompromittiert werden, so steht natürlich jeder Weg offen, dass das AIS über den Konnektor beliebige Daten zu wem auch immer ausschleust. Dies ließe sich prinzipbedingt nur durch eine Standalone Konnektor Lösung verhindern.

Stolpersteine und interessante Erkenntnisse:
-Beim Werksreset bootet der Konnektor nicht neu, sondern muß nach einiger Zeit stromlos gemacht werden. Details im Administrationshandbuch.
-Im Internet kann man ja hier und da lesen, dass „komischerweise“ die Bestandsnetze nicht automatisch aktiviert sind. Anscheinend werden die aber vom KoCo-Guide deaktiviert. Wenn man alles ohne KoCo-Guide macht, dann sind die nämlich von vorneherein aktiv.
-Wenn die Uhrzeit im Konnektor initial zu weit daneben ist, dann hilft oft auch der KoCo-Guide nicht mehr. Dann muss man sich in den Konnektor einloggen, unter „Verwaltung -> Leistungsumfang ONLINE“ „nicht aktiviert“ übernehmen, dann unter „Zeitdienst“ bei „Manuelle Angabe“ die Zeit richtig stellen und schließlich den „Leistungsumfang ONLINE“ wieder aktivieren. Dann den KoCo-Guide nochmals starten.
-Die im Internet beschriebenen Probleme mit gewissen Sonderzeichen an gewissen Stellen im Passwort konnte ich *nicht* nachvollziehen.
-Ganz böse ist folgendes: Der Konnektor ist ab Werk auf DHCP eingestellt. Beim ersten Booten holt er sich also seine Adresse vom DHCP Server. Läßt man nun den KoCo-Guide laufen, dann nimmt er die dynamisch zugewiesen Adresse und setzt diese als statisch! Damit hat man ein Gerät, welches eine IP aus dem DHCP Pool statisch belegt ohne dem DHCP Server darüber etwas zu sagen. Das ist… unschön!
-Der KoCo-Guide setzt die Ablaufperiode für das Passwort auf Maximum: Default 120, Maximum 365
-Wenn man den Konnektor zu oft mit dem Lesegerät pairt (weil man z.B. immer wieder einen Werksreset macht), dann sind irgendwann die Pairing-Slots im Lesegerät voll. Man muss die Pairings im Lesegerät auch wieder löschen und somit freigeben.
-Während des VPN-Aufbaus antwortet das Webinterface des Konnektors nicht, auch nicht auf Kommunikation mit dem KoCo-Guide. Dies ist dann problematisch, wenn der VPN Aufbau zwar begonnen wird aber nicht erfolgreich abgeschlossen werden kann und gleichzeitig aber auch nicht fatal fehlschlägt. Der Konnektor versucht es dann für immer weiter und ist dann „gebrickt“. Man hat erstmal keinerlei Möglichkeit mehr sich auf dem Konnektor einzuloggen, der alternative Werksreset geht aber noch. Abhilfe schafft hier, die Netzwerkverbindung des Konnektors in das Internet zu unterbrechen (z.B. per Firewall-Regel). Dann schlägt der VPN Aufbau nämlich final fehl und man kann sich wieder einloggen. Das waren 2 von den 5 Tagen.
-Wieso wurde das VPN nicht aufgebaut? Das hat eigentlich nichts mit dem Konnektor zu tun, aber da im Internet immer wieder Leute mit solchen Problemen zu finden sind, hier, was der Fehler in diesem Fall war: Zuerst hatte ich vermutet, dass die Firewall oder der Router Probleme mit IPSec Passthrough hätten, wie im Internet oft gemutmaßt wird. Das tatsächliche Problem war aber, dass die MTU im Router falsch eingestellt war. Die MTU war im Router auf den Standard von 1500 eingestellt. Unser Business-DSL Provider weist aber darauf hin, dass (speziell bei VPN Nutzung) ein davon abweichender, niedrigerer Wert genutzt werden muss. Was also passiert ist, war, dass die VPN Verbindung zwar initiiert werden konnte, die ersten VPN Pakete dann aber ohne Fehlermeldung zwischen uns und Provider verloren gegangen sind. Und der Konnektor hat es einfach immer weiter versucht, denn der initiale Handshake hat ja funktioniert. Sobald die MTU im Router auf den korrekten Wert eingestellt war, ging sofort alles. Die MTU im Konnektor muss dafür *nicht* angepasst werden.

Probleme, die noch nicht abschließend gelöst sind:
-Die TSL wird nicht zuverlässig abgerufen. Hierzu habe ich immer mal wieder (aber nicht immer!) anstehende Fehlermeldungen im Konnektor: „Bedeutung=Import der TSL-Datei fehlgeschlagen; Value=true; Error=4127“ Kann jemand ähnliches berichten?
-Wenn beim VSDM die Karte neu beschrieben werden soll, dann läuft der Konnektor oft (immer?) in einen Timeout: „Bedeutung=Der Timeout für VSDM Dienste ist erreicht.; Fehlercode=20026; ErrorType=Technical; Kontext=Der Updatevorgang dauerte mehr als 30 Sekunden. […]“ Diese Fehlermeldung findet man im Konnektor-Webinterface unter „Fachmodul VSDM -> Fehlerprotokoll“. Wie man sieht, habe ich den Timeout eh schon von 10 Sekunden auf 30 Sekunden hochgesetzt. Alle anderen VSDM Funktionen funktionieren tadellos. Auch hier: Hat jemand ein ähnliches Problem?

Creative Commons Zero

Nur ganz kurz: das AIS holt sich seine Infos vom Konnektor, nicht andersherum. In der Regel Port 80 / 443. Aber am Besten kurz die Ports mitschneiden. Das sollte kein großes Thema sein.
Was ich nicht gesehen habe: Wie kriegst du die Patientendaten der eGK in dein AIS? Oder ist es nur zu früh und ich sehe es nicht? : )

Kollegen von mir hatten nach der TI-Installation (Praxisverwaltungsprogramm Psyprax für Psychotherapie) am Folgetag Probleme, da sich Psyprax nicht mehr starten ließ. Die „kryptischen“ Fehlermeldungen waren wenig hilfreich und die Hotline war überfordert; in der Abrechnungszeit rund um den Quartalswechsel sind alle Anbieter an ihren Grenzen. Letztlich half Google bei Eingabe der Fehlermeldung weiter. Das Problem war nicht die TI, sondern ein Windows-Update, welches verhinderte, dass die Datenbank Firebird ordnungsgemäß starten konnte. Auf den Seiten von Psyprax fand sich dann auch eine Anleitung, wie man das Problem lösen konnte. Letztlich handelte es sich um eine Kleinigkeit mit hohem Frustpotential.
Ich sehe da zwei Probleme. Zum einen ist die IT-Unterstützung für die kleinen Praxen oft unzureichend und mit örtlichen Softwarehäusern habe ich überraschende Erfahrungen gemacht; Beispiel: Überforderung bei Installation eines Outlook-Mail-Postfachs. Zum anderen erlebe ich oft, dass ich das Computerwissen bei Kollegen häufig überschätze. So führt die Frage, welche Windows-10-Version verwendet wird, Home oder Pro, 1809 oder 1903, ins Leere. Ich will mich da nicht erheben, sehe nur Hindernisse in der Programmanwendung und Sicherheit. Wenn man eine Praxis betreibt, muss man sich um viele Dinge neben der Patientenversorgung kümmern und nun kommt auch noch die Telematik hinzu.
Was mich interessieren würde, ist der Austausch des Praxisrechners, falls dieser defekt oder zu langsam ist. Kann man einfach einen neuen Rechner kaufen und in Betrieb nehmen wie bisher oder muss dann wieder der zertifizierte Telematik-Techniker kommen?

Hallo,
lese gerade sehr interessiert hier die Meldungen, da ich in Kürze vor einer Installation des Secunet-Connectors stehe. Ich möchte die gleiche Konfig aufbauen wie CC0 im Artikel vorher.
Gibt es schon Infos dazu, wie man die Patientendaten aus dem Subnetz des Connectors ins AIS bekommt? Evtl. eine Port vom Connector zu einem bestimmten CLient im LAN aufmachen, der fürs EInlesen zuständig ist? Und wie ist das bei dieser Konfiguration mit dem kommenden KIM-Dienst; also wenn eingehende Arztbriefe beim Connector ankommen?
Weiß dazu schon jemand etwas?

Also zum Thema Ti kann ich nur sagen absolutes chaos…. entweder stürzt die connector software von Evident ab…. aber das größte problem ist das wir 2 Ausenpraxenbetreiben und der Connector in der Hauptpraxis obwohl die ports frei geschaltet sind und es über eine feste standlöeitung in die Außenpraxen geht nicht die Kartenterminals dort findet….

Moin in die Runde,
endlich eine Runde, wo man sich mal ausheulen kann 😉
mich fragte der „zertifizierter“ nenne ich ihn „Fachmann“ ?, der das Installiert hat, warum denn im Lancom router eine Deny All Strategie in der Firewall aktiv sei ?
Wieso braucht man diese Firewall überhapt ? KAnn das nicht aus ?
Der hatte von allen Netzwerkbasics null Peilung….Gateway. ?..Wan Mode ? , was ist das ?
Der Konnektor läuft hier im WAN Mode hinter dem Lancom, anstelle dem dann zB die klassische Gatway IP 192.168.10.1 zu geben, gibt er ihm aus der Luft gegriffen die 192.168.10.34 !!
und wunderte sich, wieso denn nun nix mehr funktionierte….
Er kapierte nicht, dass die Gateway IP nicht mehr die .1 sondern die .34 ist.

Fazit: Ohne mein Zutun hätte der das nie installieren können. Schön für 2.5 Std Arbeit 900 Eu in Rechnung gestellt.
Nach der heutigen Nachtuning Sitzung mit dem Lancom Remote Config Service wollten wir die Firewall noch so einstellen wie es vor der TI war, dass die Praxisrechner nicht surfen dürfen.
Pustekuchen: beim Tracen fanden wir raus, dass der ganze DNS Traffic über Port 4500 über die DNS der KV Safe Net getunnelt wird. Ich frage mich, wer sich sowas ausgedacht hat…..

Warte nun auf Rückmeldung der medys hotline, wie das hier nun weiter gehen soll…
Gruß Jürgen

Das verstehe ich aber nicht. Das DNS deines Praxisnetzs läuft durch den Konnektor? Also Seriellbetrieb? Konnektor ist Gateway und die Clients würden sich – so es denn erlaubt ist – über den Konnektor mit dem Internet verbinden?! Warum? Parallelbetrieb an. Konnektor im Lancom IPSec / DNS / 8443 TCP und NTP gestatten. Den Clients alles verbieten und den Lancom als Gateway eintragen. Schon kommt kein Client mehr raus. Der Konnektor kann sein VPN aufmachen. Und weil gleiches Subnetz, können alle Clients bei Bedarf mit dem Konnektor „sprechen“ – um z.B. das KV-Safenet (Bestandsnetz) zu erreichen (wegen mir mittels statischer Route am Rechner). Alternativ kann man DenyAll auch im Konnektor setzen. Aber da das Ding bisweilen „fremdbestimmt“ ist, würde ich eher den Weg über den Lancom gehen.

Hallo Benny.
Ich habe auch gerade meine ersten Erfahrungen mit 3 Technikern bei der Erstinstallation gemacht. Die haben zuerst mal das vorhandene Praxis-System komplett zerschossen. Mittlerweile soll’s aber laufen – die Praxisbetreiberin hofft inständig darauf, dass es ein paar Tage länger läuft als beim ersten Mal.
Ich habe bei meinen Recherchen gelesen, dass es eine E-Learning-Software für den exklusiven Kreis der Techniker, die vermutlich den Kuchen nicht gerne teilen wollen, geben soll. Weißt Du, wie man da dran kommt? Viele Grüße

Schönen guten Tag.
Ja, die Zertifizierung stützt sich ganz wesentlich auf Webinare u. Videokurse. Ich hab selbst aber keines gesehen. Würde mich aber auch interessieren. ; )

Bei mir wurde heute die Telematik angeschlossen, was etwa 90 Minuten dauerte; Windows 10, Hasomed Elefant. Insgesamt verlief es recht problemlos. Jetzt habe ich kein komplizierteres Netzwerk, sondern einfach eine Fritzbox 6490 Cable. Der Techniker meinte, er habe ca. 500 TI-Anschlüsse durchführt, abgesehen von einem Fall mit Reihenschaltung hätten sich alle anderen für einen Parallelanschluss entschieden.
Die Reihenschaltung, auch seriell genannt, mag vielleicht sicherer sein, aber neben den Problemen der Kompatibilität mit Internet-Schutzprogrammen, welche ihre Signaturen nicht aktualisieren können, gibt weitere Schwierigkeiten. So ist bei einer Reihenschaltung eine Fernwartung über Teamviewer oder Anydesk durch die Hotline des Herstellers des Praxisverwaltungsprogramms nach Angaben des Technikers nicht mehr möglich.
Probleme erwarte ich beim Einlesen von Karten von privaten Krankenversicherungen und Polizeibeamten (freie Heilfürsorge), da diese noch älteren Standards folgen.
Meine Cherry-Tastatur ist übrigens die dritte innerhalb von drei Jahren. Die beiden vorhergehenden funktionierten zwar noch gut, aber die Vorgaben für das Lesegerät änderten sich und so musste ein neues Modell angeschafft werden.
Letztlich habe ich die Telematik unter Zwang durchgeführt und Vorteile erwarte ich mir nicht davon, nur mehr Arbeit. So wünscht die Kassenärztliche Vereinigung, man möge doch bitte bei jedem Besuch die eGK einlesen. Nun bin ich froh, wenn die Patienten überhaupt einmal im Quartal ihre eGK mitbringen und nicht zu Hause liegen lassen. Es dauert dann doch fünf Minuten, bis die Karte ausgepackt, eingelesen und wieder eingepackt wurde.
Das Argument des Notfalldatensatzes halte ich für wenig stichhaltig. Es gibt derzeit noch viele Notfallausweise, diese brauchen noch nicht einmal ein Lesegerät und spielen dennoch im Alltag keine wesentliche Rolle.
Eher sehe ich die Gefahr, dass es bald im Vorstellungsgespräch oder Personalgespräch mit dem Vorgesetzten heißt, „als Arbeitgeber haben wir eine Fürsorgepflicht, darf unser Betriebsarzt mal einen kurzen Blick in ihre elektronische Krankenakte werfen.“

Die TI ist nun einen Monat angeschlossen und schon gibt es Probleme. Eben noch eine eGK eingelesen, dann leuchtete die Service-Leuchte am Secunet-Konnektor. Bei Hasomed ist über die Hotline niemand erreichbar (Telefonmenü, dann Ansage, man solle später anrufen) und bei der Telematikberatung der Kassenärztlichen Vereinigung ist am Freitagnachmittag auch keiner mehr.
Bei dem hohen Preis und Anschlusszwang hatte ich ein ausgereiftes Produkt erwartet, jetzt werde ich schon am Anfang im Stich gelassen und darf mich neben den Patienten auch noch um die TI kümmern.
So entsteht halt viel Frust bei Ärzten und Psychologischen Psychotherapeuten. Man hat keinen Vorteil, nur Kosten, Sicherheitsprobleme und Ärger.

Die Telematik hält mich weiter auf Trab. Heute wollte ich bei einer Patientin den Online-Datenabgleich vornehmen; die Patientin war im Quartal bereits erschienen. Es gab Probleme, die Krankenkassenkarte sei fehlerhaft. Meine Angestellte versuchte es über eine Stunde. Dann das gleiche Problem bei einer Neupatientin. Nach einer Stunde kam ich bei der Hotline durch. Man wechsle Server und Ports, sei überrascht über die Auswirkungen, viele Praxen würden anrufen und den gleichen Fehler melden. Ich hatte den Eindruck, die Hotline kennt die Abläufe in den Praxen nicht. Ja, es gibt auch Praxen, die Mittwoch am Nachmittag Patienten behandeln. Letztlich kam die Lösung über mein mobiles Lesegerät, denn wenn der Konnektor oder das Gesundheitsnetz Probleme hat, kann man keine eGK über das stationäre Lesegeräte einlesen. Auf die Idee, mal eine Rundmail mit einer Fehlermeldung zu versenden, kam man nicht.

Ich bin froh, dass ich Euch gefunden habe. Es ist so schwer an Infos zu kommen. Ich habe eine Frage an Benny oder einen fachkundigen Anderen:
Wenn ein Secunet-Konnektor im Reihenbetrieb vor einen Rechner mit Kaspersky Total Security und hinter eine Fritzbox installiert wird: 1. Welche Ports müssen dann freigegeben werden? 2. Müssen die Ports sowohl in der Fritzbox als auch in Kaspersky freigegeben werden?
Ich wäre super dankbar für Antwort!!

Hallo Jan. Schauen wir mal, was wir für dich tun können.

Hinter der FB bedeutet ja, simples NAT von LAN zu WAN. Du musst dir also keine Gedanken machen, ob der Router irgendwelche Ports blockiert, welche der Konnektor nach extern braucht (IPSec, DNS z.B.). Das geht bei den Plastikschüsseln ja immer alles.
Du hast also am WAN Port des Konnektors (Verbindung zur FritzBox) z.B. die IP 192.168.178.21 anliegen. Damit darf das Ding ins Internet und kann ein VPN zur TI aufbauen.

Fragen wir uns als, was bei der Konstellation „Rechner via Konnektor ins Internet “ (aka Seriellbetrieb) zu gewährleisten ist. Eigentlich auch nichts. Der Rechner ist mit dem LAN Port des Konnektors verbunden. Hat z.B. die IP 192.168.99.3. Standardgateway muss natürlich der Konnektor sein. DNS vermutlich auch (weil es einfacher ist). Das Kartenlesegerät ist im gleichen Netz wie der Rechner (192.168.99.xxx z.B.). Jetzt schickt der Rechner alle Anfragen Richtung Internet, an den Konnektor.
In dem müssen natürlich SIS (SecureInternetServices) aktiviert sein. Soweit ich weiß, gibt es keine Portbegrenzungen. Ist also identisch zum NAT der FritzBox. Von Intern nach Extern ist alles erlaubt. Eine Filterung findet wohl eher via DNS Blacklists statt. Ab diesem Zeitpunkt kann der Rechner (bestens beschützt durch die Filterung beim TI Provider) surfen. Vermutlich eher gemütlich und mit deutlicher Volumenbegrenzung so weit ich weiß (evtl. bei Windows Funktionsupdates / AIS Updates etc. relevant).

Spannender hingegen wird die Frage, wie es sich mit der Kaspersky Firewall verhält. Ich unterstelle, „Total Security“ heißt, dass die Software eine Firewallfunktion (die ich generell nicht ernst nehmen kann!) mitbringt. Hier müsste ggf. der Port für die Kommunikation AIS zu Konnektor (ziemlich sicher Port 80 und oder 443) freigegeben werden. Aber hier stelle ich mal eine These auf: Die Softwarefirewall auf dem Rechner ist ebenfalls maximal benutzerfreundlich eingestellt und lässt ebenfalls alles von intern nach extern durch. Da das AIS die Verbindung etabliert, sollte auch hier nichts zu erwarten sein. Das kann ich aber nur spekulieren, weil ich die Konfig der Software nicht kenne.

Infos genug? Zu viele? Ich hoffe nicht. Viel Erfolg! Und bitte dran denken – hier sind wir immer sofort bei der Haftungsfrage wenn es knallt. Und in der Story ist im Moment viel „Potential“. Im Zweifelsfall also jemanden ranschaffen, der den Kopf dafür (die Installation) hinhalten muss.

Vielleicht passt es hier nicht in den Zusammenhang, wenn ich die Aussagen von Hasomed korrekt verstanden habe, hatten zumindest Kaspersky und Eset Schwierigkeiten, ihre Virussignaturen beim seriellen Anschluss über SIS zu aktualisieren.

Vorstellbar. Ich kenne nur ESET wirklich gut. Aber die sind empfindlich wenn die Update-Signaturen durch einen Proxy laufen. Ich pflege in meinen Firewalls mitunter etliche Whitelisteinträge für deren Update-Server. Das muss seitens des TI Providers im Filterwerk für die SIS auch erst mal berücksichtig werden.

Hallo Benny,

bei mir in der Praxis ist die TI in Reihe angeschlossen und als der Techniker von Epikur da war und alles angeschlossen hat, hat auch alles geklappt. Sprich Karte einlesen, Stammdatenabgleich, TI Ampel grün, alles tutti (zumindest für ihn und damit für mich auch). Er hatte nur vergessen auf dem Installationsprotokoll zu vermerken, dass alles funktioniert und das aktuelle Konnektorupdate (Secunet) einzuspielen, weswegen ich heute nochmal Kontakt mit einem Mitarbeiter von Epikur hatte, der sich per TeamView von der korrekten Funktion überzeugen wollte, bevor die Rechnung an mich gestellt wird. Nun zur eigentlichen Frage: dieser Mitarbeiter meinte, das installierte Eset würde im vorliegenden Reihenbetrieb verhindern, dass Konnektor und Epikur kommunizieren können (wundert mich, weil es am Tag der Einrichtung wie oben beschrieben offensichtlich funktionierte…). Auch war es Eset nicht möglich über SIS ein Update der Datenbanken zu ziehen. Da das Problem mit Eset und (Secunet)Konnektor wohl bekannt sei, soll ich mich kümmern, damit beim nächsten Mal alles funktioniert wie es soll. Was genau ist das Problem und lässt es sich (einfach) beheben? Einstellung bei Eset, Portfreigabe etc? Für einen Tipp in die richtige Richtung wär ich maximal dankbar!

Das klingt „interessant“. Aber ein paar Infos mehr wären bei solchen Fehlern immer gut. Welche ESET Version ist installiert (nur der reine Virenscanner oder doch die Internet Security Varianten), welche Fehlermeldungen kommen… Aber ich will mal raten.

Der Antivirus-Teil von ESET versucht, auch in verschlüsselte Verbindungen zu schauen. Diese Funktion kann (egal welcher Softwarehersteller) immer wieder mal zu Problemen führen. Hier die Anleitung zum aktivieren. Funktioniert natürlich auch in die Gegenrichtung: https://support.eset.de/kb3636/

Jetzt ist aber vielleicht die Internet Security installiert. Dann wird ESET noch von einer eigenen Firewall flankiert. Hier kann es notwendig sein, Programmbestandteile bzw. Verbindungen, als Ausnahmen zu definieren. Hier wäre der Softwareanbieter gefragt, denn er muss wissen welche seiner Programmkomponenten was auf welchem Weg (Port) beim Konnektor abfragen. Den Kunden da abzuspeisen und zu behaupten, dass Problem wäre bekannt, ist schon eine steile Ansage. Zumal ich sehr sicher ausschließen kann, dass es ein generelles Problem mit ESET und den Secunet-Konnektoren gibt. Gestern erst wieder zweimal eingerichtet (allerdings im Parallelbetrieb).

Zu den Updates: Wenn wir annehmen dass surfen über die SIS ansonsten möglich ist, gibt es vielleicht ein Problem mit dem Proxy bei der TI. Die Signaturupdates von ESET kommen (mein letzter Stand) via unverschlüsseltem HTTP. Die SIS kann da also reinschauen und „erkennt“ wohlmöglich Schadsoftware in den Signaturen. Das wäre ein nicht lösbares Problem, da der Fehler auf Seiten des Anbieters liegt. Fehlerhafte Updates hinter Proxys kenne ich von ESET. Deswegen pflege ich immer viele, viele Whitelist-Einträge für deren Server in meinen Firewall.

ZUM TEST kann man ESET mal stilllegen (rechtsklick auf das Icon -> Schutz deaktivieren). Sollte dann das Epikur wieder glücklich mit dem Konnektor kommunizieren können, weißt du wenigstens an welchem Punkt man suchen muss. Aber nochmal: Es ist Aufgabe des TI-Anbieters (hier anscheinend Epikur) eine funktionierende Integration vorzunehmen. Voher würde ich als Kunde lediglich das bezahlen, was auch geleitstet wurde. Aus der Ferne kann wenigstens ich da kaum mehr zu sagen.

Vom Beitragsautor

Danke für die ausführliche Antwort und das „Raten“. Ich versuche das mal nachzuvollziehen. Es ist tatsächlich die Internet Security installiert…

Vorab vielen Dank für diesen Beitrag, lachen ist ja gesund!

Ich hab diesen und nächsten Monat auch solche Installationen bei Kunden zu begleiten und war eigentlich auf der Suche nach einem L2-Switch, da es sich um Praxisgemeinschaften mit mehreren BSNR handelt, welche in VLANs segmentiert werden sollten.

Spannend ist allerdings die Tatsache, dass die Gematik und der technische Dienstleister sich dort zum Teil gegenseitig den „Schwarzen Peter“ zuschieben, insbesondere wenn es um technische Anforderungen geht. Meine Erfahrung war hierbei dass weder die KVWL, noch die Gematik, noch der technische Anbieter einen klaren Wert zur notwendigen Uploadgeschwindigkeit benennen wollte 🙂

In einem Land, in dem VDSL Anschlüsse im ländlichen Raum noch selten vorkommen und Lösungen wie LTE oder UMTS vom technischen Anbieter klar abgelehnt werden, steht man dann recht einsam auf weiter Flur.

lg

Danke. Ja, lachen ist manchmal auch das einzige das noch hilft. : )
Uploadgeschwindigkeit? Die minimale Uploadgeschwindigkeit der Praxis um (halbwegs vernünftig) an der TI teilzunehmen? Gibt es da nicht sogar Ausnahmen für Praxen, welche nicht halbwegs performant ans Internet angeschlossen sind?!
Ich glaube, im Moment ist sind die Datenmengen so gering… sofern man SIS auslässt und genug Zeit für die Firmware-Updates einplant. Der reine Stammdatenabgleich ist überschaubar. Mehr Sorgen würde ich mir dann über die Stabilität der Anbindung machen. IPSec ist ja schon ne Memme was Verbindungsabbrüche angeht… Aber ja, für künftige, aufwendigere Anwendungen kann es dann vielleicht auch schnell mal eng werden.

Hallo beisammen,

1 MBit reicht angeblich (im Moment) aus siehe Nr. 27:
https://www.kvno.de/10praxis/45itidprax/30_onlinerollout/onlinerollout_faq/index.html

zudem zu den Datenmengen … mehr als 25 MBit werden nicht benötigt, da macht nämlich ohnehin der Konnektor in Summe für andere Verbindungen ‚dicht‘ (sie Handbuch Seite 52 eines namhaften KoConectors ;).

Und ja, es gibt wohl Ausnahmen (auf Antrag ?), wenn keine passende Netzanbindung verfügbar ist. Leider finde ich die Fundstelle auf die Schnelle nicht.

vG RW

Interessante Frage. Aber ich wüsste nicht, was dagegen spricht. Letztlich sind das nur Programmbibliotheken die aktualisiert werden. Ob TLS 1.2 oder 2 in der Kommunikation zwischen irgendeinem Konnektordienst und dem Server eingesetzt wird, ist imho auch nicht die entscheidene Frage. Diese Kommunikation ist zur jeder Zeit durch das VPN abgesichert. Natürlich sollte man aktuelle Standards einsetzen. Viel wichtiger dürfte aber die Frage sein, ob diese Standards auch technisch sauber umgesetzt sind, und ob dieser Prozess entsprechend kontrolliert wird. Mir mangelt es bei der TI NICHT an coolen Buzzwords. Was ich schmerzlich vermisse, sind unabhängige Kontrollen der Systeme und deren Einsatzumgebungen.

Anbei Copy&Paste Portliste der Kocobox Hotline

IPSEC UDP 4500 WAN OUT
ISAKMP IKEv2 UDP 500 WAN OUT
OCSP Forwarder UDP 500 WAN OUT
DHCP UDP 68 LAN IN/OUT
DHCP UDP 67 LAN IN/OUT
DNS UDP 53 WAN OUT
NTP UDP 123 LAN/WAN OUT
NTP UDP 123 LAN/WAN OUT
Konnektor-Administration TCP 9443 LAN IN
SICCT UDP/TCP 4742 LAN IN/OUT
HTTP TCP 80 LAN OUT
HTTP 80 WAN OUT
HTTPS 443 LAN OUT
Werksreset TCP 9444 LAN IN
HTTPS TCP 8443 WAN OUT
KSR-Update UDP/TCP 443 WAN OUT

Sollte anderen verzweifelten Kollegen helfen, die Kocobox in Betrieb zu nehmen….

Ich verstehe kein einziges Wort. Muss ich auch nicht weil der ganze shit (sorry for the language) nicht in die Praxis kommt. So einfach geht das.

Hallo!
Haben grade die KoKo Box bekommen . Unser Mann war aber ganz OK, trotzdem Installation ohne TLS. Unser Installateur behauptet nun den Wan port der Box nicht mehr benutzen zu dürfen.

Bisher arbeiten wir ohne internet an den praxisrechnern – nun sind alle rechner zwangsweise verbunden.

Ich dachte die KoKo nuztz den Wan für den tunnel und wir haben dann kein Netz auf der LAN Seite.

Haben sie was dvon gehört das jetzt der Konnektor zwangsweise nur am LAN port angechlossen werden muss?

Das ist ja weniger eine Frage der Verkabelung, und mehr eine Frage der Netzwerkeinstellungen. Aber nein, ich weiß nichts davon, dass der WAN-Port der Box nicht mehr funktional sein soll. Im Gegenteil. Ich musste Techniker schon aktiv davon abhalten, mittels des WAN-Ports einen Bypass um meine Firewall herum zu bauen. Und um sicher zu sein, habe ich soeben auf einen Konnektor geguckt – Hinsichtlich des WAN ist alles dort wo man es erwartet.
Ohne ein paar Details zur Netzwerktopologie lässt sich nur schwer beurteilen, warum nun alle Maschinen online sind. Ich vermute, weil DCHP eingeschaltet ist, und nun alle mit dem Internetgateway (Telekom Router z.B.) in einem Netz sind?! Vorausgesetzt SIS (sicheres Internet über die TI) ist am Konnektor nicht eingeschaltet, wäre das Problem gelöst, wenn all Rechner den Konnektor als Gateway eingetragen haben. Ist aber erstmal nicht mehr als eine These!

Hallo Benny,
Vielen Dank für die Antwort. Bisher haben wir die Praxis EDV seltenst am Netz ( nur für updates) . Fürs Internet gibts extra PCs.
Alle Rechner und FritzBox sind in einem Netz. Aber eben die Praxisrechnern- ausgesteckt. Jetzt müssen wir die Rechner zusammen mit der Koko Box und dem Leser im Netz lassen. Also von 100% Internet abstinenz auf schlechtest mögliche Lösung…

Und ich überlege wie man das am besten macht. Ich bin davon ausgegangen das die koko-Box ausser Ihr VPN nichts in unser Netz lässt. Durch diese Art der Installation (alles am Lan Port) sind wir jetzt total ohne Firewall.

Deshalb wunderte mich die Angabe des Technikers das diese Art des Anschlusses nicht mehr erlaubt sei.

Oder verstehe ich die Funktion des Konnektors da falsch – deine Bemerkung „Konnte die Umgehung der Firewall verhindern“ macht mich da stutzig. Leitet die KoKo das internet durch? . Danke

Ich glaube, du missverstehst deine Netztopologie falsch. Ich tippe auf folgendes: Alle Systeme sind jetzt direkt mit der FritzBox verbunden. Alle tummeln sich im IP Bereich 192.168.178.xxx. Als Gateway haben sie (vermutlich automatisch) die 192.168.178.1 gesetzt. So wären alle Systeme mit dem Internet verbunden. Über die FritzBox halt. Der Konnektor ist dabei nur ein weiterer Teil des Netzes. Gleichberechtigt mit den Rechnern. Ich gehe davon aus, dass der Konnektor aktuell einfach gar nichts mit dem „Internetanschluss“ eurer Praxisrechner zu tun hat. Er existiert gleichberechtigt ebenfalls im Netzwerk.
Ja, richtig wäre gewesen: WAN Port des Konnektors mit der FritzBox verbinden. Praxisrechner u. Lesegeräte mit dem LAN Port. Damit habe ich eine physische und logische Netztrennung. Internet wäre dann nur gefiltert über die SIS-Funktion der TI möglich gewesen. Muss man extra buchen und bezahlen. Bei euch wurde aber nur ein „weiterer“ Rechner ins Netzwerk eingebunden (der Konnektor). Die Kartenleser kommunizieren mit diesem. Der Konnektor kann sein VPN zur TI aufmachen. Und dank gesetzter IP Route, können die Praxiscomputer vermutlich auch auf das KV-Safenet zugreifen. Was ebenfalls über den Konnektor läuft (sofern eingeschaltet).
Was ihr jetzt machen könnt um adhoc das Gröbste zu lösen: Die IP Einstellungen an den Praxisrechnern manuell ändern. Als Gateway einfach den Konnektor eintragen. Oder auch gar nichts. Damit ist surfen außerhalb eures Netzwerks nicht mehr möglich. Ist aber eine alberne Lösung. Mittelfristig müsst ihr euch jemanden suchen, der euch eine stabile und vor allem sichere Infrastruktur baut. So muss es z.B. möglich sein, dass permanant Updates vom AV-Scanner gezogen werden können. Der (versehentliche) Aufruf von unerwünschten oder gar gefährlichen Seiten / Diensten im Internet muss aber unterbunden werden. Also braucht es eine ordentliche Struktur und eine Firewall. Oder halt die SIS Funktion des Konnektors. Aber das kann man niemanden ersthaft empfehlen.

Leitet die KoKo das internet durch?

Das kann sie. Nennt sich SIS und muss extra dazu gebucht werden.

Deshalb wunderte mich die Angabe des Technikers das diese Art des Anschlusses nicht mehr erlaubt sei.

Keine Ahnung, was der Mann da meint. Die Funktion ist für die saubere Netztrennung in Hochsicherheitsnetzen unumgänglich. Zumal man es anscheinend bei der Programmierung nicht so sehr mit Alternativen wie VLAN hatte. Ich weiß nichts davon dass diese Funktion nicht mehr genutzt werden soll.

Hallo Benny,
hallo beisammen,

die Probleme mit der TI in den Praxen ist ja nun auch in der Presse angekommen. Ich bin dabei, mich in die Thematik mal RICHTIG einzuarbeiten. Dabei scheint es mir eine Vielzahl von Irreleitungen und Missverständnissen auf (wirklich!) allen Ebenen zu geben.

Das betrifft z.B. die Betriebsarten der Konnektoren:
Serie / in Reihe vs. Parallelbetrieb in Abhängigkeit des SIS

Nach meinen bisherigen Recherchen sollte für eine ’normale‘ Praxis die Serien/Reiheninstallation der Normalfall sein. Internetnutzung benötigt dann aber ZWINGEND auch den SIS. Die Begrenzung auf 25 MBit durch den Konnektor lassen wir dabei mal dahingestellt sein.

Bisher scheint es mir aber so zu sein, dass in den meisten Praxen der Parallelbetrieb Einzug hält. Dies, ohne die von Gematik und BSI dazu geforderten Sicherheitsfeatures zu bedenken. Insofern verstehe ich in dem vorgenannten Beitrag nicht die Ausführungen zu dem WAN-Port. Dieser soll ja eben NICHT eine Verbindung um die Firewall herum aufbauen, sondern eben ALLE Verbindungen bündeln und in die (sichere 😉 TI lenken. d.h: Im Normalfall (ohne sicheres eigenes Netz mit Firewall pp) MUSS der WAN Port angeschlossen werden (und SIS genutzt werden).

Die vorgenannte These würde m.E. bedeuten, dass, ja, in der Tat alle Geräte nun *offen* sind und über den T-Fritz!-oä-Router ins Netz gehen. Der Konnektor ist und bleibt dabei mit seinem eigenen TI-Schutz sicher angebunden, aber alle anderen Rechner der Praxis sind nun offen verfügbar (waren Sie ggfs. vorher ja auch schon).

Oder bin ich total auf dem Holzweg ?

Nächste Woche erhalte ich Einblicke in mehrere Praxen, die meine theoretischen Gedanken mit praktischen Erfahrungen und Erkenntnissen anreichern werden.

Beste Grüße sendet
RockWay

Ola. Deine Fragestellung begegnet mir in den vergangenen Wochen immer wieder. Und ist komplex genug, als dass es eigentlich für einen eigenen Beitrag reichen würde. Deswegen habe ich den langen und ziemlich öden Text der hier gerade schon stand, jetzt auch wieder gelöscht.
Ja, weil es einfacher ist und man möglichst viele Installation pro Tag schaffen will und vielleicht weder die Kunden noch die Techniker ausreichend über die Pro und Contras der einzelnen Installationsarten informiert sind, dürfte der Parallelbetrieb die Regel sein. Geht am schnellsten. Aber ich sage es in aller Deutlichkeit: Wenn nach der TI Installation plötzlich das ganze Praxisnetz am Internet hängt, dann haben mehrere Leute auf mehreren Ebenen versagt! Auch als Techniker der TI (der ich nicht bin) habe ich (in meinem Selbstverständnis) die Verpflichtung, den Kunden auf eklatante Sicherheitsprobleme in seinem Laden hinzuweisen.
Im Reihenbetrieb übernimmt der Konnektor die Rolle des Gateways. ALLE Netzwerkgeräte des Praxisnetzes befinden sich HINTER dem Konnektor. Will man „surfen“, muss man SIS buchen.
Im Parallelbetrieb befinden sich alle Netzwerkgeräte (auch der Konnektor) hinter einem Gateway. Das muss schon ewig eine ordentliche (UTM) Firewall (also eben nicht nur der LANCOM Router für 600 €) sein. Sollte es aber entgegen der BSI Empfehlungen und der gesetzlichen Anforderungen durch BDSG und DSGVO „nur“ ein Plastikrouter von Telekom, AVM oder wem auch immer sein, ist die Wahrscheinlichkeit groß, dass alle Geräte „online“ sind. In dem Fall ohne jeden weiteren Schutz. Also nein, du bist nicht auf dem Holzweg.
Letzterer Modus bedeutet erheblich weniger Aufwand bei der Integration. Ich stelle mal die These auf, dass die Techniker möglichst viele Installationen pro Tag erledigen sollen. Dafür eignet sich der Parallelbetrieb besser. ; )

Hallo Benny,

danke für die Rückmeldung und insgesamt für dein Engagement mit deiner Seite in dieser so wichtigen Angelegenheit unser aller Gesundheitsdaten.

Holzweg … na, dann bin ich ja be(un)ruhigt !!!

Mir fehlen die Worte, nach dieser Bestätigung und auch nach einem weiteren Tag der Recherche. Die Fragen türmen sich immer höher auf und deine Frage (Sind denn alle wahnsinnig?) bekommt weitere Nahrung.

Jeder, der Netzwerke betreut, kennt das Gefühl eines neuen Kunden. Überall blinkt es, Kabel führen sonst wo hin, Doku oftmals veraltet oder gar Fehlanzeige, und, irgendwas funktioniert nicht im Netzwerk. Bis man dann auch nur ein kleines Netzwerk durchblickt (also WIRKLICH meine ich !), das dauert ne Weile. Uns selbst dann hat es oft auch nach Wochen noch Überraschungen auf Lager, weil doch ne feste IP doppelt vergeben ist oder mehrere Geräte DHCP ins Netz flüstern oder … ach lassen wir das …). Will sagen, ein neues Gerät ins Netz zu bringen ist vermeintlich einfach. Wenn dieses aber – wie der TI-Konnektor – doch ggf. tiefer in die Netzwerkstrukturen eingreift, dann geht es schlicht weg nicht ohne eine seriöse Planung und mit einer dann verantwortungsbewussten Herangehensweise. Dazu gehört eben eine sehr genaue Betrachtung der vorhandenen Struktur nebst der Neugestaltung der zukünftigen Netzwerktopologie. Einen Konnektor in der Pause ins Netz bringen – sorry, das ist hochgradig unseriös. Und genau da sehe ich aber bei all den Beiträgen den Hasen im Pfeffer.

Was genau passiert, wenn zB die Praxis an KV-SafeNet mit Mehrwertdiensten angebunden war? Wer erklärt bzw. weiß überhaupt Bescheid über die Folgen der Nutzung einer alten G1 Karte in Zusammenspiel mit einem neuen Lesegerät (hier wird der Patient auf die moderne Praxis schimpfen).

Es kann und darf nicht sein, dass in Arztpraxen offensichtlich solche Dinge passieren, die nachher nur sehr sehr schwer einzufangen sein werden. Ich kann es kaum glauben und die Hoffnung stirbt zuletzt.

Ich werde gerne wieder hier vorbeischauen und wünsche bis dahin
sichere und verantwortungsvolle Arbeit in der „Praxis“
vG RockWay

Benny sagt:
4. Mai 2019 um 16:25 Uhr

Ola. Deine Fragestellung begegnet mir in den vergangenen Wochen immer wieder. Und ist komplex genug, als dass es eigentlich für einen eigenen Beitrag reichen würde. Deswegen habe ich den langen und ziemlich öden Text der hier gerade schon stand, jetzt auch wieder gelöscht.

Rockway:
>>> SCHADE !!! <<<

Ich betreibe eine Praxis für ärztliche Psychotherapie und habe die TI angesichts der angedrohten Sanktionen durch die Kassenärztliche Vereinigung bestellt.
Zwar bin ich an EDV-Themen sehr interessiert, verwende privat Linux, in der Praxis Windows 10, da mein Praxisverwaltungsprogramm, wie die meisten anderen, dieses Betriebssystem verlangt. Netzwerkthemen der IT liegen jedoch nicht in meine Kernkompetenz.

Viele Techniker scheinen darin aber auch nicht firm zu sein. So wechselte ich im Vorjahr von Windows 7 auf Windows 10 und der Techniker geriet mit der Installation von MS Office 2016, dem Installation eines Druckers oder dem Umzug des Outlook Postfachs an seine Grenzen. Letztlich wusste ich mehr als der Techniker, obwohl die Aufgaben diesem vorher bekannt waren. An seinem Stundenlohn von 120 Euro von einem örtlichen Systemhaus kann es nicht gelegen haben. Details der Gruselstory kann ich bei Interesse gerne schildern.

Bei der TI-Installation gibt es einen Festpreis von rund 300 Euro pro Installation. Es lohnt sich also, möglichst viele Installationen an einem Tag zu schaffen.

Ein Berufsverband der Psychotherapeuten riet zur Parallelinstallation, wohl auch um kostenpflichtiges SIS-Datenvolumen zu sparen. Ich vermute, die meisten Praxen haben einen Standardrouter, wie eine Fritzbox und ein Internet-Sicherheits-Programm. Hier könnte schon eine großzügige Zuteilung von SiS-Datenvolumen helfen.

Um die Datensicherheit in Arztpraxen und Krankenhäuser ist es nicht gut bestellt, wie folgender Artikel aus den VDI-Nachrichten zeigt:

https://www.vdi-nachrichten.com/Gesellschaft/Hacker-Arzt

So wie ich es verstehe, möchten Firmen wie Siemens gerne die Netzwerke von Krankenhäusern und Arztpraxen übernehmen, um das Sicherheitsniveau zu erhöhen. Das Problem ist dabei, dass sowohl Arztpraxen als auch Krankenhäuser feste Preise haben, diese nicht erhöhen können, um Schulungen, bessere Technik oder Experten einzustellen. Wenn in einer Region 30 oder 40 Krankenhäuser ausfallen, setzt vielleicht ein Umdenken ein.

Hallo,
danke für die Aufstellung der ausgehenden Ports.

Welche Ziel-IPs bzw. welches Subnetz sind in der Firewall ausgehend freizugeben?
Hintergrund: Hier ist alles verboten bis auf die Ziel-IPs, die explizit erlaubt sind…
Ziel-Netz für KV-Safenet ist z.B. NETZ 188.144.0.0 mit MASK 255.255.0.0.

Danke und Gruß.

Ein schöner Blogeintrag.

ich habe ihn gelesen während ich letzten Freitag den Techniker begleitet habe der bei meiner Frau in der Zahnarztpraxis den Rollout durchgeführt hat.

Zum Einsatz kamen dabei die Lösung der Zahnärztekammer welche aus einem Kartenleser, einer Box der T-Systems und einer SMCB Karte von Medisign besteht.

Spoiler: Laut Hotline sollte die Installation „max 15 Minuten dauern“ und einfach während des laufenden Praxisbetriebes durchgeführt werden können.

Gut, das der Bogen zur Ausstattung der Praxis dreimal angefordert wurde (ich hatte ihn Gottseidank eingescannt) und das meine Skizze zur Netzwerkinfrastruktur scheinbar auch nirgendwo angekommen war habe ich fast nicht anders erwartet.
Das der Techniker eines der größten Systemhäuser Deutschlands reinkam und sagte „ich mache das heute zum ersten mal“ und auch nach meiner Frage „welche Ports er denn freigeschaltet haben müsste?“ mich groß ansah, fast ungläubig das jemand eine restriktive Firewall einsetzt hätte stutzig machen sollen ist mir heute auch klar.

Aber der Reihe nach:
In der Praxis haben wir einen DSL Anschluss der Telekom, einen Lancom 1781EW+, einen managebaren Switch mit 2 VLAN (ein sehr abgesichertes, historisch mit festen IPs und eines mit DHCP und WLAN wo die weniger sicheren Dienste angeschlossen sind wie Hausautomation, Musikstreaming, Zeitabrechnung etc…

Es fing schon damit an das der Kollege sich in eine Netzwerkdose einsteckte und beschwerte „er hätte ja gar kein Internet“…ähh ja, Internet ist in der Firewall blockiert. Kann ich aber schnell freigeben. Naja, das er danach noch gute 10 Minuten suchte warum es nicht geht und schließlich herausfand das er bei IP Adresse des Rechners und Gateway die gleiche Adresse eingetragen hatte lasse ich ja noch als Flüchtigkeitsfehler durchgehen.

Ungelogen stundenlang bastelte er dann an diesem Konnektor herum, bekam ihn aber nie verbunden. natürlich war immer die falsch konfigurierte Firewall Schuld, aber welche Ports er brauchte konnte er mir nie sagen. Das stand auch in der Doku nicht drin. (Komischerweise sah ich aber auch kein reject in den Logs).
Er rief einen Kollegen nach dem anderen an, bis er schließlich jemanden dran hatte der ihm genau sagen konnte ein welches Feld etwas einzutragen war..Die Verbindung stand (lustigerweise sogar mit aktiver Firewall)

Jetzt galt es noch das Abrechnungsportal zu erreichen. Das klappte im ersten Anlauf nicht. Und jetzt wird es ganz komisch: An dem Rechner mit dem die Abrechnung übermittelt wird wurde der Netzwerkkarte neben der IP welche sie in dem Netzwerk hat eine zweite Adresse vergeben, die der Adresse des Konnektors entspricht. Auf meinen Einwand, dass doch nie zwei Teilnehmer in einem Netzwerk die gleiche Adresse haben können, hieß es: „Doch, das mache ich immer so, dann geht es“

Ging natürlich nicht.

Wieder hektisches telefonieren. Aus einer Whatsapp Nachricht wurden schließlich irgendwelche statische Routen abgetippt, was aber auch nicht zum Erfolg führte.
Schließlich war die wenig überzeugende Antwort da: Ja, die KZVWL hat aktuell ein Serverproblem…Moment, rufen wir mal einen Kollegen im Ort an, der schon an die TI angeschlossen ist ob es bei ihm geht….Natürlich, kein Problem.
Also Anruf bei der Kammer. Hier Gottseidank technische Kompetenz: Man muss als Gateway den Konnektor eintragen und nicht den Lancom.
So funktionierte es nach 6,5h endlich…

Aus meiner Sicht täte sich die entsprechende Stelle mal gut daran etwas detaillierte Information für die lokalen Netzwerkadministratoren zu veröffentlichen.

Ich teile übrigens die Bedenken was Wartbarkeit und Erweiterung / Austauschbarkeit bringen werden..

Ein schöner Kommentar! ; )
Aber ernsthaft – das ist erschreckend. Aus mehreren Gründen. Zum einen schäme ich mich (auch nicht zum ersten Mal) über das Niveau das in dieser Branche bei den Technikern anzutreffen ist. Hier muss vor allen den Verfechtern der ach so sicheren Infrastruktur mal ein Licht aufgehen – die Kette ist immer nur so stark wie ihr schwächstes Glied. Und ich kann noch so sehr die Leute mit sicherer Lieferkette, PKI und „hochsicheren“ Plastikroutern in den Wahnsinn treiben – all dies ist hinfällig, wenn jemand das weichste aller Ziele angreift. Oder dort gleich auch noch jemand Mist baut.
Die Ignoranz gegenüber handelsüblicher Sicherheitstechnik ist mir auch schon häufig begegnet. So fragt die CGM auf ihrem Frageboben auch immer noch, welchen Router man wohl nutzen würde um ins Internet zu kommen. Für (UTM) Firewalls ist da offenbar kein Platz.
Freut micht, dass es anschließend doch noch funktioniert hat. Ich hoffe, es bleibt so.

Ja, das finde ich auch immer wieder beschämend. Ich wollte ihn erst fragen was er denn so gelernt hat..
Aber das erlebt man doch immer wieder. Solche Leute sind in ein oder zwei Produkten super geschult, können da eine Installation durchziehen, aber warum was wie ist, wie so ein VPN Funktioniert oder was eigentlich ein Zertifikat ist kann da keiner erklären..
Ich arbeite ja so am Rand von dem Thema, in der Gebäudeautomatisierung. Habe aber (teils Berufsbedingt, teils durch das Studium der Kommunikationstechnik) ein gutes Basiswissen, so dass ich mir vieles selbst herleiten kann.

Was ich an dem ganzen Thema auch interessant (oder auch belustigend finde) ist das z.B. die Telekom bei dem Konnektor drauf hinweist man solle doch wöchentlich prüfen ob die Siegelaufkleber des Gehäuses noch unbeschädigt sind. Oder die ganzen Schreiben, dass der Konnektor doch in einem ständig verschlossenen Raum stehen muss. Das wird sicher das Problem lösen:-)

Es reicht aus die Route 188.144.0.0 mit 255.255.0.0 auf Konnektor IP zu setzen, das Gateway kann beliebig gesetzt werden. Aus genau dem Grund setzt man ja die Route.

Vielleicht weiß jemand Rat 😉
Unsere KoCoBox zeigt Error 4 und das Display verweist auf das Handbuch … das wir irgendwie nicht erhalten haben.

Lt. unserem IT-Dienstleister, der die Box installiert hat liegt der Fehler daran, dass unser Praxisnetz nicht offen ist wie ein Scheunentor … und d.h. die Box kann sich kein Update ziehen.

Kennt das jemand?

Mit den Handbüchern sind die sparsam. Habe auch noch keines aus der Nähe gesehen. Nur so Zettel mit den wichtigsten Fehlercodes hinter denen im Normalfall steht, dass man die Hotline anrufen soll…
Ich habe den Updateprozess noch nicht aus der Nähe gesehen. Aber bei der ganzen (pseudo) Sicherheit erwarte ich, dass die Schüssel sich ihre signierten Updates über eine gesicherte Verbindung aus dem VPN gesicherten Tunnel holt. : ) Wie offen ihr dann hoffentlich dann nicht seid, spielt eigentlich keine Rolle. Steht der Tunnel, sollte alles laufen. Außer die Genies holen sich das Update über (möglicherweise) obskure Ports von Quellen außerhalb der TI… Ich traue es ihnen zu! Das sollte aber die Hotline wissen. Ich habe keinen Updatepfad gesehen der auf externe Quellen zeigt…

Das Administratorhandbuch lässt sich bei KocoMed via Mail anfordern. Einen Error 4 gibt es jedoch im Handbuch nicht. Die komplette Fehlermeldung müsste länger sein und die Fehlercodes sind 5-stellig. Wohingegen Betriebszustände in Kurzform ausgeschrieben werden: z.B. „Operational State Error EC_Connector_Software_Out_Of _Date“ für vorhandene Aktualisierungen.
Sobald die Verbindung komplett steht, muss auch der Updateserver erreichbar sein, eine Firewall kann in einen funktionierenden Tunnel nicht eingreifen.

Error 4 finde ich auch dubios.
Steht denn der Tunnel zur TI?
Das neulich erst rausgebrachte Update ist nicht zwingend (noch nicht?) erforderlich, dass der Tunnel aufgebaut wird.
Zum Tunnelaufbau ist aber erforderlich, dass die KoCoBox sich die CRL und TSL ziehen kann (Port 80 und 443). Haben die ihre Gültigkeit hinter sich gebracht, wird der Tunnel nicht mehr aufgebaut.
Zum einen kann das passieren, wenn die Ports nicht offen sind – zum anderen, wenn die Box lange genug bzw. zu lange (wie man’s sieht 😉 ) vom Netz getrennt (ausgeschaltet?) war. Dann muss man die beiden Dateien per Hand updaten, dann klappt’s wieder.

Mich interessiert die Aussage, dass die Kocobox in einem Vlan gekapselt wurde. Das setzt meines Wissens einen gemanagten Switch voraus, der in der Kette Internet =>Firewall/Router=> Switch => Lan hängt. Wie darf ich mir die Verkabelung vorstellen, schließlich hat die Kocobox einen Lan und einen Wan Anschluß. Ich kann ja wohl schlecht den Wanport wieder an den Switch anschließen und möchte ja auch nicht die Box in die Kette Lan=>Switch=>Koco-Box=>Firewall/Router=>Internet hängen?

Mein Kenntnisstand hierzu: Die Box macht ein VPN zum TI-Provider auf. Das VPN ist ein übliches IPSec. Darin wird alles, was per Routing für die TI bestimmt ist, eingekapselt. Sofern also nicht jemand so richtig daneben gegriffen hat, sollte der Prozess safe sein.
Die interne Kommunikation zwischen Box und AIS / Kartenleser erfolgt per Default unverschlüsselt. Das leite ich daraus ab, dass man TLS explizit aktivieren kann (das bisher aber kein Techniker gemacht hat). Hier wird wie üblich in der Branche, davon ausgegangen dass das Netz des Kunden safe ist (und bis in alle Ewigkeit auch so bleibt).
In den von mir begleiteten Installationen, wurde ausschließlich der LAN-Port der Box genutzt. Was in den meisten Fällen ausreichend sein sollte, weil die Box innerhalb des Netzes nur als Client auftritt. Die GUS-Box btw. macht das anders. Die nutzen immer LAN und WAN.

Moin Benny,

vielen Dank dafür – dieser Artikel ist aussagekräftiger, als das was z.B. Gematik, KBV, DGN oder CGM über TI preisgeben 🙂

Aber vielleicht kannst du ja noch eine Sache erhellen: So weit ich das verstanden habe, initiiert der Konnektor die Netzverbindung zum Terminal (wir sollen also einfach mal drauf vertrauen, dass diese Blackbox schon nix verkehrt macht – aber das nur am Rande…).

Doch wie sieht das mit dem TI-Softwareschnippsel in Albis aus? Geht die Kommunikationsinitiierung vom PVS aus oder baut der Konnektor Verbindungen zum Arbeitsplatzrechner auf? In den Specs habe ich dazu nichts belastbares gefunden (steht bestimmt irgendwo, aber wo?), es klingt aber so, als würde das PVS per SOAP mit dem Konnektor sprechen (was _deutlich_ besser in unsere Infrastruktur passen würde).

Danke!

Ich bin mir da nicht so sicher… Ich als Entwickler, würde die Untergeordneten Systeme immer die Kommunikation initiieren lassen. Also PVS wenn aktiv zu Konnektor, Kartenleser wenn aktiv zu Konnektor. Mein „Server“ (hier der Konnektor) lauscht ganz passiv bis eine Anfrage kommt. Reduziert die Agriffsvektoren und verringert die Last auf dem Netzwerk (ansonsten müsste der Konnektor aufhören rundzurufen wenn alle ihm bekannten Systeme online sind. Möglich, aber erhöht die Komplexität…).
Ich wäre also geneigt, deiner Sicht bezüglich PVS und Konnektor zuzustimmen. Aber ich weiß es ehrlich gesagt nicht. Ich mutmaße hier nur.

Hallo Zusammen,

vorab vielen Dank für den tollen Artikel, welcher mir in einigen Passagen ein schmunzeln ins Gesicht gezaubert hat. Geholfen haben mir die Portangaben.
Wir haben bei uns den Fall, dass wir einen Konnektor für zwei unterschiedliche Arztinformationssysteme in Betrieb nehmen müssen. Es wird ein VLAN für den Konnektor in Betrieb genommen.

Mir stellt sich noch die Frage, ob man den Zugriff vom Konnektor noch weiter eingerenzen kann – Welche Adressen müssen an der Firewall freigeschaltet werden und welche Ports werden zur Kommunikation zwischen den Kartenlesegerät und dem Konnektor benötigt?

Viele Grüße aus der Nähe von Hamburg

Zwei PVS? Ein Konnektor? Spannend. Da würde mich einfach mal so interessieren, wie praktikabel das ist. Und wie ich beim einlesen der Karte, das PVS unterscheiden kann.
Ja… ich mache mal eine ordentliche Übersicht der Ports fertig. : ) Versprochen!

2 AIS sind kein Problem. Dann muss man aber die Kartedaten über das AIS holen. Pollen geht nicht.
Portfreischaltungen innerhalb der Praxis sind eigentlich nicht notwendig. Läuft alles über Port 80 in de einfachsten Konfiguration.

Hallo Benny,
warst Du vielleicht bei meiner „Erstbegleitung einer TI Installation“ irgendwo im „Off“ dabei?
Du beschreibst genau das Szenario, daß ich auch erlebt habe.
Der einzige Unterschied dabei; Der zertifizierte Techniker war nicht nur inkompetent, sondern auch noch unerträglich frech und dreist.
Nach einer Beschwerde bei CGM hat man uns dann einen anderen geschickt, der zwar auch keine Ahnung hatte, aber wenigstens höflich war.

Guten Abend Benny,
herzlichen Dank für Deinen tollen Bericht, welcher zugleich unterhaltsam als auch sehr lehrreich aus fachlicher Sicht ist.
Ich betreibe eine Praxis für ärztliche Psychotherapie und empfinde die Angebote zur Telematik des Herstellers meines Praxisverwaltungsprogramms als überteuert. Es gibt auch keine Markenvielfalt, sondern man bietet nur einen Konnektor an, der im Juni oder Juli 2018 seine Zulassung erhalten soll. Ein Wechsel des Praxisverwaltungsprogramms ist nicht einfach, da die Patientendatenbanken der Systeme sich unterscheiden. Ich warte allerdings mit der Bestellung vorerst ab, hoffe, dass die Telematik noch vor die Wand fährt. Interessant fand ich folgenden Vortrag von der Gulasch-Programmier-Nacht 2018 aus Karlsruhe:

https://media.ccc.de/v/gpn18-125-ich-komme-aus-einem-anderen-land-telematik-in-der-medizin

Eine technische Frage habe ich zum Konnektor, der letztlich ein kleiner Computer ist. In den Beschreibungen lese ich, dass dieser ständig ans Stromnetz angeschlossen sein muss. Wenn man den Konnektor ausschalten wolle, müsse man diesen herunter fahren wie einen normalen Computer. Jetzt weiß ich, dass Rechner ist gar nicht mögen, wenn sie ohne Vorwarnungen einfach vom Stromnetz getrennt werden. Was geschieht mit dem Konnektor, wenn dieser aus Versehen vom Stromnetz getrennt wird, etwa bei Reinigungsarbeiten, jemand kommt an das Kabel, etc.? Kann man diesen einfach wieder anschalten oder fällt der Konnektor dann aus und ein zertifizierter Techniker fährt ihn wieder hoch?

Hallo Psychdoc.
Ja, die mangelnde Auswahl bei den TI Providern ist nach wie vor, ziemlich ärgerlich. Und allen Beteuerungen zum Trotz, kommen die anderen Firmen mit ihrem Kram nicht so recht an den Start. Mag am schwierigen Zertifizierungsprozess liegen… oder daran, dass die Politik bemüht ist, möglichst viel Unsicherheit in die Sache zu bringen.
Ein Wechsel des PVS wegen dem TI Anbieter, halte ich für vollkommen überzogen. Letztlich ist es eine gesetzliche Vorgabe, dass die Einführung und der Betrieb der TI, für Praxen Kostenneutral abzulaufen hat. Davon abgesehen, wird ein neuer Anbieter eines PVS gerne den alten Datenbestand konvertieren. Gibt für so ziemlich jedes PVS entsprechende Software. Trotzdem ist ein Wechsel der PVS ein unglaublich teurer Prozess, den ich mir ja eher hundertmal überlegen würde!

Zur technischen Frage. Wenn beim Reinigen irgendeine Komponente der EDV ausgeschaltet werden kann, gibt es ein grundsätzliches Problem im Aufbau, dem Zugangsschutz etc. Ich kann aber verstehen, dass es nun mal gewachsene Strukturen gibt. Ein bisschen unterscheiden sich diese Platikrouter dann doch vom Computer. Im Normalfall verkraften sie einen Stromreset deutlich besser als die gemeine Windowsmaschine. Was nicht heißt, dass man es provozieren sollte. Zumal gerade für die TI Konnektoren eine permanete Verbindung wichtig ist. In so Sicherheitsumgebungen ist eine genaue Uhrzeit wichtig, oder die häufige Überprüfung der verwendeten Zertifikate bzw. deren Aktualisierung. Also bitte – vermeide solche Hardresets. Und wenn, dann lass dir wenigstens ne Minute Zeit, bis du die Stromversorgung wiederherstellst.
Im Normalfall bootet das System anschließend wieder normal.

Hey *,

vielen Dank für den aufschlussreichen Artikel.
Bei uns ist das ganze etwas anders gelagert: Die Box und das EGK-Terminal stehen direkt hinter der fritzbox, alle Praxis-PCs stehen hinter einem Gateway/Proxy/Firewall (der auch im Fritzbox-Netz steht). Der Grund ist, dass im Praxis-Netz keine Geräte sein dürfen, die wir nicht selbst administrieren können/dürfen (Tablets, 3D-Scanner, etc).
Gibts irgendwo eine Info darüber, welche Ports vom Rezeptions-PC zu Kartenterminal/Konnektor geöffnet werden müssen?

Danke, F

Hallo F.
Der Konnektor und das Orga stehen also im .178.xxx Netz, während Praxisnetz in einem anderen Subnetz hinter einer Firewall stehen? Habe gerade mal einen Blick bei einer für mich erreichbaren Installation riskiert. Da ich nichts außergewöhnliches finde, scheint es sich auf Standards zu beschränken. Sicher bin ich mir da aber nicht. Und nein, eine Liste ist mir nicht bekannt. Wenn es aber eine geben sollte, würde ich mich schon dafür interessieren. Ansonsten könnte ich mal schauen, welche Ports vom Server / der PVS in Richtung Konnektor aufgemacht werden.

Hallo,

mal was grundsätzliches:
Das besagte Duopol besteht deshalb, weil andere im Erprobungsbetrieb noch beteiligte Hersteller, irgendwann das Interesse verloren – daher sind nach derzeitigem Stand – nur CGM-Systeme anbindbar.
Die Chance, die notwendigen Produkte zu entwickeln, wurde von den anderen einfach verpennt, nicht gesehen, was auch immer.
Der CGM da nun einen Strick draus zu drehen, ist absurd.

Die Vorgaben der TI werden durch die Gematik erstellt und diese zertifiziert die Prdoukte – wem die Gematik gehört?
Zu guten Teilen den Leuten, die momentan am lautesten plärren, das alles doof ist – genauso absurd.

DSGVO –> Die TI-Struktur ist entsprechend geprüft und konform, das Gegenteil wird leider oft behauptet, nur nicht belegt.

Kartenlesegeräte: Es gibt die Vorgabe der „sicheren Lieferkette“ – von der Gematik.
Für die Praxen wird idR ein Gerät gefördert, zusätzliche können gekauft werden, auch bereits für die Grundeinrichtung – weitere Geräte werden gefördert, wenn eine bestimmte Praxisgröße (Anzahl der Leistungserbringer, Betriebsstätten) überschritten wird.

Techniker: Es gibt die Vorgabe der Politik, auf Grund der degressiven Förderung die Praxen bis Ende 2018 auszurüsten – wir reden von 140.000 niedergelassenen Ärzten, die Krankenhäuser mal außen vor.
Was das umgerechnet an notwendigen Installationszahlen ausmacht, ist leicht zu berechnen.
Fachkräfte sind rar und teuer und so werden die Installateure grundsätzlich geschult die Hardware in Betrieb zu bekommen, leider manchmal mit den o.g. Folgen – das ist bedauerlich, aber einfach nicht anders lösbar – zumal die beteiligten Firmen diese Installationen zusätzlich zum normalen Geschäft betreiben – ich kann aus eigener Erfahrung sagen –> es ist höllisch. 🙂

Dazu kommt insgesamt die Panikmache aus den Reihen der Ärzte, die merkwürdigen, sich teils widersprechenden Aussagen der Politik, unverantwortliche Journalisten und Funktionsträger, die Meinung mit Fakten verwechseln und die Problematik, dass das ganze Projekt jetzt plötzlich dermaßen wichtig wird, man ist ja immerhin 10 Jahre zu spät dran. 🙂
Immerhin sind wir ja das Volk der 80 Millionen Fußballbundestrainer…

Ich lache mich nur weg 😀 Es ist schön wie jemand versucht die Komplexe Installation der TI versucht einfach runter zu schreiben… Ich als ZDVO (!!) bin immer sehr behutsam was das zuschauen des Arztes bei der Telematik angeht. Leider Fliegt meine Maus nur so über den Bildschirm… Blöde für die Ärzte oder dem Praxis Techniker. Grundsätzlich gilt: Ihre Hardware Kennwörter haben sie also Schauen die gerne rein. Die CGM hat nichts zu verstecken 🙂

So komplex ist die Installation überhaupt nicht! Und der Hersteller der Kocobox bietet seit kurzem ein Selbstinstatallationspaket an. Damit ist endlich dem Nimbus der „zertifizierten“ TI „Göttern“ ein Ende gesetzt! Wenn ich bedenke wie die Installation bei mir in der Praxis verlaufen ist frage ich mich ernsthaft womit diese „zertifizierten“ Techniker die Instatallationspauschale rechtfertigen…..

Hallo Benny,

bezüglich einen „erfahrener“ Betreuer ist es die gleiche Geschichte, was Du bereits oben beschrieben hast. Bei der Installation des Konnektors hat er einen „Leitfaden von CGM“ gehabt. Als er, nach mehrerer Fehlerverbindung des Konnektors, mit seinem Latein am Ende war, hat er die CGM-Hotline angerufen und über den „TeamViewer“ ein Einblick in meine „PC-Anlage“ erlaubte, klappte es plötzlich.
Während etwa 2 Stunden „Installation“ bei mir hat er einen Azubi über seinen Smartphone in einer anderen Praxis „beraten“ und immer wieder an den „CGM-Leitfaden“ eingewiesen.
Ich bin evl sehr streng mit den Technikern, aber ich stelle mir einen Chirurgen in Operationssal vor, der über den Smartphone Chef anruft und immer wieder versucht den Bauch des Patienten zu operieren.
Es ist angeblich bereits in mehreren Praxen ein „Pilot-Projekt“ sehr positiv abgelaufen.
Das bedeutet für mich, dass jemand bereits mehrere hunderte Installationen vorher durchgeführt hat. Und es hat angeblich perfekt funktioniert :-).
Hat diese Installationen evl jemand vom Mars oder Jupiter auf unserer Erde durchgeführt :-)?
Solange ein VDSM-Ausgleich funktioniert, werde ich mich ruhig verhalten.

Es ist nur sehr schade, dass für unseren Arzt-, Zahnarztpraxen, Psychotherapeuten, Apotheken und Krankenhäuser einige hunderte von Millionen Euro in Sand gesetzt wurde (ca. 120.000 Arztpraxen; ca. 50.000 Zahnarztpraxen, ca. 20.000 Apotheken und ca 2.000 Krankenhäuser).

Etwa 192.000 Institutionen die mindestens einen Konnektor und Lesegerät stationär plus ggf. mobilen benötigt. Mein Apotheker benötigt mehrere Lesegeräte.

Ich habe nur ein TI-Paket pro eine Institution gerechnet (192.00 x 3.600 Euro) und bei mir kam eine runde Summe in einer Höhe von 691.200.00 Euro. Wenn aber MVZ, Krankenhäuser und andere Praxen mehrere Geräte benötigen, dann kommt man locker auf eine Summe in eine Milliarde Euro!!!
Wie toll konnte man die Gesundheitssystem in Deutschland für diese runde Summe verbessern.
Jetzt ist nur eine dumme Frage von mir: wer steckt dahinten und wer steckt das Geld in der Tasche? Politiker? CGM? Techniker? Krankenkassen?
Ist es nicht Fall für den Korruptionsbeauftragte? Wo sind unsere „Suchende nach Wahrheit“?

Benny, Du hast recht mit deiner Frage: „Sind denn alle Wahnsinnig“!!!

Am 07.03.2018 wurde in meiner Praxis ein Konnektor „KoCoBox Med+“ und ein Kartenlesegerät „eGK ORGA 6141 online“ installiert. Nach vorherigen Installationsprobleme konnte endlich nach etwa 2 Stunden erste e-GK abgelesen werden. Zeitlich konnte ich keine Veränderung zur früherer Version feststellen. Nach etwa eine Woche erschien im Konnektor-Display eine Meldung:

Operational State Error
EC No VPN SIS
Connection
Siehe Handbuch

Das Problem ist, dass im Handbuch darüber nichts zu finden war.
Nach mehrmaligen Versuche über den „Vertrags-IT-Partner für ALBIS“ keine Problemlösung gefunden konnte.

Es kam nur eine Aussage dazu: „in vielen Arzt-Praxen“ ist ein ähnliches Problem aufgetreten. Das Problem sollte irgendwann von den Kassen geregelt werden.

Internet-Anschluß: über Telekom VDSL 25 MBiot/sec;
Router: AVM FRITZ!Box 7490 über LAN;
Konnektor ist über LAN mit einem CAT-6 mit einem Switch verbunden
eGK ORGA 6141 online ebenso mit einem CAT-6 mit einem Switch verbunden

Die eGK kann ich ablesen, jedoch fehlt ein Abgleich den Karten zentral.

Hat jemand ein gleiches Problem und evl bereits eine Lösung dazu?

Hallo Johann. Hat es vielleicht etwas HIERMIT zu tun? Auch Dr. Evil scheibt hier in den Kommentaren, etwas über falsche Zertifikate. Falsches Zertifikat auf der Box – kein VPN zur TI – kein Abgleich des VSDM
Andererseits sagt die Fehlermeldung dass das „SIS“ gestört ist. Hierbei handelt es sich um den „sicheren Internet Service“. Hast du den gebucht? Ansonsten ist die Meldung nämlich in der Tat bei der KoCoBox normal.
Probleme mit Zertifikaten etc, sind immer Sachen der Anbieter! Du als User kannst maximal einen Reset der Box auslösen. Die Frage muss aber sein, ob dein ALBIS-Vertrieb nahe genug an dem Thema dran ist?! In deinen Unterlagen müsste eine Telefonnummer vom TI-Support stehen?! Sich an die zu wenden, halte ich für gradliniger.

Hallo Benny, danke Dir für Deine Unterstützung! Mein Vertriebs- und Servicepartner aus Solingen meinte, dass es in sehr vielen Praxen eine ähnliche Situation ist.

Ich glaube, dass auch ohne „SIS“ ein Ausgleich des VSDM möglich ist. Ist es korrekt?

Weist Du, was „SIS“ kostet? Ist nur eine Lizenz zu kaufen? Oder ist auch mit Folgekosten zu rechnen?

Wer kann mir „SIS“ zur Verfügung stellen? CGM? Vertriebs- und Servicepartner-ALBIS?
Könntest Du freundlicherweise mir eine Telefonnummer vom TI_Support geben.

Danke!

Hallo Johann.
Die Informationslage ist da etwas dürftig. Was ich noch gefunden habe, ist diese hier. Dann sollten deine Probleme in der Zwischenzeit aber weg sein.
Wie gesagt, die Meldung hinsichtlich des „Sicheren Internet Services“ ist für dich irrelevant. Dieser Dienst ermöglicht es dir, über den Konnektor zu surfen (Mails, vielleicht diese Website…). Gemäß dem Angebot der CGM (PDF), ist das inklusive. Brauchen tust du es aber für das VSDM NICHT! Aktuell geben die Konnektoren eine fehlende Verbindung zum SIS aber fälschlicherweise als Fehler aus.
Hat das Ding mal jemand neugestartet? Muss man ja heute wieder fragen…
Telefonnummer will ich mal versuchen, heraus zu suchen. Kann aber ein bisschen dauern.

Lieber Benny, vielen Dank für Deine Unterstützung. Als Konnektor und Kartenlesegerät stationär vom Vertriebs- und Servicepartner aufgebaut und die Programme aktualisiert wurden, war zuerst alles in Ordnung. Auf dem Konnektor-Display war keine Info „Error“ zu sehen. Es kam in ein Paar Tagen danach. Ja, ich habe den Konnektor vom Strom genommen, da es keinen Schalter am Gerät zu finden war. Nach etwa 1 Minute (60 sec.) eingeschaltet. Keine Änderung. Für mich ist unwichtig was auf dem Display steht, wichtiger ist eine vorhandene Funktion „VSDM-Abgleich“. Am PC-Monitor unten rechts leuchtet ein „grünes“ Zeichen. Im Angebot vom CGM ist eine Funktion „SIS“ steht drin, als eine Vorbereitung. Was damit gemeint ist, kann ich noch nicht sagen.
Auf jeden Fall danke ich mich bei Dir herzlich.
Frohe Ostern-Feiertage wünsche ich Dir und Deiner Familie!

Am Wochenende habe ich ein paar Test mit meinem KoCoBox-Konnektor gemacht.
Wenn mein eGK-Kartenlesegerät stationär ORGA 6141 online ausgeschaltet ist, dann erscheint im Konnektor-Display folgende Information:

Operational State Error
EC CardTerminal Not
Available (CT ID 0001)
Siehe Handbuch

Wird das Kartenlesegerät eingeschaltet, dann erscheint folgende Information:

Operational State Error
EC No VPN SIS
Connection
Siehe Handbuch

Mein Vertriebs- und Servicepartner ALBIS und CGM in Koblenz bestätigte mir, dass „SIS“ für den VSDM-Ausgleich irrelevant ist.
Eine Leistung „SIS“ kann mann zusätzlich bestellen, um einen sicheren Weg über Internet erhalten und sollte etwa 10 Euro Monatsgebühren kosten.

Ein Handbuch für KoCoBox-Konnektor ist lächerlich!!! Eine einzige Aktion für allen möglichen Problemen: den Strom-Stecker aus dem Konnektor für etwa 20 Sekunden ziehen. Danach startet sich Konnektor erneut und sollte durch einen Selbstest alle Problemen lösen. Dazu könnte CGM in Koblenz wenigsten einen Schalter einbauen lassen. NEIN, es wäre viel zu teuer gewesen 🙂 und hier wurde einfach gespart 🙁

Hallo Johann.
Die Meldung mit alsgeschaltetem Orga ist verständlich. Der Konnektor braucht zwingend eine Verbindung zum Orga und der darin enthaltenen SMC-B. Eine Einwahl ins VPN der TI erfolgt auch erst, wenn du am Orga die korrekte PIN eingegeben hast. Ohne Kartenlesegerät geht also nichts. In sofern finde ich die Meldung i.O.
Und die andere Meldung ist bereits geschrieben, irritierend aber „normal“. Eine fehlende SIS-Anbindung melden die Kisten aktuell als Fehler. Wie ist denn der Status aktuell bei dir? Kriegen die Karten nach dem einlesen den Status „online geprüft“ oder nicht? Gibt es Meldungen in der PVS über den Verbindungsstatus zur TI?
Generell sollte dein EDV-Betreuer in der Lage sein, sich mit dem Webinterface des Konnektors zu verbinden, und einen schnellen Blick in die Logfiles zu werfen. Und sei es nur, um dem ALBIS-Betreuer weitere Hinweise zu liefern. Und du solltest dich von eventuellen Fehlern nicht verrückt machen lassen. Es ist nicht sehr wahrscheinlich, dass die Kassen an dich herantreten wenn du keinen Onlineabgleich machst! Und die Förderung solltest du sicher haben, da es ja schon mal funktioniert hat. Dokumentiere deine Fehler und die Versuche, jene von der CGM heile machen zu lassen. Mehr kann man nicht verlangen!
Powerknöpfe an solchen Geräten sind immer eine philosophische Sache. Es gibt ein Für und Wider. ; ) Ich befürworte sie aber generell.

Vom Beitragsautor

PS: ich habe total vergessen. Eine IP-Adresse wurde seitens Vertriebs- und Servicepartner frei vergeben, dass Bedeutet einfach übernommen, was FRITZ!Box 7490 frei vergeben hat. In meinem Fall IP: 192.168.178.27. Den eGK-Kartenlesegerät hat eine IP: 192.168.178.28 erhalten.
Zuerst wäre es kein Problem sein. Das Problem ist aufgetreten, als ich am 01.04.18 einen zusätzlichen Netzwerk-Drucker installiert habe. FRITZ!Box 7490 hat sofort diesem Drucker eine IP: 192.168.178.28 vergeben, da mein eGK-Kartenlesegerät komischerweise nicht gemeckert hat.
Alles hat super mit dem Drucker geklappt, außer meines eGK-Kartenlesegerätes.
Das Gerät wurde plötzlich nicht online erkannt 🙁

Zuerst dachte ich, es ist ein APRIL-Scherz 🙂

Das Gerät wurde plötzlich nicht online erkannt!!!

Ich habe das Netzübersicht im FRITZ!Box gestartet und angeschaut, klar es wurde für zwei Geräte eine IP vergeben.

Nachdem ich manuell dem Drucker eine IP: 192.168.178.29 vergeben habe, war alles erneut in Ordnung. Das eGK-Kartenlesegerät war erneut online zu erkennen.

Es war kein APRIL-Scherz. Bei der IP Vergabe sollte man evl immer selbstständig eine feste IP vergeben und anschließend ein IP-Plan erstellen und speichern.

Und noch eine Frage: welche Albis Dateien (Ordner) muss man sichern, um die Software wiederherstellen zu können (Patientendaten, Briefe, Abrechnungsdaten usw). Und wie wird eine Wiederherstellung durchgeführt.
Demoversion installieren, Lizenz installieren und anschließend gesicherte Ordner und Dateien zu implementieren (ersetzen)? Oder kann man die gesicherte DAten in Demoversion importieren?

Auf deinem Server gibt es einen ALBIS-Ordner. Normalerweise C:\ALBIS oder C:\ALBISWIN. Das Ding komplett sichern. Da ist alles drin. Die darin enthaltene ALBIS.exe kann jederzeit von jedem Rechner ausgeführt werden. Klar, ohne jede Einstellung, ohne eingerichtete Drucker etc. Aber an die Daten kommt man so nach fünf Minuten. Was Sicherung angeht, ist ALBIS wirklich furchtbar simpel.

Vom Beitragsautor

Hallo Benny, Du kennst Dich perfekt mit ALBIS-Oftware aus. Ist es korrekt? Seit dem letzten updates funktioniert bei mir eine Funktion Thesaurus nicht, so wie es sein sollte. Wenn man „dia“ Abkürzung Schreibt, eine Diagnose oder ein Symptom (z.B. Luftnot) und danach F3 druckt, kam früher einige passende ICD 10 mit Diagnosen zum erscheinen. Jetzt kommen irgendwelche Diagnose, die mit einem „Luftnot“ nicht zu tun haben. Gibt es ein Tipp aus Deiner Trick-Kiste?

Bezüglich C:\ALBISWIN Sicherung.
Ja, ich habe auch bis dato so eine Sicherung den gesamten Ordner durchgeführt.
Zuerst habe ich mir auf eine zusätzliche SSD-Festplatte mit 250 GB die gesamte Festplatte vom Server geklont und es läuft eine regelmäßige Synchronisierung. Wenigstens hoffe ich, dass es automatisch alles zu 100% synchronisiert wird.
Auf eine mobille HDD-Festplatte mache ich eine tägliche Sicherung vom o.g. ALBISWIN-Ordner. Da dieser Ordner aber bereits über 40 GB gewachsen ist, dauert es etwa 20 Minuten.
Ich dachte mir, dass eine Änderung in diesem Ordner lediglich in ein paar Subordner stattfindet. Wenn ich täglich nur diese Subordner sichern würde, dann benötige ich evtl nur ein paar Minuten.
Darum war meine Frage: in welchen Subordner findet sich eine tägliche Änderung?
Danke!

Hallo Johann ,
Der „Fehler“ ist nicht erst nach einer Woche aufgetreten. Der ist schon immer da.

SIS wurde einfach nicht aktiviert. Ist wohl nicht verpflichtend. Ich versuch es mal so zu formulieren. Mit SIS geht das komplette surfen über die Box. Ohne SIS nur der Versichertenstammdatenabgleich. MfG

Guten Abend zusammen,
wir sind seit 6 Wochen dabei. Nach erfreulicherweise fehlerfreier Installation einer KocoBox, habe wir das erste update für die Box eingespielt.
Einen Tag später konnten wir keinen Versichertenstammdatenabgleich mehr durchführen.
Ich startete daraufhin das Gerät neu. Hiernach ging alles wieder allerdings nur für 2 Stunden. Die Fehlermeldung war Error 1 keine VSDN Verbdingung möglich wobei bei VSDN ok stand. Nun müssen wir alle 2h den Konnektor neu starten und den Rechner mit dem Kartenlesegerät, damit wir weiter einen VSDN Abgleich durchführen können.
Auch die VSDN Verbindung zu KV Safe Net hat nicht mehr funktioniert. Auch hier musste dann ein Rechnerneustart erfolgen.
Hat jemand mit diesem Problem nach dem KocoBox update Erfahrung und muss man wirklich jedes Mal alle Rechner neu starten, wenn man die Box neu gestartet hat?

Guten Abend.

Das Update habe ich mich noch nicht getraut. Steht für übernächste Woche auf dem Plan. Da kann ich also nichts zu sagen.
Du meinst VPN und nicht VDSM zum KV-Safenet?! Das da ein Rechnerneustart helfen sollte, würde mich wundern. Letztlich kriegen die Rechner ja nichts davon mit. Die haben eine lokale Route in der steht, dass alles an einen bestimmten IP Bereich an die KoCo-Box geschickt werden soll. Wenn die Box also das VPN zum Safenet nicht aufgemacht hat, interessiert das den Rechner nicht ein Stück. Ich bin da also eher bei Problemen mit der Namensauflösung oder so was. Schwierig, sowas aus der Ferne zu diagnostizieren.
Der Versicherten Stammdatenabgleich ist nicht zwingend Vorraussetzung für das Einlesen der Karten! Solange sich der Kartenleser an der Box anmelden kann, können Karten eingelesen werden. Unabhängig davon, ob die Daten mit der KK abgeglichen werden kann. Dauert halt nur länger. Aber alle zwei Stunden die Schüssel neuzustarten, dauert sicherlich länger…

Hallo Benny,

vielen Dank für die schnelle Antwort. Ja entschuldige, ich meinte VPN. Er sagt aber auch VPN SIC und das ist ja wie ihr oben beschrieben habt nicht zwingend.
Erst habe ich gedacht, dass das Problem wegen der Fernwartung des TI Technikers entstanden ist. Damals hat uns der Techniker bei der Erstinstallation gesagt, dass der Konnkektor dann ein Problem bekommen könnte und neu gestartet werden müsste. Also bin ich in den Serverraum und habe das gute Stück neu gestartet.
Dann hat das Kartenlesegerät die Verbindung nicht mehr bekommen und SMCB war bei Betriebsbereitschaft herstellen rot hgeblieben und auch nach korrekter PIN Eingabe für das Kartenlesegerät. Dann habe ich den Rechner mit dem Kartenlesegerät neu gestartet.
Dann ging alles wieder… für drei Stunden. Anschließend kam wieder der gleiche Fehler: Error I Fehlercode 4056. Die Karte wird dann gar nicht mehr eingelesen. Der Balken bleibt während der eGK Prüfung hängen. Also weder mit noch ohne VSDM kann man einen Behandlungsfall anlegen. Ich habe dann wieder die Box neu gestartet.
Gleiches Spiel. Wieder Rechnerneustart erforderlich. Dann lief es wieder.
Dann habe ich versucht meine DMPs rauszuschicken:
Dann kam: LDAP Fehler Failed Sending KV Connect mime message for recipient edmp.knon.bmberg@kvaefnet.de via POST from https: Kv-safenet.de java.net.COnnect.Exception: Connection timed out connect.
Und jetzt halt Dich fest, habe ich den Rechner (ein anderer)einfach neu gestartet und habe die DMPS rausbekommen ohne Fehlermeldung. Das Dumme ist nur, dass sich der ganze Spaß alle paar Stunden wiederholt und noch dümmer ist, dass wir seit 8 Stunden auf den Rückruf des TI Technikers der CGM warten. Hast Du vielleicht eine Nummer, wo man nicht in der Hotline landet wo man nur sagt, dass man angerufen wird aber nicht sagen könne wann?
Wenn Du das update installierst, kannst Du derzeit nicht sehen, wann es beendet wirde. Das feature wurde (Originalton TI) nämlich vergessen einzuspielen. Daher kann man nur auf die Uhr schauen und hoffen, dass es geklappt hat. (Wir haben eine Fernwartung beansprucht, um das prüfen zu lassen ohne das System zu verlassen).
Das update scheint also (mal wieder) nicht ausgereift. Da man uns gesagt hat, dass das update dazu führen könne, dass man nachher keine Karten mehr einlesen könne, habe ich es vorgezogen es Ende des Quartales zu machen. Nur hat uns NIEMAND gesagt, dass auch KV Safe Net und Commect dadurch beeinträchtig werden……

Wie gesagt, es ist nicht ganz leicht von extern zu diagnostizieren. Beim lesen habe ich mal kurz überlegt, ob du vielleicht die IP Adresse der Box doppelt im Netz hast… Das sollte eigentlich nicht passieren dürfen, aber zu viele Köche und so… Muss nur einer nicht richtig aufpassen. Denn wenn der Kartenleser nicht verbinden kann, spricht das für eine Nichterreichbarkeit der Box. Und abseits von Problemen auf den höheren Ebenen (Betriebssysteme die wegen Updates hängen), ist auch das eine Möglichkeit. Wobei der Zusammenhang zum Update schon auffällig ist. Vielleicht kannst du mal testen, in dem du möglichst nur Box, Kartenleser und einen Arbeitsplatz in Betrieb nimmst? Ist umständlich, aber wenn man niemanden hat der mal eben das Netzwerk auf links drehen kann (oder auf der Box in die Logfiles schaut), vielleicht die einzige Möglichkeit.
Als Rufnummer habe ich tatsächlich auch nur die 0800 5515512. Vielleicht wäre es sinnvoll, jemanden für`s Netzwerk dazu zu holen. Für den Fall der der Hotiner komische Fragen stellt…

Vom Beitragsautor

Und jetzt ist ein falsches Zertifikat auf der koco box und das bekomme ich von meinem it unternehmen:

Guten Tag,
anbei ein Statusbericht zum Zertifikatsfehler. Das versprochene Tool der CGM steht uns /Ihnen derzeit noch nicht zur Verfügung.
Da auch die Quartalsabrechnung vor der Tür steht (KV-Portal nicht erreichbar über die TI) benötigen wir Ihre Entscheidung.

Rückmeldung zur Ihrer Entscheidung bitte ausschließlich per Mail an xxxxxxxxxxxxxxxxxx

>>> Wir warten ab, bis das Softwaretool zur Verfügung steht.

>>> Wir trauen uns selbst zu, das Zertifikat über die Konnektor-Konsole einzuspielen und den Konnektor anschließend neu zu starten. (Bitte Anleitung per E-Mail übermitteln).

>>> Bitte planen Sie eine kostenpflichtige Fernwartung am Freitagvormittag ab 09:30 Uhr für uns ein, wir werden Ihnen dann Teamviewer-ID und Kennwort zufaxen.
(Bitte Fernwartung per Teamviewer am Online-PC ermöglichen, also der PC an den Sie Ihre KV-Abrechnung durchführen werden).

>>> Bitte planen Sie eine kostenpflichtige Fernwartung am Dienstagvormittag ab 08:30 Uhr für uns ein, wir werden Ihnen dann Teamviewer-ID und Kennwort zufaxen.
(Bitte Fernwartung per Teamviewer am Online-PC ermöglichen, also der PC an den Sie Ihre KV-Abrechnung durchführen werden).

Nach Einspielen des Zertifikats und Neustart des Konnektors stehen Ihnen alle Funktionen ca. fünf Minuten später zur Verfügung.

Halten Sie für alle Fälle die Ihnen ausgehändigten Dokumentationen und Zugangsdaten zur Verfügung.

Und die cgm ist so unverschämt, auch noch darauf hinzuweisen, dass ja alles gut funktioniere, die box sich ja Sicherheitsgründen technisch richtig verhalten und abgeschaltet hat. Cool.

Was meint ihr? Geld zurück???

Ich habe das Gefühl, ein Teil des Kommentars fehlt?! Mir ist nicht ganz klar, warum die Box ein falsches Zertifikat bekommen hat…
Aber warum auch immer – die Zertifikate sind Teil der Infrastruktur. Diese richtig auszuliefern, ist ausschließlich Aufgabe der Infrastrukturbetreiber. Nicht einen Cent würde ich dafür bezahlen – auch wenn ich den Dienstleiter hier verstehen kann. Der hat ja auch nichts damit zu tun. Oder aber, die Rechnung an die CGM durchreichen. Mit ist auch nicht klar, warum die CGM hier nicht selbst mit dem entsprechenden Support reagiert?!

Die Abrechnung, kann im Zweifelsfall auch von jedem anderen Kollegen aus erfolgen. Technisch betrachtet, ist es egal mit welchen Daten man sich im KV-Portal anmeldet. Man muss nur einen Kollegen finden, der einem gestattet, seinen Zugang zu nutzen. Das würde aber den „Druck“ mit der Abrechnung entschärfen…
Aber generell würde ich mich freuen, auch den Rest der Geschichte zu lesen!

Ich habe nur IPv4-Adressen im Artikel gesehen.
IPv6 ist da wohl noch nicht angekommen, obwohl heutzutage fast alle neuen Glasfaseranschlüsse mit DS-lite, also IPv6 bedient werden.

Wenn ich mich recht erinnere, gibt’s bei den WAN-Einstellungen IPv6. Ich habe aber nicht übertrieben stark darauf geachtet.
DS-Lite und Glasfaser? Ich hoffe doch mal schwer, dass man bei einem FTTH / FTTB-Anschluss, vernünftigen Dualstack-Betrieb bekommt und eben nicht, diesem DS-Lite Blödsinn! Und begegnen einem wirklich schon vollständige Glasfaser-Anschlüsse in DE? Ich wäre ja so neidisch!

https://de.wikipedia.org/wiki/IPv6#Dual-Stack_Lite_.28DS-Lite.29

„vernünftiger Dualstack-Betrieb“ ist ein Luxus, den im Allgemeinen nur die Telekom noch gratis bietet, bei vielen anderen ist der nur noch für Geschäftskunden (passt bei Ärzten) gegen Aufpreis(passt bei niemanden) zu haben
Ich sehe schon, einige wird es noch eiskalt erwischen. (von einigen 6rd-Ausnahmen abgesehen, ist IPv6 in der Regel nativ, egal ob bei DS oder DS-lite)

Obwohl ich gestehen muss, dass ich bei der Nummer schon ein bisschen neidisch war. Hätte ich mir gerne angesehen. 😉
Wobei es ja „nur“ lokal installierte Software ist. Aber allein der Gedanke, so war via lokalem Webserver abzuwickeln, fand ich schon sehr ambitioniert. Es ist ja nicht so, als gebe es nicht täglich z.B. Probleme mit „Sicherheitssoftware“, die mittels selbstsignierten Zertifikanten, Man-in-the-middle-Angriffe fährt. Was für so eine Konstruktion vermutlich in mehrfacher Hinsicht übel wäre… Um nur ein Beispiel zu nennen – aus einer langen Liste von möglichen Problemstellungen.
Aber ja, die Installation ist vermutlich einfacher. 😉

Aktuell TI-Lösung und Datenschutz – der Widerspruch kann größer nicht sein!

Es handelt sich bei Gesundheitsdaten um „besonders schützenswerte Daten“. Damit sind die Anforderungen an alle am Erfassungs-, Speicherung-, Verarbeitungs- und Übermittlungsprozess beteiligten Systeme besonders hoch und müssen Ihrer Bedeutung entsprechen. TI als Bestandteil des Übermittlungsprozesses scheint diese Anforderungen nicht zu erfüllen, denn, wie im Artikel zu erkennen, allein der Aspekt „Sicherheit durch Technikgestaltung“ ist nicht gewährleistet.
Im Übrigen: Selbst die Umsetzung von TI, innerhalb des Verfahrens im Umgang mit den Gesundheitskarten bedarf der Zustimmung der Datenschutz-Aufsichtsbehörden! Existiert hier von den Behörden eine Stellungnahme bzw. Freigabe? Mir ist nichts bekannt! Damit liegt bereits hier ein Verstoß nahe!

Ja… bei dem Kommentar möchte ich „JA“ rufen… aber da mir definitiv das fachliche Wissen für eine akkurate, rechtliche Einschätzung fehlt, spare ich mir das. Ich denke, dass gerade auch in Hinblick auf die DSGVO durchaus der eine oder andere Punkt zu klären wäre. Ich würde mal schätzen, dass die Datenschützer nur aus der Entfernung einen Blick auf das Konstrukt werfen durften. Meines Wissens nach – und dieser Hinweis ist mir wichtig!!! – gibt es keine öffentlichen Äußerungen der zuständigen Aufsichtsbehörden. Aber es handelt sich hier auch explizit um eine Infrastruktur. Diese verarbeitet keine Daten, sondern dient deren Transport. Damit ist dem Arzt, der diese mitunter unwissendlich ausleitet, natürlich auch nicht geholfen.

Oh mein Gooottttt!
Was sagt das BSI dazu? Angebliche Zertifizierung dieser Lösung durch das BSI ?– kann ich mir beim besten Willen nicht vorstellen!
Und die ganzen, teilweise widersprüchlichen Ansätze der CGM zur Lösung – ist ja wie die aktuelle GroKo-Debatte!

Es gibt nur eine Lösung — sofortiger Stop der Umsetzung! Hier sind noch sehr viele Hausaufgaben zu machen

Das BSI hat sich (im Auftrag) jedenfalls mal damit beschäftigt:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116.pdf;jsessionid=B1C5D4CAD4ED31AAA2F621BC144F3B8F.2_cid360?__blob=publicationFile&v=2

In wie weit man dem gerecht werden kann (= Zertifizierung) und trotzdem gegen das BDSG oder die DSGVO verstoßen kann, überlasse ich mal anderen. Ich bin mir aber sicher, dass die Richtlinie auch viel Spielraum bietet…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert