Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation
Apothekenverzeichnis im E-Rezept

    

     

      
Version
      
1.4.0
     
     

      
Revision
      
989834
     
     

      
Stand
      
13.09.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_eRp_APOVZD
     
    

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 die Anforderungen und Funktionsumfang eines Apothekenverzeichnisses für die Fachanwendung E-Rezept. Dies umfasst die Schnittstellen zum Abruf von Informationen durch Clientsysteme über Apotheken, die zur Abgabe apothekenpflichtiger Arzneimittel in Deutschland berechtigt sind, sowie Schnittstellen und Prozesse zur Pflege der Informationen innerhalb des Verzeichnisses.

1.1 Zielsetzung

Die Beschreibung des Funktionsumfangs 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.

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Apothekenverzeichnis.

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller und Anbieter des Produkttypen, welcher das Apothekenverzeichnis umsetzt sowie an Hersteller und Betreiber von Produkttypen, die das Apothekenverzeichnis nutzen. Ebenso enthält dieses Dokument Informationen für Institutionen und Organisationen, die mit der Pflege der Daten beauftragt werden/sind.

1.3 Abgrenzungen

Nicht Bestandteil des Dokuments sind die Festlegungen zum E-Rezept und seiner Workflows selbst.

1.4 Methodik

Anforderungen und Anwendungsfälle

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

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

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

Die einzelnen Elemente beschreiben:

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

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

Hinweise auf offene Punkte

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

Beispiel für einen offenen Punkt.

2 Epic und User Story

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

2.1 Epic Apothekeninformationen im E-Rezept

Die E-Rezept-App schafft Mehrwerte durch sinnvolle Verknüpfung von Diensten. In diesem konkreten Kontext ermöglicht die E-Rezept-App eine komfortable Suche nach geeigneten Apotheken für die Dispensierung durch die Kombination von Suchfunktionen, Landkartendiensten und dem Verzeichnisdienst der TI (VZD) – angereichert um die freiwilligen Mehrwertinformationen des Apothekenportals für Apotheken.

Nutzer sind gewohnt, ortsbasierte Dienste in Anspruch zu nehmen, wenn sie etwas suchen, oder Filterfunktionen anzuwenden, um Ergebnislisten einzugrenzen. Um E-Rezepte einlösen zu können, brauchen sie eine Apotheke. Wenn die App bei der Suche nach nahegelegenen Apotheken hilft, indem der aktuelle Standort des Nutzers verwendet wird, dann schafft die App Mehrwerte. Nutzer erwarten Informationen, die ihnen den nächsten Schritt vereinfachen. Der nächste Schritt ist das Einlösen des Rezepts, daher ist es aus Nutzersicht wichtig, Apotheken zu finden, die auch geöffnet sind und bei denen er jetzt einlösen kann. Mit dem E-Rezept wird die Beschaffung von Medikamenten über Versandapotheken für Nutzer attraktiver werden, weil sich der Prozess deutlich vereinfacht. Gleichzeitig können Offizin-Apotheken lagernde Medikamente sofort abgeben, was für viele Nutzer ein großes Plus ist. Daher muss der Nutzer die Wahl haben, ob er zu einer Offizin-Apotheke geht oder lieber den Versandhandel wählt. 

Die gematik muss hierbei sicherstellen, dass die Such- und Filterfunktionen in Clients wettbewerbsneutral ausgestaltet sind (d.h. z.B. Sortierung nach Alphabet, nächster Standort, etc.). Alle Apotheken aus dem Apothekenverzeichnis müssen einbezogen werden. Eine Hervorhebung oder andere Art der Bevorzugung von Apotheken bei der Darstellung darf nicht erfolgen.

2.1.1 User Stories

• Als Patient möchte ich die Apotheke, in der ich E-Rezepte einlösen kann, komfortabel suchen können, so dass ich keine Zeit und Nerven damit verschwenden muss, eine geeignete Apotheke zu finden.
  
• Als Patient möchte ich die Ortungsfunktion meines Geräts nutzen können, um nahegelegene Apotheken finden zu können, so dass ich spontan die für mich bestgelegene Apotheke auswählen kann.
  
