Update 24.4.1.6333 verfügbar

[Henrik313]

Manuelle Installation ist möglich. Der Installer ist im Unterordner CGMKIM15 des TM-Updates zu finden.
viewtopic.php?f=11&t=10670

Vielen Dank!
Die Installation hatte geklappt.
Was mir gerade fehlt ist die Migration. Wenn man TM öffnet erschien die Frage, ob man migrieren möchte. Das habe ich verneint um es jetzt nachzuholen, und das kommt nun nicht mehr...

[avoelker]

das Update von TurboMed lief am Server und den Arbeitsplätzen reibungslos.
Jedoch lief beim Erststart am Server das Migrationstool zu KIM 1.5 und fragte die eHBA-PIN ab, die ich am Server (und auch mittels Remote-PIN) nicht eingeben konnte. Somit war zunächst keine saubere Migration zu KIM 1.5 erfolgt.
Entsprechend funktionierte KIM an den Clints zunächst nicht.
Ergo wieder die alte KIM-Trickkiste ausgepackt: am Server in TurboMed: Praxisdaten - Zusatzdaten - KIM - bestehende KIM-Adresse deregistriert und anschl. neu registriert mit neuem Passwort.
Zuletzt am Server unter \Programme\CGM\KIM1.5\CGM-KIM1.5.exe ausgeführt
und siehe da CGM-KIM 1.5 funzt an allen Arbeitsplätzen !
ich hoff, dass beim nächsten Serverneustart die Konfiguration erhalten bleibt - ansonsten gehe ich wieder wie oben beschrieben vor.

[SebastianG]

Hier recht interessanter Ablauf, Update am Server sehr flüssig durchgelaufen, auch Datenbankaktualisierungen ziemlich zügig gelaufen; dann Abfrage welche der 8 im System hinterlegten eHBAs denn verfügbar sind mit Auffordeurng ggf. am Kartenleser bei Aufforderung die PIN einzugeben. Am Server selber ist aber kein Lesegerät lokal verfügbar, der Kartenleser in dem mein eHBA steckte wurde nicht angesprochen und KIM ging am Ende trotzdem, eine Fehlermeldung gab es am Server auch nicht; am Server ging KIM direkt im ersten Versuch, an den Clients nach Neustart des LOKALEN Systems (nicht des Servers!), PIN Eingabe eHBA wurde nach Neustart des lokalen Systems auch nicht angefordert und es lief trotzdem.
SMCB war allerdings auch die ganze Zeit freigeschaltet und keine unserer 8 KIM Adressen hat einen eHBA hinterlegt sondern alle nur die SMCB.
eAU dann nach zweitem Start der lokalen System problemlos, zuvor Fehlermeldung schon bei Erstellung (das ist bei uns aber eigentlich nach jedem Update so, warum weis kein Mensch), KIM funktioniert bei uns lokal nach jedem Update in der Regel auch erst nach einmaligem Neustart.
eRezept Problemlos nach Update, auch BMP, die üblichen Formulare, Behandlungsfallanlage sowie KV Abrechnungen ohne ersichtliche Probleme.
Gefühlt auch alles zügiger als sonst aber kann auch darann liegen, dass statt 20 Arbeitsplätzen gerad nur einer aktiv ist...
Einen Serverneustart habe ich mich nach der ganzen Aktion sicherheitshalber nicht getraut, da warte ich erstmal den Stress am Quartalsanfang ab und schaue dann mal wie es danach aussieht...

[pmortara]

Zu den PINS:
Wenn es nur eine Praxis-KIM Adresse gibt und keine weiteren Adressen bei den Ärzten eingetragen sind, wird auch kein eHBA abgefragt. Dann muss evtl. nur die SMC-B Pin eingegeben werde, sofern die Karte noch nicht freigeschaltet ist.
Nur wenn bei den Ärzten KIM Adressen eingetragen sind, werden auch eHBAs abgefragt.

Auch ganz wichtig: Vor dem Update auf dem Server nochmal schauen, dass unten rechts in der Statusleiste das grüne Chipkarten Icon zu sehen ist. Wenn da ein rotes oder gar kein Symbol zu sehen ist, wird die Migration mit hoher Wahrscheinlichkeit schief laufen.

