Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

Einlösen ohne Anmeldung am E-Rezept-Fachdienst im E-Rezept-FdV

    

     

      
Version
      
1.0.1
     
     

      
Revision
      
947492
     
     

      
Stand
      
03.05.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_eRp_altern_Zuweisung
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt ein Feature, welches den Versicherten ermöglicht, ein mit dem E-Rezept-FdV eingescannten E-Rezept-Token einer Apotheke zuzuweisen.

Das Feature umfasst das Konzept, die Beschreibung der Schnittstelle für die Übermittlung der Nachricht sowie die Beschreibung der Schnittstelle für die Bereitstellung der für die Übermittlung notwendigen Informationen durch die Apotheke.

1.1 Zielsetzung

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

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller des Produkttyps E-Rezept-Frontend des Versicherten, Apothekendienstleister sowie Hersteller von Apothekenverwaltungssystemen.

1.3 Abgrenzungen

Die Festlegungen zur Kommunikation zwischen Versicherten und Apotheke zum Zuweisen von E-Rezepten oder zu Verfügbarkeitsanfragen, deren Nachrichten über den E-Rezept-Fachdienst übermittelt werden, sind nicht Gegenstand dieses Dokuments. Die Ausführung dieses Dokumentes ergänzen die bisherigen Festlegungen.

1.4 Methodik

Anforderungen

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

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

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

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

User Stories

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

2 Epic und User Stories

Die bisherige Umsetzung im E-Rezept-FdV sieht für eine Zuweisung eines E-Rezeptes an eine Apotheke die Nutzung des E-Rezept-Fachdienstes vor – zum Beispiel zur verbindlichen Reservierung bzw. zur Bestellung via Versand. Beide Nutzer, Versicherter wie Apotheke, müssen hierfür authentifizierte Teilnehmer der Telematikinfrastruktur sein.

Es ist zum jetzigen Zeitpunkt, Anfang Januar 2022, absehbar, dass nur eine geringe Anzahl Versicherte eine Authentisierung durchführen können, da sich die Ausgabe der zur Authentifizierung benötigten NFC-fähigen elektronischer Gesundheitskarten (eGK) und zugehöriger PIN über mehrere Jahre strecken wird. Ferner ist die NFC-Kommunikation zwischen Smartphone und eGK zum Teil schwierig und erreicht nicht die notwendige Akzeptanz bei allen Versicherten.

Da für den digitalen Empfang eines E-Rezepts diese Authentisierung notwendig ist, werden die Versicherten daher zunächst in großer Zahl weiterhin Papierausdrucke zum E-Rezept erhalten. Diese können zwar mit dem E-Rezept-FdV „fotografiert“ und gespeichert werden (technisch wird der DataMatrix-Code, der auf dem Papierausdruck abgebildet ist, ausgelesen). Einen Nutzwert außer der digitalen Ablage und damit möglicher Einlösung via App in der Apotheke hat das „Fotografieren“ aber bisher nicht.

Um den Versicherten dennoch einen Mehrwert durch das E-Rezept und dem dazugehörige E-Rezept-FdV bieten zu können, sollen schnellstmöglich die wichtigsten Funktionen (zumindest übergangsweise) auch ohne Authentisierung ermöglicht werden.

Die Nutzung dieser Funktionalität ist zeitlich beschränkt, bis die Voraussetzungen im Feld geschaffen sind, dass sich der Versicherte ohne größere Hürden mit dem E-Rezept-FdV gegenüber dem E-Rezept-Fachdienst authentisieren kann. Bspw. durch die großflächige Verbreitung von NFC-fähiger eGK und PIN bei den Versicherten oder durch Nutzung von elektronischen Identitäten für die Authentisierung der Versicherten gegenüber der TI. Die erste Prüfung der Voraussetzung durch die Gesellschafter und BSI ist für Oktober 2023 vorgesehen.

2.1 User Stories

Die User Stories beschreiben die Erwartungen der Nutzer.

2.1.1 Versicherter

Als Versicherter möchte ich:

