Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature

E-Rezept: Workflow-Steuerung durch Leistungserbringer

    

     

      
Version
      
1.0.1
     
     

      
Revision
      
947492
     
     

      
Stand
      
09.08.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_eRp_WF_LE
     
    

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 das Feature eines E-Rezept-Workflows unter der Steuerungshoheit des verordnenden Leistungserbringers für die Fachanwendung E-Rezept. Das Feature umfasst die Definition der Prozessparameter und Ergänzungen der workflowspezifischen Anforderungen an die Schnittstellen des E-Rezept-Fachdienstes sowie die Darstellung der Use Cases für verordnende Leistungserbringer und Versicherte.

1.1 Zielsetzung

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

1.2 Zielgruppe

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

1.3 Abgrenzungen

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

1.4 Methodik

Anforderungen

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

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

Anforderungen 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. [Wikepedia:User Storie]
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 Story

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

2.1 Epic Direkte Zuweisung des E-Rezepts durch den Verordnenden

Dieses Epic beschreibt besondere Versorgungssituationen, in denen, abweichend vom Regelprozess des E-Rezepts mit Verordnung erstellen → QES → Übergabe an Versicherten → Zuweisung an Apotheke → Dispensierung an Versicherten /Vertreter, ein E-Rezept direkt vom verordnenden Leistungserbringer an die abgebende Apotheke zugewiesen und übermittelt wird. Grundlage für die Anwendung dieses Workflows sind die Regelungen für anwendungsfertige Zytostatikazubereitungen in § 11 Absatz 2 Apothekengesetz (ApoG) und für die Arzneimittelversorgung durch krankenhausversorgende Apotheken und Krankenhausapotheken im Rahmen von § 14 Absätze 7 und 8 des Apothekengesetzes (ApoG).

Für die hier dargestellten Verordnungen existiert ein direkter Patientenbezug, sie sind daher abzugrenzen von Verordnungen für Sprechstundenbedarf. 

Das Epic beschreibt die Zuweisung und Übermittlung eines E-Rezepts an eine Apotheke durch die verordnenden Leistungserbringer sowie die Abgabe in der Apotheke. Prozesse der Herstellung von Arzneimitteln sowie der Dokumentation der Herstellung als Voraussetzung für die Abrechnung finden außerhalb der TI statt und werden daher hier nicht beschrieben. Da insbesondere im Bereich der Zytostatikazubereitungen zwischen abgebender und herstellender Apotheke unterschieden wird, wird in den folgenden User Stories von der abgebenden Apotheke gesprochen, um diese Prozessabgrenzung zu verdeutlichen. 

2.1.1 User Stories

Voraussetzung jeder nachfolgenden User Story ist, dass die gesetzlichen Grundlagen in § 11 Absatz 2 und § 14 Absätze 7 und 8 des ApoG erfüllt sind. 

2.1.1.1 Arzt

• Als Arzt möchte ich für bestimmte Medikamentenverordnungen ein E-Rezept unkompliziert einer Apotheke im gesetzlichen Rahmen direkt zuweisen können. 
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen nicht, dass der Patient diese Verordnungen löscht.
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen nicht, dass der Patient diese Verordnungen einer Apotheke zuweisen kann.
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen den von mir gewohnten Standard für die Übermittlung des E-Rezept-Tokens an die Apotheke nutzen, so dass ich ihn beliebig teilen kann (z.B. Ausdruck oder Weiterleiten mit sicherem Übermittlungsverfahren). 
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen E-Rezepte bestimmten, von mir einstellbaren Apotheken zuweisen können. 
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen E-Rezepte automatisch an meine herstellende Apotheke zuweisen können, wenn ich die herstellende Apotheke vorher festgelegt und die automatische Zuweisung eingerichtet habe, so dass ich mir zusätzliche und sich wiederholende Arbeitsschritte sparen kann. 
• Als Arzt möchte ich für bestimmte Medikamentenverordnungen die Zuweisung eines E-Rezepts an eine Apotheke auch an meine Mitarbeiter delegieren können, so dass ich nicht alles selber machen muss.
• Als Arzt möchte ich einstellen können, dass ich für bestimmte Medikamentenverordnungen benachrichtigt werde, wenn ein E-Rezept in der Apotheke nicht beliefert werden kann und daher zurückgegeben wird oder wenn es gelöscht wird, oder wenn das Medikament abgegeben worden ist, so dass ich immer über den aktuellen Status informiert bin und wenn notwendig handeln kann. 