• Als Patient möchte ich die Berechtigung erteilen können, dass die App die Ortungsfunktion nutzen darf, um mir das Finden nahegelegener Apotheken zu vereinfachen.
  
• Als Patient möchte ich in der Lage sein, Apotheken herauszufiltern, die gerade geöffnet haben oder die bald öffnen werden, so dass ich nicht vor verschlossenen Türen stehe, wenn ich meine Medikamente abholen will.
  
• Als Patient möchte ich Apotheken mit Notdiensten filtern können, falls ich einmal außerhalb der Öffnungszeiten ein Medikament benötige.
• Als Patient möchte ich in der Lage sein, mir von meiner bevorzugten Navigations-App eine Route zur ausgewählten Apotheke berechnen zu lassen, so dass ich nicht Adressen in meine Navigations-App kopieren muss, um den Weg zu finden.
  
• Als Patient möchte ich Offizin-Apotheken und Versandapotheken in der Apothekensuche finden können, so dass ich die Wahl habe, ob ich den Versand nutze oder lieber die Apotheke um die Ecke wähle.
  
• Als Patient möchte ich schon während der Suche nach Apotheken erkennen können, ob eine Apotheke die Belieferung nach Hause anbietet, so dass ich die Wahl habe, ob ich mich lieber beliefern lassen will oder Medikamente abholen gehe.
• Als Patient möchte ich auf einen Blick erkennen können, welche Suchergebnisse Offizin- oder Versandapotheke sind.
  
• Als Patient möchte ich eine Apotheke, der ich ein E-Rezept zugewiesen habe, direkt nach der Zuweisung als eine Stammapotheke speichern können, so dass ich sie nicht noch einmal suchen muss.
  
• Als Patient möchte ich eine Apotheke, die ich in der Apothekensuche gefunden habe, als Stammapotheke speichern können, so dass ich sie nicht noch einmal suchen muss.
  
• Als Patient möchte ich mehrere Stammapotheken speichern können, so dass ich die Apotheken in der Nähe meines Wohnorts, meines Arbeitsorts, des Wohnorts meiner Eltern etc. speichern kann.
  
• Als Patient möchte ich leicht auf meine Stammapotheken zugreifen können, so dass ich mich nicht durch die Suchfunktion arbeiten muss, um sie zu finden.
  
• Als Patient möchte ich, dass meine App automatisch die von mir zuletzt ausgewählten Apotheken speichert, so dass ich sie nicht noch einmal suchen muss.
• Als Patient möchte ich, dass die Suchfunktion meiner App fehlertolerant ist, wenn ich mich beim Eingeben des Apothekennamens vertippe oder es mehrere Apotheken mit ähnlichem Namen gibt.
• Als Patient möchte ich in meiner App verschiedene Such- und Filterfunktionen kombinieren können wie z.B. die Ortungsfunktion und die Filterung nach Öffnungszeiten, um eine Apotheke zu finden.
• Als Patient möchte ich weitere Informationen zu einer Apotheke erhalten, um mich mit ihr in Verbindung setzen bzw. über sie informieren zu können (z.B. Telefonnummer, Fax, E-Mail-Adresse, Webseite).
• Als Institution, welche die Daten im Apothekenverzeichnis eintragen und pflegen will, brauche ich einen supportverantwortlichen Ansprechpartner mit entsprechenden Serviceleveln für die technische Schnittstelle.
• Als Institution, welche die Daten im Apothekenverzeichnis eintragen und pflegen will, brauche ich einen definierten Prozess zur Anbindung an die technische Pflegeschnittstelle.
• Als Institution, welche die Daten im Apothekenverzeichnis eintragen und pflegen will, brauche ich eine einfache (technische) Möglichkeit, die Daten für das Apothekenverzeichnis editieren zu können (einstellen, lesen, verändern, löschen).
• Als Gesamtverantwortlicher für die TI möchte ich steuern können, wer einen Zugriff auf die Pflegeschnittstelle des Apothekenverzeichnisses erhält und jederzeit eine aktuelle Übersicht für alle Umgebungen (RU/TU/PU) haben.
• Als Gesamtverantwortlicher für die TI möchte ich jederzeit wissen, welche Daten im Apothekenverzeichnis hinterlegt sind und ob diese korrekt sind bzw. Fehlermeldungen vorliegen.
• Als Gesamtverantwortlicher für die TI möchte ich, dass nur berechtigte Institutionen für die Pflege der Informationen die entsprechenden Berechtigungen (er)halten.
• Als Gesamtverantwortlicher für die TI muss ich sicherstellen, dass bei einem Ausfall des Dienstes die Kunden entsprechendes Feedback und Support erhalten und ggf. Fehlermeldungen korrekt eingestellt und weitergeleitet werden.

