latest

PDF HTML Excel XML
latest






Elektronische Gesundheitskarte und Telematikinfrastruktur





Feature:

E-Rezepte für PKV-Versicherte: apothekenpflichtige Arzneimittel 



    

     

      Version
      1.0.3
     

     

      Revision
      947492
     

     

      Stand
      07.12.2022
     

     

      Status
      freigegeben
     

     

      Klassifizierung
      öffentlich
     

     

      Referenzierung
      gemF_eRp_PKV


Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version
 Stand
 Kap./ Seite
 Grund der Änderung, besondere Hinweise
 Bearbeitung
1.0.0 25.04.2022 Erstversion des Dokumentes gematik
1.0.1 26.04.2022 Kap. 6.1.4.2.2 Kap. 6.1.4.3.1 Korrekturen nach Abstimmung mit Auftragnehmer und Veröffentlichung gematik
1.0.2 09.08.2022 Kap. 6.1.2
Kap. 6.4.7		 Ergänzung Tabelle  TAB_eRPFD_004 Versichertenprotokoll
Anpassung A_19631-*; Hinweis zu A_19631-*		 gematik
1.0.3 07.12.2022 Kap. 6.1.4.5.1 Änderung A_22616-* (AccessCode im URL-Parameter);
Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance_22.3		 gematik

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Feature zur Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für PKV-Versicherte und die Bereitstellung der Abrechnungsinformationen für den Kostenträger. Das Feature umfasst die Definition der Prozessparameter und Ergänzungen der workflowspezifischen Anforderungen an die Schnittstellen des E-Rezept-Fachdienstes sowie die Darstellung der Use Cases für Leistungserbringer und Versicherte.

1.1 Zielsetzung

Die Beschreibung des Funktionsumfangs als Feature erleichtert das Verständnis und die Nachvollziehbarkeit der Lösung, ausgehend von der Darstellung der Nutzersicht auf Epic-Ebene, über das technische Konzept bis zur Spezifikation der technischen Details. Mit den hier aufgestellten Anforderungen sollen Hersteller in der Lage sein, den zusätzlichen Funktionsumfang ihrer verantworteten Komponente bzw. Produkttyp bewerten und umsetzen zu können. 

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller und Anbieter des Produkttyps E-Rezept-Fachdienst sowie Hersteller von Clientsystemen für den Zugriff auf den E-Rezept-Fachdienst.

1.3 Abgrenzungen

Die Festlegungen zum E-Rezept des bisher spezifizierten Standard-Workflows für apothekenpflichtige Arzneimittel sind nicht Gegenstand dieses Dokuments. Auch sollen die Ausführungen dieses Dokuments nicht im Widerspruch zu den bisherigen Festlegungen verstanden werden.

1.4 Methodik

Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Afo / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

  • ID: einen eindeutigen Identifier.
    • bei einer Anforderung besteht der Identifier aus der Zeichenfolge 'A_' gefolgt von einer Zahl,
    • bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
  • Titel der Anforderung / Anwendungsfalles: ein Titel, welcher zusammenfassend den Inhalt beschreibt
  • Text / Beschreibung: ausführliche Beschreibung des Inhalts, kann neben Text Tabellen, Abbildungen und Modelle enthalten

Dabei umfasst die Anforderung/der Anwendungsfall sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

User Stories

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikepedia: User Story]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.

Hinweise auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Epic und User Story

In diesem Abschnitt wird das Feature fachlich motiviert und der Mehrwert für Nutzer vorgestellt. Aus diesen Epics und User Stories wird anschließend ein technisches Konzept abgeleitet.

2.1 Epic E-Rezept für PKV-Versicherte

Der Ablauf für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für PKV-Versicherte orientiert sich an der Verordnung von apothekenpflichtige Arzneimittel für GKV-Versicherte. Die Abrechnung der Apotheke erfolgt gegenüber dem Versicherten, sofern keine Direktabrechnung mit einer Krankenversicherung vereinbart wurde. Stattdessen wird der Prozess um Aspekte für die Bereitstellung von Informationen für die Erstattung der Kosten für den Versicherten erweitert. 

Abbildung 1 : Ablauf

Der (Zahn-)Arzt verschreibt ein E-Rezept. Das E-Rezept wird auf den E-Rezept-Fachdienst übertragen. Der Versicherte erhält einen E-Rezept-Token im E-Rezept-FdV oder auf einem Tokenausdruck. Der Versicherte übermittelt den E-Rezept-Token an eine Apotheke seiner Wahl. Die Apotheke ruft das E-Rezept vom E-Rezept-Fachdienst ab und dispensiert es. Die Apotheke stellt, sofern das E-Rezept nicht dem Sachleistungsprinzip unterliegt, auf Wunsch des Versicherten die Abrechnungsinformation zum E-Rezept im E-Rezept-Fachdienst bereit. Dort werden sie mit Einwilligung des Versicherten bis zu 10 Jahren gespeichert. Alternativ übergibt der Apotheker dem Versicherten im Ersatzverfahren einen Papierbeleg mit den abrechnungsrelevanten Informationen für die Abrechnung. Der Versicherte lädt die digital bereitgestellte Abrechnungsinformation mit dem E-Rezept-FdV vom E-Rezept-Fachdienst herunter. Der Versicherte kann für die Abrechnung die Abrechnungsinformation an eine App seiner PKV / der Beihilfe weiterleiten, in einem Portal des Kostenträgers hochladen oder ausdrucken.

Der Ablauf für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel mit Steuerung durch den Leistungserbringer für PKV-Versicherte orientiert sich an der Verordnung von apothekenpflichtige Arzneimittel mit Steuerung durch den Leistungserbringer für GKV-Versicherte (Workflow-Typ "169").

2.2 User Stories

Die User Stories beschreiben die Erwartungen der Nutzer für die neuen digitalen Prozesse mit Bezug zur Abrechnung.

2.2.1 PKV-Versicherte

Als PKV-Versicherter möchte ich in der E-Rezept-App meine Zustimmung/Einwilligung geben können, so dass digitale Abrechnungsinformationen durch Apotheker im E-Rezept-Fachdienst gespeichert werden können.

Als PKV-Versicherter möchte ich in der E-Rezept-App meine Zustimmung/Einwilligung für die Speicherung von digitalen Abrechnungsinformationen zu jedem beliebigen Zeitpunkt widerrufen können.

Als PKV-Versicherter möchte ich, dass mein Apotheker erkennt, dass ich in der E-Rezept-App dem Speichern von digitalen Abrechnungsinformationen zugestimmt habe.

Als PKV-Versicherter möchte ich wählen können, ob der Apotheker mir die Abrechnungsinformation für ein E-Rezept analog (Papierbeleg) oder digital zur Verfügung stellt.

Als PKV-Versicherter möchte ich nach Abgabe in der Apotheke alle Belege in der E-Rezept-App aufrufen und nutzen können.

Als PKV-Versicherter möchte ich die Verordnungs- und Abgabedaten sowie Dispensierinformationen zusammenhängend in der App angezeigt bekommen, sodass ich nachvollziehen kann, was mir vom Arzt verordnet, was mir in der Apotheke mitgegeben  wurde und was ich gegenüber meiner Kasse abrechnen kann .

Als PKV-Versicherte möchte ich die digitalen Abrechnungsinformationen aus der E-Rezept-App als PDF-Dokument an einen anderen digitalen Speicherort exportieren und ausdrucken können, um meine Abrechnungen auch an einer anderen Stelle dokumentieren zu können. 

Als PKV-Versicherter möchte ich aus der E-Rezept-App heraus alle abrechnungsrelevanten Informationen als PDF-Dokument digital an meinen Kostenträger übermitteln können, um eine Erstattung beantragen zu können (Eine Übermittlung erfolgt nicht automatisch).

Als PKV-Versicherter möchte ich meine eingereichten Abrechnungen im E-Rezept-Fachdienst markieren können.

Als PKV-Versicherter möchte ich, dass mein Apotheker die Abrechnungsinformationen ändern kann, wenn mir bei der Abrechnung ein Fehler auffällt. Dazu möchte ich den Apotheker in der App berechtigen können.

Als PKV-Versicherter möchte ich in der E-Rezept-App darauf hingewiesen werden, wenn die Abrechnungsinformationen nachträglich geändert wurden.

Als  Versicherter möchte ich immer nur die neuste Version der Abrechnungsinformation an meinen Kostenträger weiterleiten können, damit ich nicht mit den Versionen durcheinanderkomme.

Als PKV-Versicherter möchte ich in der E-Rezept-App einen Hinweis angezeigt bekommen, bevor mein PKV-Rezept nach Ablauf von 10 Jahren automatisch gelöscht wird. 

2.2.2 Apotheker

Als Apotheker möchte ich in meinem AVS erkennen können, ob der Versicherte dem Speichern von digitalen Abrechnungsinformationen zugestimmt hat.

Als  Apotheker möchte ich dem Versicherten die digitalen Abrechnungsinformationen über den E-Rezept-Fachdienst bereitstellen können, falls der Versicherte seine Einwilligung erteilt hat.

Als Apotheker möchte ich, auf Wunsch des Versicherten, eine fehlerhaft erstellte digitale Abrechnungsinformation überschreiben können.

Als Apotheker möchte ich bei meinem Kunden die Einwilligung einholen können, um die Abrechnungsinformationen ändern zu können, wenn mir ein Fehler darin auffällt.

Als Apotheker möchte ich in meinem AVS benachrichtigt werden, wenn ein Kunde eine Änderung einer Abrechnungsinformation anfragt.

2.2.3 Kostenträger

Als Kostenträger möchte ich digital eingereichte E-Rezept-Abrechnungsinformationen direkt digital weiterverarbeiten können.

Als Kostenträger möchte ich doppelte Einreichungen (analog und digital) von E-Rezept-Abrechnungsinformationen zur Erstattung erkennen können.

3 Einordnung in die Telematikinfrastruktur

Die Einführung des E-Rezepts für PKV-Versicherte setzt auf die bestehende Infrastruktur auf, die mit der Umsetzung des E-Rezepts geschaffen wurde.

PKV-Versicherte sind eine neue Benutzergruppe. 

Die App des Kostenträgers ist eine neue Komponente, zu der das E-Rezept-Frontend des Versicherten eine Schnittstelle für Abrechnungsinformationen anbietet. Die App des Kostenträgers ist keine Komponente der TI. Der Export in Form eines PDFs ermöglicht hierbei weitere Kanäle zur Übermittlung wie bspw. E-Mail oder Webportal.

Abbildung 2: Übersicht E-Rezept-Komponenten

4 Fachliches Konzept

Die digitale Abrechnungsinformation besteht aus den folgenden Datensätzen: Verordnungsdatensatz, PKV-Abgabedatensatz und Quittungsdatensatz.

Der Verordnungsdatensatz wird durch den Arzt/Zahnarzt erstellt, mit einer Qualifizierten Elektronischen Signatur (QES) versehen und auf dem E-Rezept-Fachdienst eingestellt. Für den Abrechnungsprozess wird der Verordnungsdatensatz ohne QES übermittelt, um das Risiko vom Mehrfacheinlösungen zu vermeiden. Statt der QES wird der Verordnungsdatensatz durch den E-Rezept-Fachdienst fortgeschritten signiert, um die Integrität des Datensatzes für den Abrechnungsprozess sicherzustellen.

Der PKV-Abgabedatensatz wird durch die Apotheke erstellt. Er enthält, sofern in der Apotheke Änderungen bei der Abgabe vorgenommen werden, den QES-signierten PKV-Abgabedatensatz und sofern in der Apotheke keine Änderungen erfolgen, den fortgeschritten signierten PKV-Abgabedatensatz. Das Informationsmodell zum PKV-Abgabedatensatz wird durch den Verband der PKVen und DAV erarbeitet. 

Die Quittung wird durch den E-Rezept-Fachdienst erstellt und fortgeschritten signiert. Sie dient dem Versicherten bei der Abrechnung gegenüber dem Kostenträger als Nachweis, dass ein Arzneimittel auf ein E-Rezept einmalig über die TI abgegeben worden ist.

Der PKV-Versicherte hat die Möglichkeit, die Abrechnung in einem Zeitraum von bis zu 10 Jahren bei seiner Krankenversicherung vorzunehmen. Daher werden die Abrechnungsinformationen so lange für den Versicherten im E-Rezept-Fachdienst vorgehalten, bevor sie automatisch gelöscht werden (Rechtliche Grundlage § 360 Abs. 13 SGB V). Der PKV-Versicherte hat die Möglichkeit, sie vorab, beispielsweise wenn die Abrechnung abgeschlossen wurde, zu löschen.