[dirk]

Bei mir das gleiche Problem, "Verbindung zum Konnektor (Konnektor) kann nicht hergestellt werden." ebenfalls Secunet Box, die aber über Weboberfläche erreichbar ist und keine Fehler meldet.
Hast Du schon eine Lösung gefunden?



Nachtrag: Zertifikat neu in TM einspielen hat nichts gebracht, Fehler bleibt

Nach Update auf 24.4.1 kann der Konnektor (secunet-Box, FW 5.50.4) von Turbomed
nicht mehr erreicht werden: "Verbindung zum Konnektor (Konnektor) kann nicht hergestellt werden."
Auf die Weboberfläche des Konnektors kommt man aber, auch ins KV-Safenet.
Hat jemand ähnliches bemerkt? Da darf ich mir morgen die gegenseitigen Schudzuweisungenl
anhören, na toll!

Schönen Abend
c-it

[TMUser2015]

Update 24.4.1.6333 problemlos installiert. Eine PIN (bei uns Praxisadresse über SMB-C) musste ich nicht eingeben. eRezept, eAU und KIM funktionieren.

Beim versenden einer KIM über Thunderbird muss einmal bestätigt werden, dass dem Herausgeber des Zertifikats vertraut werden kann. Dann ging es problemlos.

[Henrik313]

Ergo wieder die alte KIM-Trickkiste ausgepackt: am Server in TurboMed: Praxisdaten - Zusatzdaten - KIM - bestehende KIM-Adresse deregistriert und anschl. neu registriert mit neuem Passwort.
Zuletzt am Server unter \Programme\CGM\KIM1.5\CGM-KIM1.5.exe ausgeführt

Will ich die KIM-Adresse deregistrieren, kommt "die clientmodul datenbank ist nicht entschlüsselt".
Ich bin am verzweifeln...

[c-it]

Bei mir das gleiche Problem, "Verbindung zum Konnektor (Konnektor) kann nicht hergestellt werden." ebenfalls Secunet Box, die aber über Weboberfläche erreichbar ist und keine Fehler meldet.
Hast Du schon eine Lösung gefunden?



Nachtrag: Zertifikat neu in TM einspielen hat nichts gebracht, Fehler bleibt

Nach Update auf 24.4.1 kann der Konnektor (secunet-Box, FW 5.50.4) von Turbomed
nicht mehr erreicht werden: "Verbindung zum Konnektor (Konnektor) kann nicht hergestellt werden."
Auf die Weboberfläche des Konnektors kommt man aber, auch ins KV-Safenet.
Hat jemand ähnliches bemerkt? Da darf ich mir morgen die gegenseitigen Schudzuweisungenl
anhören, na toll!

Schönen Abend
c-it

JA
Nachdem ich erst die Fehlerprotokolle an support@secunet.com geschickt hatte und von dort
die Aussage bekommen hatte, es sei alles o.k., habe ich die Mail an den technischen Support
von Turbomed weitergeleitet: techhotline.turbomed@cgm.com und um Rückruf gebeten.
3h später erfolgte der Rückruf und das Problem ist mit RDP und Fernwartung kompetent,
freundlich und zügig gelöst worden. (Danke, muss auch mal gesagt werden!)

Fazit: Das Problem tritt bei Fremdkonnektoren auf und wird durch Tausch einer .dll-Datei
beseitigt. Außerdem habe ich während der Wartung ein neues Zertifikat mit ECC !! erstellt.
Ob das auch notwendig war, ist nicht sicher. Die dll-Datei hat es aber geklärt. Ein weiterer
Test steht noch aus, die Praxis muss erst am Montag die SMC-B-Karte freischalten.

Schönes Wochennede
c-it

Evtl. PN?

[SebastianG]

Zu den PINS:
Wenn es nur eine Praxis-KIM Adresse gibt und keine weiteren Adressen bei den Ärzten eingetragen sind, wird auch kein eHBA abgefragt. Dann muss evtl. nur die SMC-B Pin eingegeben werde, sofern die Karte noch nicht freigeschaltet ist.
Nur wenn bei den Ärzten KIM Adressen eingetragen sind, werden auch eHBAs abgefragt.

