Implementation Guide
TIFlow - Verordnungen für Digitale Gesundheitsanwendungen (DiGA)
Version 2.0.0 - release

Technische Anwendungsfälle

Seiteninhalt:

Ablaufdiagramm Verordnung von DiGAs

Ablaufdiagramm Verordnung von DiGAAblaufdiagramm Verordnung von DiGAPVSTI-Flow-FdVTI-Flow-FachdienstFHIR VerzeichnisdienstKostenträgerPVSTI-Flow-FdVTI-Flow-FachdienstFHIR VerzeichnisdienstKostenträger[1]Workflow erstellenmit $Create (Workflow 162)[2]Verordnungsdatensatzerstellen[3]Verordnungsdatensatzmit QES signieren[4]Einstellen derVerordnung mit $activate[5]QES und FHIR prüfen[6]Abruf der Verordnungenmit GET /Task[7]Falls nicht bekannt: Zieladresse für Zuweisung durch Lookup derTelematik-ID des Kostenträgers ermitteln(auf Basis Authentisierungsinformationen des Nutzers)[8]Communication Ressourcefür Zuweisen erstellen[9]POST /Communication[10]WebSocket-Signal neue Communicationmit "Zuweisung DiGA-Verordnung"[11]GET /Communication[12]Abruf der Verordnung mit $accept(Task-ID und AccessCodeaus Communication)alt[Erfolgreiche Bearbeitung des E-Rezepts][13]Freischaltcode erzeugen[14]$close (Freischaltcodein Dispensierinformation enthalten)[15]Abruf Dispensierinformation[16]Verwendung Freischaltcodemit DiGA[17]die weitere Verarbeitunginklusiver Abrechnungerfolgt in Kassenhoheitmit den DiGA-Anbietern[E-Rezept wird zurückgegeben][18]Prüfung ergibt Rückgabe des E-Rezeptes[19]$reject (Rückgabe der Verordnungan den TI-Flow-Fachdienst)[20]POST /Communication mitRü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

funkt. Eignung: Herstellererklärung 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.

TI-Flow-FdV

funkt. Eignung: Herstellererklärung Das TI-Flow-FdV MUSS, wenn es das Einlösen von Verordnungen für DiGAs unterstützt, 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.13 - Einwilligung einsehen
  • UC 3.14 - Einwilligung erteilen
  • UC 3.15 - Einwilligung widerrufen
  • UC 3.5 - Protokolldaten abrufen
umsetzen. funkt. Eignung: Herstellererklärung Das TI-Flow-FdV SOLL, wenn es das Einlösen von Verordnungen für DiGAs unterstützt, den Anwendungsfall
  • Kostenträger suchen
umsetzen.

Clientsystem Kostenträger

funkt. Eignung: Herstellererklärung 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 erzeugenUC 2.1 - Verordnung erzeugenPrimärsystemTI-Flow-Fachdienst(Zahn-)ArztPrimärsystemTI-Flow-FachdienstKonnektor(Zahn-)Arzt(Zahn-)ArztPrimärsystemPrimärsystemTI-Flow-FachdienstTI-Flow-FachdienstKonnektorKonnektorPrimärsystemTI-Flow-FachdienstVerordnungsdatensaetze auswählen()POST /Task/$create (FlowType)Task erzeugen()Rezept-ID erzeugen()AccessCode erzeugen()Task, Rezept-ID, AccessCodeAccessCode speichern()Rezept-ID in Verordnungsdatensatz ergänzen()refVerordnungdatensatz qualifiziert signierenSignierte 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 signierenVerordnungsdatensatz qualifiziert signierenPrimärsystemKonnektorVerordnenderPrimärsystemKonnektorVerordnenderVerordnenderPrimärsystemPrimärsystemKonnektorKonnektorPrimärsystemKonnektorQES auslösen()sign_Document_QES(Verordnungsdatensatz)QES-SignaturSignierten 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 einstellenUC 2.3 - Verordnung einstellenPrimärsystemTI-Flow-Fachdienst(Zahn-)Arzt / PsychotherapeutenPrimärsystemTI-Flow-Fachdienst(Zahn-)Arzt / Psychotherapeuten(Zahn-)Arzt / PsychotherapeutenPrimärsystemPrimärsystemTI-Flow-FachdienstTI-Flow-FachdienstPrimärsystemTI-Flow-FachdienstVerordnung 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 aktualisiertE-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öschenUC 2.5 - Verordnung durch Verordnenden löschenPrimärsystemTI-Flow-FachdienstMitarbeiter LEIPrimärsystemTI-Flow-FachdienstMitarbeiter LEIMitarbeiter LEIPrimärsystemPrimärsystemTI-Flow-FachdienstTI-Flow-FachdienstPrimärsystemTI-Flow-FachdienstVerordnung zum Löschen markieren()POST /Task/{id}/$abort (AccessCode)AccessCode prüfen()Status auf "cancelled" setzen()Personenbezogene Daten löschen()StatusAccessCode 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
  • 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
Relevante(r) Sektor(en) VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.1 - E-Rezepte durch Versicherten abrufen

Sequenzdiagramm:

UC 3.1 - Verordnungen durch Versicherten abrufenUC 3.1 - Verordnungen durch Versicherten abrufenFdVTI-Flow-FachdienstVersicherterFdVTI-Flow-FachdienstVersicherterVersicherterFdVFdVTI-Flow-FachdienstTI-Flow-FachdienstFdVTI-Flow-FachdienstVerordnungen abrufen()GET /Task ()Verordnungen nach Versicherten-ID ermitteln()Verordnungen, Status, Zeitpunkte, AccessCodesListe 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öschenUC 3.2 - Verordnung durch Versicherten löschenFdVTI-Flow-FachdienstVersicherterFdVTI-Flow-FachdienstVersicherterVersicherterFdVFdVTI-Flow-FachdienstTI-Flow-FachdienstFdVTI-Flow-FachdienstE-Rezept löschen()POST /Task/{id}/$abort ()Status auf "cancelled" setzen()Daten löschen()StatusToken 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 übermittelnUC 3.3 - Nachricht durch Versicherten übermittelnFdVTI-Flow-FachdienstVersicherterFdVVerzeichnisdienstTI-Flow-FachdienstVersicherterVersicherterFdVFdVVerzeichnisdienstVerzeichnisdienstTI-Flow-FachdienstTI-Flow-FachdienstFdVTI-Flow-FachdienstNachricht mit Token senden()alt[Versand über TI]Kostenträger suchen()EmpfängerdatenPOST /Communication (Token, Text)Nachricht speichern()Status[2D-Code]Token als 2D-Code erzeugen()2D-Code anzeigen/ausdruckenBestä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 TI-Flow-FdV kann die Auswahl automatisiert erfolgen.

Ermitteln der Telematik-ID des Kostenträgers

Damit das TI-Flow-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 TI-Flow-FdV benötigt das Haupt-Institutionskennzeichen (IK) des Kostenträgers. Dieses IK ist in den Authentisierungsinformationen des Versicherten enthalten.

Sobald dem TI-Flow-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 TI-Flow-FdVs der Krankenkassen nicht relevant, da diese die korrekte Telematik-ID in ihren Apps vorab festlegen können.

Fallback bei Fehlern und fehlenden Informationen

Falls es dem TI-Flow-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 TI-Flow-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 TI-Flow-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 empfangenUC 3.4 - Nachrichten durch Versicherten empfangenFdVTI-Flow-FachdienstVersicherterFdVTI-Flow-FachdienstVersicherterVersicherterFdVFdVTI-Flow-FachdienstTI-Flow-FachdienstFdVTI-Flow-FachdienstNachrichten abrufen()GET /Communication?recipient=... ()Nachrichten ermitteln()NachrichtenNachrichten 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
  • 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
Relevante(r) Sektor(en) VERSICHERTER
Tabelle: Fachlicher Anwendungsfall UC 3.8 - Nachricht durch Versicherten löschen

Sequenzdiagramm:

UC 3.8 - Nachricht durch Versicherten loeschenUC 3.8 - Nachricht durch Versicherten loeschenFdVTI-Flow-FachdienstVersicherterFdVTI-Flow-FachdienstVersicherterVersicherterFdVFdVTI-Flow-FachdienstTI-Flow-FachdienstFdVTI-Flow-FachdienstNachricht löschen()DELETE /Communication/{id} ()Nachricht löschen()StatusNachricht 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 abrufenUC 4.1 - Verordnung durch Abgebenden abrufenClientsystemTI-Flow-FachdienstKonnektorMitarbeiter KTRClientsystemTI-Flow-FachdienstKonnektorMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstKonnektorKonnektorClientsystemTI-Flow-FachdienstKonnektorVerordnung 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, GeheimnisoptQES prüfen(Binary)ErgebnisStatus 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ückgebenUC 4.2 - Verordnung durch Abgebenden zurückgebenClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstVerordnung zurückgeben()POST /Task/{id}/$reject (Secret)Secret prüfen()Status Task prüfen()Status auf "ready" setzen()StatusToken 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 abrufenUC 4.4 - Quittung abrufenClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstAbgabe bestätigen()POST /Task/{id}/$close (Secret, MedicationDispense)Secret prüfen()Status Task prüfen()Status auf "completed" setzen()Quittung erstellen und signieren()Quittung, StatusQuittung
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 abrufenUC 4.17 - Verordnung erneut abrufenClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstVerordnung erneut abrufen()GET /Task/{id} (AccessCode)AccessCode prüfen()Telematik-ID prüfen()Status Task prüfen()Verordnung und SecretVerordnung
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 abrufenUC 4.8 - Quittung erneut abrufenClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstQuittung erneut abrufen()GET /Task/{id} (Secret)Secret prüfen()Telematik-ID prüfen()Status Task prüfen()Quittung erneut bereitstellen()QuittungQuittung
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 empfangenUC 4.6 - Nachrichten durch Abgebenden empfangenAVSTI-Flow-FachdienstMitarbeiter ApothekeAVSTI-Flow-FachdienstMitarbeiter ApothekeMitarbeiter ApothekeAVSAVSTI-Flow-FachdienstTI-Flow-FachdienstAVSTI-Flow-FachdienstE-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 uebermittelnUC 4.7 - Nachricht durch Abgebenden uebermittelnClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstAntwortnachricht erstellen()POST /Communication (Antwort)Nachricht speichern()StatusBestaetigung
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
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öschenUC 4.9 - Nachricht durch Abgebenden löschenClientsystemTI-Flow-FachdienstMitarbeiter KTRClientsystemTI-Flow-FachdienstMitarbeiter KTRMitarbeiter KTRClientsystemKostenträgerClientsystemKostenträgerTI-Flow-FachdienstTI-Flow-FachdienstClientsystemTI-Flow-FachdienstNachricht löschen()DELETE /Communication/{id} ()Nachricht löschen()StatusNachricht lokal löschen()Status
Abbildung: UC 4.9 - Nachricht durch Abgebenden löschen