Trigger-Verwaltung (Channels) 
Beschreibung
Der Nutzer des FdVs kann konfigurieren, welche Push Notifications er auf diesem Gerät erhalten möchte. Diese Konfiguration wird mit Hilfe von sogenannten Channels vorgenommen. Jeder Trigger im Fachdienst ist einem Channel zugeordnet. Die Liste der Trigger, Channel und die Zuordnung dieser wird durch das Fachspezifische Konzept vorgegeben. Es ist denktbar, dass mehrere Trigger den gleichen Channel bedienen. Beispiele hierfür wären, wenn die gleiche Notification von zwei verschiedenen Stellen ausgelöst werden kann oder auf Fachlicher Ebene Events gruppiert werden sollen oder müssen.
Die Liste der verfügbaren channel ist als GET Aufruf verfügbar. Das FdV kann die Liste der channel in gruppen abbilden, um sie für den Nutzer übersichtlicher zu gestalten. Es kann auch vorkommen, dass das FdV nicht alle channel abbildet und sie somit dem Nutzer nicht zur Verfügung stellt. In diesem Fall würde ein Trigger, dessen channel` für einen Nutzer nicht als aktiv konfiguriert wurde keine Push-Nachricht auslösen.
Der Fachdienst hat drei Endpunkte:
-
GET /channels/v1- Ruft die Liste aller verfügbarenchannelab. -
GET /channels/v1/{pushkey}- Ruft die Liste allerchannelund deren Konfiguration für das Gerät mit dem Idnetifierpushkey. -
POST /channels/v1/{pushkey}- Sendet eine Aktualisierung an den Fachdienst um die Konfiguration vorzunehmen.
Die Auswahl des Nutzers hat drei Optionen enabled, disabled und not_set. enabled bedeutet, dass der Nutzer die Push Notification für diesen channel aktiviert hat. disabled bedeutet, dass der Nutzer die Push Notification für diesen channel deaktiviert hat. not_set bedeutet, dass für die FdV-Installation not_set wird für den Trigger wie disabled behandelt. Der Nutzer kann die Auswahl für jeden channel treffen und speichern. Die Auswahl wird dann an den Fachdienst gesendet und dort gespeichert.
Beispiel
Es gibt drei verschiedene Arten von Push Notifications:
Dokument erstellen Dokument lesen Dokument löschen
Dafür gibt es drei verschiedene Trigger (sie können auch numerisch sein):
document.create document.read document.delete
Wenn das FdV einen Aufruf der Operation GET /channels/v1/{pushkey} durchführt, wird eine Liste mit den drei channel zurückgegeben. Diese werden dann im FdV angezeigt, damit der Nutzer entscheiden kann, welche er erhalten möchte. Beim ersten Mal haben alle den Status not_set, da der Nutzer sich noch nicht entscheiden hat. Der Nutzer kann dann seine Auswahl treffen, und beim Speichern führt das FdV einen Aufruf der Operation POST /channels/v1/{pushkey}` durch und sendet die neue Liste an den Fachdienst.
Die Liste kann so aussehen:
| event_id | Status |
|---|---|
|
|
|
|
|
|
Oder als JSON:
Details
{
"channel": [
{
"event_id": "document.create",
"status": "enabled"
},
{
"event_id": "document.read",
"status": "disabled"
},
{
"event_id": "document.delete",
"status": "enabled"
}
]
}Historie 
Es wird nicht möglich sein, eine Push Nachricht verschlüsselt oder unverschlüsselt im Push Gateway oder einem nebengelagerten Dienst dauerhaft speichern zu können. Eine der folgen daraus ist, dass keine vollständige Liste aller Push Notifications verschiedener Dienste geführt werden kann. Mit dem optionalen Feature der Push Historie kann diese Problematik Datenschutzkonform verbessert werden.
Dafür werden zwei Erweiterungen am Fachdienst getroffen. Die erste Erweiterung betrifft zusätzliche Endpunkte /history/* die für authentisierte Benutzer zur Verfügung stehen. Die Endpunkte ermöglichen Zugriff auf versendete Push Nachrichten. Der Nachrichteninhalt ist damit auch nach dem Versand der Push Nachrichten weiter verfügbar.
Die zweite Erweiterung betrifft den Versand der eigentlichen Push Nachrichten vom Fachdienst zum Push Gateway. Ein zusätzliches (unverschlüsseltes) property mit dem Namen "identifier" wird vom Fachdinest versendet. Dieser Identifier kann vom Push Gateway an einen dritten (FdV Betreiber internen) Service weitergegeben werden und dort gemeinsam mit einem Zeitstempel persistiert werden. Da der Identifier keine Personenbezogene Daten beinhaltet ist dies zulässig.
Am FdV kann der interne Service verwendet werden um eine vollständige Liste aller empfangenen Push Nachrichten zu bekommen. Die Elemente die aus dem vorherigen Schritt persistiert wurden können im FdV um die Informationen des Fachdienstes ergänzt werden.
Beispiel
Ein Fachdienst sendet eine Push Nachricht mit zusätzlichem identifier.
{
"ciphertext": "abcderf",
"key_identifier": "123123",
"time_message_encrypted": "2024-01",
"identifier": "123-4567-890",
"data": {
"service": "epa15"
}
}Das Push Gateway übergibt diesen Identifier zusammen z.B. mit einem Zeitstempel in einen internen Service. Das FdV ruft eine Liste aller Push Nachrichten vom internen Service ab. Dies könnte vereinfacht z.B. so aussehen:
Internal Services (Internal Services → FdV)[
{
"id": 1,
"title": "Allgemeine Benachrichtigung",
"description": "Witz des Tages: Warum können Geister so schlecht lügen? Weil man durch sie hindurchsieht!",
"created_at": "2024-01-01T12:00:00Z"
},
{
"id": 2,
"title": "Nachricht zu Ihrer ePA",
"description": "Sie haben eine Nachricht für Ihre ePA erhalten.",
"notification.identifier": "123-4567-890",
"service": "epa15",
"created_at": "2024-04-01T12:00:00Z"
},
{
"id": 3,
"title": "Nachricht zu fremder ePA",
"description": "Sie haben eine Nachricht für eine fremde ePA erhalten.",
"notification.identifier": "098-7654-321",
"service": "erp",
"created_at": "2024-05-01T12:00:00Z"
}
]In diesem Beispiel sind die Nachrichten mit den IDs 2 und 3 von jeweils einem anderen Fachdienst der den eigentlichen Nachrichteninhalt verschlüsselt versendet hat. Die Texte für title und description sind hier vom internen Service generiert, da der eigenliche Nachrichteninhalt dem internen Service nicht bekannt ist.
Das FdV kann jetzt von den eigentlichen Fachdiensten die Nachrichteninhalte laden und anzeigen.