Auch ganz wichtig: Vor dem Update auf dem Server nochmal schauen, dass unten rechts in der Statusleiste das grüne Chipkarten Icon zu sehen ist. Wenn da ein rotes oder gar kein Symbol zu sehen ist, wird die Migration mit hoher Wahrscheinlichkeit schief laufen.

Das passt so nicht ganz, bei uns gibt es eine individuelle KIM Adresse für jeden Arzt die aber alle mit der SMCB verknüpft sind. Die eHBA Abfrage kommt zwar aber konnte verneint werden und es lief trotzdem, bzw in einem Fall habe ich sie bejaht und eine PIN Eingabe wurde trotzdem nicht angefordert… alles etwas merkwürdig und von CGM schlecht kommuniziert.

[PCI]

Schließe mich an. Alles okay bisher.

[FortiSecond]

Fazit: Das Problem tritt bei Fremdkonnektoren auf und wird durch Tausch einer .dll-Datei beseitigt.

Das kann doch nicht wahr sein...
Das zum Thema Interoperabilität.
Wer bezahlt die Technikerstunden? Ein Monat SWP geschenkt wäre für CGM ein Schnäppchen. Schließlich ist TM "so" nicht den Vorgaben entsprechend.

Und... wo gibt´s die DLL auf der Turbomed-Downloadseite?
Wenn die Hotline und die VSP die Datei haben, dann wird die doch kollegial wie immer auch auf der Downloadseite stehen, nicht wahr?

Off-topic

Erinnert mich an ALBIS und RED (mit Secunet), wo ich^[TM] dann auf dem "kurzen Dienstweg"^[TM] die ini-Dateien für ALBIS+Secunet besorgt habe. Die Stunden mit den Jungs von RED am Telefon habe ich weder vergessen noch vergütet bekommen. Hier war es aber der ALBIS-Vertriebspartner meines Vertrauens, der RED und mir den ALBIS gerettet hat. Dafür dass RED nach deren vorheriger Aussage problemlos und mehrfach mit ALBIS getestet worden war...
*scnr*

@c-it DANKE! Made my day.

[FortiSecond]

Und jetzt habe ich eine Situation, die mich ebenfalls richtig ärgert:

CGM-KIM 1.5 manuell am Mittwoch -> Alles fein, eAU raus, eArztbriefe rein... alles klasse.
TM 24.4 heute drauf, KIM-Umstellung abgelehnt -> Nix geht mehr.
TM spricht selbst bei "Anderer Anbieter" nicht mit dem Clientmodul wegen "falscher Credentials".

EDIT:
Bisher gelingt es NICHT, TM 24.4 mit diesem ansonsten laufenden Clientmodul zu verheiraten. Thunderbird arbeitet aber perfekt damit. Am Clientmodul liegt es somit nicht.


Auch neu:
- KIM in Praxisdaten/Zusatzdaten = SMC-B
- KIM in Arztdaten/Zusatzdaten = nur eHBA zur Auswahl
Ärgerlich, wenn bisher KIM in den Arztdaten war, SMC-B zur Registrierung genutzt wurde. Warum? Zugriffsrechte...

[SebastianG]

Auch neu:
- KIM in Praxisdaten/Zusatzdaten = SMC-B
- KIM in Arztdaten/Zusatzdaten = nur eHBA zur Auswahl
Ärgerlich, wenn bisher KIM in den Arztdaten war, SMC-B zur Registrierung genutzt wurde. Warum? Zugriffsrechte...

Das scheint aber nur Neueinrichtungen zu betreffen, oder? Ich hab jetzt nicht in die Praxisdaten geschaut da es ja alles lief, aber bisher war da jedem Arzt die SMCB zugeordnet und es läuft auch (habe ich für jede KIM Adresse einzeln getestet), ohne dass der entsprechende eHBA verfügbar ist.
Ich trau mich jetzt besser mal nicht in den Praxisdaten nachzuschauen sonst sagt der mir in dem Dialog nachher "ätsch SMCB geht nicht mehr du musst jetzt auf eHBA umstellen"

[pmortara]

