Technische Anwendungsfälle

Seiteninhalt:

Umzusetzende Anwendungsfälle von Clients
Technische Use Cases

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

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

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

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

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

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