TI-Dienste ECC-Umstellung (TM) nach dem 31.12.25? [GELÖST]

[Augendoc]

Ich habe nichts umgestellt und konnte am 2.1. normal arbeiten: Karten einlesen, eREzept, eAU und ePA liefen.
Und ich hoffe, dass das auch so bleibt.

Allen Mitstreitern und Mitleidern hier ein gutes neues Jahr.

Genauso auch bei mir: kein aktives Eingreifen nötig, alles lief am 02.01.2026

Einen entspannten Start ins Jahr 2026 wünscht der Augendoc

[Augendoc]

Hallo in die Runde,

am 5. Januar habe ich mich noch gefreut, dass alles ging.

Jetzt habe ich im Laufe der Woche festgestellt, dass ich keine eArztbriefe versenden kann.
Das Empfangen von eArztbriefen geht nur mit 3 Tagen Verzögerung nach Absenden durch die andere Arztpraxis.

Alle anderen Funktionen wie eAU, eRP, ePA hochladen und ePA runterladen gehen.

Hat jemand das gleiche Phänomen und weiß Rat? Ich schätze, es ist eine Einstellungssache.

Vielen Dank schon mal für Hilfe
sagt der Augendoc

[Ellringmann]

Ich hatte erstmal auch nichts umgestellt, am 2.1. lief noch alles, nach meinem Urlaub am 11.1. kam die Fehlermeldung "keine Verbindung zum Konnektor".
Im Secunet Konnektor waren ECC und RSA Zertifikate aktiviert. Nach Neuerstellung eines Zertifikats und Einlesen in Turbomed war eine Verbindung zum Konnektor möglich, KIM , eRP und eAU liefen, nur die ePA nicht. Diese lies sich aber durch erneutes Senden der Daten der Cbox beheben.
aktuell läuft unter ECC alles problemlos

[FortiSecond]

Ich hatte erstmal auch nichts umgestellt, am 2.1. lief noch alles, nach meinem Urlaub am 11.1. kam die Fehlermeldung "keine Verbindung zum Konnektor".
Im Secunet Konnektor waren ECC und RSA Zertifikate aktiviert. Nach Neuerstellung eines Zertifikats und Einlesen in Turbomed war eine Verbindung zum Konnektor möglich, KIM , eRP und eAU liefen, nur die ePA nicht. Diese lies sich aber durch erneutes Senden der Daten der Cbox beheben.
aktuell läuft unter ECC alles problemlos

Beinahe alles ECC - bis auf das Konnektorzertifikat selbst, oder? Wenn DAS auch auf ECC umgestellt sein sollte, dann wäre das der erste mir bekannte Fall, in dem die CBOX damit umgehen kann.

[Nervenarzt]

Hallo !
Ich habe mich bisher noch gar nicht um irgendeine Umstellung gekümmert, habe aber (glücklicherweise) die SMC-B im Juni und meinen HBA im Dezember erneuern müssen, so dass diese jetzt ECC-fähig sein sollten.
In der KoCoBox steht unter Verwaltung / Cientsysteme folgendes:
- im mittleren Feld ("Überschrift": Button mit "Zertifikat für Authentisierung Clientsystem hinzufügen") wird bei "authenticator" RSA-2048 angegeben, und bei "TUrboMed" ECC 256.
- im unteren Feld ("Überschrift": Button mit "Zertifikat für Authentisierung Konnektor hinzufügen") stehen zwei EInträge, einmal RSA-2048, was als aktiv gekennzeichnet ist, und einem ECC-256.
Aktuell läuft - soweit ich das beurteilen kann - alles: eAU, eRP, KIM.

Muss ich eine Umstellung machen (also z.B. ECC aktiv schalten ?) Oder einfach gar nichts machen ?

[FortiSecond]

In der KoCoBox steht unter Verwaltung / Cientsysteme folgendes:
- im mittleren Feld ("Überschrift": Button mit "Zertifikat für Authentisierung Clientsystem hinzufügen") wird bei "authenticator" RSA-2048 angegeben, und bei "TUrboMed" ECC 256.
- im unteren Feld ("Überschrift": Button mit "Zertifikat für Authentisierung Konnektor hinzufügen") stehen zwei EInträge, einmal RSA-2048, was als aktiv gekennzeichnet ist, und einem ECC-256.
Aktuell läuft - soweit ich das beurteilen kann - alles: eAU, eRP, KIM.

Muss ich eine Umstellung machen (also z.B. ECC aktiv schalten ?) Oder einfach gar nichts machen ?

Aktuell würde ich das zweite Zertifikat (für Auth. Konnektor) nicht auf ECC umstellen: Ich kenne keine kugelsichere Anleitung, die CBOX (ePA) unter TURBOMED in dieser Konstellation funktionsfähig zu betreiben. Gesehen habe ich EINE solche Konstellation, aber es ist nicht klar, warum das dort funktioniert. Eingestellt habe ich es selbst, aber 1:1 wie bei allen anderen Praxen (bei denen ich dann zurückdrehen musste auf "alles ECC außer die Konnektorauth der Kocobox").