• meine E-Rezepte (oder die E-Rezepte von Angehörigen) auch ohne aufwendige Anmeldung am E-Rezept-Fachdienst in der E-Rezept-App digital an eine Apotheke zuweisen können, sodass ich mir Wege dorthin sparen kann.
• eine Rückmeldung zu der Zuweisung von der Apotheke erhalten, damit ich weiß, ob alles geklappt hat und wann ich mein Medikament erhalte.
• sehen können, welche Apotheken die Zuweisung ohne Anmeldung am E-Rezept-Fachdienst akzeptieren, damit ich mein E-Rezept nicht einer „falschen“ Apotheke zuweise.
• verstehen, dass es jederzeit die Alternative zur Anmeldung am E-Rezept-Fachdienst gibt und sie mir Vorteile bringt (z.B. neue digitale E-Rezepte empfangen).
• dass das Einlösen ohne Anmeldung am E-Rezept-Fachdienst genauso einfach ist wie nach der Anmeldung am E-Rezept-Fachdienst, damit ich keine Nachteile dadurch habe.
• dass die Übermittlung von meinem E-Rezept-Token an die Apotheke sicher ist, auch wenn ich nicht an der Telematikinfrastruktur angemeldet bin.
• alle Serviceoptionen nutzen können (Reservieren, Botendienst, Versand).
• dass ich diese komfortable Einlöse-Möglichkeit ohne Anmeldung am E-Rezept-Fachdienst sowohl für Vor-Ort Apotheken als auch für EU-Versandapotheken nutzen kann.
• dass auch nach dem Zuweisen in der E-Rezept-App sichtbar ist, welche Informationen beim Zuweisen übermittelt wurden.
• dass die beim Zuweisen generierten Daten auch verfügbar bleiben, wenn ich mich später mit der E-Rezept-App an der TI anmelde.

2.1.2 Apotheke

Als Apotheker möchte ich:

• entscheiden können, ob ich auch E-Rezepte digital annehme, wenn der Versicherte in der App nicht angemeldet ist.
• im Warenwirtschaftssystem erkennen können, ob das E-Rezept über die TI oder außerhalb der TI zugewiesen wurde, damit ich weiß, über welchen Kanal ich meinem Kunden eine Rückmeldung geben kann.
• meinen Kunden erreichen können, auch wenn er mir das E-Rezept außerhalb der TI zugewiesen hat, um Rückfragen zum E-Rezept stellen zu können oder ihn beraten zu können.
• keinen Mehraufwand bei der Bearbeitung der E-Rezepte haben, wenn mir diese außerhalb der TI zugewiesen wurden (im Vergleich zu einer Zuweisung über die TI).

3 Einordnung in die Telematikinfrastruktur

Das Einlösen ohne Anmelden am E-Rezept-Fachdienst im E-Rezept-FdV soll es dem Versicherten ermöglichen, einen eingescannten E-Rezept-Token über das E-Rezept-FdV an eine Apotheke digital zu übersenden und somit das E-Rezept aus der Distanz dort einzulösen.

Eine unauthentisierte Nutzung des E-Rezept-Fachdienstes ist nicht zulässig. Von daher wird eine Nachricht vom E-Rezept-FdV über das Internet an die Zuweisungsadresse der für die Belieferung ausgewählte Apotheke – ohne Nutzung des E-Rezept-Fachdienstes oder des zentralen Netzes der TI – übermittelt.

4 Fachliches Konzept

Das Einlösen ohne Anmelden am E-Rezept-Fachdienst im E-Rezept-FdV soll es dem Versicherten ermöglichen, einen eingescannten E-Rezept-Token über das E-Rezept-FdV an eine Apotheke digital zu übersenden und somit das E-Rezept aus der Distanz dort einzulösen. In diesem Abschnitt wird der Ablauf beschrieben.

Vorbereitende Maßnahmen:

• Die Apotheke schafft die technischen Voraussetzungen für die Unterstützung der Funktionalität, bspw. durch Beauftragung eines Apothekendienstleisters.
  
• Die Serviceinformationen der Apotheke sind im APOVZD erfasst. Für die Erfassung wird durch den Betreiber des APOVZD eine Schnittstelle für die AVS bereitgestellt. Die Serviceinformation besteht aus URLs (je eine URL für die durch die Apotheke unterstützten Belieferungsoptionen). Unter den URLs ist ein REST-Service (des Apothekendienstleisters) erreichbar. Diese Schnittstelle akzeptiert Nachrichten des E-Rezept-FdVs.  
  

Es sind drei Belieferungsoptionen vorgesehen:

• Abholung in Apotheke
• Lieferung zum Versicherten durch Vor-Ort-Apotheke
• Versand zum Versicherten durch Online-Apotheke

Ablauf:

• Ein (Zahn-)Arzt erstellt ein E-Rezept für einen Versicherten.
• Der Versicherte erhält einen Ausdruck für das E-Rezept vom (Zahn-)Arzt.
• Der Versicherte nutzt das E-Rezept-FdV ohne Anmelden am E-Rezept-Fachdienst.
• Der Versicherte scannt den Datamatrix-Code auf dem Ausdruck mit dem E-Rezept-FdV ein. Der E-Rezept-Token liegt im E-Rezept-FdV vor.
• Der Versicherte sieht im E-Rezept-FdV eine Liste aller Apotheken mit ihren Belieferungsoptionen. Die Apotheken, die diese Zuweisungsoption für keine Belieferungsoption anbieten, werden gekennzeichnet (bspw. ausgegraut). Das E-Rezept-FdV bezieht die Informationen zu den Apotheken aus dem APOVZD.
• Der Versicherte wählt eine Apotheke, der das E-Rezept zugewiesen werden soll, und die gewünschte Belieferungsoption aus. Er kann optional einen Freitext an die Apotheke erfassen.
• Der Versicherte überprüft die angegebenen Kontaktdaten (Telefonnummer und/oder E-Mail) und ggf. abweichende Lieferadresse. Er muss mindestens eine Kontaktinformation an die Apotheke übergeben. Eine abweichende Lieferadresse kann er optional mit der App erfassen. Im Folgenden werden Kontaktdaten und Lieferadresse zusammengefasst als "begleitete Attribute" bezeichnet.
• Das E-Rezept-FdV erzeugt eine UUID (128-bit, gemäß RFC-4122) zur eindeutigen Identifikation der Transaktion.
• Das E-Rezept-FdV erstellt eine Nachricht. Diese enthält:
• • für die Apotheke verschlüsselt: die Information des E-Rezept-Token, begleitende Attribute, Freitext und UUID,
  • unverschlüsselt: die UUID (redundant zu dem verschlüsselten Teil) und die Ziel-Apotheke.
• Das E-Rezept-FdV sendet die Nachricht an die adressierte Apotheke. Der hierfür bereitgestellte Dienst kann von einem Dienstleister im Auftrag der Apotheke betrieben werden. Die gematik nimmt keinen Einfluss auf diese Ausgestaltung. Der Dienst übermittelt die Nachricht an das Apothekenverwaltungssystem (AVS) der Apotheke
• Die Apotheke entschlüsselt die Nachricht des Versicherten mit dem Konnektor.
• Der E-Rezept-Token, die Kontaktdaten des Versicherten und der Freitext liegen in der Apotheke vor.
• Die Apotheke kann mit der Kenntnis des E-Rezept-Token, das E-Rezept vom E-Rezept-Fachdienst abrufen.
• Die Apotheke kann den Versicherten über die angegebenen Kontaktdaten erreichen, z.B. für Bestellbestätigung, Liefertermin, etc.
  

Die Funktionalität steht Vor-Ort- und Online-Apotheken zur Verfügung. Das Anbieten der Funktionalität ist für die Apotheken optional.

5 Technisches Konzept

Abbildung 1: Schema Einlösen ohne Anmeldung am E-Rezept-Fachdienst im E-Rezept-FdV

5.1 Apothekenstammdaten im APOVZD

Die Apothekenstammdaten im APOVZD werden um folgende Informationen erweitert:

• ein oder mehrere Verschlüsselungszertifikate der Apotheke (C.HCI.ENC)
• je eine URL für jede Belieferungsoption
• zusätzliche Type-Angabe, dass dieses Feature von der Apotheke unterstützt wird

Das APOVZD synchronisiert die Verschlüsselungszertifikate aus dem VZD der TI.

Die URLs werden durch das AVS übermittelt.

Unter der URL ist ein REST-Service erreichbar. Die Apotheke signalisiert durch Angabe der URL, dass sie die entsprechende Belieferungsoperation unterstützt.

5.2 Pflege der URLs im APOVZD

Die Pflege der Informationen zu den URLs im APOVZD erfolgt über die AVS (nach einer Information an die bzw. nach einer Freigabe durch die Apotheke) primär durch den AVS-Hersteller. Es besteht die Möglichkeit, dass die Informationen durch die Apotheke editiert werden.

Mit dem Setzen mindestens einer der möglichen URLs gilt die Apotheke als "E-Rezept-ready" und wird im E-Rezept-FdV so dargestellt.

Die URLs können die folgenden Platzhalter beinhalten:

Tabelle 1: Platzhalter in URL

