C_11585_Anlage_V1.0.0

Prereleases:

PDF HTML Excel XML
C_11585_Anlage_V1.0.0

C_11585 - E-Rezept: Push Notification für E-Rezept-FdV

Inhaltsverzeichnis

1 Änderungsbeschreibung

Im Rahmen der Anwendung ePA wurde die Feature-Spezifikation "Anwendungsübergreifende Push Notification" ([gemF_PushNotifion]) entwickelt, um Nutzern eines Frontend des Versicherten zu unterrichten, wenn Ereignisse bezüglich ihrer Daten auftreten.
Dieses Feature soll für die Anwendung E-Rezept umgesetzt werden, um den Nutzer über den Statusverlauf seiner Verordnungen und über die Kommunikation mit der Apotheke zu informieren.

2 Technisches Konzept

Der Systemüberblick und das technische Konzept zur Push Notification sind in der Feature-Spezifikation "Anwendungsübergreifende Push Notification" ([gemF_PushNotification]) beschrieben.

Der E-Rezept-Fachdienst übernimmt die Rolle „Fachdienst“. Er verwaltet FdV-Instanzen, die sich bei ihm für den Empfang von Push Notifications registriert haben, erstellt Push Notifications für vom Nutzer abonnierte Ereignisse und übermittelt diese an das zuständige Push Gateway. Der E-Rezept-Fachdienst bietet Schnittstellen für das E-Rezept-FdV zur Registrierung, Deregistrierung und Konfiguration von Kanälen an.


Das E-Rezept-Frontend des Versicherten übernimmt die Rolle „FdV“.

3 Datenschutz und Informationssicherheit

Die wesentlichen Datenschutz- und Sicherheitsmerkmale des Push-Notifications-Feature sind in und durch die Feature-Spezifikation "Anwendungsübergreifende Push Notification" ([gemF_PushNotification]) festgelegt. Dort sind Anforderungen an Fachdienste spezifiziert, die dieses Feature unterstützen. Es gilt der dort festgestellte Schutzbedarf für die Informationsobjekte des Push Notifications Feature.

Bereits in [gemF_PushNotification] festgelegt ist

  • der Einsatz von TLS mit beidseitiger Authentifizierung (mTLS) für die Kommunikation zwischen dem Fachdienst (Client) zum Push Gateway (Server),
  • das Einholen einer informierten Einwilligung vom Nutzer des FdV,
  • die Möglichkeit des Widerrufs der Einwilligung durch den Nutzer,
  • die Mechanismen und Schlüssel zur Registrierung der App.

In der Anwendung E-Rezept werden folgende Maßnahmen umgesetzt, die nicht in [gemF_PushNotification] festgelegt sind:

  • Verschlüsselung des Benachrichtigungsinhalts zwischen Fachdienst und FdV, die sowohl die Vertraulichkeit als auch die Authentizität/Integrität des Benachrichtigungsinhalts schützt,
  • Die Prozesse des Push Notification Managements müssen in der VAU des E-Rezept-Fachdienstes ablaufen.
  • Die vom Push Notification Management verarbeiteten Daten müssen verschlüsselt persistiert werden.
  • Die Registrierung und die Deregistrierung werden im Protokoll für den Versicherten protokolliert.

Die Einwilligung zum Erhalt von Push Nachrichten erfolgt anwendungsunabhängig im FdV bzw. Gerät des Versicherten, ebenso der Widerspruch. Im E-Rezept-Fachdienst werden die E-Rezept-spezifischen Registrierungs- bzw. Benachrichtigungskanalinformationen gespeichert. Die Deregistrierung einer FdV-Instanz bzw. die Abwahl aller Benachrichtigungskanäle bewirkt, dass der Versicherte keine Push Notifications vom E-Rezept-Fachdienst erhält. Falls der Versicherte über die Betriebssystemfunktion seine Einwilligung widerruft, erfolgt im E-Rezept-Fachdienst eine Deregistrierung

des FdVs falls der E-Rezept-Fachdienst beim Versuch eine Push Notification an das FdV zu senden, vom Push Gateway eine entsprechende Fehlermeldung erhält.

4 Spezifikation

4.1 Anforderungen an den E-Rezept-Fachdienst

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_FD_eRp] übernommen.

4.1.1 Neues Kapitel 6.13 Push Notification für E-Rezept-FdV

