VonDoczuDoc.de

mhh hat geschrieben: ↑Montag 23. März 2026, 07:47 - Noch eine Frage: was bedeutet das jetzt für die Installation wenn KIM 1.5 abgebrochen wird.

- Ich habe Telekonnekt als Anbieter, auf dem neuesten Stand mit dem TK-Gateway. TurboMed hat 2 1/2 Monate gebraucht bis die Experten von TM ihre Software mit TK-Gateway zum laufen gebracht haben und jetzt beginnt das Spiel wohl on vorne. Es lebe der Drucker und das FAX!

- Abbruch des KIM-Updates hat hier keinen Schaden angerichtet. Der Installer wartet auf irgendwas (vermutlich wird durch die "silent installation" ein Dialogfeld nicht angezeigt oder der Dienst nicht gestoppt oder sowas). In den mir bekannten Fällen hat der Installer nichts am laufenden KIM verändert.
- Es klappt übrigens problemlos, nachträglich aus dem KIM-Ordner des entpackten TM-Updates manuell KIM upzudaten. Das ist nur aber dann erforderlich, wenn auf dem PC noch KIM 1.5 älter als (nicht lachen) 1.20 vorliegt. Das manuelle Update läuft dann sauber durch. Klassisches WTFCGM halt.

- Fremdkonnektor bzw. Fremd-TI ist immer wieder ein Thema, auch wenn die Spezifikation die Interoperabilität einfordert und es funktionieren muss. Bei ALBIS braucht es für einen Secunet-Konnektor nur Einträge in einer ini-Datei, bei TM soll es eine ganze .dll-Datei sein, die man vom Support bekommt (wurde hier jedenfalls irgendwo beschrieben im Rahmen eines Updateproblems 2025).
Wenn das Problem wieder auftauchen sollte nach Update (weil die spezielle DLL überschrieben wurde oder sowas), ist das ärgerlich, ja.
Hoffen wir das beste. :=)

Jetzt läuft alles, nach Abbruch der Installationsprozesse KIM 1.5 und eGesundheit.

Ich denke CGM ist gefordert hier eine saubere Installationsdatei zur Verfügung zu stellen. Das Problem kostenpflichtig auf die User abzuwälzen ist unverschämt. Das war der Vorschlag der TM-Helpline.

Übrigens: KIM 1.5 ist installiert und läuft derzeit problemlos, ob das aber auch nach dem 1.4. noch gilt, weiß ich nicht, dann mache ich es wie FortiSecond beschrieben hat: Installation von KIM aus der entpackten Installationsroutine heraus.

Guten Abend,

unser Update schlug fehl. KIM …. Auch die Lösung mit KIM separat zu installieren schlug fehl.

Heute Morgen an der Hotline war kein generelles Problem bekannt. Im Laufe des Tages stellte sich heraus: es betrifft doch einige Praxen.

Aufgrund des zeitlichen kurzen Zeitraums haben wir nun direkt einen Termin eines TM Technikers, der VSP wird umgangen. Eine „saubere Lösung“ dauert 1,5-2h…. Offensichtlich ist die Zeit zu knapp eine Updaterevision durchzuführen…

Positiv TM hat einen trouble Support kurzfristig ermöglicht. Negativ die Hotline wusste von keinem Problem.

Negativ Termin sollte initial kostenpflichtig sein, aber nur kurz nach einem weiteren Anruf…

DC19 hat geschrieben: ↑Montag 23. März 2026, 18:40 Guten Abend,

unser Update schlug fehl. KIM …. Auch die Lösung mit KIM separat zu installieren schlug fehl.
Heute Morgen an der Hotline war kein generelles Problem bekannt. Im Laufe des Tages stellte sich heraus: es betrifft doch einige Praxen.

Läuft KIM denn noch?
Ansonsten: Nach Entpacken des Updates die Ordner KIM, eGesundheit und ggf. auch Clickdoc löschen (ich nehme gern auch Ifap raus, wenn vorhanden).
Danach sollte das Update durchlaufen. Es meckert nicht, wenn die Ordner fehlen.

