Hinweis aus dem gematik Implementierungsleitfaden zu Fehler 4056:
ZitatDie eGK wurde während der C2C-Authentisierung gezogen oder es liegt ein CVC-Zertifikatsfehler vor. Die eGK soll erneut eingelesen werden. Hinweis: Die eGK darf nicht vorzeitig gezogen werden.
Ich wollte eigentlich KIM via kv.dox einrichten, in der Anleitung stand: "Die Einrichtung von kv.dox ist nicht kompliziert", ich habe dann 102 Din A4 Seiten heruntergeladen und ausgedruckt. Als ich endlich herausgefunden hatte, wie die IP Adresse meines Konnektors im Rechenzentrum von Red Medical lautet, war die Hotline meines PVS Anbieters nicht mehr erreichbar. Die Angaben von kv.dox sind auch unpräzise, was das notwendige Betriebssystem ist. Die Hotline behauptet, Windows Server 2016 oder aktueller sei zwingend erforderlich, während ich von vielen Kollegen gelesen habe, dass die Installation auf Windows 10 1507 oder aktueller problemlos möglich sei. Jetzt muss ich noch herausfinden, welches Mandanten-ID, Clientsystem-ID, Arbeitsplatz-ID und User-ID als Aufruf-Kontext-Information bzw. Zugriffsparameter des SMC-B sind.
Außerdem ist noch wichtig, ob ich das KIM Clientmodul und den Mailclient auf den Server oder auf einen der Clients installieren muss.
Zu der Fehlermeldung
Das letzte Update der BNetzA-VL war nicht erfolgreich
habe ich im Administratorhandbuch KoCoBox Med+ Version 2.3 auf Seite 113 Folgendes gefunden:
Im Bereich BNetzA-VL werden die für die QES-Zertifikatsprüfung notwendigen QES-Signer- Zertifikate durch die Vertrauensliste der Bundesnetzagentur (BNetzA-VL) bereitgestellt. Dabei ist das Signer-Zertifikat der BNetzA-VL in der TSL enthalten.Analog zum Import der TSL laden Sie über den Button BNetzA-VL importieren eine BNetzA-VL manuell.
Vielleicht ist dort der Hund begraben und man müsste die BNetzA-VL nachladen. Leider habe ich kein Handbuch für den Rise Konnektor und auch keinen Zugriff auf den Konnektor, da dieser in dem Rechenzentrum von Red Medical steht.
Positiv ist: Ich kann auf KVSafeNet zugreifen, eine Notfalldatensatz auf meiner VK speichern, Impfzertifikate ausstellen und offensichtlich den Stammdatenabgleich durchführen (Meine KK hat mir bestätigt, dass an dem Tag, an dem ich testweise meine VK eingelesen hatte, ein Datenabgleich erfolgt ist).
Zitat von EdewolfRV im Beitrag #17Jetzt muss ich noch herausfinden, welches Mandanten-ID, Clientsystem-ID, Arbeitsplatz-ID und User-ID als Aufruf-Kontext-Information bzw. Zugriffsparameter des SMC-B sind.
Mandanten-ID, Clientsystem-ID und Arbeitsplatz-ID finden Sie entweder im Aufrufkontext, der in Ihrem PVS hinterlegt ist oder im Infosystem des Konnektors.
Zum Thema User-ID: Wunderschönes Thema: mehrere Stunden Telefonat in verschiedenen Hotlines im Juni/Juli hierfür verbracht:
Aussage , die ich am Ende bekommen habe: WENN PVS eine User-ID überhaupt setzt, müsste die vom PVS dann da rein. Wenn der PVS Hersteller, wie bei mir, noch nichtmal das Wort User-ID bislang gehört hat, und dazu nichts weiß, gibt es vermutlich keine User-ID: letztlich geht dann wohl irgendeine Zahl- bzw. das System setzt dann da die 1 automatisch- also bei User-ID muss hier einfach die Zahl 1 eingetragen werden. Zu gut Deutsch: Feld will befüllt werden sonst darf ma nicht weitermachen, aber wenn es keine User-ID gibt, is egal was drin steht, im zweifel die 1;-)
!! dies alles klappt so in bezug zu KIM von CGM- ob es mit kv.dox 100% vergleichbar ist, kann ich nicht sicher sagen- ich vermute aber mal , dass das änlich sein sollte an dieser Stelle
Evt. auch noch interessant:
Hier wird sich dann noch zeigen, ob wir später was mit User-ID in Bezug auf EHBA dann doch hätten anders gebraucht- und es nur noch nicht wissen, aber das wird die Zukunft zeigen.. das was bislang laufen soll läuft mit o.g. User-ID-"Definition" erstmal gut...;-)
[quote="EdewolfRV"|p269]Leider habe ich (...) keinen Zugriff auf den Konnektor, da dieser in dem Rechenzentrum von Red Medical steht.
Ist das wirklich so ? Hat RED das gesagt, dass SIe nicht auf die GUI vom Konnektor draufkommen? Also eigentlich müssten es einzurichten sein, dass Sie auch den Zugang bekommen: die GUI des Konnektors sollte sich auch über die bestehende VPN Verbindung zum Konnektor extern aufrufen lassen- damit hätten Sie komplett überblick über die gesamte Konfiguration- Frage ist jetzt noch, mit welchen Rechten Sie schauen dürfen- nur "schauen" aber nichts ändern sollte doch aber eigentlich möglich sein-allerdings weiß ich nicht, weil noch nicht probiert, ob der Konnektor einen Benutzer mit eingeschränkten REchnten einrichten lässt in dieser Form dann auch wirklich -Vollzugriff auf die Konfi vom Konnektor wird vermutlich RED nicht freigeben wollen, weil sie ja auch Fullservice vom Konnektor versprechen im Dienstleistungsverzeichnis- heißt dann aber auch, dass Sie, wenn Sie ein Problem haben mit dem KOnnektor dann immer über RED es versuchen müssen, da Sie im Ernstfall die Provider der Telematik-Dienste nicht auf Ihren Konnektor remote selbst drauflassen können...
Einfache Lösung für die aktuelle Frage: Bitten Sie RED, einen Screenshot von Ihrem Konnektor und dem Infomodell was dort eingerichtet ist, zu schicken. Und wenn die grad mal dabei sind, lassen Sie sich auch nochmal einen Screenshot von "Anbindung Clientsysteme" mitschicken- das sind die beiden wesentlichen Sachen, die Sie evt brauchen...
Zitat von EdewolfRV im Beitrag #17Außerdem ist noch wichtig, ob ich das KIM Clientmodul und den Mailclient auf den Server oder auf einen der Clients installieren muss.
Hierzu ist nach meinem bisherigen Verständnis dazu wichtig, wie Ihr Praxisverwaltungssystem das konzipiert hat- läuft alles über einen Aufrufkontext Praxisserver- oder startet der KIM Prozess von jeweils dem Client lokal , wo KIM im PVS aufgerufen wird: nach meinem bisherigen VErständnis: normal bei CGM Software soll KIM lokal auf den Clients im Netzwerk zu liegen kommen standard und bei z.B: meinem PVS Charly soll der KIM Client ausdrücklich auf den Server und NICHT auf die Clients.
Grundsätzlich besteht die Möglichkeit , statt lokal KIM auf Netzlaufwerk zu installieren, wo die einzelnen Clients drauf zugreifen können- das wäre dann eine Alternative zu "lokale Installation" lt. CGM - für Systeme wie Charly wie gesagt, wo der Traffic ohnehin zentriert serverbasiert läuft, funktioniert das glaub ich dan aber nicht, soweit ich es bislang durchschaue.
!! wenn der Aufrufkontext über den Server geht, muss der Server als Objekt im Infosystem im Konnektor angelegt sein. Anfangs wurde viel die Variante von den ZDVOs bei erstinstallation Telematik gewählt, dass sie im Infomodell nur den Rezeptions-Client eingetragen haben- hat man dann ein PVS, wo KIM serverbasiert nur läuft, dann ist man angeschmiert und muss erstmal das Info-Modell im Konnektor ändern/ergänzen- das wäre im Zweifel dann mit RED wiederum zu besprechen, die das in wenigen Minuten problemlos umsetzen können sollten
Nur eine kleine Nebeninfo: Soweit ich weiß betreibt Red medical gesharte Konnektoren, d.h. mehrere Einrichtungen teilen sich - über die Mandantentrennung - ein und denselben Konnektor (daher auch günstiger).
Der Administrationszugriff erfolgt aber immer für den gesamten Konnektor. Daher gehe ich davon aus, dass (allein schon aus Datenschutzgründen) der Kunde selbst niemals administrativ auf einen solchen gesharten Konnektor zugreifen darf. Auch nicht zum "nur lesen", denn dann würde er auch die Einstellungen der anderen Mandanten anschauen können (der Konnektor hat keine mandantenbezogene Adminfunktionen).
O.k , dann bleibt nur, dass RED die Infos telefonisch oder schriftlich mitteilen muss, wenn vom Kunden für die KIM Konfi angefragt wird, aber geht ja auch, Hauptsache man kriegt die benötigten Infos irgendwie
Hallo, Sie kommen nicht auf die gehosteten Konnektoren drauf. Das sollte aber kein Problem sein, denn alle Informationen, die benötigt werden, um KIM einzurichten (IP-Adresse, ClientID, Mandant, Arbeitsplatz-ID), sind ja bereits auch im PVS hinterlegt (in RED medical z.B. in der Arbeitsplatzverwaltung). Wenn Sie an diese Informationen nicht herankommen, dann schreiben Sie uns doch bitte eine E-Mail. Wir sehen auch alle Anrufe und rufen zurück, sobald das möglich ist.
Dass die Severity bei Info liegt, erklärt die Tatsache, dass z.B. der Stammdatenabgleich, das Ausstellen von Impfzertifikaten und der Aufruf von KVSafeNet ohne Probleme funktioniert.
Da der Konnektor geshared wird, müsste eigentlich die gleiche Meldung bei den anderen Nutzern des Konnektors auftreten.
Ich habe den TI Support der Gematik am 22. August 2021 wg. der Fragestellung angeschrieben, aber noch keine Antwort erhalten.
Ich kann und will an dem Konnektor nichts verändern, weil er ja vom Rechenzentrum gehostet wird und von kompetenten IT lern betreut wird.
Ich vermute, dass ich mit dem Problem nicht alleine bin und denke, dass bei dem Support durch die Gematik noch Luft nach oben ist, sonst wird es möglicherweise mit dem ambitionierten Terminplan etwas knapp...
Grundsätzlich finde ich dieses Forum eine gute Idee, damit man sich etwas austauschen kann und auch Tipps geben kann. :-)
2 Mitglieder finden das Top!
2 Mitglieder haben sich bedankt!
vielen Dank für das Update zum Stand der Dinge- auch wenn es für diese Frage mit Problem Update BNetzA-VL anscheinend noch bislang keine Lösung gibt weiter? Was hat denn Red M zuletzt dazu gesagt? Der Herr Wilms hat ja eigentlich selbst recht anschaulich beschrieben, und Herr Langguth ebenfalls, auf welchen Ebenen Funktionsprüfungen erfolgen sollten jetzt als nächstes- was ist dabei herausgekommen? Haben die bereits selbst bei Red M gesagt, dass Sie es an den Gematik Support schicken sollen oder haben Sie das zusätzlich gemacht? Und müsste nicht Red M auf dem gesharten Konnektor sehen können, ob die anderen, die an dem Konnektor hängen, die gleiche Fehlermeldung haben?
Und auch nochmal allgemein zu Ihrem Beitrag: Ich finde es sehr wichtig , dass solche Fälle wie Ihrer hier im Forum ausführlich exemplarisch dargestellt werden- zum einen kann man immer im Erfahrungsaustausch auch Lösungen finden oder selbst einiges für eigene Probleme dazulernen, wenn man es mitverfolgt und zum anderen stellt es halt auch die aktuelle Situation von uns als Anwendern sehr gut dar - und Ihr Fall ist hier grad Musterbeispiel dafür und mit Sicherheit aktuell kein Einzelfall einer länger bestehenden nicht gleich klärbaren Störung
noch brennt es nicht, mit allen Fristverlängerungen und Übergangsphasen ist ja QES (was vermutlich dann nicht läuft, wenn Updates BNetzA-VL nicht erfolgreich) erst für eAU nach Stand von heute ab 1.1.22 verbindlich Pflicht und eRezept frühestens auch erst ab dann - und natürlich gibt es auch immer noch den Papierweg als Alternative vorübergehend- wenn allerdings ein Problem wie Ihres sich dann anstaut und SIe in Ihrem PVS z.B: nach 2 Wochen gut bestimmt 50 AUs auf Postausgang/Signatur fehlt noch, haben - dann wäre natürlich schön, wenn das Problem zeitnäher gelöst würde als es jetzt hier der fall ist. Bleibt hier schlicht zu hoffen, dass mit steigender Erfahrung mit den Fehlermeldungen und ihren Ursachen in ein paar Monaten hier dann auch schneller und gezielter jeweils reagiert werden kann.
Und es zeigt meiner Meinung nach aber gleichzeitig bereits jetzt auch, wie wichtig es ist, dass wir uns auch je neuer TI--Anwendung IMMER in unserem IT_SIcherheitskonzept mit dem Weg B: was ist, wenn die Telematik nicht läuft, gleich von Anfang an systemtisch mit Arbeitsanweisung fürs Praxisteam mit kümmern- damit die Patientenversorgung auch im Störungsfall unvermindert verfügbar bleibt.
Gut wäre allgemein, wenn hier noch gezielter Prüf- /Test-Tools für Ebene Anwender, Sytsembetreuer usw. jetzt auch zeitnah weiterentwickelt würden- und auch Listen mit je Anwendung "typtischen Fehlerkonstellationen" und passenden Lösungsszenarien. Und vielleicht auch auf Dauer entsprechend des neuen gestuften BSI-Cybersecurity-Sicherheitsvorfallskonzeptes eine Telematik-Störfall-Ersthelfer-Hotline, die eben auch erste Ansatzpunkte gibt: wie dringend ist das, was ich da habe? abwarten? umgehend handeln? wer wird das Problem auf welcher Ebene vermutlich lösen können? Was kann ich aktuell tun bis es gelöst wird, damit die Patientenversorgung nicht beeinträchtigt ist usw.
2 Mitglieder finden das Top!
1 Mitglied hat sich bedankt!
ich habe vorhin ein Gespräch mit einem freundlichen und m.E. kompetenten Mitarbeiter der Firma Red Medical gehabt.
Er hat mir ausführlich die einzelnen Meldungen erklärt und deren Relevanz besprochen.
Info: Das letzte Update der BNetzA-Vertrauensliste war nicht erfolgreich:
Hat für mich aktuell keine Relevanz, die Updates würden automatisch erfolgen, ab und zu taucht die Meldung auf, kann durch einen Neustart des Konnektors beseitigt werden.
Warnung: Ein potentieller Missbrauch einer Kryptooperation wurde erkannt.
Erscheine im Rahmen der sukzessiven Updates wg. Einführung von KIM und der eAU, ist unbedenklich und führt für mich zu keiner funktionellen Einschränkung, kann ignoriert werden.
Fehler: Kartenterminal (.......) ist nicht verfügbar
Da der für mich zuständige Konnektor in einem Rechenzentrum bei Red Medical steht und von verschiedenen Praxis im Wechsel genutzt wird, manche Terminals aber nicht ständig im Betrieb sind, ist die Meldung für mich irrelevant und kann ignoriert werden.
Fehler: kein sicherer Kanal (VPN) zu den Sicheren Internet Services aufgebaut.
Da dies nur ein kostenpflichtiges (und von mir nicht gebuchtes) Zusatzfeature ist, welche einen sicheren Zugang ins Internet bietet, kann ich die Meldung getrost ignorieren.
Fazit:
Wenn die Gematik diese Dinge auf ihrer Homepage besser kommunizieren würde, dann könnte man viele Hotlines massiv entlasten und mancher Kollege, der vielleicht nicht so IT-affin ist, könnte ruhiger schlafen.
Die Frage ist auch, wieviele Meldungen der TI an das PVS weitergereicht werden müssen und ob man diese ggf. etwas filtern kann. Wichtig wäre auch bei jeder Meldung ein Zeitstempel (finde ich bei meinem PVS T2-Med nicht).
Nochmals vielen Dank an die Diskutanten und an den Support von Red Medical. :-)
PS.:
Morgen werden ich KIM installieren, mal sehen, wie das funktioniert :-)
Mit freundlichen Grüssen
2 Mitglieder finden das Top!
1 Mitglied hat sich bedankt!
Vielen Dank für die ausführliche Weitergabe der Informationen von Red Medical und auch an den Red Medical Mitarbeiter für die sehr guten Erläuterungen.
Zitat von EdewolfRV im Beitrag #24 Fazit: Wenn die Gematik diese Dinge auf ihrer Homepage besser kommunizieren würde, dann könnte man viele Hotlines massiv entlasten und mancher Kollege, der vielleicht nicht so IT-affin ist, könnte ruhiger schlafen.
Genau, so sehe ich das auch- und es ist einfach auch wichtig, gerade jetzt möglichst umfangreiche gute Sammlungen typischer Fehlerbilder zu machen in der kollektiven Erprobungphase der Telematik und die auch umfänglich untereinander zu teilen - daraus könnten dann z.B: spezifische FAQ-Listen werden, die man erstmal lesen kann, bevor man die Hotlines kontaktiert...
Speziell zu
Zitat von EdewolfRV im Beitrag #24Das letzte Update der BNetzA-Vertrauensliste war nicht erfolgreich:
kann ich noch inzwischen weitere eigene Erfahrung beisteuern, die sich mit dem , was Sie schreiben bzw. Red Medical gesagt hat, auch noch einmal bestätigt:
Kleine Fallvignette Telematik: Datum 31.8. 21 ca. 13.30h: Es war mal wieder Dienstag mittag- und die Zeit, wo regelmäßig wenn , dann zu dieser Zeit, Verbindungsstörungen auf die Telematikserver bei uns auftreten.Warum weiß ich bis heute nicht, aber Dienstag so gegen 13-14h geht es i.d.R. dann los, wenn es losgeht und 2h ist der Spuk vorüber, obwohl doch eiiigentlich nicht während der Arbeitszeit an den Telematikservern gearbeitet werden soll?!?.. ok, aber das ist anderes Thema..oder hat vielleicht noch wieder andere Ursache:
Jedenfalls: .
In diesem Zusammenhang konnte ich durch Zufall an diesem 31.8. weil ich wegen was anderem grad die GUI vom Konnktor offen hatte, zuschauen, wie auch bei mir diese Meldung von Ihnen mit BNetzA-VL nicht erfolgreich kam - und zwar kam die genau zeitgleich, als auch vorn das Jammern losging, man könne grad keine Karten einlesen...und VPN Error- passt also alles zusammen:
Und seither (!) steht diese Meldung vom 31.8. auch bei mir konstant an, obwohl längst danach - weil passiert ja default alle 24h- die BNetA-VLs wieder aktulisiert wurden erfolgreich- und vermutlich löscht ein Neustart (hab ich noch nicht drauf geachtet, wird aber denke ich so sein) dann jeweils die Bestandslogs und ersetzt sie durch aktuelle neue Logs. ...
huh... "gesharte Konnektoren".. da krieg ich Pickel... Das sind Nutzer, die sich vom CCC das Firmwareupdate auf die KoCoBox laden lassen, damit sie das Geld an den Hersteller sparen können und wundern sich dann, das sei dem größten deutschen Bot-Netz angehören.. Wenn ich lese, dass jemand Kartenterminals von ORGA mit einer 3.7.4 einsetzt und es zu dem Zeitpunkt die 3.8.0 gibt... dann hat die Praxis, der Praxisbetreuer und der Konnektorbetreuer zusammen in einem Bett geschlafen! Glück gehabt, dass Orga einen guten Support hat, der gleich die richtige Frage gestellt hat
Es gibt da noch ein paar andere Dateien, die habe ich in 4 Jahren TI-Support aber noch nicht benötigt... diese 3 Dateein (die tsl.xml oder die ecc-RSA ist hier Hardwarebezogen) nach dieser Reihenfolge einspielen und die Konnektoren gehen ohne zu zucken wieder ans Werk.
Der Fehler 4058, der weiter oben genannt wurde heisst einfach nur, dass die Datei für das Update nicht zur Verfügung steht. Das kann man über ein "Update mit Stick beim Orga" oder beim Cherry über die Softwareseite des Gerätes im Browser tun.
TI-Community
»
TI-Nutzung und Nutzen aus Anwendersicht
»
TI-Plattform - Hardware, Zugang, Einrichtung
»
Das letzte Update der BNetzA-VL war nicht erfolgreich
29.08.2021 21:55 (zuletzt bearbeitet: 29.08.2021 22:06)
Thema drucken
Antworten