Die Funktionalität zu Push Notification für FdVs ist anwendungsübergreifend in [gemF_PushNotification] beschrieben. Die umzusetzenden Anforderungen aus [gemF_PushNotification] sind im [gemProdT_eRp_FD_PTV] gelistet. In diesem Kapitel werden die zusätzlichen E-Rezept spezifischen Anforderungen beschrieben.

4.1.1.1 Neues Kapitel 6.13.1 Pusher registrieren

A_28111 - E-Rezept-Fachdienst - Push Notifications - OpenApi_Notification_Fachdienst

Der E-Rezept-Fachdienst MUSS die API mit den Endpunkten GET /pushers und POST /pushers/set gemäß [OpenAPI_FD] bereitstellen. [<=]

A_28112 - E-Rezept-Fachdienst - Push Notifcations - App-Registrierung - Rolle Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation POST /pushers/set die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle

  • oid_versicherter
die Operation aufrufen , damit die Operation nicht durch unberechtigte Dritte ausgeführt wird. [<=]

A_28113 - E-Rezept-Fachdienst - Push Notifcations - App-Registrierungen Abrufen - Rolle Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation GET /pushers die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle

  • oid_versicherter
die Operation aufrufen , damit die Operation nicht durch unberechtigte Dritte ausgeführt wird. [<=]

A_28114 - E-Rezept-Fachdienst - unzulässige Operationen Pushers

Der E-Rezept-Fachdienst MUSS alle Zugriffe auf die Ressource Pushers mittels der HTTP-Operationen PUT, PATCH, HEAD und DELETE sowie POST unterbinden, damit keine unzulässigen Operationen auf den Daten ausgeführt werden können. [<=]

Die folgenden Anforderungen aus der anwendungsübergreifenden Spezifikation [gemF_PushNotification] zur Operation Pusher registrieren werden dem E-Rezept-Fachdienst zugewiesen.

Anforderung Prüfverfahren
A_27104 - Fachdienst - Push Notifications - OpenApi_Notification_Fachdienst funkt. Eignung: Test Produkt/FA
A_27154 - Fachdienst - FdV-Instanz registrieren - App-Registrierung anlegen funkt. Eignung: Herstellererklärung
A_27155 - Fachdienst - FdV-Instanz registrieren - App-Registrierung aktualisieren funkt. Eignung: Herstellererklärung
A_27156 - Fachdienst - FdV-Instanz deregistrieren - App-Registrierung löschen funkt. Eignung: Herstellererklärung
A_27157 - Fachdienst - FdV-Instanz registrieren – Initiale Schlüsselableitung Sich.techn. Eignung: Produktgutachten
A_27158 - Fachdienst - Schlüsselableitung shared-secret-Jahr-Monat und AES/GCM-Schlüssel-Jahr-Monat Sich.techn. Eignung: Produktgutachten
4.1.1.2 Neues Kapitel 6.13.2 Operation Notify

A_28115 - E-Rezept-Fachdienst - Push Notification senden - Nachrichteninhalt erzeugen

Der E-Rezept-Fachdienst MUSS den Nachrichteninhalt einer Push Notification gemäß TAB_eRPFD_028 erzeugen.

Tabelle 1 TAB_eRPFD_028 Nachrichteninhalt Push Notification
ChannelId Identifier IdentifierType PrescribedProduct ActorName Message
erp.task.activate Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$activate -
erp.task.accept Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$accept -
erp.task.reject Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$reject -
erp.task.close Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$close -
erp.task.dispense Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$dispense -
erp.task.abort Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Task/<id>/$abort -
erp.communication.new Communication.basedOn.reference TaskId Falls Communication.basedOn.reference.Task.flowType gleich "160" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Communication.basedOn.reference.Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /Communication Communication.payload.content.info_text
erp.task.vertreter Task.identifier.PrescriptionID TaskId Falls Task.flowType gleich "160", "169", "200" oder "209" ist:
KBV_PR_ERP_Bundle.entry.Medication.code.text
Falls Task.flowType gleich "162" ist:
KBV_PR_EVDGA_Bundle.entry.DeviceRequest.codeCodeableConcept.text
 Lesbarer Name aus dem ID_TOKEN des Zugreifenden bei GET /Task/<id> -
erp.chargeitem.create ChargeItem.identifier.PrescriptionID TaskId ChargeItem.supportingInformation.KBV_PR_ERP_Bundle.entry.Medication.code.text Lesbarer Name aus dem ID_TOKEN des Ausführenden bei POST /ChargeItem -
erp.chargeitem.update ChargeItem.identifier.PrescriptionID TaskId ChargeItem.supportingInformation.KBV_PR_ERP_Bundle.entry.Medication.code.text Lesbarer Name aus dem ID_TOKEN des Ausführenden bei PUT /ChargeItem/<id> -
[<=]

