eAU-Versandproblem, Empfangadresse der KK, Druckerzuordnung

[avd]

Liebe Kollegen, KIM funktioniert bei uns grundsätzlich - wir können uns selbst Mails senden und empfangen - andere Kommunikation findet darüber praktisch nicht statt.

- Am Server lässt sich eAU erstellen und über das eMuster-Center signieren, allerdings nicht versenden (beim Klick auf "Versenden" passiert rein gar nichts, nicht einmal eine Fehlermeldung taucht auf)
- An den Clients landet die eAU nicht im eMuster-Center, da die "Empfangsadresse der zuständigen Krankenkasse" als fehlend gemeldet wird.

Der Ausdruck der Formulare erfolgt auf den Windows-Standarddrucker, d.h. man muss aufpassen, dass "DinA5Hoch" ausgewählt ist, ursprüngliche Druckerzuordnungen unter STRG+E fürs "Direkt Drucken" (STRG+D) werden ignoriert.

Bislang haben wir nicht auf TLS-Verschlüsselung umgestellt. KIM-Adresse ist seit Ende vergangenen Jahres registriert, wurde bislang nicht noch einmal deregistriert/ neuregistriert.

- Würde bei dem Versandproblem die Neuregistrierung und ggf. begleitende Umstellung auf TLS helfen?
- Wie kann man das Fehlen der "Empfangsadresse der zuständigen Krankenkasse" an den Clients beseitigen?
- Gibt es spezielle Druckereinstellungen für das eMuster-Center damit immer "DinA5Hoch" gewählt wird?
- CGM KIM Client Module-Dienst läuft auf dem Server. CBOX ist nicht eingerichtet, weil hier niemand ePA jemals gewünscht hat - vermutlich für eAU nicht relevant?

Hat jemand ggf. Ratschläge zu den Fragen? Besten Dank im Voraus!

[Nobbie]

Alles abschalten und weitermachen wie bisher, ist auch der Rat von der TI-Hotline.

[Roland_Colberg]

Zum Eingrenzen des Problems würde ich mal auf dem Server und auf einem Client im CGM eCockpit Verbindungstest die drei KIM-Verbindungen überprüfen (POP3, SMTP, LDAP). Bei Problemen hier könnte es an der Windows-Firewall auf dem Server liegen, hier ggf. das Script unter Netsetup\Firewalleinstellungen\FirewallKIM.cmd laufen lassen oder versuchsweise die Firewall mal ganz deaktivieren. Wir hatten hier ein paar fehlerhafte FW-Regeln drin, die den Zugriff der Clients blockiert haben.

Dann würde ich mir auf dem Server die Einträge in der Datei TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin\config.xml anschauen.

Es scheint sehr wichtig zu sein, die Einrichtung von KIM und TLS-Verschlüsselung in der richtigen Reihenfolge durchzuführen: zuerst TLS aktivieren und danach die KIM-Adressen registrieren. Danach darf die TLS-Verschlüsselung auch nicht mehr verändert werden, sonst gibt es völligen Kuddelmuddel bei der eAU.

Das Problem mit den Empfangsadressen der Krankenkassen tritt offenbar auf, wenn dieses KOMLE Plugin keinen Zugriff auf den LDAP-Server des Konnektors hat (LDAP ist ein Verzeichnisdienst). Ohne TLS läuft dieser Server auf Port 389, mit TLS auf Port 686, diese Einträge müssen in der config.xml stimmen und mit <ldapStartTls> und <ldapsUsage> korrespondieren.

Außerdem muss bei aktiviertem TLS der Eintrag des <ldapsCertificatePath> manuell in den UNC-Pfad geändert werden, damit sowohl Server als auch die Clients auf das TLS-Zertifikat zugreifen können.

[avd]

@Roland_Colberg
Ganz herzlichen Dank für die sehr ausführlichen Informationen, das werde ich dann mal demnächst hoffnungsvoll angehen.

@Nobbie
Wäre ggf. von Anfang an das beste gewesen, aber jetzt hat die TI-Hotline gut reden, sie hat nicht die Patienten und die KV im Nacken sitzen...

[Nobbie]

sie hat nicht die Patienten und die KV im Nacken sitzen...

Laut Aussage der KVNo soll das alles dann genutzt werden, wenn es funktioniert. Tut es aber nicht. Und Patienten: Die wissen mitlerweile, dass ein Gesetz, welches vorschreibt, dass ab morgen alle Autos fliegen können müssen um die Straßen zu entlasten noch lange nicht dazu führt, das die Autos das auch können.

[Randolf]

