Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature: 

Anwendungsübergreifende
Push Notification

    

     

      
Version
      
1.0.0 CC
     
     

      
Revision
      
1181178
     
     

      
Stand
      
31.03.2025
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemF_PushNotification
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Feature der Notifications eines Teilnehmers des Gesundheitswesens unabhängig von der konkreten Anwendung.

1.1 Zielsetzung

Die Beschreibung des Funktionsumfangs als Feature erleichtert das Verständnis und die Nachvollziehbarkeit der Lösung. Mit den hier aufgestellten Anforderungen sollen Hersteller in der Lage sein, den zusätzlichen Funktionsumfang ihrer verantworteten Komponente bzw. ihres Produkttyps bewerten und umsetzen zu können.

1.2 Zielgruppe

Das Dokument richtet sich zwecks der Realisierung an die Hersteller der mobilen FdVs (Frontend des Versicherten) und Fachdienste sowie an die Anbieter, welche diese Produkte betreiben.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Produkttypsteckbrief, Anbietertypsteckbrief u. a.) oder Webplattformen (z. B. gitHub u. a.) festgelegt und bekanntgegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in diesem Dokument nur die notwendigen oder optionalen Komponenten und Schnittstellen für Push Notifications für mobile FdVs durch Fachdienste der TI.

Benutzte Schnittstellen werden in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief der Produkttypen verzeichnet.

1.5 Methodik

User Story

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikipedia: User Story]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.

Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

Hinweise auf offene Punkte
Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:
Beispiel für einen offenen Punkt.

2 Epic und User Story

2.1 Epic Push Notifications für Gesundheitsanwendungen

Für die Praxistauglichkeit und die Akzeptanz einer mobilen Anwendung im Gesundheitswesen ist es von enormer Bedeutung, dass Nutzer eines FdV Push Notifications erhalten können. Push Notifications sollen dann erscheinen, wenn im Kontext des Versorgungsprozesses eine Aktivität des Nutzers erforderlich wird, oder um den Nutzer zum aktuellen Status zu informieren (z. B. wenn ein neues Dokument in die ePA (elektronische Patientenakte) eingestellt wurde, wenn ein neues E-Rezept ausgestellt wurde oder die Apotheke zu einem Bestellvorgang einen Abholzeitpunkt gemeldet hat).

Grundsätzlich muss ein Versicherter im entsprechenden Fachdienst angemeldet sein (bspw. mit eGK und PIN oder mit Gesundheits-ID), um Informationen vom Fachdienst abzurufen. Da diese Anmeldung zeitlich begrenzt ist, wird der Nutzer automatisch nach einem anwendungsabhängigen Zeitraum wieder abgemeldet. Damit der Nutzer auch über Änderungen im Fachdienst benachrichtigt wird, wenn die Anmeldung automatisch abgelaufen ist, soll die Benachrichtigungsfunktion nicht daran gebunden sein, ob ein Nutzer das FdV geöffnet hat oder aktuell an der TI angemeldet ist.

Um die Benachrichtigungsfunktion zu aktivieren, muss sich der Nutzer im Fachdienst anmelden. Der Nutzer muss im Smartphone einwilligen, dass das FdV Push Notifications anzeigen darf. Ohne diese Einwilligung durch den Nutzer sind Push Notifications nicht erlaubt. Die Einwilligung kann jederzeit durch den Nutzer widerrufen werden, wenn der Nutzer keine Push Notifications mehr erhalten möchte.

Fachdienste, die Push Notifications senden, welche Rückschlüsse auf den Gesundheitszustand des Nutzers zulassen, müssen die Push Notifications verschlüsseln. Fachdienste dürfen unverschlüsselte Push Notifications nur dann senden, wenn weder Gesundheitsdaten noch personenbeziehbare Daten in den Push Notifications enthalten sind. Beispiele hierfür sind: Eine verschlüsselte Benachrichtigung könnte Informationen über ein vom Arzt angelegtes Dokument in der ePA enthalten, während eine unverschlüsselte Benachrichtigung lediglich eine EventID für eine neue Nachricht im Messenger übermitteln kann. Das FdV könnte die eigentlichen Informationen dann als Folge der Push Notification mit Hilfe der EventID nachladen.

