Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Implementierungsleitfaden Primärsysteme – E-Rezept

    

     

      
Version
      
1.10.0
     
     

      
Revision
      
989834
     
     

      
Stand
      
13.09.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_eRp
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das Dokument beschreibt die für die Implementierung des E-Rezepts erforderlichen Vorgaben.

1.2 Zielgruppe

Das Dokument richtet sich maßgeblich an Hersteller von Primärsystemen (Praxisverwaltungssysteme, Krankenhausinformationssysteme und Apothekenverwaltungssysteme) von Leistungserbringerinstitutionen (LEI).

1.3 Geltungsbereich

Die in diesem Dokument formulierten Anforderungen sind informativ für Primärsysteme, die am Produktivbetrieb der Telematikinfrastruktur (TI) teilnehmen. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Die Anforderungen können für Implementierungsleitfäden bzw. Konformitätsprofile der Sektoren verwendet werden.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu den genutzten FHIR-Ressourcen und den E-Rezept-Token. Anforderungen hierzu befinden sich in [gemSpec_DM_eRp].

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu Implementation des Authentisierungsmoduls. Anforderungen hierzu befinden sich in [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend].

1.5 Methodik

Anforderungen

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

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

Rolle Arzt/Zahnarzt, MFA/ZFA

Wenn im Dokument die Rolle Arzt oder Medizinische Fachangestellte (MFA) benannt wird, dann umfassen diese sowohl die Ärzte als auch Zahnärzte bzw. MFA und Zahnmedizinische Fachangestellte (ZFA), sofern Zahnärzte oder ZFA nicht explizit ausgeschlossen werden.

1.5.1 Hinweis 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.

1.6 Fachliche und technische Konzepte

Die den in diesem Dokument beschriebenen Anwendungsfälle liegen folgende fachliche und technische Konzepte für ärztliche und zahnärztliche Verordnungen für apothekenpflichtige Arzneimittel zugrunde:

Tabelle 1 : TAB_ILFERP_018 – Fachliche und technische Konzepte

2 Systemüberblick

Die folgende Abbildung zeigt einen Systemüberblick für die Primärsysteme verordnende LEI und abgebende LEI.

Abbildung 1 : ABB_ILFERP_001 – Systemzerlegung

Die von den Primärsystemen direkt erreichbaren Produkttypen der TI sind

• Identity Provider
• E-Rezept-Fachdienst

Identity Provider

