Beginn mit eRezept

[rfbdoc]

1) Unter Sonstiges ->eGK->Verwaltung der Komfortsignatur sind noch ausreichend viele Signaturen frei ?
2) Bei beendetem TM die im Forum bekannte Batch zum Beenden von Javaprozessen einmal durchlaufen lassen, danach TM einmal als Administrator neu starten und beenden, im Anschluss normaler TM Start

-ist zumindest einen Versuch wert.

Viel Erfolg

[Nervenarzt]

@rfbdoc
zu 1) ja, alle verfügbar
zu 2) das hat in der Tat funktioniert, wenigstens für zwei Test-Rezepte, die ich vorher angelegt hatte und die lokal gespeichert waren. Ich konnte die Rezepte signieren. Wenn ich dann aber neue Rezepte anlege, erscheinen verschiedene Fehlermeldungen (IP-Adresse nicht erhältlich [da geht es wohl um die KIM-Adresse], Aktivierung nicht möglich, ...) und dann dreht auch wieder die Sanduhr

[rfbdoc]

(IP-Adresse nicht erhältlich [da geht es wohl um die KIM-Adresse]

Dass es da um die Kim Adresse geht glaube ich eher nicht. Das eRP benötigt eine Statische Route, die beim ersten eRP auf einem Rechner durch Klick auf des entsprechende Symbol angelegt werden muss. Das geht eigentlich automatisch. Die Route wird lokal angelegt.

Hier die Route (wobei 192.168.9.208 die IP meiner KocoBox ist)
Netzwerkadresse Netzmaske Gatewayadresse Metrik
100.102.0.0 255.254.0.0 192.168.0.208 1
0.0.0.0 0.0.0.0 192.168.0.1 Standard

Ich habe die Route zusätzlich im Router bzw. der FritzBox angelegt, wie alle statische Routen für die TI

Das Löschen der Javaprozesse über die bekannte Batch müssen wir hier u.U. auch mal wiederholen

[DocMoritz]

@torsten2 bzw. Problem mit der Signatur .

Habe auch dieses Problem, hängt wohl damit zusammen, dass die Schreibweise des Namens bei der SMC- B Anmeldung und EHBA Anmeldung etwas differieren ( abgekürzter Vorname , den Titel mal als Dr. mal als Dr.med etc ) . Dieses Problem wird viele treffen,
Ich mache bis Dezember nichts. Evtl. muss man eine SMC- B neu bestellen, bzw. Im Arztregister den Eintrag korrigieren .
Siege hier

Code: Alles auswählen

 https://www.deutsche-apotheker-zeitung.de/news/artikel/2022/08/17/e-rezept-signatur-weicht-vom-arztnamen-ab-was-tun

Dort steht :

Anders ist das beim E-Rezept. Hier lässt sich das anhand der elektronischen Signatur genau feststellen. Das Problem dabei ist: Selbst geringfügige, oft unbeabsichtigte Abweichungen fallen auf und erfüllen theoretisch die Anforderung der AMVV nicht. So wird eine Verordnung von Dr. Max Michael Mueller, die von Dr. MAX Mueller elektronisch signiert ist, plötzlich zum Problem.

[mono22]

Bei uns folgendes Problem. Vorgang hängt bei "E Rezepte zum Signieren vorbereitet" der Kreis dreht sich. Nach 30 min Abbruch. Komfort SIgnaturen sind freigeschaltet. Selbes Problem auch bei Wiederaufruf im e Muster Center. Bin dankbar für Hinweise.

[Leidig]

Das endlose drehen der Sanduhr bei der Meldung "Die E-REzepte werden zum Signieren vorbereitet" ahbe ich auch. Nach 3-4x TM neu starten geht es dann.
Das habe ich auch in diesem Beitrag beschrieben:
viewtopic.php?t=10096

Bei mir ist allerdings der Unterschied, dass das Fenster rechts oben mit der Rezeptvorschau leer bleibt. Nach mehmaligen TM Neustart ist das Fenster dann nicht mehr leer und das Signieren klappt dann für den Rest des Tages. Das ist natürlich auch noch keine wirklich gute Lösung.

[mono22]

Vorgang hängt bei "E Rezepte zum Signieren vorbereitet" der Kreis dreht sich.

Rückmeldung der Hotline: Dieser Fehler ist bekannt. Lösung in kommenden Updates.

[DocET]

Im "eMuster-Center E-Rezept" ist das "Aktivieren" der eRezepte bei uns nicht möglich, nur "Route hinzufügen" oder "Schließen".

Ich habe mit im CMD-Windows mit "route print" geprüft, was bei "Route hinzufügen" passiert. Dann wird eine statische Route zu 100.102.0.0 255.254.0.0 <Konnektor-IP> angelegt. Danach ist "Aktivieren" freigeschaltet, endet aber mit einer Fehlermeldung.
Das ist nicht verwunderlich, da der Konnektor nicht im gleichen Subnetz ist wie die Praxis-PCs, womit die von TurboMed generierte Route niemals funktioniert.

Mit cmd -> tracert kann ich prüfen, dass von den Praxis-PCs die 100.102.0.0 über unseren Konnektor geroutet wird. Allerdings antwortet diese 100.102.0.0 auf den tracert nicht, womit der Befehl schlussendlich nur die Route bis einschließlich dem Konnektor anzeigt.

eAU und KIM funktionieren einwandfrei. Nur hier habe habe ich keine Idee mehr.

Danke für Ihre Rückmeldung, viele Grüße von DocET

[torsten2]

Da ist mir auch einiges nicht ganz klar
1. Läßt sich der Konnektor denn anpingen? Aus dem LAN antwortet er ja immerhin... Wenn das nicht geht, haben wir das Problem.
2. Ist denn die im Client eingetragene IP des Konnektors richtig? Dann wäre ja der Eintrag an sich nicht falsch. Es fehlt aber noch eine Route, über welches Gateway das dahinterliegende Netzwerk erreicht werden kann. Sonst kann aber auch überhaupt gar kein Gerät dort funktionieren, falls die Kartenleser auch dort stehen. Da die normalerweise nur mit dem Konnektor reden, fällt es nicht weiter auf.
3. Wie werden die beiden LAN's verbunden, einfaches Routing oder NAT? Wenn man den Konnektor isolieren will, müßte es ein NAT sein. Da kann es auch an der Addresstranslation liegen. Beim einfachen Routing muss das Praxisnetz im Konnektor eingetragen werden, sonst findet die Antwort nicht zurück. Den Konnektor kann man über die Webseite auch Ziele pingen lassen, da kann man herausfinden, bei welchem Hop es hakt. Ansonsten würde sich der Aufwand, die Netze zu trennen, nur lohnen, wenn man Ordnung haben will oder die 253 IP's nicht reichen.

Fragen über Fragen. Ich glaube, wir brauchen mehr Details.

[DocET]

Da greife ich gern auf Ihr Bild zurück, dem unser Praxisnetzwerk nachempfunden ist (wobei die Verbindung der Firewall rechts unten zur Fritzbox nur für Windows-Defender freigeschaltet ist). Ich verwende daher jetzt die dem Bild entsprechenden Bezeichnungen:

• Im LAN sind die Praxis-PC und der TurboMed-Server. Von denen aus kann die Kocobox in der DMZ angepingt werden.
• Die Firewall trennt LAN und DMZ als NAT. Sie routet auch die 100.102.0.0/15 aus dem Praxis-LAN statisch auf die IP der Kocobox. Weiterhin leitet sie sämtliche DNS-Anfragen mit "telematik" im String an die Kocobox.

Die automatisch von der CGM im Praxis-LAN erstellte Route lautet 100.102.0.0 MASK 255.254.0.0 IP_Kocobox_DMZ. Das angegebene Gateway "IP_Kocobox_DMZ" liegt außerhalb des Praxis-LANs, womit die Route nicht funktioniert. Die statische Route vom Praxis-LAN zur 100.102.0.0/15 war unabhängig vom eRezept davor schon für die Einrichtung von KIM (und dessen Betrieb) und eAU notwendig, wo ja ebenfalls die 100.102.0.0/15 aus dem Praxis-LAN erreicht werden muss.

Ich hoffe, das Anliegen so deutlich klarer formuliert zu haben und freue mich auf Ihr Feedback.

Viele Grüße von DocET.

[torsten2]

Die falsche Route kann nicht funktionieren. Dann würde ich die löschen und richtig neu anlegen. Es macht ja nichts, wenn der Client die Pakete gleich richtig wegschickt und nicht über den Default Router. Wenn TM das so haben will. Ich denke, sie werden nur überprüfen, ob eine statische Route da ist, aber nicht alle Parameter...

[DocET]

Die korrekte Route wäre ja meiner Meinung nach vom Praxis-LAN auf die Firewall (und diese kennt ja die statische Route zur 100.102.0.0/15).
Also habe ich versucht:

• Falsche automatische Route der CGM gelöscht.
• route ADD 100.102.0.0 MASK 255.254.0.0 IP_Firewall_aus_Praxis_LAN

Diese neu gesetzte statische Route geht auf damit auf das Standard-Gateway des Praxis-LANs (was inhaltlich keinen Sinn ergibt). Diese Route akzeptiert aber das eMuster-Center -> eRezept nicht. Scheinbar parsen die den string und finden die IP-Konnektor_DMZ darin nicht.

Ratlose Grüße von DocET

[torsten2]

Dann geht das tatsächlich nicht. Da es in großen Netzen (Krankenhäuser, MVZ) immer so sein wird, muß CGM irgendwo einen Schalter eingebaut haben, um die Abfrage zu überspringen. Da kann ich aber auch nicht weiterhelfen.

[DocET]

Besten Dank für Ihr Feedback, dann habe ich zumindest nichts grundsätzlich übersehen.

Hat denn jemand von Ihnen einen guten bzw. kurzen Draht zur CGM? Dieses Routen-Problem (was ja beim KIM-Einrichtungsassistent ebenfalls, dort aber lösbar auftritt), hatte ich bereits TurboMed Berlin geschildert. An der TurboMed-Software gibt's trotzdem seit über einem Jahr keine diesbezügliche Änderung.

Da mir hier kein Work-Around einfällt, verhindert dieser Bug aber die Nutzung des eRezepts.

Für jede Idee dankbar, viele Grüße von DocET.

[joerg16]

Einfach die falsch gesetzte Route von Turbomed drin lassen und die richtige Route mit einer höhren Priorität anlegen. Villeicht hilft das

[DocET]

Verstehe ich richtig?

• CGM-Route 100.102.0.0 255.254.0.0 IP-Konnector_DMZ auf hohe Metrik z.B. 30 setzen (damit diese nicht benutzt wird, aber zum Parsen für das eMuster-Center noch exisitiert)
• korrekte Route 100.102.0.0 255.254.0.0 IP-Firewall_Praxis-LAN als Metrik 1 -> entspricht zwar dem Standard-Gateway, überschreibt dann aber die obige disfunktionale Route

War das so gemeint bzw. könnte das so funktionieren?

Danke für eine Rückmeldung, viele Grüße von DocET

[joerg16]

Ja, so war es gemeint, ob es wirklich funktioniert, zeigt nur ein Test

[DocET]

Der Test ist vermutlich nicht morgen. Ich werde gern über das Ergebnis berichten.

Besten Dank und viele Grüße von DocET.

[DocET]

Mit zwei Routen kommt man zumindest auf dem gespiegelten System ohne TI einen Schritt weiter. Im eMuster-Center wird nicht mehr die Festlegung einer neuen statischen Route angeboten bzw. gefordert.

Allerdings sind dann die Anmeldedaten zu CGM CONNECT gefragt. Ich kann mich nicht erinnern, die jemals besessen oder eingegeben zu haben. Bekommt man die auf Anfrage bei der CGM oder sind die identisch z.B. mit den KIM-Zugangsdaten?

Danke für eine kurze Rückmeldung, viele Grüße von DocET.

[rfbdoc]

Ich kann mich nicht erinnern, die jemals besessen oder eingegeben zu haben.

Das geht den meisten so. CGM CONNECT installiert sich quasi von allein. Irgendwo muss man mal einen Zugang beantragen und bekommt dann die Zugangsdaten oder diese installieren sich von selbst.
Das sind andere Daten als für KIM. CGM Connect läuft auch nicht über die KocoBox.
Ohne CGM Connect geht u.a. auch die eAU nicht.