gemSpec_App_V1.0.0_CC

Prereleases:

PDF HTML Excel XML
Zurück nach oben





Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

App 

des Versicherten




Version1.0.0_CC
Revision1710288
Stand01.09.2026
Statuszur Abstimmung freigegeben
Klassifizierungöffentlich_Entwurf
ReferenzierunggemSpec_App

Dokumentinformationen

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion

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

Dokumentenhistorie

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
1.0.0 CC 01.09.2026 zur Abstimmung freigegeben gematik











Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die fachlichen Anforderungen zur Herstellung des Produkttyps App des Versicherten.

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller die Apps für die Zielgruppe Versicherte entwickeln und mit Fachdiensten interagieren, die in der Zulassunghoheit der gematik verortet sind.

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. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) 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 dem Dokument die von dem Produkttyp bereitgestellten Eigenschaften und Funktionalitäten aus Sicht des Anwenders "Versicherter". Die Details zu den verwendeten Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen/Fachdienstes beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang ).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, u.a. zu den Bereichen Sicherheit, Infrastruktur und Betrieb sowie Authentifizierung und Autorisierung über Zero Trust Komponenten. Diese werden in dem Produkttypsteckbrief zur App gesondert aufgeführt.

1.5 Methodik

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

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Anforderungen werden im Dokument wie folgt dargestellt:
<AF-ID> - <Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

bzw.

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

2 Systemüberblick

Die Spezifikation für die App des Versicherten beschreibt allgemeine Anforderungen an eine App, die für die Zielgruppe Versicherte entwickelt wird. Dabei werden für die App Funktionalitäten in Form von fachlichen Modulen mit teilweise eigenen Steckbriefen definiert. Ausnahmen bilden nur die für TI2.0 Anwendungen essentiellen Teile zu Zero Trust und zur Interaktion mit dem sektoralen IDP. Details zu den Modulen sind in Kapitel 4 Module der App beschrieben.


Abbildung 1: App und Module

Für die grundlegende Funktionalität und Anforderungen an die App wird ein Steckbrief von der gematik veröffentlicht [gem_ProdT_G-App_PTV], der die Anforderungen an die Basisfunktionalität (beschrieben in Kapitel 4.1 Basismodule) enthält und zusätzlich jeweils einen Steckbrief für die unterschiedlichen optionalen Module der App, die ein Hersteller im Rahmen der Zulassung auswählen kann.

3 Systemkontext

Der Fokus dieses Dokumentes liegt auf der "App", die von der Usergruppe "Versicherter" genutzt wird. Aktuell umfasst dieses Dokument mobile Apps und bildet als erstes die Grundlage für den Frontend-Teil der digitalen Patientenrechnung. Neben den Anforderungen die sich aus diesem Spezifikationsdokument ergeben wird das Produkt zusätzliche Eigenschaften aus den Bereichen:

  • betriebliche Anforderungen wie z.B. die Mitwirkung am ITSM siehe [gemVZ_Afo_Hers_App] ,
  • die Anforderungen an den Zero Trust-Architektur (ZETA)-Client und
  • Anforderungen an die sichere, vertrauenswürdige Ausführungsumgebung

sowie zu den zu inkludierenden Fachmodulen erfüllen müssen, die jeweils über separate Steckbriefe ausgewiesen werden. 

4 Module der App

4.1 Basismodule

Basismodule beschreiben die notwendigen Funktionalitäten, um mit den Fachdiensten der TI2.0 zu interagieren. Eventuell können diese in Zukunft noch zu den optionalen Bestandteilen einer App umdefiniert werden. Aktuell ist jedoch keine App in Planung, bei der diese Basisfunktionalität obsolet sein könnte.

4.1.1 Auth Modul

Das Auth Modul der App bildet die benötigte Funktionalität der App mit dem sektoralen IDP ab, um die Benutzer zu authentifizieren und ggf. eine Gerätebindung sicherzustellen. Zusätzlich wird über das Auth Modul ein SSO über mehrere Fachdienste realisiert, sofern der Anwender dem zugestimmt hat. Details zu den Funktionen des Auth Moduls sind in der [Spezifikation vom IDP] beschrieben.

4.1.2 Zeta Client

Der Zeta Client enthält die notwendige Funktionalität, damit der Client sich beim Zeta Guard registrieren kann. Im Anschluss an eine erfolgreiche Anmeldung stellt der Zeta Client die Token für den Fachdienstzugriff bereit und bietet Funktionen, um diese in festgelegten Intervallen zu erneuern.