Es ist vorgesehen, dass Push Notifications auch dann für FdVs zur Verfügung stehen können, wenn Dienste außerhalb der TI verwendet werden. Zu diesem Zweck wird von jedem FdV-Hersteller neben der Push Implementierung im FdV auch gleichzeitig ein Push Gateway gefordert, der die nötige plattformspezifische Abstraktion realisiert, um auch mobile Geräte zentral erreichen zu können.

2.1.1 User Stories

Als Patient möchte ich von verschiedenen Fachdiensten benachrichtigt werden können, so dass ich über aktuelle Veränderungen informiert bin und, falls notwendig, selbst aktiv werden kann.

Als Patient möchte ich sicher sein, dass Push Notifications mich jederzeit erreichen können, so dass ich nicht regelmäßig nach neuen Informationen im FdV schauen muss, was ich vergessen könnte.

Als Patient möchte ich nicht jeden Tag meine Authentisierung gegenüber Fachdiensten erneuern müssen (bspw. durch eGK und PIN), um Push Notifications erhalten zu können, so dass ich sicher sein kann, dass mich Push Notifications erreichen und nicht von einem manuellen und repetitiven Schritt abhängig sind.

Als Patient möchte ich, dass eine Push Notification keine sensiblen Informationen enthält, so dass ich nicht in Situationen komme, bei denen Dritte solche Informationen auf dem Bildschirm meines Geräts lesen können.

Als Patient möchte ich leicht von einer Push Notification zu dem Bereich des FdV navigieren können, in dem ich mit der neuen Information etwas tun kann, so dass ich nicht manuell das FdV öffnen und über komplizierte Wege dorthin navigieren muss.

Als Patient möchte ich im FdV einstellen können, ob sie mir (z.B. via Fachdienst) Push Notifications schicken darf.

Als Patient möchte ich konfigurieren können, für welchen Situationen ich benachrichtigt werden möchte, sodass ich für mich unwichtige Push Notifications nicht angezeigt bekomme.

3 Einordnung in die Telematikinfrastruktur

Abbildung 1: Systemüberblick

Komponenten

1. Fachdienst: Neben seinen normalen Aufgaben bietet der Fachdienst in diesem Konzept weitere Interface für FdVs an. Diese umfassen unter anderem die Registrierung für Push Notifications sowie die Verwaltung dieser Registrierungen. Er ist ebenso dafür verantwortlich Trigger zu implementieren, die dann (unter Berücksichtigung einer eventuellen Channel-Konfiguration) als Push Notifications via Push Gateway zum FdV gesendet werden.
2. FdV: Das FdV ist die (mobile) Anwendung (App), die von einem Versicherten genutzt wird, um Anwendungsfälle durchzuführen.
3. Push Gateway: Das Push Gateway ist eine Art Proxy das die Kommunikation zum FdV für Notifications mittels Push Provider implementiert. Jedes Push Gateway kann eine oder mehrere FdVs bedienen. Zum Beispiel könnten das iOS FdV und das Android FdV gebündelt in einem Push Gateway angebunden oder je ein Push Gateway pro Plattform existieren. Ebenso ist eine Mandantenfähigkeit des Push Gateways denkbar.
4. Push Provider: Push Provider sind die Dienste der mobilen Betriebssystemplattformbetreiber (z.B. iOS, Android), welche die Push Notifications an das FdV auf dem Gerät des Versicherten senden. Diese Dienste sind nicht Teil der Telematikinfrastruktur.

4 Technisches Konzept

Der Zweck dieses Konzepts besteht darin, eine flexible und sichere Push Infrastruktur bereitzustellen, die es ermöglicht, dass verschiedene Fachdienste Push Notifications an eine mobile Anwendung senden können. Durch die Implementierung eines zentralen Push Gateways pro FdV wird eine einheitliche Schnittstelle geschaffen, die als Fassade für die plattformspezifischen APIs von Anbietern wie Google und Apple fungiert. Dies erlaubt es mehreren Fachdiensten, gleichzeitig Push Notifications für vorher unbekannte FdVs bereitzustellen, ohne dass jeder Fachdienst individuell mit den plattformspezifischen APIs interagieren muss. Eine Anpassung der Fachdienste für zukünftige neue Push Provider ist ebenso nicht notwendig, da dafür ein neues oder angepasstes Push Gateway ausreicht.