2.1.1.2 Abgebende Apotheke

• Als abgebende Apotheke möchte ich, dass sich die Zuweisung von E-Rezepten für alle Medikamentenverordnungen aus meiner Sicht nicht unterscheidet, unabhängig davon, um welche Medikamentenverordnungen es sich handelt und wer die Zuweisung vorgenommen hat.
• Als abgebende Apotheke möchte ich bei den durch einen Verordnenden zugewiesenen Medikamentenverordnungen nicht mit dem Patienten kommunizieren, weil die Kommunikation, falls notwendig, mit dem Verordnenden erfolgt.
• Als abgebende Apotheke möchte ich die unterschiedlichen Typen von Medikamentenverordnungen unterscheiden können.
• Als abgebende Apotheke möchte ich unabhängig davon, wer mir ein E-Rezept zugewiesen hat, ein Medikament schnell liefern können.
• Als abgebende Apotheke möchte ich dem verordnenden Arzt auf dem gleichen Übermittlungsweg, über den er mir das E-Rezept zugewiesen hat, antworten können, um mit ihm direkt und unkompliziert zur Belieferung eines E-Rezepts kommunizieren zu können.

2.1.1.3 Versicherter

• Als Versicherter möchte ich auch Medikamentenverordnungen, die mein Arzt direkt einer Apotheke zuweist, in meiner E-Rezept-App einsehen können, so dass ich volle Transparenz über alle meine Verordnungen habe.
  
• Als Versicherter möchte ich für bestimmte Medikamentenverordnungen in meiner E-Rezept-App den Status des E-Rezepts einsehen können.
• Als Versicherter möchte ich für bestimmte Medikamentenverordnungen Einsicht in die Zugriffsprotokolle haben.
  
• Als Versicherter möchte ich für bestimmte Medikamentenverordnungen nicht benachrichtigt werden, wenn ein E-Rezept in der Apotheke nicht beliefert werden kann und daher zurückgegeben wird oder wenn es gelöscht wird, oder wenn das Medikament abgegeben worden ist.
• Als Versicherter möchte ich für bestimmte Medikamentenverordnungen keine Nachrichten an die Apotheke senden und auch keine Nachrichten von der Apotheke erhalten.

3 Einordnung in die Telematikinfrastruktur

Das Feature des leistungserbringergesteuerten E-Rezept-Workflows führt keine neuen Produkttypen oder Komponenten ein. Das Primärsystem der verordnenden und abgebenden Leistungserbringer benutzen die Schnittstellen des E-Rezept-Fachdienstes gemäß den Festlegungen für den bisherigen E-Rezept-Workflow 160. Das E-Rezept-FdV stellt dem Versicherten Use Cases zur Einsichtnahme in die Daten des E-Rezepts bereit. Da die Steuerungshoheit hier jedoch nicht beim Versicherten liegt, kann er keine Einlöseinformationen an Apotheker oder Vertreter weitergeben und den Vorgang auch nicht löschen.

Abbildung 1: Übersicht E-Rezept-Komponenten 

Der wesentliche Unterschied gegenüber der bisherigen Prozessdefinition für den Workflowtype 160  besteht in der Übergabe der Einlöseinformationen an die Apotheke durch den verordnenden Leistungserbringer. Für den Übertragungsweg erfolgen keine Festlegungen einer konkreten Methode. 

4 Technisches Konzept

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

4.1 Use Case E-Rezept für Workflow 169 durch Verordnenden erzeugen

Mit diesem Anwendungsfall erstellt ein Leistungserbringer einen Verordnungsdatensatz mit workflowspezifischen Parametern. Der Verordnungsdatensatz erhält von dem E-Rezept-Fachdienst eine Rezept-ID und wird von dem Leistungserbringer qualifiziert signiert. Der Leistungserbringer muss in seinem Primärsystem den workflowspezifischen Parameter für die direkte Zuweisung an eine Apotheke auswählen.