[Lazarus]

Ich muss noch mal nachfragen:
nach dem Update auf 26.1.1 heute kann ich keine e-Rezepte mehr ausstellen. Es kommt die rückmeldung "the requests Message was incorrectly structured" auf allen Rechnern. ich habe mal von RSA auf ECC umgestellt und zurück, kein Effekt
den Konnektor habe ich auch neu gestartet.
Muss ich etwas neu registrieren?

[Lazarus]

edit: jetzt geht es wieder nach Reinstallation der IfapDB

[Olli]

Guten Abend in die Runde.

Wir haben nach den ganzen Infos hier im Forum alles beim Alten belassen und seit Mittwoch funktioniert KIM und somit auch der Versand der eAU nicht mehr. Wir haben nun sämtliche Einstellungen getestet, mit RSA, mit ECC und ohne Zertifikat aber wir bekommen es nicht zum Laufen. Hat jemand noch eine Idee für uns, wie wir das wieder hinbekommen? Im KIM Clientmodul sieht eigentlich alles ganz gut aus - jedoch scheint das CGM NachrichtenCenter keine Verbindung aufbauen zu können bzw. bleibt offline. Die Routen sehen gut aus, ich teste es auch direkt am Server.

Da wir generell froh sind, wenn das System läuft, haben wir in den vergangenen Monaten auch nichts an den Einstellungen verändert, daher kann es ja eigentlich nur an irgendeiner Problematik mit den Zertifikaten liegen, oder hat das Verhalten noch jemand seit Mittwoch?

Nachtrag: In den Zusatzdaten und Konnektoreinstellungen erhalte ich immer Fehler über falsche Credentials. Zertifikat ließ sich hinzufügen, aber scheinbar nicht aktivieren.

Viele Grüße
Olli

[Olli]

Nachtrag: Wir konnten vorhin kurzzeitig eAU versenden - keine Ahnung wieso. Aktuell geht wieder gar nicht. KIM zeigt teilweise ein merkwürdiges Verhalten. Teilweise kann ich mich nicht mit meiner Praxis-EMail in die KIM Adminoberfläche einloggen, Turbomed meldet unter PraxisDaten - Verwaltung KIM regelmäßig "Es ist ein unbekannter Fehler aufgetreten"

Mich wundert das error Log von KIM und ich habe keine Ahnung was der von mir will:

Caused by: com.cgm.ndesign.kim.gematik.api.ApiException: {"message": "Die Kombination aus Benutzernamen und Passwort ist nicht bekannt oder der Benutzer ist gesperrt."}
at com.cgm.ndesign.kim.gematik.api.ApiClient.invokeAPI(ApiClient.java:1069)
at com.cgm.ndesign.kim.gematik.api.accountmanager.EmailAccountApi.getAccountWithHttpInfo(EmailAccountApi.java:219)
at com.cgm.ndesign.kim.gematik.api.accountmanager.EmailAccountApi.getAccount(EmailAccountApi.java:155)
at com.cgm.ndesign.kim.repository.accountmanager.AccountManagerServiceImpl.callGetAccount(AccountManagerServiceImpl.kt:198)
... 86 common frames omitted
2026-01-18 17:43:43.290 [https-jsse-nio-8000-exec-7] WARN c.c.n.k.p.r.t.e.ThirdPartyControllerAdvice | sessionId=[5263137793432438053] correlationId=[aeb7bbff-2f03-4793-8a89-925d337bb389] protocol=[] user=[] - ErrorResponse(systemName=ACCOUNT_MANAGER, systemCode=3007, systemMessageDisplay=[Die angegebenen Credentials sind nicht gültig oder falsch])
com.cgm.ndesign.kim.exception.domain.LoginDomainException: Account does not exist (or password does not match) at the Account Manager

Eine Deregistrierung mit Neuregistrierung brachte leider auch keinen Erfolg.

Hat jemand noch eine Idee?

[Augendoc]

Bei mir zeigt der gesamte TI-Kram ein sehr merkwürdiges Verhalten.
eArztbriefe brauchen mal 3 Tage bis zum Versenden und/oder Empfang. Dann geht es innerhalb von 1 Sekunde. Dann wieder erst nach erneutem aktiven Versenden.
Da es zwischenzeitlich ja funktioniert, gehe ich davon aus, dass nicht ich das Problem bin/ habe, sondern der Server der TI (wo auch immer in der Welt dieser beheimatet ist) ein Problem hat.

Noch lästiger sind die vielen Lucas, Claras und Aarons, die jetzt in zunehmender Zahl in deutschen Arztpraxen den Telefondienst versehen und sehr effektiv verhindern, dass man einen Kollegen/ eine Kollegin sprechen kann.

