Geplante Releases werden an dieser Stelle aufgeführt, sobald Planungsinformationen, z.B. vorgesehene Deployment-Termine oder Inhalte (Änderungen, Fehlerbehebungen, betriebliche Anpassungen, etc.) vereinbart sind. Sind die Termine und Inhalte geplant, aber noch unbestätigt, so werden sie explizit so benannt. Legende: (U) - unbestätigt
C_12238 - E-Rezept: Umgang mit Datums- und Zeitangaben ohne Zeitzoneninformation (ARZ, AVS, FdV, KTR, PVS/ZPVS/KIS)
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.
C_12295-E-Rezept: Verordnungen zu Lasten sonstiger Kostenträger ermöglichen (ARZ, AVS, PVS/ZPVS/KIS)
Änderungen RC1:
C_12034 - E-Rezept: Zugriff für Betriebsstätte Vorsorge- und Rehabilitation (PVS/ZPVS/KIS)
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.
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.
C_12201 - E-Rezept-Fachdienst: Kein Löschen von Communications bei $close (AVS, FdV)
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.
C_12219 - E-Rezept: Validierung von Referenzen in Bundles (AVS, FdV, KTR, PVS/ZPVS/KIS)
Format fullUrl‘s: 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.
C_12211 - E-Rezept: DiGA: Unterstützung "Recovery Secret" und "Quittung erneut abrufen" für KTR-Clientsysteme (KTR)
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.
C_12129 - E-Rezept: DiGA Communication bei $reject (KTR)
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.
C_12269 - E-Rezept-Fachdienst: Beziehen einer OCSP-Response bei Signaturüberprüfung (Kein Änderungsbedarf für Clientsysteme)
C_12125 - E-Rezept-Fachdienst: Datum der Einreichung der Zustimmung setzen (Kein Änderungsbedarf für Clientsysteme)
C_12316- ePA Operation Outcome Code ins BDEv2 aufnehmen
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)
Änderungen RC2:
C_12190 - Detektion von Nutzungsanomalien im E-Rezept-Fachdienst
RU
PU
TU
RU-DEV
RC2
RC1
Mit den RC werden in der RU-DEV sukzessive bereitgestellt. Der volle Umfang der Änderungen ist in der RU-DEV erst mit dem finalen RC erreicht! Der Umfang der Änderungen pro RC wird dementsprechend links ausgewiesen.
E-Rezept Fachdienst (eRp FD): Aktuelles Release
An dieser Stelle wird das Release aufgeführt, welches sich in PU befindet.
Neue FHIR-Profile mit der Beginn Gültigkeit 01.10.2025.Mehr Informationen (ARZ, AVS, FdV, KTR, PVS/ZPVS/KIS)
Neues FHIR-Versionierungskonzept (kein Änderungsbedarf für Clientsyteme)
Durch die neuen Profilversionen besteht die Möglichkeit mehrere meta.profile Informationen anzugeben. Das soll im E-Rezept nicht genutzt werden, sondern wie bisher nur ein meta.profile angegeben werden.
Der Endpunkt bestehende PATCH /ChargeItem wird dafür genutzt, dass der Versicherte Informationen zu Abrechnungsinformationen (bspw. ob der Kostenbeleg bei der Krankenkasse eingereicht wurde) am E-Rezept-Fachdienst hinterlegen kann. Mit der Einführung der Profile zu de.gematik.erezept-patientenrechnung.r4 1.1.0 wird das neue Profil GEM_ERPCHRG_PR_PAR_Patch_ChargeItem_Input eingeführt, welches ein FHIR-Profil für den Endpunkt PATCH /ChargeItem definiert.
Anpassung im Mapping bei der Übermittlung der Daten vom E-Rezept-Fachdienst in den ePA Medication Service
C_12284 - E-Rezept: Filter für in der EU einlösbare Rezepte
C_12272 - E-Rezept-Fachdienst: EU Consent für DELETE Endpunkt
C_12136 - E-Rezept: Abfrage von Daten vom FHIR-VZD
Speichern der MedicationDispense in eu-close (ANFERP-3332 Punkt 2)
E-Rezept: Standardkonforme Darstellung des Authentifizierungsverfahren im ACCESS_TOKEN - Kein Änderungsbedarf für Clientsysteme, da der von der Änderung betroffene ACCESS_TOKEN durch die Clientsysteme durchgeleitet werden.
Mit den RC werden in der RU-DEV sukzessive bereitgestellt. Der volle Umfang der Änderungen ist in der RU-DEV erst mit dem finalen RC erreicht! Der Umfang der Änderungen pro RC wird dementsprechend links ausgewiesen.