AF_10111 - E-Rezept für Workflow 169 durch Verordnenden erzeugen

Alle am Anwendungsfall "E-Rezept für Workflow 169 durch Verordnenden erzeugen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 1 : E-Rezept für Workflow 169 durch Verordnenden erzeugen

Name	E-Rezept für Workflow 169 durch Verordnenden erzeugen
Vorbedingungen	Der oder die Versicherten sind der LEI bekannt. Der HBA ist für die QES gesteckt und freigeschaltet. Die gesetzlichen Grundlagen aus § 11 ApoG sind erfüllt.
Kurzbeschreibung (Außenansicht)	Der verordnende Leistungserbringer wählt im Primärsystem einen Verordnungsdatensatz zum Signieren aus. Der Leistungserbringer wählt das Signaturverfahren aus. Der Leistungserbringer wählt im Primärsystem den Rezept-Typ "Workflow-Steuerung durch Leistungserbringer" aus. Das Primärsystem ruft für das E-Rezept vom E-Rezept-Fachdienst eine Rezept-ID ab (rote Markierung im Sequenzdiagramm) und ergänzt diese im Verordnungsdatensatz. Anschließend wird das E-Rezept mittels Konnektor mit einer QES signiert. Es kann die Einzel-, Stapel- oder Komfortsignatur genutzt werden.
Nachbedingungen	Die erzeugten E-Rezepte beinhalten eine eineindeutige Rezept-ID und haben eine QES. Der AccessCode für jedes E-Rezept ist im Primärsystem gespeichert. Die E-Rezepte sind im E-Rezept-Fachdienst angelegt und haben den Status "initialisiert".

[<=]

4.2 Use Case E-Rezept durch Verordnenden einstellen

Mit diesem Anwendungsfall stellt eine verordnende Leistungserbringerinstitution ein E-Rezept auf den E-Rezept-Fachdienst ein und erzeugt den zugehörigen E-Rezept-Token.

AF_10112 - E-Rezept durch Verordnenden einstellen

Alle am Anwendungsfall "E-Rezept durch Verordnenden einstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 2 : E-Rezept durch Verordnenden einstellen

Name	E-Rezept durch Verordnenden einstellen
Vorbedingungen	Der verordnende Leistungserbringer hat den Anwendungsfall "UC 2.1 - E-Rezepte erzeugen" ausgeführt. Ein E-Rezept und die zugehörige Signatur liegen im Primärsystem vor. Die Rezept-ID und der AccessCode sind im Primärsystem bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "initialisiert".
Kurzbeschreibung (Außenansicht)	Der verordnende Leistungserbringer oder ein Mitarbeiter der medizinischen Institution wählt im Primärsystem ein E-Rezept zum Einstellen aus. Das Primärsystem aktualisiert das E-Rezept im E-Rezept-Fachdienst. Das Primärsystem erstellt einen E-Rezept-Token und speichert diesen.
Nachbedingungen	Das E-Rezept ist im E-Rezept-Fachdienst gespeichert und hat den Status "offen". Das Einstellen ist im E-Rezept-Fachdienst protokolliert.

[<=]

4.3 Use Case E-Rezept-Token an Apotheker übermitteln

In diesem Anwendungsfall übermittelt die verordnende LEI die Einlöseinformationen (Task-ID und AccessCode) eines E-Rezepts direkt an eine Apotheke. Der Abruf des E-Rezepts in der Apotheke unterscheidet sich nicht vom Standard-Workflow und wird hier daher nicht beschrieben. 

AF_10113 - E-Rezept-Token an Apotheker übermitteln

Alle am Anwendungsfall "E-Rezept-Token an Apotheker übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 3 : E-Rezept-Token an Apotheker übermitteln