Die Platzhalter werden beim Aufruf der URL durch das E-Rezept-FdV mit den konkreten Werten belegt.

Das AVS erstellt einen Datensatz mit den URLs.

Siehe auch [ADAS-A2B-eRezept].

Das AVS signiert den Datensatz mit dem Konnektor und der Apotheke zugehörigen SMC-B. Mit der im Signaturzertifikat enthaltenen Telematik-ID wird der zugehörige Eintrag im APOVZD zugeordnet.

Die Signatur des Datensatzes erfolgt mit dem Konnektor mit der Signaturidentität der SMC-B C.HCI.OSIG gemäß [RFC5652] mit Profil CAdES-BES ([CAdES]) als Enveloping-Signatur.

Das APOVZD stellt eine Schnittstelle (Upload-Container) bereit.

Das AVS authentifiziert sich gegenüber dem Upload-Container über einen durch den NGDA bereitgestellten Authentisierungsendpunkt, der der Systematik der Authentifizierung für den securPharm-Prozess entspricht. Es werden zwei abweichende Parameter verwendet:

Das Ergebnis der Authentifizierung ist ein Bearer Token, der bei Aufrufen des AVS an den Upload-Container im Header übergeben werden muss.

Das AVS übermittelt den signierten Datensatz.

Das APOVZD prüft das Vorhandensein eines Eintrages mit der Telematik-ID im APOVZD und die Signatur des übermittelten Datensatzes. Bei erfolgreicher Prüfung wird auf Basis der Telematik-ID aus dem Signaturzertifikat die übermittelten URLs den Einträgen im APOVZD zugeordnet.

Das Synchronisieren vom Upload-Container in das APOVZD erfolgt täglich zwischen 0 und 6 Uhr. Spätestens ab 6 Uhr ist die Änderung für das E-Rezept-FdV verfügbar.

Für die europäischen Versandapotheken erfolgt die Pflege der URLs im APOVZD mittels des Pflegetools der gematik. 

5.3 Bereitstellung Zusatzinformationen für das E-Rezept-FdV

Das E-Rezept-FdV ruft die Informationen zu den Apotheken vom APOVZD ab. Das Datenmodell wird erweitert.

Die Zusatzinformationen Verschlüsselungszertifikate und URL für Belieferungsoptionen werden als Erweiterung der LocationApoVzd-Ressource und Binärdaten transportiert. Die LocationApoVzd Ressource ist eine Profilierung auf Basis der FHIR-Ressource Location gemäß https://gematik.de/fhir/apovzd/StructureDefinition/LocationApoVzd .

5.3.1 Verschlüsselungszertifikate

Die Verschlüsselungszertifikate C.HCI.ENC jeder Apotheke bezieht das APOVZD aus dem Verzeichnisdienst der TI (VZD). Bsp.:

Das APOVZD stellt jedes Zertifikat in einer eigenen FHIR-Binary-Ressource bereit, wobei jedes Binary eine Referenz auf die zugehörige LocationApoVzd enthält. Dafür wird das Attribut Binary.securityContext verwendet. Über die Suche nach Binary mit dem Suchparameter ?_securityContext=Location/<location_id> können alle Verschlüsselungszertifikate einer Apotheke gefunden und heruntergeladen werden.

Binary-Beispiel:

5.3.2 URL für Belieferungsoptionen

Die URLs der angebotenen Belieferungsoptionen pflegen Apotheken in ihren eigenen Einträgen im APOVZD entsprechend der Vorgaben ihrer Warenwirtschaft bzw. ihres Dienstleisters.

Dem E-Rezept-FdV werden die URLs innerhalb der LocationApoVzd-Ressource als weitere telecom-Attribute mitgeteilt. Die zu verwendenden Kontaktinformationen (Webseite, Telefon, E-Mail) erhalten einen niedrigen "rank" für eine hohe Priorität. Die bis zu 3 Belieferungsoptionen werden mit dem "system": "other" und folgenden Prioritäten festgelegt:

• 100 = URL für Belieferungsoption "Abholung in der Apotheke"
• 200 = URL für Belieferungsoption "Lieferung zum Versicherten durch Vor-Ort-Apotheke" (Botendienst)
• 300 = URL für Belieferungsoption "Versand zum Versicherten durch Online-Apotheke"

Beispiel:

5.3.3 Filter für Apothekensuche

Um aus dem E-Rezept-FdV nach Apotheken zu filtern, die dieses Feature unterstützen, wird ein zusätzlicher Type DELEGATOR aus dem Codesystem http://terminology.hl7.org/CodeSystem/v3-RoleCode in Ergänzung zu den vorhandenen Typen eingeführt.

