Implementation Guide
TIFlow - Verordnungen für Arzneimittel
Version 2.0.0-ballot.2 - ballot

## Technische Anwendungsfälle

Diese Seite beschreibt die technischen Anwendungsfälle, die für das Modul der Verordnung von Arzneimitteln genutzt werden.

### Umzusetzende Anwendungsfälle von Clients

#### PS verordnende LEI

funkt. Eignung: Herstellererklärung Das PS der verordnenden LEI MUSS für die Umsetzung der Verordnung von E-Rezepten für Arzneimittel die Anwendungsfälle

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

umsetzen.

#### E-Rezept-FdV

funkt. Eignung: Herstellererklärung Das E-Rezept-FdV MUSS für die Umsetzung der Nutzung von E-Rezepten für Arzneimittel die Anwendungsfälle

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

umsetzen.

#### PS abgebende LEI

funkt. Eignung: Herstellererklärung Das PS der abgebenden LEI MUSS für die Umsetzung der Belieferung von E-Rezepten für Arzneimittel die Anwendungsfälle

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

umsetzen. funkt. Eignung: Herstellererklärung Das PS der abgebenden LEI SOLL für die Umsetzung der Belieferung von E-Rezepten für Arzneimittel den Anwendungsfall

- UC 4.16 - Dispensierinformationen bereitstellen

umsetzen.

### Technische Use Cases

#### Verordnende Leistungserbringerinstitution

##### UC 2.1 - E-Rezepte erzeugen

Beschreibung | Der verordnende Leistungserbringer erzeugt eine Verordnung im Primärsystem. Für die Verordnung wird eine Rezept-ID aus dem TI-Flow-Fachdienst bezogen und der Verordnungsdatensatz anschließend qualifiziert elektronisch signiert (QES).
Vorbedingungen | Der Versicherte ist der LEI bekannt. Ein Verordnungsdatensatz liegt im Primärsystem vor. HBA ist gesteckt und für die QES freigeschaltet.
Durchzuführende Aktionen | Der Leistungserbringer wählt den Verordnungsdatensatz und ein Signaturverfahren aus. Das Primärsystem ruft eine Rezept-ID beim TI-Flow-Fachdienst ab und ergänzt sie im Verordnungsdatensatz. Der AccessCode wird im Primärsystem gespeichert. Der Verordnungsdatensatz wird über den Konnektor mit QES signiert (Einzel-, Stapel- oder Komfortsignatur).
Nachbedingungen | E-Rezept enthält Rezept-ID und QES. AccessCode des E-Rezepts ist im Primärsystem gespeichert. Workflow zum E-Rezept ist im TI-Flow-Fachdienst im Status "draft" angelegt.
Schnittstellen | Operation API: E-Rezept erstellen QES im Primärsystem (Konnektor)
Relevante(r) Sektor(en) | (ZAHN-)ARZT

Tabelle: Fachlicher Anwendungsfall UC 2.1 - E-Rezepte erzeugen

Sequenzdiagramm:

Abbildung: UC 2.1 - E-Rezepte erzeugen

##### E-Rezept qualifiziert signieren

Beschreibung | Der Verordnungsdatensatz wird durch den (Zahn-)Arzt mittels HBA qualifiziert elektronisch signiert (QES). Vorbereitende Tätigkeiten im Primärsystem können organisatorisch delegiert werden, die QES selbst jedoch nicht.
Vorbedingungen | Rezept-ID (PrescriptionID) ist im Verordnungsdatensatz enthalten. Ein freigeschalteter HBA steht zur Verfügung. Konsistenz: `authoredOn` im Verordnungsdatensatz entspricht dem Datum der QES.
Durchzuführende Aktionen | Das Primärsystem startet die QES-Erstellung über den Konnektor. Der (Zahn-)Arzt signiert den Verordnungsdatensatz mit dem HBA. Das Primärsystem erhält den QES-signierten Datensatz zur weiteren Verarbeitung.
Nachbedingungen | QES-signierter Verordnungsdatensatz liegt im Primärsystem vor.
Schnittstellen | Keine (QES im Primärsystem)
Relevante(r) Sektor(en) | (ZAHN-)ARZT

Tabelle: Fachlicher Anwendungsfall E-Rezept qualifiziert signieren

Sequenzdiagramm:

Abbildung: E-Rezept qualifiziert signieren

##### UC 2.3 - E-Rezept einstellen

Beschreibung | Ein E-Rezept wird vom Primärsystem beim TI-Flow-Fachdienst eingestellt und ein E-Rezept-Token erzeugt.
Vorbedingungen | UC 2.1 wurde ausgeführt; E-Rezept und Signatur liegen im Primärsystem vor. Rezept-ID und AccessCode sind bekannt. Status im TI-Flow-Fachdienst ist "draft".
Durchzuführende Aktionen | Der Leistungserbringer wählt ein E-Rezept zum Einstellen aus. Das Primärsystem lädt das E-Rezept in den Workflow im TI-Flow-Fachdienst. Das Primärsystem erstellt einen E-Rezept-Token und speichert ihn.
Nachbedingungen | Das E-Rezept ist im TI-Flow-Fachdienst gespeichert. Der Workflow hat den Status "ready". Das Einstellen ist im TI-Flow-Fachdienst für den Versicherten protokolliert.
Schnittstellen | Operation API: E-Rezept aktivieren
Relevante(r) Sektor(en) | (ZAHN-)ARZT

Tabelle: Fachlicher Anwendungsfall UC 2.3 - E-Rezept einstellen

Sequenzdiagramm:

Abbildung: UC 2.3 - E-Rezept einstellen

Technische Aspekte für die Mehrfachverordnung (MVO)

Für jede Teilverordnung einer Mehrfachverordnung wird ein einzelnes E-Rezept erstellt. Im Verordnungsdatensatz wird das E-Rezept als Teil einer Mehrfachverordnung gekennzeichnet (`MedicationRequest: extension:Mehrfachverordnung.extension:Kennzeichen`).

Zusätzlich werden u.a. die Informationen

- Nummer des Rezepts der Mehrfachverordnung (`MedicationRequest.extension:Mehrfachverordnung.extension:Nummerierung.value[x]:valueRatio.numerator`)
- Gesamtzahl der Teilverordnungen in der Mehrfachverordnung (`MedicationRequest: extension Mehrfachverordnung.extension: Nummerierung.value[x]:valueRatio.denominator`)
- Start der Gültigkeit (`MedicationRequest.extension: Mehrfachverordnung extension: Zeitraum.value[x]:valuePeriod.start`)
- Ende der Gültigkeit (`MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end`) angegeben.

Jede Teilverordnung einer Mehrfachverordnung wird im TI-Flow-Fachdienst mit einem eigenen Workflow (Task) verwaltet. Dies ermöglicht den Versicherten und den Apotheken eine separate Verarbeitung jedes E-Rezepts einer Mehrfachverordnung.

##### UC 2.5 - E-Rezept durch Verordnenden löschen

Beschreibung | Ein E-Rezept wird durch die verordnende LEI gelöscht und der Status im TI-Flow-Fachdienst auf "cancelled" gesetzt.
Vorbedingungen | UC 2.3 wurde ausgeführt. Rezept-ID und AccessCode sind bekannt. Status im TI-Flow-Fachdienst ist "ready".
Durchzuführende Aktionen | Ein Mitarbeiter der verordnenden LEI markiert das E-Rezept zum Löschen und bestätigt den Vorgang. Das Primärsystem ruft den TI-Flow-Fachdienst mit Rezept-ID und AccessCode auf. Der Status wird auf "cancelled" gesetzt und medizinische Daten werden gelöscht. Der AccessCode wird im Primärsystem gelöscht.
Nachbedingungen | Der Workflow hat den Status "cancelled". Die personenbezogene und medizinische Daten (ausser Versicherten-ID) sind aus dem Workflow entfernt. Das Löschen ist im TI-Flow-Fachdienst für den Versicherten protokolliert.
Schnittstellen | Operation API: E-Rezept löschen
Relevante(r) Sektor(en) | (ZAHN-)ARZT

Tabelle: Fachlicher Anwendungsfall UC 2.5 - E-Rezept durch Verordnenden löschen

Sequenzdiagramm:

Abbildung: UC 2.5 - E-Rezept durch Verordnenden löschen

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

