Hallo,

ich schreib mal kurz 2 Erfahrungsberichte Fehlersuche eRezept an dieser Stelle auf:

Denn vielleicht sind sie auch für andere noch mit hilfreich: beide Fälle kennzeichnet, dass eRezept in den betroffenen Praxen nicht funktionierte und in beiden Fällen die jeweils kontaktierte Hotline gleich ohne überhaupt auf dem System geschaut zu haben nach Glaskugeldiagnose auf "TIStrukturelles Grundsatzprobleme (Routing, TLS- klingt ja immer gut) verwies und bevor DAS nicht geklärt sei könne man da leider leider nichts machen...usw. ... und in BEIDEN Fällen lag es letztlich am Ende an irgendeinem kleinen (!) Detail in der lokalen (!) PVS/AIS Konfig. Somit die Botschaft dieses Beitrags: sich nicht von Glaskugelferndiagnosen ins Bockshorn jagen lassen bei dem Thema;-)

Fall 1:
Arztpraxis mit PVS Medistar von CGM und CGM TI Komponenten.

Lizenz eRezept ist gekauft, aktiviert, im PVS Medistar ist bei Zustimmung Identity Provider Dienst der Haken gesetzt, Nutzerrechte auch alles richtig gesetzt, dennoch kommt eine Identity Provider Fehlermeldung

Anruf bei CGM TI Hotline:
Da wurde ganz schnell gesagt, das müsse daran liegen, dass sie kein TLS aktiviert hätten.

(Und natürlich ist bei denen TLS alles aktiv, und alle anderen Komponenten laufen damit ja auch (Kim, EPA, Signatur...).

Gelöst hat es dann am Ende ein weiterer Anruf diesmal nochmal direkt bei der Medistar hotline:

Die haben geprüft, erst auch gesagt, es müsse am Haken "Identity Prov. Nutzung zustimmung" liegen. Da der aber da war, haben die sich dann lt. Bericht meiner Kollegin remote nochmal aufgeschaltet und leider verdeckt- ich kann nicht berichten was- noch irgendwas anderes aktiviert im PVS und danach ging es plötzlich- leider wissen wir nicht was, dazu hat sich Medistar nicht geäußert.

Fall2:

Der andere Fall ist PVS Charly /Solutio in Kombination mit Kocobox:

Der Anfang der Geschichte ist auch HIER:ab #20 | RE: Kocobox Firewall blockt Anfragen von Clientsystemen) zu lesen- wir haben dann aber je tiefer die Loggings gingen es dann doch nur noch außerhalb des Forums weiter analysiert:

Kurzfassung des Falls:

eErzept Dienst ging nicht - Fehler "bei Erstellung Fehlgeschlagen" und die einzig angebotene Lösung war, dass das Routing in die Bestandsnetze geprüft und erforderlichenfalls konfiguriert werden sollte auf Konnektor weil man angeblich Drops in der Kocobox sah auf IP eRezeptFachdienste.

Das hatte der Kollege dann gemacht und ging trotzdem nicht. Nachdem ich gesehen hatte, dass ich auch Drops auf IP eRezeptFachdienste auf meiner Kocobox hatte, aber es dennoch mit eRezept/Charly bei mir lief, haben wir mit Wireshark zunächst mal gegenseitig nachgewiesen, dass IDS-Fachdienst ganz normal auch bei dem Kollegen erreicht wurde, womit auch die Glaskuegeldiagnose Hotline schonmal widerlegt war.

Wir haben das dann Anfang 2023 pvs seitig intensiv mit erweitertem Logging auseinandergenommen gehabt:

Und am Ende war es hier "nur" folgender kleiner Bug im Charly:

Folgende Fehlermeldung:
Next issue ERROR - Bundle.entry[5].resource.ofType(Organization).address[0].country - Der angegebene Wert ("DE") ist nicht im ValueSet https://fhir.kbv.de/ValueSet/KBV_VS_BASE_GemRS_Anlage_8 (https://fhir.kbv.de/ValueSet
/KBV_VS_BASE_GemRS_Anlage_8, und ein Code aus diesem Valueset ist erforderlich) (error message = Unknown code 'DE') at 1:8552

Also übersetzt: bei eRezept wird ein DE im Kassenarztstempel nicht "verdaut"- da muss ein D stehen- und Charly glättet das nicht selbst- und siehe da, wenn man im Charly NUR das DE in D dann ändert, läuft plötzlich auch eRezept.

Ärgerlich nur, dass auch hier die Hotline erstmal ohne näher zu schauen, was wirklich ist, den Kollegen gleich auf die Fährte Routing geschickt hat, und das, obwohl eigentlich bekannteweise bei Routingproblemen eREzept Charly ein zugehörige FEhlermeldung sogar auswirft.
Außerdem: In der Datenbank eRezept bei Charly gibt es sogar im table precription eine Spalte "Last state before error" , wo man sehr genau sehen kann, an welcher Stelle es hängt - und hätte man da gleich geschaut, hätte man sehen können, dass es bei diesem Fall eben nicht am Routing lag, sondern dass der Fehler danach auftrat: denn last statt before error war : FACHDIENST IDS RECIEVED