Das passt so nicht ganz, bei uns gibt es eine individuelle KIM Adresse für jeden Arzt die aber alle mit der SMCB verknüpft sind. Die eHBA Abfrage kommt zwar aber konnte verneint werden und es lief trotzdem, bzw in einem Fall habe ich sie bejaht und eine PIN Eingabe wurde trotzdem nicht angefordert… alles etwas merkwürdig und von CGM schlecht kommuniziert.

Ob die Arzt-KIM-Adresse mit dem eHBA oder SMC-B verknüpft sind, spielt scheinbar auch keine Rolle, das hatte ich auch nicht geschrieben. Das verhalten bei Arzt-Adressen ist ziemlich merkwürdig, da stimme ich auch zu und versuche noch eine bessere Erklärung zu bekommen.

Was sicher scheint ist, dass bei einer einfachen Praxis-KIM-Adresse, ohne zusätzliche Arzt-KIM-Adressen, keine eHBA Pin Abfrage kommt!

[FortiSecond]

Bisher gelingt es NICHT, TM 24.4 mit diesem ansonsten laufenden (vorab manuell installierten) Clientmodul zu verheiraten, das mit .6269 noch perfekt funktionierte(!). Thunderbird arbeitet weiterhin damit. Am Clientmodul liegt es somit nicht.

Beide Versionen getestet (1.10 und 1.11), in TM ist weder Anbindung "Anderer KIM-Anbieter" mit CGM-KIM-CM 1.5 möglich noch Registrierung mit einem manuell installierten Clientmodul.
Inzwischen vermute ich, dass TM in dieser Konstellation den Benutzernamen verhunzt und das CM dann mault. Laut Logs scheitert Kommunikation mit dem Mailserver.

Mal sehen, wird wohl lange Nacht.
Wenn TM nicht schon mit dem eigenen Modul nicht zurechtkäme, würde ich ja glatt die betreffende Praxis mit kv.dox ausstatten, damit am Montag garantiert alles läuft. Nur... wer weiß, ob das überhaupt klappt.

Wieder ein Meisterstück. Ich hoffe ja inständig, dass ich hier einen Denkfehler mache und CGM es nicht mal wieder verdaddelt hat. Na, erstmal Junk-Food, Junk-Movie und dann weiter Junk-KIM.

[Olli]

Ich glaube es ist mal wieder kein "Drittanbieter only" Problem, auch wir mit CGM Software suchen gerade den Fehler, weil seit dem Update KIM mit SMB-C nicht mehr anspringt und auch die eAU nun nicht mehr versenden will. Aber wer weiß welche Zusammenhänge diese tolle Software hat.

Im Fehlerprotokoll von KIM1.5 steht, aber für uns nichts eindeutiges:

2024-09-27 20:52:11.956 [SpringApplicationShutdownHook] WARN c.c.n.k.d.c.ScheduledTimeSyncTaskConfiguration | sessionId=[] correlationId=[] protocol=[] user=[] - Trying to stop already stopped time sync
2024-09-27 20:52:12.001 [SpringApplicationShutdownHook] WARN c.c.n.k.r.t.KeystoreFileRepositoryWebApiTlsImpl | sessionId=[] correlationId=[] protocol=[] user=[] - retry: Old keystore could not be removed
2024-09-27 20:52:12.032 [SpringApplicationShutdownHook] WARN c.c.n.k.r.t.KeystoreFileRepositoryWebApiTlsImpl | sessionId=[] correlationId=[] protocol=[] user=[] - retry: Old keystore could not be removed
2024-09-27 20:52:12.062 [SpringApplicationShutdownHook] WARN c.c.n.k.r.t.KeystoreFileRepositoryWebApiTlsImpl | sessionId=[] correlationId=[] protocol=[] user=[] - retry: Old keystore could not be removed
2024-09-27 20:52:40.317 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Deleting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:40.321 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Deleting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:40.336 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:40.487 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:40.692 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:40.738 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:46.725 [main] WARN c.c.n.k.d.t.WebApiTlsKeystoreServiceImpl | sessionId=[] correlationId=[] protocol=[] user=[] - Created new self signed certificate for API/Web TLS connections with SHA-256 fingerprint: [C3FBxxxxxxx7A18EFE3BA633A1D60F99F64B5A6333188xxxxxxxxxxx]
2024-09-27 20:52:47.808 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:48.247 [main] ERROR c.m.c.i.w.CredManagerBackedSecureStore | sessionId=[] correlationId=[] protocol=[] user=[] - Getting secret failed. [1168] Element nicht gefunden.
2024-09-27 20:52:54.618 [main] WARN o.b.j.p.DisabledAlgorithmConstraints | sessionId=[] correlationId=[] protocol=[] user=[] - Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': include jdk.disabled.namedCurves
2024-09-27 20:52:54.620 [main] WARN o.b.j.p.DisabledAlgorithmConstraints | sessionId=[] correlationId=[] protocol=[] user=[] - Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
2024-09-27 20:52:54.620 [main] WARN o.b.j.p.DisabledAlgorithmConstraints | sessionId=[] correlationId=[] protocol=[] user=[] - Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01
2024-09-27 20:52:54.621 [main] WARN o.b.j.p.DisabledAlgorithmConstraints | sessionId=[] correlationId=[] protocol=[] user=[] - Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': include jdk.disabled.namedCurves