Beschreibung | Mit diesem Anwendungsfall erstellt ein Leistungserbringer einen Verordnungsdatensatz mit workflowspezifischen Parametern. Der Verordnungsdatensatz erhält von dem TI-Flow-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.
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.
Durchzuführende Aktionen | 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 TI-Flow-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 TI-Flow-Fachdienst angelegt und haben den Status "draft".
Schnittstellen | $create-Operation
Relevante(r) Sektor(en) | (ZAHN-)ARZT

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

Sequenzdiagramm:

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

##### E-Rezept-Token an Apotheker übermitteln

Beschreibung | 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.
Vorbedingungen | In der verordnenden LEI wurde der Anwendungsfall "UC 2.3 - E-Rezept einstellen" ausgeführt
Durchzuführende Aktionen | 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
Schnittstellen | E-Rezept-spezifische KIM-Messages
Relevante(r) Sektor(en) | (ZAHN-)ARZT

Tabelle: Fachlicher Anwendungsfall E-Rezept-Token an Apotheker übermitteln

Sequenzdiagramm:

Abbildung: E-Rezept-Token an Apotheker übermitteln

#### Versicherter

##### UC 3.1 - E-Rezepte durch Versicherten abrufen

Beschreibung | Ein Versicherter ruft im E-Rezept-FdV alle seine im TI-Flow-Fachdienst eingestellten E-Rezepte ab.
Vorbedingungen | Keine.
Durchzuführende Aktionen | Das FdV fordert E-Rezepte beim TI-Flow-Fachdienst an. Der TI-Flow-Fachdienst identifiziert E-Rezepte über die Versicherten-ID. Der TI-Flow-Fachdienst liefert E-Rezepte, Status und Statuszeitpunkte.
Nachbedingungen | E-Rezepte stehen im E-Rezept-FdV zur Anzeige bereit; Daten für E-Rezept-Token sind verfügbar. Der Abruf ist protokolliert.
Schnittstellen | Query API: Task
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.1 - E-Rezepte durch Versicherten abrufen

Sequenzdiagramm:

Abbildung: UC 3.1 - E-Rezepte durch Versicherten abrufen

##### UC 3.2 - E-Rezept durch Versicherten löschen

Beschreibung | Der Versicherte setzt den Status eines E-Rezepts auf "cancelled" und löscht es im TI-Flow-Fachdienst.
Vorbedingungen | UC 3.1 wurde ausgeführt. Status des E-Rezepts ist ungleich "in-progress".
Durchzuführende Aktionen | Versicherter wählt ein E-Rezept im E-Rezept-FdV und bestätigt das Löschen. Das E-Rezept-FdV überträgt die Löschanforderung an den TI-Flow-Fachdienst. Der Status wird geändert; Daten im E-Rezept werden gelöscht. Der E-Rezept-Token wird im E-Rezept-FdV gelöscht.
Nachbedingungen | Der Workflow hat den Status "cancelled". Die personenbezogene und medizinische Daten (ausser Versicherten-ID) sind aus dem Workflow entfernt. Das Löschen ist im TI-Flow-Fachdienst für den Versicherten protokolliert.
Schnittstellen | Operation API: E-Rezept löschen
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.2 - E-Rezept durch Versicherten löschen

Sequenzdiagramm:

Abbildung: UC 3.2 - E-Rezept durch Versicherten löschen

##### UC 3.3 - Nachricht durch Versicherten übermitteln

Beschreibung | Ein Versicherter übermittelt einen E-Rezept-Token und/oder eine Nachricht an eine abgebende Institution , wahlweise über die TI oder als 2D-Code.
Vorbedingungen | UC 3.1 wurde ausgeführt und ein E-Rezept-Token erstellt.
Durchzuführende Aktionen | Auswahl eines E-Rezept-Tokens und Versandart (TI oder 2D-Code). Bei Versand über TI: Empfängerinstitution (bspw. Apotheke) im Verzeichnisdienst suchen und auswählen. Das FdV stellt die Nachricht mit Token und/oder Text im E-Rezept-Fachdienst ein. Bei 2D-Code: Token wird als 2D-Code angezeigt oder ausgedruckt.
Nachbedingungen | Nachricht liegt im TI-Flow-Fachdienst und kann vom Empfänger abgerufen werden. Bei 2D-Code ist der Token für den Empfänger verfügbar.
Schnittstellen | Query API: Nachricht einstellen
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.3 - Nachricht durch Versicherten übermitteln