3 Einordnung in die Telematikinfrastruktur

Das E-Rezept wird in der Telematikinfrastruktur durch drei wesentliche Komponenten/Produkttypen realisiert. Der E-Rezept-Fachdienst speichert und verwaltet den Status der elektronischen Verordnungen, der Zugriff durch Clients erfolgt für Leistungserbringer über ihre Primärsysteme, Versicherte nutzen zur Verwaltung ihrer E-Rezepte das E-Rezept-Frontend des Versicherten (E-Rezept-FdV) oder das E-Rezept-Anwendungen des Versicherten (E-Rezept-AdV).

Um Versicherten im E-Rezept-FdV eine Übersicht der Apotheken zu geben, die ein E-Rezept beliefern können, wird ein Apothekenverzeichnis eingeführt, das dem Versicherten beschreibende Informationen (Anschrift, Öffnungszeiten, weitere Dienstleistungen) und dem E-Rezept-FdV Daten zur Anzeige des Apothekenstandorts in einer Karte liefert.

Das Apothekenverzeichnis wird als Service der Telematikinfrastruktur konzipiert, der die Daten zum Abruf im Internet durch das E-Rezept-FdV bereitstellt. Der Zugriff durch das E-Rezept-FdV soll über eine FHIR-Schnittstelle, analog der Schnittstelle des E-Rezept-Fachdienstes, erfolgen. Der FHIR-Standard definiert ein RESTful Interface und findet zunehmend Verbreitung im digitalen Gesundheitswesen. Der Vorteil liegt in der Einfachheit der verwalteten Ressourcen und des Transports über das HTTP-Protokoll. Für das Apothekenverzeichnis werden zwei Datentypen (Standort: Location, Dienstleistungen: HealthcareService) benötigt. Mit einer entsprechenden Konfiguration und angemessener Sicherheitsleistung kann hierfür ein Standard-FHIR-Server verwendet werden.

Die für das E-Rezept notwendigen Apothekendaten werden vom Deutschen Apothekerverband (DAV) als Leistungserbringerorganisation der Apotheken in Deutschland und Gesellschafter der gematik bereitgestellt. Das Apothekenverzeichnis stellt eine apothekerverwaltete Teilkomponente des Verzeichnisdienstes der Telematikinfrastruktur dar.  

Die folgende Abbildung gibt einen Überblick des Apothekenverzeichnisses mit den beteiligten Komponenten und Diensten in der Telematikinfrastruktur.

Abbildung 1: Überblick Apothekenverzeichnis

Das E-Rezept-FdV als Komponente der Telematikinfrastruktur ruft die Schnittstellen des Apothekenverzeichnisses und des Apothekenportals über das Internet auf. Der Verzeichnisdienst der TI wird vom Apothekenverzeichnis über die im Internet erreichbare Pflegeschnittstelle aufgerufen. Für die Lieferung von Betriebsdaten nutzt das Apothekenverzeichnis die Schnittstelle der Betriebsdatenerfassung im Internet. Das Apothekenverzeichnis ist nicht an das zentrale Netz der Telematikinfrastruktur angeschlossen.

Der Import von Apothekendaten in das Apothekenverzeichnis erfolgt durch ein Drittsystem des Anbieters des Apothekenverzeichnisses, das nicht als Teil der Telematikinfrastruktur betrachtet wird. Es wird hier der Vollständigkeit halber dargestellt.

4 Technisches Konzept

Die folgenden Ausführungen stellen den technischen Rahmen und das Zusammenspiel der beteiligten Produkttypen in konzeptionellen Anforderungen dar.