Die Löschfristen für das E-Rezept mit den in Beziehung stehenden Daten, wie Dispensierinformationen und Kommunikationen zum E-Rezept, werden unabhängig von der zugehörigen Abrechnungsinformation durchgesetzt. Siehe [gemSysL_eRp#A_18525].

Eine Langzeitarchivierung der Abrechnungsinformation im E-Rezept-Fachdienst ist nicht vorgesehen. Hierfür kann der Versicherte beispielsweise die elektronische Patientenakte (ePA) nutzen.

Der PKV-Versicherte kann über die E-Rezept App die Abrechnungsinformation digital an seine PKV schicken, um die Erstattung zu beantragen. Der Export in Form eines PDFs ermöglicht hierbei verschiedene Kanäle zur Übermittlung (wie E-Mail, Webportal, App des Kostenträgers).

5 Technisches Konzept

Für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für PKV-Versicherte wird der Workflow-Typ "200" eingeführt. Für den Workflow von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel mit Steuerung durch Leistungserbringer wird der Workflow-Typ "209" eingeführt.

Im Workflow-Typ "200"  und Workflow-Typ "209" werden dasselbe Informationsmodell für den Verordnungsdatensatz (siehe https://simplifier.net/erezept ) wie bei der Verordnung für GKV-Versicherte verwendet.
Hinweis: In MedicationRequest.insurance.Coverage.type mit dem Codesystem Coverage.type.coding in https://fhir.kbv.de/StructureDefinition/KBV_PR_FOR_Coverage ist erkennbar, ob der Versicherte, für den das E-Rezept erstellt wurde, bei einer PKV versichert ist.

Der Ablauf im Workflow-Typ "200" ist identisch zum Workflow-Typ "160". Der Ablauf im Workflow-Typ "209" ist identisch zum Workflow-Typ "169". 

Der Workflow-Typ "200" und der Workflow-Typ "209" verwenden dasselbe Statusmodell, wie der Workflow-Typ "160". Siehe [gemSysL_eRp#2.4.6 Konzept Status E-Rezept].

Für E-Rezepte der Workflow-Types "200" und "209" können die Abrechnungsinformationen über den E-Rezept-Fachdienst an den Versicherten übermittelt werden.

5.1 Identifikation von PKV-Versicherten

Die Zuordnung eines E-Rezeptes zu einem Versicherten erfolgt auf Basis der Versicherten-ID (10-stelliger unveränderlicher Teil der Krankenversichertennummer (KVNR)). D.h. teilnehmende PKV-Versicherte benötigen eine KVNR, welche ihnen über ihre Krankenversicherung zugeordnet wird. An der Versicherten-ID kann nicht erkannt werden, ob der Versicherte bei einer PKV versichert ist.

Die Authentisierung des Nutzers am E-Rezept-Fachdienst erfolgt mittels eines ACCESS_TOKEN. Diese werden durch Identity Provider (IdP) ausgestellt, welche die Identität des Nutzers attestieren. Es werden ACCESS_TOKEN von IdPs akzeptiert, bei denen der E-Rezept-Fachdienst sich registriert hat.

Mit dem Start der Anwendung E-Rezept kann der IdP der gematik genutzt werden. Für die Authentisierung eines Versicherten am IdP der gematik mittels E-Rezept-FdV wird eine eGK mit NFC-Schnittstelle verwendet.

Mit der Entwicklung von digitalen Identitäten, bspw. föderierter IdPs, werden diese für die Authentisierung einbezogen.

5.2 Use Cases im Rahmen der Verordnung

Die Prozesse des verordnenden Leistungserbringers, welche für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für GKV-Versicherte konzipiert wurden, werden ebenso für die Verordnung von apothekenpflichtige Arzneimittel für PKV-Versicherte genutzt.

Folgende Anwendungsfälle werden genutzt:

  • UC 2.1 - E-Rezepte erzeugen
  • UC 2.3 - E-Rezept einstellen
  • UC 2.5 - E-Rezept durch Verordnenden löschen

Für Details zu den Anwendungsfällen siehe [gemSysL_eRp].

5.3 Use Cases im Rahmen der Belieferung durch eine Apotheke

Die Prozesse der abgebenden Leistungserbringerinstitution für das Abrufen, das Zurückweisen, das Löschen des E-Rezeptes, das Abrufen der Quittung und die Kommunikation mit dem Versicherten, welche für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für GKV-Versicherte konzipiert wurden, werden ebenso für die Verordnung von apothekenpflichtige Arzneimittel für PKV-Versicherte genutzt.

Folgende Anwendungsfälle werden genutzt:

  • UC 4.1 - E-Rezept durch Abgebenden abrufen
  • UC 4.2 - E-Rezept durch Abgebenden zurückgeben
  • UC 4.3 - E-Rezept durch Abgebenden löschen
  • UC 4.4 - Quittung abrufen
  • UC 4.5 - Abgabedatensatz durch Abgebenden signieren
  • UC 4.8 - Quittung erneut abrufen
  • UC 4.6 - Nachrichten durch Abgebenden empfangen
  • UC 4.7 - Nachricht durch Abgebenden übermitteln
  • UC 4.9 - Nachricht durch Abgebenden löschen

Beim Abruf des E-Rezepts vom E-Rezept-Fachdienstes (UC 4.1) wird die Information übermittelt, ob der Versicherte eine Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt hat.

Für Details zu den Anwendungsfällen siehe [gemSysL_eRp].

Folgende zusätzliche Anwendungsfälle werden für das Bereitstellen und Verwalten der Abrechnungsinformation genutzt.

5.3.1 Abrechnungsinformation durch Abgebenden bereitstellen

Mit der Belieferung des E-Rezeptes benötigt der Versicherte die Abrechnungsinformation, um ggf. das E-Rezept bei Kostenträgern abzurechnen. Der Versicherte entscheidet, ob die Abrechnungsinformation digital oder papierbasiert bereitgestellt werden soll. Falls der Versicherte eine Einwilligung zum Speichern der Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt hat und die digitale Übermittlung gewünscht wird, dann übermittelt die Apotheke mit diesem Anwendungsfall einen PKV-Abgabedatensatz an den E-Rezept-Fachdienst und stellt somit einen Teil der Daten der Abrechnungsinformation zur Verfügung.

Die erstmalige digitale Bereitstellung der Abrechnungsinformation durch die abgebende LEI muss vor dem Löschen des E-Rezepts auf dem E-Rezept-Fachdienst erfolgen, da für diese Bereitstellung der Abrechnungsinformation die Daten des Verordnungsdatensatzes und der Quittung aus dem Workflow in die Abrechnungsinformation übernommen werden. Spätestens 100 Tagen nach dem Statuswechsel zu "quittiert" wird das E-Rezept vom E-Rezept-Fachdienst gelöscht und ein Bereitstellen der Abrechnungsinformation ist nicht mehr möglich.

Mit dem Bereitstellen der Abrechnungsinformation erzeugt der E-Rezept-Fachdienst den AccessCode zum Ändern. Der AccessCode ist ein Wert mit hoher Entropie. Es kann durch den Versicherten an den Apotheker übermittelt werden, falls der Versicherte eine Korrektur des PKV-Abgabedatensatzes durch die Apotheke wünscht.

AF_10082 - E-Rezept - Abrechnungsinformation durch Abgebenden bereitstellen

Alle am Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen. 

Tabelle 1 : Abrechnungsinformation durch Abgebenden bereitstellen

Name Abrechnungsinformation durch Abgebenden bereitstellen 
Vorbedingungen
  • Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.4 - Quittung abrufen" durchgeführt.
  • Die Task-ID und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" des E-Rezepts sind im PS bekannt.
  • Das E-Rezept im E-Rezept-Fachdienst hat den Status "quittiert".
  • Der Versicherte hat im E-Rezept-FdV eine Einwilligung zum Speichern der Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt. Diese Information liegt im PS vor.
Kurzbeschreibung
(Außenansicht)		 Ein Mitarbeiter der abgebenden LEI hat mit dem Versicherten abgestimmt, dass die Abrechnungsinformation digital zur Verfügung gestellt werden soll.
Das PS erstellt den PKV-Abgabedatensatz und signiert diesen mit dem Konnektor.
Das PS erstellt eine ChargeItem-Ressource mit einem Identifier aus der PrescriptionID und den übrigen Pflichtfeldern gemäß FHIR-Profil und übermittelt diese an den E-Rezept-Fachdienstes zusammen mit dem generierten Geheimnis des belieferten Tasks zum Zeitpunkt des Statuswechsels "in Abgabe (gesperrt)" und den signierten Abgabedaten.
Der E-Rezept-Fachdienst prüft, ob eine Einwilligung zum Speichern der Abrechnungsinformationen vorliegt.  Falls die Einwilligung vorliegt, übernimmt der E-Rezept-Fachdienst  den Verordnungsdatensatz und die Quittung aus dem E-Rezept-Workflow und speichert diese als Teil der Abrechnungsinformation zusammen mit dem "ChargeItem". Identifier der ChargeItem-Ressource ist die Rezept-ID. 
Der E-Rezept-Fachdienst prüft die Signatur und die FHIR-Validität des PKV-Abgabedatensatzes.
Der E-Rezept-Fachdienst erzeugt einen AccessCode zum Ändern.
Der Status des E-Rezept-Tasks ändert sich nicht.
Nachbedingungen Die Abrechnungsinformation ist im E-Rezept-Fachdienst gespeichert.
Das Einstellen der Abrechnungsinformation ist im E-Rezept-Fachdienst protokolliert.
Alternative (für Abrechnungs-information) Wenn der Versicherte die Abrechnungsinformation nicht in digitaler Form, sondern in Papierform möchte, dann stellt der Mitarbeiter der abgebenden LEI die Unterlagen zusammen und übergibt sie dem Versicherten.
Die Operation am E-Rezept-Fachdienst wird nicht aufgerufen.
Hinweis: Zum Inhalt und Layout des Papierausdrucks werden Regelungen durch DAV und dem Verband der PKVen getroffen.

Abbildung 3 : SD Abrechnungsinformation durch Abgebenden bereitstellen

[<=]

5.3.2 Abrechnungsinformation abrufen

Es kann die Notwendigkeit bestehen, dass der Versicherte seine Apotheke um eine Änderung des PKV-Abgabedatensatzes bittet, bspw. weil der Kostenträger einen formalen Fehler festgestellt hat und für die Abrechnung eine Korrektur benötigt. Dazu übermittelt der Versicherte der abgebenden LEI den AccessCode zum Ändern, mittels einer Nachricht über das E-Rezept-FdV oder durch Anzeige zum Abscannen im E-Rezept-FdV. Mit diesem Anwendungsfall kann eine Apotheke eine zuvor durch sie bereitgestellte Abrechnungsinformation vom E-Rezept-Fachdienst abrufen, wenn die Daten nicht mehr im Primärsystem vorliegen und der AccessCode zum Ändern bekannt ist.

AF_10081 - E-Rezept - Abrechnungsinformation durch Abgebenden abrufen

Alle am Anwendungsfall "Abrechnungsinformation durch Abgebenden abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen. 

Tabelle 2 : Abrechnungsinformation durch Abgebenden abrufen

Name Abrechnungsinformation durch Abgebenden abrufen
Vorbedingungen
  • Die Rezept-ID und der AccessCode zum Ändern der Abrechnungsinformation sind im PS bekannt.
Kurzbeschreibung
(Außenansicht)		 Das PS übermittelt beim Aufruf an den E-Rezept-Fachdienst die Rezept-ID und den AccessCode zum Ändern.
Der E-Rezept-Fachdienst prüft den AccessCode zum Ändern.
Der E-Rezept-Fachdienst prüft, ob die Abrechnungsinformation initial durch die LEI eingestellt wurde.
Der E-Rezept-Fachdienst übermittelt den PKV-Abgabedatensatz und den Verordnungsdatensatz an die Apotheke.
Nachbedingungen Der PKV-Abgabedatensatz und der Verordnungsdatensatz liegen im PS vor, um Änderungen am PKV-Abgabedatensatz zu ermöglichen.
Der Datenzugriff ist im E-Rezept-Fachdienst protokolliert.

Abbildung 4 :SD Abrechnungsinformation durch Abgebenden abrufen

[<=]

5.3.3 PKV-Abgabedatensatz ändern

Mit diesem Anwendungsfall kann die abgebende LEI, welche initial die Abrechnungsinformation auf dem E-Rezept-Fachdienst bereitgestellt hat, auf Wunsch des Versicherten den PKV-Abgabedatensatz ändern, falls diese korrigiert werden soll. Dazu übermittelt der Versicherte der abgebenden LEI den AccessCode zum Ändern, mittels einer Nachricht über das E-Rezept-FdV oder durch Anzeige zum Abscannen im E-Rezept-FdV.

Der zuvor im E-Rezept-Fachdienst gespeicherte PKV-Abgabedatensatz wird überschrieben. Es werden keine älteren Versionen im E-Rezept-Fachdienst gespeichert.

AF_10083 - E-Rezept - PKV-Abgabedatensatz durch Abgebenden ändern

Alle am Anwendungsfall "PKV-Abgabedatensatz durch Abgebenden ändern" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen. 

Tabelle 3 : PKV-Abgabedatensatz durch Abgebenden ändern

Name PKV-Abgabedatensatz durch Abgebenden ändern
Vorbedingungen
  • Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" durchgeführt.
  • Die Rezept-ID der Abrechnungsinformation und der AccessCode zum Ändern sind im PS bekannt.
Kurzbeschreibung
(Außenansicht)		 Ein Mitarbeiter der abgebenden LEI erstellt mit dem Primärsystem einen neuen PKV-Abgabedatensatz.
Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID, den AccessCode zum Ändern und den PKV-Abgabedatensatz.
Der E-Rezept-Fachdienst prüft den AccessCode zum Ändern.
Der E-Rezept-Fachdienst prüft, dass die Abgabeinformation initial durch die LEI eingestellt wurde.
Der E-Rezept-Fachdienst prüft die Signatur und die FHIR-Validität des PKV-Abgabedatensatzes.
Der E-Rezept-Fachdienst überschreibt den PKV-Abgabedatensatz. 
Der E-Rezept-Fachdienst erzeugt einen neuen AccessCode zum Ändern und überschreibt den alten AccessCode zum Ändern.
Nachbedingungen Das Ändern des PKV-Abgabedatensatzes ist im E-Rezept-Fachdienst protokolliert.

Abbildung 5 : SD PKV-Abgabedatensatz durch Abgebenden ändern

[<=]

5.4 Use Cases zur E-Rezept-Verwaltung durch PKV-Versicherte

Die Prozesse des Versicherten für die Einsichtnahme in die E-Rezepte, das Zuweisen der E-Rezepte an abgebende Leistungserbringerinstitutionen und die Kommunikation mit abgebenden Leistungserbringerinstitutionen, welche für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel für GKV-Versicherte konzipiert wurden, werden ebenso für die Verordnung von apothekenpflichtige Arzneimittel für PKV-Versicherte genutzt.

Folgende Anwendungsfälle werden genutzt:

  • UC 3.1 - E-Rezepte durch Versicherten abrufen
  • UC 3.6 - E-Rezept durch Vertreter abrufen
  • UC 3.2 - E-Rezept durch Versicherten löschen 
  • UC 3.3 - Nachricht durch Versicherten übermitteln
  • UC 3.4 - Nachrichten durch Versicherten empfangen
  • UC 3.8 - Nachricht durch Versicherten löschen
  • UC 3.5 - Protokolldaten abrufen

Für Details zu den Anwendungsfällen siehe [gemSysL_eRp].

Die im Folgenden beschriebenen Anwendungsfälle ergeben sich für PKV-Versicherte zusätzlich im Rahmen der Abrechnung der E-Rezepte.

Die folgenden Anwendungsfälle kann der Versicherte neben dem E-Rezept-FdV auch in der Anwendung für die Wahrnehmung der Rechte der informationellen Selbstbestimmung (E-Rezept-AdV) ausführen:

  • Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen
  • Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen
  • Abrechnungsinformation durch den Versicherten abrufen
  • Abrechnungsinformation durch den Versicherten löschen

In der Rolle Vertreter kann ein Versicherter keine der Anwendungsfälle im Rahmen der Abrechnung der E-Rezepte durchführen.

5.4.1 Einwilligung zum Speichern der Abrechnungsinformationen durch den Versicherten erteilen

Mit diesem Anwendungsfall kann der Versicherte seine Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilen.

Die Einwilligung wird unbefristet erteilt.

AF_10084 - E-Rezept - Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen

Alle am Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen. 

Tabelle 4 : Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen

Name Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen
Vorbedingungen
  • Im FdV (E-Rezept-FdV) liegt die Information vor, dass der Nutzer ein PKV-Versicherter ist.
Kurzbeschreibung
(Außenansicht)		 Ein Versicherter wählt im FdV (E-Rezept-FdV) die Operation zum Erteilen der Einwilligung zum Speichern der Abrechnungsinformationen auf.
Der E-Rezept-Fachdienst speichert die Einwilligung.
Nachbedingungen Die Einwilligung zum Speichern der Abrechnungsinformationen ist im E-Rezept-Fachdienst gespeichert. Das Erteilen ist im E-Rezept-Fachdienst protokolliert.

Abbildung 6 : SD Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen

[<=]

5.4.2 Einwilligung zum Speichern der Abrechnungsinformationen durch den Versicherten widerrufen

Mit diesem Anwendungsfall kann der Versicherte seine zuvor erteilte Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst widerrufen. Mit dem Widerruf der Einwilligung werden bereits gespeicherte Abrechnungsinformationen gelöscht.

AF_10085 - E-Rezept - Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen

Alle am Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 5 : Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen

Name Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen
Vorbedingungen
  • Im FdV (E-Rezept-FdV, E-Rezept-AdV) liegt die Information vor, dass eine Einwilligung erteilt wurde.
Kurzbeschreibung
(Außenansicht)		 Ein Versicherter wählt über ein FdV (E-Rezept-FdV, E-Rezept-AdV) die Operation zum Widerrufen der Einwilligung zum Speichern der Abrechnungsinformationen auf.
Der E-Rezept-Fachdienst prüft, ob zuvor eine Einwilligung erteilt wurde und löscht diese. Der E-Rezept-Fachdienst löscht alle zuvor gespeicherten Abrechnungsinformationen unwiederbringlich.
Nachbedingungen Das Widerrufen der Einwilligung ist im E-Rezept-Fachdienst protokolliert. Das Löschen der Abrechnungsinformationen ist im E-Rezept-Fachdienst protokolliert.

Abbildung 7 : SD Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen

[<=]

5.4.3 Einwilligung zum Speichern der Abrechnungsinformationen einsehen

Mit diesem Anwendungsfall kann der Versicherte einsehen, ob auf dem E-Rezept-Fachdienst eine Einwilligung zum Speichern der Abrechnungsinformationen hinterlegt ist.

AF_10086 - E-Rezept - Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen

Alle am Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 6 : Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen

Name Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen
Vorbedingungen
  • keine
Kurzbeschreibung
(Außenansicht)		 Das FdV (E-Rezept-FdV, E-Rezept-AdV) führt die Operation zum Abfrage der Einwilligung zum Speichern der Abrechnungsinformationen auf.
Der E-Rezept-Fachdienst gibt die Information an das FdV.
Nachbedingungen Die Information steht zur Anzeige im FdV bereit.

Abbildung 8 : SD Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen

[<=]

5.4.4 Abrufen der Abrechnungsinformationen durch den Versicherten

Mit diesem Anwendungsfall kann der Versicherte die zuvor durch Apotheken im E-Rezept-Fachdienst gespeicherten Abrechnungsinformationen vom E-Rezept-Fachdienst abrufen.

AF_10087 - E-Rezept - Abrechnungsinformationen durch den Versicherten abrufen

Alle am Anwendungsfall "Abrechnungsinformationen durch den Versicherten abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 7 : Abrechnungsinformationen durch den Versicherten abrufen

Name Abrechnungsinformationen durch den Versicherten abrufen
Vorbedingungen
  • Der Versicherte hat eine Einwilligung zum Speichern der Abrechnungsinformationen erteilt.
  • Eine oder mehrere abgebende LEI hat den Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" für E-Rezepte durchgeführt. Die Abrechnungsinformationen sind auf dem E-Rezept-Fachdienst gespeichert.
Kurzbeschreibung
(Außenansicht)		 Ein Versicherter ruft über ein FdV (E-Rezept-FdV, E-Rezept-AdV) eine Liste seine im E-Rezept-Fachdienst eingestellten Abrechnungsinformationen ab.
Der E-Rezept-Fachdienst identifiziert die Abrechnungsinformationen auf Basis der Versicherten-ID des Versicherten und liefert diese an das FdV.
Das FdV ruft die Details der Abrechnungsinformation ab
Der E-Rezept-Fachdienst signiert beim Detailabruf die Datensätze der Abrechnungsinformationen.
Nachbedingungen Die Abrechnungsinformationen stehen zur Anzeige im FdV und für den Export bereit.
Der Abruf ist im E-Rezept-Fachdienst protokolliert.

Abbildung 9 : SD Abrechnungsinformation durch den Versicherten abrufen

[<=]

5.4.5 Weitergeben der Abrechnungsinformation durch den Versicherten

Mit diesem Anwendungsfall kann der Versicherte die zuvor vom E-Rezept-Fachdienst abgerufene Abrechnungsinformation aus dem E-Rezept-FdV heraus mit einer anderen App teilen, um so die Abrechnungsinformation bspw. der PKV oder Beihilfe zur Abrechnung zu übermitteln.

AF_10088 - E-Rezept - Abrechnungsinformation durch den Versicherten weitergeben

Alle am Anwendungsfall "Abrechnungsinformation durch den Versicherten weitergeben" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 8 : Weitergeben der Abrechnungsinformation durch den Versicherten

Name Abrechnungsinformation durch den Versicherten weitergeben
Vorbedingungen
  • Der Versicherte hat über das FdV (E-Rezept-FdV) die Abrechnungsinformation vom E-Rezept-Fachdienst abgerufen.
Kurzbeschreibung
(Außenansicht)		 Der Versicherte wählt die Abrechnungsinformation zum Weitergeben aus und wählt die Teilen Funktion. Das FdV erstellt ein PDF/A und bettet die Abrechnungsinformation in das PDF ein.
Nachbedingungen Die Abrechnungsinformation ist in der Ziel-App übertragen.
Alternativen
  • Download des PDF ins Dateisystem, mit der Möglichkeit es nachfolgend in ein Portal hochzuladen
  • Versand des PDF mit E-Mail
  • etc.

Abbildung 10 : SD Abrechnungsinformation durch den Versicherten weitergeben

[<=]

5.4.6 Markieren der Abrechnungsinformation durch den Versicherten

Mit diesem Anwendungsfall kann der Versicherte die zuvor durch eine Apotheke im E-Rezept-Fachdienst gespeicherte Abrechnungsinformation auf dem E-Rezept-Fachdienst markieren.

Eine oder mehrere der folgenden Markierungen sind möglich:

  • zur Abrechnung bei Krankenversicherung eingereicht
  • zur Abrechnung bei der Beihilfe eingereicht
  • zur Einreichung beim Finanzamt verwendet

Der Anwendungsfall wird ebenfalls dafür genutzt, eine Markierung zu löschen.

AF_10089 - E-Rezept - Abrechnungsinformation durch den Versicherten markieren

Alle am Anwendungsfall "Abrechnungsinformation durch den Versicherten markieren" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 9 : Abrechnungsinformation durch den Versicherten markieren

Name Abrechnungsinformation durch den Versicherten markieren 
Vorbedingungen
  • Eine LEI hat den Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" für das E-Rezept durchgeführt. Die Abrechnungsinformation ist auf dem E-Rezept-Fachdienst gespeichert.
  • Der Versicherte hat sich über den Anwendungsfall "Abrufen der Abrechnungsinformation durch den Versicherten" die zu markierende Abrechnungsinformation herausgesucht.
Kurzbeschreibung
(Außenansicht)		 Ein Versicherter wählt im FdV (E-Rezept-FdV) die zu markierende Abrechnungsinformation sowie die zu Optionen für die Markierung aus.
Der E-Rezept-Fachdienst speichert die Information.
Nachbedingungen Die Information zur Markierung ist im E-Rezept-Fachdienst gespeichert. Der Datenzugriff ist im E-Rezept-Fachdienst protokolliert.

Abbildung 11 : SD Abrechnungsinformation durch den Versicherten markieren

[<=]

5.4.7 Löschen der Abrechnungsinformation durch den Versicherten

Mit diesem Anwendungsfall kann der Versicherte eine zuvor durch eine Apotheke im E-Rezept-Fachdienst gespeicherte Abrechnungsinformation vom E-Rezept-Fachdienst löschen. Das Löschen erfolgt unwiederbringlich.

AF_10090 - E-Rezept - Abrechnungsinformation durch den Versicherten löschen

Alle am Anwendungsfall "Abrechnungsinformation durch den Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 10 : Abrechnungsinformation durch den Versicherten löschen

Name Abrechnungsinformation durch den Versicherten löschen
Vorbedingungen
  • Eine LEI hat den Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" für das E-Rezept durchgeführt
  • Der Versicherte hat sich über den Anwendungsfall "Abrufen der Abrechnungsinformation durch den Versicherten" die Abrechnungsinformation auf sein FdV heruntergeladen.
Kurzbeschreibung
(Außenansicht)		 Ein Versicherter wählt im FdV (E-Rezept-FdV, E-Rezept-AdV) die zu löschende Abrechnungsinformation aus und bestätigt das Löschen. Das FdV überträgt den Lösch-Request.
Der E-Rezept-Fachdienst löscht die Abrechnungsinformation.
Nachbedingungen Die Abrechnungsinformation sind auf dem E-Rezept-Fachdienst gelöscht.
Das Löschen ist im E-Rezept-Fachdienst protokolliert.

Abbildung 12 : SD Abrechnungsinformation durch den Versicherten löschen

[<=]

5.4.8 Berechtigen der Apotheke zum Ändern des PKV-Abgabedatensatzes

Mit diesem Anwendungsfall kann ein Versicherter einen AccessCode zum Ändern des PKV-Abgabedatensatzes an die Apotheke übermitteln, um die Apotheke zum Abruf und Ändern zu autorisieren. Als Alternative steht die optische Übermittlung des AccessCodes als 2D-Code zur Verfügung. 

Die Übermittlung erfolgt gemäß dem Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln".

5.5 Abrechnung durch die Kostenträger

Die Abrechnungsinformation besteht aus den drei signierten Datensätzen:

  • E-Rezept (Verordnungsdatensatz)
  • PKV-Abgabedatensatz
  • Quittung des E-Rezept-Fachdienstes

Der E-Rezept-Fachdienst prüft die Gültigkeit der QES des Verordnungsdatensatzes beim Einstellen des E-Rezeptes durch die verordnenden LEI.

Der E-Rezept-Fachdienst prüft die Gültigkeit der QES bzw. nonQES Signatur des PKV-Abgabedatensatzes beim Bereitstellen der Abrechnungsinformation durch die abgebende LEI.

Die Datensätze werden nach erfolgreicher Prüfung mit Signatur im E-Rezept-Fachdienst gespeichert. Wenn der Versicherte die Abrechnungsinformation abruft, dann signiert der E-Rezept-Fachdienst die Datensätze mit seinem Signaturzertifikat (C.FD.OSIG). Das Signaturzertifikat hat eine Gültigkeit von maximal 5 Jahren, in denen der Sperrstatus des Zertifikates ermittelt werden kann. Das Signaturzertifikat wird jährlich erneuert, sodass der Sperrstatus noch mindestens 4 Jahre nach dem Abruf ermittelt werden kann.

Tabelle 11 : Signaturen der Abrechnungsinformation

Datensatz Datenformat Signaturzertifikat Signaturformat Zeitpunkt der Signatur
Verordnungsdatensatz XML Signaturzertifikat (C.FD.OSIG) des E-Rezept-Fachdienstes CAdES enveloping PKCS#7 Abruf durch den Versicherten
PKV-Abgabedatensatz XML Signaturzertifikat (C.FD.OSIG) des E-Rezept-Fachdienstes  CAdES enveloping PKCS#7 Abruf durch den Versicherten 
Quittung XML Signaturzertifikat (C.FD.OSIG) des E-Rezept-Fachdienstes CAdES enveloping PKCS#7 Abruf durch den Versicherten

Die Datensätze kann der Versicherte über eine Schnittstelle aus dem E-Rezept-FdV in eine App eines Kostenträgers übermitteln. Hierzu wird ein PDF zur Abrechnung erstellt und die drei Datensätze in das PDF eingebettet.

Jeder der drei Datensätze enthält die über mehr als 10 Jahre eindeutige E-Rezept-ID. Über diese E-Rezept-ID lassen sich die Datensätze einander zuordnen.

Im Rahmen der Abrechnung können die Signaturen der Datensätze geprüft werden.

Hierzu ist das Ergebnis der Online-Prüfung des Signaturzertifikates des E-Rezept-Fachdienstes zum Zeitpunkt der Signaturerstellung in die Signatur der Datensätze eingebettet.

6 Spezifikation

Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die verschiedenen Produkt- und Anbietertypen. In den jeweiligen Produkt- und Anbietertypsteckbriefen sind zu den Anforderungen ("Blattanforderungen") die jeweiligen Prüfverfahren angegeben.

Dargestellt sind die zusätzlichen Anforderungen an die Produkttypen des E-Rezepts, die bestehende Anforderungslage für bereits eingeführte Workflow-Typen, wie bspw. den Prozess der apothekenpflichtigen Arzneimittel (Flowtype=160) bleibt hiervon unberührt.

6.1 Anforderungen an den E-Rezept-Fachdienst

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

6.1.1 Löschfristen

Das Kapitel 5.6 aus [gemSpec_FD_eRp] wird erweitert.

Für die Löschfristen des E-Rezepts gelten für Flowtype 200 und 209 die Vorgaben von Flowtype 160 gemäß A_19252.

A_22109 - E-Rezept-Fachdienst – Löschfrist ChargeItem

Der E-Rezept-Fachdienst MUSS ein ChargeItem innerhalb eines Monats nach Ablauf von 10 Jahren nach dem Erstellen der Ressource  automatisch löschen und das Löschen in einem AuditEvent für den Versicherten nachvollziehbar protokollieren, damit nicht mehr benötigte Informationen gelöscht sind.
Der E-Rezept-Fachdienst MUSS bei jedem Löschen eines ChargeItems alle referenzierten Bundles (E-Rezept-Bundle, Quittungs-Bundle, PKV-Abgabedatensatz) ebenfalls löschen, damit die Informationen rund um ein gelöschtes ChargeItem ebenfalls entfernt werden. [<=]

6.1.2 Protokollierung

Das Kapitel 5.5 aus [gemSpec_FD_eRp] wird erweitert.

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

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

Tabelle 12: TAB_eRPFD_004 Versichertenprotokoll

Operation Rolle des
zugreifenden Nutzers		 Beschreibung (ggfs. 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 POST /Task
$activate Arzt-/Zahnarztpraxis/Krankenhaus Arzt-/Zahnarztpraxis/Krankenhaus hat das E-Rezept bereitgestellt
$accept Apotheke Apotheke hat das E-Rezept heruntergeladen
$reject Apotheke Apotheke hat das E-Rezept zurückgegeben
$close Apotheke Apotheke hat das E-Rezept beliefert
$abort Versicherter,
Vertreter		 Patient/Versicherter/Vertreter hat das E-Rezept gelöscht
Arzt-/Zahnarztpraxis/Krankenhaus Arzt-/Zahnarztpraxis/Krankenhaus hat das E-Rezept gelöscht
Apotheke Apotheke hat das E-Rezept gelöscht
http GET /MedicationDispense/<id> bzw. Zugriff via Suchparameter 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 erteilt
http DELETE /Consent Versicherter Versicherter hat Einwilligung widerrufen
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 ggfs. intervenieren. [<=]

6.1.3 Ressource Task

6.1.3.1 HTTP-Operation POST
6.1.3.1.1 POST /Task/<id>/$accept

Das Kapitel 6.1.2.3 aus [gemSpec_FD_eRp] wird erweitert.

Für die Flowtypes 200 und 209 werden der abgebenden LEI im Task die Information übermittelt, ob der Versicherte eine Einwilligung zum Speichern von Abrechnungsinformationen im E-Rezept-Fachdienst erteilt hat. 

A_22110 - E-Rezept-Fachdienst – Task akzeptieren – Flowtype 200/209 - Einwilligung ermitteln

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task des Flowtype Task.extension:flowType = 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$accept, wenn für die KVNR des begünstigten Versicherten (Task.for)  eine Consent Ressource mit Consent.patient.identifier = KVNR und Consent.category.coding.code = "CHARGCONS" existiert, das Response Bundle um die Consent Ressource ergänzen, um der abgebenden LEI die Information zu übermitteln, ob der Versicherte eine Einwilligung zum Speichern der Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt hat. [<=]

6.1.3.1.2 POST /Task/<id>/$activate

Das Kapitel 6.1.2.2 aus [gemSpec_FD_eRp] wird erweitert.

Für den Flowtype 200 und 209 wird geprüft, dass im Verordnungsdatensatz für Coverage.type.coding.code der Wert "PKV" gesetzt ist.

A_22347-01 - E-Rezept-Fachdienst – Task aktivieren – Flowtype 200/209 - Prüfung Coverage Type

Der E-Rezept-Fachdienst MUSS beim Zugriff auf einen Task des Flowtype Task.extension:flowType = 200 oder 209 mittels HTTP-POST-Operation über /Task/<id>/$activate prüfen, ob Coverage.type.coding.code mit dem Wert "PKV" belegt ist und im Fehlerfall die Operation mit Http-Fehlercode 400 abbrechen, um sicherzustellen, dass diese Workflows nur für E-Rezepte für PKV-Versicherte genutzt werden. [<=]

6.1.4 Ressource ChargeItem

A_22111 - E-Rezept-Fachdienst – ChargeItem - unzulässige Operationen

Der E-Rezept-Fachdienst MUSS alle Zugriffe auf die Ressource ChargeItem mittels der HTTP-Operationen HEAD unterbinden, damit keine unzulässigen Operationen auf die Informationen zu Abrechnungsinformationen ausgeführt werden können. [<=]

6.1.4.1 HTTP-Operation DELETE

Die FHIR-Operation führt zum Löschen der unter <Prescription-ID> gespeicherten Abrechnungsinformation. Diese Operation steht dem Versicherten, für den das E-Rezept erstellt wurde, zur Verfügung.

A_22112 - E-Rezept-Fachdienst – Abrechnungsinformation löschen - alles Löschen verbieten

Der E-Rezept-Fachdienst MUSS den Aufruf der Operation DELETE /ChargeItem ohne Angabe einer konkreten über <id> adressierte  ChargeItem Ressource  mit dem HTTP-Fehlercode 405 ablehnen, um das Löschen mehrerer Ressourcen über einen Request zu verhindern.  [<=]

A_22113 - E-Rezept-Fachdienst – Abrechnungsinformation löschen - Rollenprüfung

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-DELETE-Operation auf eine konkrete über <id> adressierte  /ChargeItem/<id> Ressource  sicherstellen, dass ausschließlich Nutzer in der Rolle 

  • oid_versicherter
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit eine Abrechnungsinformation nicht durch Unberechtigte gelöscht werden können. [<=]

A_22114 - E-Rezept-Fachdienst – Abrechnungsinformation löschen – Prüfung KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-DELETE-Operation auf eine konkrete über <id> adressierte/ChargeItem/<id> Ressource durch einen Versicherten, den Versicherten anhand der KVNR aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren, diese gegen die in "ChargeItem.subject.identifier" hinterlegte KVNR des begünstigten Versicherten prüfen und bei Ungleichheit den Aufruf mit dem HTTP-Fehlercode 403 abweisen, damit ausschließlich der begünstigte Versicherte als Berechtigter eine Abrechnungsinformation löscht. [<=]

A_22117 - E-Rezept-Fachdienst - Abrechnungsinformation löschen - zu löschende Ressourcen

Der E-Rezept-Fachdienst MUSS beim Löschen einer ChargeItem-Ressource auch die in ChargeItem.supportingInformation referenzierten Ressource des Verordnungsdatensatzes, des PKV-Abgabedatensatzes und der Quittung löschen. [<=]

6.1.4.2 HTTP-Operation GET
6.1.4.2.1 GET /ChargeItem

Mit dieser Operation kann eine Liste von ChargeItem-IDs abgefragt werden, für deren Zugriff der Anfragende berechtigt ist.

A_22118 - E-Rezept-Fachdienst – Abrechnungsinformationen abrufen - Rollenprüfung Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /ChargeItem sicherstellen, dass ausschließlich Nutzer in der Rolle

  • oid_versicherter
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit E-Rezepte nicht durch Unberechtigte ausgelesen werden können. [<=]

A_22119 - E-Rezept-Fachdienst – Abrechnungsinformationen abrufen – Versicherter – Filter KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /ChargeItem durch einen Versicherten, den Versicherten anhand der KVNR aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren und die ChargeItems danach filtern, damit der Versicherte nur Abrechnungsinformationen abruft, bei denen er der Begünstigte ist. [<=]

A_22121 - E-Rezept-Fachdienst – Abrechnungsinformationen abrufen - Suchkriterien

Der E-Rezept-Fachdienst MUSS das Eingrenzen einer Suchanfrage auf /ChargeItem über die URL-Parameter gemäß https://www.hl7.org/fhir/chargeitem.html#search  mindestens für die Attribute

  • ChargeItem.enteredDate
  • ChargeItem.meta.__lastUpdated
erlauben, damit Versicherte und Apotheken eine Suche nach neuen Abrechnungsinformation Einträgen durchführen können. [<=]

A_22122 - E-Rezept-Fachdienst – Abrechnungsinformationen abrufen– Response

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /ChargeItem eine Liste von ChargeItem Ressourcen ohne die in supportingInformation referenzierten Datensätze entsprechend der Filterung und Suchkriterien übermitteln. [<=]

A_22123 - E-Rezept-Fachdienst – Abrechnungsinformationen abrufen - Paging

Der E-Rezept-Fachdienst KANN beim Aufruf der HTTP-GET-Operation auf den Endpunkt /ChargeItem das Suchergebnis in einem Paging-Mechanismus auf mehrere Ergebnis-Bundle aufteilen, damit der Nutzer eine komfortable Navigationsmöglichkeit in seinen Abrechnungsinformationen erhält. [<=]

6.1.4.2.2 GET /ChargeItem/<id>

Mit dieser Operation können die Details zu einem ChargeItem abgefragt werden. Ein Versicherter ist berechtigt auf eine ChargeItem Ressourcen zuzugreifen, wenn er der Begünstigte ist. Eine Apotheke ist berechtigt auf eine ChargeItem Ressource zuzugreifen, wenn sie diese dem Versicherten bereitgestellt hat und wenn sie den vom Versicherten bereitgestellten AccessCode übermitteln kann.

A_22124 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen - Rollenprüfung Versicherter oder Apotheker

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf eine konkrete über <id> adressierte/ChargeItem/<id> Ressource sicherstellen, dass ausschließlich Versicherte oder Apotheken in einer der Rollen

  • oid_versicherter
  • oid_oeffentliche_apotheke
  • oid_krankenhausapotheke
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit E-Rezepte nicht durch Unberechtigte ausgelesen werden können. [<=]

A_22125 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen – Versicherter – Prüfung KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf eine konkrete über <id> adressierte/ChargeItem/<id> Ressource durch einen Versicherten, den Versicherten anhand der KVNR aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren, diese gegen die in "ChargeItem.subject.identifier" hinterlegte KVNR des begünstigten Versicherten prüfen und bei Ungleichheit den Aufruf mit dem HTTP-Fehlercode 403 abweisen, damit ausschließlich der begünstigte Versicherte als Berechtigter eine Abrechnungsinformation abrufen kann. [<=]

A_22126 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen – Apotheke – Prüfung Telematik-ID

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf eine konkreten über <id> adressierte/ChargeItem/<id> Ressource durch eine abgebende Leistungserbringerinstitution, die LEI anhand der Telematik-ID aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren, diese gegen die in "ChargeItem.enterer.identifier" hinterlegte Telematik-ID der einstellenden LEI prüfen und bei Ungleichheit den Aufruf mit dem HTTP-Fehlercode 403 abweisen, damit ausschließlich die LEI eine Abrechnungsinformation abrufen kann, welche die Abrechnungsinformation im E-Rezept-Fachdienst bereitgestellt hat. [<=]

A_22611-01 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen – Apotheke – Prüfung AccessCode

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf eine konkreten über <id> adressierte/ChargeItem/<id> Ressource durch eine abgebende Leistungserbringerinstitution, den im URL-Parameter "?ac=..." übertragenen AccessCode gegen den im referenzierten ChargeItem gespeicherten AccessCode ChargeItem.identifier:AccessCode als https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AccessCode prüfen und bei Ungleichheit oder Fehlen des URL-Parameters die Operation mit dem HTTP-Fehlercode 403 abbrechen, damit Zugriffe auf diesen Datensatz nur durch Berechtigte in Kenntnis des AccessCodes erfolgen. [<=]

A_22127-01 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen – Versicherte – Signieren

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation GET /ChargeItem/<id> durch einen Versicherten zusätzlich zum ChargeItem die folgenden Datensätze im JSON-Format in einem Responsebundle zurück liefern und dafür in jedem Aufruf

  • den Verordnungsdatensatz im XML-Format mit der Signaturidentität des E-Rezept-Fachdienstes ID.FD.OSIG gemäß [RFC5652] mit Profil CAdES-BES ([CAdES]) Enveloping signieren (QES wird dabei entfernt),
  • den PKV-Abgabedatensatz im XML-Format mit der Signaturidentität des E-Rezept-Fachdienstes ID.FD.OSIG gemäß [RFC5652#section-11.4] mit Profil CAdES-BES ([CAdES]) Enveloping im gegensignieren
  • die Quittung im XML-Format mit der Signaturidentität des E-Rezept-Fachdienstes ID.FD.OSIG gemäß [RFC5652] mit Profil CAdES-BES ([CAdES]) Enveloping signieren und
  • in jede Fachdienstsignatur die letzte OCSP-Antwort der regelmäßigen Statusprüfung des Signaturzertifikats C.FD.OSIG einbetten (jedes Signatur-Ergebnis wird als dss:Base64Signature-Objekt in Bundle.signature des jeweiligen JSON-Objekts eingebettet),
damit der Versicherte die Daten für die Abrechnung an Kostenträger weiterleiten kann. [<=]

Hinweis: außer ChargeItem sind die zurückgegebenen FHIR-Ressourcen vom Typ Bundle und jedes Bundle trägt "seine" Signatur im jeweiligen Attribut Bundle.signature im CAdES-Enveloping-Format. Die signierten Daten sind dadurch doppelt vorhanden, das erspart jedoch die fehleranfällige Normalisierung und Kanonisierung in der Signaturprüfung.

Hinweis: Der Verordnungsdatensatz, der PKV-Abgabedatensatz und die Quittung werden zum Abrufzeitpunkt signiert, um die Möglichkeit der Prüfung der Signaturzertifikate im nachfolgenden Abrechnungsprozess sicherzustellen.

Hinweis: Es ist geplant, das Signaturzertifikat C.FD.OSIG durch ein eIDAS Siegel zu ersetzen, um eine Prüfung der Signatur außerhalb der TI mit Standardtools zu ermöglichen.

A_22128 - E-Rezept-Fachdienst – Abrechnungsinformation abrufen – Apotheke – kein AccessCode und Quittung

Der E-Rezept-Fachdienst DARF beim Aufruf der Operation GET /ChargeItem/<id> durch eine abgebende Leistungserbringerinstitution das in "ChargeItem.supportingInformation" referenzierte Element ChargeItem.supportingInformation:receipt und den Identifier Task.identifier:AccessCode NICHT in den Response übernehmen, sodass die abgebende LEI nur den Verordnungsdatensatz und durch sie änderbaren PKV-Abgabedatensatz erhält. [<=]

Hinweis: Der Verordnungsdatensatz wird mit QES des Verordnenden an die Apotheke zurück geliefert.

6.1.4.3 HTTP-Operation PATCH

Die FHIR-Operation führt zum Aktualisieren einer unter <Prescription-ID> gespeicherten ChargeItem Ressource.

Diese Operation steht dem Versicherten für das Aktualisieren der Markierungen zur Verfügung.

6.1.4.3.1 PATCH /ChargeItem/<id>

A_22879 - E-Rezept-Fachdienst – Abrechnungsinformation ändern (PATCH) - alles Ändern verbieten

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation PATCH auf den Endpunkt /ChargeItem ohne Angabe einer <id> für eine konkrete Ressource mit dem HTTP-Fehlercode 405 ablehnen, um das Ändern mehrerer Ressourcen über einen Request zu verhindern.   [<=]

Hinweis: Auf die Prüfung, ob die Einwilligung zum Speichern der Abrechnungsinformationen vorliegt, kann verzichtet werden, weil bei einem zwischenzeitlichen Widerruf alle Abrechnungsinformationen des Versicherten vom E-Rezept-Fachdienst gelöscht wurden. Beim Aufruf der Operation PATCH /ChargeItem/<id> wird der HTTP-Fehlercode 404 (Not found) zurückgegeben.

A_22875 - E-Rezept-Fachdienst – Abrechnungsinformation ändern (PATCH) – Rollenprüfung

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-PATCH-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource sicherstellen, dass ausschließlich Nutzer in der Rolle 

  • oid_versicherter 
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit eine Abrechnungsinformation nicht durch Unberechtigte aktualisiert werden kann. [<=]

A_22877 - E-Rezept-Fachdienst – Abrechnungsinformation ändern (PATCH) – Versicherter - Prüfung KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PATCH-Operation auf eine konkrete über <id> adressierte/ChargeItem/<id> Ressource durch einen Versicherten, den Versicherten anhand der KVNR aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren, diese gegen die im gespeicherten Datensatz in "ChargeItem.subject.identifier" hinterlegte KVNR des begünstigten Versicherten prüfen und bei Ungleichheit den Aufruf mit dem HTTP-Fehlercode 403 abweisen, damit ausschließlich der begünstigte Versicherte als Berechtigter eine Abrechnungsinformation ändert. [<=]

A_22878 - E-Rezept-Fachdienst - Abrechnungsinformation ändern (PATCH) – Zulässige Felder

Der E-Rezept-Fachdienst MUSS die im HTTP-PATCH-Operation auf die Ressource ChargeItem übertragenen Attribute gegen das FHIR-Profil ChargeItem prüfen, auf die Zulässigkeit der änderbaren Felder prüfen:

Versicherter darf nur Markierungen (extention ChargeItem.extension:markingFlag) ändern 

und bei fehlerhafter Prüfung die Operation mit dem http-Status-Code 400 und einem Hinweis auf unzulässige Änderung gesperrter Attribute in OperationOutcome abbrechen, damit kein Schadcode und keine "fachfremden" Daten in den E-Rezept-Fachdienst hochgeladen werden.  [<=]

6.1.4.4 HTTP-Operation POST

Die FHIR-Operation führt zum Einstellen einer neuen Abrechnungsinformation. 

Diese Operation steht für das Einstellen den Apotheken zur Verfügung.

6.1.4.4.1 POST /ChargeItem

A_22129 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen - Rollenprüfung

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem sicherstellen, dass ausschließlich Nutzer in der Rolle 

  • oid_oeffentliche_apotheke
  • oid_krankenhausapotheke 
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit eine Abrechnungsinformation nicht durch Unberechtigte eingestellt werden kann. [<=]

A_22130 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen - Prüfung Parameter Task

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem sicherstellen, dass ein URL-Parameter "task=..." übermittelt wurde und bei Fehlen des URL-Parameters die Operation mit dem HTTP-Fehlercode 400 abbrechen. [<=]

A_22131 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen - Prüfung Existenz Task

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem sicherstellen, dass zu der im URL-Parameter "task=..." übertragene Task-ID eine Task Ressource mit dem Status Task.status = completed existiert und bei fehlgeschlagener Prüfung mit dem HTTP-Fehlercode 409 abbrechen, damit nur eine Abrechnungsinformation für E-Rezepte mit dem Status „quittiert“ angelegt wird. [<=]

Aus der Details der Fehlerbeschreibung in OperationOutcome soll für den Nutzer (Angehöriger einer abgebenden LEI) durch eine verständliche Darstellung im Primärsystem hervorgehen, warum die Abgabeinformation nicht bereitgestellt werden kann, damit der Grund dem Versicherten übermittelt werden kann.

A_22132-01 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Prüfung Secret Task

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem das im URL-Parameter "secret=..." übertragene Secret gegen das im referenzierten Task gespeicherte Secret Task.identifier:Secret als https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Secret prüfen und bei Ungleichheit oder Fehlen des URL-Parameters die Operation mit dem HTTP-Fehlercode 403 abbrechen, damit der Zugriff auf diesen Datensatz nur durch die berechtigten Apotheke in Kenntnis des Secrets erfolgt. [<=]

A_22731 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Prüfung Flowtype Task

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem sicherstellen, dass der im URL-Parameter "task=..." referenzierte Task den Flowtype  Task.extension:flowType = 200 oder 209 besitzt und bei fehlgeschlagener Prüfung mit dem HTTP-Fehlercode 400 abbrechen, damit nur eine Abrechnungsinformation für E-Rezepte mit zulässigen Flowtype angelegt wird. [<=]

A_22133 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Prüfung Einwilligung

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem sicherstellen, dass zu der in ChargeItem.subject.identifier übermittelten KVNR ein Consent Datensatz mit Consent.patient.identifier = KVNR und Consent.category.coding.code = CHARGCONS existiert und bei fehlgeschlagener Prüfung die Operation mit dem HTTP-Fehlercode 403 abbrechen, damit nur eine Abrechnungsinformation für Versicherte gespeichert wird, die eine Einwilligung erteilt haben. [<=]

Aus der Details der Fehlerbeschreibung in OperationOutcome soll für den Nutzer (Angehöriger einer abgebenden LEI) durch eine verständliche Darstellung im Primärsystem hervorgehen, warum die Abgabeinformation nicht bereitgestellt werden kann, damit der Grund dem Versicherten übermittelt werden kann.

A_22136-01 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – FHIR-Validierung ChargeItem

Der E-Rezept-Fachdienst MUSS die im HTTP-POST-Operation auf die Ressource ChargeItem übertragene ChargeItem Ressource gegen das FHIR-Profil ChargeItem prüfen und

  • die Korrektheit der Rezept-ID https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PrescriptionId im referenzierten Task als ChargeItem.identifier ,
  • die Korrektheit der Versicherten-ID des Versicherten im referenzierten Task (Task.for) gegen ChargeItem.subject.identifier 
  • und die Korrektheit der Telematik-ID der Apotheke gemäß ACCESS_TOKEN mit dem Wert in ChargeItem.enterer.identifier
prüfen und bei Nicht-Konformität das Anlegen der Ressource im E-Rezept-Fachdienst mit dem http-Status-Code 400 ablehnen, damit nur FHIR-valide Ressourcen in den E-Rezept-Fachdienst hochgeladen werden. [<=]

Der PKV-Abgabedatensatz wird containedbinary im Aufruf übermittelt.

A_22137 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – PKV-Abgabedatensatz übernehmen

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem den im containedbinary übermittelten PKV-Abgabedatensatz herauslösen und entfernen, die Ressource zur ChargeItem Ressource speichern und in ChargeItem.supportingInformation:dispenseItem die Referenz hinzufügen. [<=]

A_22138 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – FHIR-Validierung PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS die im HTTP-POST-Operation auf die Ressource ChargeItem übertragene PKV-Abgabedatensatz Ressource gegen das FHIR-Profil http://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PKV-PR-ERP-AbgabedatenBundle prüfen und bei Nicht-Konformität das Anlegen der Ressource im E-Rezept-Fachdienst mit dem http-Status-Code 400 ablehnen, damit nur FHIR-valide Ressourcen in den E-Rezept-Fachdienst hochgeladen werden. [<=]

A_22139 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Signaturprüfung PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem die Signatur des PKV-Abgabedatensatzes gemäß [ETSI_QES] prüfen, und bei fehlender oder nicht gültiger Signatur mit Status 400 abbrechen, um ausschließlich authentische Daten zu verwalten.  [<=]

Der PKV-Abgabedatensatz hat QES eines HBAs des Apothekers oder eine nonQES einer SMC-B der Apotheke. Die Zertifikate QES bzw. nonQES werden anhand ihres Zertifikatstyps (Policy-OID) unterschieden.

A_22140 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Prüfung Signaturzertifikat PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem das Signaturzertifikats des PKV-Abgabedatensatzes prüfen. Das Signaturzertifikat muss anhand der Zertifikatsprüfung für [mathematisch gültig UND zeitlich gültig UND online gültig ] befunden werden und der Aufruf anderenfalls mit Status 400 abgebrochen werden, um ausschließlich authentische Daten zu verwalten. [<=]

Die Vorgaben für die Prüfung eines QES Zertifikates sind in A_20159 beschrieben.

A_22141 - E-Rezept-Fachdienst – Signaturzertifikat SMC-B prüfen

Der E-Rezept-Fachdienst MUSS ein Signatur-Zertifikat einer nonQES-Signatur eine Leistungserbringerinstitution gemäß [gemSpec_PKI#TUC_PKI_018] mit folgenden Parametern auf Gültigkeit prüfen:

Tabelle 13: TAB_eRPFD_xxx Parameter Prüfung Signaturzertifikat SMC-B

Parameter
Zertifikat Signaturzertifikat aus nonQES 
PolicyList oid_smc_b_osig 
intendedKeyUsage nonRepudiation
intendedExtendedKeyUsage (leer)
OCSP-Graceperiod 12 Stunden
Offline-Modus nein
Prüfmodus OCSP
Der E-Rezept-Fachdienst darf die OCSP-Response für die Abfrage des Zertifikatsstatus für 12 Stunden zwischenspeichern. [<=]

A_22134 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Verordnungsdatensatz übernehmen

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem das E-Rezept-Bundle vom Profil https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle ohne die Signatur zur im URL-Parameter "task=..." übertragenen Task-ID identifizieren und zur ChargeItem Ressource mit dem Identifier PrescriptionID speichern und in ChargeItem.supportingInformation:prescriptionItem die Referenz hinzufügen. [<=]

Für den übernommenen Verordnungsdatensatz gelten nicht die Löschfristen des Tasks, aus dem der Verordnungsdatensatz übernommen wurde.

A_22135-01 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – Quittung übernehmen

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem das Quittung-Bundle vom Profil https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Bundle ohne die Signatur zur im URL-Parameter "task=..." übertragenen Task-ID identifizieren und zur ChargeItem Ressource mit dem Identifier PrescriptionID speichern und in ChargeItem.supportingInformation:receipt die Referenz hinzufügen. [<=]

Für die übernommene Quittung gelten nicht die Löschfristen des Tasks, aus dem die Quittung übernommen wurde.

A_22614-01 - E-Rezept-Fachdienst - Abrechnungsinformation bereitstellen - Generierung AccessCode

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /ChargeItem eine 256-Bit-Zufallszahl mit einer Mindestentropie von 120 Bit erzeugen, hexadezimal kodieren ([0-9a-f]{64}) und diese im zu speichernden ChargeItem als externe ID in ChargeItem.identifier:AccessCode als https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AccessCode hinzufügen, damit nachfolgende Zugriffe auf diesen Datensatz nur durch Berechtigte in Kenntnis des AccessCodes erfolgen. [<=]

A_22143 - E-Rezept-Fachdienst – Abrechnungsinformation bereitstellen – ChargeItem befüllen

Der E-Rezept-Fachdienst MUSS beim Erzeugen eines ChargeItem mittels HTTP-POST-Operation die folgenden Elemente schreiben:

  • ChargeItem.enteredDate: aktueller Zeitstempel
[<=]

6.1.4.5 HTTP-Operation PUT

Die FHIR-Operation führt zum Aktualisieren einer unter <Prescription-ID> gespeicherten ChargeItem Ressource. 

Diese Operation steht der Apotheke, welche die Abrechnungsinformation bereitgestellt hat, für das Aktualisieren des PKV-Abgabedatensatzes zur Verfügung.

6.1.4.5.1 PUT /ChargeItem/<id>

A_22144 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Rollenprüfung

Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource sicherstellen, dass ausschließlich Nutzer in der Rolle 

  • oid_oeffentliche_apotheke
  • oid_krankenhausapotheke 
die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit eine Abrechnungsinformation nicht durch Unberechtigte aktualisiert werden kann.  [<=]

A_22215 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Prüfung Einwilligung

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte/ChargeItem/<id> Ressource sicherstellen, dass zu der in ChargeItem.subject.identifier übermittelten KVNR ein Consent Datensatz mit Consent.patient.identifier = KVNR und Consent.category.coding.code = CHARGCONS existiert und bei fehlgeschlagener Prüfung die Operation mit dem HTTP-Fehlercode 403 abbrechen, damit nur eine Abrechnungsinformation für Versicherte gespeichert wird, die eine Einwilligung erteilt haben.  [<=]

A_22146 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Apotheke - Prüfung Telematik-ID

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), diese anhand der Telematik-ID aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren, diese gegen die im gespeicherten Datensatz in "ChargeItem.enterer.identifier" hinterlegte Telematik-ID prüfen und bei Ungleichheit den Aufruf mit dem HTTP-Fehlercode 403 abweisen, damit ausschließlich die Apotheke, welche die Abrechnungsinformation bereitgestellt hat, als Berechtigte eine Abrechnungsinformation ändert. [<=]

A_22616-01 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Apotheke – Prüfung AccessCode

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 im URL-Parameter "?ac=..." übertragenen AccessCode gegen den im referenzierten ChargeItem gespeicherten AccessCode ChargeItem.identifier:AccessCode als https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AccessCode prüfen und bei Ungleichheit oder Fehlen des URL-Parameters die Operation mit dem HTTP-Fehlercode 403 abbrechen, damit Zugriffe auf diesen Datensatz nur durch Berechtigte in Kenntnis des AccessCodes erfolgen. [<=]

A_22148 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Apotheke – PKV-Abgabedatensatz übernehmen

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende LEI, den im containedbinary übermittelten PKV-Abgabedatensatz herauslösen und entfernen, die Ressource zur ChargeItem Ressource speichern und in ChargeItem.supportingInformation:dispenseItem die Referenz hinzufügen.  [<=]

A_22149 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Apotheke – FHIR-Validierung PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende LEI, die im HTTP-PUT-Operation auf die Ressource ChargeItem übertragene PKV-Abgabedatensatz Ressource gegen das FHIR-Profil PKV-Abgabedatensatz prüfen und bei Nicht-Konformität das Anlegen der Ressource im E-Rezept-Fachdienst mit dem http-Status-Code 400 und einem Hinweis auf die FHIR-Invalidität in OperationOutcome ablehnen, damit nur FHIR-valide Ressourcen in den E-Rezept-Fachdienst hochgeladen werden.  [<=]

A_22150 - E-Rezept-Fachdienst – Abrechnungsinformation ändern - Apotheke – Signaturprüfung PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende LEI, die Signatur des PKV-Abgabedatensatzes gemäß [ETSI_QES] prüfen, und bei fehlender oder nicht gültiger Signatur mit Status 400 und einem Hinweis auf den die ungültige Signatur in OperationOutcome abbrechen, um ausschließlich authentische Daten zu verwalten.   [<=]

A_22151 - E-Rezept-Fachdienst – Abrechnungsinformation ändern – Apotheke – Prüfung Signaturzertifikat PKV-Abgabedatensatz

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende LEI, das Signaturzertifikats des PKV-Abgabedatensatzes prüfen. Das Signaturzertifikat muss anhand der Zertifikatsprüfung für [mathematisch gültig UND zeitlich gültig UND online gültig] befunden werden und der Aufruf anderenfalls mit Status 400 und einem Hinweis auf das abgelaufene/gesperrte Signaturzertifikat in OperationOutcome abgebrochen werden, um ausschließlich authentische Daten zu verwalten.  [<=]

Die Vorgaben für die Prüfung eines QES Zertifikates sind in A_20159 beschrieben. Die Vorgaben für die Prüfung eines nonQES Zertifikates sind in A_22141 beschrieben.

A_22152 - E-Rezept-Fachdienst - Abrechnungsinformation ändern – FHIR-Validierung ChargeItem

Der E-Rezept-Fachdienst MUSS die im HTTP-PUT-Operation auf die Ressource ChargeItem übertragene ChargeItem Ressource gegen das FHIR-Profil ChargeItem prüfen, auf die Zulässigkeit der änderbaren Felder prüfen:

abgebende LEI darf nur PKV-Abgabedatensatz ändern 
und bei fehlerhafter Prüfung die Operation mit dem http-Status-Code 400 und einem Hinweis auf unzulässige Änderung gesperrter Attribute in OperationOutcome abbrechen, damit kein Schadcode und keine "fachfremden" Daten in den E-Rezept-Fachdienst hochgeladen werden.  [<=]

A_22615-01 - E-Rezept-Fachdienst - Abrechnungsinformation ändern - Apotheke - Generierung AccessCode

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-PUT-Operation auf eine konkrete über <id> adressierte /ChargeItem/<id> Ressource durch eine abgebende LEI eine 256-Bit-Zufallszahl mit einer Mindestentropie von 120 Bit erzeugen, hexadezimal kodieren ([0-9a-f]{64}) und diese im zu speichernden ChargeItem als externe ID in ChargeItem.identifier:AccessCode als https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AccessCode überschreiben, damit nachfolgende Zugriffe auf diesen Datensatz nur durch Berechtigte in Kenntnis des AccessCodes erfolgen. [<=]

6.1.5 Ressource Consent

Für das Speichern der Abrechnungsinformationen eines Versicherten im E-Rezept-Fachdienst muss der Versicherte vorab eine Einwilligung erteilen. Für die Übermittlung der Einwilligung wird die FHIR Ressource Consent verwendet.

A_22153 - E-Rezept-Fachdienst - unzulässige Operationen Consent

Der E-Rezept-Fachdienst MUSS alle Zugriffe auf die Ressource Consent mittels der HTTP-Operationen PUT, PATCH, oder HEAD unterbinden, damit keine unzulässigen Operationen auf die Informationen zur Einwilligung ausgeführt werden können. [<=]

6.1.5.1 HTTP-Operation DELETE

Die Operation führt zum Löschen der für den Versicherten gespeicherten Einwilligung. Diese Operation steht dem Versicherten, der die Einwilligung erteilt hat, zur Verfügung.

A_22154 - E-Rezept-Fachdienst – Consent löschen - alles Löschen verbieten

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent ohne Angabe ?category mit dem HTTP-Fehlercode 405 ablehnen, um das Löschen mehrerer Ressourcen über einen Request zu verhindern.   [<=]

A_22155 - E-Rezept-Fachdienst - Consent löschen - Rollenprüfung Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent 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 am E-Rezept-Fachdienst aufrufen dürfen, damit die Information zur Einwilligung nicht durch Unberechtigte gelöscht werden kann. [<=]

A_22874-01 - E-Rezept-Fachdienst - Consent löschen - Prüfung category

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent prüfen, dass der für ?category angegebene Wert im System https://gematik.de/fhir/erpchrg/CodeSystem/GEM_ERPCHRG_CS_ConsentType enthalten ist und bei fehlerhafter Prüfung den Request mit dem Fehler 400 abbrechen, damit nur Löschrequests für definierte Consent Typen ausgeführt werden. [<=]

A_22157 - E-Rezept-Fachdienst - Consent löschen - Löschen der bestehenden Abrechnungsinformationen

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent mit ?category=CHARGCONS alle dem Versicherten zugeordneten ChargeItem-Ressourcen (ChargeItem.subject.identifier) anhand der KVNR des Versicherten im ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren und löschen. [<=]

A_22158 - E-Rezept-Fachdienst - Consent löschen - Löschen der Consent

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent die Ressource löschen, bei der Consent.patient.identifier der KVNR aus dem ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests sowie Consent.category.coding.code dem in ?category übermittelten Wert entspricht. [<=]

6.1.5.2 HTTP-Operation GET

Mit der FHIR-Operation kann die Consent Ressource für die im ACCESS_TOKEN angegebene KVNR abgerufen werden. Diese Operation steht Versicherten zur Verfügung.

A_22159 - E-Rezept-Fachdienst - Consent lesen - Rollenprüfung Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Consent sicherstellen, dass ausschließlich Versicherte in der Rolle oid_versicherter die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit die Information zur Einwilligung nicht durch Unberechtigte ausgelesen werden kann. [<=]

A_22160 - E-Rezept-Fachdienst - Consent lesen - Filter Consent auf KVNR des Versicherten

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Consent die dem Versicherten zugeordneten Consent-Ressourcen anhand der KVNR des Versicherten im ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren und in den Response aufnehmen, die in Consent.Patient.identifier die entsprechende KVNR des begünstigten Versicherten referenziert haben, damit ausschließlich Versicherte ihre eigenen Information zu Einwilligungen einsehen können. [<=]

6.1.5.3 HTTP-Operation POST

Die FHIR-Operation führt zum Schreiben einer neuen Einwilligung. Diese Operation steht Versicherten zur Verfügung.

A_22161 - E-Rezept-Fachdienst - Consent schreiben - Rollenprüfung Versicherter

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent sicherstellen, dass ausschließlich Versicherte in der Rolle oid_versicherter die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit eine Einwilligung nicht durch Unberechtigte erteilt werden kann. [<=]

A_22289 - E-Rezept-Fachdienst - Consent schreiben - Prüfung KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent sicherstellen, dass die KVNR im ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests und die KVNR in Consent.patient.identifier  übereinstimmen, damit eine Einwilligung für einen Versicherten nicht durch Dritte erteilt werden kann. Im Fehlerfall muss der Http-Request mit dem Http-Fehlercode 403 abgewiesen werden. [<=]

A_22351 - E-Rezept-Fachdienst - Consent schreiben - FHIR-Validierung

Der E-Rezept-Fachdienst MUSS die im HTTP-POST-Operation auf die Ressource Consent übertragene Consent Ressource gegen das FHIR-Profil Consent prüfen und bei Nicht-Konformität das Anlegen der Ressource im E-Rezept-Fachdienst mit dem http-Status-Code 400 ablehnen, damit nur FHIR-valide Ressourcen in den E-Rezept-Fachdienst hochgeladen werden. [<=]

A_22162 - E-Rezept-Fachdienst - Consent schreiben – nur eine Einwilligung CHARGCONS pro KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent sicherstellen, dass noch keine Consent Ressource für die KVNR im ACCESS_TOKEN und  Consent.category.coding.code = CHARGCONS  gespeichert ist, um maximal eine Einwilligung für den Versicherten zu speichern. Im Fehlerfall muss der Http-Request mit dem Http-Fehlercode 409 abgewiesen werden. [<=]

A_22350 - E-Rezept-Fachdienst - Consent schreiben – Persistieren

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent – falls bei den Prüfungen keine Fehler aufgetreten sind, welche zum Abbruch der Operation führen – die übermittelte Ressource persistieren. [<=]

6.1.6 Ressource Communication

6.1.6.1 POST /Communication/

Das Kapitel 6.5.2.1 aus [gemSpec_FD_eRp] wird erweitert.

A_19447-04 - E-Rezept-Fachdienst - Nachricht einstellen - Schemaprüfung

Der E-Rezept-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die im http-Request-Body übergebene Communications-Ressource gegen das aus der Kommunikationsbeziehung ableitbare, zulässige Schema gemäß TAB_eRPFD_008

Tabelle 14: TAB_eRPFD_008 Nachrichtentyp zu Kommunikationsbeziehung

sender recipient zusätzliche Bedingung Schema
KVNR TelematikID Communication.basedOn
referenziert Task		 https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq 
KVNR TelematikID Communication.about
referenziert Medication
Communication.basedOn
referenziert Task		 https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_InfoReq 
TelematikID KVNR Communication.basedOn
referenziert Task		 https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Reply 
KVNR KVNR Communication.basedOn
referenziert Task 		 https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Representative 
KVNR TelematikID Communication.basedOn
referenziert ChargeItem		 https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq
TelematikID KVNR Communication.basedOn
referenziert ChargeItem		 https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReply
prüfen und den Aufruf bei Nicht-Konformität mit dem http-Status-Code 400 ablehnen, damit ausschließlich konforme E-Rezept-Nachrichten ausgetauscht werden. [<=]

A_20885-03 - E-Rezept-Fachdienst - Nachricht einstellen - Versicherte - Prüfung Versichertenbezug und Berechtigung

Der E-Rezept-Fachdienst MUSS das Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq",  "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_InfoReq" oder "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Representative" durch einen Versicherten über die http-Operation POST auf den Endpunkt /Communication mit dem http-Status-Code 400 abbrechen, wenn

  • die KVNR des in Communication.basedOn referenzierten Tasks Task.for ungleich der KVNR des Einstellenden in "idNummer" des übergebenen ACCESS_TOKEN
und 
  • der http-Header "X-AccessCode" fehlt oder der im http-Header "X-AccessCode" übergebene AccessCode ungleich dem AccessCode-Identifier des referenzierten Tasks
ist, um irreführende Testnachrichten zu unterbinden, die eine vermeidbare Mehrbelastung für den E-Rezept-Fachdienst darstellen. [<=]

A_21371-02 - E-Rezept-Fachdienst - Nachricht einstellen - Prüfung Existenz Task

Der Fachdienst E-Rezept MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq", "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_InfoReq", "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Reply" oder "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Representative" über die http-Operation POST auf den Endpunkt /Communication mit dem http-Status-Code 400 abbrechen, wenn das Pflichtfeld Communication.basedOn einen Task referenziert, der nicht existiert, um Spam und nicht-rezeptbezogene Kommunikation zu verhindern. [<=]

A_22734-01 - E-Rezept-Fachdienst - Nachricht einstellen - Prüfung Existenz ChargeItem

Der Fachdienst E-Rezept MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq" oder "https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReply" über die http-Operation POST auf den Endpunkt /Communication mit dem http-Status-Code 400 abbrechen, wenn das Pflichtfeld Communication.basedOn einen ChargeItem referenziert, der nicht existiert, um Spam und nicht-rezeptbezogene Kommunikation zu verhindern. [<=]

A_22367-02 - E-Rezept-Fachdienst - Nachricht einstellen - Notification Apotheke

Der E-Rezept-Fachdienst MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq",  "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_InfoReq" oder "https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq" zur Versicherter-zu-Apotheken-Kommunikation über die http-Operation POST auf den Endpunkt /Communication prüfen, ob für die Telematik-ID des Empfängers Subscriptions registriert sind und für Registrierungen über den Subscription Service eine Notification (ping : subscription-id) senden. [<=]

6.2 Anforderungen an das E-Rezept-FdV

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

6.2.1 Kommunikation zu Diensten der TI

Das Kapitel 5.1.2 aus [gemSpec_eRp_FdV] wird erweitert.

Die Tabelle TAB_FdVERP_019 wird wie folgt ergänzt:

Tabelle 15 : TAB_FdVERP_019 - HTTP-Header "X-erp-resource"

Operation X-erp-resource
DELETE /Consent/
 Consent
GET /Consent/ Consent
POST /Consent/ Consent
DELETE /ChargeItem/<id> ChargeItem
GET /ChargeItem/ ChargeItem
GET /ChargeItem/<id> ChargeItem
PATCH /ChargeItem/<id> ChargeItem

Die in den folgenden Kapiteln beschriebenen Anwendungsfälle sind nur für PKV-Versicherte sinnvoll nutzbar. Die Benutzerführung im E-Rezept-FdV muss so gestaltet werden, dass die Funktionen nur Versicherten angeboten wird, welche sich, bspw. durch Konfigurationseinstellungen, als PKV-Versicherte identifiziert haben.   

6.2.2 E-Rezepte in E-Rezept-Fachdienst löschen

Das Kapitel 5.2.3.8 aus [gemSpec_eRp_FdV] wird erweitert.

Die Beschreibung der Umsetzung des Anwendungsfalls "E-Rezept im E-Rezept-Fachdienst löschen" wird um die folgende Information ergänzt:

Für das Löschen von E-Rezepten des Workflow-Typ "200" und "209" ist der Nutzer zu informieren, dass nach Löschen des E-Rezeptes nicht mehr die Möglichkeit besteht, dass die abgebende LEI (Apotheke) die Abrechnungsinformation zum E-Rezept für den PKV-Versicherten über das E-Rezept-FdV bereitstellt.

6.2.3 Einwilligung zum Speichern der Abrechnungsinformationen erteilen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilen und die Information auf dem E-Rezept-Fachdienst speichern.

A_22709 - E-Rezept-FdV: Einwilligung Abrechnungsinformation erteilen - Einwilligungstext

Das E-Rezept-FdV MUSS den Text für die Einwilligung darart gestalten, dass dem Nutzer eine informierte Einwilligung möglich ist. Insbesondere MÜSSEN enthalten sein: der Verwendungszweck, die konkreten Informationen über die Art der erhobenen Daten, die Speicherdauer, Hinweis auf Freiwilligkeit, auf Widerrufsrecht, Hinweis auf die Folgen bei Verweigerung oder Widerruf. [<=]

A_22163 - E-Rezept-FdV: Einwilligung Abrechnungsinformation erteilen - Einwilligung eingeben

Das E-Rezept-FdV MUSS es dem Nutzer, welcher sich als PKV-Versicherte identifiziert hat, ermöglichen, die Einwilligung zum Speichern der Abrechnungsinformation auf dem E-Rezept-Fachdienst, einzugeben. [<=]

A_22164 - E-Rezept-FdV: Einwilligung Abrechnungsinformation erteilen

Das E-Rezept-FdV MUSS den Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten erteilen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 16 : TAB_FdVERP_xxx – Einwilligung Abrechnungsinformation erteilen

Name Einwilligung Abrechnungsinformation erteilen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat die Einwilligung in der GUI erteilt.
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Information zur Einwilligung ist im E-Rezept-Fachdienst gespeichert.
Standardablauf
  1. Consent Ressource erstellen
  2. Einwilligung Abrechnungsinformation speichern
[<=]

A_22165 - E-Rezept-FdV: Einwilligung Abrechnungsinformation erteilen - Consent Ressource erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung Abrechnungsinformation erteilen" eine Consent Ressource mit

  • Versicherten-ID in Consent.patient.identifier
  • CHARGCONS in  Consent.category.coding.code
erstellen. [<=]

A_22166 - E-Rezept-FdV: Einwilligung Abrechnungsinformation erteilen - Speicherrequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung Abrechnungsinformation erteilen" zum Speichern der Information im E-Rezept-Fachdienst die HTTP-Operation POST /Consent mit 

  • ACCESS_TOKEN im Authorization-Header
ausführen. [<=]

6.2.4 Einwilligungsinformation abrufen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Information, ob eine Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt wurde, vom E-Rezept-Fachdienst abrufen.

A_22167 - E-Rezept-FdV: Einwilligungsinformationen abrufen

Das E-Rezept-FdV MUSS den Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten einsehen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 17 : TAB_FdVERP_xxx – Einwilligungsinformation abrufen

Name Einwilligungsinformation abfragen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Information zur Einwilligung liegt im FdV zur Anzeige vor.
Standardablauf
  1. Einwilligung Abrechnungsinformation abfragen
  2. Prüfen, ob Consent mit Consent.category.coding.code = CHARGCONS vorliegt
[<=]

A_22168 - E-Rezept-FdV: Einwilligungsinformation abrufen - Abfragerequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligungsinformation abfragen" zum Abrufen der Information vom E-Rezept-Fachdienst die HTTP-Operation GET /Consent mit 

  • ACCESS_TOKEN im Authorization-Header
ausführen. [<=]

Im Response können mehrere Consent Ressourcen enthalten sein. Die Einwilligung zum Speichern der Abrechnungsinformationen liegt vor, wenn eine Consent mit Consent.category.coding.code = CHARGCONS übermittelt wurde.

6.2.5 Einwilligung zum Speichern der Abrechnungsinformationen widerrufen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst widerrufen und die Information zur Einwilligung vom E-Rezept-Fachdienst zu löschen. 

Mit dem Widerruf der Einwilligung werden alle Abrechnungsinformationen des Versicherten gelöscht. Das Löschen erfolgt unwiederbringlich.

A_22169 - E-Rezept-FdV: Einwilligung Abrechnungsinformation widerrufen - Einwilligung eingeben

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die Einwilligung zum Speichern der Abrechnungsinformation auf dem E-Rezept-Fachdienst, zu entziehen. [<=]

A_22330 - E-Rezept-FdV: Einwilligung Abrechnungsinformation widerrufen - Bestätigung

Das E-Rezept-FdV MUSS vom Nutzer eine Bestätigung einholen, dass die Einwilligung zum Speichern der Abrechnungsinformation auf dem E-Rezept-Fachdienst widerrufen werden soll und somit auch alle gespeicherten Abrechnungsinformationen gelöscht werden und die Möglichkeit geben, das Widerrufen abzubrechen. [<=]

A_22170 - E-Rezept-FdV: Einwilligung Abrechnungsinformation widerrufen

Das E-Rezept-FdV MUSS den Anwendungsfall "Einwilligung zum Speichern der Abrechnungsinformationen durch Versicherten widerrufen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 18 : TAB_FdVERP_xxx – Einwilligung Abrechnungsinformation widerrufen

Name Einwilligung Abrechnungsinformation widerrufen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat den Widerruf der Einwilligung in der GUI eingegeben.
  • Im FdV wurde der Anwendungsfall "Einwilligungsinformation abfragen" ausgeführt.
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Information zur Einwilligung ist im E-Rezept-Fachdienst gelöscht.
  • Alle für den Versicherten im E-Rezept-Fachdienst gespeicherten Abrechnungsinformationen sind gelöscht.
Standardablauf
  1. Einwilligung Abrechnungsinformation löschen
[<=]

Mit dem Anwendungsfall "Einwilligungsinformation abfragen" werden die bestehenden Einwilligungen bestimmt. Das E-Rezept-FdV bestimmt die Consent-ID der Ressource mit Consent.category.coding.code = CHARGCONS.

A_22171 - E-Rezept-FdV: Einwilligung Abrechnungsinformation widerrufen - Löschrequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung Abrechnungsinformation widerrufen" zum Löschen der Information im E-Rezept-Fachdienst die HTTP-Operation DELETE /Consent/?category=CHARGCONS mit 

  • ACCESS_TOKEN im Authorization-Header
ausführen. [<=]

6.2.6 Abrechnungsinformationen abrufen

6.2.6.1 Liste von Abrechnungsinformationen abrufen

Mit diesem Anwendungsfall kann der Nutzer eine Liste aller Abrechnungsinformationen vom E-Rezept-Fachdienst abrufen, welche für den Versicherten bereitgestellt wurden.

A_22172 - E-Rezept-FdV: Liste Abrechnungsinformationen abrufen

Das E-Rezept-FdV MUSS den Anwendungsfall "Abrechnungsinformation durch den Versicherten abrufen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 19 : TAB_FdVERP_xxx – Liste Abrechnungsinformationen abrufen

Name Liste Abrechnungsinformationen abrufen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Liste zur Weiterverarbeitung (bspw. Herunterladen der detaillierten Informationen) bereit.
Standardablauf
  1. Mehrere Datensätze abfragen
[<=]

A_22173 - E-Rezept-FdV: Liste Abrechnungsinformationen abrufen - Abfragerequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Liste Abrechnungsinformationen abfragen" zum Abrufen der Information vom E-Rezept-Fachdienst die HTTP-Operation GET /ChargeItem mit 

  • ACCESS_TOKEN im Authorization-Header
ausführen. [<=]

Im Response ist eine Liste von ChargeItem-Ressourcen enthalten. Für jede ChargeItem-Ressource ist die folgende Information enthalten:

  • Prescription-ID

6.2.6.2 Abrechnungsinformation abrufen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Abrechnungsinformation zu einem E-Rezept vom E-Rezept-Fachdienst herunterladen.

A_22174 - E-Rezept-FdV: Abrechnungsinformation abrufen

Das E-Rezept-FdV MUSS den Anwendungsfall "Abrechnungsinformation durch den Versicherten abrufen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 20 : TAB_FdVERP_xxx – Abrechnungsinformation abrufen

Name Abrechnungsinformation abrufen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat sich gegenüber der TI authentisiert.
  • Die Prescription-ID zur Abrechnungsinformation ist bekannt
Nachbedingung
  • Die Daten stehen zur Weiterverarbeitung (bspw. Anzeige oder Übermittlung zum Kostenträger) bereit.
Standardablauf
  1. Prescription-ID bestimmen
  2. Datensatz abfragen
[<=]

A_22175 - E-Rezept-FdV: Abrechnungsinformation abrufen - Abfragerequest einzelner Datensatz

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation abfragen" zum Abrufen der Information zu einem einzelnen Datensatz vom E-Rezept-Fachdienst die HTTP-Operation GET /ChargeItem/<id>/ mit 

  • ACCESS_TOKEN im Authorization-Header
  • Prescription-ID in URL <id>
ausführen. [<=]

Im Response ist die ChargeItem Ressource und die zugehörigen Detaildatensätze Verordnungsdatensatz, PKV-Abgabedatensatz, Quittung und der AccessCode zum Ändern enthalten.

6.2.7 Abrechnungsinformation-Token als 2D-Code anzeigen

Mit diesem Anwendungsfall kann der Nutzer den AccessCode zum Ändern als 2D-Code auf dem Bildschirm seines E-Rezept-FdVs anzeigen lassen, um es direkt in der Apotheke vorzuzeigen und die Apotheke damit zu berechtigen, die Abrechnungsinformation vom E-Rezept-Fachdienst abzurufen und den PKV-Abgabedatensatz einmalig zu ändern.

A_22726 - E-Rezept-FdV: 2D-Code Abrechnungsinformation anzeigen - E-Rezept auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein E-Rezept für die Anzeige des 2D-Code der Abrechnungsinformation auszuwählen, um einer Apotheke das Einscannen zu ermöglichen und sie somit für das Ändern des PKV-Abgabedatensatzes zu berechtigen. [<=]

A_22727 - E-Rezept-FdV: 2D-Code Abrechnungsinformation anzeigen - Abrechnungsinformation-Token erstellen

Das E-Rezept-FdV MUSS für das ausgewählte E-Rezept den Abrechnungsinformation-Token erstellen. [<=]

Für die Beschreibung der Struktur des Abrechnungsinformation-Token siehe [gemSpec_DM_eRp].

A_22728 - E-Rezept-FdV: 2D-Code Abrechnungsinformation anzeigen

Das E-Rezept-FdV MUSS mit dem erstellten Abrechnungsinformation-Token einen 2D-Code erstellen und auf dem Display des Endgerätes anzeigen.  [<=]

6.2.8 Abrechnungsinformation-Token einer Apotheke übermitteln

Mit diesem Anwendungsfall kann der Nutzer den AccessCode zum Ändern mittels einer Nachricht einer Apotheke übermitteln und die Apotheke damit zu berechtigen, die Abrechnungsinformation vom E-Rezept-Fachdienst abzurufen und den PKV-Abgabedatensatz einmalig zu ändern.

A_22735 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln - E-Rezept auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein E-Rezept auszuwählen, um den zugehörigen Abrechnungsinformation-Token der Apotheke, welche den PKV-Abgabedatensatz bereitgestellt hat, mittels einer Nachricht zu übermitteln und die Apotheke somit für das Ändern des PKV-Abgabedatensatzes zu berechtigen. [<=]

A_22736 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln - Apotheke auswählen

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation-Token einer Apotheke übermitteln" es dem Nutzer ermöglichen, die Apotheke auszuwählen, welche die Abrechnungsinformation bereitgestellt hat. [<=]

A_22737 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln - freie Textnachricht

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine freie Textnachricht zu erfassen, welche der Nachricht an die Apotheke hinzugefügt wird. [<=]

Hinweis: Die Textnachricht ist optional.

Innerhalb der Textnachricht sind keine Internet-Links und keine  Non-Printable-Characters zulässig.

A_22738 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" aus [gemSysL_eRp] für das Zuweisen eines E-Rezepts gemäß TAB_FdVERP_xxx umsetzen.

Tabelle 21 : TAB_FdVERP_xxx – Abrechnungsinformation-Token einer Apotheke übermitteln

Name Abrechnungsinformation-Token einer Apotheke übermitteln
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Die ChargeItem-Ressource ist im E-Rezept-Frontend lokal gespeichert.
  • Die Authentisierung des Nutzers ist erfolgt
Nachbedingung
  • Die Apotheke kann eine Nachricht mit dem Abrechnungsinformation-Token vom E-Rezept-Fachdienst abrufen
Standardablauf
  1. Abrechnungsinformation-Token erstellen
  2. Nachricht erstellen
  3. Nachricht auf dem E-Rezept-Fachdienst einstellen
Varianten / Alternativen
  • 2D-Code anzeigen
[<=]

Für die Spezifikation des Abrechnungsinformation-Token siehe [gemSpec_DM_eRp].

A_22739-01 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln - Nachricht erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation-Token einer Apotheke übermitteln" eine FHIR Ressource Communication des Profils https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq mit 

  • Telematik-ID der ausgewählten abgebenden LEI in recipient
  • Textnachricht in payload contentString
  • E-Rezept-Token in basedOn reference auf Task inkl. AccessCode als "/ChargeItem/<id>?ac=..." 
erstellen. [<=]

Für die Spezifikation der Communication Ressource siehe [gemSpec_DM_eRp].

A_22740 - E-Rezept-FdV: Abrechnungsinformation-Token übermitteln - Nachricht auf E-Rezept-Fachdienst einstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation-Token einer Apotheke übermitteln" zum Einstellen der Nachricht die HTTP-Operation POST /Communication  mit

  • ACCESS_TOKEN im Authorization-Header
  • Communication Ressource in HTTP-Request-Body
ausführen. [<=]

6.2.9 Abrechnungsinformation markieren

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) Markierungen zu seiner Abrechnungsinformation setzen. Diese werden auf dem E-Rezept-Fachdienst gespeichert.

A_22176 - E-Rezept-FdV: Abrechnungsinformation markieren - Markierungen auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine oder mehrere der folgenden Inhalte als Markierung für eine Abrechnungsinformation zu wählen oder abzuwählen:

  • zur Abrechnung bei Krankenversicherung eingereicht (extention "insuranceProvider")
  • zur Abrechnung bei der Beihilfe eingereicht (extention "subsity")
  • zur Einreichung beim Finanzamt verwendet (extention "taxOffice")
[<=]

A_22177 - E-Rezept-FdV: Abrechnungsinformation markieren

Das E-Rezept-FdV MUSS den Anwendungsfall "Abrechnungsinformation durch den Versicherten markieren" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 22 : TAB_FdVERP_xxx – Abrechnungsinformation markieren

Name Abrechnungsinformation markieren
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat eine oder mehrere Markierungen aus- oder abgewählt.
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Markierungen sind im E-Rezept-Fachdienst gespeichert.
Standardablauf
  1. ChargeItem erstellen
  2. Prescription-ID der Abrechnungsinformation bestimmen
  3. Daten speichern
[<=]

A_22178 - E-Rezept-FdV: Abrechnungsinformation markieren – ChargeItem erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation markieren" in der zuvor vom E-Rezept-Fachdienst heruntergeladene FHIR-Ressource ChargeItem die Extention "ChargeItem.extension:markingFlag" gemäß der Auswahl der Markierungen anpassen. [<=]

Für die Spezifikation der Ressource ChargeItem siehe [gemSpec_DM_eRp].

A_22179 - E-Rezept-FdV: Abrechnungsinformation markieren - Speicherrequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation markieren" zum Speichern der Information im E-Rezept-Fachdienst die HTTP-Operation PUT /ChargeItem/<id> mit 

  • ACCESS_TOKEN im Authorization-Header
  • Prescription-ID in URL <id>
  • ChargeItem im http-Body des Aufrufs als data
ausführen. [<=]

6.2.10 Abrechnungsinformation löschen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Abrechnungsinformation zu einem E-Rezept, die auf dem E-Rezept-Fachdienst gespeichert ist, löschen.

A_22180 - E-Rezept-FdV: Abrechnungsinformation löschen - Abrechnungsinformationen zum Löschen auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine Abrechnungsinformationen zum Löschen auf dem E-Rezept-Fachdienst zu markieren. [<=]

A_22181 - E-Rezept-FdV: Abrechnungsinformation löschen - Bestätigung

Das E-Rezept-FdV MUSS vom Nutzer eine Bestätigung einholen, dass die selektierte Abrechnungsinformation gelöscht werden soll und die Möglichkeit geben, das Löschen abzubrechen. [<=]

Das E-Rezept-FdV muss im Rahmen der Bestätigung darauf hinweisen, dass mit dem Löschen der Abrechnungsinformation die Daten des Verordnungsdatensatzes, des PKV-Abgabedatensatzes und der Quittung gelöscht werden und somit ein Neueinstellen der Abrechnungsinformation durch die Apotheke ggf. nicht mehr möglich ist.

Das E-Rezept-FdV kann es dem Nutzer ermöglichen, den Anwendungsfall zum lokalen Löschen für die zu löschende Abrechnungsinformation zusammen mit dem Löschen auf dem E-Rezept-Fachdienst auszuführen.

A_22182 - E-Rezept-FdV: Abrechnungsinformation löschen

Das E-Rezept-FdV MUSS den Anwendungsfall "Abrechnungsinformation löschen" gemäß TAB_FdVERP_xxx umsetzen. 

Tabelle 23 : TAB_FdVERP_xxx – Abrechnungsinformation löschen

Name Abrechnungsinformation löschen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Versicherter
Vorbedingung
  • Der Nutzer hat die Abrechnungsinforamtion vom E-Rezept-Fachdienst heruntergeladen
  • Der Nutzer hat die Abrechnungsinformation zum Löschen markiert und das Löschen bestätigt.
  • Der Nutzer hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die ausgewählten Abrechnungsinformation ist vom E-Rezept-Fachdienst unwiederbringlich gelöscht.
Standardablauf
  1. Prescription-ID der Abrechnungsinformation bestimmen
  2. Abrechnungsinformation löschen
[<=]

A_22183 - E-Rezept-FdV: Abrechnungsinformation löschen - Löschrequest

Das E-Rezept-FdV MUSS im Anwendungsfall "Abrechnungsinformation löschen" die HTTP-Operation DELETE /ChargeItem/<id> des E-Rezept-Fachdienstes mit

  • ACCESS_TOKEN im Authorization-Header
  • Prescription-ID in URL <id>
ausführen. [<=]

Der E-Rezept-Fachdienst bewahrt eine Abrechnungsinformation für 10 Jahre auf. Danach werden sie vom E-Rezept-Fachdienst automatisch  gelöscht.

A_22707 - E-Rezept-FdV: Hinweis automatisches Löschen Abrechnungsinformationen

Das E-Rezept-FdV MUSS den Nutzer vor Erreichen der Aufbewahrungsfrist der Abrechnungsinformation einen Hinweis zum automatischen Löschen geben, um dem Nutzer die Möglichkeit zu geben, falls gewünscht die Daten herunterzuladen und zu archivieren. [<=]

6.2.11 Abrechnungsinformation exportieren

Mit diesem Anwendungsfall kann der Versicherte die Abrechnungsinformation aus dem FdV exportieren, um es zur Abrechnung einzureichen oder zu archivieren.

A_22184 - E-Rezept-FdV: Abrechnungsinformation exportieren - PDF/A erstellen

Das E-Rezept-FdV MUSS auf Basis der vom E-Rezept-Fachdienst zu einer Prescription-ID heruntergeladenen ChargeItem, Verordnungsdatensatz, PKV-Abgabedatensatz und Quittung Ressourcen

  • einen Ausdruck erstellen,
  • für den Ausdruck ein PDF gemäß PDF/A-3-Standard (ISO 19005-3) erstellen,
  • in das Dokument den signierten Verordnungsdatensatz (<Prescription-ID>_verordnung.ps7), den signierten PKV-Abgabedatensatz (<Prescription-ID>_abrechnung.ps7) und den signierten Quittung Datensatz (<Prescription-ID>_quittung.ps7) gemäß PDF/A-3 einbetten.
[<=]

A_22185 - E-Rezept-FdV: Abrechnungsinformation exportieren - PDF teilen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, das erstellte PDF mit anderen Apps zu teilen, um den Versicherten die Möglichkeit zu geben, seine Abrechnungsinformation an Krankenversicherungen oder andere Institutionen zur Abrechnung zu übermitteln. [<=]

Das schließt das Versenden per E-Mail oder die Ablage im Dateisystem ein.

6.3 Anforderungen an das Primärsystem der verordnenden LEI

Das nachfolgenden Kapitel wird in das Dokument [gemILF_PS_eRp] übernommen.

6.3.1 E-Rezept erstellen - Workflow 200/209

In Bezug auf die Interoperabilität mit den Diensten der TI ergeben sich keine geänderten oder zusätzlichen Anforderungen für das Primärsystem der verordnenden Leistungserbringerinstitutionen. 

Der Verordnungsdatensatz für PKV-Versicherte basiert auf demselben Datenmodell wie für GKV-Versicherte.

Folgende Anforderungen bestehen für einen Verordnungsdatensatz:

A_22541-01 - PS verordnende LEI: E-Rezept erstellen – Flowtype 200/209 – KVNR als Identifier

Das PS der verordnenden LEI MUSS im Verordnungsdatensatz für ein E-Rezept des Flowtype 200 oder 209 als Identifier des Patienten in Patient.identifer.value die KVNR des Versicherten verwenden.
[<=]

Im Verordnungsdatensatz für ein E-Rezept des Flowtype "200" oder "209" muss für Patient.identifier.type.coding.code der Wert "PKV" gesetzt werden.

Im Verordnungsdatensatz für ein E-Rezept des Flowtype "200" oder "209" wird das Patient.identifer.system nicht angegeben.

A_22542-01 - PS verordnende LEI: E-Rezept erstellen – Flowtype 200/209 – Versicherungstyp PKV

Das PS der verordnenden LEI MUSS im Verordnungsdatensatz für ein E-Rezept des Flowtype 200 oder 209 für Coverage.type.coding.code den Wert "PKV" verwenden.
[<=]

Hinweis: Diese Anforderungen beschreiben nicht abschließend die Unterschiede zwischen Verordnungsdatensätzen für PKV-Versicherte und GKV-Versicherte.

In der Operation "E-Rezept erstellen" wird der Workflow-Typ "200" bzw. "209" als Rezept-Typ im Parameter FlowType übermittelt, um einen Workflow für PKV-Versicherte zu initiieren.

6.4 Anforderungen an das Primärsystem der abgebenden LEI

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

6.4.1 Kommunikation zu Diensten der TI

Das Kapitel 5.1.1 aus [gemILF_PS_eRp] wird erweitert.

Die Tabelle TAB_ILFERP_014 wird wie folgt ergänzt:

Tabelle 24 : TAB_FdVERP_014 - HTTP-Header "X-erp-resource"

Operation X-erp-resource
GET /ChargeItem/<id> ChargeItem
POST /ChargeItem/ ChargeItem
PUT /ChargeItem/<id> ChargeItem

6.4.2 E-Rezept abrufen

Das Kapitel 5.3.1 aus [gemILF_PS_eRp] wird erweitert.

Der Anwendungsfall "E-Rezept abrufen" wird identisch, wie bei einem E-Rezept des Flowtype "160" umgesetzt.

Für den Flowtype "200" und "209" wird im Response Bundle eine Consent Ressource mit Consent.category.coding.code = CHARGCONS übermittelt, falls der Versicherte eine Einwilligung zum Speichern von Abrechnungsinformationen erteilt hat. Diese Information kann in der Abstimmung mit dem Versicherten genutzt werden, ob die Abrechnungsinformation digital oder als Papierbeleg bereitgestellt wird.

6.4.3 E-Rezept löschen

Das Kapitel 5.3.5 aus [gemILF_PS_eRp] wird erweitert.

A_22742 - PS abgebende LEI: E-Rezepte löschen - Flowtype 200/209 - Warnung Abgabeinformationen

Das PS der abgebenden LEI MUSS, falls der Nutzer ein E-Rezept mit Flowtype 200 oder 209 zum Löschen ausgewählt hat und für das E-Rezept noch keine Abrechnungsinformationen bereitgestellt wurden, eine Warnung anzeigen, dass ein Bereitstellen der Abrechnungsinformationen zum E-Rezept nach dem Löschen des E-Rezepts nicht mehr möglich ist. [<=]

6.4.4 Abrechnungsinformation bereitstellen

Mit diesem Anwendungsfall stellt die abgebende LEI die Abrechnungsinformation zu einem E-Rezept auf dem E-Rezept-Fachdienst ein.

A_22708 - PS abgebende LEI: Abrechnungsinformation bereitstellen – Einwilligung muss vorliegen

Das PS der abgebenden LEI DARF NICHT Abrechnungsinformation auf dem E-Rezept-Fachdienst bereitstellen, wenn ihm nicht zuvor die Information über die Einwilligung des Versicherten vom E-Rezept-Fachdienst übertragen wurde. [<=]

A_22186 - PS abgebende LEI: Abrechnungsinformation bereitstellen – E-Rezept auswählen

Das PS der abgebenden LEI MUSS es dem Nutzer ermöglichen, ein E-Rezept auszuwählen, zu dem die Abrechnungsinformation auf dem E-Rezept-Fachdienst bereitgestellt werden soll. [<=]

Die Information, dass der Versicherte die Einwilligung zum Speichern der Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt hat, wird im Anwendungsfall "E-Rezept abrufen" übermittelt.

A_22187 - PS abgebende LEI: Abrechnungsinformation bereitstellen

Das PS der abgebenden LEI MUSS den Anwendungsfall "Abrechnungsinformation durch Abgebenden bereitstellen" gemäß TAB_ILFERP_xxx umsetzen. 

Tabelle 25 : TAB_ILFERP_xxx – Abrechnungsinformation bereitstellen

Name Abrechnungsinformation bereitstellen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung
  • Die abgebende LEI hat den Workflow zum E-Rezept mit dem Anwendungsfall „Quittung abrufen“ abgeschlossen. Die Information Task-ID und dem Secret zum E-Rezept sind bekannt.
  • Im PS liegt die Information vor, dass der Versicherte die Einwilligung zum Speichern der Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt hat.
  • Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Der PKV-Abgabedatensatz ist auf dem  E-Rezept-Fachdienst gespeichert.
Standardablauf
  1. PKV-Abgabedatensatz erstellen
  2. PKV-Abgabedatensatz mit Konnektor signieren
  3. ChargeItem erstellen
  4. Task-ID und Geheimnis des E-Rezepts bestimmen
  5. PKV-Abgabedatensatz speichern
[<=]

A_22188 - PS abgebende LEI: Abrechnungsinformation bereitstellen – PKV-Abgabedatensatz erstellen

Das PS der abgebenden LEI MUSS im Anwendungsfall "Abrechnungsinformation bereitstellen" eine FHIR-Ressource des PKV-Abgabedatensatzes mit den Informationen zur Abrechnung des abgegebenen Medikaments erstellen. [<=]

Für die Spezifikation der Ressource PKV-Abgabedatensatz siehe [gemSpec_DM_eRp].

Das Signieren des PKV-Abgabedatensatzes erfolgt gemäß [gemILF_PS_eRp] Kap. "Abgabedatensatz signieren". Für die Wahl des Signaturverfahrens (QES oder nonQES) gelten die rechtlichen Vorgaben.

A_22189 - PS abgebende LEI: Abrechnungsinformation bereitstellen – ChargeItem erstellen

Das PS der abgebenden LEI MUSS im Anwendungsfall "Abrechnungsinformation bereitstellen" eine FHIR-Ressource ChargeItem erstellen und den PKV-Abgabedatensatzes als contained Ressource einfügen. [<=]

Für die Spezifikation der Ressource ChargeItem siehe [gemSpec_DM_eRp].

A_22190 - PS abgebende LEI: Abrechnungsinformation bereitstellen - Speicherrequest

Das PS der abgebenden LEI MUSS im Anwendungsfall "Abrechnungsinformation bereitstellen" die HTTP-Operation POST /ChargeItem/ des E-Rezept-Fachdienstes mit

  • ACCESS_TOKEN im Authorization-Header
  • Task-ID als URL-Parameter ?task=
  • Geheimnis in URL-Parameter ?secret=
  • ChargeItem im http-Body des Aufrufs als data
ausführen. <= [<=]

Wenn das E-Rezept bereits vom E-Rezept-Fachdienst gelöscht wurde, dann enthält der Response den Fehlercode 405. Das Bereitstellen der Abrechnungsinformation zu einem E-Rezept ist nur möglich bevor das E-Rezept gelöscht wurde.

Wenn der Versicherte zwischenzeitlich die Einwilligung zum Speichern von Abrechnungsinformationen im E-Rezept-Fachdienst widerrufen hat, dann enthält der Response den Fehlercode 403.

6.4.5 PKV-Abgabedatensatz ändern

Mit diesem Anwendungsfall kann die abgebende LEI den PKV-Abgabedatensatz zu einem E-Rezept, welche die abgebende LEI zuvor auf dem E-Rezept-Fachdienst bereitgestellt hat, ändern. Als Voraussetzung muss der Versicherte der abgebenden LEI einen AccessCode übermitteln, um die abgebende LEI zu berechtigen.

A_22191 - PS abgebende LEI: PKV-Abgabedatensatz ändern - PKV-Abgabedatensatz zum Ändern auswählen

Das PS der abgebenden LEI MUSS es dem Nutzer ermöglichen, die Abrechnungsinformation zu einem E-Rezept zum Ändern auf dem E-Rezept-Fachdienst auszuwählen. [<=]

A_22192 - PS abgebende LEI: PKV-Abgabedatensatz ändern

Das PS der abgebenden LEI MUSS den Anwendungsfall "PKV-Abgabedatensatz durch Abgebenden ändern" gemäß TAB_ILFERP_xxx umsetzen. 

Tabelle 26 : TAB_ILFERP_xxx – Abrechnungsinformation ändern

Name PKV-Abgabedatensatz ändern
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung
  • Der Versicherte hat den AccessCode übermittelt.
  • Die abgebende LEI hat die Abrechnungsinformation für das E-Rezept auf dem E-Rezept-Fachdienst bereitgestellt. Die Information zur Prescription-ID ist bekannt.
  • Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Der geänderte PKV-Abgabedatensatz ist auf dem E-Rezept-Fachdienst gespeichert.
Standardablauf
  1. PKV-Abgabedatensatz erstellen
  2. PKV-Abgabedatensatz mit Konnektor signieren
  3. Prescription-ID und AccessCode der Abrechnungsinformation bestimmen
  4. Abrechnungsinformation speichern
[<=]

A_22193 - PS abgebende LEI: PKV-Abgabedatensatz ändern – PKV-Abgabedatensatz erstellen

Das PS der abgebenden LEI MUSS im Anwendungsfall "PKV-Abgabedatensatz ändern" eine FHIR-Ressource des PKV-Abgabedatensatzes mit den Informationen zur Abrechnung des abgegebenen Medikaments erstellen. [<=]

Für die Spezifikation der Ressource PKV-Abgabedatensatz siehe [gemSpec_DM_eRp].

Das Signieren des PKV-Abgabedatensatzes erfolgt gemäß [gemILF_PS_eRp] Kap. "Abgabedatensatz signieren".

A_22194 - PS abgebende LEI: PKV-Abgabedatensatz ändern – ChargeItem erstellen

Das PS der abgebenden LEI MUSS im Anwendungsfall "PKV-Abgabedatensatz ändern" eine FHIR-Ressource ChargeItem erstellen und den PKV-Abgabedatensatzes als contained Ressource einfügen. [<=]

Für die Spezifikation der Ressource ChargeItem siehe [gemSpec_DM_eRp].

A_22195 - PS abgebende LEI: PKV-Abgabedatensatz ändern - Speicherrequest

Das PS abgebende LEI MUSS im Anwendungsfall "PKV-Abgabedatensatz ändern" die HTTP-Operation PUT /ChargeItem/<id>/ des E-Rezept-Fachdienstes mit

  • ACCESS_TOKEN im Authorization-Header
  • Prescription-ID in URL <id>
  • AccessCode in URL-Parameter ?ac=
  • ChargeItem im http-Body des Aufrufs als data
ausführen. [<=]

Wenn der Versicherte zwischenzeitlich die Einwilligung zum Speichern von Abrechnungsinformationen im E-Rezept-Fachdienst widerrufen hat, dann enthält der Response den Fehlercode 403.

6.4.6 Abrechnungsinformation abrufen

Mit diesem Anwendungsfall kann eine abgebende LEI die Abrechnungsinformation vom E-Rezept-Fachdienst abrufen, welche durch sie zuvor bereitgestellt und noch nicht gelöscht wurde. Als Voraussetzung muss der Versicherte der abgebenden LEI einen AccessCode übermitteln, um die abgebende LEI zu berechtigen.

A_22202 - PS abgebende LEI: Abrechnungsinformation abrufen

Das PS der abgebenden LEI MUSS den Anwendungsfall "Abrechnungsinformation durch Abgebenden abrufen" gemäß TAB_ILFERP_xxx umsetzen. 

Tabelle 27 : TAB_ILFERP_xxx – Abrechnungsinformation abrufen

Name Abrechnungsinformation abrufen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung
  • Der Versicherte hat den AccessCode übermittelt.
  • Die Prescription-ID der Abrechnungsinformation ist im Primärsystem bekannt
  • Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Die Informationen zum PKV-Abgabedatensatz liegen im PS vor
Standardablauf
  1. Prescription-ID und AccessCode der Abrechnungsinformation bestimmen
  2. Abrechnungsinformation abrufen
[<=]

A_22203 - PS abgebende LEI: Abrechnungsinformation abrufen - Leserequest

Das PS abgebende LEI MUSS im Anwendungsfall "Abrechnungsinformation abrufen" die HTTP-Operation GET /ChargeItem/<id> des E-Rezept-Fachdienstes mit

  • ACCESS_TOKEN im Authorization-Header
  • Prescription-ID in URL <id>
  • AccessCode in URL-Parameter ?ac=
ausführen. [<=]

Im Response ist die ChargeItem Ressource mit dem Verordnungsdatensatz und dem zugehörige PKV-Abgabedatensatz enthalten.

6.4.7 2D-Code scannen

Das Kapitel 5.3.10 aus [gemILF_PS_eRp] wird erweitert.

Die Übermittlung eines Abrechnungsinformation-Token kann ebenfalls persönlich in der Apotheke vor Ort erfolgen. Hierzu präsentiert der Versicherte dem Mitarbeiter der abgebenden LEI einen 2D-Code auf dem Display seines mobilen Gerätes.

A_19630-01 - PS abgebende LEI: 2D-Code scannen

Das PS der abgebenden LEI MUSS es dem Nutzer ermöglichen, einen 2D-Code für das Zuweisen von E-Rezepten oder zum Ändern einer Abrechnungsinformation einzuscannen. [<=]

Der 2D-Code eines Abrechnungsinformation-Token enthält genau einen Token.

A_19631-01 - PS abgebende LEI: 2D-Code scannen - Token extrahieren

Das PS der abgebenden LEI MUSS den oder die Token aus einem eingescannten 2D-Code extrahieren. [<=]

Für den Aufbau des 2D-Codes und Struktur des Abrechnungsinformation-Token siehe [gemSpec_DM_eRp].

Mit der Information aus dem Abrechnungsinformation-Token kann die Abrechnungsinformation vom E-Rezept-Fachdienst heruntergeladen und der PKV-Abgabedatensatz einmalig auf dem E-Rezept-Fachdienst aktualisiert werden.

6.4.8 Nachrichten von Versicherten empfangen

Das Kapitel 5.3.6 aus [gemILF_PS_eRp] wird erweitert.

Eine Communication Ressource kann unterschiedlichen Typs sein und beinhaltet typabhängige, fachliche Informationen:

  • Übermittlung Abrechnungsinformation-Token (GEM_ERP_PR_Communication_ChargChangeReq)
    • Referenz auf ein ChargeItem inkl. Zugriffsberechtigung
    • optional: Mitteilung/Text

Wenn die Nachricht einen Abgabeinformation-Token enthält, dann hat der Versicherte die abgebende LEI autorisiert, den PKV-Abgabedatensatz zu ändern.

6.5 Daten- und Informationsmodell

6.5.1 Fast Healthcare Interoperability Resources

Die Spezifikation der Ressourcen zum PKV-Abgabedatensatz wird durch DAV und dem Verband der PKVen vereinbart. Siehe Simplifier-Projekt https://simplifier.net/eRezeptAbgabedatenPKV .

Es werden neue Profile im Simplifier-Projekt E-Rezept-Workflow https://simplifier.net/erezept-abrechnungsinformationen  eingeführt:

  • Consent - Ressource zur Verwaltung der Einwilligung
  • ChargeItem - Ressource zur Verwaltung der Abrechnungsinformation
  • ChargeItemChangeRequest - Communication Ressource für die Übermittlung eines Abrechnungsinformations-Token
  • ChargeItemChangeReply - Communication Ressource für Antwort auf die Übermittlung eines Abrechnungsinformations-Token

Es werden Ergänzungen an den folgenden Artefakten vorgenommen:

Das Kapitel 2.1 aus [gemSpec_DM_eRp] wird erweitert.

A_19299-02 - FHIR-Ressource Communication

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Communication gemäß der FHIR-Profilierungen 

unterstützen. [<=]

A_22204 - FHIR-Ressource PKV-Abgabedatensatz

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource PKV-Abgabedatensatz gemäß der FHIR-Profilierung http://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PKV-PR-ERP-AbgabedatenBundle  unterstützen.  [<=]

A_22205-01 - FHIR-Ressource ChargeItem

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource ChargeItem gemäß der FHIR-Profilierung https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_ChargeItem unterstützen. [<=]

A_22206-01 - FHIR-Ressource Consent

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource Consent gemäß der FHIR-Profilierung https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Consent unterstützen. [<=]

6.5.2 Erweiterungen der Prozessparameter

Das Kapitel 2.4 aus [gemSpec_DM_eRp] wird erweitert.

Erweiterung A_19445-* - FHIR FLOWTYPE für Prozessparameter

A_19445-08 - FHIR FLOWTYPE für Prozessparameter

Der E-Rezept-Fachdienst MUSS in Abhängigkeit des Task-Parameters FLOWTYPE und dem in der http-POST-Operation /Task/<id>/$activate übergebenen, gültig signierte E-Rezept-Bundle die Attribute des zu erzeugenden Tasks wie folgt belegen:  

FLOWTYPE Attributierung des zu erzeugenden Tasks
160 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.PrescriptionType.valueCoding.display = "Muster 16 (Apothekenpflichtige Arzneimittel)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
169 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "Muster 16 (Direkte Zuweisung)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
200 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "PKV (Apothekenpflichtige Arzneimittel)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
209 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "PKV (Direkte Zuweisung)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
damit dem Versicherten Informationen über die Gültigkeit (Erstattungsfrist durch die Kostenträger = AcceptDate, Einlösefrist = ExpiryDate) des E-Rezepts angezeigt werden und der Workflow auf Basis der gewählten Parameter gesteuert werden kann. [<=]

6.5.3 2D-Code für Abrechnungsinformation

Um auf Wunsch des Versicherten den PKV-Abgabedatensatz ändern zu können, muss die Apotheke das Wissen um die Referenz des ChargeItem und den AccessCode zum Nachweis der Berechtigung erlangen. Diese Informationen werden vom Versicherten zur Verfügung gestellt. Die Bereitstellung kann als Nachricht über den E-Rezept-Fachdienst oder durch Abscannen als 2D-Code vom Display der E-Rezept-FdV erfolgen. 

A_22729 - Datenstruktur Zugriffsinformationen für Abrechnungsinformation

Das E-Rezept-FdV MUSS zum Erstellen eines Token für die Zugriffsinformationen für eine Abrechnungsinformation die ID auf einen ChargeItem zusammen mit dem AccessCode zum Ändern aus den lokal verfügbaren Informationen einer Abrechnungsinformation als URL in der Form: 2D-Code-Daten = "ChargeItem/" + ChargeItem.id  + "?ac=" + AccessCode zusammenstellen, damit diese Zeichenkette als Referenz in einer E-Rezept-Nachricht oder für die Generierung eines 2D-Codes verwendet werden kann. [<=]

Beispiel für Abrechnungsinformation-Token:

"ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612"

A_22730 - Generierung 2D-Code Abrechnungsinformation-Token

Das E-Rezept-FdV MUSS einen Abrechnungsinformation-Token in JSON-Notation gemäß [JSON] der folgenden Form

  • 2D-Code-Daten = { "urls": [ "Abrechnungsinformation" ] }
darstellen, um daraus einen 2D-Code generieren zu können. [<=]

Beispiel für die Codierung als 2D-Code:

{
  "urls": [ "ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612" ]

}

6.5.4 Zugriffsprotokoll

Das Kapitel 2.5 aus [gemSpec_DM_eRp] wird erweitert.

A_19296-02 - E-Rezept-Fachdienst - Inhalt Protokolleintrag

Der E-Rezept-Fachdienst MUSS einen Protokolleintrag mit den folgenden Werten befüllen:

  • AuditEvent.text: Generierung eines HTML-<div>-Elements mit lesbarer Beschreibung in einfacher Sprache
  • AuditEvent.type: Fester Wert "rest" gemäß http://terminology.hl7.org/CodeSystem/audit-event-type 
  • AuditEvent.subtype: aus dem ValueSet https://www.hl7.org/fhir/valueset-audit-event-sub-type.html  gemäß http://hl7.org/fhir/restful-interaction 
    • "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource)
    • "read" beim lesenden Zugriff auf ein Datenobjekt mit Versichertenbezug
    • "update", wenn das Datenobjekt mit Versichertenbezug geändert/aktualisiert wird
    • "delete", wenn das Datenobjekt mit Versichertenbezug manuell oder automatisch gelöscht wird
  • AuditEvent.action: analog AuditEvent.subType (C, R, U, D) gemäß https://www.hl7.org/fhir/valueset-audit-event-action.html 
  • AuditEvent.recorded: aktuelle Systemzeit des E-Rezept-Fachdienstes
  • AuditEvent.outcome: Ergebnis der aufgerufenen Operation gemäß https://www.hl7.org/fhir/valueset-audit-event-outcome.html (0 = Erfolg, 4 = Fehler auf Clientseite, 8 = Serverfehler) 
  • AuditEvent.agent.type: Fester Wert "humanuser" aus  http://terminology.hl7.org/CodeSystem/extra-security-role-type 
  • AuditEvent.agent.name: Lesbarer Name aus Identity-Token des Zugreifenden, der die zu protokollierende Aktion getriggert hat, z.B. "Praxis Dr. Müller, Bahnhofstr. 78" oder Versicherter z.B. "Max Mustermann"
  • AuditEvent.agent.who: KVNR bzw. Telematik-ID des zugreifenden Nutzers aus Identity-Token, der diesen Protokolleintrag ausgelöst hat
  • AuditEvent.agent.requestor: Fester Wert "false", da keine Protokolleinträge von außen erzeugt werden
  • AuditEvent.soure.site: Fester Wert "E-Rezept-Fachdienst"
  • AuditEvent.soure.observer: Device-Informationen des E-Rezept-Fachdienstes (status, serialnumber=gemäß Release)
  • AuditEvent.entity.what: Referenz auf das betroffene Datenobjekt Task, ChargeItem, MedicationDispense oder Consent zum Abruf
  • AuditEvent.entity.name: Eintrag der KVNR des betroffenen Versicherten aus dem Identifier des protokollierten Datenobjekts (String)
  • AuditEvent.entity.description: Rezept-ID als Identifier, wird übernommen aus MedicationDispense, ChargeItem oder Task bzw. Consent.category.coding.code bei Anlegen oder Löschen eines Consent 
[<=]

6.6 Datenschutz und Sicherheit

Im Unterschied zu GKV-Versicherten erhalten PKV-Versicherte vom Apotheker Abrechnungsinformationen, die sie bei ihrer privaten Krankenversicherung zur Kostenerstattung einreichen können. Bei der Umsetzung durch das E-Rezept überträgt der Apotheker den PKV-Abgabedatensatz in den E-Rezept-Fachdienst, sofern der PKV-Versicherte in die Speicherung dieser Daten im E-Rezept-Fachdienst (einmalig) eingewilligt hat. Die Einwilligung erfolgt also gegenüber dem Anbieter des E-Rezept-Fachdienstes. Dort werden sie dann bis zu 10 Jahren gespeichert. Der PKV-Versicherte kann die Abrechnungsinformationen mit dem E-Rezept-FdV vom E-Rezept-Fachdienst herunterladen und für die Abrechnung an eine App der PKV bzw. der Beihilfe weiterleiten oder ausdrucken.

Dass dies nur für PKV-Versicherte gilt, muss in der Anwendung E-Rezept berücksichtigt werden:

A_22207 - Einwilligung in Verarbeitung von Abrechnungsinformationen nur für PKV-Versicherte

Die Fachanwendung E-Rezept MUSS sicherstellen, dass eine Einwilligung in die Verarbeitung von Abrechnungsinformationen nur für PKV-Versicherte möglich ist. [<=]

Nur für PKV-Versicherte, die in die Verarbeitung von Abrechnungsinformationen eingewilligt haben, darf die Verarbeitung auch stattfinden:

A_22208 - Verarbeitung von Abrechnungsinformationen nur nach Einwilligung

Die Fachanwendung E-Rezept MUSS sicherstellen, dass eine Verarbeitung von Abrechnungsinformationen nur für PKV-Versicherte erfolgt, die hierfür eingewilligt haben. [<=]

Für den E-Rezept-Fachdienst heißt dies:

A_22209 - Verarbeitung von Abrechnungsinformationen im E-Rezept-Fachdienst nur nach Einwilligung

Der E-Rezept-Fachdienst DARF NICHT Abrechnungsinformationen verarbeiten, wenn keine Einwilligung des PKV-Versicherten erfolgt ist. [<=]

Um zu vermeiden, dass der Anbieter des E-Rezept-Fachdienstes Zugriff auf ein Profil über alle PKV-Versicherte erhält, die in die Verarbeitung von Abrechnungsinformationen eingewilligt haben, wird die Information über die erfolgte Einwilligung in der VAU verarbeitet und verschlüsselt gespeichert. Dies hat zur Konsequenz, dass der Anbieter des E-Rezept-Fachdienstes keine Auskunft darüber erteilen kann, ob ein PKV-Versicherter seine Einwilligung in die Verarbeitung von Abrechnungsinformationen gegeben hat oder nicht. Die Nichtabstreitbarkeit einer erfolgten Einwilligung muss deshalb durch die technische Umsetzung sichergestellt werden:

A_22210 - Nichtabstreitbarkeit der Einwilligung

Die Fachanwendung E-Rezept MUSS sicherstellen, dass die technische Umsetzung der Einwilligung im E-Rezept-FdV und des Vermerkens dieser im E-Rezept-Fachdienst so zuverlässig ist, dass der Vermerk im E-Rezept-Fachdienst als nicht abstreitbar angesehen werden kann. [<=]

Hinweis: Neben dem Einsatz zuverlässiger Techniken wird die Zuverlässigkeit über Produktgutachten geprüft, die den E-Rezept-FdV-Anteil und den E-Rezept-Fachdienstanteil prüfen.

Die Speicherdauer von Abrechnungsinformationen im E-Rezept-Fachdienst ist gesetzlich auf maximal zehn Jahre begrenzt:

A_22211 - Löschen von Abrechnungsinformationen nach zehn Jahren

Der E-Rezept-Fachdienst MUSS Abrechnungsinformationen zu einem E-Rezept nach zehn Jahren löschen. [<=]

Ein Apotheker kann Abrechnungsinformationen für einen PKV-Versicherten nur in den E-Rezept-Fachdienst transferieren, falls eine Einwilligung des PKV-Versicherten erfolgt ist. Apotheker sollen nicht für beliebige PKV-Versicherte prüfen können, ob sie in die Verarbeitung von Abrechnungsinformationen eingewilligt haben, sondern immer nur im Zusammenhang mit einem konkreten E-Rezept, für dessen Zugriff sie vom PKV-Versicherten autorisiert wurden:

A_22212 - Information über Möglichkeit des Speicherns der Abrechnungsinformationen nur für konkretes E-Rezept

Der E-Rezept-Fachdienst MUSS sicherstellen, dass abgebende Leistungserbringer die Information über die Möglichkeit des Speicherns der Abrechnungsinformationen im E-Rezept-Fachdienst nur im Kontext eines konkreten E-Rezepts erhalten. [<=]

A_22213 - Schutz der Abrechnungsinformationen

Der E-Rezept-Fachdienst MUSS die Abrechnungsinformationen während der Verarbeitung (inkl. Transport und Speichern) vor unberechtigter Einsichtnahme oder Manipulation schützen. [<=]

Hinweis: Diese Anforderung gilt auch gegenüber dem E-Rezept-Fachdienst-Anbieter/Betreiber. Das Verarbeiten und Speichern der Abrechnungsinformationen muss also in der VAU erfolgen und der Transport über die VAU-Verschlüsselung geschützt werden.

A_22214 - Protokollierung der Einwilligung bzw. des Widerrufs

Der E-Rezept-Fachdienst MUSS die Einwilligung in das Speichern der Abrechnungsinformationen und deren Widerruf – inkl. Zeitpunkt der Aktion – für den Versicherten protokollieren. [<=]

6.7 Betrieb

Die nachfolgenden Anforderungen werden in [gemSpec_Perf] und [gemKPT_Betr] übernommen.

6.7.1 Verfügbarkeit

Für die Hinzunahme der PKV-Versicherten in den E-Rezept-Fachdienst existieren keine abweichenden Anforderungen an die Verfügbarkeit. Es gelten die bereits existierenden Anforderungen an den E-Rezept-Fachdienst.

6.7.2 Last

Die initiale Planung der zu erwartenden Last des E-Rezept-Fachdienstes basierte auf der Analyse von realen Rezepten des Jahres 2018. Diese sieht im Jahr 2021 ein zu erwartendes Rezeptaufkommen von ca. 1 Milliarde Rezepten vor. Dies wurde auf Grundlage von 60 Millionen Versicherten in der GKV geschätzt. Die Hinzunahme von 10 Millionen Versicherten der PKV würde demzufolge theoretisch eine Steigerung von ~15 % unter der Annahme bedeuten, dass das Rezeptaufkommen für PKV-Versicherte dem von GKV-Versicherten entspricht. Die Infrastruktur des E-Rezept-Fachdienstes ist auf die doppelte Kapazität ausgelegt, demzufolge wird im ersten Schritt keine Notwendigkeit einer Erweiterung gesehen. Die tatsächliche Auslastung des Systems muss in der Praxis durch den Anbieter als Teil seines Capacity Managements überwacht und entsprechend den realen Gegebenheiten im Zuge der geplanten Reporting Sessions an die gematik gemeldet werden, um hier gegebenenfalls proaktiv zu skalieren.

6.7.3 Antwortzeiten

Die folgenden Änderungen werden an der [gemSpec_Perf] vorgenommen. Diese beinhalten Bearbeitungszeitvorgaben für die als relevant erachteten neuen Operationen.

Tabelle 28: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall 

ID
Datenmenge
[KB]
Mittelwert
[s]
ERP.UC_2_1
10
2,3
ERP.UC_2_3
10
1,3
ERP.UC_2_3_169 10 1,3
ERP.UC_2_3_200 10 1,3
ERP.UC_2_3_209 10 1,3
ERP.UC_3_1
10
0,7
ERP.UC_3_1_2 20 1,4
ERP.UC_3_3
10
1,3
ERP.UC_4_1
10
3,1
ERP.UC_4_1_2 10 3,1
ERP.UC_4_4
10
1,3
ERP.UC_4_4_2 10 1,3
ERP.UC_4_7 10 1,3

Tabelle 29: Tab_gemSpec_Perf_eRp-Fachdienst: Last- und Bearbeitungszeitvorgaben

UseCase-Bezug Fachdienstoperation Spitzenlast
[1/s]		 Mittelwert
[ms]		 99%-Quantil
[ms]
ERP.UC_2_1 POST /Task/$create 390 460 620
ERP.UC_2_3
 POST /Task/<id>/$activate mit Flowtype 160
335
400
550
ERP.UC_2_3_169 POST /Task/<id>/$activate mit Flowtype 169 5 400 550
ERP.UC_2_3_200 POST /Task/<id>/$activate mit Flowtype 200 50 400 550
ERP.UC_2_3_209 POST /Task/<id>/$activate mit Flowtype 209 5 400 550
ERP.UC_3_1 GET /Task 310 410 665
ERP.UC_3_1_2 GET /ChargeItem/<id> mit Rolle oid_versicherter 40 420 575
ERP.UC_3_3 POST /Communication 50 380 525
ERP.UC_4_1
 POST /Task/<id>/$accept
240
455
615
ERP.UC_4_1_2 GET /ChargeItem/<id> mit Rolle oid_oeffentliche_apotheke oder oid_krankenhausapotheke 30 420 575
ERP.UC_4_4 POST /Task/<id>/$close 120 375 520
ERP.UC_4_4_2 POST /ChargeItem 30 375 520
ERP.UC_4_7
 POST /Communication
75
380
525

Referenziert innerhalb der existierenden Anforderungen [gemSpec_Perf#A_20165-03], [gemSpec_Perf#A_20166] 

6.7.4 Bereitstellung von Betriebsdaten

Es ergeben sich die folgenden Änderungen in [gemSpec_Perf].

Tabelle 30: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst

$FD-operation
 Produkttyp Operation
 Schnittstelle zu
 useragent
ERP.UC_2_1
 E-Rezept-Fachdienst  POST /Task/$create
 verordnende LEI
 nein
ERP.UC_2_3
 E-Rezept-Fachdienst  POST /Task/<id>/$activate mit Flowtype 160
 verordnende LEI
 nein
ERP.UC_2_3_169 E-Rezept-Fachdienst POST /Task/<id>/$activate mit Flowtype 169 verordnende LEI nein
ERP.UC_2_3_200 E-Rezept-Fachdienst POST /Task/<id>/$activate mit Flowtype 200 verordnende LEI nein
ERP.UC_2_3_209 E-Rezept-Fachdienst POST /Task/<id>/$activate mit Flowtype 209 verordnende LEI nein
ERP.UC_3_1 E-Rezept-Fachdienst  GET /Task Versicherte
 ja
ERP.UC_3_1_2 E-Rezept-Fachdienst  GET /ChargeItem/<id> mit Rolle oid_versicherter Versicherte ja
ERP.UC_3_3 E-Rezept-Fachdienst POST /Communication Versicherte ja
ERP.UC_3_6 E-Rezept-Fachdienst GET /Task/<id> Versicherte ja
ERP.UC_4_1 E-Rezept-Fachdienst  POST /Task/<id>/$accept abgebende LEI nein
ERP.UC_4_1_2 E-Rezept-Fachdienst  GET /ChargeItem/<id> mit Rolle oid_oeffentliche_apotheke oder oid_krankenhausapotheke abgebende LEI nein
ERP.UC_4_4 E-Rezept-Fachdienst  POST /Task/<id>/$close abgebende LEI nein
ERP.UC_4_4_2 E-Rezept-Fachdienst  POST /ChargeItem abgebende LEI nein
ERP.UC_4_7 E-Rezept-Fachdienst  POST /Communication
 abgebende LEI nein

Referenziert innerhalb der existierenden Anforderungen [gemSpec_Perf#A_19733-02], [gemSpec_Perf#A_20048], [gemSpec_Perf#A_20047], [gemSpec_Perf#A_20043-04], [gemSpec_Perf#A_20040-02]

6.7.5 Performance-Kennzahlen

In der Tabelle [gemKPT_Betr#Tab_gemKPT_Betr_UC_Anwendungsfallübersicht] werden die folgenden Anwendungsfälle hinzugefügt:

Produkttyp ID Anwendungsfall Beschreibung Berichtsformat-Alias
PDT50 A11 ERP.UC_3_1_2 Abrechnungsinformationen durch den Versicherten abrufen
PDT50 A12 ERP.UC_4_4_2 Abrechnungsinformationen durch Abgebenden bereitstellen
PDT50 A14 ERP.UC_2_3_200 E-Rezept PKV einstellen
PDT50 A15 ERP.UC_2_3_209 E-Rezept PKV (Direktzuweisung) einstellen
PDT50 A16 ERP.UC_4_1_2 Abrechnungsinformationen durch Abgebenden abrufen

In der Tabelle [gemKPT_Betr#Tab_gemKPT_Betr_Performance-Kenngroessen] werden die folgenden Ergänzungen vorgenommen:

E-Rezept
Performance-Kenngröße Performance-Grösse Störungsampel Service-Level-Report Performance-Report Reports auf Basis Rohdaten Reports auf Basis Service Monitoring
PDT50-A11-D2-G04 Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum  x
 PDT50-A12-D2-G04 Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum x
PDT50-A14-D2-G04 Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum  x
PDT50-A15-D2-G04 Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum  x
PDT50-A16-D2-G04 Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum  x
 PDT50-A11-D2-G08 Mittlere Bearbeitungszeit pro Monat x
 PDT50-A12-D2-G08 Mittlere Bearbeitungszeit pro Monat x
PDT50-A14-D2-G08 Mittlere Bearbeitungszeit pro Monat x
PDT50-A15-D2-G08 Mittlere Bearbeitungszeit pro Monat x
PDT50-A16-D2-G08 Mittlere Bearbeitungszeit pro Monat x
PDT50-A11-D2-G30 Maximale Bearbeitungszeit x
PDT50-A12-D2-G30 Maximale Bearbeitungszeit x
PDT50-A14-D2-G30 Maximale Bearbeitungszeit x
PDT50-A15-D2-G30 Maximale Bearbeitungszeit x
PDT50-A16-D2-G30 Maximale Bearbeitungszeit x
PDT50-A11-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe x
PDT50-A12-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe x
PDT50-A14-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe x
PDT50-A15-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe x
PDT50-A16-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe x
PDT50-A11-D1-G01 Anzahl der Aufrufe im Erfassungszeitraum x
PDT50-A12-D1-G01 Anzahl der Aufrufe im Erfassungszeitraum x
PDT50-A14-D1-G01 Anzahl der Aufrufe im Erfassungszeitraum x
PDT50-A15-D1-G01 Anzahl der Aufrufe im Erfassungszeitraum x
PDT50-A16-D1-G01 Anzahl der Aufrufe im Erfassungszeitraum x
PDT50-A11-D1-G02 Datenmenge x
PDT50-A12-D1-G02 Datenmenge x
PDT50-A14-D1-G02 Datenmenge x
PDT50-A15-D1-G02 Datenmenge x
PDT50-A16-D1-G02 Datenmenge x
PDT50-A11-D3-G30 Fehlerquote im Erfassungszeitraum x
PDT50-A12-D3-G30 Fehlerquote im Erfassungszeitraum x
PDT50-A14-D3-G30 Fehlerquote im Erfassungszeitraum x
PDT50-A15-D3-G30 Fehlerquote im Erfassungszeitraum x
PDT50-A16-D3-G30 Fehlerquote im Erfassungszeitraum x
PDT50-A11-D3-G31 Anzahl der fehlerhaften Aufrufe im Erfassungszeitraum x
PDT50-A12-D3-G31 Anzahl der fehlerhaften Aufrufe im Erfassungszeitraum x
PDT50-A14-D3-G31 Anzahl der fehlerhaften Aufrufe im Erfassungszeitraum x
PDT50-A15-D3-G31 Anzahl der fehlerhaften Aufrufe im Erfassungszeitraum x
PDT50-A16-D3-G31 Anzahl der fehlerhaften Aufrufe im Erfassungszeitraum x

6.7.6 TI-Service-Desk

Es sind Auswirkungen auf den TI-Service-Desk zu erwarten und entsprechend zu berücksichtigen:

  • Steigerung des Call-Aufkommens, potentiell +10 Mio PKV-Versicherte zusätzlich (~ +15 %)
  • neue Anwendungsfälle im Hinblick auf PKV-Versicherte, z.B. Abruf der Abrechnungsinformationen oder Erteilung der Erlaubnis zur Speicherung und damit die Notwendigkeit eines angepassten Fragenkataloges
  • geplante Interoperabilitätsfeatures der App: Export der Abrechnungsinformationen in eine App eines Kostenträgers, Druckerschnittstelle -> Anpassung Fragenkatalog

7 Dokumentenhaushalt

In diesem Abschnitt werden die Auswirkungen auf den Dokumentenhaushalt des E-Rezepts dargestellt.

7.1 Übersicht betroffener Dokumente

Dieses Dokument beschreibt das Feature als geschlossene funktionale Einheit. Mit der Freigabe zur Umsetzung werden die hier getroffenen Festlegungen in einem nachgelagerten Wartungsrelease in die jeweiligen Produkt- und Anbietertypspezifikationen überführt.

Dokument
 Titel
[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
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb

7.2 Übersicht Produkt- und Anbietertypen

Die hier aufgelisteten Anforderungen richten sich an die Produkt- und Anbietertypen

  • E-Rezept-Fachdienst
  • E-Rezept-Frontend des Versicherten
  • Primärsystem der verordnenden LEI
  • Primärsystem der abgebenden LEI
  • E-Rezept-Anwendungen des Versicherten

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

Kürzel Erläuterung
AdV Anwendungen des Versicherten
AVS Apothekenverwaltungssystem
DAV Deutscher Apothekerverband
ePA elektronische Patientenakte
FdV Frontend des Versicherten
FHIR Fast Healthcare Interoperability Resources
GKV Gesetzliche Krankenversicherung
IdP Identity Provider
KIS Krankenhausinformationssystem
KVNR Krankenversichertennummer
LEI Leistungserbringerinstitution
PKV Private Krankenversicherung
PVS Praxisverwaltungssystem, ärztliches bzw. zahnärztliches
PS Primärsystem
QES Qualifizierte Elektronische Signatur 
TI Telematikinfrastruktur
VAU vertrauenswürdige Ausführungsumgebung

8.2 Abbildungsverzeichnis

8.3 Tabellenverzeichnis

8.4 Glossar

Begriff Erläuterung
Abrechnungsinformation Informationen, welcher der Versicherte einem Kostenträger zur Abrechnung eines E-Rezepts bereitstellt. Bei einer digitalen Übermittlung bestehen diese aus Verordnungsdatensatz, PKV-Abgabedatensatz und Quittung. 
Versicherten-ID 10-stelliger unveränderlicher Teil der Krankenversichertennummer

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

[Quelle]
 Herausgeber: Titel
[gemGlossar]
 gematik: Glossar der Telematikinfrastruktur
[gemSysL_eRp]
 gematik: Systemspezifisches Konzept E-Rezept
[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
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemSpec_PKI] gematik: Übergreifende Spezifikation Private Key Infrastruktur der TI
[gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb

8.5.2 Weitere Dokumente

[Quelle]
 Herausgeber (Erscheinungsdatum): Titel