Die Datenstruktur des Nachrichteninhalts ist in [gemSpec_DM_eRp#TAB_eRpDM_004] beschrieben.

A_28116 - E-Rezept-Fachdienst - Push Notification senden - verpflichtende Verschlüsselung

Der E-Rezept-Fachdienst MUSS den Nachrichteninhalt einer Push Notification verschlüsseln. [<=]

Die Vorgaben für die Verschlüsselung ist in "A_27161-* - Fachdienst - Push Notification senden – Nachricht verschlüsseln" beschrieben.

A_28135 - E-Rezept-Fachdienst - Push Notification senden - Referenz auf Protokolleintrag

Der E-Rezept-Fachdienst MUSS beim Erstellen einer Push Notifcation die Identifier des zugehörigen Protokolleintrags (AuditEvent) des Triggers im Feld notification/identifier angeben. [<=]

Die folgenden Anforderungen aus der anwendungsübergreifenden Spezifikation [gemF_PushNotification] zur Operation Notify werden dem E-Rezept-Fachdienst zugewiesen.

Anforderung Prüfverfahren
A_27160 - Fachdienst - Push Notification senden – Schlüsselableitung Sich.techn. Eignung: Produktgutachten
A_27405 - Fachdienst - Schlüsselableitung - Alte Schlüssel löschen Sich.techn. Eignung: Produktgutachten
A_27680 - Fachdienst - Push Notification senden - Nachricht kodieren funkt. Eignung: Test Produkt/FA
A_27161 - Fachdienst - Push Notification senden – Nachricht verschlüsseln Sich.techn. Eignung: Produktgutachten
A_27610 - Fachdienst - Push Notification senden - Größe des Nachrichteninhalts verschleiern Sich.techn. Eignung: Produktgutachten
A_27162 - Fachdienst - Push Notification senden – Einbetten des Zeitstempels funkt. Eignung: Herstellererklärung
A_27163 - Fachdienst - Push Notification senden - Aufruf Push Gateway funkt. Eignung: Herstellererklärung
A_27652 - Fachdienst - Push Notification senden - Hinterlegte URL Sich.techn. Eignung: Produktgutachten
A_27374 - Fachdienst - Push Notification senden - Aufruf Push Gateway Response verarbeiten funkt. Eignung: Herstellererklärung
A_27436 - Fachdienst – Keine personenbezogenen Klartextdaten in Push Notifications Sich.techn. Eignung: Produktgutachten
A_27166 - Fachdienst - Exponential Back-off bei Fehlern im Versand an Push Gateway funkt. Eignung: Herstellererklärung
4.1.1.3 Neues Kapitel 6.13.3 Channel/Trigger Konfiguration

A_28117 - E-Rezept-Fachdienst - Push Notifications - Channels - OpenApi_Notification_Fachdienst

Der E-Rezept-Fachdienst MUSS die API mit den Endpunkten GET /channels, GET /channels/{pushkey} und POST /channels/{pushkey} gemäß [OpenAPI_FD] bereitstellen. [<=]

A_28118 - E-Rezept-Fachdienst - Push Notifcations - Channels abrufen - Rolle Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation GET /channels die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle

  • oid_versicherter
die Operation aufrufen , damit die Operation nicht durch unberechtigte Dritte ausgeführt wird. [<=]

A_28119 - E-Rezept-Fachdienst - Push Notifcations - Channels des Geräts abrufen - Rolle Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation GET /channels/{pushkey} die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle

  • oid_versicherter
die Operation aufrufen , damit die Operation nicht durch unberechtigte Dritte ausgeführt wird. [<=]

A_28120 - E-Rezept-Fachdienst - Push Notifcations - Channels konfigurieren - Rolle Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation POST /channels/{pushkey} die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle

  • oid_versicherter
die Operation aufrufen , damit die Operation nicht durch unberechtigte Dritte ausgeführt wird. [<=]

A_28121 - E-Rezept-Fachdienst - unzulässige Operationen Channels

Der E-Rezept-Fachdienst MUSS alle Zugriffe auf die Ressource Channels mittels der HTTP-Operationen PUT, PATCH, HEAD und DELETE sowie POST unterbinden, damit keine unzulässigen Operationen auf den Daten ausgeführt werden können. [<=]

Die folgenden Anforderungen aus der anwendungsübergreifenden Spezifikation [gemF_PushNotification] zur Channel/Trigger Konfiguration werden dem E-Rezept-Fachdienst zugewiesen.

Anforderung Prüfverfahren
A_27190 - Fachdienst - Push Notifications - Channels - OpenApi_Notification_Fachdienst funkt. Eignung: Test Produkt/FA
A_27193 - Fachdienst - FdV-Instanz registrieren - Liste der event_ids des Geräts anlegen funkt. Eignung: Herstellererklärung
A_27196 - Fachdienst - Push Notification senden - Status der event_id prüfen funkt. Eignung: Herstellererklärung
A_27197 - Fachdienst - FdV-Instanz deregistrieren - Liste der event_ids des Geräts löschen funkt. Eignung: Herstellererklärung

4.1.2 Änderung in Kapitel 6.1.2.2 POST /Task/<id>/$activate

Nach A_25925

A_28126 - E-Rezept-Fachdienst - Task aktivieren - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$activate den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.activate" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.3 Änderung in Kapitel 6.1.2.3 POST /Task/<id>/$accept

Nach A_19149

A_28127 - E-Rezept-Fachdienst - Task akzeptieren - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$accept den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.accept" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.4 Änderung in Kapitel 6.1.2.4 POST /Task/<id>/$reject

Nach A_24286-02

A_28128 - E-Rezept-Fachdienst - Task zurückweisen - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$reject den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.reject" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.5 Änderung in Kapitel 6.1.2.5 POST /Task/<id>/$close

Nach A_19233-05

A_28129 - E-Rezept-Fachdienst - Task schließen - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Beenden eines Tasks mittels HTTP-POST-Operation über /Task/<id>/$close den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.close" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.6 Änderung in Kapitel 6.1.2.6 POST /Task/<id>/$abort

Nach A_19121

A_28131 - E-Rezept-Fachdienst - Task löschen - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task mittels HTTP-POST-Operation über /Task/<id>/$abort den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.abort" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.7 Änderung in Kapitel 6.1.2.7 POST /Task/<id>/$dispense

Nach A_24285-01

A_28130 - E-Rezept-Fachdienst - Dispensierinformationen bereitstellen - Push Notifications

Der E-Rezept-Fachdienst MUSS bei der Bereitstellung von Dispensierinformationen mittels HTTP-POST-Operation über /Task/<id>/$dispense den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.dispense" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.8 Änderung in Kapitel 6.5.2.1 POST /Communication/

Bevor A_22367-02

A_28132 - E-Rezept-Fachdienst - Nachricht einstellen - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Einstellen einer Nachricht mittels HTTP-POST-Operation über /Communication den Push Notification Prozess für den Trigger mit der ChannelId "erp.communication.new" und den Versicherten mit der KVNR = Communication.recipient initiieren [<=]

4.1.9 Änderung in Kapitel 6.1.1 HTTP-Operation GET

Nach A_19116-01

A_28125 - E-Rezept-Fachdienst - Task abrufen - Vertreter - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation GET /Task/<id> durch einen Versicherten mit der Rolle oid_versicherter, sofern die KVNR des Aufrufenden ungleich der KVNR in Task.for ist, den Push Notification Prozess für den Trigger mit der ChannelId "erp.task.vertreter" und den Versicherten mit der KVNR = Task.for initiieren. [<=]

4.1.10 Änderung in Kapitel 6.3.4.1 POST /ChargeItem

Nach A_23704

A_28133 - E-Rezept-Fachdienst - Abrechnungsinformation bereitstellen - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den /ChargeItem den Push Notification Prozess für den Trigger mit der ChannelId "erp.chargeitem.create" und den Versicherten mit der KVNR = ChargeItem.subject initiieren. [<=]

4.1.11 Änderung in Kapitel 6.3.5.1 PUT /ChargeItem/<id>

Nach A_22615-02

A_28134 - E-Rezept-Fachdienst - Abrechnungsinformation ändern - Push Notifications

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende Leistungserbringerinstitution (Apotheke), den Push Notification Prozess für den Trigger mit der ChannelId "erp.chargeitem.create" und den Versicherten mit der KVNR = ChargeItem.subject initiieren. [<=]

4.1.12 Änderung zu Kapitel 5.4 Fehlercodes

Änderung zu TAB_eRPFD_003 Übersicht HTTP-Statuscodes

HTTP-Status-Code Bedeutung in welchen Operationen als Statuscode möglich Bedingung
200 Operation erfolgreich beendet, in der Rückgabe ist ggfs. das Ergebnis der Operation enthalten ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 Die Operation wurde erfolgreich bearbeitet. In der Rückgabe sind die erzeugten bzw. gelesenen Daten enthalten.
400 Bad Request, der Operationsaufruf enthält ungültige Daten. ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 In der aufgerufenen Operation werden vom Client Daten für die Verarbeitung erwartet. Entsprechen sie nicht dem erwarteten FHIR-Profil oder sind sie ungültig (bspw. Signatur), werden sie vom E-Rezept-Fachdienst zurückgewiesen.
401 Der Nutzer konnte nicht authentifiziert werden. ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 Der Aufruf enthält keine oder abgelaufene oder ungültige Authentifizierungsinformationen im HTTP-Request-Header "Authorization"
403 Der Nutzer ist nicht berechtigt, die aufgerufene Operation anzufordern ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 Gemäß Rollenprüfung in jedem Operationsaufruf sind nur bestimmte Operationen je aufrufendem Nutzer zulässig.
408 Request Timeout. Die Anfrage konnte innerhalb der erwarteten Zeit nicht beantwortet werden ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 Der E-Rezept-Fachdienst ist überlastet und kann die Anfrage innerhalb der Wartezeit des Clients (PVS, AVS, FdV) nicht beantworten
429 Der Client hat zu viele Aufrufe innerhalb einer festgelegten Zeitspanne getätigt ...
GET /pushers
POST /pushers/set
GET /channels
GET /channels/{pushkey}
POST /channels/{pushkey}		 Der Client (PVS, AVS, FdV) hat innerhalb des konfigurierten Zeitabschnitts zu viele Requests geschickt

4.1.13 Änderung zu Kapitel 5.5 Zugriffsprotokollierung

Änderung zu A_19284-*  (Hinzufügen der Operation POST /pushers/set)

A_19284-12 - E-Rezept-Fachdienst - Versichertenprotokoll zu Operationen

Der E-Rezept-Fachdienst MUSS jeden Aufruf der folgenden Operationen protokollieren:

Tabelle 2: TAB_eRPFD_004 Versichertenprotokoll

Operation Rolle des
zugreifenden Nutzers		 Beschreibung (ggf. als Vorschlag für einen lesbaren Protokolleintrag in einfacher Sprache)
http GET /Task/<id>
- Versicherter,
Vertreter		 Patient/Versicherter/Vertreter hat das E-Rezept heruntergeladen
Apotheker Apotheke hat die E-Rezept-Quittung heruntergeladen
http GET /Task
Apotheker
  • im Erfolgsfall beim passenden AcceptPN3VSDMxx=false:
Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen.

  • im Erfolgsfall bei PN3 und passende AcceptPN3VSDMxx=true:
Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen. (Offline-Check wurde akzeptiert)
  • im Fehlerfall PN3 und passende AcceptPN3VSDMxx=false:
Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. (Offline-Check wurde nicht akzeptiert)

  • im sonstigen Fehlerfall:
Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. 
Kostenträger Krankenkasse hat die Liste der offenen E-Rezepte (DiGA-Verordnungen) abgerufen.
http POST /Task
$activate Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept bereitgestellt
$accept Apotheke Apotheke hat das E-Rezept heruntergeladen
Kostenträger Krankenkasse hat das E-Rezept heruntergeladen
$reject Apotheke Apotheke hat das E-Rezept zurückgegeben
Kostenträger Krankenkasse hat das E-Rezept zurückgegeben
$dispense Apotheke Apotheke hat das E-Rezept beliefert
$close Apotheke Apotheke hat das E-Rezept abgeschlossen
Kostenträger Krankenkasse hat das E-Rezept abgeschlossen
$eu-close NCPeH-FD Der Parameters.parameter:requestData.part:practitionerRole Parameters.parameter:requestData.part:practitionerName hat in Parameters.parameter:requestData.part:healthcare-facility-type Parameters.parameter:requestData.part:pointOfCare in Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode) Ihr E-Rezept eingelöst.
$abort Versicherter,
Vertreter		 Patient/Versicherter/Vertreter hat das E-Rezept gelöscht
Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept gelöscht
Apotheke Apotheke hat das E-Rezept gelöscht
http PATCH /Task/<id> Versicherter Versicherter hat Markierung zu Einlösung im EU Ausland gespeichert
GET /MedicationDispense?<parameter>=...
Versicherter,
Vertreter		 Patient/Versicherter hat Medikament-Informationen heruntergeladen
http DELETE /ChargeItem/<id> Versicherter Versicherter hat Abrechnungsinformation gelöscht
http GET /ChargeItem/<id> Versicherter Versicherter hat Abrechnungsinformation gelesen
Apotheke Apotheke hat Abrechnungsinformation gelesen
http POST /ChargeItem Apotheke Apotheke hat Abrechnungsinformation bereitgestellt
http PATCH /ChargeItem/<id> Versicherter Versicherter hat Markierung zu Abrechnungsinformation gespeichert
http PUT /ChargeItem/<id> Apotheke Apotheke hat PKV-Abgabedatensatz gespeichert
http POST /Consent Versicherter Versicherter hat Einwilligung für "Beschreibung für Consent.category.coding.code" erteilt.
http DELETE /Consent Versicherter Versicherter hat Einwilligung für "Beschreibung für Consent.category.coding.code" widerrufen. 
http POST /$grant-eu-access-permission Versicherter Sie haben eine Zugriffsberechtigung zum Einlösen von E-Rezepten für das Land "Land B" erteilt.
http DELETE /$revoke-eu-access-permission Versicherter Sie haben die Zugriffsberechtigung zum Einlösen von E-Rezepten für das Land "Land B" gelöscht.
POST /$get-eu-prescriptions
Parameters.parameter:requestData.part:requesttype = demographics NCPeH-FD Der Parameters.parameter:requestData.part:practitionerRole Parameters.parameter:requestData.part:practitionerName hat in Parameters.parameter:requestData.part:healthcare-facility-type Parameters.parameter:requestData.part:pointOfCare in Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode) Ihre Patientendaten abgerufen.
Parameters.parameter:requestData.part:requesttype = e-prescriptions-list NCPeH-FD Der Parameters.parameter:requestData.part:practitionerRole Parameters.parameter:requestData.part:practitionerName hat in Parameters.parameter:requestData.part:healthcare-facility-type Parameters.parameter:requestData.part:pointOfCare in Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode) Ihre offenen E-Rezepte abgerufen.
Parameters.parameter:requestData.part:requesttype = e-prescriptions-retrieval NCPeH-FD Der Parameters.parameter:requestData.part:practitionerRole Parameters.parameter:requestData.part:practitionerName hat in Parameters.parameter:requestData.part:healthcare-facility-type Parameters.parameter:requestData.part:pointOfCare in Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode) Ihre einzulösenden E-Rezepte abgerufen.
POST /pushers/set Versicherter
  • Falls kind=null:
    Versicherter hat das Gerät "device_display_name" für Push-Nachrichten deregistriert.
  • Falls kind=http:
    Versicherter hat das Gerät "device_display_name" für Push-Nachrichten registriert.