Das Apothekenverzeichnis wird als Service konzipiert, der FHIR-Ressourcen verwaltet und über eine RESTful-Schnittstelle zum Abruf im Internet gemäß [FHIR-API] bereitstellt. Es kann als Erweiterung eines bestehenden FHIR-Servers oder als eigenständiger FHIR-Server realisiert werden. In einer ersten Stufe werden zunächst die FHIR-Ressourcen Location und HealthcareService betrachtet, was den Einsatz eines FHIR-Servers mit größerem Funktionsumfang nicht ausschließt.

Im Folgenden werden die wesentlichen Use Cases der Interaktion mit dem Apothekenverzeichnis dargestellt.

4.1 Use Case "Apothekeninformationen abrufen"

Mit diesem Anwendungsfall kann ein Versicherter über das Clientsystem Apothekeninformationen aus dem Apothekenverzeichnis abrufen und anzeigen lassen.

AF_10076 - UC "Apothekeninformationen abrufen"

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

Tabelle 1 : Apothekeninformationen abrufen

Name	Apothekeninformationen abrufen
Vorbedingungen	keine
Kurzbeschreibung (Außenansicht)	Das Clientsystem greift direkt auf das Apothekenverzeichnis zu. Dazu fragt das Clientsystem beim Apothekenverzeichnis die Ressourcen mit ihren FHIR-spezifischen Suchparametern an. Der Versicherte benennt Suchkriterien, die das Clientsystem als Suchparameter in den Aufruf einbettet. Das Clientsystem erhält eine passende Treffermenge als Antwort.
Nachbedingungen	Die Liste der zur Suchanfrage passenden Apotheken liegen als Liste im Clientsystem zur Anzeige bzw. Darstellung auf einer Karte  bereit. Der Versicherte hat die Option, eine Nachricht an eine aus der Treffermenge erwählte Apotheke zu schicken.

Abbildung 2: Apothekensuche  

[<=]

4.2 Use Case "Pflege des Apothekenverzeichnisses"

Mit diesem Anwendungsfall kann ein Redakteur die Einträge des Apothekenverzeichnisses aktualisieren.

AF_10077 - UC "Pflege des Apothekenverzeichnisses"

Alle am Anwendungsfall "Pflege des Apothekenverzeichnisses" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 2 : Pflege des Apothekenverzeichnisses

Name	Pflege des Apothekenverzeichnis
Vorbedingungen	Redakteur ist mit Redakteurrechten (insbesondere Schreibrechte) im Apothekenverzeichnis registriert Für zu aktualisierende Einträge hat ein initialer Import stattgefunden, die Ressourcen-ID der Einträge im Apothekenverzeichnis sind bekannt Im Pflegeclient liegen Informationen zur Aktualisierung einzelner Apothekenverzeichniseinträge vor
Kurzbeschreibung (Außenansicht)	Der Redakteur stößt die Aktualisierung im Pflegeclient an. Der Pflegeclient weist sich gegenüber dem Apothekenverzeichnis mit den Zugangsdaten des Redakteurs aus. Für jeden zu aktualisierenden Eintrag wird ein Aktualisierungsaufruf (POST, PUT, etc. adressiert über die bekannte Ressourcen-ID) mit den zu ändernden Daten an das Apothekenverzeichnis geschickt. Das Apothekenverzeichnis bestätigt die Änderung mit dem neu angelegten oder aktualisierten Datensatz in der Response inkl. Nennung der Ressourcen-ID für die Adressierung in zukünftigen Anwendungsfällen. Wurde ein Eintrag des Apothekenverzeichnisses über den Statusabgleich mit dem VZD gelöscht, beantwortet das Apothekenverzeichnis den Aufruf mit dem HTTP-Status-Code 404.
Nachbedingungen	aktualisierte Apothekeninformationen liegen zum Abruf durch Clients bereit

Abbildung 3: Pflege des Apothekenverzeichnisses 

[<=]

4.3 Leistungen des Apothekenverzeichnisses

