eAU

[Roland_Colberg]

Nachdem es so aussieht, dass es zum 1.7. mit der eAU "ernst" wird, versuche ich diese Funktion derzeit zum Laufen zu bringen.

Die ersten Versuche waren zunächst erfolgreich, die eAUs wurden im eMuster-Center abgelegt und konnten von dort signiert und versendet werden.

Dann habe ich zur Nutzung der Komfort-Signatur die TLS-Verschlüsselung am Konnektor und in Turbomed eingeschaltet, bin dabei nach der "Anleitung Aktivierung TLS-Schlüssel" von Turbomed vorgegangen. Das hat auch funktioniert, nachdem ich in den Turbomed Konnektor-Einstellungen zusätzlich den Eventport von 45000 auf 45123 geändert und noch das Tool unter "TurboMed - Sonstiges - Wartung - CGM KIM - TLS Verschlüsselung" habe laufen lassen. EGKs lassen sich weiterhin einlesen.

Allerdings findet das Programm seitdem die "Empfangsadresse der zuständigen Krankenkasse" nicht mehr und druckt stattdessen die 2. Kopie für den Kostenträger aus, anstatt die eAU im eMuster-Center anzuzeigen:

Fehlende Empfangsadresse.png

Außerdem konnte im eCockpit Verbindungstest unter CGM KIM keine LDAP Verbindung mehr hergestellt werden (POP3 und SMTP haben funktioniert).

Nach einigem Suchen habe ich unter "Sonstiges - Praxisdaten - Arzt - Zusatzdaten - KIM - Konfigurationsparameter ändern" von den Verzeichnisdienst von LDAP auf LDAPS umgestellt, seitdem funktioniert KIM wieder, das Problem bei der eAU besteht aber weiter.

Nachdem die eAU hier offenbar bei mehreren Praxen auch mit Komfortsignatur/TLS funktioniert: ist dort LDAP oder LDAPS eingestellt, bzw. hat das überhaupt eine Auswirkung auf die eAU?

Hat jemand ähnliche Probleme (gelöst)?

[nappi218]

Hallo,

funktioniert die eAU am Server?

Wir hatten das Problem auch - gelöst wurde es durch den Service-Partner - ich hab mir folgendes notiert:

Problem: Kim Suche Geht nicht am Arbeitsplatz.

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>

Vielleicht hilft es ja.

Beste Grüße
Nappi

[nappi218]

Nachtrag:
\\XXX.XXX.XXX.XXX\ = Serveradresse

Gruss Nappi

[rfbdoc]

@Roland Colberg
Nach Umstellung auf TLS muss Kim einmal deregistriert und wieder neu registriert werden.
Dann müsste auch unter TLS der eAU Versand wieder laufen.
Zum Thema Drucken:
Wenn eine zum Versand markierte eAU nicht versandt werden kann erfolgt automatisch der Ausdruck des Durchschlags für die Krankenkasse. Eigentlich ja nicht dumm. Der Ausdruck muss dann von der Praxis an die Kasse geschickt werden, dafür gibt es auch eine Portoziffer 86cent im EBM.
Bei mir war es meist so, dass bei einem späteren neuen Sendeversuch der Versand dann doch glatt durchlief.

Bei mir klappt allerdings die Signierung nur über die SMCB und nicht über den eHBA, warum auch immer. Vermutlich ein Fehler in meinem Infomodell

[hw]

Ja, wir haben seit der nachträglichen Umstellung auf TLS genau die von Roland_Colberg beschriebenen Probleme, dass die Adresse der Krankenkasse nicht mehr gefunden wird. Das hat vor der Umstellung noch funktioniert.
KIM scheint noch zu funktionieren, wir können jedenfalls Adressen suchen und uns selbst auch Briefe usw. schicken. ABer eAU-Versand geht nicht, da die Adresse der Krankenkasse nicht gefunden wird.
Hat jemand das Tageskennwort für 21.5.22, dann würde ich mal KIM deregistrieren und neu registrieren.

[Roland_Colberg]

Hallo,

funktioniert die eAU am Server?

Nein, auch am Server besteht dieses Problem.

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>

Das ist interessant. Bei mir sieht diese Datei (auf dem Server) so aus:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
    <pop3Port>8995</pop3Port>
    <smtpPort>8465</smtpPort>
    <komLeClientAdresse>TS1</komLeClientAdresse>
    <Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
    <ldapUrl>ldap://192.168.xxx.xxx:389</ldapUrl>
    <ldapStartTls>false</ldapStartTls>
    <FachdienstPortSMTP>465</FachdienstPortSMTP>
    <FachdienstPortPOP3>995</FachdienstPortPOP3>
    <ldapsUsage>false</ldapsUsage>