[FortiSecond]

Eine Deregistrierung mit Neuregistrierung brachte leider auch keinen Erfolg.

Hat jemand noch eine Idee?

Mit Masterpasswort in die lokale Adminoberfläche des KIM-CM gehen (Masterpasswort inzwischen in TM in den KIM-Einstellungen sichtbar - markieren zum Kopieren, da manchmal länger als angezeigt), dann als Admin einloggen und die Zertifikate der Konnektorverbindung und des Konnektors prüfen. Danach mit der KIM-Adresse als User einloggen und dort das Zertifikat für das CM erneut erstellen.
...wäre jetzt mein erster Ansatz.

[FortiSecond]

Bei mir zeigt der gesamte TI-Kram ein sehr merkwürdiges Verhalten.
eArztbriefe brauchen mal 3 Tage bis zum Versenden und/oder Empfang. Dann geht es innerhalb von 1 Sekunde. Dann wieder erst nach erneutem aktiven Versenden.
Da es zwischenzeitlich ja funktioniert, gehe ich davon aus, dass nicht ich das Problem bin/ habe, sondern der Server der TI (wo auch immer in der Welt dieser beheimatet ist) ein Problem hat.

Noch lästiger sind die vielen Lucas, Claras und Aarons, die jetzt in zunehmender Zahl in deutschen Arztpraxen den Telefondienst versehen und sehr effektiv verhindern, dass man einen Kollegen/ eine Kollegin sprechen kann.

Senden/Empfangen: Irgendwo kann man einstellen, wie oft KIM abgerufen wird. Manchmal spinnt der Communicator im Hintergrund (Reparatur-Batch lässt grüßen). Gelegentlich ernstes Problem, das sich im error.log des KIM-CM sehen lässt: Mehrere Stationen versuchen den KIM-Abruf, und vielleicht ist es zu häufig oder eine Station mit nicht korrekten Zugangsdaten oder sowas - Zeitsperre, die sich ständig verlängert, bis mal die betreffende "Quelle" ausfällt und nur noch die "richtige" Station abruft (und dann was bekommt).

Off-topic

Telefonassis: Unverständliches Zeugs oder Wörter wie "Berater|Hilfe|Marsupilami|Waddehaddeduddeda" bewegen diese Telefonassis, die bei den meisten Anbietern zwingend vorgesehene Fallback-Funktion zu nutzen, sprich: In die Praxis durchzustellen.
Rein formal "sollte" ein KI-Assi auch dann durchstellen, wenn KEINE Spracheingabe vom Anrufer kommt. Das ist nicht gemeint wie der 112-Röchelruf, sondern ist mehr oder weniger als Teil der Barrierefreiheit zu sehen - wie bei Tastenmenüs (die ja auch nicht jeder bedienen kann bzw. nicht alle Telefone bedienen können).

[Olli]

Mit Masterpasswort in die lokale Adminoberfläche des KIM-CM gehen (Masterpasswort inzwischen in TM in den KIM-Einstellungen sichtbar - markieren zum Kopieren, da manchmal länger als angezeigt), dann als Admin einloggen und die Zertifikate der Konnektorverbindung und des Konnektors prüfen. Danach mit der KIM-Adresse als User einloggen und dort das Zertifikat für das CM erneut erstellen.
...wäre jetzt mein erster Ansatz.

Moin FortiSecond,

ich habe das nun alles durchgeführt, das ECC Zertifikat ist hinterlegt und alle möglichen Zertifikate habe ich erneuert. Und trotzdem streikt KIM.
In TM unter PraxisDaten Zusatzdaten sehe ich" Ein unbekannter Fehler ist aufgetreten"
Im eCockpit ist CGM KIM rot und der Verbindungstest sagt: Verbindung nicht möglich, ein technischer Fehler ist aufgetreten.

Und das Error Log von KIM meckert über Account does not exists oder Kombination Benutzername Passwort falsch oder gesperrt. Das verstehe ich halt nicht, wenn ich mich auf der KIM-CM lokal anmelden kann.

[Olli]

Nachtrag: Es läuft nun irgendwie, eAU und KIM. Ich habe zwar das ECC Zertifikat in der Kokobox, aber nicht als verpflichtend eingestellt. Dann in der Konnektor Konfig das Zertifikat hinterlegt und in Kim nochmals die manuelle Konfiguration leicht angepasst (Kennwort falsch eingetragen und erneut korrekt) KIM Dienste neu gestartet - Warum der Fehler plötzlich auftrat weiß ich nicht, auch kann ich nicht sagen, wieso es nun geht und was die Ursache war.

Danke für die Ideen zur Fehlersuche, wir warten dann ab ob es so bleibt oder wieder irgendetwas nicht funktioniert...