Eine Suche aus dem E-Rezept-FdV kann dann über den URL-Parameter "?type=<filter>" in Form eines Token-Search gemäß [FHIR-SEARCH] aufgerufen werden, z.B. als https://gematik.de/fhir/apovzd/StructureDefinition/LocationApoVzd?type=http://terminology.hl7.org/CodeSystem/v3-RoleCode|DELEGATOR .

5.4 Verschlüsselung Kommunikation E-Rezept-FdV zu Apothekensystem

5.4.1 Transportverschlüsselung

Die Übermittlung der Message vom E-Rezept-FdV zum Apothekensystem erfolgt über eine TLS-Verbindung. Es gelten die übergreifenden TLS Vorgaben der gematik (siehe [gemSpec_Krypt]).

5.4.2 Verschlüsselung der Nachricht des Versicherten

Die Nachricht des Versicherten wird für die Übermittlung zwischen E-Rezept-FdV und Apotheke verschlüsselt. Das E-Rezept-FdV verschlüsselt die Nachricht hybrid mit allen Verschlüsslungszertifikaten (C.HCI.ENC) der SMC-Bs der Apotheke. In jeden verschlüsselten Datensatz müssen dabei die Empfängerinformationen zur Identifikation der richtigen SMC-B durch das Apothekensystem eingetragen werden. Diese erfolgt analog zur Anwendung Kommunikation im Medizinwesen (KIM) über die Seriennummer des verwendeten Zertifikats in der Verschlüsselung.

Das Zielformat der Verschlüsselung ist ein CMS-Objekt, in das zusätzliche (unsafe = unverschlüsselt) Attribute für die Unterstützung der Entschlüsselung eingebettet werden. Diese werden unter der OID oid_komle-recipient-emails gemäß [gemSpec_OID] gespeichert.

Die Einbettung der Attribute erfolgt in eine ASN.1-Struktur analog zum KIM-Verfahren. Anstelle der im KIM-Verfahren verwendeten E-Mail-Adresse des Empfängers wird die Telematik-ID der adressierten Apotheke eingetragen.

Diese ASN.1-Struktur muss Base64-DER codiert im Aufruf der Verschlüsselungsoperation übergeben werden.

Das folgende beispielhafte Kommando verschlüsselt einen Datensatz für ein ENC-Zertifikat inkl. Einbettung der unsafe-Attribute (kotlin-Code).

Der erhaltene CMS-Datensatz enthält unter der genannten OID die Entschlüsselungsinformationen für den Empfänger:

Abbildung 2:  Ausschnitt recipient-mails-Informationen im CMS-Datensatz

Im Bild ist die Telematik-ID der Empfänger-Apotheke (3-SMC-B-Testkarte-883110000116873) und die Seriennummer des in der Verschlüsselung verwendeten SMC-B-Zertifikats (407776027367366) angegeben. Mit diesen Informationen kann durch Auslesen der Karteninformationen über den Konnektor der Apotheke die richtige SMC-B für die Entschlüsselung identifiziert werden.

5.5 Lokalisierung SMC-B und Entschlüsselung

Die Lokalisierung der SMC-B zum Entschlüsseln und das Entschlüsseln der Nachricht erfolgt durch das Apothekenverwaltungssystem (AVS). Da eine Apotheke mehrere SMC-Bs in Benutzung haben kann (Redundanz, Lastverteilung, verschiedene Einsatzzwecke), muss das AVS wissen, mit welcher Karte der empfangene Datensatz entschlüsselt werden kann. Die oben in der Verschlüsselung eingebetteten Informationen helfen dabei.

Um die Anzahl der Zugriffe auf die Schnittstellen des Konnektors zu reduzieren, empfiehlt sich ein lokaler Cache im AVS, der Zuordnungen zwischen Telematik-ID, Zertifikats-Seriennummer und ICCSN von HBA/SM-B speichert. Die gespeicherten Zertifikats-Seriennummern sind dabei im ASN.1-Format in IssuerAndSerialNumber enthalten.

Das AVS geht dabei wie folgt vor:

1. Die über den Konnektor verfügbaren (gesteckten) Karten werden über die Operation GetCards ermittelt. Diese liefert je Karte ein CardHandle und die ICCSN der Karte zurück. Im Folgenden wird die jeweilige Karte über das CardHandle adressiert
2. Die Zertifikate je Karte werden über die Konnektoroperation ReadCardCertificate abgerufen. Mit dem Parameter CertRefList = "C.ENC" werden nur die Zertifikate Verschlüsselungsidentität abgerufen. In der Rückgabe ist die Seriennummer des Zertifikats in IssuerAndSerialNumber enthalten.
3. Mit dieser Suche wird fortgefahren, bis eine passende Karte gefunden ist, dessen ENC-Zertifikats-Seriennummer mit der Seriennummer in den ungeschützten (unsafe) Attributen im verschlüsselten Datensatz übereinstimmt. Mit dieser Karte kann der Datensatz entschlüsselt werden.

Das Entschlüsseln mittels der gefundenen Karte erfordert den Einsatz des PIN-geschützten privaten Schlüssels auf der Karte. Die Konnektoroperation fragt nicht automatisch nach dem PIN. Ist der PIN-Status dem AVS unbekannt, kann über die Konnektoroperationen GetPinStatus geprüft werden, ob eine PIN-Abfrage erforderlich ist. Die Konnektoroperation VerifyPin startet die PIN-Abfrage am Kartenterminal. Siehe auch [gemILF_PS]

Anschließend kann der Datensatz mit der Operation DecryptDocument des Konnektors und den Parametern CardHandle für die gefundene Karte und Document (die verschlüsselten Daten) entschlüsselt werden. Die übrigen Parameter (Verschlüsselungsalgorithmus, Kurvenparameter etc.) entnimmt der Konnektor dem Verschlüsselungscontainer.

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <S:Body>
    <ns5:DecryptDocument xmlns="http://ws.gematik.de/tel/error/v2.0"
         xmlns:ns2="http://ws.gematik.de/conn/ConnectorCommon/v5.0"
         xmlns:ns3="urn:oasis:names:tc:dss:1.0:core:schema"
         xmlns:ns4="http://www.w3.org/2000/09/xmldsig#"
         xmlns:ns5="http://ws.gematik.de/conn/EncryptionService/v6.1"
         xmlns:ns6="http://ws.gematik.de/conn/ConnectorContext/v2.0"
         xmlns:ns7="urn:oasis:names:tc:SAML:1.0:assertion">
      <ns6:Context>
        <ns2:MandantId>Mandant1</ns2:MandantId>
        <ns2:ClientSystemId>CS1</ns2:ClientSystemId>
        <ns2:WorkplaceId>AP1</ns2:WorkplaceId>
        <ns2:UserId>user</ns2:UserId>
      </ns6:Context>
      <ns5:PrivateKeyOnCard>
        <ns2:CardHandle>SMC-B-73</ns2:CardHandle>
        <ns5:KeyReference/>
      </ns5:PrivateKeyOnCard>
      <ns2:Document>
        <ns3:Base64Data MimeType="text/plain">MIAGCyqGSIb3DQEJE...</ns3:Base64Data>
      </ns2:Document>
    </ns5:DecryptDocument>
  </S:Body>
</S:Envelope>

5.6 Zuweisungsinformationen

Für die direkte Zuweisung werden die Referenz auf das einzulösende E-Rezept, die Zugriffsberechtigung (AccessCode) und Kontaktinformationen des Versicherten verschlüsselt an die Apotheke geschickt. Die folgende Datenstruktur transportiert die benötigten Informationen, wie im folgenden Beispiel angegeben:

6 Spezifikation

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

Dargestellt sind die zusätzlichen Anforderungen an die Produkttypen des E-Rezepts, die bestehende Anforderungslage für bereits eingeführte Funktionalitäten, wie bspw. der Zuweisung von E-Rezepten über die Kommunikation des E-Rezept-Fachdienstes bleibt hiervon unberührt.

6.1 Anforderungen an das Apothekenverzeichnis

In den Attributen kann jeweils eine URL, z.B. https://urlDerApotheke.de/12345, hinterlegt werden.

Es sind drei Belieferungsoptionen spezifiziert:

• Reservierung
• Botendienst
• Versand

Hinweis: Für die Anzeige der möglichen Belieferungsoptionen im E-Rezept-FdV werden die bestehenden Flags im Stammdatensatz genutzt.

Zu diesem Zweck stellt das Apothekenverzeichnis einen Upload-Container bereit, welcher eine Schnittstelle zu den AVS anbietet.