Automatisches Löschen durch den Fachdienst
Ressource Task E-Rezept-Fachdienst Veraltete E-Rezepte vom Fachdienst automatisch gelöscht
Ressource MedicationDispense Veraltete Medikament-Informationen vom Fachdienst automatisch gelöscht
Ressource Communication Veraltete Nachrichten vom Fachdienst automatisch gelöscht
Ressource ChargeItem Veraltete Abrechnungsinformation vom E-Rezept-Fachdienst automatisch gelöscht

und die gelesene bzw. geschriebene Ressource im Protokolleintrag AuditEvent.entity.what als Referenz hinzufügen sowie die KVNR des betroffenen Versicherten in AuditEvent.entity.name speichern.
Mit diesen Informationen kann der Versicherte die Zugriffe auf seine Daten nachvollziehen und bei einem unberechtigten Zugriff ggf. intervenieren. [<=]

4.1.14 Änderung zu Kapitel 5.8.4 Sicherheit der Netzübergänge

Änderung zu A_19815-* (Hinzufügen der Push Gateways)

A_19815-03 - E-Rezept-Fachdienst – Richtlinien für den Paketfilter zum Internet

Der Paketfilter des E-Rezept-Fachdienstes MUSS die Weiterleitung von IP-Paketen an der Schnittstelle zum Internet auf die nachfolgenden Protokolle beschränken:

  1. HTTPS, und
  2. OCSP-Zugriffe für das OCSP-Stapling nach A_20026 (vgl. Hinweis nach A_19815-*), ggf. notwendige DNS Anfragen (und Antworten)
  3. Zugriff auf den FHIR-VZD
  4. Zugriff auf Webdienste des BfArM
  5. Zugriff auf die authentisierten Push Gateways
