Implementation Guide
TIFlow - Kernfunktionalitäten
Version 2.0.0 - release

Technische Umsetzung - Push Notification

Die Rolle "Fachdienst", die in [gemF_PushNotification] beschrieben wird, wird durch ZETA Guard übernommen. Der TI-Flow-Fachdienst verwendet die Schnittstelle von ZETA Guard als "Resource Server", wie in [OpenAPI_NotificationService] beschrieben, um den Nachrichteninhalt an die FdVs zu senden. ZETA Guard prüft, ob für den Versicherten aktive Pusher Registrierungen vorhanden sind, und führt den Prozess nur dann weiter aus, wenn eine Registrierung existiert und der entsprechende Channel aktiv ist.

Darüber hinaus stellt ZETA Guard einen weiteren Endpunkt zur Verfügung, über den der TI-Flow-Fachdienst prüfen kann, welche Channels für den Versicherten aktiv sind und ob eine Registrierung vorhanden ist. Dieser Endpunkt kann zur Optimierung des Prozesses verwendet werden.

Implementierung für die FdVs

Die Funktionalität zu Push Notification für FdVs ist anwendungsübergreifend in [gemF_PushNotification] beschrieben.

funkt. Eignung: Test Produkt/FA Das TI-Flow-FdV MUSS, wenn es den Anwendungsfall "Push Notifications" umsetzt, für die Registrierung und Verwaltung der FdV-Instanzen sowie der Channels die Funktionalität des ZETA Clients verwenden.

Push Notification senden

Der TI-Flow-Fachdienst erstellt ein NotificationRequest-Objekt wie in [OpenAPI_NotificationService] beschrieben. Der Nachrichteninhalt, auf den in diesem Kapitel verwiesen wird, ist der Inhalt des Payloads. Der Nachrichteninhalt wird in den modulspezifischen IGs beschrieben und festgelegt.

Die Übermittlung von Notification-Objekten an den Notification Service wird über einen asynchronen Prozess realisiert. Dies hat die Konsequenz, dass es bei der Übermittlung der Daten an den Notification Service zu Verzögerungen kommen kann. Dadurch kann sich auch die Zustellung und somit der Empfang der Push Notifications beim Versicherten verzögern.

funkt. Eignung: Herstellererklärung Der TI-Flow-Fachdienst MUSS beim Auftreten eines Triggers für Push Notifications den Nachrichteninhalt erstellen und den Notification Service unter Verwendung der [OpenAPI_NotificationService] aufrufen. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS beim Erstellen einer Push Notifcation das Reference-Feld des äußeren NotificationRequest-Objekts (notificationRequest.reference) in Abhängigkeit von der ChannelId wie folgt befüllen:
ChannelId Identifier.Feld
tiflow.communication.new Identifier des zugehörigen Communication (Communication.id)
ungleich tiflow.communication.new Identifier des zugehörigen Protokolleintrags (AuditEvent.id)

Push Notification Datenstruktur

funkt. Eignung: Herstellererklärung funkt. Eignung: Herstellererklärung Der TI-Flow-Fachdienst und das TI-Flow-FdV MÜSSEN für den Anwendungsfall "Push Notifications" Nachrichteninhalte mit der folgenden Datenstruktur im JSON Format unterstützen:
Attribut verpflichtend Beschreibung zulässige Werte Beispiel
ChannelId ja Der Trigger, der die Push Notification initiiert hat. bis zu 30 Stellen, UTF-8 tiflow.communication.new
Identifier ja Ein Identifier, der als Kontext zur Nachricht dient. bis zu 50 Stellen, UTF-8 160.000.000.000.123.76
IdentifierType ja Der Art Identifier, der mitgeschickt wird. bis zu 20 Stellen, UTF-8 TaskId
Product ja Der Name des verordneten bzw. abgegebenen Produkts (Medikament oder DiGA). bis zu 100 Stellen, UTF-8 Sumatriptan-1a Pharma 100 mg Tabletten
ActorName ja Der Name des Akteurs. Das kann zum Beispiel der Name der Apotheke oder des Kostenträgers sein. bis zu 100 Stellen, UTF-8 Meine Apotheke
Message nein Die Nachricht, die an den Versicherten verschickt wird.
Nachrichten mit mehr als 240 Zeichen müssen nach 237 Zeichen abgeschnitten und mit drei Punkten (...) ergänzt werden.
bis zu 240 Stellen, UTF-8 Wir möchten Sie informieren, dass Ihre bestellten Medikamente zur Abholung bereitstehen.
Tabelle: TAB_eRp_DM_004 Push Notification Datenstruktur Nachrichteninhalte