Wo ist den Ifap-Ordner versteckt ?

dr.bibber hat geschrieben: ↑Montag 23. März 2026, 19:33 Wo ist den Ifap-Ordner versteckt ?

Gute Frage, die zugleich erklärt, warum IFAP mit Datenstand 15.12.25 bei einigen auftaucht...

Diesmal befindet sich kein IFAP im Installationspaket, zumindest nicht in dem, was mir vorliegt.
-> Dann KANN auch nix Neueres an IFAP installiert werden.
-> Dann muss man den Ordner nicht löschen (wie auch?).

Mir fällt´s gar nicht wirklich auf, weil meine Praxen quasi immer am 3. und am 18. des Monats das Update von der ifap-Website bekommen (im IPC nach Update suchen, dann Download und Installation). Neuere Versionen werden regelmäßig nicht überschrieben, wenn CGM mit TURBOMED mal wieder einen alten Datenstand liefert. Oder... wie diesmal anscheinend: Keinen Datenstand mitliefert.
Da lässt man solche Praxen wieder im Regen stehen, die eben nicht alle paar Wochen manuell ifap updaten. Was kümmert´s CGM -> Die dadurch wegfallende Nutzungszulässigkeit als Verordnungssoftware (>4 Wochen alter Datenstand) laut "Regelung von oben" ist ja Problem des Kunden...

Mache gerade Per Fernwartung in fünf Praxen das Update.
Alles IFAP was von früher 25.xxx TM-Update stammt, kann nicht geupdatet werden !!!
Also spiele ich gerade vom 26.1.2 das IFAP vom 22.01. in meine Praxen, denn dann geht auch das Update.
Obs mit 26.1.1 geht weiß ich nicht. Auch egal, da man das Ganze wiedermal als riesen Schweinerei bezeichnen kann..!!

horkano007 hat geschrieben: ↑Dienstag 24. März 2026, 00:13 Mache gerade Per Fernwartung in fünf Praxen das Update.
Alles IFAP was von früher 25.xxx TM-Update stammt, kann nicht geupdatet werden !!!
Also spiele ich gerade vom 26.1.2 das IFAP vom 22.01. in meine Praxen, denn dann geht auch das Update.
Obs mit 26.1.1 geht weiß ich nicht. Auch egal, da man das Ganze wiedermal als riesen Schweinerei bezeichnen kann..!!

Als Anwender (Arzt) kann man zur Not einfach nur Wirkstoffe verordnen, dann ist man aus dem Schlamassel draussen....der Apotheker hat dann die Wahl und die Verantwortung. Das ewige Updaten habe ich satt.

horkano007 hat geschrieben: ↑Dienstag 24. März 2026, 00:13 Mache gerade Per Fernwartung in fünf Praxen das Update.
Alles IFAP was von früher 25.xxx TM-Update stammt, kann nicht geupdatet werden !!!
Also spiele ich gerade vom 26.1.2 das IFAP vom 22.01. in meine Praxen, denn dann geht auch das Update.
Obs mit 26.1.1 geht weiß ich nicht. Auch egal, da man das Ganze wiedermal als riesen Schweinerei bezeichnen kann..!!

Danke für den Hinweis, ich habe aus der 26.1.2 ifap auf allen Rechnern geupdatet und dann das TM-Update 26.2.1 installiert. Lief durch.
Aber, der NetInstall-Ordner auf dem Server wurde offenbar nicht korrekt befüllt (ich nutze NetInstall nicht), beim Starten von TM bei allen Clienten kam die Meldung, dass die alte Version im NetInstall-Ordner liegt.
Habe den Ordner dann weggesichert und geleert und jetzt läuft alles.