Ein Verbindungsaufbau aus dem E-Rezept-Fachdienst in Richtung Internet MUSS unterbunden werden, mit Ausnahme der Verbindungen aus Punkten 2, 3, 4 und 5. [<=]

4.2 Anforderungen an das E-Rezept-FdV

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_eRp_FdV] übernommen.

4.2.1 Neues Kapitel 5.2.3.23 Push Notifications

Die Funktionalität zu Push Notification für FdVs ist anwendungsübergreifend in [gemF_PushNotification] beschrieben. Die umzusetzenden Anforderungen aus [gemF_PushNotification] sind im [gemProdT_eRp_FD_PTV] gelistet. In diesem Kapitel werden die zusätzlichen E-Rezept spezifischen Anforderungen beschrieben.

4.2.1.1 Neues Kapitel 5.2.3.23.1 FdV-Instanz Registrieren

A_28122 - E-Rezept-FdV: Push Notifications - Instanz registrieren - OpenAPI

Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall "Push Notifications" umsetzt, für die Registrierung und Verwaltung der FdV-Instanzen am E-Rezept-Fachdienst die Operationen gemäß [OpenAPI_FD] verwenden. [<=]

Die folgenden Anforderungen aus der anwendungsübergreifenden Spezifikation [gemF_PushNotification] zur FdV-Instanz werden dem E-Rezept-Fachdienst zugewiesen.

