Update 24.4.1.6333 verfügbar

[Evelin]

So..hier mal meine Erfahrung mit dem Update.
Download gelang erst beim 4. Versuch. Zuvor wg. "Netzwerkfehler" 3 x Abbruch des Downloads.
Wohl Überlastung der Server. War zuerst beunruhigt ob der Fehler vielleicht irgendwo in meinem Internetzugang o.ä. zu suchen sei.

Dann Start der Installation.
Der Heilberufausweis war im Kartenleser am Server gesteckt.
Die SMCB Karte am 1. Clienten Kartenleser fest eingesetzt.

Lief alles recht flüssig. Musste einmal am Server PC Kartenleser
die Zugangsnummer eingeben.
Dann Aktualisierung von Medilisten ...und Neustart.
Dann die Installation auf den 2 Clients.

Die Versionsnummer ist aktualisiert. Proberezepte und eAu s über Stefanie Musterfrau (heisst glaube ich so) probiert.
Scheint zu klappen.

Auffallend aber ist, dass beim Starten von TM auf den Clients der Balken ab dem Bereich ifap sehr lange verweilt.

Insgesamt ging die Installation fast schon zu "glatt".
Ich hoffe dass nach dem Quartalswechsel wirklich alles funktioniert.

Jetzt meine Frage:
Wo sehe ich, dass die aktualisierte KIM Version wirklich
installiert ist...?

Grüsse

Evelin

[pmortara]

Zu der Idee mit dem Snapshot, unter Vorbehalt:
Das wird wohl nicht funktionieren, da die KIM Credentials mit hoher Wahrscheinlichkeit in der Datenbank gespeichert werden und somit mit auch mit dem Backup übertragen werden. Man könnte es allerdings mit dem BDT Export des Hausbesuchsmoduls versuchen, aber dann fehlen u.U. Termine und andere Dinge nicht in den BDT wandern. Wenn weitere Snapshots des Servers gemacht werden können, kann man das aber ja alles mal relativ gefahrlosversuchen ....

Die KIM Migration startet nicht, wenn in den Grundeinstellungen der Schalter 'Station mit dem Konnektor verbinden' auf Nein steht und wenn im manuell installierten Clientmodul schon ein Masterpasswort festgelegt wurde.

Nach unseren Erkenntnissen spielt die vorher installierte TM Version keine Rolle.

Ich weiß, dass viele hier das nicht gerne hören werden, aber ich glaube für die meisten Problemfälle hier ist ein Anruf am Montag beim VSP die schnellste und einfachste Lösung!

[pmortara]

Eine kleine Ergänzung: Die Migration muss am Server bzw. dort wo das alten Client-Modul installiert ist durchgeführt werden! Es gab Fälle wo aus verschiedenen Gründen (ein paar habe ich weiter oben genannt) die Migration nicht auf dem Server angeboten wurde, sondern auf dem ersten Client der gestartet wurde. Das führte dann in Folge auch zu einem nicht funktionierendem KIM Modul.

[FortiSecond]

Aufgrund der hohen Komplexität in Verbindung mit Risiken durch Anwendereingriff wird der Anruf bei der Hotline der letzte und vermutlich nervenschonendste Weg sein. Tut mir leid für die Hotliner[Innen], das mal wieder ausbaden zu dürfen.

Es können nicht alle Konstellationen berücksichtigt werden, und das hat halt Kollateralschäden zur Folge. Produkthaftung bei Software ist leider ein Stiefkind der Legislative.
Im Wesentlichen betreffen die hier besprochenen Problemfälle verschiedenste Konstellationen von "serienmäßig durch VSP" bis "Admin-Frickelei-Installation".
Allein, es gibt keinen Plan B, keine Umgehungslösung, kein Fallback und keine Rettungsanleitung zur Selbsthilfe am Wochenende vor dem Quartalswechsel. Ebenso enthält TM in der Hilfe noch die alten KIM-Dialoge.

So, das war jetzt die diplomatische Aussage dazu.

----

Es folgt ein Rant, der einer "leichten Anspannung" zu verdanken ist:

Off-topic

Was erlauben CGM?
- KIM-Migration ohne Hauptpasswort für das Clientmodul? Nassen Hut auf? Was, wenn ich eine zweite KIM-Adresse "nur für Thunderbird" (oder ein anderes PVS etc.) nutzen will mit CGM KIM? Geht nicht mehr? Hello, wake up!

- CGM sieht KIM als gesonderten Vertrag, egal ob über TM-Bestellformular oder direkt im Webshop gekauft. Dann (ver...fi....esgnaddelt) nochmal muss es auch bedienbar sein als eigenständiges Produkt. Und es muss den Spezifikationen der gematik folgen. Beide Seiten. KIM-CM und PVS. Tut es das? Sehe ich bei TM aktuell nicht als hinreichend gegeben.