</GeneralConfiguration>

TS1 ist der Turbomed-Server, 192.168.xxx.xxx der Konnektor
Somit scheint dieses Plugin bei mir weiter LDAP statt LDAPS zu verwenden, was die erfolglose Adresssuche erklären könnte.

Vermutlich muss ich hier nicht nur den Zertifikatspfad, sondern auch das Passwort irgendwo eintragen. Können Sie mir mal Ihre ganze config.xml (ohne Passwort ) schicken?

Das Tageskennwort für heute habe ich leider auch nicht, daher kann ich KIM gerade nicht neu registrieren.

Vielen Dank!

[hw]

Bei uns genau der gleiche Dateiinhalt und auch keine eAU auf keinem Arbeitsplatz, auch nicht auf Server.

[hw]

Wir haben jetzt KIM deregistriert, Konto gelöscht und neu registriert. Danach geht tatsächlich die eAU wieder, so wie es jetzt aussieht. Zumindest am Server, mehr habe ich noch nicht ausprobieren können.
Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Das Tageskennwort für 30.4.2022 lautet: 923796 (wenn das jemand verwenden will, muss der Rechner auf dieses Datum eingestellt werden, danach nicht vergessen, wieder das aktuelle Datum zu verwenden!)

Also: rfbdoc hat Recht, KIM neu Registrieren hilft auch hier!

[Roland_Colberg]

Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Könnten Sie mir die funktionierende config.xml mal zukommen lassen (gerne auch per pn, und ohne Passwort)? Das mit der Datumsumstellung würde ich gern vermeiden.

Vielen Dank!

[Thomas]

Das ist meine config.xml:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
    <pop3Port>8995</pop3Port>
    <smtpPort>8465</smtpPort>
    <komLeClientAdresse>TS</komLeClientAdresse>
    <Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
    <ldapUrl>ldaps://ip_des_konnektors:636</ldapUrl>
    <ldapStartTls>false</ldapStartTls>
    <FachdienstPortSMTP>465</FachdienstPortSMTP>
    <FachdienstPortPOP3>995</FachdienstPortPOP3>
    <ldapsUsage>true</ldapsUsage>
    <ldapsCertificatePath>C:\TurboMed\Daten\Var\Konnektor\Zertifikate\4BABDF6F-1382-41b2-9FCB-9C190F97791A\client.p12</ldapsCertificatePath>
    <ldapsCertificatePassword>my0+tQoCzbXszjM9npRLHAL1hBf+S6cnknrwjK3Ux4w=</ldapsCertificatePassword>
</GeneralConfiguration>

Das mit dem Tageskennwort und der Datumsrückstellung tut gar nicht so weh: Ich gehe immer bis zur Abfrage des Tageskennworts, gebe das ein, stelle dann das Datum um, klicke auf ok, um das Kennwort zu bestätigen, und - bevor ich dann irgendetwas anderes in TM mache - stelle ich sofort das Datum wieder korrekt ein. Dann sollten alle Datenbanken usw. keine falschen Einträge bekommen...

Viele Grüße
Thomas

[nappi218]

Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Könnten Sie mir die funktionierende config.xml mal zukommen lassen (gerne auch per pn, und ohne Passwort)? Das mit der Datumsumstellung würde ich gern vermeiden.

Vielen Dank!

Hallo,

Datei sieht so aus:

<?xml version="1.0" encoding="UTF-8" standalone="true"?>
-<GeneralConfiguration>
<pop3Port>8995</pop3Port>
<smtpPort>8465</smtpPort>
<komLeClientAdresse>server</komLeClientAdresse>
<Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
<ldapUrl>ldaps://xxx.xxx.xxx.xxx:636</ldapUrl>
<ldapStartTls>false</ldapStartTls>
<FachdienstPortSMTP>465</FachdienstPortSMTP>
<FachdienstPortPOP3>995</FachdienstPortPOP3>
<ldapsUsage>true</ldapsUsage>
<ldapsCertificatePath>\\xxx.xxx.xxx.xxx\TurboMed\Daten\Var\Konnektor\Zertifikate\xxxxxxxxxxxxxxxxxxxxxxxxxx\client.p12</ldapsCertificatePath> ' hier muss der Netzwerkpfad rein, sonst sind die clients anscheinend blind
<ldapsCertificatePassword>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=</ldapsCertificatePassword>
</GeneralConfiguration>

und hier das Vorgehen wie ich bei uns die TLS-eAU neu eingerichtet habe:

Einrichtung TI / KIM --> Vorgehen: alles deinstallieren und dann neu aufsetzen - das kurzzeitige Rückstellen des TagesPW sollte kein Problem sein soweit ich weiss.

--> TM als Administrator starten
--> Sofern eingerichtet muss zunächst die TLS-Verschlüsselung deaktiviert werden
--- sonstiges --> Praxisdaten --> eGK -->
Zertifikatsverzeichnis löschen, auf einfaches http einstellen und alles übernehmen
--- TM beenden und als admin neu starten --> Verbindung zum connector wird scheitern --> sonstiges --> Praxisdaten
--> smcb löschen und
--> Anbindung an connector deaktivieren

--- Kocobox Managementschnittstelle --> Signaturdienst aus
... Kocobox Managementschnittstelle --> Verwaltung --> Clientsysteme --> ja / Aus / nicht aktiviert / Zertifikat
... Zugangszertifikate Turbomed / CA Turbomed löschen und dann übernehmen

--> TM beenden, Server und Kocobox neu starten
--> TM als Admin starten

--> nun das ganze wieder einrichten:
... Anbindung an Connector aktivieren --> SMCB auswählen --> Pin eingeben ...... den Anweisungen folgen
--> Testen des entsprechenden Kartenlesegerätes

--> wenn alles funktioniert, TLS wieder einrichten - zunächst Errechbarkeit der Box unter https testen
(siehe hierzu auch Anleitung zur TLS-Einrichtung im Forum)

--> Kocobox Managementschnittstelle --> Verwaltung --> Clientsysteme --> nein / ein / aktiviert / Zertifikat
--> Zugangszertifikat hinzufügen --> "TurboMed" --> Speichern (am besten Desktop) --> alles übernehmen
--> Signaturdienst einschalten

--> gespeicherte zip-datei entpacken

--> --- sonstiges --> Praxisdaten --> eGK --> https mit Clientzertifikat
--- Zertifikat aus der entpackten zip einspielen, PW ist in der textdatei im selben ordner

--> alles übernehmen und als Admin neu starten.
--> Verbindung testen und eine eGK zum Test einlesen.

Nun kim neu einrichten

--> \TurboMed\NetSetup\Firewalleinstellungen --> FirewallKIM.cmd etc. als admin ausführen

--> Dann Vorgehen wie im Forum beschrieben:
... Kim-Adresse deregistrieren - und mittels Tageskennwort löschen
... Anschließend neu einrichten

--> was auffällt:
Als Praxisadresse eingerichtet --> eCockpit cgm kim --> rot
Als Arztadresse eingerichtet --> eCockpit cgm kim --> grün, verstehe das wer will

Problem: Kim Suche Geht nicht am Arbeitsplatz.

Unter dem 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>

xxx.xxx.xxx.xxx --> ServerIP

Beste Grüße
Nappi

[Randolf]

Hallo
Vielen Dank an Nappi218 für die konkrete Handlungsanleitung, da wir zZt noch nichts aktiviert haben, ist der Weg etwas einfacher und wir planen dank der guten Hilfe duch die Kollegen hier für Juni die Sache doch mal anzugehen und zu versuchen. TM liefert solche Anleitungen eher nicht , oder habe ich sie noch nicht entdeckt ? Unklar wofür wir die hohen laufenden Kosten eigentlich bezahlen ?

[hw]

Vielen Dank @nappi,
nach der KIM-Neuregistrierung sah die Datei genau so aus. Allerdings beinhaltet sie nicht die IP-Adresse, sondern den Laufwerksbuchstabe, unter dem das Verzeichnis am SERVER vorhanden ist.
Das soll ja nach der Anleitung geändert werden.

Problem ohne Änderung:
Am Server klappt eAU und KIM, an den Clients nur KIM
Auf den Clients wird die Datei nicht gefunden. Die eAU-Erstellung läuft auf Fehler auf.

Wenn LW-Buchstabe durch IP des Servers ersetzt wird:
KIM geht überall, eAU kann nirgends mehr erstellt werden.

Irgendwo geht das was schief.
Gibt es einen Unterschied, wenn TLS vom Server aus aktiviert wurde im Gegensatz zum Client als Ausführort? Die Beschreibung von TM zur Aktivierung von TLS ist ja in diesem Punkt unklar und könnte auf einen Client hindeuten.

[nappi218]

Vielen Dank @nappi,
nach der KIM-Neuregistrierung sah die Datei genau so aus. Allerdings beinhaltet sie nicht die IP-Adresse, sondern den Laufwerksbuchstabe, unter dem das Verzeichnis am SERVER vorhanden ist.
Das soll ja nach der Anleitung geändert werden.