Sequenzdiagramm:

Abbildung: UC 3.3 - Nachricht durch Versicherten übermitteln

##### UC 3.4 - Nachrichten durch Versicherten empfangen

Beschreibung | Ein Versicherter empfängt Nachrichten von abgebenden Institution über den E-Rezept-Fachdienst.
Vorbedingungen | UC 4.7 wurde ausgeführt. UC 3.3 wurde ausgeführt.
Durchzuführende Aktionen | Das FdV fragt beim TI-Flow-Fachdienst nach neuen Nachrichten. Nachrichten werden heruntergeladen.
Nachbedingungen | Nachrichten liegen im FdV zur Anzeige bereit.
Schnittstellen | Query API: Nachrichten abrufen
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.4 - Nachrichten durch Versicherten empfangen

Sequenzdiagramm:

Abbildung: UC 3.4 - Nachrichten durch Versicherten empfangen

##### UC 3.8 - Nachricht durch Versicherten löschen

Beschreibung | Der Versicherte löscht von ihm übermittelte Nachrichten an Apotheken.
Vorbedingungen | UC 3.3 wurde ausgeführt.
Durchzuführende Aktionen | Der Versicherte wählt Nachrichten zum Löschen aus und bestätigt den Vorgang. Das FdV überträgt die Löschanforderung je Nachricht an den TI-Flow-Fachdienst. Der TI-Flow-Fachdienst löscht die Nachrichten. Die Nachrichten werden im FdV gelöscht.
Nachbedingungen | Nachrichten sind im TI-Flow-Fachdienst und im FdV gelöscht.
Schnittstellen | Query API: Nachricht löschen
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.8 - Nachricht durch Versicherten löschen

Sequenzdiagramm:

Abbildung: UC 3.8 - Nachricht durch Versicherten löschen

##### UC 3.9 - Dispensierinformationen durch Versicherten abrufen

Beschreibung | Ein Versicherter ruft im FdV alle seine im TI-Flow-Fachdienst eingestellten Dispensierinformationenen ab.
Vorbedingungen | Dispensierinformationen wurden durch eine abgebende LEI bereitgestellt.
Durchzuführende Aktionen | Das FdV fordert Dispensierinformationenen beim TI-Flow-Fachdienst an. Der TI-Flow-Fachdienst identifiziert Dispensierinformationenen über die Versicherten-ID. Der TI-Flow-Fachdienst liefert Dispensierinformationenen an das FdV aus.
Nachbedingungen | Dispensierinformationen stehen im FdV zur Anzeige bereit. Der Abruf ist protokolliert.
Schnittstellen | Query API: MedicationDispense
Relevante(r) Sektor(en) | VERSICHERTER

Tabelle: Fachlicher Anwendungsfall UC 3.9 - Dispensierinformationen durch Versicherten abrufen

Sequenzdiagramm:

Abbildung: UC 3.9 - Dispensierinformationen durch Versicherten abrufen

#### Apotheke

##### UC 4.6 - Nachrichten durch Abgebenden empfangen

Beschreibung | Eine abgebende LEI empfängt E-Rezept-Token über die TI oder optisch als 2D-Code.
Vorbedingungen | UC 3.3 wurde ausgeführt oder der 2D-Code wurde präsentiert.
Durchzuführende Aktionen | Das Primärsystem wählt den Empfangsweg (TI oder 2D-Code). Bei TI: Primärsystem fragt beim TI-Flow-Fachdienst neue Nachrichten für die Telematik-ID ab und lädt sie herunter. Bei 2D-Code: Primärsystem wandelt den Code in die Token-Textform um.
Nachbedingungen | E-Rezept-Token liegt im Primärsystem vor.
Schnittstellen | Query API: Nachrichten abrufen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.6 - Nachrichten durch Abgebenden empfangen

Sequenzdiagramm:

Abbildung: UC 4.6 - Nachrichten durch Abgebenden empfangen

##### UC 4.15 - E-Rezepte durch Abgebenden abrufen (PoPP)