- Man zahlt für das KIM-Modul in TM die SWP. Es muss interoperabel sein. CGM KIM 1.5 mit T2med, Medical Office - guess what, es funktioniert reibungslos. Am Clientmodul liegt es also nicht.

CGM KIM 1.5 mit TM? Sehen wir ja. Anderes KIM mit TM? Ach, gerade nicht so wirklich.

TURBOMED mit irgendeinem KIM? Mit gewissem Risiko nicht nach dem Update. Also wenn es nicht gerade eine Supersuper-Vanilla-Installation ist mit einer KIM-Adresse auf SMC-B in den Praxisdaten...
Hat CGM hier zu komplex gedacht und alles dran gesetzt, solche (aus Beobachtung abgeleitet) noch seltenen exotischen "KIM-im-Arzt-mit-eHBA-registriert"-Konstellationen migrieren zu können, aber dabei so viel B0ll0cks zu fabrizieren, dass Normalfälle nicht laufen?

- Warum werden diejenigen benachteiligt, die KIM seit jeher (aus guten Gründen) als Stand-Alone laufen lassen?

- KIM 1.5 ist seit >1 Jahr bei anderen Anbietern verfügbar und reibungslos umgestellt. Warum kriegt CGM es wieder nicht auf die Reihe, rechtzeitig vor dem Stichtag (der ja nicht seit gestern bekannt ist), die funktionierende Umstellung zu ermöglichen.

- Warum ist es so leicht, KIM zu zerschießen, wenn man das Update nach Anleitung installiert?
Offenbar passte es nicht in das (Migrations-)Konzept, dass es Praxen gibt, die die KIM-Adresse beim ARZT erfasst und mit SMC-B registriert haben.

-- Viel schlimmer: Warum zerschießt die KIM-Migration die KIM-Funktionalität? Warum kann ich kein Fremdanbieter-KIM einrichten?
- Noch schlimmer: Auch bei gescheiterter Migration scheint x:\turbomed\ExtPrg\KIM weitgehend geleert zu werden (!!!!!!!)
- Am schlimmsten: Vor dem Update war es möglich, KIM-Adressen aus TM zu entfernen und neu zu erfassen. Es war möglich, aus TM heraus neu zu registrieren oder aber dies manuell durchzuführen und KIM in TM neu zu erfassen. Okay, Registrierung entfällt bei 1.5, aber diese Destruktion einer vorher laufenden Funktion ist doch ein Schlag ins Kontor.

Warum zum Geier VERKACKT CGM ES ES WIEDER UND WIEDER? VOR EINEM WOCHENENDE. VOR DEM QUARTALSWECHSEL. IN LETZTER MINUTE vor einem Stichtag, der LANGE ANGEKÜNDIGT war?
Bei TM-Installationen, die tags zuvor mit KIM 1.5 funktionierten!
WHHHHYYYYY??????

Und am Ende: Warum hat die F1-Hilfe im aktuellen TM noch die uralten Dialoge, teils mit Datumsangaben 2021?

NB: CGM KIM ist okay. 1.5 ist okay. Das Clientmodul ist funktional sehr sauber gemacht. Allein TM ist verkrüppelt. Bei ALBIS lief es vor 6 Wochen reibungslos, zumindest wo ich es im Rahmen des Updates gesehen habe - unabhängig von Stand-Alone oder automatische Migration.
Zurückhaltend wäre die Frage zu stellen, ob TM mal wieder mit halbgarer Umsetzung glänzt...

Fazit: Wenn man nicht seine Sprechzeit mit Hotline, Fernwartung und Betriebsunterbrechung verbringen will, muss man halt selbst abends oder nachts ran und hoffen, dass man es irgendwie hinkriegt. Oder dass man einen Fähigen bzw. Dummen findet, der außerhalb der Sprechzeiten helfen kann.
In beiden Fällen entsteht ein nicht unerheblicher Schaden durch Betriebsunterbrechung oder Fremdkosten oder... verschwendete Lebenszeit.

[Kasimir]

Jetzt meine Frage:
Wo sehe ich, dass die aktualisierte KIM Version wirklich
installiert ist...?

In der Dienste-Verwaltung von Windows muss der Dienst "CGM KIM 1.5 Clientmodul" drinstehen und aktiv sein.

[Evelin]

Hallo Kasimir..
.danke
.ich fahre sofort noch mal in die Praxis und schaue nach.
Danke
Evelin

[Evelin]

Noch mal an Kasimir...