Problem ohne Änderung:
Am Server klappt eAU und KIM, an den Clients nur KIM
Auf den Clients wird die Datei nicht gefunden. Die eAU-Erstellung läuft auf Fehler auf.

Wenn LW-Buchstabe durch IP des Servers ersetzt wird:
KIM geht überall, eAU kann nirgends mehr erstellt werden.

Irgendwo geht das was schief.
Gibt es einen Unterschied, wenn TLS vom Server aus aktiviert wurde im Gegensatz zum Client als Ausführort? Die Beschreibung von TM zur Aktivierung von TLS ist ja in diesem Punkt unklar und könnte auf einen Client hindeuten.

Hallo,

die gesamte Anleitung wurde von mir so am Server eingerichtet. Auch laufen alle Dienste auf dem Server.

Könnte es sein, dass die entsprechende Netzwerkfreigabe so bei Ihnen nicht existiert? Unter windows ---> Netzwerk --> Server aufrugfen, hier muss der entsprechende TurboMed-Pfad ("TurboMed") erscheinen / freigeben sein. Ansonsten muss der Pfad angepasst werden.

Beste Grüße
Nappi

[Roland_Colberg]

Vielen Dank für die genauen Anleitungen, bei mir funktioniert die eAU jetzt schonmal auf dem Server, auch mit der Anpassung auf den UNC-Pfad in der config.xml.

Ich habe jetzt auch den Weg über die KIM-Neuregistrierung gewählt, da ja das Zertifikats-Passwort offenbar nicht im Klartext in die config-Datei gehört.

Dabei hatte ich (wie früher schon einmal) das Problem, dass die Deregistrierung zuerst mit einer Fehlermeldung abgebrochen ist und danach die KIM-Adressen gar nicht mehr in der CGM KIM Einrichtung angezeigt wurden. Daher habe ich dann

• die TLS-Verschlüsselung ausgeschaltet
• die KIM Konten gelöscht (die Warnung ignoriert)
• TLS wieder aktiviert (neues Zertifikat erstellt)
• die KIM-Adressen ohne Probleme wieder registriert.

Neustarts von Konnektor oder Server waren nicht notwendig, allerdings musste der CGM KIM Dienst auf dem Server neu gestartet werden.

@hw: ich denke auch, dass hier die Freigabe des Turbomed-Ordners auf dem Server korrekt angegeben werden muss. Bei mir geht auch der Servername:

\\ts1\turbomed\daten\....

Das sollte auch in einem Explorer-Fenster über die Adressleiste so aufzurufen sein (das ist ein UNC-Pfad, der beginnt mit 2 Backslashes). Wichtig ist, dass über diesen Pfad sowohl der Server wie auch die Clients auf das Zertifikat zugreifen können.

Übrigens frage ich mich, was die Krankenkassen eigentlich mit diesen ganzen Mustermann-Test-AUs anfangen

[Roland_Colberg]

Nachtrag: eAU und KIM funktionieren jetzt auch auf den Clients.

[peter]

Ich kann die eAU unter 5397 Version vom Musterpatienten der TK und AOK Plus austellen, signieren und versenden, nach 10-120 Sekunden kommt die Meldung zugestellt. Soweit so gut.
ABER die eAU zu stornieren( kommt in Hausarztpraxis häufiger bei normaler AU vor, wenn man sich verklickt oder die Länge der AU passt den Patienten nicht) geht nicht. In eMuster Center anklicken geht, aber keine Reaktion von TM System auf "eAU stornieren".Wenn die eAU von Muster Patient 1 Tag alt ist kommt sogar eine Fehlermeldung 4000 und Syntaxfehler. Bei TM und TI Hotline wird das Problem hin und her geschoben. Funktioniert das "eAU stornieren" bei jemanden oder haben auch andere TM Nutzer hier Probleme?

[Thomas]

@Peter: Hier geht das Stornieren in eMuster-Center. Der Typ wechselt auf "eAU Storno" und nach einer Weile der Status (ganz rechts in der Zeile) auf "storniert". Die Test-eAU war vom 22.5., also knapp 3 Tage alt.

[Roland_Colberg]

Bei uns funktioniert das Stornieren auch.

[doc2810]

Prima, dann klappt´s ja aktuell mit dem Gehorsam und den verlorenen gegangenen Eiern, die vielleicht zu Ostern 2023 dann wieder im Nirwana zu finden sind.
Bravo und weiter so!