Der beigestellte Upload-Container stellt im Internet einen REST-Service gemäß [ADAS-A2B-eRezept] unter der folgenden URL zur Verfügung, welcher die POST-Operation zur Einlieferung der Endpunkte durch das AVS unterstützt:

https://datahub.ngda.de/erx2gem/<version>/configuration/erx2url/?n_id=<N-ID>

mit

• <version> - Versionsnummer der Schnittstellenspezifikation, aktuelle Version: 1.1
  (gepflegt durch ADAS als openAPI Spec in SwaggerHub)
• <N-ID> - N-ID der Apotheke als Identifier

Der Identifier N-ID ist dem AVS aus der Authentifizierungsmethodik der NGDA bekannt.

Beispiel-URL: https://datahub.ngda.de/erx2gem/1.1/configuration/erx2url/?n_id=APO1234567 

Beispiel für den Aufruf der POST-Operation:

Die Metainformationen basieren auf Werten, die in der Standard-ADAS-Schnittstelle bei allen Requests gegeben sind.
Der Type GMU definiert, dass es sich um ein Konfigurationsobjekt für die gematik handelt.
Der Contenttype zeigt mit „application/pkcs7-mime“ an, dass der URL-Datensatz nach dem PKCS7 Format signiert wurde.
Das Feld „data“ ist das eigentliche GMU „Payload“ Objekt. Der Wert der „value“ zugeordnet wird (oben mit Platzhalter „base64value“ definiert), beinhaltet die eigentliche Information für das Verzeichnis in einem base64-codierten PKCS7-Container.
Als Contenttransfertype ist „base64“ gesetzt, und zeigt an, dass der Payload base64 encodiert wurde.

Der Betreiber des Apothekenverzeichnisses stellt die Informationen zur API den AVS-Hersteller zur Verfügung. Die AVS authentisieren sich ggü. dem Upload-Container mittels des etablierten im securPharm-Prozess genutzten Vorgehen. Das AVS übermittelt einen mit der zur Telematik-ID zugehörigen SMC-B signierten Datensatz mit den Endpunktinformationen der Apotheke. 

Das Apothekenverzeichnis MUSS die von den AVS übermittelten URL Datensätze aus dem Upload-Container mit den Einträgen im APOVZD synchronisieren.

Hinweis:

Die Nutzung des Suchparameters "_securityContext" ist in [FHIR-SEARCH] nicht dokumentiert, konnte aber mit der HAPI Referenzimplementierung und einer Beispielsuche https://hapi.fhir.org/baseR4/Binary?_securityContext=Location%2F2928943  erfolgreich getestet werden.

6.2 Anforderungen an das Apothekensystem

Das Apothekensystem bezeichnet ein System, welches den Empfang und die Verarbeitung der Nachricht umsetzt. Die genaue Architektur wird nicht vorgegeben. Ein Teil der Funktionalitäten muss nicht durch das Primärsystem der abgebenden Leistungserbringerinstitution (AVS) erbracht werden, sondern kann an einen Dienstleister ausgelagert werden. Anforderungen, welche durch das AVS umgesetzt werden müssen und nicht ausgelagert werden dürfen, werden an das PS der abgebenden LEI adressiert. 

Das Apothekensystem MUSS für die Übertragung mittels TLS mindestens die TLS-Version 1.2 unterstützen. Für Details zu den TLS-Versionen 1.2 und 1.3 siehe gemSpec_Krypt#3.3.2 TLS-Verbindungen. 

Der REST Service kann weitere Operationen anbieten, d.h. er muss nicht exklusiv für die Schnittstelle zum E-Rezept-FdV angeboten werden.

Beispiel für den Aufruf der POST-Operation:

Der Aufruf beinhaltet, falls in der URL der Platzhalter <transactionID> verwendet wurde, eine Transaktions-ID ("UUID [(pseudo-)zufällig gemäß Version 4]"). Der Aufruf beinhaltet, falls in der URL der Platzhalter <ti_id> verwendet wurde, die Telematik-ID der adressierten Apotheke, welche zum Routing genutzt wird.

Die Nachricht beinhaltet einen verschlüsselten Inhalt. Die Telematik-ID der adressierten Apotheke steht ebenfalls in den unsafe-Attributes des verschlüsselten Inhalts. Die Transaction-ID ist auch Bestandteil des verschlüsselten Inhalts.

6.3 Anforderungen an das Primärsystem der abgebenden LEI

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

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

6.3.2 Nachricht von Apothekendienstleister empfangen