Warum kann ein Update nicht einfach mal funktionieren?

Edit: Hier scheint die Migration des KIM Moduls komplett schief gelaufen zu sein, ich hatte nun als Bastellösung das KIM1.5 Clientmodul komplett händisch angelegt, alle Werte manuell aus der Koco Box ausgelesen, weil selbst in Turbomed irgendwie zwar etwas hinterlegt war aber nicht korrekt übernommen wurde.

Nach Anlegen im KIM 1.5 Clientmodul sowie Ersteinrichtung dieses geht nun alles...
Warum das beim Update schief lief, keine Ahnung. Bei Fehlermeldungen zum Mailversand einfach mal C:\Program Files\CGM\KIM1.5\app\start.html prüfen, ob das Teil richtig läuft und eingerichtet ist. Ansonsten Danke @FortiSecond für die Anleitung zur Einrichtung von Kim 1.5 - half perfekt fürs händisch neu machen weil Upgrade scheiterte

Ich hoffe Du findest auch noch Deine Lösung.

[FortiSecond]

Ich kriege schubbige Augen...
Und eine Idee.

Praxis A:

ScreenShot4124.jpg

Felder Fachdienst-Adresse und Client-Modul-Adresse und Ports verdreht:

ScreenShot4125.jpg

--> KIM läuft einwandfrei mit grünem KIM im eCOCKPIT (ist "grün" hier ein Fehlerstatus?!)
--> Thunderbird ebenfalls.

Praxis B:
Sieht korrekt aus. Lief vor dem TM-Update seit Dienstag mit KIM 1.5 problemlos. Einträge sind 1:1 wie in der alten Maske (nicht ganz: Punkt hinter den Adressen gemäß Angaben im Clientmodul mit gleichem Ergebnis) plus die beiden neuen Adressen für SMTP und POP3.

ScreenShot4119.jpg

Und Log:

ScreenShot4120.jpg

--> Nix geht. Weder mit CGM KIM (auch nicht mit . hinter telematik) noch mit KV-DOX.
--> Thunderbird läuft perfekt.

Praxis C:

ScreenShot4126.jpg

--> KIM und Thunderbird ohne Fehler. Trotz "Brummkreisel". Nach MANUELLEM KIM-Update und danach TM-Update. Tsts...

Idee? Ja, erinnert sich noch jemand an die Konfiguration des alten Clientmoduls? Wenn man mit TAB durch die Felder für die Konnektorverbindung ganz am Anfang gegangen ist, waren die TAB-Sprünge teils durcheinander. Falsche Feldfolge. Designerfehler.
Was Ähnliches könnte auch auf Seiten von Turbomed passiert sein.
Wenn hier jetzt die Felder falsch beschriftet sein sollten und die Eingaben verwürfelt werden... wäre eine Erklärung.

[Henrik313]

Edit: Hier scheint die Migration des KIM Moduls komplett schief gelaufen zu sein, ich hatte nun als Bastellösung das KIM1.5 Clientmodul komplett händisch angelegt, alle Werte manuell aus der Koco Box ausgelesen, weil selbst in Turbomed irgendwie zwar etwas hinterlegt war aber nicht korrekt übernommen wurde.