Name	E-Rezept-Token an Apotheker übermitteln
Vorbedingungen	In der verordnenden LEI wurde der Anwendungsfall "UC 2.3 - E-Rezept einstellen" ausgeführt
Kurzbeschreibung (Außenansicht)	Die verordnende LEI bestimmt die Adressatinformationen der intendierten Apotheke (z.B. mittels VZD) und wählt das E-Rezept-Token des direkt zuzuweisenden E-Rezepts aus.   Das Primärsystem der verordnenden LEI erstellt eine Nachricht, bettet das E-Rezept-Token in die Nachricht ein (z.B. als URL) und sendet die Nachricht an die abgebende Apotheke. Das Primärsystem der abgebenden LEI empfängt die Nachricht und extrahiert das E-Rezept-Token.
Nachbedingungen	Die abgebende LEI ist in der Lage, das E-Rezept einzusehen und zu beliefern

[<=]

4.4 Use Case E-Rezept durch Versicherten einsehen

Der Versicherte kann in diesem Workflow E-Rezepte einsehen sowie auf die Dispensierinformationen und das Zugriffsprotokoll zugreifen. Ein Löschen durch den Versicherten ist nicht möglich.

AF_10114 - E-Rezept durch Versicherten einsehen

Alle am Anwendungsfall "E-Rezept durch Versicherten einsehen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 4 : E-Rezept durch den Versicherten einsehen

Name	E-Rezept durch Versicherten einsehen
Vorbedingungen	keine
Kurzbeschreibung (Außenansicht)	Ein Versicherter ruft alle seine im E-Rezept-Fachdienst eingestellten Rezepte ab. Der E-Rezept-Fachdienst identifiziert die E-Rezepte auf Basis der Versicherten-ID des Versicherten und liefert die E-Rezepte, Status und die Zeitpunkte, an denen die Status gesetzt wurden. Die AccessCodes werden dem Versicherten für diesen speziellen Rezept-Typ nicht übermittelt.
Nachbedingungen	Im FdV stehen die E-Rezepte zur Anzeige bereit. Der Abruf ist im E-Rezept-Fachdienst protokolliert.

[<=]

4.5 Informationsmodell

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

Der Workflow für die direkte Zuweisung von Verordnungen durch die verordnende an die abgebende Leistungserbringerinstitution nutzt das Datenmodell und die FHIR-Ressourcen für den Workflow mit Flowtype 160 für apothekenpflichtige Arzneimittel unter der Steuerungshoheit durch den Versicherten. Das Datenmodell des Verordnungsdatensatzes der KBV bleibt unverändert. Die FHIR-Ressourcen des E-Rezept-Fachdienstes Task, Communication, Bundle/Composition, Medication Dispense und Audit Event bleiben ebenfalls gleich. Es wird lediglich ein neuer Flowtype 169 zur Erkennung des abweichenden Prozessablaufs und zur Nutzung in der Berechnung der Rezept-ID eingeführt.

Die folgende Tabelle gibt einen Überblick der Prozessparameter und stellt sie dem Prozess für Flowtype 160 gegenüber.

Tabelle 5: Übersicht Prozessparameter im Vergleich 

optional: Dies weist darauf hin, dass der Anwender der Funktion zustimmt bzw. dass er sie abstellen kann 

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.

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

5.1 Anforderungen an den E-Rezept-Fachdienst

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

Dieser Abschnitt beschreibt die Anforderungen an den E-Rezept-Fachdienst als Produkttyp und den Anbieter des E-Rezept-Fachdienstes. Die folgenden Anforderungen sind als Ergänzung zur Spezifikation [gemSpec_FD_eRp] für den hier spezifizierten Workflow umzusetzen, ergänzen aber auch die bisherigen allgemeinen Anforderungen und Spezifikationslücken. 

5.2 Anforderungen an das E-Rezept-Frontend des Versicherten

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

Für E-Rezepte mit dem Flowtype 169 gibt es folgende Einschränkungen im E-Rezept-FdV:

• Der Versicherte darf das E-Rezept nicht löschen.
• Der Versicherte darf das E-Rezept nicht einer Apotheke zuweisen
• Der Versicherte darf keinen Vertreter für das Einlösen des E-Rezeptes berechtigen.

5.3 Anforderungen an das Primärsystem der verordnenden LEI

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