Siehe [gemILF_PS#4.4.5.2 Entschlüsseln].

6.4 Anforderungen an das E-Rezept-FdV

Für die Struktur der Nachricht siehe A_22784 - E-Rezept - Einlösen ohne Anmelden - Datenstruktur Nachricht .

Das Profil des C.HCI.ENC Zertifikats wird in [gemSpec_PKI] beschrieben. Die Verwendung anderer Zertifikate zur Verschlüsselung von Nachrichten ist nicht zulässig.

Eine Apotheke kann mehrere SMC-Bs mit gleicher Telematik-ID im Einsatz haben, auf jeder SMC-B befinden sich aktuell Verschlüsselungsidentitäten für das kryptografische RSA und das ECC-Verfahren.

Für Liste der Platzhalter siehe Tabelle "Platzhalter in URL".

Das folgende curl-Kommando zeigt, wie die Daten an die Schnittstelle des Apothekensystems übergeben werden:

6.5 Daten- und Informationsmodell

6.5.1 Stammdatensatz der Apotheke

Der Stammdatensatz der Apotheke wird erweitert.

Tabelle 3: Stammdatensatz 

Tabelle 4: Datenstruktur der Binary-Ressource

6.5.2 Message an die Apotheke

Die Message beinhaltet folgende Informationen

• Telematik-ID der adressierten Apotheke
• Transaktions-ID
• verschlüsselte Nachricht des Versicherten

Die Nachricht des Versicherten enthält folgende Informationen:

Ein Beispiel für die ausgetauschte JSON-Struktur findet sich oben in Abschnitt 5.

6.6 Datenschutz und Sicherheit

Die in diesem Dokument spezifizierte Lösung trägt der Situation Rechnung, dass die Anmeldung am E-Rezept-Fachdienst mittels NFC-fähiger eGK und PIN-Eingabe aus verschiedenen Gründen für viele Versicherte eine große Hürde darstellt.

Diese Lösung trägt also bis zur Einführung einer komfortabel nutzbaren elektronischen Identität für Versicherte und wird dann obsolet.

Obwohl es sich also um eine Übergangslösung handelt, besteht das Ziel, die Lösung sicher zu gestalten. Dementsprechend wird der zu übermittelnde E-Rezept-Token mit einem (SMC-B)-Zertifikat verschlüsselt, dessen zugehöriger privater Schlüssel in alleiniger Hoheit der Empfänger-Apotheke liegt. Der in der Kommunikation zwischen E-Rezept-FdV und Apotheke geschaltete Dienstleister kann somit nicht auf den E-Rezept-Token in Klartext zugreifen. Gleiches gilt für die damit verbundene Nachricht des Versicherten an die Apotheke und die darin ggf. befindlichen personenbezogenen Daten.

Insofern muss der zwischengeschaltete Dienstleister auch keine Nachweise über seine (betrieblichen) Sicherheitsmaßnahmen erbringen. Dieser Dienstleister liegt mit seiner Technik, seinen Prozessen und seiner Verbindung zu den Apotheken außerhalb der Grenzen der Sicherheitsleistung der TI.

Da die Kommunikation vom E-Rezept-FdV zur Apotheke nicht über den E-Rezept-Fachdienst läuft, kann letzterer hierfür auch keine Protokolleinträge (Audit-Log) erstellen. Dies erfolgt lokal im E-Rezept-FdV - mit der Folge, dass die Protokolleinträge nicht von der E-Rezept-AdV oder einem E-Rezept-FdV auf einem anderen mobilen Gerät des Versicherten eingesehen werden können.

6.7 Betrieb

Die Kommunikation des Versicherten muss im Fehlerfall in Richtung der Apotheke gelenkt werden, da nur diese den Support in Richtung des durch sie genutzten AVS herstellen kann. Das E-Rezept-FdV muss durch entsprechende Hinweise in der Benutzerführung den Versicherten diesbezüglich anleiten. Der TI-Service-Desk (TISD) muss den Versicherten bei Kontaktaufnahme ebenfalls in die Richtung des abgebenden Leistungserbringers lenken.

Alle teilnehmenden AVS-Hersteller sollen am IT-Service-Management der TI (TI-ITSM) teilnehmen, damit auftretende Probleme im Zusammenspiel mit dem E-Rezept-FdV abgewickelt werden können.

7 Dokumentenhaushalt

7.1 Übersicht betroffener Dokumente

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

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Referenzierte Dokumente

8.2.1 Dokumente der gematik

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

8.2.2 Weitere Dokumente