Der Identity Provider (IDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen bereitstellt. Der IDP bietet außerdem die Möglichkeit, bereits erfolgte Authentifizierungen eines Nutzers im Sinne eines Single Sign-on nachzunutzen.

Der IDP besteht aus dem zentralen Nutzerdienst und einer dezentralen Komponente, dem Authentisierungsmodul des IDP.

Authentisierungsmodul des IDP

Das Authentisierungsmodul ergänzt den IDP, um auf dem Gerät des Nutzers die fachliche Logik für die Authentisierung entsprechend dem OpenID Connect-Standard sowie das Challenge Response Verfahren mit der SMC-B umzusetzen. Der Zugriff auf die Smart Card des Nutzers erfolgt über die Außenschnittstellen des Konnektors.

Das Authentisierungsmodul wird durch das Primärsystem implementiert.

Konnektor

Der Konnektor bildet das Gateway zum zentralen Netz der TI, d.h. es routet die Anfragen an den IDP und den E-Rezept-Fachdienst.

Für die Signatur des E-Rezepts bzw. des Abgabedatensatzes wird die CMS-Signatur (CAdES) des Konnektors genutzt.

Der Konnektor kapselt die Zugriffe auf die SMC-B für die Authentisierung.

E-Rezept-Fachdienst

Der E-Rezept-Fachdienst ist ein offener fachanwendungsspezifischer Dienst in der TI, welcher Workflow zu den E-Rezepten umsetzt.

3 Systemkontext

3.1 E-Rezept Status

Ein E-Rezept durchläuft vom Erstellen bis zum Einlösen verschiedene Status. Abhängig vom Status sind in den Primärsystemen verschiedene Anwendungsfälle möglich.

Der Status wird im E-Rezept-Fachdienst verwaltet. Ist ein Anwendungsfall aufgrund des Status nicht zulässig, antwortet der E-Rezept-Fachdienst mit einer Fehlermeldung.

TAB_ILFERP_001 listet die möglichen Status.

Tabelle 2 : TAB_ILFERP_001 – E-Rezept-Status

Die Abbildung ABB_ILFERP_002 zeigt die Anwendungsfälle, welche zu Statusübergängen führen.

Abbildung 2 : ABB_ILFERP_002 – Statusübergänge

Für weitere Details zu Statusübergängen siehe [gemKPT_SysD_TI] und [gemSysL_eRp].

3.2 FHIR-Ressourcen

Für die Spezifikation der Schnittstellen in dieser Anwendung wird der Standard FHIR (Fast Healthcare Interoperability Resources) verwendet. In FHIR werden Datenstrukturen und Elemente in "Ressourcen" beschrieben, welche über standardisierte Schnittstellen zwischen verschiedenen Komponenten übertragen werden können. Die Daten werden dabei in XML oder in JSON repräsentiert.

Durch die Primärsysteme werden folgende FHIR-Ressourcen in den Schnittstellen zum E-Rezept-Fachdienst verwendet:

• Bundle (durch die KBV profilierte Ressource für Verordnungen von Arzneimitteln)
• MedicationDispense
• Communication
• Task
• Bundle (für die Darstellung der zu signierenden signierten Quittung)
• Organization

Für eine Beschreibung der Ressourcen siehe [gemSpec_DM_eRp].

Der FHIR Standard erlaubt eine Darstellung von FHIR-Ressourcen im JSON als auch XML Format. Für die FHIR-Ressourcen wird ausschließlich die XML Darstellung genutzt.

4 Übergreifende Festlegungen

4.1 Logging und Meldungen

4.2 Namensauflösung

Der E-Rezept-Fachdienst ist für Primärsysteme gemäß den Festlegungen in [gemSpec_FD_eRp] über die Adresse erp.zentral.erp.splitdns.ti-dienste.de lokalisierbar. Das Redundanzkonzept sieht mehrere Instanzen vor, die über verschiedene IP-Adressen angesprochen werden. Folglich liefert die DNS-Namensauflösung verschiedene IP-Adressen zum FQDN zurück. Diese Adressen werden vom DNS-Server in zufälliger Reihenfolge geschickt, sodass es legitim ist, immer den ersten Eintrag für den folgenden Operationsaufruf zu verwenden. Üblicherweise wird die DNS-Auflösung vom Betriebssystem gekapselt, eine Lastverteilung am E-Rezept-Fachdienst ergibt sich aus der zufälligen Reihenfolge der IP-Adressen der DNS-Abfrage.
Unspezifiziert ist das Verhalten, wenn die erste Zieladresse nicht erreichbar ist. Empfehlenswert ist die Nutzung der anderen/weiteren IP-Adressen der DNS-Abfrage. Es muss aber angenommen werden, dass bestimmte Betriebssysteme bzw. Laufzeitumgebungen des Primärsystems diese mit der Nutzung der ersten Adresse bereits verworfen haben. Bei Nicht-Erreichbarkeit des Zielhosts der ersten IP-Adresse wird daher empfohlen, weitere Verbindungsversuche auf Basis einer neuen DNS-Abfrage zu tätigen, mit dem Ziel, eine andere IP-Adresse an erster Stelle der DNS-Antwort zu erhalten, als die des nicht erreichbaren Zielhosts.

Das Primärsystem erreicht den E-Rezept-Fachdienst und IDP über den Konnektor geroutet. Je nach Installationsumgebung des Primärsystems ist der Konnektor evtl. nicht das Default-Gateway. Um diese offenen Fachdienste zu erreichen, müssen ggfs. feste Routen und eine DNS-Konfiguration für das [Split-DNS] pro Arbeitsplatz-Computer im Rahmen der Installation festgelegt werden.

Der Hersteller des Primärsystems kann die Konfiguration zum Installationszeitpunkt unterstützen, indem er bspw. eine Batch-Datei zum Hinterlegen der Netzwerkeinstellungen für die verschiedenen FQDN für E-Rezept-Fachdienst und IDP über den Konnektor als Gateway bereitstellt.

Mit dem E-Rezept wird ein Split-DNS eingeführt, um die Domainadresse "ti-dienste.de" auch im zentralen Netz für Fachdienste nutzen zu können. Für diesen Zweck wird "splitdns.ti-dienste.de" in die Bestandsnetzkonfiguration des Konnektors ergänzt. Der Konnektor übernimmt dann für die Domain splitdns.ti-dienste.de die Namensauflösung. Für lokale Netzwerkinstallationen, die den Konnektor nicht als Nameserver und Gateway in ihrem Netzwerk nutzen, müssen entsprechende Netzwerkkonfigurationen manuell vorgenommen werden.

Die gematik plant, ergänzende Informationen zu Netzwerkkonfigurationen zu veröffentlichen, bspw. auf der github-Seite https://github.com/gematik .

4.3 Health-Checks

Ein Health-Check ist eine https-Abfrage mit der Aufgabe, die Erreichbarkeit und damit gleichzeitig die Nutzbarkeit des E-Rezept-Fachdienstes festzustellen. Ein Health-Check dient nicht dazu, die fachliche Korrektheit des E-Rezept-Fachdienstes zu überprüfen. Ein Health-Check kann genutzt werden, um die Erreichbarkeit des E-Rezept-Fachdienstes zu überprüfen. 

Endanwender müssen sich darauf verlassen können, dass vom Betreiber des E-Rezept-Fachdienstes nur Endpunkte zur Verfügung gestellt werden, deren fachliche Korrektheit und Funktionalität kontinuierlich intern überwacht werden. Dadurch kann der Hersteller eines Primärsystems davon ausgehen, dass – sofern eine Erreichbarkeit eines Endpunktes gegeben ist – auch die fachliche Korrektheit und damit die Verfügbarkeit des Dienstes gegeben sind. Der Betreiber des E-Rezept-Fachdienstes prüft periodisch, ob alle verbunden Backendsysteme in den festgelegten Parametern ordnungsgemäß funktionieren. Sollte dies nicht der Fall sein, so wird der entsprechende Host automatisiert vom Netz getrennt, wodurch keine Anfragen an ihn mehr stattfinden können.

Durch die kontinuierliche Weiterentwicklung und Sicherstellung dieses Verfahrens kann damit bei Erreichbarkeit des E-Rezept-Fachdienstes von einer Verfügbarkeit der angebotenen Endpunkte ausgegangen werden.

Da jeglicher Aufruf am E-Rezept-Fachdienst Last erzeugt, ist es notwendig, dass zur Art und Weise der Durchführung dieser Health-Checks eine klarere Regelung getroffen wird.

Es wird folgend eine Klassifikation der Health-Checks vorgenommen, um den tatsächlichen Anwendungsfall konkret zu unterstützen und transparent zu machen.

4.3.1 Erweiterter Health-Check

Ein erweiterter Health-Check ist ein spezieller Aufruf auf den Endpunkt /metadata mit der http-Methode GET im inneren, verschlüsselten http-Request an die /VAU ⇒ ( "POST /VAU [GET /metadata]" ). Ziel dieses Health-Checks soll es sein, die Anmeldung am E-Rezept-Fachdienst und dem damit einhergehenden VAU-Protokoll zur Ver- und Entschlüsselung zu überprüfen. Dabei wird ebenfalls das Access-Token überprüft, welches vorher am IDP abgeholt wurde. Dieses Verfahren soll in der produktiven Betriebsumgebung nur dann angewandt werden, wenn z.B. ein neuer Client in Betrieb genommen wird. Als Abfrage zum Systemstart darf dieser Health-Check nicht eingesetzt werden!

Spezialfall: Für Hersteller von Primärsystemen der abgebenden LEI ist, ersetzend zum o.g. Verfahren, die Nutzung von /Subscription mit der http-Methode POST im inneren, verschlüsselten http-Request an die /VAU vorzuziehen, da dieses Verfahren bereits dazu dient, die Verbindungen zum E-Rezept-Fachdienst auf einen WebSocket zu reduzieren
⇒ ( "POST /VAU [POST /Subscription]" ).

4.3.2 Einfacher Health-Check

Ein einfacher Health-Check ist ein leichtgewichtiger Aufruf auf den Fachdienst-Endpunkt / (root) mit der http-Methode GET ("äußerer http-Request"), ohne eine zusätzliche VAU-Verschlüsselung ⇒ ( "GET / [---]" ). Ziel dieses Health-Checks soll es sein, die Verfügbarkeit des E-Rezept-Fachdienstes vom Clientsystem aus sicherzustellen. Dabei werden weder Access-Token noch Verschlüsselung benötigt, was ihn für wiederkehrende Abfragen optimiert.

Dieses Verfahren soll in der produktiven Betriebsumgebung nur dann angewandt werden, wenn z.B. binnen einer festgelegten Periode vom Clientsystem keine Anfragen an den E-Rezept-Fachdienst gestellt worden sind. Der Health-Check soll nicht in festgelegten Zeitintervallen, unabhängig von fachlichen Anwendungsfällen benutzt werden – sondern soll erst bei einem echten Idle-Zeitraum Anwendung finden.

4.3.3 Festlegungen zum Verfahren mit Health-Checks

Ausnahme bei technischen Störungen: Das Primärsystem darf einen weiteren einfachen Health-Check innerhalb der Idle-Periode durchführen, sofern ein fachlicher Aufruf die Nichterreichbarkeit des E-Rezept Fachdienstes zurückmeldet. Die Wiederholung des Health-Checks muss dann den Exponential Backoff-Algorithmus zur Wiederherstellung der erfolgreichen Verbindung umsetzen.

Ausnahme bei parallel durchgeführten, fachlichen Aufrufen: Das Primärsystem DARF KEINEN Health-Check durchführen, wenn innerhalb der festgelegten Idle-Periode ein regulärer Aufruf an einem beliebigen Endpunkt des E-Rezept-Fachdienstes mit erhaltener Antwort durchgeführt wurde. Die Antwort des E-Rezept-Fachdienstes MUSS die festgelegte Idle-Periode von Beginn starten lassen.

Das Primärsystem soll zur Vermittlung der Erreichbarkeit an den Endnutzer geeignete Informationen bereitstellen, um die Fehlerursache der Nichterreichbarkeit transparent darzustellen. Fehlerursachen für die Nichterreichbarkeit können beispielsweise sein: die Verbindung zum Konnektor, Verfügbarkeit der SMC-B, Verbindung zum VPN oder andere.

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Kommunikation zu den Diensten der TI

Das PS einer verordnenden bzw. abgebenden LEI nutzt TLS-Verbindungen für die Kommunikation zu den Diensten der TI. Es verbindet sich mit dem E-Rezept-Fachdienst und einem Identity Provider.

Die Abfrage beim Namensdienst der TI erfolgt über einen DNS-Lookup. Hierfür muss der Konnektor als DNS-Resolver konfiguriert sein.

Die Informationen zu den Endpunkten des Identity Providers ermittelt das Primärsystem aus dem Discovery Document. Siehe auch [gemSpec_IDP_Dienst#Registrierung von Endgerät und Anwendungsfrontend]. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar. 

Es gelten die Vorgaben aus [gemSpec_Krypt] für TLS.

Tabelle 3 : TAB_ILFERP_014 - HTTP-Header "X-erp-resource"

5.1.2 Verschlüsselte Kommunikation zur VAU des E-Rezept-Fachdienstes

Die Kommunikation zum E-Rezept-Fachdienst wird zusätzlich zu TLS über einen sicheren Kanal (Verschlüsselung auf Http-Ebene) zwischen dem PS und der Vertrauenswürdigen Ausführungsumgebung (VAU) im E-Rezept-Fachdienst gesichert.

Für Informationen zum Kommunikationsprotokoll zwischen E-Rezept-FdV und der VAU des E-Rezept-Fachdienstes siehe [gemSpec_Krypt#3.16 E-Rezept-spezifische Vorgaben (informativ)] und [gemSpec_Krypt#7 Kommunikationsprotokoll zwischen E-Rezept-VAU und E-Rezept-Clients] .

Alternativ zur Umsetzung des TUC_PKI_018 gemäß [gemSpec_Krypt#A_21216] soll das Primärsystem für die Prüfung des VAU-Zertifikates die VerifyCertificate Operation des Konnektors nutzen.

Folgendes kann umgesetzt werden:

(1) Beziehen des VAU-Zertifikat von /VAUCertificate

(2) Lokales Speichern der aktuellen Zeit mit dem VAU-Zertifikat als Tupel

(3) Prüfen des VAU-Zertifikates mittels der Konnektor-Operation VerifyCertificate

(4) Abbrechen falls INVALID

(5) if (get_current_time() < gespeicherte Zeit + 12h) { VAU-Zertifikat wird als gültig angesehen, Nutzen des VAU-Zertifikat }

     if (get_current_time() >= gespeicherte Zeit + 12h) { VAU-Zertifikat neu beziehen, siehe (1)}

Hinweis zum Fehlerhandling: Nur wenn der äußere Response der E-Rezept-Fachdienstes den Response-Code 200 liefert, enthält der payload eine mittels VAU-Protokoll verschlüsselte Response. Liefert der äußere Response eine Code >= 400, ist im VAU-Protokoll ein Fehler aufgetreten. Das PS muss nicht versuchen, den payload zu entschlüsseln.

5.1.3 Zertifikatsprüfung

Das Primärsystem der verordnenden und abgebenden LEI verwendet bei den in TAB_ILFERP_012 dargestellten Aktivitäten Zertifikate.

Tabelle 4 : TAB_ILFERP_012 – Zertifikatsnutzung

Es gelten folgende übergreifende Festlegungen für die Prüfung aktiv durch das E-Rezept-FdV genutzter Zertifikate.

"Ein Zertifikat aktiv verwenden" bedeutet im Sinne von A_20769, dass ein Primärsystem einen dort aufgeführten öffentlichen Schlüssel innerhalb einer kryptografischen Operation (Signaturprüfung, Verschlüsselung, Signaturprüfung von öffentlichen (EC)DH-Schlüsseln etc.) nutzt. Erhält ein Primärsystem bspw. einen Access-Token, in dem Signaturen und Zertifikate enthalten sind, und behandelt es diesen Token als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet das Primärsystem diese Zertifikate im Sinne von A_20769 passiv.

5.1.3.1 Zertifikatsprüfung von Zertifikaten der TI

5.1.3.2 Zertifikatsprüfung von Internet-Zertifikaten

Folgende Vorgaben gelten für die Prüfung von Internet-Zertifikaten.

Hinweis: Der erste Teil von A_20091 ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers ist.

5.1.4 Authentifizierung der LEI

Die LEI authentisiert sich für Zugriffe auf Dienste der TI im Rahmen der Anwendung E-Rezept gegenüber dem IDP-Dienst. 

Das Primärsystem übernimmt hierbei, wenn kein gültiger "ACCESS_TOKEN" vorliegt, neben der Rolle der Anwendungsfrontend-Applikation auch die Aufgabe des Authenticator-Moduls (der in [RFC6749 # section-4.1] beschriebene t), um das zum Zugriff auf Fachdienste benötigte "ACCESS_TOKEN" zu beantragen. Hierfür wird am Authorization-Endpunkt des IDP-Dienstes ein "AUTHORIZATION_CODE" beantragt, der nach erfolgreicher Verifikation am Token-Endpunkt des IDP-Dienstes gegen ein "ID_TOKEN" und ein "ACCESS_TOKEN" getauscht wird.

Die für die Beantragung des "AUTHORIZATION_CODE" im Challenge-Response-Verfahren notwendige elektronische Signatur mit der AUT-Identität einer SMC-B der LEI lässt das Primärsystem über die Schnittstellen des Konnektors generieren. Im Fall einer bereits freigeschalteten Smartcard passiert diese Aktion ohne Interaktion mit dem Nutzer im Hintergrund. 

Der IDP-Dienst führt die Identifikation der LEI durch, und stattet diese anschließend mit "ID_TOKEN" gemäß [openid-connect-core 1.0 # IDToken] und "ACCESS_TOKEN" gemäß [RFC6749 # section-1.4 & RFC6749 # section-5] aus. Dabei wurde aus Sicherheitsaspekten der "Authorization Code Grant" gemäß [RFC6749 # section-4.1] gewählt, welcher in identischem Ablauf auch für mobile Endgeräte mit getrennten Komponenten für Authenticator-Modul und Anwendungsfrontend anwendbar ist. Um dem erforderlichen Sicherheitsniveau gerecht zu werden, wird zudem die Verwendung von PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] vorgesehen.

Der IDP-Dienst selbst teilt sich in mehrere statisch adressierte Teildienste auf. Diese umfassen:

• Discovery-Endpunkt ("OAuth 2.0 Authorization Server Metadata" [RFC8414])
• Authorization-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749])
• Token-Endpunkt [RFC6749 # section-3.2]

Für weitere Informationen zum IDP-Dienst und zum Ablauf der Authentisierung siehe [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend].

Die gematik wird Beispielsätze und weitere Hilfestellungen auf ihrer Webseite in jeweils aktueller Form bereitstellen.

5.1.4.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes

Zur Nutzung des IDP-Dienstes gelten einige grundlegende Voraussetzungen, welche das PS erfüllen muss.

Hinweis: Der genaue Aufbau entspricht [gemSpec_IDP_Dienst#Kapitel 7.7 Aufbau des Discovery Document].

Bei Aufruf der Funktion "VerifyDocument" an der Außenschnittstelle des Konnektors ist es nicht möglich, direkt auch eine Prüfung des Zertifikatstyps und der Rollen-OID durchzuführen.

Hinweis: Zur Durchführung der Prüfungen gemäß A_20657 und ähnlicher Anforderungen ist zu verifizieren, ob im Feld certificatePolicies (2.5.29.32) des Zertifikates der richtige Zertifikatstyp FD.SIG (1.2.276.0.76.4.203) gemäß [gemSpec_OID#Tabelle Tab_PKI_405] eingetragen ist und sich in der Admission (1.3.36.8.3.3) des Zertifikats die richtige "oid_idpd" (1.2.276.0.76.4.260) findet.

Darüber hinaus gelten für die Kommunikation mit dem IDP-Dienst die Vorgaben aus 5.1.1 Kommunikation zu den Diensten der TI.

5.1.4.2 Abruf von Token beim IDP-Dienst

Im Folgenden wird der Ablauf der Token-Beantragung und Ausstellung detaillierter beschrieben und – wo für das Primärsystem notwendig – mit entsprechenden Anforderungen hinterlegt. 
Im ersten Schritt erzeugt sich das Primärsystem einen zufälligen "CODE_VERFIER" und bildet darüber den Hash "CODE_CHALLENGE". Mit dessen Hilfe kann es sich im späteren Verlauf als valider Empfänger des Tokens ausweisen.

Anschließend werden der gehashte Zufallswert und die notwendigen Angaben als "CODE_CHALLENGE" beim Authorization-Endpunkt des IDP-Dienstes eingereicht.

Der Authorization-Endpunkt legt nun eine "session_id" an, stellt alle nötigen Informationen zusammen und erzeugt das "CHALLENGE_TOKEN".
Darüber hinaus stellt der Authorization-Endpunkt den im Claim des entsprechenden Fachdienstes vereinbarten "Consent" zusammen, welcher die für dessen Funktion notwendigen Attribute beinhaltet.

Der Authorization-Endpunkt liefert als Response zur Anfrage des "AUTHORIZATION_CODE" einen "CHALLENGE_TOKEN", um die Identität der LEI zu bestätigen, sowie den "consent" des im "scope" angefragten Fachdienstes.

Das Primärsystem verwendet nun die AUT-Identität der SM-B der LEI und deren Konnektor, um das gehashte "CHALLENGE_TOKEN" des IDP-Dienstes zu signieren. Wenn es sich um eine erstmalige Anmeldung des Benutzers bei diesem Fachdienst handelt, werden diesem darüber hinaus die für den Zugriff übermittelten Daten der LEI angezeigt.

Hinweis: Die erfolgte Zustimmung des Nutzers darf gespeichert werden und weitere Abfragen können entfallen.

Hinweis: Der Aufbau der Anfrage und der einzureichenden Objekte entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].

Hinweis: Aktuell befinden sich vornehmlich SMC-B der Generation G2 im Feld. Bei diesen ist für die Signatur, entsprechend dem Default des Konnektors, das Verfahren RSASSA-PSS zu nutzen.
Wenn eine SMC-B G2.1-Karte vorhanden ist, ist ECDSA zu priorisieren. Beide Verfahren werden durch den IDP-Dienst unterstützt.

Für weitere Informationen siehe Kapitel "Als Nutzer gegenüber der Telematikinfrastruktur authentisieren" in der API-Schnittstelle [E-Rezept API Dokumentation].

Hinweis: Im Rahmen der Signatur wird auf privates Schlüsselmaterial zugegriffen. Die verwendeten Karten müssen sich daher in einem erhöhten Sicherheitszustand befinden, der ggf. erst durch eine PIN-Eingabe hergestellt werden muss. Das Primärsystem muss den Kartenzustand abfragen und die Karte ggf. durch den Nutzer freischalten lassen. Mit dem (optionalen) Einblenden eines Hinweises der Form "Bitte beachten Sie die Anzeige an Ihrem Kartenterminal" muss das Primärsystem dafür sorgen, dass die Abfrage einer PIN-Eingabe am Kartenterminal vom Benutzer nicht übersehen wird.

Anschließend werden die signierte "challenge" und das verwendete Authentisierungszertifikat der Smartcard an den IDP-Dienst übermittelt.

Hinweis: Der Aufbau der Anfrage und der einzureichenden Objekte entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].

Hinweis: Das Signieren und Verschlüsseln des "CHALLENGE_TOKEN" ist durch die Verwendung eines Nested JWT [angelehnt an den folgenden Draft: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03 zu realisieren. Im cty-Header ist "NJWT" zu setzen, um anzuzeigen, dass es sich um einen Nested JWT handelt. Das Signieren wird dabei durch die Verwendung einer JSON Web Signature (JWS) [RFC7515 # section-3 - Compact Serialization] gewährleistet. Die Verschlüsselung des signierten Token wird durch die Nutzung der JSON Web Encryption (JWE) [RFC7516 # section-3] sichergestellt. Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Der Authorization-Endpunkt validiert nun die "session" sowie die "signed_challenge" und prüft das Zertifikat der LEI. Anschließend verknüpft er die "session" mit der Identität aus dem Authentisierungszertifikat und erstellt einen "AUTHORIZATION_CODE", welchen er als Antwort zurücksendet.

Das Primärsystem empfängt nun diesen "AUTHORIZATION_CODE" vom IDP-Dienst und reicht ihn zusammen mit dem KEY_VERIFIER beim Token-Endpunkt ein.

Hinweis: Der Aufbau des "KEY_VERIFIER" entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

Hinweis: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Der Token-Endpunkt validiert den "CODE_VERFIER" und gleicht diesen mit der "code_challenge" ab. Dann erzeugt er die erforderlichen Token und verschlüsselt beide mit dem "Token-Key".

Das Primärsystem erhält nun den signierten "ID_TOKEN" und den "ACCESS_TOKEN" vom Token-Endpunkt und prüft die Signatur des "ID_TOKEN".

Hinweis: Der Aufbau der Antwort und des "ID_TOKEN" entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweis: Der Aufbau der Antwort und des "ACCESS_TOKEN" entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Zur Prüfung von Zertifikatstyp- und Rollen-OID siehe Hinweis zu A_20657.

Im weiteren Verlauf kann der "ACCESS_TOKEN" innerhalb seiner Gültigkeitsdauer bei verschiedenen Aufrufen des Fachdienstes eingereicht werden. Der Fachdienst entschlüsselt das "ACCESS_TOKEN" mit seinem privaten Schlüssel, validiert es, zieht die notwendigen Informationen entsprechend seinem Claim heraus und verwendet diese für seine fachlichen Operationen.

5.2 Anwendungsfälle verordnende LEI

Folgende Anwendungsfälle werden im Primärsystem einer verordnenden LEI umgesetzt.

5.2.1 E-Rezept erstellen

Mit diesem Anwendungsfall werden die Aufbewahrungspflichten der verordnenden LEI unterstützt. Das PS der verordnenden LEI fragt für das Erstellen eines E-Rezepts beim E-Rezept-Fachdienst eine über 11 Jahre eindeutige Rezept-ID ab, die für das E-Rezept verwendet wird. 

Je nach Rezept-Typ oder Art der Zuweisung werden verschiedene Workflow-Typen des E-Rezept-Fachdienst. Die korrekte Auswahl des Workflow-Typs ist vor dem Erzeugen des E-Rezepts notwendig, da die Rezept-IDs workflow-spezifisch sind. Der Workflow-Typ für ein E-Rezept kann nachträglich nicht mehr geändert werden. Soll für ein E-Rezept, der Workflow geändert werden, dann ist der ursprüngliche Workflow zu löschen und ein neuer Workflow zu erstellen. Die mit dem neuen Workflow erstellte Rezept-ID ist in den Verordnungsdatensatz einzubetten und dieser erneut mit einer QES zu versehen.

Für weitere Informationen siehe Operation "E-Rezept erstellen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Value-Katalog für FlowType ist in [gemSpec_DM_eRp] beschrieben.

Der Response des Fachdienstes liefert

• die Rezept-ID (Task.Identifier mit "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PrescriptionId"), mit der das E-Rezept-Bundle vervollständigt wird,
• die Task-ID (Task.id), mit dem der Task bei Aufrufen des E-Rezept-Fachdienstes referenziert wird,
• und den AccessCode (Task.Identifier mit "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AccessCode"), welcher für den Zugriff auf das E-Rezept im Fachdienst berechtigt

Dieses Bundle wird in diesem Dokument als E-Rezept-Bundle bezeichnet. Ein E-Rezept-Bundle enthält genau eine Verordnungszeile.

Der E-Rezept-Fachdienst prüft die Gleichheit und weist bei Nicht-Übereinstimmen das E-Rezept beim Einstellen mit dem Fehler 400 und Operation-Outcome "Ausstellungsdatum und Signaturzeitpunkt weichen voneinander ab, müssen aber taggleich sein" ab.

Für die qualifizierte elektronische Signatur des E-Rezept Bundels wird der Konnektor verwendet. Es wird eine CMS-Signatur (CAdES) erstellt. Die Operation für die QES muss durch den Leistungserbringer durchgeführt werden.

Für weitere Informationen siehe Operation "E-Rezept qualifiziert signieren" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Für die Nutzung der Komfortsignatur siehe [gemILF_PS].

Falls keine Komfortsignatur zur Verfügung steht oder die Komfortsignatur deaktiviert ist, soll das PS der verordnenden LEI die Stapelsignatur verwenden ist, falls mehrere E-Rezepte signiert werden sollen. 

5.2.1.1 E-Rezept erstellen - Workflow 200/209

Voraussetzung für die Verwendung des E-Rezeptes für Privatversicherte ist die sichere digitale Übermittlung von Versichertenstammdaten an verordnende Leistungserbringer. Der "Online Check-in" ist das definierte digitale Verfahren, um verordnenden Leistungserbringern die Krankenversichertennummer und weitere Versichertenstammdaten einmalig (und nach Änderungen) zur Nutzung von TI-Anwendungen bereitzustellen. Die Implementierung des Verfahren ist daher erforderlich, um auch Funktionen für Privatversicherte und Workflows 200 und 209 bereitzustellen. Für die Beschreibung des Verfahrens siehe [ILF OCI].

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

Folgende Anforderungen bestehen für einen Verordnungsdatensatz:

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

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

Hinweis: Diese Anforderungen beschreiben nicht abschließend die Unterschiede zwischen Verordnungsdatensätze 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 den Workflow für PKV-Versicherte zu initiieren.

5.2.1.2 E-Rezept erstellen - Mehrfachverordnung

Eine Mehrfachverordnung besteht aus bis zu 4 Teilverordnungen.

Folgende Anforderungen bestehen für den Verordnungsdatensatz jeder Teilverordnung:

Die Angabe des Endes der Einlösefrist der Teilverordnung ist optional.

5.2.2 E-Rezept einstellen

Mit diesem Anwendungsfall wird das von der verordnenden LEI erstellte E-Rezept auf dem Fachdienst eingestellt, damit es für den Versicherten verfügbar ist.

Das Einstellen des E-Rezepts muss innerhalb von 5 Tagen nach dem Erstellen des E-Rezept erfolgen. Anderenfalls wird das E-Rezept (Task mit Status "draft") auf dem E-Rezept-Fachdient gelöscht. Nach dem Löschen kann das E-Rezept nicht mehr eingestellt werden.

Das erstellte E-Rezept-Bundle wird innerhalb einer PKCS#7-Datei (enveloping) für die QES an den Task in der $activate-Operation übergeben.

Für weitere Informationen siehe Operation "E-Rezept vervollständigen und Task aktivieren" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Es gelten vorrangig die Regelungen zum Ausdruck eines E-Rezepts aus den Bundesmantelverträgen [BMV] und [BMV-Z].

Für die Spezifikation des E-Rezept-Token siehe [gemSpec_DM_eRp#2.3].

Für die Spezifikation des Datamatrix-Code für E-Rezept-Token siehe [gemSpec_DM_eRp#2.3]. 

Für Regelungen zum Inhalt des Ausdrucks siehe auch Bundesmantelverträge [BMV] und [BMV-Z].

5.2.2.1 E-Rezept einstellen - Workflow 169

Geeignete Verfahren sind z.B. die Übermittlung des E-Rezept-Token mit dem sicheren Übermittlungsverfahren der TI, KIM.

5.2.3 E-Rezept löschen

Mit diesem Anwendungsfall kann die verordnende LEI ein E-Rezept löschen, welches sie zuvor auf den E-Rezept-Fachdienst eingestellt hat.

Für weitere Informationen siehe Operation "Ein E-Rezept löschen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3 Anwendungsfälle abgebende LEI

Folgende Anwendungsfälle werden im Primärsystem einer abgebenden LEI umgesetzt.

5.3.1 E-Rezepte von einem Versicherten abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die E-Rezept-Token Information zu allen E-Rezepten mit dem Status "offen" von einem Versicherten, dessen eGK in ein mit dem Konnektor gepairten E-Health-Kartenterminal gesteckt wurde, vom E-Rezept-Fachdienst abrufen.

Der Parameter PerformOnlineCheck gibt an, dass eine Onlineprüfung und -aktualisierung durchgeführt werden soll. Der Parameter ReadOnlineReceipt gibt an, dass ein Prüfungsnachweis erstellt und an den aufrufenden Client übermittelt werden soll.

Der Response beinhaltet die Elemente PersoenlicheVersichertendaten, AllgemeineVersicherungsdaten, GeschuetzteVersichertendaten und Pruefungsnachweis. Deren Inhalte sind komprimiert sowie base64-kodiert und müssen vor dem Parsen entsprechend dekodiert werden.

Für weitere Informationen zur Operation ReadVSD siehe [gemILF_PS].

Der Prüfungsnachweis wird aus dem ReadVSD Response entnommen, URL-kodiert und in den Aufruf des E-Rezept-Fachdienstes übernommen.

Bsp.-URL: GET /Task?pnw=q94mhx93b8ch... 

Im Response ist eine Liste von Tasks enthalten. Für jeden Task sind u.a. folgende Informationen enthalten:

• Task-ID und
• AccessCode.

Auf Basis dieser Informationen können die Verordnungsdatensätze zu den E-Rezepten vom E-Rezept-Fachdienst abgerufen werden. Erst dann sind die Inhalte der Verordnungen im AVS bekannt und können mit dem Versicherten abgestimmt werden.

Abgerufene Rezepte, welche nicht durch die Apotheke beliefert werden, müssen durch die Apotheke zurückgegeben (Anwendungsfall "E-Rezept durch Abgebenden zurückgeben") werden.

5.3.2 E-Rezept abrufen

Mit diesem Anwendungsfall kann die abgebende LEI Daten zum E-Rezept inklusive QES zu einem vom Versicherten empfangenen E-Rezept-Token vom E-Rezept-Fachdienst abrufen, um das E-Rezept einzulösen.
Darüber hinaus wird durch die Gültigkeit der QES sichergestellt, dass es sich um ein gegenüber der Krankenkasse abrechenbares gültiges E-Rezept handelt.

Für weitere Informationen siehe Operation "E-Rezepte abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response liefert eine Task Ressource. Für die Spezifikation der Task Ressource siehe [gemSpec_DM_eRp]. Jeder Task enthält die folgenden fachlichen Informationen:

• Secret - Dieser Code wurde vom E-Rezept-Fachdienst spezifisch für diesen Abruf des E-Rezepts erstellt. Er berechtigt, die weiteren Statusänderungen auf dem E-Rezept-Fachdienst vorzunehmen.
• signature - base64 kodierter PKCS#7-Datei mit dem E-Rezept-Bundle und der Signatur, wie sie vom Konnektor der verordnenden LEI generiert wurde.

Hinweis zu Mehrfachverordnung:

Wenn ein AVS eine Teilverordnung abruft, deren Einlösezeitraum noch nicht erreicht ist, dann liefert der E-Rezept-Fachdienst einen Fehler 403. Im OperationOutcome der Fehlermeldung liefert der E-Rezept-Fachdienst das Datum des Beginns der Einlösefrist.

Für die QES-Prüfung wird die PKCS#7-Datei verwendet. Die Verordnungsdaten des E-Rezepts sind innerhalb der PKCS#7-Datei enthalten und müssen für die Weiterverarbeitung extrahiert werden.

Für weitere Informationen siehe Operation "Qualifizierte Signatur des E-Rezepts prüfen" aus der API-Schnittstelle [E-Rezept API Dokumentation]. Implementierungshinweise zur Signaturprüfung für Primärsysteme sind in [gemILF_PS#4.4.2] beschrieben. Die Außenschnittstelle des Konnektors ist in [gemSpec_Kon#TIP1-A_5034-x Operation VerifyDocument (nonQES und QES)] beschrieben. 

Als Response liefert der Konnektor einen standardisierten Prüfbericht in einer VerificationReport-Struktur gemäß [OASIS-VR].

Für die weitere Verarbeitung wird das E-Rezept-Bundle aus der PKCS#7-Datei verwendet.

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.

Möchte der Versicherte die Möglichkeit einer Online-Rezepteinlösung nutzen, kann die abgebende LEI die Belieferungs- und ggfs. Zuzahlungsmodalitäten über ihr Warenwirtschaftssystem ("Onlineshop") abwickeln. Hierzu ist ggfs. die Übernahme von Rezeptinformationen zur Befüllung eines Warenkorbs erforderlich. 

5.3.3 E-Rezept erneut abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die Verordnung erneut abrufen, falls bei der Übermittlung vom E-Rezept-Fachdienst beim Abruf des E-Rezepts ein Fehler aufgetreten ist.

Im Response ist der signierte Verordnungsdatensatz und das Secret für den Task enthalten.

Für weitere Informationen siehe Operation "E-Rezept erneut abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.4 Dispensierinformationen bereitstellen

Mit diesem Anwendungsfall stellt das PS der abgebenden LEI Dispensierinformationen für den Versicherten bereit, die dann vom Versicherten auf seinem E-Rezept-FdV heruntergeladen werden können. Das E-Rezept-FdV kann dem Versicherten außerdem darstellen, dass das E-Rezept beliefert wurde bevor der Workflow des E-Rezepts durch den Anwendungsfall "Quittung abrufen" beendet wird.

Dieser Anwendungsfall kann so lange wiederholt werden, so lange sich der Task zum E-Rezept im Status "in Abgabe (gesperrt)" befindet.

5.3.5 Quittung abrufen

Mit diesem Anwendungsfall kennzeichnet das PS der abgebenden LEI das E-Rezept nach der Belieferung im E-Rezept-Fachdienst als abgegeben und lädt die Quittung herunter, die für die weiteren Abrechnungsprozesse genutzt wird.
Darüber hinaus werden dem E-Rezept-Fachdienst Informationen über das abgegebene Medikament bereitgestellt, die dann vom Versicherten auf seinem FdV heruntergeladen werden können. 

Wenn keine MedicationDispense im Operationsaufruf übergeben wird, muss vorher eine MedicationDispense in einem Aufruf der $dispense-Operation übergeben worden sein. Andernfalls bricht der E-Rezept-Fachdienst die $close-Operation mit dem Fehler 403 ab. Wenn vorher ein $dispense Aufruf erfolgte und in der $close-Operation eine MedicationDispense übergeben wird, überschreibt diese die MedicationDispense aus der $dispense-Operation. Nach Aufrufen der $close-Operation kann die MedicationDispense nicht mehr verändert werden.

Für die Spezifikation der Ressource MedicationDispense siehe [gemSpec_DM_eRp]. Die Befüllung des Medication-Objekts der MedicationDispense kann in Abhängigkeit eines Austauschs aus der Übernahme der wesentlichen Attribute (PZN, Wirkstoff, Darreichungsform, Dosierinformationen) aus dem Verordnungsdatensatz und den Daten aus dem Securpharm-Scan in die MedicationDispense und Medication kopiert werden. Weitere Informationen, die sich aus dem Scan des Securpharm-Codes für Fertigarzneimittel ergeben (z.B. Charge, Haltbarkeitsdatum) und im Primärsystem vorliegen, können ebenfalls übernommen werden.

Für weitere Informationen siehe Operation "E-Rezept-Abgabe vollziehen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response enthält ein signiertes Quittungs-Bundle, welches im Abrechnungsprozess genutzt wird.

Stapelverarbeitung

Eine Apotheke schließt nach Belieferung eines E-Rezepts den Vorgang mittels $close-Aufruf bis zum Ende des folgenden Werktags ab. Der Abschluss des Vorgangs mittels $close-Operation kann einzeln oder auch als Stapelverarbeitung durchgeführt werden. Bei einer Stapelverarbeitung ruft das AVS hintereinander die $close-Operation für jedes E-Rezept auf. Um Lastspitzen am E-Rezept-Fachdienst zu vermeiden, gelten folgende Anforderungen für die Stapelverarbeitung.

Falls ein AVS diese Aufrufe im Stapel verarbeitet, soll der Startzeitpunkt für die Aufrufe der $close-Operation am E-Rezept-Fachdienst zufällig verteilt sein, um die betriebliche Stabilität des E-Rezept-Fachdienstes zu gewährleisten.

Hinweis: Die [E-Rezept API Dokumentation] enthält im Abschnitt "E-Rezept-Abgabe vollziehen" einen Beispielalgorithmus, um den Startzeitpunkt der $close-Stapelverarbeitung zufällig zwischen 18:00 und 22:00 zu setzen.

Quittungssignatur prüfen

Der E-Rezept-Fachdienst prüft regelmäßig den Status seines Signaturzertifikats, die mandatorische Signaturprüfung der Quittung obliegt dem Quittungsempfänger, kann aber vom AVS vor der Weitergabe in die Abrechnungsprozesse ebenfalls geprüft werden.

Die Quittung wird als PKCS#7-Datei erstellt. Die quittierten Daten sind innerhalb der PKCS#7-Datei enthalten.

Implementierungshinweise zur Signaturprüfung für Primärsysteme sind in [gemILF_PS#4.4.2] beschrieben. Die Außenschnittstelle des Konnektors ist in [gemSpec_Kon#TIP1-A_5034-x Operation VerifyDocument (nonQES und QES)] beschrieben. 

Als Response liefert der Konnektor einen standardisierten Prüfbericht in einer VerificationReport-Struktur gemäß [OASIS-VR].

Hinweis: Mit den Konnektor-Versionen PTV4, PTV4+ und PTV5 kann die Signatur der Quittung nicht geprüft werden, da die Signaturprüfung immer eine negatives Ergebnis liefert. Grund ist, dass für das Zertifikatsprofil des durch den E-Rezept-Fachdienstes verwendeten Signaturzertifikates die Signaturprüfung noch nicht spezifiziert und implementiert ist. Wenn eine Apotheke die Signatur der Quittung prüfen möchte, dann muss dies unabhängig vom Konnektor im AVS umgesetzt werden. Die Zertifikatsprüfung im Rahmen der Signaturprüfung kann mittels der Konnektorfunktion VerifyCertificate erfolgen. 

5.3.6 Quittung erneut abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die Quittung erneut abrufen, falls bei der Übermittlung vom E-Rezept-Fachdienst ein Fehler aufgetreten ist.

Der Anwendungsfall kann bei Bedarf wiederholt werden.

Für weitere Informationen siehe Operation "Quittung erneut abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response enthält ein signiertes Quittungs-Bundle, welches im Abrechnungsprozess genutzt wird.

5.3.7 E-Rezept zurückgeben

Mit diesem Anwendungsfall kann die abgebende LEI ein E-Rezept, welches vom E-Rezept-Fachdienst abgerufen wurde, wieder zurückgeben, z.B. weil das E-Rezept nicht beliefert werden kann oder weil der Versicherte darum gebeten hat. Nachfolgend kann es durch den Versicherten einer anderen abgebenden LEI zugewiesen werden.

Dieser Anwendungsfall ist auch von Kostenträgern auszuführen, wenn die Verarbeitung der Zuweisung einer digitalen Gesundheitsanwendung nicht möglich ist.

Für weitere Informationen siehe Operation "Ein E-Rezept zurückweisen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.8 E-Rezept löschen

Mit diesem Anwendungsfall kann die abgebende LEI ein E-Rezept, welches auf dem E-Rezept-Fachdienst gespeichert ist, löschen, z.B. wenn ein Fehler an der Verordnung gefunden wurde, der sich nur durch das Ausstellen eines neuen E-Rezepts durch die verordnende LEI beheben lässt.

Für weitere Informationen siehe Operation "Ein E-Rezept löschen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.9 Nachrichten von Versicherten empfangen

Mit diesem Anwendungsfall kann die abgebende LEI den Token eines E-Rezepts empfangen, um es zu beliefern. Darüber hinaus kann es Nachrichten des Versicherten, wie z.B. Anfragen zur Belieferung durch eine Apotheke, empfangen.  

Für weitere Informationen siehe Operationen "Anwendungsfall auf neue Nachrichten prüfen" und  "Anwendungsfall Alle Nachrichten vom E-Rezept-Fachdienst abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Falls eine oder mehrere E-Rezept-Nachrichten für die abgebende LEI auf dem Fachdienst bereitstehen, übermittelt der Fachdienst ein Bundle von Communication Ressourcen. 

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

• Absender-ID (Versicherten-ID) für die Korrespondenz möglicher Antwortnachrichten
• Nachrichten-ID, um auf eine konkrete Nachricht zu antworten
• unverbindliche Anfrage zur Belieferung durch eine Apotheke
  
• • Informationen zum verordneten bzw. angefragten Medikament als Medication-Ressource
  • Anzahl der Packungen des verordneten bzw. angefragten Medikamentes
    
  • IK-Nummer des begünstigten Versicherten (unabhängig von der Versicherten-ID, da auch Vertreter Anfragen zur Belieferung durch eine Apotheke stellen können) 
  • Aut-Idem-Feld entsprechend der Festlegung im E-Rezept-Datensatz
  • Rezepttyp als Wert des Flowtypes im Task des E-Rezept-Workflows
  • optional: bevorzugte Belieferungsoptionen ["Apotheke", "Bote", "Versand"] des Versicherten 
  • optional: Mitteilung/Text
• verbindlicher Einlöseauftrag
• • Referenz auf den aktiven E-Rezept-Task inkl. Zugriffsberechtigung (E-Rezept-Token), über den sämtliche einlöserelevanten Informationen beziehbar sind
  • optional: Mitteilung/Text
• Übermittlung Abrechnungsinformation-Token (GEM_ERPCHRG_PR_Communication_ChargChangeReq)
• • Referenz auf ein ChargeItem inkl. Zugriffsberechtigung
  • optional: Mitteilung/Text

Wenn die Nachricht einen E-Rezept-Token enthält, dann hat der Versicherte das E-Rezept der Apotheke zugewiesen. Mit den Informationen aus dem E-Rezept-Token kann das E-Rezept vom Fachdienst abgerufen (Anwendungsfall "E-Rezept abrufen") und beliefert werden.

Wenn die Nachricht Informationen zum verordneten Mittel und keinen E-Rezept-Token enthält, dann kann die Information entsprechend der Mitteilung des Versicherten (bspw. Anfrage zur Belieferung durch eine Apotheke) verarbeitet werden. 

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

Die unverbindliche Anfrage zur Belieferung wird mit dem Start des E-Rezepts am 01.07.2021 noch nicht unterstützt.

Der verbindliche Einlöseauftrag wird mit dem Start des E-Rezepts am 01.07.2021 die optionale Mitteilung/Text als Freitext für den Versicherten nicht unterstützt. Anstelle des im Freitext zu definierenden Belieferungswunsches werden Informationen zum Belieferungswunsch in der folgenden JSON Struktur in Communication.payload übermittelt.

Beispiele für diesen Anwendungsfall stehen im E-Rezept Beispielrepository bereit: https://github.com/gematik/eRezept-Examples.

Tabelle 17 : TAB_ILFERP_015 – Nachricht von Versicherten empfangen - payload

Hinweis zur Bedeutung der Abhol-/Lieferoptionen:

• onPremise = Abholung in Apotheke
  
• delivery = Lieferung zum Versicherten durch Vor-Ort-Apotheke
  
• shipment = Versand zum Versicherten durch Online-Apotheke

5.3.10 Nachricht an Versicherten versenden

Mit diesem Anwendungsfall kann die abgebende LEI auf Nachrichten eines Versicherten antworten, z.B. um mitzuteilen, ob das E-Rezept durch die Apotheke beliefert werden kann oder wann die Arzneimittel zur Abholung bereitstehen.

Wickelt die abgebende LEI ein E-Rezept über einen Onlineshop ab, kann dem Versicherten das Weiterbearbeiten seines Warenkorbs in einer externen Bestellplattform (z.B. Versandadresse, Zuzahlung) ermöglicht werden. Hierzu erlaubt der E-Rezept-Fachdienst den Versand einer Warenkorb-URL in der Nachricht an den Versicherten.

Für die Nutzerführung im E-Rezept-FdV ist es wichtig zu erkennen, ob es sich um eine automatisierte Antwort oder bspw. die Bitte um Rückruf handelt. Hierfür kann optional das Feld Communication.topic verwendet werden. Es kommen die Werte des Standard-Codesystems https://www.hl7.org/fhir/codesystem-communication-topic.html zur Anwendung.

Als ID des Empfängers wird die Versicherten-ID des Absenders aus der empfangenen E-Rezept-Nachricht verwendet.

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

Die unverbindliche Anfrage zur Belieferung wird mit dem Start des E-Rezepts am 01.07.2021 noch nicht unterstützt. Aus dem Grund wird die Attribute verfügbare Belieferungsoptionen, Verfügbarkeitsstatus und Communication.topic nicht durch das E-Rezept-FdV ausgewertet.

Beispiele für diesen Anwendungsfall stehen im E-Rezept Beispielrepository bereit: https://github.com/gematik/eRezept-Examples.

Es können folgende Fälle abgewickelt werden:

• Zustellung + Anzeige eines Freitextes
• Zustellung + Anzeige eines menschenlesbaren Abholcodes
• Zustellung + Anzeige eines maschinenlesbaren Abholcodes
• Zustellung + Anzeige einer URL für den Absprung in einen Warenkorb

Tabelle 19 : TAB_ILFERP_016 – Nachricht an Versicherten versenden - payload

Für weitere Informationen siehe Operationen "Anwendungsfall Nachricht als Apotheke an einen Versicherten schicken" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.11 Nachricht löschen

Mit diesem Anwendungsfall kann die abgebende LEI von ihr versendete Nachrichten an einen Versicherten auf dem E-Rezept-Fachdienst löschen.

Der E-Rezept-Fachdienst prüft anhand der Telematik-ID im ACCESS_TOKEN, ob die LEI der Absender der zu löschenden Nachricht ist.

Wenn die Nachricht bereits vom Versicherten abgerufen wurde, dann wird im Response des E-Rezept-Fachdienstes im HTTP-Header eine Warnung mit dem Zeitpunkt des Abrufes übermittelt.

Für weitere Informationen siehe API-Schnittstelle [E-Rezept API Dokumentation].

Hinweis: Nachrichten an Versicherte sind immer an E-Rezept-Workflows gebunden. Wenn ein E-Rezept-Workflow, bspw. durch den Versicherten oder aufgrund von durch den E-Rezept-Fachdienst durchgesetzte Löschfristen, auf dem E-Rezept-Fachdienst gelöscht wird, dann werden auch alle zugehörigen Nachrichten gelöscht.

5.3.12 Abgabedatensatz signieren

Nach der Belieferung eines E-Rezepts erstellt das PS der abgebenden LEI einen Abgabedatensatz, welcher zusammen mit dem E-Rezept-Bundle und der Quittung für die Abrechnung des E-Rezepts verwendet wird.

Die Inhalte und die Struktur des Abgabedatensatzes werden durch DAV und GKV-SV vorgegeben. Die Definition erfolgt in Form von FHIR-Profilen. Der Datensatz selbst sollte zur Vereinfachung der Verarbeitung in Folgeprozessen in Analogie der KBV-Festlegungen im XML-Format (anstelle von bspw. JSON) dargestellt sein. 

Der Abgabedatensatz dient der Abrechnung. Demgegenüber stehen die Dispensierinformationen der MedicationDispense-Ressource für den Versicherten (vgl. Abschnitt 5.3.2). 

Für die Signatur des Abgabedatensatzes wird der Konnektor verwendet.

5.3.13 2D-Code einscannen

Eine Alternative zur Übermittlung eines E-Rezept-Token oder eines Abrechnungsinformation-Token vom Versicherten mittels E-Rezept-Nachricht ist die persönliche Übergabe in der Apotheke vor Ort. Hierzu übergibt der Kunde (Versicherter oder Vertreter) dem Mitarbeiter der abgebenden LEI einen Papierausdruck mit 2D-Code oder präsentiert einen 2D-Code auf dem Display seines mobilen Gerätes. Ebenso besteht die Möglichkeit, dass ein Versicherter den Papierausdruck eines E-Rezept-Tokens an eine Versandapotheke sendet. Der 2D-Code wird eingescannt.

Der 2D-Code für E-Rezept-Token enthält mindestens einen Token für ein E-Rezept und kann zu 3 Token zusammenfassen. Dies dient einer besseren Usability.

Der 2D-Code für Abrechnungsinformation-Token enthält genau einen Token.

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

Mit den Informationen aus einem E-Rezept-Token kann das E-Rezept vom E-Rezept-Fachdienst heruntergeladen werden.

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.

Hinweis zu Mehrfachverordnung:

Wenn Datamatrix-Codes einer Mehrfachverordnung von einem Ausdruck eingescannt werden, dann dürfen die E-Rezept-Token der Teilverordnungen, welche noch nicht ihren Gültigkeitszeitraum erreicht haben, nicht automatisch im AVS gespeichert werden, da der Versicherte das Recht hat, für diese ggf. eine andere Apotheke für das Einlösen auszuwählen.

Die Apotheke stimmt mit dem Patienten ab, wie mit der Teilverordnung verfahren wird, bspw. telefonische Rücksprache mit dem Patienten, ob das Rezept beliefert werden soll oder automatische Belieferung bei Erreichen der Einlösefrist.

5.3.14 Rezept-Informationen von verordnenden LEI empfangen

Im Rahmen des Workflow 169 / 209 erfolgt die Zuweisung des E-Rezeptes an die abgebende LEI durch die verordnende LEI. Hierfür ist ein sicheres Übermittlungsverfahren, bspw. Kommunikation im Medizinwesen (KIM) zu verwenden.

5.3.15 Rezept-Informationen mittels Zuweisen ohne Anmelden am E-Rezept-Fachdienst empfangen

Die folgenden Anforderungen gelten, wenn das AVS das Feature "Einlösen ohne Anmelden am E-Rezept-Fachdienst im E-Rezept-FdV" unterstützt.

5.3.15.1 Verwalten der Zuweisungsadresse

Das PS der abgebenden LEI muss die URL der Schnittstelle im Apothekenverzeichnis verwalten. Die Verwaltung der IP-Adresse anstatt der URL ist nicht zulässig.

Die Verwaltung der IP-Adresse anstatt der URL ist nicht zulässig.

Die URLs können die Platzhalter <ti_id> für die Telematik-ID der Apotheke und den Platzhalter <transactionID> für die Übermittlung einer Transaktions-ID enthalten.

Es müssen immer alle unterstützten Belieferungsoptionen übermittelt werden. Wird eine Belieferungsoption nicht unterstützt, dann wird das entsprechende JSON Element weggelassen.

5.3.15.2 Nachricht von Apothekendienstleister empfangen

Siehe [gemILF_PS#4.4.5.2 Entschlüsseln].

5.3.16 Abrechnungsinformationen

5.3.16.1 Abrechnungsinformation bereitstellen

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

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.

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.

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

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.

5.3.16.2 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.

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 Spezifikation der Ressource ChargeItem siehe [gemSpec_DM_eRp].

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

5.3.16.3 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.

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

5.3.17 Subscription für neue Communication

Um die Last am E-Rezept-Fachdienst zu kontrollieren, wurde festgelegt, dass ein AVS nicht öfter als alle 5 min nach neuen Nachrichten anfragen darf (A_21556). Die dadurch bis zu 5 min entstehende Verzögerung verlängert die Zeit, bis eine Apotheke auf die Nachricht des Versicherten reagieren kann. Aus dem Grund wird eine Funktionalität eingeführt, mit der AVS eine Notification erhalten, dass eine neue Nachricht für eine Telematik-ID vorliegt. Nach Erhalt einer Notification darf das AVS die neue Nachricht sofort abrufen.

Beispiel:

POST /v1/Subscription
 
<Subscription>
  <status value="requested"/>
  <criteria value="Communication?received=null&amp;recipient=3-05.2.1001000000.381"/>
  <channel>
    <type value="websocket"/>
  </channel>  
</Subscription>

Im Response des POST /v1/Subscription Request ist die Subscription Ressource, ergänzt um die subscription-id und einen Authorization Header (Bearer-Token), enthalten.

Beispiel:

GET https://subscription.zentral.erp.splitdns.ti-dienste.de/subscription
Authorization: Bearer secret-token-abc-123
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==

Der Subscription Service antwortet mit dem Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=

Das Upgrade erfolgt mit einer "bind" Text-Nachricht über die Web Socket-Verbindung an den Server.

bind: <subscription id>

Der Subscription Service antwortet mit einer "bound" um die Einrichtung der Subscription zu bestätigen.

bound: <subscription id>

Wenn eine neue Nachricht für die Telematik-ID der Apotheke eingestellt wird, dann sendet der E-Rezept-Fachdienst eine Nachricht ping: <subscription-id>. Das AVS kann dann diese Nachricht mittels des Anwendungsfalls "Nachrichten von Versicherten empfangen" unter Nutzung des Requests GET /Communication?received=null&recipient=<Telematik-ID> abrufen.

Bei Nutzung des Subscription Services kann abweichend von der Anforderung "A_21556 - PS abgebende LEI: Häufigkeit des Abrufen von Nachrichten" die Operation GET /Communication häufiger als alle 5 Minuten, d.h. nach jeder Notification, mit den obigen Parametern angefragt werden.

Die Websocket-Verbindung kann bis zu 12 h bestehen. Danach muss das AVS die Subscription neu registrieren.

Hinweis: Jede eingestellte Nachricht führt zu einem Ping, ggfs. im Millisekundenbereich, wenn viele Nachrichten an einen Empfänger gerichtet werden. In Abhängigkeit von der Implementierung kann dieses Verhalten zu einer Überlastung des PS führen, wenn bspw. jedes einzelne Ping den Anwendungsfall „Nachrichten von Versicherten empfangen“ triggert.

5.4 E-Rezept-spezifische KIM-Messages

5.4.1 E-Rezept-spezifische KIM-Messages für E-Rezept-Zuweisung

Es werden zwei E-Rezept-spezifische KIM-Messages im Rahmen der Kommunikation zwischen verordnenden und abgebenden LEI für das Zuweisen eines E-Rezeptes spezifiziert.

Eine Message dient der direkten Zuweisung eines E-Rezepts und enthält einen Mitteilungstext, den E-Rezept-Token und optional einen Therapieplan. Die strukturierte Message kann automatisiert verarbeitet werden.

Der zweite Message-Typ dient der freien Kommunikation zur Belieferung des E-Rezepts, bspw. Rückfragen durch die Apotheke.

Das Einfügen des "CRLF" erfolgt, um Warnungen im Validator zu vermeiden und muss beim Verarbeiten im abgebenden PS berücksichtigt werden.

Im Entwicklungsprozess kann der folgende Validator https://tools.ietf.org/tools/msglint/ für die Konformitätsprüfung genutzt werden. Im Produktivbetrieb ist die Nutzung aufgrund des Datenschutzes nicht zulässig.

Für Beispiele zu E-Rezept spezifischen Nachrichten wird auf https://github.com/gematik/api-erp/blob/master/docs/erp_steuerung_durch_le.adoc#kim-nachrichten-in-der-e-rezept-fachanwendung verwiesen.

5.5 Fehlerbehandlung

Tritt ein Fehler bei der Verarbeitung von Operationsaufrufen an einem Dienst der TI (bspw. E-Rezept-Fachdienst) auf, dann antwortet der Dienst mit einer Fehlermeldung. Das Format und die verwendeten Fehlercodes sind in den Spezifikationen der Interfaces (bspw. [gemSpec_FD_eRp]) beschrieben. Weiterhin können Fehler in der lokalen Verarbeitung auftreten.

Während der Auslösung von Anfragen durch einen Client können diverse Fehler auftreten. Bei einigen dieser Fehler ist eine erneute Anfrage (Retry) sinnvoll, für alle anderen Fälle soll kein Retry versucht werden. Um eine klare Leitlinie für die Fehlerbehandlung zu etablieren, wird auf die Webseite https://github.com/gematik/api-erp/blob/master/docs/erp_statuscodes.adoc verwiesen. Dort sind sämtliche Fehlercodes aufgeführt und für jeden einzelnen Code wird bewertet, ob ein erneuter Versuch der Anfrage (Retry) sowie ein Client-Failover empfohlen sind. Diese Bewertungen dienen als Orientierungshilfe für die Implementierung einer effektiven Fehlerbehandlungsstrategie, um die Robustheit und Zuverlässigkeit des Systems zu gewährleisten.

6 Informationsmodell

Dienste der TI:

Authentisierung

Session-Daten

für PS verordnende LEI

E-Rezept:

für PS abgebende LEI:

E-Rezept:

7 Best practice UX Primärsysteme für verordnende LEIs

Hinweis:

Für den Verordnungsprozess von Rezepten gibt es regulierende Vorgaben, welche durch die  Primärsysteme der verordnenden Leistungserbringerinstitutionen umgesetzt werden müssen. U.a.

• § 73 SGB V
• Bundesmantelvertrag-Ärzte
• "Technische Anlage zur elektronischen Arzneimittelversorgung" [KBV_ITA_VGEX_Technische_Anlage_ERP]

Die in diesem Implementierungsleitfaden beschriebenen best practice für User Experience soll die Umsetzung im Primärsystem so unterstützen, dass der Verordnungsprozess für den Nutzer effizient erfolgen kann.

Die best practice für User Experience stellen eine Umsetzungsempfehlung dar. D.h. es ist den Herstellern der Primärsystem freigestellt, effizientere Lösungen zu implementieren, welche den Verordnungsprozessen in den Primärsystemen entsprechen.

7.1 Allgemeine Hinweise

7.1.1 E-Rezept in jedem Verordnungsvorgang sichtbar

Der Nutzer des Systems soll in jedem Verordnungsvorgang für Arzneimittel die Möglichkeit haben, ein E-Rezept ausstellen zu können. 

7.1.2 Ladevorgänge im Hintergrund

Das Primärsystem soll bei Ladevorgängen zum Anlegen, Speichern und Verarbeiten eines E-Rezepts dem Nutzer das Weiterarbeiten im System erlauben. Insbesondere Signaturen sollen gemäß [gemILF_PS#A_23502 - Signaturerstellung im Hintergrund] im Hintergrund verarbeitet werden.

Dem Nutzer werden nur bei Fehlermeldungen auffällige  und für den Nutzer verständliche Hinweise angezeigt. Erfolgsmeldungen können so in die Benutzeroberfläche integriert werden, dass sie keine Interaktion des Nutzers verlangen und den Nutzer nicht im weiteren Arbeitsprozess stören.

7.2 Konfigurationsmöglichkeiten des Systems

7.2.1 E-Rezept als Default

In den Einstellungen des Primärsystems kann das E-Rezept übergreifend oder für einzelne Patienten als Default eingestellt werden. Das E-Rezept ist dann bei jedem Verordnungsvorgang (bei dem E-Rezept zulässig ist) voreingestellt. Der Nutzer spart sich einen zusätzlichen Klick, um von Muster 16 auf E-Rezept zu wechseln. 

7.2.2 Default Konfiguration und Vorbelegung für die Erstellung eines E-Rezeptes

Um Rezepte schnell erstellen zu können, soll es möglich sein, in den Einstellungen bestimmte Parameter und Verhalten von neu erstellten E-Rezepten zu setzen.

In den Einstellungen des Primärsystems kann für das E-Rezept je Patient der Einlöseweg als Default eingestellt werden (Patientenausdruck, E-Rezept-App oder eGK). Wenn der Ausdruck konfiguriert wurde, wird dann standardmäßig bei jedem E-Rezept automatisch der Patientenausdruck gedruckt. Der Nutzer spart sich in dem Fall einen zusätzlichen Klick bei jedem E-Rezept.

Weitere Konfigurationsparameter und Übernahme von hinterlegten Stammdaten können den Verordnungsprozess beschleunigen. 

Das Primärsystem soll für die Einführung des patienten-individuellen Konfigurationsparameter einen Defaultwert anbieten. Die initiale Wert der Einstellung kann auf Basis der letztmaligen oder ersten Ausstellung eines E-Rezeptes für den Versicherten gesetzt werden.

7.3 Erstellen eines E-Rezepts

7.3.1 Optimaler Klickpfad

Das PS kann dem Nutzer in diesem Arbeitsschritt auch eine Liste der häufig verschriebenen Medikamente anbieten.

Hinweis: Um den Nutzer hinreichend auf den folgenden Signaturschritt (nach [gemILF_PS#A_19138 - PS: Auslösen der Komfortsignatur bei Nachnutzung der Primärsystem-Authentisierung]) hinzuweisen, muss z.B. bei der Verwendung einer Schaltfläche diese deutlich machen, dass

1. eine Verordnung erzeugt werden wird. Dies kann erreicht werden durch eine passende Benennung z.B. mit  "Verordnen", "Dem Rezept hinzufügen".
2. im nächsten Schritt die Signatur erfolgen kann. Dies kann erreicht werden, durch eine passende Benennung z.B. mit 
   "[Verordnung/Arzneimittel] zur Signatur auswählen" oder durch die Verwendung eines Signatur-Icons.

Hinweis: Im Gegensatz zur Aufgabenliste handelt es sich bei dieser Liste um eine patientenspezifische Sammlung von zu signierenden Rezepten.

Hinweis: Mit der Umsetzung der Aufgabenliste für das Signieren der Verordnungen wird diese Anforderung erfüllt.

Hinweis: Um die Benennung der Schaltfläche eindeutig zu gestalten, kann diese z.B. als "Jetzt signieren" benannt werden.

7.3.2 Entscheidungsunterstützung: E-Rezept oder Muster 16

Derzeit können nicht alle Verordnungsinhalte, die per Muster 16 zu verschreiben sind, als E-Rezept abgebildet werden. Der Nutzer soll hier nicht überlegen müssen, was er per E-Rezept verschreiben kann und was nicht. In der Benutzerführung soll der Nutzer informiert werden, ob eine Verordnung als E-Rezept erstellt werden kann oder nicht.

Um zu vermeiden, dass der Nutzer etwas über die Freitextverordnung verschreibt, was derzeit nicht als E-Rezept zulässig ist, soll der Nutzer bei einer Freitextverordnung darüber in Kenntnis gesetzt werden, was derzeit als E-Rezept verordnet werden darf.

Ein aktueller Stand der verfügbaren Features (Umfang der Anwendung E-Rezept) ist auf der gematik/api-erp Seite auf GitHub zu finden. 

Freitextverordnungen sollen nur verwendet werden, wenn das Erstellen einer strukturierten Verordnung für PZN, Wirkstoff oder Rezepturen nicht möglich ist.

Der Hinweis soll sichtbar sein, aber nicht den Arbeitsablauf stören.

7.3.3 Abgabehinweis für Apotheken (zus. Freitext)

Um weiterführende Informationen zu einer Verordnung zu notieren (z.B. die Diagnose als Hinweis für den Apotheker), soll der Arzt das Feld im Verordnungsdatensatz "Abgabehinweis für Apotheken" nutzen. Dieses Feld muss dem Arzt im Verordnungsprozess angezeigt werden, so dass er es wahrnimmt und in Situationen, in denen er eigentlich etwas handschriftlich auf dem Muster 16 notiert hätte, nutzt. 

7.3.4 Verordnender Arzt aus HBA gefüllt

Beim Erstellen einer Verordnung kann es zu einer Abweichung zwischen dem die Verordnung Erstellenden und dem die Verordnung Signierenden kommen. Dies ist nach der §2 AMVV in Absatz (1) Satz 1 nicht zulässig. Es ist verpflichtend, dass der im Verordnungsdatensatz in author referenzierte Practitioner mit dem im Signaturzertifikat der QES angegebenen Person übereinstimmt.

7.3.4.1 Sonderfall Vertretungssituation

Hinweis: Das in diesem Abschnitt beschriebene Szenario "Sonderfall Vertretungsfall" findet keine Anwendung in ZPVS.

Wenn Ärzte aufgrund von Urlaub/Krankheit/Abwesenheit in der eigenen Praxis ausfallen, dürfen sie sich von einem Kollegen für maximal bis zu 3 Monate innerhalb von 12 Monaten vertreten lassen.

Der Nutzer soll (ggf. für einen bestimmten Zeitraum) entscheiden können, welcher der Vertretungsfälle zutrifft (z.B. im Rechtemanagement des Systems). Das System füllt dann die Informationen zum Verordnenden Arzt in der Verordnung automatisch richtig aus. 

Dabei gibt es folgende Vertretungsfälle (siehe [https://www.kbv.de/html/erezept.php], Stand 27.02.2023) 

• Kollegiale Vertretung: (nach § 20 Musterberufsordnung): Die/der abwesende Arzt lässt sich von einem fachgleichen Kollegen/in in dessen Praxis vertreten. Die Abrechnung erfolgt über die LANR/BSNR des Vertretenden. Im Datensatz der elektronischen Verordnung erfolgt keine Kennzeichnung einer Vertretungskonstellation, es werden die Daten der ausstellenden Person und der vertretenden Praxis übermittelt.

• Persönliche Vertretung: Ein Vertreter oder eine Vertreterin wird in der Praxis des Vertretenen tätig, bspw. als dessen Sicherstellungsassistentin im Falle von Kindererziehungszeiten. Rechtsgrundlage wäre hier § 32 Abs. 2, Satz 2 Ärzte-Zulassungsverordnung. Die Abrechnung erfolgt über die LANR/BSNR des Vertretenen. Es muss eine Kennzeichnung des Vertreters im Datensatz erfolgen. Es werden die Daten der vertretenden ausstellenden Person sowie des vertretenen Arztes und dessen Praxis übermittelt.

Der ausstellende (signierende) Arzt wird in KBV_PR_ERP_Composition Composition.author angegeben.

Nach der "Technischen Anlage zur elektronischen Arzneimittelversorgung" (P36-34, Stand 15.11.2022) der KBV wird die Verordnung bei der persönlichen Vertretung wie folgt angepasst werden:

• Der ausstellende (signierende) Arzt wird in KBV_PR_ERP_Composition Composition.author hinterlegt.
• Der verantwortliche (zu vertretende) Arzt wird in KBV_PR_ERP_Composition Composition.attester.party hinterlegt.

7.3.4.2 Sonderfall Weiterbildungsassistent

Hinweis: Das in diesem Abschnitt beschriebene Szenario "Sonderfall Weiterbildungsassistent" findet keine Anwendung in ZPVS.

Ein Weiterbildungsassistent ist berechtigt, E-Rezepte auszustellen, solange die ordnungsgemäße Überwachung und Anleitung durch eine Vertragsärztin oder einen Vertragsarzt gewährleistet ist.

Die für den Weiterbildungsassistenten und die ausbildende Person anzugebenden Daten sind in [KBV_ITA_VGEX_Technische_Anlage_ERP] festgelegt.

Der Weiterbildungsassistent signiert mit seinem HBA das E-Rezept. Wenn der Weiterbildungsassistent noch keinen HBA besitzt, dann kann er nicht als Ersteller des E-Rezeptes erfasst werden.

Siehe auch [https://www.kbv.de/html/erezept.php ]

7.4 Mehrfachverordnungen

7.5 Aufgabenliste

7.5.1 Zentrale Aufgabenliste

Ein Arzt arbeitet in seinem Arbeitsablauf verschiedene Signaturaufgaben (bspw. für die Elektronische Arbeitsunfähigkeitsbescheinigung oder das E-Rezept) ab. Diese sollen ihm im Primärsystem an einer zentralen Stelle (im Folgenden als „Aufgabenliste“ bezeichnet) angezeigt werden, sodass die Aufgaben einfach zu finden und zu bearbeiten sind.

Diese Aufgabenliste soll sortier- und filterbar sein.

In Gemeinschaftspraxis, wo bspw. mehrere Ärzte gemeinsam Patienten behandeln, soll es möglich sein die Rezepte anderer Kollegen einzusehen und zu signieren.

Zu den relevanten Informationen einer Verordnung gehören Patient, Medikament, Einnahmehinweise, Arzt, Weg der Einlösung, Ersteller etc..

Die Aufgabenliste kann weitere Signaturaufträge oder andere Praxisaufgaben beinhalten. 

Folgende Grafik dient als Beispiel:

7.5.2 Erstellen von Folgerezepten durch MFA

Für einen effizienten Arbeitsablauf soll ein MFA E-Rezepte anlegen, ausfüllen und anschließend dem Arzt zum Signieren vorlegen können. Hierbei soll der behandelnde Arzt über die Patientenakte automatisch ausgewählt werden, um das Rezept in der Aufgabenliste einem Arzt zuordnen zu können (siehe auch Kap. 1.2.2 Default Konfiguration und Vorbelegung für die Erstellung eines E-Rezeptes).

Das System muss verhindern,  dass ein Rezept von einer Person ohne persönlichen HBA signiert werden kann. Das bedeutet insbesondere, dass aus dem Benutzeraccount einer MFA nicht auf die Komfortsignatur des Arztes zugegriffen werden kann. Es darf lediglich gespeichert werden, um es dem Arzt dann zum Signieren zu übergeben.

7.5.3 Benachrichtigungen in der Aufgabenliste

Um eine zeitnahe Bearbeitung von Signaturaufgaben des Arztes zu ermöglichen, soll der Arzt auf diese in Form einer Benachrichtigung hingewiesen werden. So können noch nicht signierte und vorbereitete E-Rezepte schneller signiert werden. Das System kann den Arzt in verschiedenen Formen bspw. Pushnachrichten oder Statusfeld über die Anzahl der offenen Aufgaben benachrichtigen.

7.5.4 Bearbeiten eines Rezeptes/ Aufgabe vor der Signatur

Der Verordnende hat die Möglichkeit die in der Aufgabenliste vorbereiteten Verordnungen vor dem Signieren zu prüfen. Er soll aus der Aufgabenliste heraus einzelne Einträge bearbeiten können. Er soll aus der Aufgabenliste heraus die Informationen des Patienten, für den das E-Rezept ausgestellt werden soll, einsehen können, falls er für die Prüfung weitere Informationen zum Patienten benötigt.

7.5.5 Sammelbearbeitung der Aufgaben (Signieren)

Wie in [gemILF_PS#A_23503 - Bündeln von Signaturen zur Stapelsignatur] beschrieben, muss der Arzt Signaturen bündeln und als Sammelbearbeitung abarbeiten können. Dies gilt auch für das Signieren von E-Rezepten.

Mit der Auswahl bestätigt der Nutzer, dass die Verordnung erfolgen soll und dass im nächsten Schritt die Signatur ausgelöst wird. (erster Klick im Sinne von [gemILF_PS#A_19138 - PS: Auslösen der Komfortsignatur bei Nachnutzung der Primärsystem-Authentisierung]).

Hinweis: Wie im optimalen Klickpfad beschrieben, ist es wichtig, bei der Bereitstellung von Verordnungen zur Signatur die Schaltflächen klar und eindeutig zu benennen/kennzuzeichnen, um zusätzliche Bestätigungen durch den Nutzer zu vermeiden und den Signaturprozess reibungslos zu gestalten.

7.6 Nachbereitung

7.6.1 Benachrichtigung des Patienten über Ausstellung eines Folgerezeptes

In den Fällen, wo der Patient nicht in der Praxis anwesend ist, wenn der Arzt ein E-Rezept ausstellt (z.B. Folgerezepte oder Rezepte, die telefonisch bestellt wurden), möchte der Arzt den Patienten automatisch darüber in Kenntnis setzen, dass ein E-Rezept ausgestellt wurde und damit zum Einlösen in der Apotheke bereit steht.

Somit kann der Patient dann das E-Rezept mit der App oder der eGK einlösen.

Beispiel für eine Nachricht:

"Ihr E-Rezept wurde soeben von Ihrem Arzt unterschrieben und kann nun mit der Gesundheitskarte oder der E-Rezept App in der Apotheke eingelöst werden. Um das Rezept anzusehen und vorab an Ihre Apotheke zu senden, empfehlen wir die Nutzung der E-Rezept App der gematik."

7.7 Fehlermanagement

7.7.1 Bei Ausfall auf Muster 16 zurückgreifen

Wenn es technisch nicht möglich ist ein E-Rezept auszustellen (Ausfall einer der relevanten Komponenten), wird automatisch ein Muster 16 mit dem Verordnungsinhalt ausgewählt. Dem Nutzer wird ein Hinweis eingeblendet, dass es aktuell nicht möglich ist, ein E-Rezept auszustellen.

Um festzustellen, ob relevante Komponenten der TI nicht erreichbar sind, kann ein einfacher Healthcheck (https://github.com/gematik/api-erp/blob/master/docs/erp_ps_probing.adoc#einfacher-health-check )  genutzt werden. Es sollte ebenfalls auf ein Muster 16 zurückgegriffen werden, wenn beim Erstellen eines Rezeptes in der Kommunikation mit den Diensten der TI ein Fehler auftritt.

7.7.2 Fehlermeldungen

7.7.2.1 Verständliche Fehlermeldungen

Im Arbeitsablauf des Nutzers können Fehler in der Erstellung und Verarbeitung eines E-Rezeptes auftreten. Da vom Nutzer kein technisches Vorwissen erwartet werden darf, sind Fehlermeldungen so anzugeben, dass dieser nach Möglichkeit darauf reagieren kann. Hierbei sollen Fehlermeldungen so aufbereitet werden, dass der Nutzer versteht, welches System im Prozess den Fehler verursacht hat. Außerdem sollen bei technischen Fehlern diese sprachlich aufbereitet werden, so dass der Nutzer den Inhalt des Fehlers verstehen kann.

Die Bereitstellung der Fehlerdetails per Email o.Ä. steht mit diesen Anforderungen nicht im Widerspruch. Es soll weiterhin möglich sein technische Details an den technischen Support zu übermitteln.

7.7.2.2 Status des E-Rezepts bei Versuch es zu löschen

Ein Arzt kann ein von ihm ausgestelltes E-Rezept löschen. Wenn das nicht möglich ist, soll der Arzt aus dem PS heraus den Grund erkennen können, um besser darauf reagieren zu können. Wenn versucht wird das Rezept zu löschen, sind folgende Fehlermeldungen auszuwerten:

• Returncode 403 - Forbidden: Das Rezept ist gesperrt und befindet sich in Bearbeitung bei einer Apotheke. Solange das E-Rezept noch nicht durch die Apotheke beliefert wurde, kann es durch die Apotheke gelöscht werden.
• Returncode 410 - Gone: Das Rezept wurde bereits gelöscht und ist nicht mehr im E-Rezept-Fachdienst verfügbar

8 Best practice UX Primärsysteme für abgebende LEIs

Hinweis:

Die in diesem Implementierungsleitfaden beschriebenen best practice für User Experience soll die Umsetzung im Primärsystem so unterstützen, dass die Nutzung der Anwendung E-Rezept bestmöglich in die Arbeitsabläufe in der Apotheke integriert.

Die best practice für User Experience stellen eine Umsetzungsempfehlung dar. D.h. es ist den Herstellern der Primärsystem freigestellt, effizientere Lösungen zu implementieren, welche den Prozessen in den Primärsystemen entsprechen.

8.1 Zuweisung von E-Rezepten an eine Apotheke

Dieser Abschnitt beschreibt UX-Guidelines für den Fall der Zuweisung eines E-Rezeptes an eine Apotheke via E-Rezept-FdV oder via KIM (KIM-Dienstkennung: "eRezept;Zuweisung;V1.0"). Im folgenden werden diese beiden Fälle als "Zuweisung" bezeichnet.

8.1.1 Hinweis bei zugewiesenen E-Rezepten

Wenn ein E-Rezept über das E-Rezept-FdV oder über KIM an eine Apotheke zugewiesen wird, soll der Sender schnellstmöglich über die Annahme und Bearbeitung des E-Rezeptes durch die Apotheke informiert werden. Dabei ist der Hinweis über den Erhalt eines E-Rezeptes via KIM oder E-Rezept-FdV so lange im AVS anzuzeigen, bis der Hinweis verarbeitet wurde. Im Falle der Zuweisung per E-Rezept-FdV soll eine Rückmeldung an den Kunden übermittelt werden.

Bei Erhalt eines E-Rezeptes soll potentiell jeder Arbeitsplatz einen Hinweis erhalten. Es soll konfiguriert werden können, an welchen Arbeitsplätzen der Hinweis angezeigt wird.

Nachdem die Apotheke eine Zuweisung erhalten hat soll das Primärsystem, so weit möglich, Daten im Hintergrund verarbeiten und einen möglichst automatischen Arbeitsablauf starten.

Zuweisungen, die einen E-Rezept-Token enthalten, sollen dabei einfach in das System integriert werden können, indem automatisch ein Vorgang angelegt wird, dem das E-Rezept zugeordnet wird. Folgende Nachrichten enthalten einen E-Rezept-Token: 

• KIM-Nachricht mit Dienstkennung "eRezept;Zuweisung;V1.0"
• Communication des E-Rezept-FdV (GEM_ERP_PR_Communication_DispReq)

8.1.2 Konfiguration von Nachrichten bei Zuweisung

Im Arbeitsablauf der Apotheke ist der Austausch und die Kommunikation mit den Kunden über Verordnungen und Medikamente ein wichtiger Bestandteil. Viele Nachrichten sind dabei zum Großteil identisch. Daher sollen Vorlagen und Nachrichten konfigurierbar sein, die für die Kommunikation bei Zuweisung genutzt werden können.

Für die individuelle Kommunikation und Benachrichtigung von Kunden sollen die Nachrichten mit möglichst wenig Aufwand erstellt werden können. In Vorlagen für Nachrichten können Platzhalter verwendet werden, die bei Nutzung der Vorlagen automatisch befüllt werden.

8.1.3 Nachrichtenaustausch bei zugewiesenen Rezepten

Nach Zuweisung eines E-Rezepts über KIM kann es erforderlich sein, mit dem Verordnenden Arzt in Kontakt zu treten.

Wenn ein Versicherter ein E-Rezept über das E-Rezept-FdV einer Apotheke zugewiesen hat, ist es wichtig, dass der Versicherte über den Verlauf des Bearbeitungsvorgangs informiert wird. Aktuell kann der Nutzer des E-Rezept-FdV nicht auf Nachrichten der Apotheke antworten, daher soll die Apotheke den Versicherten mit entsprechenden Informationen über den Bestellvorgang informieren.

Rückmeldungen, wie bspw. der Empfang der Zuweisung und das Herunterladen des E-Rezepts, können automatisch erfolgen.

Der Nutzer soll die Möglichkeit haben, vorkonfigurierte Nachrichten zu verwenden, die vor dem Versenden editierbar sind, um bspw. zusätzliche Informationen zum Vorgang hinzuzufügen.

Sobald der Vorgang seitens der Apotheke bearbeitet wurde, möchte der Nutzer den Kunden darüber informieren, dass die Bestellung abgeholt werden kann. Alle für das Abholen relevanten Informationen (bspw. Abhol-Code, Zeitpubkt der Verfügbarkeit) sollen in der Nachricht übermittelt werden.

Falls ein Medikament in der Apotheke nicht verfügbar ist, ist das dem Kunden mitzuteilen. In diesem Fall ist das E-Rezept am E-Rezept-Fachdienst wieder freizugeben (Operation POST /Task/<id>/$reject). Es empfiehlt sich dem Kunden die klare Handlungsempfehlung mitzugeben, dass eine andere Apotheke zum Einlösen des Rezepts gesucht werden muss.

Neben vorher beschriebenen Nachrichten, soll das System ebenfalls ermöglichen, manuell erstellte Nachrichten an den Sender einer Zuweisung zu übermitteln.

Das Erstellen und Senden einer Nachricht soll nach Möglichkeit aus dem Arbeitsfluss im AVS möglich sein, ohne dabei ein separates Programm öffnen zu müssen. Weiterhin ist eine fortlaufende Kommunikation mit einem Vorgang zu verknüpfen, sodass der Anwender den Nachrichtenverlauf nachvollziehen kann. Dies bezieht sich sowohl auf die Kommunikation via KIM, als auch via E-Rezept-FdV.

Exemplarisch eine Beispielnachricht, wie sie der Kunde im Frontend des Versicherten sehen würde:

8.2 Bedienen eines Rezepts

Dieser Abschnitt beschreibt UX-Guidelines für den Prozess der Bedienung eines E-Rezeptes.

Hinweis: Für die Bedienung von E-Rezepten ist es es wichtig, alle Informationen zum Datenaustausch mit dem E-Rezept-Fachdienst zu sichern. Insbesondere bei Verlust des Secrets nach dem Herunterladen des E-Rezepts (Operation POST /Task/<id>/$accept) ist die Weiterverarbeitung des E-Rezepts nicht mehr möglich.

8.2.1 Bedienen von E-Rezepten nach Ablauf von Fristen

Verordnungen für apothekenpflichtige Arzneimittel für gesetzlich Versicherte unterliegen bestimmten Fristen:

• Belieferungsfrist: Frist bis zu welcher ein Rezept zu Lasten der gesetzlichen Krankenkasse eingelöst werden kann (Frist endet zu Task.extension:acceptDate, bei Kassenrezepten 28 Tage nach Ausstellung). Danach kann die Apotheke entscheiden das Rezept als Privatrezept zu beliefern (§11, Abs 4 AM-RL).
• Einlösefrist: Frist bis zu welcher ein Rezept beliefert werden darf (Frist endet zu Task.extension:expiryDate, bei Kassenrezepten 3 Monate nach Ausstellung). Danach darf ein Rezept nicht mehr von der Apotheke beliefert werden (§2, Abs. 5 AMVV).

Bei Mehrfachverordnungen sind Belieferungsfrist und Einlösefrist identisch und können vom Arzt bis zu einem Jahr frei gewählt werden.

Das Primärsystem soll dem Nutzer bei Ablaufen der entsprechenden Fristen entsprechende Hinweise darstellen.

Der E-Rezept-Fachdienst löscht eingestellte Rezepte zehn Tage nach Ablaufen einer der Gültigkeit einer Verordnung (Task.extension:expiryDate). Daher kann das AVS in diesen zehn Tagen ein abgelaufenes Rezept vom E-Rezept-Fachdienst abrufen. Diese Verordnungen dürfen nicht von der Apotheke beliefert werden.

8.2.2 Finden von vorhandenen Vorgängen per Scan des E-Rezept-Tokens nach Zuweisung

Wenn ein Versicherter das E-Rezept-Token entweder per E-Rezept-FdV übermittelt oder in der Filiale den zugehörigen Datamatrix-Code vorgezeigt hat, dann ruft die Apotheke das E-Rezept vom E-Rezept-Fachdienst ab. Das E-Rezept erhält den Status "in Abgabe (gesperrt)". Ein E-Rezept mit diesem Status kann nicht noch einmal vom E-Rezept-Fachdienst abgerufen  werden.

Wenn der Kunde das Medikament dann zu einem späteren Zeitpunkt in der Filiale abholt, soll es möglich sein, den zugehörigen Vorgang im AVS auch per Scan des E-Rezept-Token zu finden.

Hinweis: Die Abfrage eines bereits durch die Apotheke heruntergeladenen E-Rezepts am E-Rezept-Fachdienstes liefert einen Fehler. Daher sollte diese Abfrage nicht durchgeführt werden.

Ist der Vorgang zum gescannten E-Rezept-Token bereits abgeschlossen, dann soll der Vorgang angezeigt, aber nicht wieder geöffnet werden.

8.2.3 Verarbeitung von Freitextverordnungen

Für die Abgabe von Medikamenten, die auf einer Freitextverordnung basieren, soll der Nutzer des AVS bestmöglich unterstützt werden, entsprechende Präparate zu finden und abzugeben. Hierzu sollen die gesamten Freitext-Informationen  der Verordnung angezeigt werden:

• Darreichungsform: KBV_PR_ERP_Medication_FreeText.form.text
• Freitextverordnung: KBV_PR_ERP_Medication_FreeText.code.text

Das System soll den Nutzer dabei unterstützen zu erkennen, ob die Verschreibung für ein E-Rezept zulässig ist. Siehe auch https://github.com/gematik/api-erp#umfang-der-anwendung-e-rezept .

Das System soll den Nutzer darin unterstützen, diese Verordnung im Sinne einer Verordnung von Fertigarzneimittel (PZN), Wirkstoff oder einer Rezeptur zu beliefern. Hierzu können beispielsweise Inhalte des Freitextes nach PZN-Pattern untersucht und anschließend in der Arzneimitteldatenbank ermittelt werden. Weiterhin könnte das System anbieten nach einzelnen Bestandteilen einer Freitextverordnung in einer geeigneten Datenbank zu suchen.

Hierbei ist insbesondere darauf hinzuweisen, dass geprüft werden muss, ob eine Dosieranweisung vorliegt.

8.2.4 Prüfung von E-Rezepten

Der E-Rezept-Fachdienst überprüft derzeit noch nicht gänzlich die formale Richtigkeit der E-Rezepte. Das AVS soll eine formale Prüfung der Verordnungsdaten vornehmen. Diese Prüfung kann mittels ABDA- bzw. TI-Referenzvalidator vorgenommen werden.

Siehe auch https://github.com/DAV-ABDA/eRezept-Referenzvalidator/releases.

8.2.5 Sonderfall: Nachträgliches Zuordnen von E-Rezepten

In bestimmten Fällen kann es vorkommen, dass ein Vorgang für eine Verordnung im Primärsystem angelegt wird, obwohl der E-Rezept-Token für das Herunterladen des E-Rezepts noch nicht vorliegt.

Beispiele für diesen Fall sind:

• telefonische Bestellung eines Medikaments
• fernmündliche Verordnung nach §4 AMVV
• Nachreichen eines Rezeptes, um die Abgabe über die gesetzliche Krankenkasse abrechnen zu lassen

Es soll die Möglichkeit bestehen, einem Vorgang nachträglich ein E-Rezept zuzuordnen. Somit soll vermieden werden, dass der bestehende Vorgang gelöscht und ein neuer Vorgang angelegt werden muss.

Abweichungen zwischen den Informationen im Vorgang und der Verordnung sollen dem Nutzer angezeigt werden.

8.2.6 Weiterleiten von E-Rezepten an eine andere Apotheke

Für Apothekenverbünde mit mehreren Filialen besteht die Möglichkeit E-Rezepte für die Belieferung weiterzuleiten. Dies kann von Interesse sein, wenn beispielsweise innerhalb eines Verbundes eine Apotheke sich um Vorbestellungen und Botendienste kümmert.  In dem Fall können die anderen Apotheken des Verbundes die vom E-Rezept-Fachdienst heruntergeladenen E-Rezepte an diese Apotheke weiterleiten.

Das Weiterleiten kann auch im Rahmen eines Inhaberwechsels genutzt werden.

Hinweis: Beim Abruf der Quittung erfolgt im E-Rezept-Fachdienst keine Prüfung, ob die Telematik-ID der Quittung abrufenden Apotheke mit der Telematik-ID der Apotheke übereinstimmt, welche das E-Rezept heruntergeladen und den Status in "in Abgabe (gesperrt)" geändert hat.

Für das Weiterleiten eines E-Rezeptes werden Access-Code, Task-ID, Secret des E-Rezeptes sowie sämtliche Inhalte der E-Rezeptes übermittelt. Die weitere Bearbeitung des E-Rezeptes kann ohne den Umweg über Freigabe des E-Rezeptes von einer Apotheke und erneutes Herunterladen durch eine andere Apotheke erfolgen. 

Wenn eine Apotheke Zugang zu diesen Informationen erhält, kann diese die Abgabe vollziehen. Hierzu muss die empfangene Apotheke die FHIR-Operation POST /Task/<id>/$close des Rezeptes beim Fachdienst aufrufen.

Für die sichere Kommunikation kann KIM verwendet werden.

Unter der Annahme, dass die Apotheken in einem Apothekenverbund die gleiche Software nutzen, wurde bisher darauf verzichtet eine standardisiertes Schnittstelle bspw. auf Basis von KIM-Nachrichten zu entwickeln.

Hinweis: Es ist zu vermeiden, E-Rezepte mittels Zurückweisen (Operation POST /Task/<id>/$reject) und erneuten Abrufen  (Operation POST /Task/<id>/$accept) zu übergeben. Diese Vorgehensweise erzeugt Protokolleinträge und zukünftig Notifications für den Versicherten, welche für diesen ggf. nicht nachvollziehbar sind.

8.3 Nachbereitung

8.3.1 Quittung automatisch abrufen

Die Quittung für ein beliefertes E-Rezept muss innerhalb einer vertraglich vereinbarten Frist abgerufen werden. Es sind die Regelungen des Rahmenvertrags nach SGB V §300 zu berücksichtigen. Das AVS soll sicherstellen, dass die Frist nicht überschritten wird und ggf. die Quittung automatisch abrufen.

Die gematik empfiehlt die Quittung zeitnah nach der Abgabe an den Kunden abzurufen, denn mit dem Quittungsabruf werden dem Versicherten die Abgabeinformationen zum Abruf mit der App bereitgestellt.

Hinweis: Der E-Rezept-Fachdienst bietet mit der Operation GET /Task/<id> die Möglichkeit, die Quittung nach dem erstmaligen Aufruf der Operation POST /Task/<id>/$close noch einmal abzurufen. Dies ist nur möglich, bis das E-Rezept durch den Versicherten oder nach Erreichen der Löschfrist automatisch durch den E-Rezept-Fachdienst gelöscht wird.

Der Anwendungsfall "Quittung abrufen" generiert nicht nur die Quittung für die Abrechnung der Apotheke, sondern schließt auch den Workflow im E-Rezept-Fachdienst ab. Der Versicherte hat Einblick in den Statusverlauf und kann ein E-Rezept auch nach Abschluss des Workflows löschen.
Das AVS muss bei der Abgabe jeglichen Rezepttyps und unabhängig vom Kostenträger den Workflow über diesen Anwendungsfall abschließen.

8.3.2 QES durch den Apotheker

Jeder Abgabedatensatz zu einem E-Rezept muss signiert werden. Für die nicht-qualifizierten Signatur wird die SMC-B der Apotheke verwendet. In vertraglich vereinbarten Fällen ("Rahmenvertrag über die Arzneimittelversorgung nach §129 Absatz 2 SGB V",  https://www.abda.de/fileadmin/user_upload/assets/Vertraege/2021-10-01_RV_129_redaktionelle_Gesamtfassung_Stand_01102021_barrierefrei.pdf) muss der HBA des Apothekers/-assistents/Pharmazieingenieurs für eine QES verwendet werden.

In Fällen, in denen eine nicht-qualifizierte Signatur ausreicht, soll keine QES erzwungen werden. Dies führt zu Zeitersparnis, da unnötige PIN-Eingaben vermieden werden.

Für Stapel- und Komfortsignatur siehe [gemILF_PS].

8.3.3 Verständliche Rückmeldungen vom Apotheken Rechenzentrum

In der Nachbereitung bedarf es für den Nutzer des AVS einer Übersicht der Abrechnungsinformationen aus dem Apotheken Rechenzentrum (ARZ). Hierbei ist der Nutzer so zu unterstützen, dass Fehler in der Abrechnung von E-Rezepten schnell sichtbar sind und der Nutzer auch dahin geleitet wird fehlende oder falsche Angaben zu korrigieren.

8.4 Fehlermanagement

8.4.1 Erreichbarkeit von TI-Komponenten

Im Arbeitsablauf des Nutzers können Fehler in der Erstellung und Verarbeitung eines E-Rezeptes auftreten. Da vom Nutzer kein technisches Vorwissen erwartet werden darf, sind Fehlermeldungen so anzugeben, dass dieser nach Möglichkeit darauf reagieren kann. Hierbei sollen Fehlermeldungen so aufbereitet werden, sodass der Nutzer versteht, welches System im Prozess den Fehler verursacht hat. Außerdem sollen bei technischen Fehlern diese sprachlich aufbereitet werden, so dass der Nutzer den Inhalt des Fehlers verstehen kann.

Für den Fall, dass die zentralen Dienste der TI (insbesondere der E-Rezept-Fachdienst) nicht erreichbar sind, ist es für die Mitarbeiter einer Apotheke hilfreich darüber benachrichtigt zu werden. Solch eine Nicht-Erreichbarkeit kann durch einen Ausfall der TI-Dienste oder der lokalen TI-Komponenten der Apotheken (HBA, SMB-C, Konnektor, etc.) auftreten.

In diesem Fall können E-Rezepte nicht vom E-Rezept-Fachdienst abgerufen und eingelöst werden. Diese Information ist präsent darzustellen. Der Arbeitsfluss und insbesondere die Funktionalität für das Einlösen von Muster-16 Verordnungen dürfen in diesem Fall nicht blockiert werden.

Für das Umschwenken auf eine andere Instanz des E-Rezept-Fachdienstes siehe [gemSpec_ILF_PS_eRp#4.2 Namensauflösung].

Wenn das Fehler-meldende System eine technische Fehlermeldung liefert, braucht diese dem Nutzer nicht dargestellt werden.

Die Bereitstellung der Fehlerdetails per Email o.Ä. steht mit diesen Anforderungen nicht im Widerspruch. Es soll weiterhin möglich sein technische Details an den technischen Support zu übermitteln.

9 Best practice UX Clientsysteme Kostenträger

9.1 Zusatzinformationen

Nach Abschluss der Workflows eines E-Rezeptes hat der Kostenträger die Möglichkeit dem Versicherten eine Antwort zur Zuweisung zu übermitteln. Hierfür erstellt der Kostenträger eine Communication vom Profil  GEM_ERP_PR_Communication_Reply und ergänzt unter Communication.payload.contentString den Antworttext, der dem Nutzer im E-Rezept-FdV dargestellt werden soll.

Hierfür gelten die Vorgaben aus [gemSpec_DM_eRp#A_23877].

9.2 Fehlermanagement

Falls es bei der Verarbeitung einer Zuweisung einer digitalen Gesundheitsanwendung zu einem Fehler kommt, bspw. wenn der Nutzer nicht beim Kostenträger versichert ist, muss das Clientsystem den Nutzer informieren und das E-Rezept zur weiteren Nutzung zurückgeben.

Hierzu führt der Kostenträger die E-Rezept-Fachdienst Operation "$reject" aus und übermittelt dem Nutzer eine GEM_ERP_PR_Communication_Reply in der der Kostenträger angeben kann, warum die Verordnung nicht bearbeitet werden kann.

10 Anhang A – Verzeichnisse

10.1 Abkürzungen

10.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

10.3 Abbildungsverzeichnis

10.4 Tabellenverzeichnis

10.5 Referenzierte Dokumente

10.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.

10.5.2 Weitere Dokumente