Anwendungsfall "E-Rezept durch Verordnenden erstellen"

Anwendungsfall "E-Rezept durch Verordnenden einstellen"

5.4 Anforderungen an das Primärsystem der abgebenden LEI

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

5.5 Fast Healthcare Interoperability Resources

Es ergeben sich keine Änderungen am FHIR Datenmodell.

5.6 Anforderungen für Prozessparameter

Die nachfolgenden Anforderungen werden in [gemSpec_DM_eRp] und [gemSpec_FD_eRp] übernommen.

Im Folgenden sind die Anforderungen an die E-Rezept-Produkttypen dargestellt, mit denen die Prozessparameter aus Abschnitt 4 umgesetzt werden sollen. Diese Anforderungen werden mit Einführung dieses Features ins Feld in die Spezifikation des Datenmodells zum E-Rezept [gemSpec_DM_eRp] migriert bzw. gemerged. Anforderungen mit gleichlautendem Inhalt für Flowtype 160 in anderen E-Rezept-Spezifikationen werden ebenfalls in [gemSpec_DM_eRp] konsolidiert, insbesondere um die Spezifikation des E-Rezept-Fachdienstes [gemSpec_FD_eRp] perspektivisch auf den Stand eines generischen, parametergesteuerten Workflow-Servers zu bringen. 

5.6.1 Gültigkeitszeitraum

Erweiterung A_19445-* - FHIR FLOWTYPE für Prozessparameter

5.6.2 Löschfristen

Es gelten die Löschfristen, wie für E-Rezepte des Workflows 169.

5.6.3 Berechtigungen und Prozessparameter

5.7 E-Rezept-spezifische KIM-Message

Es werden zwei E-Rezept-spezifische KIM-Messages 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.

Beispiel für eine E-Rezept-spezifische KIM-Message für die Zuweisung eines E-Rezeptes

Beispiel für eine E-Rezept-spezifische KIM-Message für die Kommunikation zu einem E-Rezept

5.8 Sicherheit

Die nachfolgenden Anforderungen werden in [gemILF_PS_eRp] übernommen.

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

5.9 Betrieb

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

5.9.1 Verfügbarkeit

Für die Direktzuweisung eines Rezeptes über Flowtype 169 existieren keine abweichenden Anforderungen an die Verfügbarkeit. Es gelten die bereits existierenden Anforderungen an den E-Rezept-Fachdienst.

5.9.2 Last

Für die Direktzuweisung eines Rezeptes über Flowtype 169 werden die Anforderung zum Lastverhalten des E-Rezept-Fachdienstes nicht verändert, da in der initial geschätzten Last für die Stufe 1 (Flowtype 160) alle Rezepte mit Muster 16 berücksichtigt wurden.

5.9.3 Antwortzeiten

Die Direktzuweisung eines Rezeptes mittels Flowtype 169 ändert nichts an den bestehenden Antwortzeit-Vorgaben der existierenden Fachdienst Operationen. Diese bleiben unberührt und gelten weiterhin.

5.9.4 Bereitstellung von Betriebsdaten

Aufgrund der Tatsache, dass im Zuge der Einführung der Direktzuweisung der neue Flowtype 169 eingeführt wird, muss das Format der Bereitstellung der Rohdaten angepasst werden, um hier eine Unterscheidung zum bereits existierenden Flowtype 160 zu ermöglichen.

Dies kann bspw. über das Auslesen des Flowtype im Body des HTTP-Requests der Fachdienstoperation ERP.UC_2_3 erfolgen.

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

Tabelle 8: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst

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

Tabelle 9: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall 

Tabelle 10: Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben

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

5.9.5 Performance-Kenngrößen

In der Tabelle [gemKPT_Betr#Tab_gemKPT_Betr_UC_Anwendungsfallübersicht] wird der folgende Anwendungsfall geändert bzw. hinzugefügt:

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

6 Dokumentenhaushalt

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

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

6.2 Übersicht Produkt- und Anbietertypen

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

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

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

Allgemeine Begriffe finden sich in [gemGlossar].

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

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

7.5.2 Weitere Dokumente