Anforderung Prüfverfahren
A_27168 - FdV: Push Notifications - Instanz registrieren - app_id funkt. Eignung: Herstellererklärung
A_27171 - FdV: Push Notifications - Instanz registrieren - pushkey aktualisieren funkt. Eignung: Test Produkt/FA
A_27172 - FdV: Push Notifications - Instanz registrieren funkt. Eignung: Test Produkt/FA
A_27173 - FdV: Push Notifications - Instanz registrieren - pushkey ermitteln funkt. Eignung: Herstellererklärung
A_27174 - FdV: Push Notifications - Instanz registrieren - initial shared secret (iss) erzeugen Sich.techn. Eignung: Produktgutachten
A_27175 - FdV: Push Notifications - Instanz registrieren - Aufruf funkt. Eignung: Test Produkt/FA
A_27396 - FdV: Push Notifications - Instanz registrieren - Keine personenbezogenen Daten bei der Registrierung nutzen Sich.techn. Eignung: Produktgutachten
A_27176 - FdV: Push Notifications - Instanz registrieren - Initiale Schlüsselableitung shared-secret-Jahr-Monat und AES/GCM-Schlüssel-Jahr-Monat Sich.techn. Eignung: Produktgutachten
A_27177 - FdV: Push Notifications - Instanz registrieren - Speichern des kryptographischen Materials funkt. Eignung: Herstellererklärung
A_27375 - FdV: Push Notifications - Instanz registrieren - initial shared secret (iss) löschen Sich.techn. Eignung: Produktgutachten
A_27664 - FdV: Push Notifications - Instanz registrieren - Registrierte Instanzen anzeigen Sich.techn. Eignung: Produktgutachten
A_27665 - FdV: Push Notifications - Instanz löschen Sich.techn. Eignung: Produktgutachten
A_27170 - FdV: Push Notifications - Schlüsselableitung shared-secret-Jahr-Monat und AES/GCM-Schlüssel-Jahr-Monat Sich.techn. Eignung: Produktgutachten
A_27178 - FdV: Push Notifications empfangen funkt. Eignung: Test Produkt/FA
A_27179 - FdV: Push Notifications empfangen - Schlüsselableitung Sich.techn. Eignung: Produktgutachten
A_27180 - FdV: Push Notifications empfangen - Löschen alter Schlüssel Sich.techn. Eignung: Produktgutachten
A_27181 - FdV: Push Notifications empfangen - Benachrichtigungsinhalt entschlüsseln Sich.techn. Eignung: Produktgutachten
A_27612 - FdV: Push Notifications empfangen - Aktive Bestätigung bei Verlassen des FdVs Sich.techn. Eignung: Produktgutachten
A_27182 - FdV: Push Notifications - Default deaktiviert funkt. Eignung: Herstellererklärung
A_27183 - FdV: Push Notifications - Option aktivieren funkt. Eignung: Test Produkt/FA
A_27184 - FdV: Push Notifications - Option deaktivieren funkt. Eignung: Test Produkt/FA
A_27185-01 - FdV: Datenschutzinformationen zu Push Notifications Sich.techn. Eignung: Produktgutachten