Ein weiterer Vorteil dieses Ansatzes ist, dass die Credentials, die das Push Gateway gegenüber dem Push Provider authorisieren eine Push Nachricht an ein FdV zu senden, beim Push Gateway bleiben und nicht an alle Fachdienste weitergegeben werden müssen. Dadurch wird das Risiko eines unbefugten Zugriffs auf diese Geheimnisse minimiert und die Integrität der Kommunikation gewährleistet. Als Vorbild dient die Push Implementierung wie sie im Matrix Protokoll beschrieben ist.

Weitere Details und Beispiele sind auf Github ([Push_Notification_Generic_Concept]) zu finden. Neben einer detaillierten Beschreibung finden sich dort auch OpenAPI Dokumente für die konkreten Schnittstellen.

5 Spezifikation

Dieses Kapitel beschreibt die technischen Anforderungen und Spezifikationen für die Implementierung des Push Notification-Systems, das in den Fachdiensten und FdVs integriert wird. Ziel ist es, eine sichere und effiziente Kommunikation zwischen den Systemkomponenten zu gewährleisten, die den Nutzern zeitnahe Push Notifications über relevante Ereignisse ermöglicht.

5.1 Anforderungen an den Fachdienst

Der anwendungsspezifische Fachdienst verwaltet die Push Notifications für den jeweiligen Anwendungsfall. Der Fachdienst erstellt Push Notifications für abonnierte Ereignisse und übermittelt diese an das zuständige Push Gateway. Er bietet Schnittstellen für Versicherte zur Registrierung und Konfiguration von Pushern. Ein Pusher bezieht sich auf eine FdV-Instanz und ist eine Konfiguration im Fachdienst, in der die Informationen zur Adressierung der Push Notifications hinterlegt werden (u. a. das zu nutzende Push Gateway, Schlüssel zur Verschlüsselung von Nachrichteninhalten). Der Versicherte kann für mehrere Endgeräte Pusher im Fachdienst hinterlegen.

Nicht alle Anforderungen werden für alle Produkttypsteckbriefe Anwendung finden. Abhängig vom Produkt wird Verschlüsselung für Push Notifications notwendig sein oder nicht, entsprechende Afos entfallen daher gegebenenfalls. Es gelten nur die Afos, die auch im Produktsteckbrief zugeordnet sind.

Der anwendungsspezifische Fachdienst muss sich selbst um die Themen kümmern, die hier nicht festgelegt werden. Dazu gehören unter anderem das Festlegen von Triggern, das Bestimmen des Nachrichteninhalts und Authorisierungsthemen.

5.1.1 Pusher registrieren

Da ein anwendungsspezifischer Fachdienst jedoch zusätzliche Anforderungen an seine API haben kann, können dieser eigene Anforderung dazu formuliert, und ein einiges OpenApi auf der Basis [OpenApi_Notification_Fachdienst] definiert werden.

5.1.2 Operation Notify

Beispiel zu A_27610-*:

Die maximal verfügbare Größe für den Nachrichteninhalt sind 2048 Bytes. Die eigentliche Nachricht ist "test". Dann ist die Länge des Leerzeichenabschnitts = 1024 - 4 - 2 - 4 = 1014. 

Hexdump der Konkatenation: 504e4d31 07f6 020202...0202 74657374

Die Details der möglichen Antworten sind auf der OpenAPI-Seite zu finden [OpenApi_Notification_PushGateway].

Hinweis zu A_27436-*: Das Verbot von unverschlüsselten personenbezogenen Klartextdaten bezieht sich auf alle Informationen einer Push Notification, nicht nur auf den Benachrichtigungsinhalt.

Hinweis: Es ist zulässig, dass nach einer gewissen Zeit der Push-Versand abgebrochen wird, da davon ausgegangen werden kann, dass eine Push-Nachricht nur für einen gewissen Zeitraum für ein Event von Bedeutung ist.