Das Apothekenverzeichnis wird als FHIR-Server eingeführt. Um die zweckgebunden erhobenen Informationen des Apothekenverzeichnisses vor unberechtigtem Zugriff (außerhalb des Gesundheitswesens) zu schützen, sind Zugriffe ausschließlich durch authentifizierte Nutzer zulässig. 

Das Apothekenverzeichnis muss den Abruf von Apothekeninformationen über die Bereitstellung einer HL7-FHIR-konformen REST-Schnittstelle [FHIR_API] ermöglichen.

Das Apothekenverzeichnis muss die Pflege von Apothekeneinträgen über eine Schnittstelle für autorisierte Nutzer ermöglichen.

Das Apothekenverzeichnis muss Maßnahmen zum Schutz vor der aktuellen Version der OWASP-Top-10-Risiken umsetzen.

Das Apothekenverzeichnis muss sicherstellen, dass der Status der gelisteten Apotheken mit jenen des VZD der Telematikinfrastruktur übereinstimmt.

4.4 Leistungen eines Clientsystems

Das Clientsystem erreicht das Apothekenverzeichnis über das Internet. Für eine intuitive Suche nach relevanten Informationen sind Nutzer auf geeignete Darstellungen und User Interfaces angewiesen. Als Clientsysteme kommt für das Apothekenverzeichnis in einer ersten Umsetzung das E-Rezept-FdV zum Einsatz.

Das Clientsystem muss die Schnittstelle des Apothekenverzeichnisses als HTTP-REST-Client gemäß den Festlegungen in [FHIR-API] nutzen.

Das Clientsystem muss abgerufene Apothekeninformationen aus dem Apothekenverzeichnis lokal cachen, um das Aufrufaufkommen am Apothekenverzeichnis auf sinnvolle Suchanfragen zu reduzieren. So muss bspw. das minimale Verschieben der Ansicht auf einer Karte und die sekundliche Frage nach "neuen" Daten nicht notwendigerweise zu einem erneuten Schnittstellenaufruf führen.

Das Clientsystem muss dem Nutzer ein geeignetes User Interface zur Eingabe von Filterkriterien für Apothekennamen, Adressinformationen und Dienstleistungen anbieten.

Das Clientsystem muss vom Nutzer vor der ersten Abfrage zu dessen aktueller Geoposition die Einwilligung zur Abfrage und Zustimmung zur Übermittlung an das Apothekenverzeichnis einholen.

4.5 Leistungen zur Pflege der Informationen

Das Apothekenverzeichnis hat das Ziel, Informationen für Versicherte zu allen öffentlichen Apotheken in Deutschland und Versandapotheken bereitzustellen, damit die Versicherten ein E-Rezept in der Apotheke ihrer Wahl einlösen und über das E-Rezept-FdV mit der Apotheke kommunizieren können.

Die für diesen Mehrwert der Versicherten nötigen Informationen unterliegen Anpassungen (Öffnungszeiten, Nacht-/Notdienstzeiten, Lieferoptionen etc.) und werden über einen Dienstleister von den Apothekern erhoben. Dieser Dienstleister pflegt mögliche Anpassungen an den Informationen in das Apothekenverzeichnis ein oder stellt sie über eine API zum Import bereit. Neben diesen vom Dienstleister verwalteten Einträgen können zusätzliche Einträge existieren, deren Pflegehoheit bei der gematik liegt (z.B. Informationen über Versandapotheken mit Sitz im europäischen Ausland).

Das Apothekenverzeichnis muss den Dienstleister als Redakteur der Apothekeninformationen eindeutig anhand spezieller Redakteur-Zugangsdaten identifizieren.

Das Apothekenverzeichnis muss den Import und die Aktualisierung von Apothekeninformationen durch einen Redakteur über das Internet gemäß einer HL7-FHIR-konformen REST-Schnittstelle [FHIR_API] ermöglichen.

Das Apothekenverzeichnis muss das Aktualisieren und das Löschen von Einträgen, die der Pflege durch einen Redakteur unterliegen, über das Internet gemäß einer HL7-FHIR-konformen REST-Schnittstelle [FHIR_API] ermöglichen.