Hallo!
Ich habe nach dem Hinweis von Horkano007 VOR dem TM Update erst mal ein IFAP Update mit einem Download über deren Webseite gemacht.
Das Update lief dann ohne Fehlermeldung durch.
ABER die ePA funktioniert mal wieder nicht mehr. Bei mir war das bei den letzten Updates mehrmals so, dass die Epa nicht mehr funktioniert hat. Es kommt folgende Fehlermeldung:
"Fehlerstatus: 502
Fehlertitel: Es ist ein VAU-Protocol Fehler in der C-Box aufgetreten
Fehlerdeteail: Mit den nötigen Services für den VAU-Login konnte nicht kommuniziert werden."
bisher konnte ich das Problem mit eniem Neustart des CGM IDP Service oder einem Neustart des Servers lösen.
Das funktioniert heute leider nicht.

Viele Grüße,
SL

Leidig hat geschrieben: ↑Dienstag 24. März 2026, 22:20 Hallo!
Ich habe nach dem Hinweis von Horkano007 VOR dem TM Update erst mal ein IFAP Update mit einem Download über deren Webseite gemacht.
Das Update lief dann ohne Fehlermeldung durch.
ABER die ePA funktioniert mal wieder nicht mehr. Bei mir war das bei den letzten Updates mehrmals so, dass die Epa nicht mehr funktioniert hat. Es kommt folgende Fehlermeldung:
"Fehlerstatus: 502
Fehlertitel: Es ist ein VAU-Protocol Fehler in der C-Box aufgetreten
Fehlerdeteail: Mit den nötigen Services für den VAU-Login konnte nicht kommuniziert werden."
bisher konnte ich das Problem mit eniem Neustart des CGM IDP Service oder einem Neustart des Servers lösen.
Das funktioniert heute leider nicht.

Viele Grüße,
SL

Hallo SL,

da der normale Neustart des Servers und des Dienstes diesmal nicht geholfen hat, liegt das Problem tiefer. Meistens blockieren nach einem Update fehlerhafte Dateiberechtigungen den Dienst, sodass er zwar "startet", aber nicht voll funktionsfähig ist (daher der Fehler 502).

Gehe bitte folgende Punkte gezielt durch:

1. Ordnerberechtigungen (Ursache für Fehler 1053)
Wenn der CGM IDP Service nicht läuft oder beim manuellen Starten den "Fehler 1053" (Dienst antwortete nicht rechtzeitig) bringt, liegt das fast immer an fehlenden Rechten im Dateisystem.

Prüfe den Ordner: C:\TurboMed\ExtPrg\CGM-IDP.

Rechtsklick -> Eigenschaften -> Sicherheit.

Stelle sicher, dass der Zugriff (am besten für die Gruppe "Jeder" oder den Dienst-Nutzer) auf Vollzugriff steht. Diese Berechtigung muss zwingend für alle Unterordner übernommen werden.

2. TurboMed-Sitzung neu initialisieren
Oft läuft der Dienst nach der Rechte-Korrektur zwar wieder, aber die offene TurboMed-Sitzung "weiß" das noch nicht.

Nach dem Fix der Berechtigungen und dem Dienst-Neustart am Server muss TurboMed an den Arbeitsplätzen einmal komplett geschlossen und neu gestartet werden, um die VAU-Kommunikation zur C-Box frisch aufzubauen.

3. Analyse über Log-Dateien
Falls es danach immer noch hakt, kommen wir ohne einen Blick in die Protokolle nicht weiter. Schau bitte in folgende Verzeichnisse und prüfe die aktuellsten Einträge:

...\ExtPrg\CGM-IDP\log\

...\ExtPrg\CS.CBox.DE\logs\

Dort lässt sich meist genau ablesen, an welcher Stelle der VAU-Login scheitert.

Viele Grüße!

Leidig hat geschrieben: ↑Dienstag 24. März 2026, 22:20 Es kommt folgende Fehlermeldung:
"Fehlerstatus: 502
Fehlertitel: Es ist ein VAU-Protocol Fehler in der C-Box aufgetreten
Fehlerdeteail: Mit den nötigen Services für den VAU-Login konnte nicht kommuniziert werden."
bisher konnte ich das Problem mit eniem Neustart des CGM IDP Service oder einem Neustart des Servers lösen.
Das funktioniert heute leider nicht.

1) Läuft der IdP-Dienst?
2) SMC-B freigeschaltet? *wichtig, weil sonst keine Anmeldung an den ePA-Servern möglich*