Hallo
@Nobbie , Danke, schönes Statement vor dem Feiertag. Noch erzeugt bei mir eine nicht zuverlässig nutzbare EDV bei der Bewältigung der Grundaufgaben der Patientenversorgung mehr Ärger und Druck auf den Nacken als der politische Wunsch nach "Indienststellung einer komplizierten teuren und wenig nutzbringenden TI" .Solange die Sache nicht zuverlässig und stabil anwendbar ist überstürzen wir weiterhin nichts und arbeiten zuverlässig ,konventionell für die Patienten.

[RAMöller]

Heute drei eAU versandt, soweit ok. ´Dann kam jemand mit der neuen NFC-Karte, danach stürzte der Konnektor ab, ohne dass der Fehler erkennbar war (Feld blieb "grün").
Anschließend war der Versand der eAU blockiert. Nach Konektorneustart gings dann wieder.
Frage: Was soll das alles bringen, wenn die Praxis lahmgelegt wird, wodurch auch immer?
Sollten wir uns einen 2. Konnektor zulegen, der dann einspringt, wenn der andere blockiert, quasi im Ping-Pong-Modus?

[Frankolas]

Alles abschalten und weitermachen wie bisher, ist auch der Rat von der TI-Hotline.

Jup, diese Strategie verfolge ich auch und sie funktioniert einwandfrei.

[Nobbie]

Moin,
ganz entgegen meiner Grundhaltung habe ich die eAU mal getestet, und sie funktioniert bedingt. Den Drucker kann man unter Strg+E einstellen als Standartdrucker (DinA 5 KV Papier haben wir gemacht). In den Behandlungsräumen haben wir in den Grundeinstellungen Gematik > Verbindung mit Konnektor: nein eingestellt und auch keinen KVK-Leser zugeordnet (im Infomodell nicht eingebunden). Signieren und versenden machen wir vom Büro aus als Stapelverarbeitung (Grundeinstellungen Gematik > Verbindung mit Konnektor: ja) über die SMC-B Karte, mit dem Arztausweis kommt eine Fehlermedung. Hat die Krankenkasse keine KIM-Adresse, werden alle 3 AU-Formulare gedruckt. Obwohl in den Praxisdaten der Pfad für das Zertifikat auf den Server eingestellt ist, mussten wir die Verzeichnisse TM > Daten > Var .... Konnektor auf jeden Platz kopieren. Nach dem Umstellen auf eAU TM neu starten. Möchte man eine alte AU neu drucken, muß man eAU dafür wieder abschalten und danach wieder einschalten (sonst blauer Kreis etc. und tschüss). Signieren, versenden und empfangen geht recht zügig und wird in der F3 dokumentiert. Danach löschen wir die Einträge im eMuster-Center. Morgen machen wir noch mal einen Testlauf (heute habe ich frei).

[hw]

Hallo,

...mussten wir die Verzeichnisse TM > Daten > Var .... Konnektor auf jeden Platz kopieren

das kopieren von Verzeichnissen des Servers auf Arbeitsplatzrechner kann nicht die Lösung sein.

Siehe https://vondoczudoc.de/viewtopic.php?f= ... 6&start=45

Das Entscheidende ist anscheinend, dass der Pfad in der Datei entsprechend anzupassen ist.

Unter dem Server-Verzeichnis im TM-Ordner ?:\TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin in der config.xml muss ggf. der serverpfad zum Zertifikat eingerichtet werden (nach Installation einer neuen Kim Adresse)
Sofern <ldapsCertificatePath>?:\TurboMed\Daten\Var\Konnektor\Zertifikate\......\client.p12</ldapsCertificatePath>
ändern in
<ldapsCertificatePath>\\XXX.XXX.XXX.XXX\TurboMed\Daten\Var\Konnektor\Zertifikate\.....\client.p12</ldapsCertificatePath>

Für xxx.xxx.xxx.xxx soll die IP des Servers eingetragen werden (im Original steht dort vermutlich der LW-Buchstabe auf dem Server) . Bei uns hat das allerdings zunächst nicht funktioniert, erst als wir anstelle der IP den Servernamen eingetragen haben, hat alles funktioniert. Das ist aber vermutlich ein Problem der Berechtigung/Freigabe bei uns.

[Nobbie]

Moin,
habe jetzt die Datei config.xml angepasst. Seit dem können wir auch mit sem eHBA signieren und versenden, aber danach ist es mit dem Erstellen der eAU vorbei, TM schmiert beim Erstellen der eAU ab. Geht erst wieder nach abschalten, Neustart an allen Plätzen und aktivierung der eAU.