5.2 Anforderungen an das Push Gateway

Das Push Gateway besitzt einen anwendungsübergreifenden Endpunkt, an den Push Notifications übermittelt werden. Das Push Gateway leitet die Informationen der Push Notification an den Push Provider weiter. Es wird vom Hersteller des FdV bereitgestellt, und es kann weitere Endpunkte für Dienste außerhalb der TI geben, die ebenfalls über dieses Push Gateway Notifications versenden.

Hinweis zu A_27611-*: Der plattformspezifische Push Provider soll u.a. nicht erkennen können, ob es sich um Push Notifications zur ePA oder zum E-Rezept handelt.

Hinweis: Ein Implementierungsleitfaden ist unter [Push_Notification_Generic_Concept#priority] zu finden.

5.3 Anforderung an die FdV-Instanz

Die FdV-Instanz ist ein auf einem mobilen Endgerät installiertes FdV.  Push Notifications werden für eine FdV-Instanz registriert und an diese gesendet.  Die FdV-Instanz kann mehrere Anwendungen integrieren (ePA, E-Rezept, TI-Messenger, Kassenanwendungen), für die der Versicherte jeweils Push Notifications auswählen kann.

In der jeweiligen Fachdienst-Spezifikation wird geregelt, ob verschlüsselte oder unverschlüsselte Push Notification versendet werden.

Hinweis: Der Anwendungsfall "Push Notifications" ist optional für die FdV-Hersteller. Das wird auch so im Steckbrief stehen. Wenn sich ein FdV-Hersteller entscheidet, Push Notifications zu implementieren, gelten diese Anforderungen.

Da ein anwendungsspezifischer Fachdienst jedoch zusätzliche Anforderungen an seine API haben kann, können dieser eigene Anforderung dazu formuliert, und ein einiges OpenApi auf der Basis [OpenApi_Notification_Fachdienst] definiert werden.

5.3.1 Schlüsselableitung für Push Notifications

5.3.2 FdV-Instanz Registrieren

Die app_id sollte ein "reverse-DNS style identifier" sein (zum Beispiel: "com.example.app.ios"). Wichtig ist, dass der Push Gateway später daraus ableiten kann, wie das FdV zu erreichen ist. Für iOS FdVs könnte hierfür der Bundle Identifier verwendet werden, für Android FdVs wäre dies der Package Name.

Hinweis: Die Einwilligung wird typischer weise auf dem Endgerät (z.B. iOS oder Android Gerät) lokal im System gespeichert und kann ggf. in den Systemeinstellungen des Betriebssystems widerrufen werden.

Hinweis: Wenn sich das FdV bei mehreren Anwendungen registriert, muss der Prozess für jede Anwendung einzeln ausgeführt werden.

Hinweis: Diese Anforderung betrifft nur die technisch erhobenen Daten. Eine Benennung von Geräten durch Nutzer, die personenbezogene Daten (wie z.B. die KVNR) enthält, kann technisch nicht verhindert werden und fällt nicht unter diese Anforderung.

5.3.2.1 Push Notifications empfangen

Hinweis zu A_27612-*: Durch die Anforderung sollen z.B. Phishing-Angriffe verhindert werden.

5.3.2.2 Notifications aktivieren und deaktivieren

5.4 Optionale Anforderungen

Folgende Anforderungen sind optional in dem Sinne, dass ein Produktsteckbrief diese Anforderungen verwenden kann, sofern das Produkt das Feature verwenden soll. Unterstützt ein Produkt ein Feature nicht, werden diese Anforderungen auch kein Teil des Produktsteckbriefes und sind somit auch nicht Teil der Anwendung.

5.4.1 Channel/Trigger Konfiguration

5.4.1.1 Fachdienst

Da ein anwendungsspezifischer Fachdienst jedoch zusätzliche Anforderungen an seine API haben kann, können dieser eigene Anforderung dazu formuliert, und ein einiges OpenApi auf der Basis [OpenApi_Notification_Fachdienst] definiert werden.

5.4.1.2 FdV

5.4.2 Push Notification Historie

Durch das implementieren der Push Notification Historie wird es den FdVs ermöglicht auch nach dem einmaligen Empfang einer Push Notification erneut auf versendete Push Notifications zuzugreifen. Beispiele wie dieses Feature zum Einsatz gebracht werden kann, finden sich unter [Push_Notification_Optional_History].

5.4.2.1 Fachdienst

Da ein anwendungsspezifischer Fachdienst jedoch zusätzliche Anforderungen an seine API haben kann, können dieser eigene Anforderung dazu formuliert, und ein einiges OpenApi auf der Basis [OpenApi_Notification_Fachdienst] definiert werden.

Hinweis: Wenn ein Fachdienst Anforderungen an maximale Speicherdauer von Daten hat, sind diese ggf. auch für die Push Historie zu berücksichtigen.

5.5 Sicherheit

Da für das Übertragen der Push Notifications die Dienste der Anbieter von mobilen Plattformen (z.B. Google, Apple) genutzt werden, ist insbesondere das Thema der Datenverarbeitung in Drittstaaten zu beachten und die sich daraus ergebenden datenschutzrechtlichen Herausforderungen mit technischen Maßnahmen abzumildern.

Diese Maßnahmen sind:

• Es kann eine Verschlüsselung des Benachrichtigungsinhalts zwischen Fachdienst und FdV, die sowohl die Vertraulichkeit als auch die Authentizität/Integrität des Benachrichtigungsinhalts schützt, eingesetzt werden. Die Notwendigkeit dafür wird in der Spezifikation des jeweiligen Fachdienstes festgestellt.
• Vom Nutzer wird eine informierte Einwilligung eingeholt.

Die Einwilligung für den Empfang von Push Notifications und den Widerruf der Einwilligung kann der Versicherte im FdV vornehmen.

Die Kommunikation zwischen dem Fachdienst und dem Push Gateway erfolgt mittels TLS und beidseitiger Authentifizierung (mTLS). Für diese Authentifizierung müssen Zertifikate der Komponenten-PKI der TI verwendet werden. Aus Sicht der jeweiligen Komponente ist es wichtig mit dem richtigen Partner zu kommunizieren. Der Fachdienst soll sicher sein, die Notifications an den richtigen Push Gateway zu senden und der Push Gateway soll sicher sein, die Notifications vom richtigen Fachdienst zu erhalten.

Die Verbindung vom Push Gateway zum Push Provider erfolgt ebenfalls über eine mittels des TLS-Protokolls geschützten Datenverbindung.

Für die Festlegung von Maßnahmen zum Schutz der Informationen, die im Notification Service verarbeitet werden, erfolgt hier eine Schutzbedarfsfeststellung der maßgeblichen Informationsobjekte. Die Verwendung von Datenklassen erfolgt dabei gemäß der Methodik zur Schutzbedarfsfeststellung der gematik für die TI.

Tabelle 3: Schutzbedarf der Informationsobjekte, die für das Feature Push Notifications benötigt werden

Diese Bewertung lässt eine Verarbeitung der Informationsobjekte im Push Gateway ohne spezielle technische Maßnahmen - wie z. B. eine VAU - zu.

5.6 Betrieb

5.6.1 Betriebliche Steuerung des Push-Gateways

Die Frage, ob es eine betriebliche Steuerung des Push-Gateways geben soll und, wenn ja, in welchem Umfang, ist noch in interner Abstimmung und wird später nachgeliefert.

6 Dokumentenhaushalt

Punkt befindet sich noch in Klärung

angepasst: gemProdT_ePA_FdV Kapitel 4.1

7 Beispiele und Referenzimplementierungen

Beispiele und ggf. Referenzimplementierungen sind in der Dokumentation unter [Push_Notification_Github_Repo] zu finden.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Abbildungsverzeichnis

8.3 Tabellenverzeichnis

8.4 Referenzierte Dokumente

8.4.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

8.4.2 Weitere Dokumente

9 Anhang C – Offene Punkte, Fragen

9.1 Betriebliche Steuerung des Push-Gateways

Die Frage, ob es eine betriebliche Steuerung des Push-Gateways geben soll und, wenn ja, in welchem Umfang, ist noch in interner Abstimmung und wird später nachgeliefert.