Das Apothekenverzeichnis muss bestimmte Einträge des Apothekenverzeichnisses auf Antrag der gematik als nicht-änderbar und nicht-löschbar durch einen Redakteur markieren können.

4.6 Informationsmodell

Das Apothekenverzeichnis wird als FHIR-Server konzipiert. Für das Abbild der notwendigen Apothekeninformationen werden die Standard-Profile der HL7-FHIR-Ressourcen Location und HealthcareService verwendet.

Das Apothekenverzeichnis und das Clientsystem müssen die Standard-Profile für Location [FHIR-Location] und HealthcareService [FHIR-HealthcareService] gemäß den Festlegungen im FHIR-Standard unterstützen.

Das Apothekenverzeichnis muss für den Statusabgleich der Apothekeneinträge mit dem Status im VZD die Telematik-ID als Primärschlüssel verwenden.

5 Spezifikation

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

5.1 Anforderungen an das Apothekenverzeichnis

Dieser Abschnitt beschreibt die Anforderungen an das Apothekenverzeichnis als Produkttyp und an den Anbieter des Apothekenverzeichnisses. Als Produkt kann das Apothekenverzeichnis als eigenständige Komponente oder Erweiterung eines existierenden Produkttyps realisiert werden. Der Anbieter des Apothekenverzeichnisses kann ebenso als eigenständiger Anbieter auftreten oder der Anbieter eines existierenden Produkts übernimmt die Anbieterrolle für das Apothekenverzeichnis, das als Erweiterung seines Produkts umgesetzt wird.

5.1.1 Abgleich mit Verzeichnisdienst der TI (VZD)

Der Verzeichnisdienst der TI (VZD) ist das führende Verzeichnis der bekannten und registrierten Leistungserbringerinstitutionen und wird von den Kartenherausgebern der zertifikatsgebundenen Institutsidentitäten (SMC-B) gepflegt. Daher ist ein regelmäßiger Statusabgleich der im Apothekenverzeichnis gelisteten Apothekeneinträge mit dem technischen Status in der Telematikinfrastruktur erforderlich, um ggfs. keine veralteten Einträge an Clients des Apothekenverzeichnisses herauszugeben.

Die Liste aller aktuell gültigen Apothekeneinträge ist über die RESTful-Pflegeschnittstelle des VZD über das Internet abrufbar. Hierfür müssen Zugangsdaten beim Anbieter des VZD der Telematikinfrastruktur beantragt werden. Eine detaillierte Beschreibung findet sich im Dokument [gemILF_Pflege_VZD]. Insbesondere Abschnitt 3 "API Dokumentation" erläutert detailliert die Schritte zur Beantragung und Implementierung eines Clients zum Abruf der Daten.

Tabelle 3 : Mapping der Attribute der Pflegeschnittstelle auf FHIR Datenobjekte

Im VZD sind ggfs. Apotheken gelistet, denen die Belieferung von E-Rezepten nicht gestattet ist bzw. an deren Belieferung besondere Anforderungen gerichtet sind (z.B. Bundeswehrapotheken). Das Apothekenverzeichnis stellt Clients nur solche Einträge zum Abruf bereit, in denen eine Einlösung von E-Rezepten möglich ist. Eine Liste der zulässigen Einträge soll konfigurierbar sein.

Zunächst wird die konfigurierbare Liste der zulässigen Einträge des Apothekenverzeichnisses nur die öffentliche Apotheke umfassen (oid_oeffentliche_apotheke). Versandapotheken werden ebenfalls unter dieser Rollen-OID geführt.

5.1.2 Authentifizierung von Clientsystemen

Das Apothekenverzeichnis führt öffentliche Informationen über Apotheken in Deutschland sowie weitere von den Apothekeninhabern erhobene, zweckgebundene Auskünfte zur Nutzung im E-Rezept. Zusätzlich sind Informationen (Telematik-ID) enthalten, die nur in Anwendungsfällen für authentifizierte Nutzer genutzt werden kann und ebenso als schützenswerte Informationen bewertet sind. Daher ist der Zugriff auf solche Informationen nur authentifizierten Nutzern gestattet, wobei das Apothekenverzeichnis keine Auswertung der individuellen Nutzerinformationen vornimmt. Das Apothekenverzeichnis erlaubt daher den Zugriff nur explizit authentifizierten Nutzern (Redakteuren) und technischen Systemen mit Wissen um einen API-Key. 