4.2.1.2 Neues Kapitel 5.2.3.23.2 Channel/Trigger Konfiguration

A_28123 - E-Rezept-FdV: Push Notifications - Channelkonfiguration - OpenAPI

Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall "Push Notifications" umsetzt, für die Registrierung und Verwaltung der Channels für die FdV-Instanzen des Versicherten am E-Rezept-Fachdienst die Operationen gemäß [OpenAPI_FD] verwenden. [<=]

Die folgenden Anforderungen aus der anwendungsübergreifenden Spezifikation [gemF_PushNotification] zur Channel/Trigger Konfiguration werden dem E-Rezept-Fachdienst zugewiesen.

Anforderung Prüfverfahren
A_27198 - FdV Push Notifications - Instanz registrieren - Channelkonfiguration anlegen funkt. Eignung: Test Produkt/FA
A_27666 - FdV Push Notifications - Channelkonfiguration verwalten funkt. Eignung: Test Produkt/FA
4.2.1.3 Neues Kapitel 5.2.3.23.3 Push Notification Historie

Das optionale Feature "Push Notification Historie" wird im E-Rezept-Fachdienst nicht wie in [gemF_PushNotification] beschrieben umgesetzt. Stattdessen übermittelt der E-Rezept-Fachdienst den Identifier des AuditEvents, der durch den Trigger der Push Notifcation erstellt wird, an das Push Gateway im Feld notification.identifier. Dadurch besteht die Möglichkeit, dem Nutzer eine Historie der gesendeten Push Notifications anzubieten.