Abbildung 2: Zeta Integration

4.1.3 Push Benachrichtigungen

Push Benachrichtigungen stellen ein optionales Modul dar, welches von verschiedenen Fachmodulen genutzt werden kann, um Push Benachrichtigungen über die Infrastruktur der Anbieter von Betriebssystemen für mobile Devices zu versenden. Die Inhalte werden vor der Übertragung an die Push-Plattformen von google und Apple aus Datenschutzgründen verschlüsselt.

4.2 Fachmodule

In den folgenden Kapiteln sind die optionalen Module aufgeführt, die in eine App integriert werden können. Es ist also möglich Fachmodul A in App A zu integrieren und Fachmodul B in App B oder Fachmodul A & B gemeinsam in der App A zu implementiieren und dem Anwender bereitzustellen.

4.2.1 DiPag

4.2.1.1 Systemkontext

Abbildung 3: Funktionaler Aufbau der Anwendung Digitale Patientenrechnung

4.2.2 Umsetzungsoptionen

4.2.2.1 Integration ins die bestehende App einer Versicherung

Bei dieser Variante wird die DiPag Funktionalität mit in die App der Versicherung integriert.

Abbildung 4: Integrierte Funktionalität

4.2.2.2 Separate mobile App

Diese Umsetzungsveriante sieht vor eine eigene App zur Interaktion mit dem DiPag-Fachdienst zu entwickeln und die geladenen Dokumente über die Teilen Funktion des Smartphones der App zur Rechnungseinreichung zu übermitteln.

Abbildung 5: Separate App

4.2.3 Akteure und Rollen

Im Kontext der DiPag treten die folgenden Rollen in Kommunikation zueinander:

  • Versicherter,
  • Leistungserbringerinstitution,
  • Abrechnungsdienstleister und
  • Kostenträger

Diese Spezifikation legt den Fokus auf die Sicht des Versicherten.

4.3 Anwendungsfälle aus Sicht des Versicherten

Die in diesem Kapitel beschriebenen Anwendungsfälle setzen einen funktionalen Rahmen für die gewünschte DiPag Funktionalität der Anwendung und sind im Rahmen der Zulassung der gematik vorzuführen. Die Anwendungsfälle sind bewusst abstrakt gehalten, um den Herstellern Freiheitsgerade bei der optimalen Implementierung für unterschiedliche Benutzergruppen zu lassen. Der Implementierungsleitfaden [IG_VERSICHERTEN_APP] mit UI Entwürfen der gematik dient lediglich als Anregung zu einer möglichen Umsetzungsvariante. 

Hinweis: Die Afos sind in dieser Version der Spezifikation enthalten, um dem Leser einen Einblick in die neue Prüfsäule UX-Prüfung und der dieser Prüfsäule zugeordneten Afos zu geben. Die Afos werden im Rahmen der Kommentierung über einen Eigenkommentar in die DiPag spezifischen Spezifikationen verschoben und sind dann nur noch über den Modulsteckbrief Teil der App-Zulassung.

4.3.1 Abruf von Rechnungen (Rechnungsempfänger)

A_30077 - Abruf der Rechnungen

Die DiPag-App MUSS die Rechnungen für den angemeldeten Versicherten vom Fachdienst abrufen. [<=]

4.3.2 Ansicht von Rechnungen

A_30078 - Anzeige der Rechnungen

Die DiPag-App MUSS dem angemeldeten Versicherten seine Rechnungen in einer Übersicht anzeigen. [<=]

A_30082 - Detailansicht der Rechnungen

Die DiPag-App MUSS dem Versicherten die Rechnungen in einer Detailansicht anzeigen können. [<=]

A_30083 - Abruf angereicherter PDFs

Die DiPag-App MUSS zu den Rechnungen das angereicherte PDF abrufen können. [<=]

4.3.3 Manuelles Ändern des Bearbeitungsstatus

A_30084 - Ändern des Bearbeitungsstatus

Die DiPag-App MUSS dem Versicherten ermöglichen den Bearbeitungsstatus einer Rechnung anzupassen. [<=]

4.3.4 Manuelles Markieren von Rechnungen und Dokumenten

A_30179 - Manuelles Markieren

Die DiPag-APP MUSS eine Funktion anbieten, um Markierungen/Notizen an Dokumenten zu hinterlegen. [<=]

4.3.5 Löschen eines Rechnungsvorgangs

A_30104 - Rechnungsvorgang löschen

Die DiPag-App MUSS eine Funktion anbieten, um den Rechnungsvorgang endgültig zu löschen. [<=]

