Im Folgenden die umgesetzten, abgelösten Releases. Informationen, die älter als 1 Jahr sind, werden entfernt. Die Installationen auf der RU-DEV können in der Regel nur kurzfristig bekannt gegeben werden.
WORKFLOW 1.4 (AB 15.01.25)KBV 1.1.2DMP 1.06ABGABEDATEN 1.4ABGABEDATEN PKV 1.3.0 (AB 15.01.25)PATIENTENRECHN 1.0.4 (AB 15.01.25)ABRECHNUNGSDATEN 1.4DARREICHUNG 1.14
RU
TU
RU-DEV
eRp FD 1.16.0-1 RC3 - finale Version
eRp FD 1.16.0-1 RC2
Korrektur bei der Ausgabe der Duration in BDE Daten
eRp FD 1.16.0-1 RC1
Medication Service (Versichertenprotokoll), Fehlerbehandlung Aktenkonto-Umzug, Toggle für PU/nonPU im VAU-Protokoll, DeadLetter Queue bei Validierungsfehler im MedicationService
Behebung Mapping Problem von ERP-Medication 1.4 zu ePA-Medication denominator, $close oder $dispense ohne Medication, Verbesserung der Fehlerbehandlung im exporter
Verbesserung Logging, Monitoring und Performance
eRp FD 1.15.0-5
eRp FD 1.15.0-5
Bereinigung von Tasks im Status "Cacelled".
PU
TU
-
RU
-
RU-DEV
-
eRp FD 1.15.0-3
eRp FD 1.15.0-3
Prüfung im Fachdienst:
Zeitpunkt $close muss jünger sein als Zeitpunkt $accept
Zeitsynchronisation beim Start des VAU-Image erzwingen
Versionsvalidierung des Binarys bei POST /ChargeItem
Die Funktionalität zu Pagination, Filtern und Sortieren von Listen wurde für die Endpunkte GET /Task, GET /Communication, GET /AuditEvent, GET /MedicationDispense und GET /ChargeItem wurde überarbeitet.
Betroffen: AVS, FdV
Dieses Feature gibt den Apotheken die die kundenfreundliche Möglichkeit, die Dispensierinformationen unmittelbar nach der Abgabe für den Versicherten bereitzustellen, sodass dieser die Information in seiner App anzeigen kann, Zukünftig werden diese Informationen auch in die ePA übermittelt. Dieses Feature ist erst verfügbar, wenn die Workflow FHIR Profile 1.3 durch den E-Rezept-Fachdienst genutzt wird.
In der Implementierung des E-Rezept-Fachdienstes wurde als Identifier des ChargeItems die Rezept-ID gewählt. Mit dieser Änderung wird das in der Spezifikation so festgeschrieben.
Kein Anpassungsbedarf für Clientsysteme.
Beim Einstellen eines E-Rezepts für die Workflow 160/169/200/209 prüft der E-Rezept-Fachdienst, ob im Verordnungsdatensatz eine Arzneimittel beinhaltet (Medication.extension:Arzneimittelkategorie = 00). Falls nicht wird der Http-Fehlercode 400 mit OperationOutcome "Für diesen Workflowtypen sind nur Arzneimittelverordnungen zulässig" an das PVS übermittelt. So soll bspw. sichergestellt werden, dass nicht eine DiGA über diese Workflows übermittelt wird.
Der E-Rezept-Fachdienst validiert den Verordnungsdatensatz, welcher durch den Verordnenden eingestellt wird. Als Teilaktivität wird geprüft, ob die Angabe zur Darreichungsform in einem gültigen Wertekatalog enthalten ist. Am 01.10.24 werden folgende Werte in der Schlüsseltabelle "DARREICHUNGSFORM" gültig.
IID - Injektions- und Infusionsdispersion
LIV - Lösung zur intravesikalen Anwendung
Betroffen: AVS, PVS/ZPVS/KIS
Der E-Rezept-Fachdienst validiert den Verordnungsdatensatz, welcher durch den Verordnenden eingestellt wird. Als Teilaktivität wird geprüft, ob die Angabe zur DMP-Kennzeichen in einem gültigen Wertekatalog enthalten ist. Am 01.10.24 wird S_KBV_DMP Version 1.06 gültig. siehehttps://applications.kbv.de/S_KBV_DMP.xhtml
Betroffen: AVS, PVS/ZPVS/KIS
Abschaltung des InfoReq Endpunktes für Anwendungsfall "Apothekenanfrage" (Feature noch in Spezifizierung)
kleinere Fehlerbehebungen
PU
eRP FD 1.15.0-2
WORKFLOW 1.3 (AB 01.11.24)KBV 1.1.2DMP 1.06 (AB 01.10.24)ABGABEDATEN 1.4 (AB 01.11.24) ABGABEDATEN PKV 1.2PATIENTENRECHN 1.0.2ABRECHNUNGSDATEN 1.4 (AB 01.11.24)DARREICHUNG 1.14 (AB 01.10.24)
TU
eRP FD 1.15.0-2
RU
eRP FD 1.15.0-2
Zustand bis 15.09.2024
Konfiguration wie v1.14 auf PU
Zustand ab 16.09.2024 (ERP_2024_10_01_VALID_FROM=16.09.2024)
Darreichungsform_1_14 gültig
DMP_1_06 gültig
workflow Profile 1.2 werden akzeptiert
Zustand ab 14.10.2024 (ERP_2024_11_01_VALID_FROM=14.10.2024)
Darreichungsform_1_14 gültig
DMP_1_06 gültig
workflow Profile 1.2 werden akzeptiert
workflow Profile 1.3 werden akzeptiert
eRP FD 1.15.0-1
wie 1.15.0-0
eRP FD 1.15.0-0
Zustand bis 05.08.2024
Konfiguration wie v1.14 auf PU
Zustand ab 06.08.2024 (ERP_2024_11_01_VALID_FROM=06.08.2024)
Darreichungsform_1_14 gültig
DMP_1_06 gültig
workflow Profile 1.2 werden akzeptiert
workflow Profile 1.3 werden akzeptiert, FD antwortet mit 1.3
Behebung Fehler bei Validierung der MVO-ID auf urn:ietf:rfc:3986
eRp FD 1.14.1-1:
Behebung Netzwerk-Interface Fehler auf neuer VAU Server-HW
eRp FD 1.14.1-0:
Im Rahmen des Anwendungsfalls "eGK in der Apotheke" ruft ein AVS mittels de Operation GET /Task die Liste der offenen E-Rezepte zu einer KVNR ab. Aktuell enthält die Ergebnisliste auch E-Rezepte deren Gültigkeitszeitraum (expirydate) bereits überschritten ist. Wenn das AVS im Folgeschritt mittels $accept Operation die Verordnungsdaten zu einem E-Rezept abruft, antwortet der E-Rezept-Fachdienst mit einem Fehler, falls der Gültigkeitszeitraum des E-Rezepts überschritten wurde.
Die Operation GET /Task wird so angepasst, dass die Ergebnisliste keine E-Rezepte enthält deren Gültigkeitszeitraum überschritten ist.
Keine Änderung im AVS notwendig.
Die Technische Anlage zur elektronischen Arzneimittelverordnung sieht für das Feld value vor: Die Software stellt sicher, dass das Element extension:Mehrfachverordnung.extension:ID.value[x]:valueIdentifier.value nach folgenden Vorgaben befüllt wird. Es wird eine UUID in Form einer URN übermittelt. Die UUID wird gemäß RFC4122 Version 5 mit den zugehörigen Separatoren erzeugt. Der Inhalt des Elementes entspricht somit dem folgenden Schema urn:uuid: <XXXXXXXX-XXXX-XXXXXXXX-XXXXXXXXXXXX>, welches die UUID nach darstellt.
Die Prüfung des E-Rezept-Fachdienst wird angepasst, sodass der value dem Schema aus TECHNISCHE ANLAGE ZUR ELEKTRONISCHEN ARZNEIMITTELVERORDNUNG (E16A) (v.1.51) #Pflichtfunktion P36-26 Akzeptanzkriterium 3.b) entsprechen muss. Dies wird unabhängig davon validiert, ob das System angegeben ist oder nicht.
Wenn sich das verordnende System TA konform verhält, ist keine Anpassung notwendig.
Weitere betriebliche Anpassungen, die keinen Impact auf Clients haben:
Anpassen des UA Handlings an der Webschnittstelle
Erweiterung für den Endpunkt Get /Random
Erweiterung für die beiden neuen Endpunkte Get/PKICertificates und Get /OCSPResponse
Der E-Rezept-Fachdienst validiert den Verordnungsdatensatz, welcher durch den Verordnenden eingestellt wird. Als Teilaktivität wird geprüft, ob die Angabe zur Darreichungsform in einem gültigen Wertekatalog enthalten ist. Am 01.07.24 wird folgender Wert in der Schlüsseltabelle "DARREICHUNGSFORM" gültig: LYO - Lyophilisat zur Herstellung einer Infusionslösung
Der E-Rezept-Fachdienst validiert den Verordnungsdatensatz, welcher durch den Verordnenden eingestellt wird. Als Teilaktivität wird geprüft, ob die Angabe zur Darreichungsform in einem gültigen Wertekatalog enthalten ist. Der Wertekatalog enthält eine Angabe, zu welchem Stichtag ein Wert zulässig wird. Der E-Rezept-Fachdienst hat eine generische Lösung implementiert, um die Wertetabelle und die stichtagsbezogene Gültigkeit für die Validierung abzubilden.
Keine Anpassung im PVS/ZPVS, AVS notwendig.
Das E-Rezept-FdV ist dazu verpflichtet die Zertifikate, die es für die Kommunikation mit dem IDP-Dienst und dem E-Rezept-Fachdienst nutzt, auf Gültigkeit zu prüfen. Hierfür wurden bisher zwei Endpunkte am E-Rezept-Fachdienst implementiert, die dem FdV ermöglichen diese Prüfungen durchzuführen: GET /CertList und GET/OCSPList. Diese bisherige Implementierung weist Abhängigkeiten auf, die insbesondere beim Wechsel von Zertifikaten zu Problemen führen kann.
Einführung neuer Endpunkte GET /PKICertificates und GET /OCSPResponse am E-Rezept-Fachdienst für den Bezug der Zertifikate und OCSP-Reponses.
Kein breaking Change, da die bestehende Lösung erst in der zweiten Jahreshälfte 2025 abgekündigt wird.
PU
Inhalt geht mit Patchupdate v1.14.0-1 live
eRp FD 1.13.0-4
Behebung Problem im Bereich DB-Wartung
PU
eRp FD 1.13.0-3
1.13.0-2 zzgl.:
Fehlerbehebung SysDig Agent
PU
eRp FD 1.13.0-2
Aktualisierung Secure Boot Zertifikat
Änderungen am front-laod-balancer und tls-proxy
PU
-
RU
eRp FD 1.13.0-1
eRp FD 1.13.0-0 zzgl.:
Bei einer festgestellten Nichtverfügbarkeit eines Fachdienstes VSDM oder eines Intermediär VSDM temporär für den Zeitraum der Nichtverfügbarkeit auch ein VSDM-Prüfungsnachweis mit dem Ergebnis 3 vom E-Rezept-Fachdienst akzeptiert werden.
Anpassung durch AVS notwendig API ist abwärtskompatibel
Entlassrezepte sollen nur 3 Werktage zu Lasten der Krankenkasse einlösbar sein (Task.AcceptDate = Signaturzeitpunkt + 2 Werktage nach A_19517). Aktuell setzt der Fachdienst die Dauer auf 6 Tage. Dies wurde in der Vergangenheit durch Pandemie auf 6 Tage erhöht.
Keine Anpassung im PVS/ZPVS, AVS notwendig.
PU
eRp FD 1.13.0-0
C_11553 - Änderung BDEv2 Messagefeld MVO, Task-ID und (Z)ANR
C_11573 - E-Rezept: Lieferung von Bestandsdaten
sowie:
Der E-Rezept-Fachdienst prüft im Rahmen der Operation zum Einstellen von E-Rezepten die Korrektheit der Prüfziffer für die LANR. Hierfür ist eine Liste von Pseudonummern angegeben, die ebenfalls akzeptiert sind. Folgende zusätzliche Pseudonummer soll in Absprache mit der KBV aufgenommen werden: 333333300 Grundlage:https://www.kbv.de/media/sp/Vereinbarung_BSNR_Vergabe.pdf(Seite 4)
Keine Anpassung im PVS/ZPVS notwendig.
Das vom E-Rezept-Fachdienst ausgestellte Quittungs Bundle ist aktuell nicht FHIR Konform, da es zu einer Mischung von absoluter und relativer Referenz kommt. Die Referenzen im Quittungsbundle wird so umgestellt, dass alle Referenzen als absolute Referenzen urn:uuids angegeben werden.
SieheERPFIND-617-Fehlerhafte Referenzen im QuittungsbundleIN ARBEIT
Keine Anpassung im AVS notwendig.
Das Workflow Modell für die E-Rezepte sieht vor, dass eine Apotheke ein E-Rezept im Status "offen" in Kenntnis des E-Rezept-Token (Task-ID, AccessCode) vom E-Rezept-Fachdienst abruft. Mit diesem Abruf ändert sich der Status des Task in "in Abgabe (gesperrt)" und die Apotheke erhält ein Secret, welches für das Weiterführen des Workflow an den E-Rezept-Fachdienst übermittelt werden muss. Ein erneuter Abruf des E-Rezeptes im Status "in Abgabe (gesperrt)" ist nicht möglich.Es besteht das Risiko, dass beim Übermitteln der Response vom Fachdienst zum AVS ein Fehler auftritt und der Response nicht durch das AVS verarbeitet werden kann. In diesem Fall kann der Workflow nicht weitergeführt werden. Der Versicherte benötigt ein neues E-Rezept.Um das zu vermeiden, soll dem AVS die Möglichkeit gegeben werden, die Informationen zum E-Rezept noch einmal vom E-Rezept-Fachdienst abzurufen, wenn es dieses E-Rezept zuvor für die Belieferung abgerufen hat. Das AVS übermittelt hierfür die Informationen aus dem E-Rezept-Token.
Anpassung durch AVS notwendig
Das Feature "eGK in der Apotheke" ermöglicht es einem Versicherten per Stecken der eGK alle Rezepte in einer Apotheke einzulösen. E-Rezepte, die mit Workflow 169 im E-Rezept-Fachdienst eingestellt wurden, werden derzeit ebenfalls über dieses Feature mit übertragen. Mit dieser Änderung werden nur noch E-Rezepte des Workflow 160 durch den E-Rezept-Fachdienst an das AVS übermittelt.
keine Anpassung durch das AVS notwendig
Bisher war es möglich, dass AVS Verordnungen abrufen, deren Einlösefrist bereits überschritten ist. Dies wird mit dieser Änderung durch den E-Rezept-Fachdienst unterbunden.
Anpassung durch AVS notwendig
Add Comment