eAU - o.k. am Server - Versandfehler an den Clients

[kiwi]

Hallo zusammen,

wir haben das Problem, dass die eAU zwar am Server funktioniert und auch versendet/zugestellt wird, aber an den Arzt-Clients wird nur ein Versandfehler produziert

TM-Version 22.2.2.5441
TLS aktiviert, momentan noch Einzelversand
KIM auf Praxis registriert (weil nur eine KIM-Adresse, aber 2 Ärzte)
Signatur geht überall problemlos sowohl über SMC-B als auch über eHBA
Im Infomodell sind alle Clients eingetragen mit Verbindung zum Konnektor, etc.
An den Clients erstellte eAUs mit Versandfehler können im Nachhinein im E-Center vom Server aus versandt und zugestellt werden

Hat jemand eine Idee, wie wir die eAU auch an den Arzt-Clients zum Laufen (bzw. zum Versenden) kriegen könnten ?

Viele Grüsse
Kiwi

[nappi218]

Hallo,

siehe viewtopic.php?f=11&t=8806&start=45

Die clients finden die \client.p12 nicht und brauchen den Pfad

Beste Grüße
Nappi

[kiwi]

Hallo nappi218,

in der config des KomlePlugins ist die Server-IP ist eingegeben
<ldapsCertificatePath>\\XXX.XXX.XXX.XXX\TurboMed\Daten\Var\Konnektor\Zertifikate\.....\client.p12</ldapsCertificatePath>
Daran kann es eigentlich nicht liegen
Vielleicht noch andere Ideen ??

[DC19]

Wir haben auch den "Versandfehler" 420. Signieren, erstellen kein Problem. eRezept geht (wenn es nicht so Zeitaufwenig wäre). Sonntag wurde vor Wochenbeginn nochmal die eAU getestet, ohne Probleme (aktuelles Update). eAu eigentlich seid 2 Wochen sicher lauffähig.

Heute RS mit der TM Hotline (wirklich kompetent), es wurde alles angeschaut, einschließlich Client/Server, alles richtig, keine Fehler unsererseits. Am Ende wurde differenziert dass es ein grundsätzliches Problem gibt. Unklar ob seitens der Ti (Fachmodul) oder TM seitig. Wir werden informiert (Anruf oder Rundschreiben) wenn es eine Lösung gibt.

Seit der eAU vor über 2 Wochen, bekommen die Patientin auch bei bisheriger erfolgreicher Zustellung den KK Zettel mit, und sollen dies einreichen. So werden wir es einfach weiter machen. Nach dieser Beratung und Prüfung verschwende ich keine weitere Zeit. Es ist ausserdem bekannt, dass TM häufiger "Abstürzt". Lösung/Fehlersuche läuft.

MFG

[rfbdoc]

Am Ende wurde differenziert dass es ein grundsätzliches Problem gibt.

Das ist ja immerhin schon ein Zugeständnis.
Bei uns bis 30.6.22 keine eAU Probleme. Seit Update auf 23.3.1 nur noch Probleme mit den o.g. Fehlern und natürlich wie immer der unverschämte Verweis an den Vertriebspartner. Man wird von der TM Hotline schlicht und ergreifend hingehalten.

Es ist aus meiner Sicht nur Lebenszeitverschwendung einen Fehler in der eigenen Konfiguration zu suchen, wenn mit der Vorversion die eAU problemlos lief.

KIM über eCockpit oder Thunderbird ist hier nicht betroffen.

[Freich]

Hallo,
ich habe auch Problem mit der Verbindung von TM und dem Clientmodul.
Selbst nach (mehrfacher) Registrierung/Deregistrierung der Kim Adresse - in meinem Fall eine KV-Dox Adresse -geht es nicht.
Ich kann mit Thunderbird Problemlos KIM Nachrichten senden und empfangen, jedoch TM verweigert kommentarlos den Dienst.
Eine Fehlermeldung im eCockpit beim senden lautet.

eNachricht Editor.png

Die config Datei in KOMLEPlugin ist seltsam leer, ich vermute hier den Fehler:

KOMLEPlugin_config.xml - Notepad+.png

Ist bei Ihnen die Datei auch nicht mit Zugangsdaten befüllt ? Die Ports kommen mir auch komisch vor.

Der Turbomed Dienstleister konnte mir nicht helfen!
Ich hatte zuerst noch TLS aktiviert - er meinte nur das würde nicht richtig funktionieren....

[rfbdoc]

Fehlt da nich die komLeClientAdresse ?