Beschreibung | Eine Apotheke kann nach dem Einlesen der eGK auf die einlösbaren E-Rezepte des Versicherten zugreifen.
Vorbedingungen | Der Versicherte oder ein Vertreter befindet sich vor Ort im Kontakt mit einem Mitarbeiter der Apotheke. Der Versicherte hat seine eGK bzw. der Vertreter die eGK des zu Vertretenden dabei.
Durchzuführende Aktionen | Das PS liest unter Nutzung eines im Rahmen von PoPP zulässigen Kartenlesegerät die eGK ein. Das PS ruft für diese eGK den Anwendungsfall zum Erstellen eines PoPP-Token auf. Im Ergebnis erhält das PS, sofern die eGK nicht gesperrt und das Authentifizierungszertifikat gültig ist, einen PoPP-Token. Das PS übermittelt dem PoPP-Token, um die einlösbaren E-Rezepte des Versicherten vom TI-Flow-Fachdienst abzurufen. Der TI-Flow-Fachdienst prüft die Gültigkeit des PoPP-Tokens. Der TI-Flow-Fachdienst übermittelt die Zugriffsinformationen (Task-ID und AccessCode) zu jedem einlösbaren E-Rezept.
Nachbedingungen | Im PS stehen die Zugriffsinformationen (Task-ID und AccessCode) für alle einlösbaren E-Rezepte zur Verfügung. Im PS kann zu den einzelnen E-Rezepten der Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" ausführen, um die E-Rezepte im PS anzuzeigen. Der Zugriff der Apotheke auf die E-Rezepte ist für den Versicherten auf dem TI-Flow-Fachdienst protokolliert.
Schnittstellen | Query API: Task
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.15 - E-Rezepte durch Abgebenden abrufen (PoPP)

Sequenzdiagramm:

Abbildung: UC 4.15 - E-Rezepte durch Abgebenden abrufen (PoPP)

##### UC 4.1 - E-Rezept durch Abgebenden abrufen

Beschreibung | Eine abgebende LEI ruft ein E-Rezept auf Basis eines E-Rezept-Tokens aus dem TI-Flow-Fachdienst ab.
Vorbedingungen | Ein E-Rezept-Token wurde übermittelt. UC 4.6 wurde ausgeführt. Token liegt im Primärsystem vor; Status des E-Rezepts ist "ready".
Durchzuführende Aktionen | Primärsystem ermittelt Rezept-ID und AccessCode aus dem Token. Primärsystem ruft das E-Rezept beim TI-Flow-Fachdienst ab. Status wechselt auf "in-progress". TI-Flow-Fachdienst erzeugt ein Geheimnis zur Statusänderung und übermittelt es. optional: Primärsystem prüft die QES über den Konnektor.
Nachbedingungen | Status ist "in-progress" und protokolliert. E-Rezept liegt im AVS vor; Geheimnis ist gespeichert.
Schnittstellen | Operation API: Task akzeptieren
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.1 - E-Rezept durch Abgebenden abrufen

Sequenzdiagramm:

Abbildung: UC 4.1 - E-Rezept durch Abgebenden abrufen

Technische Aspekte für die Mehrfachverordnung (MVO)

Wenn ein AVS eine Teilverordnung abruft, deren Einlösezeitraum noch nicht erreicht ist, dann liefert der TI-Flow-Fachdienst einen Fehler 403. Im OperationOutcome der Fehlermeldung liefert der TI-Flow-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.

##### UC 4.2 - E-Rezept durch Abgebenden zurückgeben

Beschreibung | Ein abgerufenes E-Rezept wird an den TI-Flow-Fachdienst zurückgegeben.
Vorbedingungen | UC 4.1 wurde ausgeführt. Rezept-ID, AccessCode und Geheimnis sind bekannt. Status ist "in-progress".
Durchzuführende Aktionen | Abgebender markiert das E-Rezept zum Zurückgeben und bestätigt. Primärsystem ruft den TI-Flow-Fachdienst mit Rezept-ID und Geheimnis auf. Status wird auf "ready" geändert.
Nachbedingungen | Status ist "ready" und protokolliert. E-Rezept, Token und Geheimnis sind im Primärsystem gelöscht.
Schnittstellen | Operation API: Task zurückweisen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.2 - E-Rezept durch Abgebenden zurückgeben

Sequenzdiagramm:

Abbildung: UC 4.2 - E-Rezept durch Abgebenden zurückgeben

##### UC 4.3 - E-Rezept durch Abgebenden löschen