4.3 Anforderung für gemSpec_DM_eRp

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_DM_eRp] übernommen.

4.3.1 Neues Kapitel 2.8 Push Notifications

A_28124 - E-Rezept - Push Notifications - Datenstruktur Nachrichteninhalte

Der E-Rezept-Fachdienst und das E-Rezept-FdV MÜSSEN für den Anwendungsfall "Push Notifications" Nachrichteninhalte mit der Datenstrukur im JSON Format gemäß TAB_eRpDM_004 unterstützen.

Tabelle 3 TAB_eRp_DM_004 Push Notification Datenstruktur Nachrichteninhalte

Attribut verpflichtend Beschreibung zulässige Werte Beispiel
ChannelId ja Der Trigger, der die Push Notification initiiert hat. bis zu 30 Stellen, UTF-8 erp.task.activate
Identifier ja Ein Identifier, der als Kontext zur Nachricht dient. bis zu 50 Stellen, UTF-8 160.000.000.000.123.76
IdentifierType ja Der Art Identifier, der mitgeschickt wird. bis zu 20 Stellen, UTF-8 TaskId
PrescribedProduct nein Der Name des verordneten Produkts (Medikament oder DiGA).  bis zu 100 Stellen, UTF-8 Sumatriptan-1a Pharma 100 mg Tabletten
ActorName nein Der Name des Akteurs. Das kann zum Beispiel der Name der Apotheke oder des Kostenträgers sein. bis zu 100 Stellen, UTF-8 Meine Apotheke
Message nein Die Nachricht, die an den Versicherten verschickt wird. bis zu 300 Stellen, UTF-8 Wir möchten Sie informieren, dass Ihre bestellten Medikamente zur Abholung bereitstehen.
[<=]

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

Kürzel
 Erläuterung
FdV Frontend des Versicherten

5.2 Referenzierte Dokumente

5.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

[Quelle]
 Herausgeber: Titel
[gemF_PushNotification] gematik: Feature: Anwendungsübergreifende Push Notification
[gemProdT_eRp_FD_PTV] gematik: Produkttypsteckbrief E-Rezept-Fachdienst
[gemSpec_DM_eRp] gematik: Spezifikation Datenmodell E-Rezept
[gemSpec_eRp_FdV] gematik: Spezifikation E-Rezept Frontend des Versicherten
[gemSpec_FD_eRp] gematik: Spezifikation E-Rezept-Fachdienst
[OpenAPI_FD] gematik: https://github.com/gematik/api-erp/blob/feature/push-notifications/resources/openapi/erp_fd_push_notifications.yaml