E-Rezept@RU

Verordnungen zu Lasten sonstiger Kostenträger ermöglichen

PVS/ZPVS/KIS,
AVS
ARZ

Zugriff für Betriebsstätte Vorsorge- und Rehabilitation

Aktuell können Ärzte und Zahnärzte E-Rezepte ausstellen, welche in einer Arztpraxis, Zahnarztpraxis, Psychotherapie oder Krankenhaus arbeiten. Es soll auch Ärzten und Zahnärzten die Möglichkeit gegeben werden E-Rezepte auszustellen, die in einer Betriebsstätte Vorsorge- und Rehabilitation arbeiten.
Mit dieser Anpassung kann mit einer SMC-B mit oid_institution-vorsorge-reha in der Rolle Verordnender auf den E-Rezept-Fachdienst zugegriffen werden.
Hinweis: Beim Einstellen eines E-Rezeptes prüft der E-Rezept-Fachdienst die QES und stellt sicher, dass die QES mit dem HBA eines Arztes oder Zahnarztes erstellt wurde.

Abweisen ungesliceter Extensions

Gemäß dem FHIR-Standard können beliebig viele Extensions an jeder Stelle eines Datensatzes hinzugefügt werden, ohne die Validität des Datensatzes zu beeinträchtigen. Die FHIR-Spezifikation erlaubt es FHIR-Servern jedoch auch, nicht definierte oder unbekannte Extensions abzulehnen oder zu verwerfen. Im Kontext des E-Rezepts ist es nicht vorgesehen, eigenständig vom Clientsystemen erstellte Extensions zuzulassen.
Der E-Rezept-Fachdienst akzeptiert nur Datensätze, deren Extensions auch im Profil definiert sind.
Diese Prüfung wird bereits für den Verordnungsdatensatz angewendet und wird auf alle Endpunkte des E-Rezept-Fachdienst erweitert.

E-Rezept-Fachdienst: Kein Löschen von Communications bei $close

Derzeit werden alle auf dem E-Rezept-Fachdienst gespeicherten Nachrichten zwischen Versicherten und Apotheke zu einem E-Rezept gelöscht, sobald eine Apotheke den Workflow zu einem E-Rezept abschliesst ($close-Operation). Dies führt in de Praxis zu Problemen bei der Nachvollziehbarkeit und dem Informationsfluss für die Versicherten.
Daher sollen die Communication-Ressourcen nicht mehr bei der Ausführung der $close-Operation, sondern erst zusammen mit dem Task (Löschfrist 100 Tage nach Statuswechsel zu "complete") im E-Rezept-Fachdienst gelöscht werden.
Kein Änderungsbedarf für AVS oder FdV.

Validierung von Referenzen in Bundles: FHIR verwendet in Bundles fullUrls. Diese stellen einen Identifier innerhalb des Bundles dar, wonach die angegeben Einträge gefunden werden können. FHIR sieht hierzu verschiedene Schemata vor, um Referenzen anzugeben:

• https, Bsp: https://pvs.praxis.local/fhir/Patient/1
• urn:uid, Bsp: urn:uuid:3ed97133-679f-4674-afd7-e3dc9a3389ec
• urn:oid, Bsp: urn:oid:1.3.6.1.4.1.343

Die Verwendung von urn:oid nicht mehr zulässig ist.

Der E-Rezept-Fachdienst führt bei übermittelten Ressourcen folgende Prüfungen durch:

• Format fullUrl‘s
• Vergleich der ID's von fullUrl und Ressource
• Vermischung von URN und URL Referenzierung
• Ressourcen ohne .id

Ab dem 01.04.2026 wird der E-Rezept-Fachdienst die Prüfungen forcieren. Fehlerhaft übermittelte Ressoucen werden mit einer Fehlermeldung abgewiesen. Aufgrund der Stichtagsaktivierung wird ein Feature Toggle benötigt.

DiGA: Unterstützung "Recovery Secret" und "Quittung erneut abrufen" für KTR-Clientsysteme

Der Anwendungsfälle "E-Rezept erneut abrufen" (Recovery secret) kann auch durch Kostenträger durchgeführt werden, wenn der Response der $accept Operation nicht erfolgreich verarbeitet werden konnte. Der Anwendungsfälle "Quittung erneut abrufen" kann auch durch Kostenträger durchgeführt werden, wenn der Response der $close Operation nicht erfolgreich verarbeitet werden konnte.

DiGA Communication bei $reject

Wenn eine DiGA-Verordnung einem Kostenträger zugewiesen wird und die Prüfung des Kostenträgers ergibt, dass das E-Rezept an den Versicherten zurückgegeben werden muss, ruft der Kostenträger die $reject-Operation am E-Rezept-Fachdienst auf.​ Weiterhin ist definiert worden, dass der Kostenträger über Senden einer GEM_ERP_PR_Communication_Reply dem Versicherten mitteilt, warum die Verordnung zurückgegeben wurde. Dieses Profil verlang am E-Rezept-Fachdienst die Verwendung eines JSON für Apotheken in .payload.contentString.​ Um diese Abhängigkeit aufzulösen, wurde ein neues Profil GEM_ERP_PR_Communication_DiGA entwickelt, was diese Anforderung nicht trägt.​

Beziehen einer OCSP-Response bei Signaturüberprüfung

Datum der Einreichung der Zustimmung setzen

zzgl. Fehlerbehebungen:

• Exponentiell Backoff zum Information Service wirkt nicht wie erwartet - B_FD-1281 (ERP-28254)

• A_27131 Zugriffsberechtigungen werden beim Entziehen des EU-Consent nicht gelöscht - B_FD-1434 (ERP-30578)

• GET /MedicationDispense gemischt mit EU-Medication-Dispense liefert nicht die referenzierten Objekte - B_FD-1349 (ERP-30124)

 Detektion von Nutzungsanomalien im E-Rezept-Fachdienst 

Aktualisierung von Komponenten mit neueren Bibliotheken

ePA Operation Outcome Code in BDEv2 aufnehmen (eML)

Umgang mit Datums- und Zeitangaben ohne Zeitzoneninformation

In der API der Anwendung E-Rezept und den zugehörigen Clientsystemen treten häufig Datums- und Zeitangaben ohne explizite Zeitzoneninformation auf, wie "2025-10-01" oder "2025-10-01T12:00:00". Das Fehlen einer Zeitzonenkennzeichnung kann zu unterschiedlichen Interpretationen und Verarbeitungsergebnissen führen.
Es wird festgelegt, dass bei fehlender Zeitzoneninformation implizit die deutsche Zeit (CET/CEST) angenommen wird.

Es wird in Task.performerType die Angabe des Coding.system korrigiert. Anpassungsbedarf besteht nur für Clientsysteme, die Task.performerType auswerten.

Fehlerbehebung zu

• C_12125 Datum der Einreichung der Zustimmung setzen