Ansonsten... ohne Gewähr, mache ich nur aus Erinnerung ohne Live-Check:

TM beenden.
IdP-Dienst und HCS.CBOX (Dienste) beenden.

/ TurboMed / ExtPrg / HCS.CBox.DE
-> Ordner workingdata entfernen.
-> Datei baseconfiguration.json wegschieben (nicht löschen... für alle Fälle)
-> Datei jwtauthentication.json wegschieben (dito)

IdP-Dienst wieder starten
TM beenden
IdP-Dienst ggf. einrichten (also aufmachen und gleich wieder speichern)
CBOX neu einrichten.
TM beenden
CBOX-Dienst neustarten
TM starten.

Damit sollte die CBOX wieder aufgefrischt sein.


Hilfedokumente zu den Funktionen INNERHALB von TM (nicht sonderlich technisch):
https://support.cgm.com/CGM_TURBOMED/el ... P-Services
https://support.cgm.com/CGM_TURBOMED/el ... n_der_CBOX

Nachtrag: Erst den von @MediIT empfohlenen Weg prüfen!

(Und nicht über Zugriff für "Jeder" wundern - ich habe noch niemals ein TM gesehen, das auf einem Server läuft, bei dem die Rechte gemäß gebotener Sorgfalt eingerichtet sind - dann wäre "Jeder" nur mit Begründung und Unterschrift zu vergeben. Soll nicht heißen, dass ich das für unmöglich halte. Ich frage mich gerade, ob ich überhaupt mal ein CGM-PVS ohne "Jeder" gesehen habe... insbesondere solche, die von den größeren VSP/Systemhäusern aufgestellt wurden, die zugleich CGM PROTECT als unverzichtbar anbieten.)

FortiSecond hat geschrieben: ↑Mittwoch 25. März 2026, 00:10 Nachtrag: Erst den von @MediIT empfohlenen Weg prüfen!

(Und nicht über Zugriff für "Jeder" wundern - ich habe noch niemals ein TM gesehen, das auf einem Server läuft, bei dem die Rechte gemäß gebotener Sorgfalt eingerichtet sind - dann wäre "Jeder" nur mit Begründung und Unterschrift zu vergeben. Soll nicht heißen, dass ich das für unmöglich halte. Ich frage mich gerade, ob ich überhaupt mal ein CGM-PVS ohne "Jeder" gesehen habe... insbesondere solche, die von den größeren VSP/Systemhäusern aufgestellt wurden, die zugleich CGM PROTECT als unverzichtbar anbieten.)

Volle Zustimmung, die 'Jeder'-Gruppe hat in einer sauberen Struktur eigentlich nichts verloren. Wir handhaben das bei unseren Installationen aber strikter: Wir richten grundsätzlich eine Domäne ein, womit dieser pauschale Zugriff direkt hinfällig wird.

Das Problem ist oft der Altbestand, den man in vielen Praxen vorfindet. Da wurden über Jahre hinweg Berechtigungen 'passend gemacht', was heute kaum noch jemand entwirren kann. Wir setzen daher bei Neu-Installationen oder Migrationen direkt auf saubere Berechtigungen, um diesen Wildwuchs gar nicht erst fortzuführen.

Wenn es vernünftig eingerichtet ist braucht TURBOMED keine "Jeder" Berechtigung.

VIELEN DANK an MediIT und Fortisecond!!!

Nach dem Setzen von "Vollzugriff" für den Ordner C:\TurboMed\ExtPrg\CGM-IDP (und Unterorder) läuft die ePA wieder.
Die Dienste habe ich nach dem Rechte setzen auch neu gestartet, ich weiss nicht ob das nötig gewesen ist.

Viele Grüße,
SL

Guten Abend.