Beschreibung | Der abgebende Leistungserbringer löscht ein zuvor abgerufenes E-Rezept.
Vorbedingungen | Ein E-Rezept-Token wurde übermittelt und der Wunsch zum Löschen liegt vor. UC 4.6 und UC 4.1 wurden ausgeführt. Rezept-ID, AccessCode und Geheimnis sind bekannt; Status ist "in-progress".
Durchzuführende Aktionen | Abgebender markiert das E-Rezept zum Löschen und bestätigt. Primärsystem ruft den TI-Flow-Fachdienst mit Rezept-ID und Geheimnis auf. Status wechselt auf "cancelled"; Daten werden entfernt.
Nachbedingungen | Status ist "cancelled" und protokolliert; Daten sind entfernt. E-Rezept, Token und Geheimnis sind im Primärsystem gelöscht.
Schnittstellen | Operation API: E-Rezept löschen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.3 - E-Rezept durch Abgebenden löschen

Sequenzdiagramm:

Abbildung: UC 4.3 - E-Rezept durch Abgebenden löschen

##### UC 4.16 - Dispensierinformationen bereitstellen

Beschreibung | Ein Mitarbeiter der abgebenden LEI hat ein E-Rezept dispensiert. Er markiert das E-Rezept über das Primärsystem als abgegeben und bestätigt es. Das Primärsystem übermittelt beim Aufruf des TI-Flow-Fachdienstes die Rezept-ID und das Geheimnis zur Bereitstellung der Dispensierinformationen. Im Aufruf ist die Dispensierinformation enthalten.
Vorbedingungen | Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" durchgeführt.- Das Primärsystem hat die QES des E-Rezepts erfolgreich geprüft. Die QES des E-Rezepts ist gültig. Die Rezept-ID, der AccessCode und das Geheimnis zur Statusänderung "in-progress" des E-Rezepts sind im Primärsystem bekannt. Das E-Rezept im TI-Flow-Fachdienst hat den Status "in-progress".
Durchzuführende Aktionen | Abgebender wählt ein beliefertes E-Rezept zur Bereitstellung von Dispensierinformationen aus. Das Primärsystem übermittelt die Dispensierinformationen an den TI-Flow-Fachdienst.
Nachbedingungen | Das E-Rezept im TI-Flow-Fachdienst hat den Status "in-progress". Die Information zur Abgabe liegen im TI-Flow-Fachdienst. Das Bereitstellen der Dispensierinformationen ist im TI-Flow-Fachdienst protokolliert. Das Primärsystem erhält eine Bestätigung, dass die Dispensierinformationen bereitgestellt wurden.
Schnittstellen | Operation API: Dispensierinformationen bereitstellen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.16 - Dispensierinformationen bereitstellen

Sequenzdiagramm:

Abbildung: UC 4.16 - Dispensierinformationen bereitstellen

##### UC 4.4 - Quittung abrufen

Beschreibung | Nach der Abgabe wird das E-Rezept quittiert und eine Quittung vom TI-Flow-Fachdienst abgerufen.
Vorbedingungen | UC 4.1 wurde ausgeführt. QES des E-Rezepts ist gültig geprüft. Rezept-ID, AccessCode und Geheimnis sind bekannt; Status ist "in-progress".
Durchzuführende Aktionen | Abgebender markiert das E-Rezept als abgegeben. Primärsystem übermittelt Rezept-ID, Geheimnis und Abgabeinformationen an den TI-Flow-Fachdienst. Status wechselt zu "completed"; Quittung wird erstellt und zurückgegeben.
Nachbedingungen | Status ist "completed"; Abgabeinformationen sind gespeichert. Statuswechsel ist protokolliert; Quittung liegt im Primärsystem vor.
Schnittstellen | Operation API: Task schliessen
Folgeaktionen des E-Rezept-Fachdienst | Abgabedatensatz signieren
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.4 - Quittung abrufen

Sequenzdiagramm:

Abbildung: UC 4.4 - Quittung abrufen

##### UC 4.5 - Abgabedatensatz durch Abgebenden signieren