Hier meine config:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
<pop3Port>8995</pop3Port>
<smtpPort>8465</smtpPort>
<komLeClientAdresse>192.168.0.10</komLeClientAdresse>
<Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
<ldapUrl>ldaps://192.168.0.208:636</ldapUrl>
<ldapStartTls>false</ldapStartTls>
<FachdienstPortSMTP>465</FachdienstPortSMTP>
<FachdienstPortPOP3>995</FachdienstPortPOP3>
<ldapsUsage>true</ldapsUsage>
<ldapsCertificatePath>\\192.68.0.10\F\TurboMed\Daten\Var\Konnektor\Zertifikate\9ADAE77F-A11C-4d67-AFC8-EB64D5146BBD\client.p12</ldapsCertificatePath>
<ldapsCertificatePassword>GELÖSCHT<ldapsCertificatePassword>
</GeneralConfiguration>

[Freich]

Hmmm,
ich probiere morgen mal das händisch zu befüllen...
@rfbdoc - Danke für den Einblick!

[Forti]

[...]
Heute RS mit der TM Hotline (wirklich kompetent), es wurde alles angeschaut, einschließlich Client/Server, alles richtig, keine Fehler unsererseits. Am Ende wurde differenziert dass es ein grundsätzliches Problem gibt. Unklar ob seitens der Ti (Fachmodul) oder TM seitig.

MFG

Gut zu wissen:
Fehler tritt auf mit TM + dgn-KIM + Kocobox.
Fehler tritt auch auf mit Secunet-Konnektor, CGM KIM, TurboMed.

Fehler tritt nicht auf mit Medical Office, CGM KIM und Secunet-Konnektor.
Fehler tritt nicht auf mit ALBIS, Doc Cirrus, MEDISTAR mit verschiedenen Konnektoren usw.

Also sind Konnektoren, KIM und Zugangsdienste "raus". Was bleibt?
Richtig: TurboMed. Und nicht am 1. Juli 2022, sondern in unveränderter Umgebung ab 4. Juli 2022. Da ist mir völlig egal, in welchem Modul der Fehler steckt. Mich interessiert nur, "was in der Hektik des Alltags sicherlich mal übersehen werden konnte". *nach-Luft-ring*

[Netzi]

Hmmm,
ich probiere morgen mal das händisch zu befüllen...
@rfbdoc - Danke für den Einblick!

Hallo,

Wird nicht funktionieren es gibt zu viele stelle in TurboMed wo Parameter abgelegt werden, und wenn wird Sie nicht sauber funktionieren.

Tipp:
- TLS Einrichten in TurboMed
- Dann KIM einrichten

Noch ein kleiner Hinweis: Mit den neuen Q3/22 Update funktioniert die Einrichtung mit einer kv.dox Adresse nicht richtig.
Konfigurationsparameter die man einträgt fliegen direkt nach dem Verlassen der Eingabemaske raus.

Mit den Update wurde Konnektorverbindung erneuert und das ist aktuell sehr schrecklich...

Dafür werde ich jetzt gelyncht ...
Wenn man einen anderen KIM Anbieter wählt, bedenkt das es in manchen fällen keinen Support seitens CGM/DVO gibt. (außer der DVO ist ganz nett)
Die Zuständigkeit wird hin und her geschoben, das sollte einen klar sein.

Das war keine Werbung für die CGM KIM Adresse

[kiwi]

RFB
Fehlt da nich die komLeClientAdresse ?

Hier meine config:

Ich habe jetzt bemerkt, dass in unserer config bei der KomLeClientAdresse der NAME des Servers steht anstatt der Server-IP.
Kann das einen Unterschied machen ?
Werde ich mal ausprobieren.

[hw]

Bei uns hat die Angabe der Server-IP nicht zum Erfolg geführt. Die Eingabe des Servernamens anstelle der IP hat aber funktioniert. Ich denke, dass das ein Problem der Freigaben ist.

[nappi218]

Hallo,

Bei uns hat die Angabe der Server-IP nicht zum Erfolg geführt. Die Eingabe des Servernamens anstelle der IP hat aber funktioniert. Ich denke, dass das ein Problem der Freigaben ist.

Ja, das ist oftmals wohl das Problem. Der Pfad bezieht sich auf die Standard-Freigabe, die bei der Serverinstallation angelegt wird. Wer unter Netzwerk --> Server keine Freigabe "Turbomed" hat muss den Pfad wohl anpassen.

Ggf. am client in Windows über Netzwerk--> server --> in den entsprechenden "TurboMed\Daten\Var\Konnektor\Zertifikate\......\ navigieren --> rechte Maustaste --> als Text kopieren. Dann hat man den freigegeben Pfad und dann sollte es gehen.

Beste Grüße
Nappi

[rfbdoc]

Ich habe jetzt bemerkt, dass in unserer config bei der KomLeClientAdresse der NAME des Servers steht anstatt der Server-IP.
Kann das einen Unterschied machen ?

Eigentlich nicht, sofern DNS richtig konfiguriert ist.

Aber die Sektion komLeClientAdresse (5. Zeile im Post) war in Ihrem Post doch leer
(ebenso die Sektion Fachdienstadresse, 6.Zeile im Post)