Wir haben nun den Zustand, dass das Update mit KIm Client durch ist. Leider funktioniert die ePA nicht, Vollzugriff besteht. Die Patientenakte öffnet sich, aber es kommt ein "unbekannter" Fehler. Immerhin kein Vault Fehler mehr...... Im Konntekot Unter ePA , Telematikdienste kommt ein Timeout... in Dauerschleife... Interessant ist das die ePA auth genau eine Stunde vor der Konnektor Zeit läuft.... statt 20 Uhr XX 19 Uhr XX

Heute Mittag vor dem Update liefen alle Funktionen....

DC19 hat geschrieben: ↑Mittwoch 25. März 2026, 20:42 Guten Abend.

Wir haben nun den Zustand, dass das Update mit KIm Client durch ist. Leider funktioniert die ePA nicht, Vollzugriff besteht. Die Patientenakte öffnet sich, aber es kommt ein "unbekannter" Fehler. Immerhin kein Vault Fehler mehr...... Im Konntekot Unter ePA , Telematikdienste kommt ein Timeout... in Dauerschleife... Interessant ist das die ePA auth genau eine Stunde vor der Konnektor Zeit läuft.... statt 20 Uhr XX 19 Uhr XX

Heute Mittag vor dem Update liefen alle Funktionen....

Das mit der Uhrzeit kann durchaus sein, wenn ein Dienst die Universalzeit loggt (Wir sind in CET Normalzeit/Winterzeit, also UTC+1).

In den Logdateien von KIM C:\Programme\CGM\KIM1.5\logs oder ähnlich (error.log) und in den Ordnern der CBOX und ggf. auch IDP nachsehen, wo es hakt.
Oh, und Timeout... das hatte ich vor kurzem auch in einer Praxis mit KIM und Kocobox (aber kein CGM-PVS). Da brauchte der Konnektor einen Neustart, und danach war alles in Butter. Warum auch immer. Vielleicht als erstes probieren?

Guten morgen. Konnektor, Serverneustar, erneute SMBC auth. ergab leider keine Veränderung. Einen richtigen Fehler lässt sich nicht auslesen.

Nebenbei geht mit dem Update die HzV Abrechnung nicht "interner Fehler" ohne weiteres..... Dieses Update ist eine Katastrophe. Kurz vor Quartalsende uns zu was aufzuerlegen..... eine Frechheit.

DC19 hat geschrieben: ↑Donnerstag 26. März 2026, 08:40 Guten morgen. Konnektor, Serverneustar, erneute SMBC auth. ergab leider keine Veränderung. Einen richtigen Fehler lässt sich nicht auslesen.

Nebenbei geht mit dem Update die HzV Abrechnung nicht "interner Fehler" ohne weiteres..... Dieses Update ist eine Katastrophe. Kurz vor Quartalsende uns zu was aufzuerlegen..... eine Frechheit.

Hallo DC19,

das klingt nach einem frustrierenden Start in den Praxisalltag, besonders so kurz vor der Abrechnung. Um dem "internen Fehler" bei der HzV und den ePA-Problemen auf den Grund zu gehen, lass uns bitte folgende Punkte prüfen:

Häufig liegt die Ursache für den "internen Fehler" in einer gestörten Kommunikation mit dem HÄVG-Modul oder abgelaufenen Schlüsseln. Bitte prüfe:

• Lässt sich das Prüfmodul über den Browser aufrufen?

http://[IP-Adresse-deines-Servers]:22220/

• Navigiere im Modul zu Zertifikate -> Liste vorhandener Zertifikate -> Aktive HOKs.

Wird dort der Online-Key korrekt und als aktiv angezeigt?
Tritt der Fehler an allen Arbeitsstationen auf oder ist nur ein spezifischer Platz betroffen?


Da die ePA-Fehlerbeschreibungen oft vage sind, benötigen wir einen Blick "unter die Haube". Schau bitte in die folgenden Verzeichnisse auf dem Server/Client:

• TurboMed\ExtPrg\HCS.CBox.DE\logs

• TurboMed\ExtPrg\CGM-IDP\log

Mein Angebot: Kopiere die aktuellsten Log-Einträge gerne in eine PN (Private Nachricht) an mich. Ich schaue mir die Fehlermeldungen im Detail an und versuche, das Problem einzugrenzen.