Super.. CGM KIM Clientmodul 1.5 wird ausgeführt.

Lieber Kasimir...
Vielen,lieben Dank für Ihren Tipp.

Hat mir das Wochenende gerettet.

Danke

Evelin

[Alexander69berlin]

Kim Update hat auch bei mir nicht geklappt
wir sind 4 Ärzte Server Client struktur, hab server upgedatet, aber TM nicht gestratet, da server keine Pineingabe möglich ist, dann an einem Arbeitsplatz wo ich vorher noch ein Rezept mit PIN frei geschaltet hatte. Turbomed Update gestratet, frage nach KIM Update , das mit ja bestätigt und dann gleich endloses Fehler Fenster, das nicht copiert werden konnte , kam gar kiene Frage nch PIN eingabe, als hat bei mir auch nicht gekappt, Unverstandlich das nicht ein Punkt zum neu starten des KIM updtete programiert wurde, wie Überzeugt sind die Programiere von sich selbst das sie keine Fehler machen und das alles klapt???

[Henrik313]

Ich kann nur auf das verweisen: viewtopic.php?t=10670
Hat bei mir geklappt. @FortiSecond Sie sind der Allerbeste!!

[FortiSecond]

Lacher des Tages:
2024-09-28 21:54:32,205 [DEBUG] [SvJ] connector.plugins.komle.configuration.ConfigurationUtils - Created POP3 username: dr.house@tm.kim.telematik#pop3-kim.tm.kim.telematik.:8995#012345600#TurboMed#STATION-1#Station-1#Konnektor-012345600
2024-09-28 21:54:32,205 [DEBUG] [SvJ] connector.plugins.komle.configuration.ConfigurationUtils - Created SMTP username: dr.house@tm.kim.telematik#smtp-kim.tm.kim.telematik.:8465#012345600#TurboMed#STATION-1#Konnektor-012345600

Aus der aktuellen "CGM KIM Technische Dokumentation", Seite 4:

Code: Alles auswählen

Beispiel einer vollständigen POP3-Benutzername-Zeichenkette:
• ohne optionale Bestandteile:
erik.mustermann@tm.kim.telematik#pop3-kim.tm.kim.telematik:995#M1#CS01#AP01
• nurUserId als optionaler Bestandteil:
erik.mustermann@tm.kim.telematik#pop3-kim.tm.kim.telematik:995#M1#CS01#AP01#UID01
• keine UserId jedoch die KonnektorId:
erik.mustermann@tm.kim.telematik#pop3-
kim.tm.kim.telematik:995#M1#CS01#AP01#*#KonID01
• UserId und KonnektorId als optionale Bestandteile:
erik.mustermann@tm.kim.telematik#pop3-
kim.tm.kim.telematik:995#M1#CS01#AP01#UID01#KonID01
WICHTIG:
[highlight=yellow]Wird ein dedizierter Konnektor im Benutzernamen angegeben, aber keine User-ID benötigt
(da mit einer SMC-B gearbeitet wird und nicht mit einem eHBA), muss zwingend ein „*“ als
Platzhalter für die User-ID verwendet werden, da sonst das KIM-Clientmodul die Konnektor-
ID als User-ID interpretiert.[/highlight]

Und jetzt möge CGM mir bitte erklären, weshalb im POP3-Benutzernamen ausgerechnet "Station-1" als User-ID auftaucht.
Das ist der angemeldete Username (aus der TM-Anmeldung), könnte also auch "tmuser" lauten oder was Unzulässiges sein.
Und ein (für KIM) unbrauchbarer User lässt sich im TM problemlos anlegen:

ScreenShot4130.jpg

Ich glaube, das will ich im Log sehen... mal schauen...

[FortiSecond]

Okay, das war es nicht. Es taucht weiterhin Station-1 im Benutzernamen auf.

ScreenShot4131.jpg

ScreenShot4132.jpg

[FortiSecond]

...und es ist der Rechnername. Der ist Station-1, während TM, Infomodell etc. den PC als STATION-1 führen.
KIM-CM sieht ihn als Station-1.
Dann probiere ich es nun mit Umbennung des PC in Großbuchstaben.

Ob´s hilft?

[FortiSecond]

Jetzt falle ich vom Glauben ab:
Es ist nicht der Rechnername. Aber (erst) nach dem Neustart zeigt das Log den Anmeldenamen in TM als Teil des POP3-Benutzernamens.
Das übergibt TM an das Clientmodul? Soso...

Ist nicht mein Fachgebiet, aber bei sowas denke ich immer gleich an Puffer-Überlauf, Exploits mit ungültigen Zeichen und sowas. Aber daran wird man sicher gedacht haben.

Spaßeshalber:

ScreenShot4135.jpg

Und bei genauerer Betrachtung würden die ## und die Sternchen das KIM-Clientmodul anwidern:

ScreenShot4136.jpg

EDIT: Das Clientmodul weist weiterhin einfach nur den POP3-Benutzernamen zurück. Ist korrekt. Lässt sich nicht ärgern.

[FortiSecond]

GOTCHA!
*omg*
Ich glaube, ich hab´s.

ScreenShot4138.jpg

[FortiSecond]

Okay. Also... es geht zu retten, wenn KIM nicht mehr will.
Etwas unorthodox, aber es geht.
Und interessanterweise wohl auch mit einem "Fremdmodul", werde ich aber wohl morgen (Sonntag) erst testen.

Off-topic

Dass das Zusammenspiel auch mit Secunet oder RED (RISE/Secunet) ohne die weiter oben erwähnte .dll funktioniert, glaube ich nicht. Hier vermute ich, dass TM an dieser Stelle (und nur hier) das selbe Problem hat wie CGM ALBIS mit Secunet.
Kurzfassung, nur grob umschrieben: Secunet liefert bei einer Konnektorabfrage ein Antwortpaket, das anders formatiert ist als bei der Kocobox. Das ist meines Wissens zwar spezifikationskonform, aber ALBIS braucht dafür dann eine Anpassung in einer .ini-Datei. TURBOMED arbeitete bisher mit Secunet-Konnektor gut zusammen. Aber anscheinend an dieser Stelle nicht. Da hat man bei CGM vielleicht diese Besonderheit nicht mehr eingepflegt. Über Gründe könnte man mutmaßen, aber das hilft nicht weiter.

Wie auch immer: An dieser Stelle ist für heute Schluss.

Ob/wie ich die Lösung morgen (Sonntag) bereitstellen kann, muss ich noch prüfen. Ich bin mir sicher, dass alle leidgeplagten Foren-UserInnen in der Lage sind, die nötigen Schritte zu gehen und dass das Unterfangen kein besonderes Risiko darstellt. Dennoch gibt es Gründe, das hier nicht öffentlich zu machen. Mal schauen...

[dirk]

Hallo zusammen,
könnte mir bitte jemand mit der besagten DLL Datei aushelfen, sonst habe ich Montag ein völlig dysfunktionales System in meiner Praxis dank CGM... Bin gerade echt am verzweifeln... Gerne per PM

Ganz lieben Dank,
Dirk

[Leidig]

Eine kleine Ergänzung: Die Migration muss am Server bzw. dort wo das alten Client-Modul installiert ist durchgeführt werden! Es gab Fälle wo aus verschiedenen Gründen (ein paar habe ich weiter oben genannt) die Migration nicht auf dem Server angeboten wurde, sondern auf dem ersten Client der gestartet wurde. Das führte dann in Folge auch zu einem nicht funktionierendem KIM Modul.

Funktioniert die Migration dann auch, wenn am Server kein Lesegerät zur PIN Eingabe konfiguriert ist?
Evtl. vor Update KIM auf SMB-C registrieren wenn aktuell auf HBA registriert?

Viele Grüße,
SL

[PCI]

Hallo zusammen,
könnte mir bitte jemand mit der besagten DLL Datei aushelfen, sonst habe ich Montag ein völlig dysfunktionales System in meiner Praxis dank CGM... Bin gerade echt am verzweifeln... Gerne per PM

Ganz lieben Dank,
Dirk

Ich möchte mich anschließen, wir stehen auch ohne Anbindung nach dem Update.

Viele Grüße in die Runde
XK

[Randolf]

Danke, für die umfangreichen Meldungen,
wir warten erst mal ab, können mit kv.dox dieses betrübliche CGM-Chaos wohl z.Glück erst ein mal von der Seitenlinie aus betrachten. Gibt es schon Erfahrungen mit dem update unter kv.dox ??
Das werden wir erst in Angriff nehmen wenn die Situation klarer ist. Anders geht es unter TM leider nicht mehr! Wir haben uns mit der Situation arrangiert , indem wir nichts mehr überstürzen und zumeist erst mal Zeit gewinnen bis man weiß, was der aktuelle Sachstand mit den Updates ist.

[cwang]

Funktioniert die Migration dann auch, wenn am Server kein Lesegerät zur PIN Eingabe konfiguriert ist?
Evtl. vor Update KIM auf SMB-C registrieren wenn aktuell auf HBA registriert?

Ich habe gerade das Update durchgeführt. KIM ist bei uns auf SMB-C registriert, es wurde trotzdem nach PIN.CH (nicht PIN.QES) von HBA gefragt.
VG
@cwang