[kiwi]

Aber die Sektion komLeClientAdresse (5. Zeile im Post) war in Ihrem Post doch leer
(ebenso die Sektion Fachdienstadresse, 6.Zeile im Post)

das war der Post von Freich, ich habe meine komplette config nicht gepostet. Bei uns ist die KomLeClientAdresse etc. befüllt.
Trotzdem gelingt es mir nicht, die Clients zum Senden zu bringen (am Server funktioniert es tadellos).
In der config habe ich sowohl den Servernamen als auch die IP benutzt - keine Änderung.
An den Netzwerkfreigaben kann es auch nicht liegen, der Server und Turbomed sind übers Netzwerk ansteuerbar.
Ich habe auch die Firewalleinstellungen (CGM Connect und KIM) am Client nochmals als Administrator laufen lassen und auch einen Versuch mit ausgeschalteter Firewall gestartet - immer dasselbe -> Versandfehler.
Momentan habe ich keine Idee mehr
Wäre aber für jedem Hinweis dankbar...

Viele Grüsse
Kiwi

[nmndoc]

Aber die Sektion komLeClientAdresse (5. Zeile im Post) war in Ihrem Post doch leer
(ebenso die Sektion Fachdienstadresse, 6.Zeile im Post)

das war der Post von Freich, ich habe meine komplette config nicht gepostet. Bei uns ist die KomLeClientAdresse etc. befüllt.
Trotzdem gelingt es mir nicht, die Clients zum Senden zu bringen (am Server funktioniert es tadellos).
In der config habe ich sowohl den Servernamen als auch die IP benutzt - keine Änderung.
An den Netzwerkfreigaben kann es auch nicht liegen, der Server und Turbomed sind übers Netzwerk ansteuerbar.
Ich habe auch die Firewalleinstellungen (CGM Connect und KIM) am Client nochmals als Administrator laufen lassen und auch einen Versuch mit ausgeschalteter Firewall gestartet - immer dasselbe -> Versandfehler.
Momentan habe ich keine Idee mehr
Wäre aber für jedem Hinweis dankbar...

Viele Grüsse
Kiwi

Im Infomodell auf dem Konnektor (zB Kocobox) sind die Clients aber richtig eingetragen?

[kiwi]

Anbei unser Infomodell, ich denke eigentlich schon, dass hier alles richtig ist.
Station 1 ist der Server, Station 2 und 3 sind die clients, von denen aus das Versenden nicht funktioniert.
Sie haben eine Verbindung zu dem jeweiligen Kartenleser im Sprechzimmer und zum Kartenleser an der Anmeldung.
Aktuell signieren wir immer mit SMC-B (steckt im Kartenleser an der Anmeldung), da die eAU nur am Server erstellt werden kann.
Unter Mandant sind alle 3 PC's, der Konnektor (KocoBox) und alle 3 Kartenleser eingetragen

[DocMoritz]

ich denke. Sie sollten auch im Menü SMBen bei Kartenterminale ( bei Ihne rechts abgeschnitten) auch die 2 Clients dazufügen ( alles ohne Gewähr), bei mir sind die Clients dort angekreuzt, so dass diese auch SMB nutzen können.
Muss mich Korrigieren: die Zuordnung zu den KartenTeminale geschieht beim anklicken der Stifte unter Arbeitsplätze

[kiwi]

Hallo Doc Moritz,
den Clients sind die Kartenterminals zugeordnet, signieren geht auch problemlos von den Clients über SMCB - nur Versenden geht eben nicht.

Mittlerweile habe ich noch im KOMLEPlugin unter unserer KIM-Adresse Dateien für die 2 Clients angelegt mit entsprechender config (bis jetzt war dort nur eine Datei für den Server vorhanden) - wie von Icer beschrieben

4) im Verzeichis F:\TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin\ sind Unterverzeichnisse mit den KIM-Email-Accounts. In diesen wiederum muss ein Unterverzeichnis für jeden Arbeitsplatz (Name=Comoputername des Arbeitsplatzes) existieren, von dem aus man KIM nutzen will. Fehlt das, gibt es einen Fehler. In Unterverzeichnissen muss eine config.xml enthalten sein, die den passenden Computernamen enthält. Also für den PC "ARZT1"

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<WorkplaceConfiguration>
<workPlaceID>ARZT1</workPlaceID>
</WorkplaceConfiguration>

Hat aber leider nichts geändert

[hw]

Hier meine config:
.......
<ldapsCertificatePath>\\192.68.0.10\F\TurboMed\Daten\Var\Konnektor\Zertifikate\9ADAE77F-A11C-4d67-AFC8-EB64D5146BBD\client.p12</ldapsCertificatePath>
.....

Ist da nicht ein Fehler in der Zeile? Nach der IP des Servers ist "F" doch vermutlich das Laufwerk. Muss es dann nicht "F:" heißen?