Technische Anwendungsfälle
Ablaufdiagramm Verordnung von DiGAs
Ablaufdiagramm Verordnung von DiGA PVS E-Rezept-FdV TI-Flow-Fachdienst FHIR Verzeichnisdienst Kostenträger [1] Workflow erstellen mit $Create (Workflow 162) [2] Verordnungsdatensatz erstellen [3] Verordnungsdatensatz mit QES signieren [4] Einstellen der Verordnung mit $activate [5] QES und FHIR prüfen [6] Abruf der Verordnungen mit GET /Task [7] Falls nicht bekannt: Zieladresse für Zuweisung durch Lookup der Telematik-ID des Kostenträgers ermitteln (auf Basis Authentisierungsinformationen des Nutzers) [8] Communication Ressource für Zuweisen erstellen [9] POST /Communication [10] WebSocket-Signal neue Communication mit "Zuweisung DiGA-Verordnung" [11] GET /Communication [12] Abruf der Verordnung mit $accept (Task-ID und AccessCode aus Communication) alt [Erfolgreiche Bearbeitung des E-Rezepts] [13] Freischaltcode erzeugen [14] $close (Freischaltcode in Dispensierinformation enthalten) [15] Abruf Dispensierinformation [16] Verwendung Freischaltcode mit DiGA [17] die weitere Verarbeitung inklusiver Abrechnung erfolgt in Kassenhoheit mit den DiGA-Anbietern [E-Rezept wird zurückgegeben] [18] Prüfung ergibt Rückgabe des E-Rezeptes [19] $reject (Rückgabe der Verordnung an den TI-Flow-Fachdienst) [20] POST /Communication mit Rückgabegrund als Freitext [21] Darstellung des Rückgabegrundes an den Versicherten
Abbildung: Ablaufdiagramm DiGA-Verordnung
Umzusetzende Anwendungsfälle von Clients
Die folgenden Abschnitte beschreiben die technischen Anwendungsfälle, die für das Modul der Verordnung von digitalen Gesundheitsanwendungen genutzt werden.
PS verordnende LEI
Das PS der verordnenden LEI MUSS für die Umsetzung der Verordnung von DiGAs 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 Verordnungen von DiGAs die Anwendungsfälle
UC 3.1 - E-Rezepte durch Versicherten abrufen
UC 3.2 - E-Rezept durch Versicherten löschen
Kostenträger suchen
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.
Clientsystem Kostenträger
Das Clientsystem des Kostenträgers MUSS für die Umsetzung der Verordnung von DiGAs die Anwendungsfälle
UC 4.1 - E-Rezept durch Abgebenden abrufen
UC 4.2 - E-Rezept durch Abgebenden zurückgeben
UC 4.4 - Quittung abrufen
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.
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
Relevante(r) Sektor(en)
(ZAHN-)ARZT
PSYCHOTHERAPEUT
Tabelle: Fachlicher Anwendungsfall UC 2.1 - E-Rezepte erzeugen
Sequenzdiagramm:
UC 2.1 - Verordnung erzeugen (Zahn-)Arzt (Zahn-)Arzt Primärsystem Primärsystem TI-Flow-Fachdienst TI-Flow-Fachdienst Konnektor Konnektor Verordnungsdatensaetze auswählen() POST /Task/$create (FlowType) Task erzeugen() Rezept-ID erzeugen() AccessCode erzeugen() Task, Rezept-ID, AccessCode AccessCode speichern() Rezept-ID in Verordnungsdatensatz ergänzen() ref Verordnungdatensatz qualifiziert signieren Signierte Verordnung
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
PSYCHOTHERAPEUT
Tabelle: Fachlicher Anwendungsfall E-Rezept qualifiziert signieren
Sequenzdiagramm:
Verordnungsdatensatz qualifiziert signieren Verordnender Verordnender Primärsystem Primärsystem Konnektor Konnektor QES auslösen() sign_Document_QES(Verordnungsdatensatz) QES-Signatur Signierten Verordnungsdatensatz speichern() QES abgeschlossen
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
Relevante(r) Sektor(en)
(ZAHN-)ARZT
PSYCHOTHERAPEUT
Tabelle: Fachlicher Anwendungsfall UC 2.3 - E-Rezept einstellen
Sequenzdiagramm:
UC 2.3 - Verordnung einstellen (Zahn-)Arzt / Psychotherapeuten (Zahn-)Arzt / Psychotherapeuten Primärsystem Primärsystem TI-Flow-Fachdienst TI-Flow-Fachdienst Verordnung zum Einstellen auswählen() POST /Task/{id}/$activate (AccessCode, QES-Bundle) AccessCode prüfen() Status Task prüfen() Signatur und Daten prüfen() Status auf "ready" setzen() Status, Verordnung aktualisiert E-Rezept-Token erstellen() Verordnung eingestellt
Abbildung: UC 2.3 - E-Rezept einstellen
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
Relevante(r) Sektor(en)
(ZAHN-)ARZT
PSYCHOTHERAPEUT
Tabelle: Fachlicher Anwendungsfall UC 2.5 - E-Rezept durch Verordnenden löschen
Sequenzdiagramm:
UC 2.5 - Verordnung durch Verordnenden löschen Mitarbeiter LEI Mitarbeiter LEI Primärsystem Primärsystem TI-Flow-Fachdienst TI-Flow-Fachdienst Verordnung zum Löschen markieren() POST /Task/{id}/$abort (AccessCode) AccessCode prüfen() Status auf "cancelled" setzen() Personenbezogene Daten löschen() Status AccessCode löschen() Status
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
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
Relevante(r) Sektor(en)
VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.1 - E-Rezepte durch Versicherten abrufen
Sequenzdiagramm:
UC 3.1 - Verordnungen durch Versicherten abrufen Versicherter Versicherter FdV FdV TI-Flow-Fachdienst TI-Flow-Fachdienst Verordnungen abrufen() GET /Task () Verordnungen nach Versicherten-ID ermitteln() Verordnungen, Status, Zeitpunkte, AccessCodes Liste der Verordnungen
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
Relevante(r) Sektor(en)
VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.2 - E-Rezept durch Versicherten löschen
Sequenzdiagramm:
UC 3.2 - Verordnung durch Versicherten löschen Versicherter Versicherter FdV FdV TI-Flow-Fachdienst TI-Flow-Fachdienst E-Rezept löschen() POST /Task/{id}/$abort () Status auf "cancelled" setzen() Daten löschen() Status Token löschen() Status
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
Relevante(r) Sektor(en)
VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.3 - Nachricht durch Versicherten übermitteln
Sequenzdiagramm:
UC 3.3 - Nachricht durch Versicherten übermitteln Versicherter Versicherter FdV FdV Verzeichnisdienst Verzeichnisdienst TI-Flow-Fachdienst TI-Flow-Fachdienst Nachricht mit Token senden() alt [Versand über TI] Kostenträger suchen() Empfängerdaten POST /Communication (Token, Text) Nachricht speichern() Status [2D-Code] Token als 2D-Code erzeugen() 2D-Code anzeigen/ausdrucken Bestätigung
Abbildung: UC 3.3 - Nachricht durch Versicherten übermitteln
Für das Übermitteln der Verordnung wird als Adressat der Kostenträger ausgewählt. Bei
der Umsetzung im E-Rezept-FdV kann die Auswahl automatisiert erfolgen.
Ermitteln der Telematik-ID des Kostenträgers
Damit das E-Rezept-FdV der gematik “UC 3.3 - Nachricht durch Versicherten übermitteln” ausführen kann, muss es zunächst die Telematik-ID des Kostenträgers als Empfängeradresse der Nachricht ermitteln.
Das E-Rezept-FdV benötigt das Haupt-Institutionskennzeichen (IK) des Kostenträgers. Dieses IK ist in den Authentisierungsinformationen des Versicherten enthalten.
Sobald dem E-Rezept-FdV das IK vorliegt, sucht es im FHIR-VZD nach der Telematik-ID des Kostenträgers mithilfe des IK.
Dieser Fall ist für die E-Rezept-FdVs der Krankenkassen nicht relevant, da diese die korrekte Telematik-ID in ihren Apps vorab festlegen können.
Falls es dem E-Rezept-FdV nicht möglich ist, das IK oder die Telematik-ID des Kostenträgers zu bestimmen, soll der Versicherte dennoch die Möglichkeit haben, seine DiGA Verordnung zuzuweisen.
Hierzu zeigt das E-Rezept-FdV dem Versicherten alle Kostenträgereinträge des FHIR-VZD mit oid_kostentraeger, die eine IKNR und Telematik-ID haben. Der Versicherte wählt die Krankenkasse aus, bei der er versichert ist und kann so die Einlösung vornehmen.
Zuweisen der Verordnung durch den Versicherten
Sobald die Telematik-ID im E-Rezept-FdV vorliegt, kann der Versicherte die Verordnung seinem Kostenträger zuweisen. Hierzu wird eine Communication (GEM_ERP_PR_Communication_DispReq) erstellt und der E-Rezept-Token eingebettet.
Beim Zuweisen im Rahmen einer DiGA-Verordnung wird kein Payload mit Zusatzinformationen wie bspw. Kontaktdaten und Belieferungsoptionen übertragen.
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
Relevante(r) Sektor(en)
VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.4 - Nachrichten durch Versicherten empfangen
Sequenzdiagramm:
UC 3.4 - Nachrichten durch Versicherten empfangen Versicherter Versicherter FdV FdV TI-Flow-Fachdienst TI-Flow-Fachdienst Nachrichten abrufen() GET /Communication?recipient=... () Nachrichten ermitteln() Nachrichten Nachrichten anzeigen
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
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
Relevante(r) Sektor(en)
VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.8 - Nachricht durch Versicherten löschen
Sequenzdiagramm:
UC 3.8 - Nachricht durch Versicherten loeschen Versicherter Versicherter FdV FdV TI-Flow-Fachdienst TI-Flow-Fachdienst Nachricht löschen() DELETE /Communication/{id} () Nachricht löschen() Status Nachricht lokal löschen() Status
Abbildung: UC 3.8 - Nachricht durch Versicherten löschen
Kostenträger
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.1 - E-Rezept durch Abgebenden abrufen
Sequenzdiagramm:
UC 4.1 - Verordnung durch Abgebenden abrufen Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Konnektor Konnektor Verordnung abrufen() Verordnungs-ID und AccessCode aus Token ermitteln() POST /Task/{id}/$accept (AccessCode) AccessCode prüfen() Status Task prüfen() Status auf "in-progress" setzen() Geheimnis erzeugen() Task, Binary, Geheimnis opt QES prüfen(Binary) Ergebnis Status und Verordnungsdaten
Abbildung: UC 4.1 - E-Rezept durch Abgebenden abrufen
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.2 - E-Rezept durch Abgebenden zurückgeben
Sequenzdiagramm:
UC 4.2 - Verordnung durch Abgebenden zurückgeben Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Verordnung zurückgeben() POST /Task/{id}/$reject (Secret) Secret prüfen() Status Task prüfen() Status auf "ready" setzen() Status Token und Secret löschen() Status
Abbildung: UC 4.2 - E-Rezept durch Abgebenden zurückgeben
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.4 - Quittung abrufen
Sequenzdiagramm:
UC 4.4 - Quittung abrufen Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Abgabe bestätigen() POST /Task/{id}/$close (Secret, MedicationDispense) Secret prüfen() Status Task prüfen() Status auf "completed" setzen() Quittung erstellen und signieren() Quittung, Status Quittung
Abbildung: UC 4.4 - Quittung abrufen
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.17 - Verordnung erneut abrufen
Sequenzdiagramm:
UC 4.17 - Verordnung erneut abrufen Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Verordnung erneut abrufen() GET /Task/{id} (AccessCode) AccessCode prüfen() Telematik-ID prüfen() Status Task prüfen() Verordnung und Secret Verordnung
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.8 - Quittung erneut abrufen
Sequenzdiagramm:
UC 4.8 - Quittung erneut abrufen Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Quittung erneut abrufen() GET /Task/{id} (Secret) Secret prüfen() Telematik-ID prüfen() Status Task prüfen() Quittung erneut bereitstellen() Quittung Quittung
Abbildung: UC 4.8 - Quittung erneut abrufen
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.6 - Nachrichten durch Abgebenden empfangen
Sequenzdiagramm:
UC 4.6 - Nachrichten durch Abgebenden empfangen Mitarbeiter Apotheke Mitarbeiter Apotheke AVS AVS TI-Flow-Fachdienst TI-Flow-Fachdienst E-Rezept-Token empfangen() alt [Empfang über TI] GET /Communication () Nachrichten ermitteln() E-Rezept-Token [2D-Code] 2D-Code scannen() Token extrahieren() Token verfügbar
Abbildung: UC 4.6 - Nachrichten durch Abgebenden empfangen
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.7 - Nachricht durch Abgebenden übermitteln
Sequenzdiagramm:
UC 4.7 - Nachricht durch Abgebenden uebermitteln Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Antwortnachricht erstellen() POST /Communication (Antwort) Nachricht speichern() Status Bestaetigung
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
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
Relevante(r) Sektor(en)
KOSTENTRÄGER
Tabelle: Fachlicher Anwendungsfall UC 4.9 - Nachricht durch Abgebenden löschen
Sequenzdiagramm:
UC 4.9 - Nachricht durch Abgebenden löschen Mitarbeiter KTR Mitarbeiter KTR Clientsystem Kostenträger Clientsystem Kostenträger TI-Flow-Fachdienst TI-Flow-Fachdienst Nachricht löschen() DELETE /Communication/{id} () Nachricht löschen() Status Nachricht lokal löschen() Status
Abbildung: UC 4.9 - Nachricht durch Abgebenden löschen