Für die Pflege der Informationen durch einen Redakteur sind gesonderte Zugriffsrechte erforderlich.

5.1.3 Schnittstelle

Für den Abruf von Apothekeninformationen stellt das Apothekenverzeichnis eine Schnittstelle im Internet zur Verfügung.

Zum Angebot der FHIR-Schnittstelle gehört gemäß Definition der FHIR-Konformität die Bereitstellung eines Capability-Statements.

Tabelle 4 : Verwendete Attribute Ressource Location

Tabelle 5 : Verwendete Attribute Ressource HealthcareService

Zur Klarstellung der Funktionsweise sind im Folgenden die Ergänzungen zu den Standardprofilen dargestellt.

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

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.

5.2 Anforderungen an Clients des Apothekenverzeichnisses

Clientsysteme haben keine hochfrequenten Änderungen im Apothekenverzeichnis zu erwarten. Um jedoch das eigene Datenvolumen zu schonen ist es ratsam, Abfrageergebnisse zu cachen. Aufgrund der standardisierten Suchparameter inkl. Geopositions-Suche kann das Apothekenverzeichnis eine Stütze beim Auffinden relevanter Apothekeneinträge sein.

5.3 Sicherheits- und Datenschutzaspekte

Dem Anbieter des Apothekenverzeichnisses werden entsprechend dem Modularisierungskonzept in [gemSpec_DS_Anbieter] die folgenden Module der Informationssicherheit und des Datenschutzes zugeordnet:

• Informationssicherheit: Basis-IS, Basis-ISMS, TI-Sicherheitsbericht
• Datenschutz: Basis-DS, TI- Datenschutzbericht 

Die Überprüfung der Anforderungen erfolgt im Wesentlichen über ein Anbieter-Sicherheitsgutachten.

Diese Zuordnung begründet sich aus der Situation, dass auf der einen Seite das Apothekenverzeichnis logisch als Teil des Verzeichnisdienstes der TI gesehen wird, und auf der anderen Seite im Apothekenverzeichnis keine personenbezogenen medizinischen Daten verarbeitet werden.

Jedoch erhält das Apothekenverzeichnis Daten aus dem Verzeichnisdienstes der TI, um einen Abgleich der Einträge vornehmen zu können. Diese Daten dürfen durch den Apothekenverzeichnis-Betreiber nur in der vorgesehenen Weise verwendet werden. Die gematik hat ein Interesse daran, dass die Daten der Apotheken im Apothekenverzeichnis korrekt sind.

Da es sich bei der Apothekensuche um eine Komfortfunktion handelt, ist aus Sicht der Sicherheit keine besondere Verfügbarkeit des Apothekenverzeichnisses erforderlich.

Folgende Anforderungen sind spezifisch für das Apothekenverzeichnis umzusetzen:

5.4 Betrieb

Das Apothekenverzeichnis wird als neuer Produkttyp konzipiert und wird von einem neuen Anbieter betrieben. Aus Sicht des Betriebes relevante Anforderungen wurden dem Produkt- und dem Anbietertypsteckbrief zugewiesen. Das Apothekenverzeichnis wird aus Sicht des Betriebes wie der Fachdienst E-Rezept behandelt. Ergänzende oder abweichende Anforderungen und Regelungen werden im Folgenden beschrieben.

5.4.1 Servicemodell

Der Anbieter Apothekenverzeichnis muss die organisatorischen Service Level im Modell H+N gemäß [gemKPT_Betr#TIP1-A_7265-03] liefern.

6 Beispiele und Referenzimplementierungen

Beispiele zur Nutzung der Abrufschnittstelle des Apothekenverzeichnisses finden sich auf der github-Seite der gematik unter https://github.com/gematik/api-erp/blob/master/docs/erp_versicherte.adoc#eine-apotheke-aus-dem-apotheken-verzeichnis-ausw%C3%A4hlen 

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Referenzierte Dokumente

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

7.2.2 Weitere Dokumente