4.3.6 Nutzerprotokoll

A_30080 - Nutzerprotokoll Einsicht

Die DiPag-App MUSS eine Funktion anbieten, um das Nutzerprotokoll einzusehen. [<=]

A_30081 - Nutzerprotokoll Export

Die DiPag-App MUSS eine Funktion zum Export seines Nutzerprotokoll dem Versicherten bereitstellen. [<=]

4.3.7 Berechtigungen verwalten

A_30079 - Berechtigungen bearbeiten

Die DiPag-App MUSS eine Funkion anbieten, um die im Benutzerkonto des Versicherten hinterlegten Berechtigungen zu verwalten. [<=]

4.3.8 Rechnungen teilen

A_30138 - Rechnungs-PDF

Die DiPag-App MUSS die Rechnung als PDF Dokument mit Banking-Apps teilen können. [<=]

A_30103 - EPC-/GiroCode

Die DiPag-App MUSS die Rechnungsdaten als EPC-/GiroCode in Form eines generierten QR-Code Bildes mit Banking-Apps teilen können. [<=]

A_30110 - Zwischenablage der Rechnungsinformationen

Die DiPag-App MUSS für die Felder:

  • Empfänger
  • IBAN
  • Verwendungszweck die Übernahme der Inhalte in die Zwischenablage anbieten.
[<=]

4.3.9 Nutzerkonto verwalten

A_30180 - Nutzerkonto Einstellungen verwalten

Die DiPag-App MUSS eine Funktion anbieten, um das eigene Benutzerkonto verwalten zu können. [<=]

A_30181 - Nutzerkonto löschen

Die DiPag-App MUSS eine Funktion anbieten, um das eigene Benutzerkonto löschen zu können. [<=]

5 Übergreifende Festlegungen

5.1 Sicherheit

Zur Sicherstellung, dass das Thema Sicherheit bei der Entwicklung der App von Beginn an mitgedacht wird, hat der Hersteller nachzuweisen, dass er entsprechende Anforderungen im Rahmen seines Entwicklungsprozesses berücksichtigt.

A_30112 - BSI TR-03185

Der Hersteller MUSS eine Zertifizierung nach BSI TR-03185 vorweisen und das Gutachten der gematik vorlegen. [<=]

Zusätzlich ist sicherzustellen, dass das Zulassungsartefakt die Anforderungen an Vertraulichkeit und Integrität erfüllt und dies über ein Produktgutachen nachzuweisen.

A_30113 - BSI TR-03161

Die App MUSS die BSI [TR-03161-Teil 1] erfüllen, sofern die Bestandteile für die App anwendbar sind und das Gutachten ist der gematik im Rahmen der Zulassung vorzulegen. [<=]

Hinweis: Nicht anwendbar können zum Beispiel sein: O.Paid .. Die Anwendbarkeit ist zwischen Hersteller der App und dem Gutachter zu klären unter Berücksichtigung der in der App enthaltenen Fachmodule und die Anwendbarkeit der TR Anforderungen bezogen auf die fachliche Funktionalität. 

5.2 Datenschutz und Informationssicherheit

5.2.1 Tracking

Für die Analyse des Nutzerverhaltens (Tracking) bei der Verwendung der App durch den Versicherten gelten die nachfolgend aufgeführten Anforderungen.

Im Folgenden wird unter Tracking Usability-Tracking sowie Crash-Reporting verstanden.

A_30018 - Verbot von Werbetracking

Die App für den Versicherten DARF KEIN Tracking zu Werbezwecken verwenden. [<=]

A_30021 - Tracking - Nutzer informieren

Die App MUSS, falls Tracking-Funktionen ohne Einwilligung des Versicherten genutzt werden, den Versicherten über das Tracking der App in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache informieren, bevor die Trackingdaten erhoben werden. [<=]

Hinweis: Diese Anforderung ist nicht durch einen alleinigen Verweis auf die AGB oder Nutzungsbedingungen der App erfüllbar. Verständliche Form bedeutet eine kurze nicht juristische Erklärung zum Zweck des Trackings. Leicht zugängliche Form bedeutet direkt in der App.

A_30019 - Tracking ohne Einwilligung des Nutzers

