Redaktion: Transition Management E-Rezept
👀 Abonnieren Sie die Subseiten, für die Sie sich interessieren. Diese Hauptseite dient der zusammenfassenden Darstellung und ändert sich selten.
News
- E-Rezept-Fachdienst
PoPP-Token können verarbeitet werden
- IDP-Dienst
Schlüsselwechsel Test jew. zw. 10-12 Uhr (Zertifikate)
Umgebungsstatus und -Planung
Im Folgenden sind die aktuellen und geplanten Installationsstände der Umgebungen sowie ausgewählte, wichtige Events und Aktivitäten dokumentiert. Detailinformationen zu dedizierten E-Rezept Releases finden sich in den Release Hinweisen unten.
Legende: <Produktversion> (U) - Termin ist unbestätigt
| eRp FD | eRp IDP-Dienst | |||||
| Event | RU-DEV | PU | RU | RU | PU | |
| Aktuell | 1.22.0 RC4 | 1.21.0-1 | 1.21.0-0 | 3.2.0-1 | 3.2.0-0 | |
| 1.22.0 RC2 | |||||
| 1.21.0-1 | |||||
| 1.21.0-1 | |||||
| 1.22.0 RC3 |
| ||||
| 1.22.0 RC4 |
| ||||
| 1.22.0 | |||||
| 1.22.0 | |||||
FHIR Versionierung 🔗
| PU | |
| |
| RU | |
| RU Dev | |
| |
kbv.erp_1.1.2
kbv.erp_1.4.1Geplante 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. PU: RU: PU: RU: RU-DEV AVS ePA AS NCPeH Die FHIR Ressource Communication wird in der Anwendung E-Rezept u.a. für Nachrichten zwischen Versicherten und Apotheken verwendet. Die Profile besitzen ein Payload-Feld, das den Inhalt der Nachricht im JSON-Format enthält. Derzeit existieren zwei verschiedene gültige Versionen des JSON Schemas, die beide durch Version 3 ersetzt werden. Das JSON Schema der Version 3 erweitert die Funktionalität der Communication-Profile (u.a. GEM_ERP_PR_Communication_DispReq und GEM_ERP_PR_Communication_Reply) sowohl durch neue Felder als auch durch die Festlegung verschiedener Nachrichtenarten. Die Nachrichtenarten bestimmen, welche Felder verpflichtend und welche nicht anzugeben sind. AVS AVS AVS Um ein E-Rezept im europäischen Ausland einlösbar zu machen, benötigt der Task zwei Voraussetzungen. Zum einen muss der E-Rezept-Fachdienst aufgrund der Eigenschaften der Verordnung das E-Rezept als einlösbar markiert haben und zum anderen muss der Nutzer das E-Rezept zur Einlösung im europäischen Ausland freigeben. Für das E-Rezept-FdV existiert bereits eine Anforderung, wonach nur aufgrund der Eigenschaften einlösbare E-Rezepte für die Einlösung im europäischen Ausland freigegeben werden sollen. Mit diesem Änderungseintrag soll zusätzlich eine Anforderung eingeführt werden, die einen Fehler zurückgibt, falls das E-Rezept-FdV versucht, ein E-Rezept für die Einlösung im europäischen Ausland freizugeben, das aber aufgrund der Eigenschaften des E-Rezeptes nicht einlösbar ist. FdV AVS AVS, FdV, KTR, NCPeH, PVS/ZPVS/KIS RU-DEV AVS RU-DEV B_FD-1506 Patch Task schlägt mit HTTP 500 fehl - PatchTaskHandler.cxx:50 RU-DEV Weiterer Scope (noch keinem Releasecandidate zugeordnet) Dieser Änderungseintrag fügt die Einschränkung der Validierung von IDs auf das http(s)- Schema hinzu. Der E-Rezept-Fachdienst validiert die Referenzen innerhalb der Bundle Ressource. Siehe 2025-02-03 Sprechstundenprotokoll. AVS PU: RU: RC3 RU Dev FHIR: Aktivierung neuer Packages zum 01.07.2026 auf PU ERP_2026_03 RC3 RU-Dev RC2 RU-Dev ERP_2026_01 RC2 RU-Dev FHIR: BugFix zu eRezept und eVDGA Bugfix für eML Übertragung an IBM-ePA-Aktensystem (B_FD-1431) C_12263 RU-DEV C_12429 Anpassung der Rückgabe der $dispense-Operation Der E-Rezept-Fachdienst ermöglicht eine vorzeitige Abgabe eines E-Rezepts durch den Aufruf der $dispense-Operation. Bei diesem Aufruf übergibt die Apotheke Dispensierinformationen, ohne den Status oder die Parameter des E-Rezepts zu verändern. Das bedeutet, dass das AVS keine Rückgabeinformationen vom E-Rezept-Fachdienst nach dem Aufruf der Operation benötigt. Aktuell liefert der E-Rezept-Fachdienst die eingestellten Informationen an das AVS zurück.Zur Optimierung der Performance und Reduzierung des Wartungsaufwandes soll die Rückgabe eines erfolgreichen Aufrufs der $dispense-Operation als "204 - No Content" definiert werden. AVS C_12441 Prüfung auf Daten ohne BOM - Die Clientsystem müssen sicherstellen, dass sie für FHIR-Ressourcen "UTF-8 ohne BOM" verwenden! Aus ERPFIND-1061 hat sich der Bedarf ergeben im E-Rezept-Fachdienst technisch eine Anforderung aus "TECHNISCHES HANDBUCH DIGITALE VORDRUCKE" [KBV_ITA_VGEX_TECHNISCHES_HANDBUCH_DIMUS] umzusetzen: "4.2 ZEICHENSATZ Für digitale Muster im Format FHIR gilt der Zeichensatz „UTF-8 ohne BOM“." PVS/ZPVS/KIS Prüfung des Empfängers einer Zuweisung nach FlowType - Keine Anpassung im FdV notwendig! Der E-Rezept-Fachdienst prüft beim Einstellen einer Zuweisung eines E-Rezepts, ob der Empfänger berechtigt ist, auf den Rezepttypen zuzugreifen. D.h. es wird eine Zuweisung von DiGA-Verordnungen an Apotheken und E-Rezepten an Kostenträger verhindert. FdV Rückbau GET /CertList und GET /OCSPList Die beiden Endpunkte /OCSPList und /CertList sind deprecated und werden ab März 2026 abgeschaltet. E-Rezept-FdV nutzen statt dessen die Endpunkte GET /PKICertificates und GET /OCSPResponse. Primärsystem nutzen den Konnektor für Zertifikatsprüfungen FdV Verordnung von e-T-Rezepten (noch nicht für Produktion geplant) (C_12419 Validierung von strukturierten Dosierungen auf PU erst ab 01.07.26) PVS/ZPVS/KIS Validationszeitpunkt EU-Close Parameters 1.20.0-3 PU: OpenSSL Bugfix 1.20.0-2 PU: Zielgruppe ERP_2026_01-1 1.20.0-1 RU: FHIR: BugFix zu eRezept und eVDGA (TI-Validator wird ebenfalls korrigiert und ausgeliefert) ERP_2026_01-1 validierende Clients 1.20.0-0 PU: RU-DEV Verordnungen zu Lasten sonstiger Kostenträger ermöglichen PVS/ZPVS/KIS, 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. 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. 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. 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: Die Verwendung von urn:oid nicht mehr zulässig ist. Der E-Rezept-Fachdienst führt bei übermittelten Ressourcen folgende Prüfungen durch: 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: 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) RU-DEV Detektion von Nutzungsanomalien im E-Rezept-Fachdienst RU-DEV Aktualisierung von Komponenten mit neueren Bibliotheken ePA Operation Outcome Code in BDEv2 aufnehmen (eML) RU-DEV 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 in Task.performerType die Angabe des Coding.system korrigiert. Anpassungsbedarf besteht nur für Clientsysteme, die Task.performerType auswerten. Fehlerbehebung zu RU-DEV fix: Kontext des EU-Feature: nach $eu-close ändert sich Task.lastModified nicht E-Rezept Fachdienst (eRp FD): Geplante Releases
Legende: (U) - unbestätigt
RC1
Zielgruppe 
AVS muss E-Rezepte mit KBV1.4.1 verarbeiten können Alle eML-verarbeitenden Clients müssen ab 01.07.26 mind. das Feld .extension[renderedDosageInstruction] verarbeiten.
FdV
KTR
PVS/ZPVS/KIS AVS und FdV können neue Kommunikationsmöglichkeiten im E-Rezept umsetzen. Hier finden Sie die Datenstruktur zum experimentieren. Teilweise umgesetzt, ohne neue JSON Schema (ANFERP-3628, ANFERP-3651,ANFERP-3671)
FdV AVS und KTR können einen /Task im Status 'completed' (Anwendungsfall "Recovery Secret") abrufen. Bisher war das nur im Status "in-progress" möglich.
KTR
PVS/ZPVS/KIS Änderung für FdV Clients für die Implementierung des "EU-Features": Wenn das E-Rezept-FdV versucht, ein E-Rezept für die Einlösung im europäischen Ausland freizugeben (zu markieren), das aber aufgrund der Eigenschaften des E-Rezeptes nicht einlösbar ist, liefert der E-Rezept-Fachdienst einen Fehler (409).
Die Spezifikation wird so angepasst, dass E-T-Rezepte über den Anwendungsfall "eGK in der Apotheke" abgerufen werden können.
D.h. wenn eine eGK in der Apotheke seine eGK steckt, erhält die Apotheke eine Liste der einlösbaren verschreibungspflichtigen Arzneimittel (WF 160) und der einlösbaren E-T-Rezepte (WF 166) Anpassung notwendig, falls der Endpunkt GET /VAUCertificateOCSPResponse genutzt wird
KTR
PVS/ZPVS/KIS
D.h. der Inhalt von A_21267-01 ist redundant zu parallel existierenden Anforderungen. A_21267-01 wird daher storniert
In der zu ändernden Anforderung A_22927-02 wird ein Fehlertext konkret definiert. Im Bestreben für Entwickler einheitliche Fehlerausgaben zu generieren, wird die konkrete Ausprägung entfernt. In der API Dokumentation wird es dann ein Beispiel geben, was eine generische Ausgabe des FHIR-Validators angeben wird. Dort steht dann z.B. "element doesn't match any slice in closed slicing". Ggf. veränderte Fehlermeldung wenn nicht im Profil definierte Extensions angegeben werdenRC2
Zielgruppe Teilweise umgesetzt
Unterstützung für Bundle bei $close und $dispense zurückbauenRC3
Zielgruppe gemF_eRp _Autorisierung _Apo_2_0_0 AVS RC4
Zielgruppe gemF_eRp _Autorisierung _Apo_2_0_0 AVS Anpassung der Angabe von Referenzen notwendig, falls nicht bereits konform umgesetzt. Über die Aktivierung der Prüfung wird separat in der Sprechstunde informiert.
FdV
KTR
NCPeH
PVS/ZPVS/KIS
RC1
Zielgruppe
Dieser Änderungseintrag nimmt eine Anforderung auf, wonach der E-Rezept-Fachdienst diese Prüfung bei jeder Validierung von FHIR-Ressourcen (d.h. bspw. auch Abgabeinformationen und Communications) durchführt.
AVS
FdV
KTR
NCPeH
ARZ
AVS
FdV RU:
RU:
RU:
RC1
Zielgruppe C_12295
AVS
ARZC_12034
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.PVS/ZPVS/KIS C_12200
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.PVS/ZPVS/KIS
AVS,
FdV,
KTRC_12201
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.AVS
FDVC_12219 PVS/ZPVS/KIS
AVS
FdV
KTRC_12211 KTR C_12129 KTR C_12269 - C_12125 - RC2
C_12190 RC3
- C_12316 RC4
C_12238
Es wird festgelegt, dass bei fehlender Zeitzoneninformation implizit die deutsche Zeit (CET/CEST) angenommen wird.PVS/ZPVS/KIS
AVS
FdV
ARZ
KTRC_12169 AVS RC5
Änderungen: PU: 16.12.25 Änderungen: PU: 11.11.25 Änderungen: PU: 23.07.25 Änderungen: PU: 19.02.25 Änderungen: PU: 11.12.24 Änderungen: PU: 16.10.24 PU: 07.02.24 PU: 13.12.23 PU: 17.10.23Identity Provider (IdP)
Label. Inhalt/Umfang Deployment..... eRp IDP 3.2.0-0
TU: 18.11.25
RU: 18.11.25eRp IDP 3.1.1-1
TU: 28.10.25
RU: 28.10.25eRp IDP 3.1.1-0
ID-Token der Version 2.0.0
[ti_features_supported]
[federation_entity/organization_name]
application/jwk-set+jwt bei Abfrage der URI in signed_jwks_uri eines sektoralen IDPs
TU: 23.06.25
RU: 23.06.25 eRp IDP 3.1.0-1
TU: 18.12.24
RU: 18.12.24 eRp IDP 3.0.5-6
TU: 27.11.24
RU: 27.11.24 eRp IDP 3.0.5-5
TU: 04.09.24
RU: 04.09.24 eRp IDP 3.0.5-3
TU: 17.01.24
RU: 17.01.24 eRp IDP 3.0.5-2
TU: 29.11.23
RU: 29.11.23 eRp IDP 3.0.5-1 Hotfix: CVE-2023-42795 (Bereinigung von Requests)
TU: 16.10.23
RU: 16.10.23