Nach Anlegen im KIM 1.5 Clientmodul sowie Ersteinrichtung dieses geht nun alles...
Warum das beim Update schief lief, keine Ahnung. Bei Fehlermeldungen zum Mailversand einfach mal C:\Program Files\CGM\KIM1.5\app\start.html prüfen, ob das Teil richtig läuft und eingerichtet ist. Ansonsten Danke @FortiSecond für die Anleitung zur Einrichtung von Kim 1.5 - half perfekt fürs händisch neu machen weil Upgrade scheiterte

Wie haben Sie das komplett händisch angelegt?
Nach der hier kursierenden Anleitung für Kim 1.5-11 (oder so?)


Bei mir kam ja nach Ablehnung des Migrationstools die Frage nicht noch einmal und seitdem geht Kim nicht mehr. Auch deregistrieren geht nicht.
Ich bin jetzt soweit einen Snapshot vom Vortag einzuspielen und das Update noch einmal zu probieren. Aber dann geht 1 Tag Praxisarbeit/Patientendaten verloren.
Würde es funktionieren wenn ich jetzt die TM eigene Backupfunktion laufen lasse, dann mein Snapshot zurückspiele und dann das TM restore? Mit dem TM eigenen Backup habe ich mich noch nie befasst.

[Olli]

Wie haben Sie das komplett händisch angelegt?
Nach der hier kursierenden Anleitung für Kim 1.5-11 (oder so?)

Bei mir kam ja nach Ablehnung des Migrationstools die Frage nicht noch einmal und seitdem geht Kim nicht mehr. Auch deregistrieren geht nicht.
Ich bin jetzt soweit einen Snapshot vom Vortag einzuspielen und das Update noch einmal zu probieren. Aber dann geht 1 Tag Praxisarbeit/Patientendaten verloren.
Würde es funktionieren wenn ich jetzt die TM eigene Backupfunktion laufen lasse, dann mein Snapshot zurückspiele und dann das TM restore? Mit dem TM eigenen Backup habe ich mich noch nie befasst.

Moin,
ja, nach dem Thread hab ich gearbeitet:
viewtopic.php?t=10670
da bei uns angeblich die Migration durchgeführt wurde - zumindest laut Installation - und KIM und eAU sowie die abhägigen Dienste nicht gingen, hab ich zuerst geschaut, ob C: Programme CGM KIM1.5 vorhanden ist und der 1.5 Dienst läuft. (Unter Dienste)
Dieser lief bereits und das KIM Update war installiert. Also zuerst die Reparaturinstallation versucht (Installer aus dem TM Updatedaten)
Dies brachte kein Erfolg.
Die Migration anstarten klappte auch nicht, also im Verzeichnis gestöbert und C:\Program Files\CGM\KIM1.5\app\start.html gefunden.

Gestartet und bemerkt, dass hier NICHTS eingerichtet war, somit Admin Passwort vergeben und nach der Anleitung von FortiSecond die Daten zuerst als Admin angelegt, anschließend mich mit meiner KIM Adresse angemeldet und wenn man drauf achtet, dass die Konnektor-ID für KIM mit denen der Praxisdaten aus Turbomet übereinstimmt, dann funktioniert KIM und die abhängigen Dienste zumindest bei uns wieder.

Ob das klassisches CGM Glück war, dass es wieder geht und die Software mit uns Lotto spielte oder es einen "einfacheren" Weg gibt, weiß ich nicht. Aber bevor ich das Backup zurückspiele würde ich wegen KIM erst alles andere versuchen...
Viel Erfolg

[SebastianG]

Nur noch so eine Idee, keine Ahnung ob das eine Rolle spielt, bei uns läuft es ja trotz recht komplizierter Konstellation mit 8 KIM Adressen bei 8 Ärzten und bisher SMC-B hinterlegt. Kann die vorherige TM Version eine Rolle spielen für die Frage ob es Probleme gibt? Ich hatte mir die 24.3.2 nämlich gespart, den abgleich der Patientendaten für die Fälle wo Briefe importiert wurden habe ich händisch vorgenommen und die Briefe einfach ausgedruckt statt diese zu importieren.