Die App MUSS, falls Tracking-Funktionen ohne Einwilligung des Versicherten genutzt werden, sicherstellen, dass die Tracking-Daten

  • sich nur auf eine Nutzersession (von der ersten Interaktion des Nutzers mit dem FdV bis zum Schließen des FdVs bzw. bis zum Inaktivitätstimeout) beziehen und nicht mit anderen Sessions des Nutzers verknüpft werden,
  • weder personenbezogene noch pseudonymisierte personenbezogene Daten enthalten,
  • keine nutzerbezogenen IDs oder gerätespezifischen IDs der Nutzergeräte enthalten,
  • keinen Rückschluss auf Versicherte, deren Vertreter, Leistungserbringer oder Kostenträger ermöglichen, insbesondere Rückschlüsse anhand des Nutzerverhaltens über die Zeit oder über Nutzersessions hinweg,
  • nicht durch die Verknüpfung mit personenbezogenen Daten aus anderen Quellen de-anonymisiert werden können
[<=]

Hinweis: Andere Quellen sind z.B. Webtracker, Tracker von anderen Apps oder Trackingmerkmale des Betriebssystems (z.B. Hardware IDs, Network IDs oder Advertising IDs). 

A_30022 - Zufällige Identifier

Die App MUSS, falls Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Versicherten genutzt werden, für jede Clientnutzung neue Nutzungs-Identifier zufällig generieren. [<=]

A_30035 - Keine personenbezogenen Daten

Die App MUSS sicherstellen, falls sie Tracking-Funktionen implementiert, dass die Tracking-Informationen keine Daten enthalten, die natürliche Personen direkt identifizieren. [<=]

A_30023 - Versicherten Opt-in

Die App MUSS, falls Tracking-Funktionen implementiert sind und die Tracking-Daten mehrerer Nutzersessions verknüpft werden, technisch sicherstellen, dass diese Tracking-Funktionen bei der Installation der App standardmäßig deaktiviert sind und nur nach expliziter Einwilligung durch den Versicherten aktiviert werden (Opt-in). [<=]

A_30024 - Einwilligungsinformationen

Die App MUSS den Versicherten vor der Einwilligung in die Aktivierung von Tracking-Funktionen in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen anzeigen:

  • welche Daten durch die Tracking-Funktionen erhoben werden,
  • zu welchen Zwecken die Daten erhoben werden,
  • welche Informationen durch die Auswertung der erhobenen Daten gewonnen werden und ob Rückschlüsse auf den Gesundheitszustand des Nutzers möglich wären,
  • wer die Empfänger der Daten sind,
  • wie lange die Daten gespeichert werden
  • wie die Tracking-Funktionen deaktiviert werden können
[<=]

Hinweis: Diese Anforderung ist nicht durch einen alleinigen Verweis auf die AGB oder Nutzungsbedingungen des FdVs erfüllbar. Verständliche Form bedeutet eine kurze nicht juristische Erklärung zum Zweck des Trackings. Leicht zugängliche Form bedeutet direkt im FdV.

A_30020 - Keine Weitergabe von Sicherheitsmerkmalen

Die App MUSS sicherstellen, dass in den Trackinginformationen keine Sicherheitsmerkmale enthalten sind.
[<=]

Hinweis: Sicherheitsmerkmale sind die Gerätekennung (DeviceID) und Session-Daten wie z. B. geheime oder private Schlüssel, Authentifizierungs- oder Autorisierungsbestätigungen.

A_30037 - Verarbeitung und Auswertung durch Dritte

Der Hersteller der App MUSS die Verarbeitung und Auswertung der gesammelten Tracking-Informationen selbst durchführen und darf diese nicht von einem Drittanbieter durchführen lassen.
[<=]

A_30038 - Keine Profilbildung

Der Hersteller bzw. der Anbieter der App DARF die gesammelten Informationen zu Usability-Tracking sowie Crash-Reporting NICHT für eine Profilbildung verwenden.
[<=]

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Kürzel
Erläuterung

6.2 Glossar

Begriff
Erläuterung
Funktionsmerkmal Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems.

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

    6.5 Referenzierte Dokumente

    6.5.1 Dokumente der gematik

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

    [Quelle]
    		Herausgeber: Titel
    [gemGlossar] gematik: Einführung der Gesundheitskarte – Glossar
    [gemVZ_Afo_Hers_App] gematik: Verzeichnis von betrieblichen Anforderungen
    Prüfvorschrift Hersteller einer App für Versicherte
    [IG_VERSICHERTEN_APP] gematik: Implementierungsleitfaden für App Entwicklungen
    https://gematik.github.io/ig-versicherten-app/v1.0.0/index.html 

    6.5.2 Weitere Dokumente

    [Quelle]
    		Herausgeber (Erscheinungsdatum): Titel