Beschreibung | Der Abgebende signiert den Abgabedatensatz fortgeschritten oder qualifiziert (QES).
Vorbedingungen | E-Rezept wurde dispensiert. Abgabedatensatz liegt im Primärsystem bereit. HBA oder SMC-B ist gesteckt und freigeschaltet.
Durchzuführende Aktionen | Bei Abgabe ohne Änderung: fortgeschrittene Signatur. Bei Abgabe mit Änderung: QES für den Dispensierdatensatz.
Nachbedingungen | Abgabedatensatz ist durch den Abgebenden signiert.
Schnittstellen | Keine (Signatur im Primärsystem)
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.5 - Abgabedatensatz durch Abgebenden signieren

Sequenzdiagramm:

Abbildung: UC 4.5 - Abgabedatensatz durch Abgebenden signieren

##### UC 4.17 - Verordnung erneut abrufen

Beschreibung | Die Verordnung wird erneut abgerufen, falls die Übertragung beim ersten Abruf mit $accept fehlgeschlagen ist.
Vorbedingungen | UC 4.1 wurde ausgeführt; im Clientsystem liegt keine Verordnung oder das zugehörige Secret vor. Status des E-Rezepts ist "in-progress".
Durchzuführende Aktionen | Abgebender wählt die Zugriffsinformation für die Verordnung (E-Rezept-Token) aus und ruft die Verordnung erneut ab. Primärsystem übermittelt Rezept-ID und Access_Code; der TI-Flow-Fachdienst liefert die Verordnung und das Secret erneut aus.
Nachbedingungen | Verordnung liegt im Primärsystem vor.
Schnittstellen | Query API: Task
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.17 - Verordnung erneut abrufen

Sequenzdiagramm:

Abbildung: UC 4.17 - Verordnung erneut abrufen

##### UC 4.8 - Quittung erneut abrufen

Beschreibung | Die Quittung wird erneut abgerufen, falls die Übertragung beim ersten Abruf fehlgeschlagen ist.
Vorbedingungen | UC 4.4 wurde ausgeführt; im Primärsystem liegt keine Quittung vor. Status des E-Rezepts ist "completed".
Durchzuführende Aktionen | Abgebender wählt das E-Rezept und ruft die Quittung erneut ab. Primärsystem übermittelt Rezept-ID und Geheimnis; der TI-Flow-Fachdienst liefert die Quittung erneut aus.
Nachbedingungen | Quittung liegt im Primärsystem vor.
Schnittstellen | Query API: Task
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.8 - Quittung erneut abrufen

Sequenzdiagramm:

Abbildung: UC 4.8 - Quittung erneut abrufen

##### UC 4.7 - Nachricht durch Abgebenden übermitteln

Beschreibung | Die abgebende LEI antwortet auf eine Nachricht eines Versicherten.
Vorbedingungen | UC 3.3 wurde ausgeführt. UC 4.6 wurde ausgeführt.
Durchzuführende Aktionen | Ein Mitarbeiter wählt die Nachricht zu einer Verordnung und erstellt eine Antwort. Das Primärsystem stellt die Antwortnachricht im E-Rezept-Fachdienst ein.
Nachbedingungen | Nachricht liegt im TI-Flow-Fachdienst und kann asynchron empfangen werden.
Schnittstellen | Query API: Nachricht einstellen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.7 - Nachricht durch Abgebenden übermitteln

Sequenzdiagramm:

Abbildung: UC 4.7 - Nachricht durch Abgebenden übermitteln

##### UC 4.9 - Nachricht durch Abgebenden löschen

Beschreibung | Der Abgebende löscht von ihm übermittelte Nachrichten an Versicherte.
Vorbedingungen | UC 4.7 wurde ausgeführt.
Durchzuführende Aktionen | Der Abgebende wählt Nachrichten zum Löschen aus und bestätigt. Das Primärsystem überträgt Löschanforderungen an den TI-Flow-Fachdienst. Der TI-Flow-Fachdienst löscht Nachrichten und liefert ggf. Warnung bei bereits erfolgtem Abruf. Nachrichten werden im Primärsystem gelöscht.
Nachbedingungen | Nachrichten sind im TI-Flow-Fachdienst und im Primärsystem gelöscht.
Schnittstellen | Query API: Nachricht löschen
Relevante(r) Sektor(en) |

Tabelle: Fachlicher Anwendungsfall UC 4.9 - Nachricht durch Abgebenden löschen

Sequenzdiagramm:

Abbildung: UC 4.9 - Nachricht durch Abgebenden löschen