gemSpec_DiPag_FD

Telematikinfrastruktur 2.0

Spezifikation

Digitale Patientenrechnung

Fachdienst

    Version1.1.3_CCRevision1655850Stand03.07.2026Statuszur Abstimmung freigegebenKlassifizierungöffentlich_EntwurfReferenzierunggemSpec_DiPag_FD

# 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
--- | --- | --- | --- | ---
|  |  | aufgrund der Technikanpassung wurde V1.0.0 erweitert auf V1.1.0 | gematik
1.1.0 | 19.05.2025 |  | - Berücksichtigung des aktuellen Standes der Zero Trust Architektur der TI (ZETA). - Platzierung des Rechnungstoken als 2D Barcode auf jeder Seite des Rechnungs-PDF - Unterstützung elektronischer Zahlungen - Anpassung gemäß E-Rechnung_25_1 | gematik
1.1.1 | 22.05.2025 |  | formale Änderung von "E-Rechnung" in "Digitale Patientenrechnung" inkl. Dokumentenreferenzierungskürzel (vorher gemSpec_eRg_FD) | gematik
1.1.2 | 22.10.2025 |  | Korrekturen und Klarstellungen | gematik
1.1.3_CC | 03.07.2026 |  | - Inhaltliche Korrekturen und Klarstellungen aus der Implementierungsphase - Konsistente Zuordnung von Prüfverfahren | gematik

# Inhaltsverzeichnis

- Dokumentinformationen
- Inhaltsverzeichnis
- 1 Einordnung des Dokumentes
- 1.1 Zielsetzung
- 1.2 Zielgruppe
- 1.3 Geltungsbereich
- 1.4 Abgrenzungen
- 1.5 Methodik
- 2 Systemüberblick
- 3 Systemkontext
- 3.1 Zugang zum Fachdienst in der TI
- 3.2 Autorisierte Nutzergruppen und Rollen
- 3.2.1 Claims
- 3.2.2 Scopes
- 4 Zerlegung des Produkttyps
- 5 Übergreifende Festlegungen
- 5.1 Datenschutz und Informationssicherheit
- 5.1.1 Protokollierung für die Versicherten
- 5.1.2 Löschfristen
- 5.1.2.1 Nutzerkonten
- 5.1.2.2 Rechnungen und Dokumente
- 5.1.3 Vertrauenswürdige Ausführungsumgebung
- 5.1.3.1 Verarbeitungskontext
- 5.1.3.2 Verarbeitung schützenswerter Daten
- 5.1.3.3 Persistierung schützenswerter Daten
- 5.1.3.4 Transport schützenswerter Daten
- 5.1.3.5 Schutz der Integrität der VAU
- 5.1.3.6 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld
- 5.1.3.7 Einbinden des ZETA Guard der gematik
- 5.1.3.8 Konsistenz des Systemzustands, Logging und Monitoring
- 5.1.4 Dateigrößen
- 5.1.5 Dokumentenformate
- 5.1.6 Nutzerprotokoll
- 5.1.6.1 Rechnungen
- 5.1.6.2 Berechtigungen
- 5.1.6.3 Markierungen
- 5.1.6.4 Nutzerkonten
- 5.2 RESTful API
- 5.3 FHIR-Ressourcen
- 5.4 FHIR-Endpunkte und -Operations
- 5.4.1 RE-PS als Akteur
- 5.4.1.1 Abfrage Rechnungsempfänger und dessen Einwilligung zum Rechnungsversand
- 5.4.1.2 Rechnung validieren und einreichen
- 5.4.1.3 Rechnung validieren/einreichen (Bulk)
- 5.4.1.4 Abfrage von Daten zu Rechnungen und Dokumenten per Token
- 5.4.1.5 Abfrage von angereicherten PDFs per Token (Bulk)
- 5.4.2 FdV als Akteur
- 5.4.2.1 Abrufen/Suchen von Rechnungen
- 5.4.2.2 Abfrage von Daten zu Rechnungen und Dokumenten per Token
- 5.4.2.3 Statuswechsel
- 5.4.2.4 Markieren von Rechnungen und Dokumenten
- 5.4.2.5 Löschen eines Rechnungsvorgangs
- 5.4.2.6 Nutzerprotokoll einsehen
- 5.4.3 KTR als Akteur
- 5.4.3.1 Abfrage von Daten zu Rechnungen und Dokumenten per Token
- 5.5 Weitere REST-Endpunkte
- 5.6 Nutzerregistrierung
- 5.6.1 Institutionen
- 5.6.2 Versicherte
- 5.7 Benachrichtigungen
- 5.8 Interne Fehlercodes
- 6 Informationsmodell
- 6.1 FHIR-Ressourcen
- 6.2 Nutzerprotokoll
- 6.3 Rechnungs- oder Dokumenten-Token
- 6.3.1 Zufallswert
- 6.3.2 Darstellung als Barcode
- 6.4 Angereichertes PDF
- 6.5 Signatur
- 7 Verteilungssicht
- 8 Anhang A – Verzeichnisse
- 8.1 Abkürzungen
- 8.2 Glossar
- 8.3 Abbildungsverzeichnis
- 8.4 Tabellenverzeichnis
- 8.5 Referenzierte Dokumente
- 8.5.1 Dokumente der gematik
- 8.5.2 Weitere Referenzen

## 1 Einordnung des Dokumentes

### 1.1 Zielsetzung

Die vorliegende Spezifikation definiert die fachlichen Anforderungen zur Herstellung des Produkttyps Digitale Patientenrechnung Fachdienst. Sie dient als Ergänzung und Detaillierung der konzeptionellen Beschreibung der Anwendung Digitale Patientenrechnung im Feature Dokument [gemF_DiPag].

### 1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller des Digitale Patientenrechnung Fachdienstes, sowie an Hersteller und Anbieter von weiteren Produkttypen der Fachanwendung Digitale Patientenrechnung .

### 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 (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen 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 Infrastruktur und Betrieb sowie Authentifizierung und Autorisierung über Zero Trust Komponenten. Diese werden in dem Produkttypsteckbrief des Produkttyps DiPag FD verzeichnet, der zu einem späteren Zeitpunkt zur Verfügung gestellt wird.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich des Frontend der Versicherten der Anwendung Digitale Patientenrechnung (DiPag FdV). Hierzu wird zu einem späteren Zeitpunkt ein weiteres Spezifikationsdokument sowie ein Produkttypsteckbrief für den Produkttyp DiPag FdV erstellt.

### 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.

FHIR Spezifikation

Des Weiteren wird im Dokument über AFOs auf die Spezifikation der Operationen und Datenstrukturen in FHIR referenziert. Die referenzierten Festlegungen zu FHIR sind auf simplifier.net [Simplifier DiPag] verfügbar und dort über einen Implementation Guide dokumentiert. Sie werden während der Auftragsvergabe und Umsetzung zusammen mit dem Auftragnehmer im Rahmen der jeweils geltenden Anforderungslage weiterentwickelt und stellen in der aktuellen Version mitgeltende Bestandteile der vorliegenden Spezifikation dar.

## 2 Systemüberblick

Das folgende Bild zeigt die funktionale Aufteilung des Fachdienstes sowie die Schnittstellen zu den Client-Systemen und weiteren benötigten Diensten (siehe auch [gemF_DiPag#5.1 Zerlegung des Fachdienstes]).

Abbildung 1: Funktionaler Aufbau der Anwendung Digitale Patientenrechnung

Des Weiteren ist dargestellt, welche funktionalen Anteile und Schnittstellen des Digitale Patientenrechnung Fachdienstes im Rahmen dieser Spezifikation beschrieben werden. Nur die rot umrandeten Anteile des Fachdienstes sind Gegenstand dieser Spezifikation, d.h. Anforderungen an folgende Gegenstände werden hier nicht oder nur teilweise erfasst. Dies betrifft

- betriebliche Anforderungen wie z.B. das Betriebsdaten-Monitoring,
- die Absicherung des Fachdienstes per Zero Trust-Architektur (ZETA) und
- Anforderungen an die sichere, vertrauenswürdige Ausführungsumgebung.

Anforderungen zu den oben aufgeführten Gegenständen ergeben sich aus referenzierten Dokumenten bzw. den Anforderungen aus mitgeltenden Dokumenten gemäß Produkttypsteckbrief des Fachdienstes.

## 3 Systemkontext

Entsprechend der Beteiligung der Nutzergruppen der Digitale Patientenrechnung sind die jeweils genutzten IT-Systeme in die Gesamtlösung zu integrieren (für mehr Details siehe [gemF_DiPag#3]).

### 3.1 Zugang zum Fachdienst in der TI

Der Zugang für die Nutzergruppen und die von ihnen genutzten Client-Systeme wird auf unterschiedliche Weise umgesetzt:

Institutionen (Rechnungsersteller und Kostenträger)

Der Zugriff erfolgt über das Internet, abgesichert nach dem Zero Trust-Ansatz, siehe [gemSpec_ZETA]. Da die Authentisierung der Institutionen in der ersten Version der Digitale Patientenrechnung mit der SMC-B bzw. HSM-B erfolgt, müssen diese über eine Anbindung mittels zugelassener dezentraler Komponenten verfügen:

- Konnektor oder
- Basis-Consumer oder
- TI Gateway (mit High Speed Konnektor)

Für die Anwendung Digitale Patientenrechnung (DiPag) ist kein Fachmodul für den Konnektor oder den Basis-Consumer vorgesehen.

Eine Zusammenstellung der verschiedenen möglichen TI-Zugangslösungen findet sich in [gemF_DiPag#Anhang A].

Versicherte

Der Zugriff erfolgt über das Internet, abgesichert nach dem Zero Trust-Ansatz, siehe [gemSpec_ZETA].

### 3.2 Autorisierte Nutzergruppen und Rollen

Leistungserbringerinstitutionen (LEI) , Abrechnungsdienstleister (ADL), Kostenträger (KTR) und Versicherte, die auf den Digitale Patientenrechnung Fachdienst zugreifen möchten, müssen zuvor autorisiert werden. Dabei erfolgt eine rollenbasierte Berechtigungsprüfung durch den Autorisierungsdienst des Fachdienstes, wobei nur bestimmten Nutzergruppen der Zugriff in der jeweils zulässigen Rolle auf die Anwendung DiPag gewährt wird. Diese Prüfung basiert auf der OID (Object Identifier) des Nutzers, die bei der Anmeldung mittels GesundheitsID (Versicherte) oder SM(C)-B (Institutionen) ermittelt wird.

A_26020 - Digitale Patientenrechnung Fachdienst - Erlaubte Nutzergruppen und Rollen

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass bei der Autorisierung ausschließlich die in der Tabelle angegebenen Nutzergruppen und OIDs Zugriff erhalten dürfen und darauf basierend die folgenden Rollen zugewiesen werden müssen.

Tabelle 1: Erlaubte Nutzergruppen und Rollen

Nutzergruppe | OID1 (gemäß [gemSpec_OID]) | Rolle
--- | --- | ---
Versicherter | oid_versicherter | Rechnungsempfänger, Rechnungseinreicher
Leistungserbringerinstitution | oid_zahnarztpraxis oid_praxis_arzt oid_oeffentliche_apotheke | Rechnungsersteller
Abrechnungsdienstleister | oid_abrechnungsdienstleister | Rechnungsersteller
Kostenträger | oid_kostentraeger | Kostenträger

1Die Auflistung der zulässigen OIDs ist abschließend, wird jedoch ggf. bei weiteren Ausbaustufen erweitert, um die autorisierten Nutzergruppen zu erweitern. [<=]

#### 3.2.1 Claims

A_26026 - Digitale Patientenrechnung Fachdienst - Autorisierte Nutzergruppen und Rollen - Claims

Der Digitale Patientenrechnung Fachdienst MUSS die Claims verwenden, die in [gemF_DiPag] beschrieben sind. [<=]

#### 3.2.2 Scopes

Der Digitale Patientenrechnung Fachdienst verwendet Scopes, die sich im Aufbau an den Empfehlungen von [SMART on FHIR] orientieren. Diese bestehen aus dem Namen des Datenobjekts, gefolgt von einem "." und eine Liste an Berechtigungen. Die Liste der Berechtigungen besteht in der Reihenfolge aus den Buchstaben "c" = "create", "r" = "read", "u" = "update", "d" = "delete" und "s" = "search", sofern zutreffend. Ein Scope, der das Lesen und Aktualisieren einer Rechnung erlaubt, würde wie folgt lauten:

invoiceDoc.ru

A_26027 - Digitale Patientenrechnung Fachdienst - Autorisierte Nutzergruppen und Rollen - Scopes

Der Digitale Patientenrechnung Fachdienst MUSS zur Prüfung der Autorisierung bei Aufrufen die Scopes verwenden, welche wie folgt den Rollen zugeordnet sind:

Tabelle 2: Rollen und Scopes

Rolle | Zugriffsberechtigung | Scope
--- | --- | ---
Rechnungsersteller | Daten des Rechnungsempfängers lesen | insurantAccount.rs
Digitale Patientenrechnungen (mit Dokumenten) anlegen | invoiceDoc.c
Angereichertes Dokument abrufen | invoiceDoc.r
Eigenes Nutzerkonto anlegen, lesen, bearbeiten und löschen | practitionerAccount.crud
Rechnungsempfänger | Digitale Patientenrechnungen (mit Dokumenten) lesen, bearbeiten1, löschen und suchen | invoiceDoc.ruds
Angereichertes Dokument abrufen | invoiceDoc.r
Eigenes Nutzerkonto anlegen, lesen, bearbeiten und löschen | insurantAccount.crud
Einträge des Nutzerprotokolls lesen und suchen | auditEvent.rs
Berechtigungen lesen, bearbeiten und löschen | permission.rud
Kostenträger | Digitale Patientenrechnungen (mit Dokumenten) lesen | invoiceDoc.r
Angereichertes Dokument abrufen | invoiceDoc.r
Eigenes Nutzerkonto anlegen, lesen, bearbeiten und löschen | insuranceAccount.crud

[<=]

Hinweise:

1 Das "Bearbeiten" von Dokumenten und Digitale Patientenrechnungen beschränkt sich auf die Bearbeitung von ergänzenden Metadaten, z.B. eine Markierung als ungelesen oder gelesen. Die eigentlichen Digitale Patientenrechnungen und Dokumente werden unverändert gespeichert und übertragen.

## 4 Zerlegung des Produkttyps

Eine weitere Untergliederung der Aufbaustruktur des Produkttyps ist nicht erforderlich.

## 5 Übergreifende Festlegungen

### 5.1 Datenschutz und Informationssicherheit

Dieser Abschnitt enthält die anwendungsfallübergreifenden Datenschutz- und Sicherheitsanforderungen an den Digitale Patientenrechnung Fachdienst bzw. seinen Hersteller sowie Anbieter/Betreiber.

Allgemeine Anforderungen

Der Hersteller des Digitale Patientenrechnung Fachdienstes muss die Anforderungen aus dem Abschnitt "Sicherer Softwareentwicklungsprozess" sowie die Anforderungen aus dem Abschnitt "Unterstützung von Audits" des Dokuments [gemSpec_DS_Hersteller] erfüllen. Die konkreten Anforderungen sind im Produkttypsteckbrief aufgeführt.

Die gematik stellt mit der Prüfkarte eGK eine elektronische Identität zur Überprüfung verschiedener Anwendungsfälle in der Telematikinfrastruktur (TI) zur Verfügung, die vorrangig von Dienstleistern vor Ort (DVOs) genutzt wird. Die Prüfkarte eGK ist nicht für die Nutzung im regulären Versorgungsalltag von Leistungserbringern (LE) oder Versicherten vorgesehen. Die folgende Anforderung soll eine Vermischung von Prüfaktivitäten mittels der Prüfkarte eGK und den Anwendungsfällen von Versicherten verhindern.

A_25907 - Digitale Patientenrechnung Fachdienst – Umgang mit Prüfidentitäten

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Prüfidentitäten nicht auf Daten von echten Personen oder Institutionen zugreifen können und dass echte Personen oder Institutionen nicht auf Daten von Prüfidentitäten zugreifen können. [<=]

Hinweis: Eine eGK-Prüfkartenidentität kann anhand der Bildungsregel X0000nnnnP, mit nnnn aus der Menge {0001 .. 5000} und P = Prüfziffer für die KVNR der Prüfkarte eGK erkannt werden.

Für die Gesamtsicherheit der Anwendung Digitale Patientenrechnung ist es bedeutsam, dass der Digitale Patientenrechnung Fachdienst nur zugelassene – und damit sicherheitsgeprüfte – Frontends des Versicherten (FdVs) den Zugriff auf Daten ermöglicht. Dies wird durch Komponenten der Zero Trust-Architektur sichergestellt.

Die Gliederung der folgenden Anforderungen orientiert sich an den Schutzzielen des Datenschutzes und der Informationssicherheit.

Vertraulichkeit

Die Vertraulichkeit der im Digitale Patientenrechnung Fachdienst verarbeiteten personenbezogenen medizinischen Daten wird durch

- die Verschlüsselung der Daten beim Transport in den Digitale Patientenrechnung Fachdienst und aus dem Digitale Patientenrechnung Fachdienst sowie zwischen den Komponenten des Fachdienstes (data in motion),
- die vertrauliche Verarbeitung im Digitale Patientenrechnung Fachdienst (data in use, siehe Anforderungen zur VAU in Abschnitt 5.1.3 Vertrauenswürdige Ausführungsumgebung),
- und die verschlüsselte Speicherung im Digitale Patientenrechnung Fachdienst (data at rest, siehe Anforderungen zur VAU in Abschnitt 5.1.3 Vertrauenswürdige Ausführungsumgebung)

gewährleistet. Die kryptographischen Vorgaben für die umzusetzenden Maßnahmen (insbes. TLS) sind in [gemSpec_Krypt] formuliert.

A_25911 - Umsetzung der fachlichen Operationen in einer VAU

Der Digitale Patientenrechnung Fachdienst MUSS die Verarbeitung aller fachlichen Operationen des Fachdienstes in einer VAU umsetzen. [<=]

Integrität

Die von LE bzw. Abrechnungsdienstleistern (ADL) eingestellten Rechnungen werden nach der Übertragung in den Fachdienst mit der Identität des Digitale Patientenrechnung Fachdienstes signiert. Ein Client, der Dokumente abruft, kann damit im Nachhinein die Integrität einer Rechnung prüfen. Details zur Signatur finden sich im Abschnitt 6.5 Signatur.

Verfügbarkeit

Die Verfügbarkeit des Digitale Patientenrechnung Fachdienstes wird über die betrieblichen Anforderungen geregelt.

Transparenz

Der Digitale Patientenrechnung Fachdienst führt Nutzerprotokolle für die Versicherten, in denen alle Zugriffe auf die personenbezogenen (medizinischen) Daten eines Versicherten für den Versicherten einsehbar sind. Die Protokolleinträge müssen enthalten, wer wann in welchem Use Case (auf was) zugegriffen hat. Die Einträge müssen in einer leicht verständlichen Sprache formuliert sein.

Die Anforderungen zur Protokollierung sind in Abschnitt 6.2 Nutzerprotokoll formuliert.

Nichtverkettbarkeit

A_25914 - Digitale Patientenrechnung Fachdienst - Verbot unbefugter Profilbildung aus personenbezogenen Daten

Der Anbieter des Digitale Patientenrechnung Fachdienstes DARF im Digitale Patientenrechnung Fachdienst verarbeitete personenbezogene Daten NICHT für eine unbefugte Profilbildung verwenden. [<=]

Diese Anforderung gilt explizit auch für Verbindungsdaten, die durch die Kommunikation von Clients der Nutzer mit dem Fachdienst entstehen.

A_25913 - Digitale Patientenrechnung Fachdienst - Verbot unbefugter Profilbildung aus Verbindungsdaten

Der Anbieter des Digitale Patientenrechnung Fachdienstes DARF anfallende Verbindungsdaten (Client-IP-Adresse, etc.) NICHT für eine unbefugte Profilbildung der verbundenen Clients bzw. ihrer Nutzer verwenden. [<=]

Hinweis: Eine Verwendung zur Sicherung der Schnittstelle (DDoS-Schutz, Fehleranalyse in sehr eingeschränktem Maß) ist zulässig (im Sinne einer befugten Profilbildung zur Sicherstellung des sicheren Betriebs).

Intervenierbarkeit

Die Nutzung der Anwendung Digitale Patientenrechnung ist für alle Beteiligten freiwillig. Die Versicherten geben ihre Einwilligung in die Nutzung der Anwendung über das FdV und der Fachdienst muss diese Information speichern.

A_25918 - Digitale Patientenrechnung Fachdienst – Anlegen Nutzerkonto nur bei Einwilligung

Der Digitale Patientenrechnung Fachdienst DARF NICHT ein Nutzerkonto für einen Nutzer anlegen, wenn ihm dessen Einwilligung in die Nutzung der Anwendung Digitale Patientenrechnung nicht vorliegt. [<=]

A_25919 - Digitale Patientenrechnung Fachdienst – Einwilligung speichern

Der Digitale Patientenrechnung Fachdienst MUSS die Einwilligung eines Nutzers in die Nutzung der Anwendung Digitale Patientenrechnung speichern. [<=]

Widerruft ein Nutzer die Einwilligung zur Nutzung der Anwendung, muss sein Nutzerkonto und die die damit verbundenen Daten im Fachdienst gelöscht werden. Andersherum ist die Löschung eines Nutzerkontos durch den Nutzer gleichbedeutend mit dem Widerruf der Einwilligung in die Anwendung Digitale Patientenrechnung .

A_25920 - Digitale Patientenrechnung Fachdienst – Daten löschen bei Widerrufung der Einwilligung

Der Digitale Patientenrechnung Fachdienst MUSS alle Daten von und über einen Nutzer löschen, wenn ein Nutzer die Einwilligung in die Nutzung der Anwendung Digitale Patientenrechnung widerruft. [<=]

Versicherte haben die Möglichkeit für sie im Fachdienst gespeicherte Rechnungen zu löschen.

A_25921 - Digitale Patientenrechnung Fachdienst – Löschen von Rechnungen durch den Versicherten

Der Digitale Patientenrechnung Fachdienst MUSS es Versicherten ermöglichen, ihre Rechnungen im Digitale Patientenrechnung Fachdienst zu löschen. [<=]

Datenminimierung

A_25915 - Digitale Patientenrechnung Fachdienst – Zweckbestimmte Verarbeitung von Daten

Der Digitale Patientenrechnung Fachdienst DARF NICHT Daten verarbeiten, die nicht dem rechtmäßigen Zweck der Anwendung dienen. [<=]

Die Anforderungen zu Löschfristen sind im Abschnitt 5.1.2 Löschfristen formuliert.

#### 5.1.1 Protokollierung für die Versicherten

Der Digitale Patientenrechnung Fachdienst führt Nutzerprotokolle für die Versicherten, in denen alle Zugriffe auf die personenbezogenen (medizinischen) Daten eines Versicherten für den Versicherten einsehbar sind. Diese Nutzerprotokolle sind unabhängig von technischen Protokollen und stehen ausschließlich dem Versicherten zur Wahrnehmung seiner Betroffenenrechte zur Einsicht zur Verfügung.

Die Anforderungen zum Nutzerprotokoll sind im Abschnitt 5.1.6 Nutzerprotokoll formuliert.

#### 5.1.2 Löschfristen

Der Digitale Patientenrechnung Fachdienst soll datensparsam umgesetzt werden. Das bedeutet, dass personenbezogene Daten und nicht mehr benötigte Daten nach folgend definierten Fristen gelöscht werden.

##### 5.1.2.1 Nutzerkonten

A_25675 - Digitale Patientenrechnung Fachdienst - Löschfristen - Nutzerkonten - Löschfrist inaktiver Nutzerkonten

Der Digitale Patientenrechnung Fachdienst MUSS Nutzerkonten sowie deren verknüpften Daten, Dokumente, Workflows und Protokolle automatisch zum Ende des laufenden Monats löschen, wenn diese 3 Jahre inaktiv waren. [<=]

A_25676 - Digitale Patientenrechnung Fachdienst - Löschfristen - Nutzerkonten - Benachrichtigung vor Löschung

Der Digitale Patientenrechnung Fachdienst MUSS den Nutzer automatisch 3 Monate vor der Löschung des Nutzerkontos per Benachrichtigung über diese informieren, so dass dieser sich anmelden kann, um die Löschung zu vermeiden. [<=]

A_25682 - Digitale Patientenrechnung Fachdienst - Löschfristen - Nutzerkonten - Erinnerung vor Löschung

Der Digitale Patientenrechnung Fachdienst MUSS den Nutzer automatisch 2 Wochen vor der Löschung des Nutzerkontos per Benachrichtigung an die bevorstehende Löschung erinnern. [<=]

##### 5.1.2.2 Rechnungen und Dokumente

A_25677 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Papierkorb für OFFEN

Der Digitale Patientenrechnung Fachdienst MUSS Rechnungen 3 Jahre nach der Rechnungserstellung automatisch zum nächsten Jahresende in den Status PAPIERKORB ändern. [<=]

A_25678 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Verlängerung durch Statuswechsel in OFFEN

Der Digitale Patientenrechnung Fachdienst MUSS Rechnungen 3 Jahre nach Wechsel in den Status OFFEN zum nächsten Jahresende automatisch in den Status PAPIERKORB ändern. [<=]

A_26132 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Papierkorb für ERLEDIGT

Der Digitale Patientenrechnung Fachdienst MUSS Rechnungen ein Jahr nach Wechsel in den Status ERLEDIGT zum nächsten Monatsende automatisch in den Status PAPIERKORB ändern. [<=]

A_25833 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Gesamtaufbewahrungsdauer

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Rechnungen trotz Verlängerungen der Löschfrist spätestens 10 Jahre nach Erstellung automatisch endgültig gelöscht werden. [<=]

A_25679 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Löschen

Der Digitale Patientenrechnung Fachdienst MUSS Rechnungen sowie die verknüpften, strukturierten Daten und Dokumente 3 Monate nach dem Wechsel in den Status PAPIERKORB zum nächsten Monatsende automatisch löschen. [<=]

A_25694 - Digitale Patientenrechnung Fachdienst - Löschfristen - Rechnungen und Dokumente - Benachrichtigung vor Löschung

Der Digitale Patientenrechnung Fachdienst MUSS den Nutzer bei einem Wechsel in den Status PAPIERKORB per Benachrichtigung über diese informieren, so dass dieser die Löschfrist verlängern kann. [<=]

A_25695 - Digitale Patientenrechnung Fachdienst -Löschfristen - Rechnungen und Dokumente - Erinnerung vor Löschung

Der Digitale Patientenrechnung Fachdienst MUSS den Nutzer automatisch 2 Wochen vor der Löschung von Rechnungen in dem Status PAPIERKORB per Benachrichtigung an die bevorstehende Löschung erinnern. [<=]

#### 5.1.3 Vertrauenswürdige Ausführungsumgebung

In diesem Abschnitt werden die Anforderungen an den Digitale Patientenrechnung Fachdienst (DiPag FD) zur Umsetzung einer Vertrauenswürdigen Ausführungsumgebung (VAU) dargestellt. Die VAU dient der datenschutzrechtlich zulässigen und sicheren Verarbeitung von schützenswerten Klartextdaten innerhalb des DiPag FD sowie dem technischen Ausschluss der Profilbildung durch den Anbieter bzw. Betreiber. Die VAU stellt dazu Verarbeitungskontexte (d. h. Instanzen der VAU) bereit, in denen die Verarbeitung sensibler Daten im Klartext erfolgen kann. Diese Verarbeitungskontexte sind entsprechend zu schützen.

##### 5.1.3.1 Verarbeitungskontext

Die Gesamtheit aus der für eine Klartextverarbeitung erforderlichen Software, dem für eine Klartextverarbeitung genutzten physikalischen System sowie den für die Integrität einer Klartextverarbeitung erforderlichen organisatorischen und physischen Rahmenbedingungen bildet den Verarbeitungskontext der Vertrauenswürdigen Ausführungsumgebung.

Zur VAU gehören neben den Verarbeitungskontexten alle für ihre Erreichbarkeit und betriebliche Steuerung erforderlichen Komponenten.

Der Verarbeitungskontext grenzt sich von allen weiteren, im betrieblichen Kontext beim Anbieter des Digitale Patientenrechnung -Fachdienstes vorhandenen Systemen und Prozessen dadurch ab, dass die sensiblen Klartextdaten von Komponenten innerhalb des Verarbeitungskontextes aus erreichbar sind oder sein können, während sie dies von außerhalb des Verarbeitungskontextes nicht sind. Sensible Daten verlassen den Verarbeitungskontext ausschließlich gemäß wohldefinierten (Zugriffs-)Regeln und in verschlüsselter Form.

A_27407 - Digitale Patientenrechnung Fachdienst - Verarbeitungskontext der VAU

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS sämtliche physikalischen Systemkomponenten sowie sämtliche Softwarekomponenten umfassen, deren Sicherheitseigenschaften sich auf den Schutz der personenbezogenen medizinischen Daten vor Zugriff durch Unbefugte bei ihrer Verarbeitung im Klartext auswirken können. [<=]

##### 5.1.3.2 Verarbeitung schützenswerter Daten

A_27464 - Digitale Patientenrechnung Fachdienst - Klartext-Datenverarbeitung ausschließlich im Verarbeitungskontext

Der Digitale Patientenrechnung Fachdienst MUSS technisch sicherstellen, dass eine Klartext-Verarbeitung von schützenswerten Daten ausschließlich innerhalb eines Verarbeitungskontextes erfolgt. [<=]

A_27465 - Digitale Patientenrechnung Fachdienst - Isolation zwischen Datenverarbeitungsprozessen

Der Digitale Patientenrechnung Fachdienst MUSS technisch sicherstellen, dass Datenverarbeitungsprozesse einer Client-Session keinen Zugriff auf Datenverarbeitungsprozesse einer anderen Client-Session ermöglichen können und je nach gewählter Form der Umsetzung von Client-Sessions (bspw. als Thread eines http-Servers) eine entsprechend gehärtete Implementierung einsetzen. [<=]

Hinweis: Im Falle des Digitale Patientenrechnung Fachdienstes wird seitens der gematik von einem Verarbeitungskontext ausgegangen, der einen HTTP-Server enthält und gleichzeitig viele Client-Sessions halten kann. Client-Requests sind dabei auf der Ebene von Threads isoliert.

A_27466 - Digitale Patientenrechnung Fachdienst - Löschen aller schützenswerten Daten beim Beenden eines Verarbeitungskontextes

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS sicherstellen, dass beim Beenden eines Verarbeitungskontextes sämtliche schützenswerten Daten dieses Verarbeitungskontextes aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist. [<=]

##### 5.1.3.3 Persistierung schützenswerter Daten

A_27408 - Digitale Patientenrechnung Fachdienst - Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS sicherstellen, dass sämtliche schützenswerten Daten vor einer Speicherung außerhalb der VAU verschlüsselt werden. Der Verarbeitungskontext MUSS dazu mindestens einmal pro Sekunde den verwendeten Schlüssel wechseln, so dass nur die innerhalb einer Sekunde neu angelegten Digitale Patientenrechnungen mit einem Schlüssel verschlüsselt werden. [<=]

Hinweise: Für für eine effiziente Suche in den verschlüsselten Daten dürfen "Blind Indices" genutzt werden, wenn die betreffende Datenmenge für eine Suche innerhalb der VAU zu groß ist. Nicht alle Daten, die persistiert werden, sind schützenswert. So dürfen z.B. die Zeitpunkte von (ansonsten verschlüsselten) Nutzerprotokolleinträgen im Klartext gespeichert werden.

A_27409 - Digitale Patientenrechnung Fachdienst - Ableitung der Persistenzschlüssel durch ein HSM

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS die zur Verschlüsselung der persistierten Digitale Patientenrechnungsdaten verwendeten Schlüssel von einem HSM abrufen, in dem mindestens eine Partition ausschließlich für die Verwendung mit der VAU des Digitale Patientenrechnung Fachdienstes konfiguriert ist.
[<=]

A_27410 - Digitale Patientenrechnung Fachdienst - Ableitung der Persistenzschlüssel aus Merkmal der Digitale Patientenrechnungen

Das HSM der VAU des Digitale Patientenrechnung Fachdienstes MUSS eine Schnittstelle zur Ableitung von symmetrischen Schlüsseln für die Persistierung von Digitale Patientenrechnungsdaten bereitstellen. Das HSM der VAU des Digitale Patientenrechnung Fachdienstes MUSS zur Ableitung des jeweiligen Schlüssels einen bei der ersten Erstellung im Verarbeitungskontext ermittelten und anschließend unveränderlichen Zeitstempel des jeweiligen zu speichernden Datensatzes als Ableitungsparameter verwenden.
[<=]

Hinweis: Eine grobe Abschätzung nach oben ergibt eine maximale Zahl von Persistenzoperationen für Rechnungsdatensätze von 50 pro Sekunde. Dies definiert eine obere Schranke für die mit einem Persistenzschlüssel gesicherten Datensätze in der Datenbank. Der Mechanismus ist unabhängig von der relationalen Struktur der Datensätze. Die Persistenzschlüssel werden mittels einer Key Derivation Function unter Verwendung des Zeitstempels (auf eine Sekunde abgerundet) als Parameter abgeleitet. Die Rekonstruktion der Schlüssel für den Lesezugriff erfolgt auf der Grundlage des im Klartext als Teil der Datensätze mit gespeicherten Zeitstempels.

##### 5.1.3.4 Transport schützenswerter Daten

A_25908 - Digitale Patientenrechnung Fachdienst - Schutz der in die VAU des Fachdienstes transportierten Daten

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass die Kommunikation zwischen Clients und dem Digitale Patientenrechnung Fachdienst ausschließlich authentisiert, vertraulich und integritätsgeschützt erfolgt. [<=]

Für den Ausschluss des Anbieters/Betreibers des Digitale Patientenrechnung Fachdienstes vom Zugriff auf die zwischen Clients und Digitale Patientenrechnung Fachdienst transportierten personenbezogenen medizinischen Daten muss der Endpunkt dieser Kommunikation in der Vertrauenswürdigen Ausführungsumgebung (VAU) des Digitale Patientenrechnung Fachdienstes liegen.

A_25909 - Digitale Patientenrechnung Fachdienst - Endpunkt der Transportsicherung in der VAU des Fachdienstes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass der Endpunkt der transportgeschützten Kommunikation zwischen Clients und dem Digitale Patientenrechnung Fachdienst in der VAU liegt. [<=]

A_25910 - Digitale Patientenrechnung Fachdienst - Schutz der innerhalb des Fachdienstes transportierten Daten

Der Anbieter des Digitale Patientenrechnung Fachdienstes MUSS die zwischen den Komponenten des Digitale Patientenrechnung Fachdienstes auszutauschenden Daten vertraulich und integritätsgeschützt übertragen. [<=]

A_25912 - Digitale Patientenrechnung Fachdienst - Umsetzung der Operationen für das Protokoll der Versicherten in einer VAU

Der Digitale Patientenrechnung Fachdienst MUSS die Verarbeitung aller Operationen des Fachdienstes für das Protokoll der Versicherten in einer VAU umsetzen. [<=]

Hinweis: für die Qualität der Transportverschlüsselung gelten die Anforderungen aus [gemSpec_Krypt].

A_27422-01 - Digitale Patientenrechnung Fachdienst - Sicherer Kanal vom Client zum Verarbeitungskontext der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS den Aufbau eines vertraulichen und integritätsgeschützten Kommunikationskanals gemäß [gemSpec_Krypt#8] zwischen einem Client und einem Verarbeitungskontext erzwingen, bevor der Verarbeitungskontext seine fachlichen Schnittstellen für den Client nutzbar macht. [<=]

A_27411-01 - Digitale Patientenrechnung Fachdienst - Authentisierung gegenüber Clients

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS sich gegenüber Clients, die mit ihm kommunizieren, mittels der Fachdienstidentität oid_dipag-vau mit Zertifikatsprofil C.FD.AUT (oid_fd_aut) ausweisen. [<=]

A_27412 - Digitale Patientenrechnung Fachdienst – Isolation zwischen Datenverarbeitungsprozessen der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS die in ihr ablaufenden Verarbeitungen für die Daten einer Client-Session von den Verarbeitungen für die Daten anderer Client-Sessions in solcher Weise trennen, dass mit technischen Mitteln ausgeschlossen ist, dass aus einer (ggf. kompromittierten) Client-Session auf Daten einer anderen Client-Session zugegriffen werden kann. [<=]

Um Verbindungen vom Digitale Patientenrechnung Client zum Verarbeitungskontext zu ermöglichen, ist ein der VAU vorgelagertes Routing ausgehend von einem netztechnischen Eingangspunkt (z. B. in Form eines TLS-terminierenden Load Balancers) erforderlich. Der Eingangspunkt vermittelt die Verbindungen zwischen dem Client und dem jeweils benötigten Verarbeitungskontext.

A_27425 - Digitale Patientenrechnung Fachdienst - Verarbeitungskontexte der VAU über gemeinsame Host-Adressen erreichbar

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS ihre Verarbeitungskontexte über gemeinsame IP-Adressen und Ports des Eingangspunkts des Fachdienstes erreichbar machen. [<=]

A_27427 - Digitale Patientenrechnung Fachdienst - Automatisierter Abbau des sicheren Kanals

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS den sicheren Kanal zu einem Client nach Abschluss einer fachlichen Operation (die aus mehreren Requests bestehen kann) abbauen, sodass anschließend keine Zugriffe dieses Clients auf den Verarbeitungskontext mehr möglich sind, ohne dass eine neue Verbindung aufgebaut wird. [<=]

##### 5.1.3.5 Schutz der Integrität der VAU

A_27454 - Digitale Patientenrechnung Fachdienst - Remote Attestation beim Start eines Verarbeitungskontextes

Der Verarbeitungskontext des Digitale Patientenrechnung Fachdienstes MUSS unmittelbar nach seinem Start gegenüber einem Attestationsdienst der VAU nachweisen, dass er aus einem autorisierten und unveränderten VAU-Image initialisiert wurde. [<=]

Hinweis: Der Verarbeitungskontext wird als ein "VAU-Image" geladen. Hierbei kann es sich um ein VM-Image oder einen Container o. Ä. handeln. Ein VAU-Image kann nur erfolgreich attestiert werden, wenn seine Attestationsmesswerte (Hashwert des Images im Arbeitsspeicher, bestimmte Konfigurationseinstellungen des Hosts bzw. der CPU, Signer-ID der CPU bzw. des TPM, etc.) zuvor beim Attestationsdienst als gültige Referenzwerte registriert wurden.

A_27471 - Digitale Patientenrechnung Fachdienst - Betreiber-unabhängiger Root of Trust for Measurement

Der Betreiber der Infrastruktur des Digitale Patientenrechnung Fachdienstes MUSS attestationsfähige Server-Hardware einsetzen, die erzeugte Attestation-Reports mit in der Hardware verankertem Schlüsselmaterial signiert, das nicht in der Hoheit des Betreibers liegt. [<=]

Hinweis: Dies können Schlüssel in den CPUs der Server handeln (z. B. Intel Root of Trust for Measurement) oder in TPMs sein.

A_27472 - Digitale Patientenrechnung Fachdienst - Kontrollierte Lieferkette für VAU-Server

Der Betreiber der Infrastruktur des Digitale Patientenrechnung Fachdienstes MUSS Maßnahmen ergreifen, die das Risiko einer Kompromittierung der Hardware, der Firmware oder des integrierten Schlüsselmaterials der VAU-Server in der Lieferkette minimieren und diese im Rahmen seiner Supply Chain Security dokumentieren. [<=]

A_27455 - Digitale Patientenrechnung Fachdienst - Erfolgreiche Attestation als Vorbedingung für Zugriff des Verarbeitungskontextes auf Schlüsselmaterial

Der Remote Attestation Mechanismus des Digitale Patientenrechnung Fachdienstes MUSS gewährleisten, dass Verarbeitungskontexte erst nach erfolgreichem Nachweis ihrer Autorisierung und Integrität gegenüber dem Attestationsdienst die Möglichkeit zum Zugriff auf das für die Authentisierung als Digitale Patientenrechnung Fachdienst gegenüber Clients oder das Ver- bzw. Entschlüsseln der schützenswerten persistenten Daten erforderliche Schlüsselmaterial erlangen. [<=]

A_27467 - Digitale Patientenrechnung Fachdienst - Sichere Verbindung zwischen Verarbeitungskontext und Attestationsdienst

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS technisch sicherstellen, dass zwischen einem Verarbeitungskontext der VAU und dem Attestationsdienst eine beidseitig authentisierte und vertrauliche Verbindung besteht, die auch gegen Zugriffe durch den Anbieter des Fachdienstes bzw. den Betreiber der Infrastruktur schützt. [<=]

A_27468 - Digitale Patientenrechnung Fachdienst - Sichere Verbindung zwischen Verarbeitungskontext und HSM

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS technisch sicherstellen, dass Verbindungen zwischen einem Verarbeitungskontext der VAU und dem HSM, die für die Nutzung von für den Verarbeitungskontext erforderlichem Schlüsselmaterial benötigt werden, beidseitig authentisiert und vertraulich sind und auch gegen Zugriffe durch den Anbieter des Fachdienstes bzw. den Betreiber der Infrastruktur schützen. [<=]

A_27469 - Digitale Patientenrechnung Fachdienst - Sichere Verbindung zwischen Attestationsdienst und HSM

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS technisch sicherstellen, dass nur der im Rahmen der Einrichtung der VAU im 4-Augen-Prinzip mit der gematik autorisierte Attestationsdienst Zugriff auf das für ihn erforderliche Schlüsselmaterial im HSM erhalten kann. [<=]

A_27456 - Digitale Patientenrechnung Fachdienst - Registrierung von Referenzwerten im 4-Augen Prinzip

Der Anbieter des Digitale Patientenrechnung Fachdienstes MUSS die Registrierung von Referenzwerten für die Attestation von Verarbeitungskontexten unter Beteiligung der gematik in solcher Weise durchführen, dass unautorisierte Veränderungen seitens des Betreibers oder des Herstellers der VAU-Images ausgeschlossen sind. [<=]

A_27470 - Digitale Patientenrechnung Fachdienst - Regelmäßiger Neustart von Verarbeitungskontexten

Der Digitale Patientenrechnung Fachdienst MUSS Instanzen des Verarbeitungskontextes der VAU spätestens eine Stunde nach ihrem jeweiligen Start neu starten, um die Attestation zu erneuern, ohne dass dies bestehende User Sessions terminiert und ohne dass laufende Transaktionen unterbrochen werden. [<=]

Hinweis: Im Falle der für den Digitale Patientenrechnung Fachdienst vorgesehenen Architektur des Verarbeitungskontextes als Cluster von regulären (gehärteten) Web-Servern werden User Sessions über einen verteilten (verschlüsselten) Cache vom Lebenszyklus der einzelnen Web-Server-Instanz entkoppelt. Der Verarbeitungskontext muss daher lediglich dafür sorgen, dass sich keine offenen Transaktionen mehr in der Verarbeitung befinden, wenn der Neustart erfolgt. Hierzu kann es erforderlich sein, dass der vorgeschaltete Load Balancer den Ablauf unterstützt, indem er ab einem gewissen Zeitpunkt vor dem geplanten Neustart keine weiteren Requests mehr an eine Instanz des Web-Servers ausliefert.

A_28479 - Digitale Patientenrechnung Fachdienst - Dedizierte Hosts für Verarbeitungskontexte

Der Digitale Patientenrechnung Fachdienst MUSS Instanzen des Verarbeitungskontextes der VAU auf Hardware-Ressourcen ausführen, die ausschließlich nur Verarbeitungskontexte von Vertrauenswürdigen Ausführungsumgebungen zugelassener TI-Dienste ausführen und dies mittels technischer Mechanismen bzw. Richtlinien sicherstellen. [<=]

Hinweis: Ob Verarbeitungskontexte anderer TI-Dienste neben den Verarbeitungskontexten des Digitale Patientenrechnung Fachdienstes ausgeführt werden können, hängt davon ab, ob diese anderen TI-Dienste dies gestatten.

##### 5.1.3.6 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld

Der Schutzbedarf der im Verarbeitungskontext der VAU verarbeiteten Klartextdaten erfordert den technischen Ausschluss von Zugriffen des Anbieters. Dies umfasst insbesondere Zugriffe durch Personen aus dem betrieblichen Umfeld des Anbieters.

A_27413 - Digitale Patientenrechnung Fachdienst - Isolation der VAU von Datenverarbeitungsprozessen des Anbieters und des Betreibers

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS die in ihren Verarbeitungskontexten ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Anbieters und des Betreibers der zugrundeliegenden Infrastruktur trennen und damit gewährleisten, dass der Anbieter und der Betreiber des Digitale Patientenrechnung Fachdienstes vom Zugriff auf die in der VAU verarbeiteten schützenswerten Daten ausgeschlossen ist. [<=]

Hinweis: Für die Separation zwischen Verarbeitungskontexten und Verarbeitungsprozessen des Anbieters und des Bertreibers, die der betrieblichen Steuerung des Systems dienen, ist eine Low-Level Separation anzustreben, da - im Unterschied zur Separation zwischen Verarbeitungskontexten - hier technisch sehr verschiedene Aspekte getrennt werden müssen.

A_27414 - Digitale Patientenrechnung Fachdienst - Ausschluss von Manipulationen an der Software der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS eine Manipulation der eingesetzten Software erkennen und eine Ausführung der manipulierten Software verhindern. [<=]

A_27415 - Digitale Patientenrechnung Fachdienst - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS die Integrität der eingesetzten Hardware schützen und damit insbesondere Manipulationen an der Hardware durch den Anbieter des Digitale Patientenrechnung-Fachdienstes ausschließen. [<=]

Hinweis: Der Anbieter kann z. B. folgende Maßnahmen ergreifen: Sicherer Betrieb des RZ, organisatorische Prozesse zur Überwachung von Aktivitäten des Personals im RZ, Gehäuse mit Manipulationsschutz, verschlossene Rack-Schränke ggf. mit Alarmierung, Überwachungspersonal getrennt vom Betriebspersonal (sollte mindestens Manipulationen erkennen, besser: verhindern können.

A_27416 - Digitale Patientenrechnung Fachdienst - Kontinuierliche Wirksamkeit des Manipulationsschutzes der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS den Ausschluss von Manipulationen an der Hardware und der Software durch den Anbieter des Digitale Patientenrechnung Fachdienstes mit Mitteln umsetzen, deren dauerhafte und kontinuierliche Wirksamkeit gewährleistet werden kann. [<=]

A_27417 - Digitale Patientenrechnung Fachdienst - Kein physischer Zugang des Anbieters zu Systemen der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS mit technischen Mitteln sicherstellen, dass niemand, auch nicht der Anbieter des Digitale Patientenrechnung-Fachdienstes oder der Betreiber der den Fachdienst ausführenden Infrastruktur, unerkannt während der Verarbeitung personenbezogener medizinischer Daten Zugriff auf physische Schnittstellen der Systeme erlangen kann, auf denen eine VAU ausgeführt wird. [<=]

Hinweis: Siehe auch Hinweis zu A_27415. Zur Umsetzung dieser Anforderung sind die Server im besten Fall so konstruiert, dass sie keine offenen Schnittstellen haben. Server, an denen gearbeitet werden muss, müssen vorab aus der Verarbeitung genommen werden. Hierzu sollen geeignete organisatorische Prozesse definiert und dokumentiert sein, die für Innentäter nur schwer und unter hohem Risiko einer Entdeckung zu umgehen sind.

A_27418 - Digitale Patientenrechnung Fachdienst - Nutzdatenbereinigung vor physischem Zugang zu Systemen der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS mit technischen Mitteln sicherstellen, dass physischer Zugang zu Hardware-Komponenten der Verarbeitungskontexte nur erfolgen kann, nachdem gewährleistet ist, dass aus ihnen keine Nutzdaten extrahiert werden können. [<=]

A_27419 - Digitale Patientenrechnung Fachdienst - Private Schlüssel von Dienstzertifikaten im HSM

Der Digitale Patientenrechnung Fachdienst MUSS die folgenden privaten Schlüssel in einem Hardware Security Module (HSM) erzeugen und anwenden:

- Privater Schlüssel (PrK.FD.ENC) des Schlüsselpaars zur Authentisierung des Verarbeitungskontextes gegenüber dem Digitale Patientenrechnung Frontend des Versicherten (DiPag FdV) und Primärsystemen (sicherer Kanal auf Anwendungsebene).

Die Prüftiefe des HSM MUSS dabei den in A_27420 angegebenen Standards entsprechen. [<=]

Hinweis: Die TLS-TI-Fachdienst-Identität kann z. B. auf einem außerhalb der VAU betriebenen Load Balancer mit TLS-Terminierung verwendet werden.

A_27420 - Digitale Patientenrechnung Fachdienst - Einsatz zertifizierter HSM

Der Anbieter des Digitale Patientenrechnung Fachdienstes MUSS beim Einsatz eines HSM sicherstellen, dass dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria, ITSEC oder Federal Information Processing Standard (FIPS) in Frage.
Die Prüftiefe MUSS mindestens:

1. FIPS 140-2 Level 3,
2. Common Criteria EAL 4+ mit hohem Angriffspotenzial oder
3. ITSEC E3 der Stärke „hoch“ entsprechen.

[<=]

A_27421 - Digitale Patientenrechnung Fachdienst - HSM-Kryptographieschnittstelle verfügbar nur für Instanzen der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS mit technischen Mitteln, die auch Manipulationen durch den Anbieter des Digitale Patientenrechnung Fachdienstes ausschließen, gewährleisten, dass nur Instanzen der VAU Zugriff auf die Kryptographieschnittstelle des HSM zur Nutzung des privaten Schlüsselmaterials für ihre Dienstzertifikate erhalten können. [<=]

Hinweis: Falls die Verarbeitungskontexte als Threads, Workers, o. Ä. umgesetzt sind und daher gemeinsam in einem übergreifenden Anwendungsprozess ausgeführt werden, kann dieser Anwendungsprozess eine authentisierte Verbindung zur Kryptograhieschnittstelle des HSM herstellen und aufrecht erhalten, um darüber die Kryptographieschnittstelle des HSM den Verarbeitungskontexten (und nur diesen) lokal zur Verfügung zu stellen.

##### 5.1.3.7 Einbinden des ZETA Guard der gematik

Der Digitale Patientenrechnung Fachdienst verwendet als TI 2.0-Service die Mechanismen des Zero Trusts für die Zugriffskontrolle. Dazu wird von der gematik zentral ein Software-Image für den ZETA Guard bereitgestellt, der von den Diensten der TI 2.0 eingebunden wird.

Da der von der gematik bereitgestellte ZETA Guard ein reines Docker-Image ist, muss es vom Hersteller des Digitale Patientenrechnung Fachdienstes in die Lage versetzt werden, als VAU-Image in der VAU des Digitale Patientenrechnung Fachdienstes importiert werden zu können und dort lauffähig zu sein.

Der ZETA Guard ist also so im Build-Prozess zu berücksichtigen, dass dieser ohne manuelle Anpassungen am Code automatisiert integriert werden kann. Da häufige Updates des ZETA Guard zu erwarten sind (insbesondere schnelle Patches bei neuen, relevanten CVE), ist ein manueller Anpassungsprozess zur Herstellung der Kompatibilität des ZETA Guard zur VAU des Digitale Patientenrechnung Fachdienstes inakzeptabel.

Im Folgenden wird das System, dass den Prozess zur Erzeugung von VAU-Images umsetzt und dabei automatisiert den ZETA Guard einbindet VAU-Image-Build-Pipeline genannt.

A_27583 - Digitale Patientenrechnung Fachdienst - Bereitstellung VAU-Image-Build-Pipeline und automatisiertes Einbinden des ZETA Guard

Der Hersteller des Digitale Patientenrechnung Fachdienst MUSS eine VAU-Image-Build-Pipeline bereitstellen und nutzen, von der:

1. das seitens gematik bereitgestellte ZETA Guard-Image entgegengenommen wird, wobei:

1. die gematik-Signatur des Images gegen den als vertrauenswürdig hinterlegten gematik-Signatur-Prüfschlüssel verifiziert wird und
2. das Image genau nur bei erfolgreicher Signaturprüfung übernommen wird,

und anschließend automatisiert:

1. entweder aus der Digitale Patientenrechnung Fachdienst-Logik und dem ZETA Guard-Image ein gemeinsames VAU-Image erzeugt wird
2. oder aus jeweils Digitale Patientenrechnung Fachdienst-Logik und ZETA Guard-Image ein eigenes VAU-Image erzeugt wird, wobei in jedes VAU-Image ein Vertrauensanker für die Authentifizierung anderer Verarbeitungskontexte hinterlegt wird,

und anschließend automatisiert:

1. zu jedem VAU-Image der signierte Attestierungswert mit der gleichen Methodik/Technik ermittelt wird, wie sie auch in der VAU im Betrieb verwendet wird und
2. das/die VAU-Image(s) und die dazugehörigen signierten Attestierungswerte ausgegeben werden.

[<=]

Hinweis: Der in der zweiten Variante ("oder") genannte Vertrauensanker wird bei der gegenseitigen Authentifizierung bei der Kommunikation Verarbeitungskontext-zu-Verarbeitungskontext verwendet. Die Identitäten des jeweiligen Verarbeitungskontextes und die ausstellende CA sind auf dem HSM der VAU gespeichert und werden bei der initialen Zeremonie erzeugt. Dabei wird der öffentliche Schlüssel der CA exportiert, der dann als Vertrauensanker in die VAU-Images eingebracht wird. Die Authentifizierung eines anderen Verarbeitungskontext ist in ersterer Variante ("entweder") nicht notwendig, da die Kommunikation ZETA Guard<=>Digitale Patientenrechnung Fachdienst-Logik dort innerhalb des Verarbeitungskontext stattfindet.

Ggf. ist zudem der Import eines Vertrauensankers für die Kommunikation zum HSM (Authentifizierung des HSM durch den Verarbeitungskontext) notwendig. Es kann hier dieselbe Certification Authority (CA) verwendet werden. Grundsätzlich sind aber auch andere Methoden zur Etablierung eines beidseitig authentisierten Kanals zwischen Verarbeitungskontext und HSM möglich, solange der Verarbeitungskontext das HSM eindeutig authentifizieren kann.

Die VAU-Image-Build-Pipeline muss im Rahmen der Produkt-Begutachtung des Digitale Patientenrechnung Fachdienstes geprüft werden. Der ZETA Guard selbst hat einen von der gematik abgenommenen Sicherheitsnachweis (Produktgutachten). Daher muss dieser bei dem beschriebenen Vorgehen nicht noch einmal sicherheitstechnisch betrachtet werden.

A_27584 - Digitale Patientenrechnung Fachdienst – Sichere VAU-Image-Erzeugung (Prozess)

Der Hersteller des Digitale Patientenrechnung Fachdienst MUSS einen sicheren Gesamtprozess zur VAU-Image-Erzeugung umsetzen und dabei:

1. die geprüfte VAU-Image-Build-Pipeline nutzen,
2. im 4-Augen-Prinzip abgesichert den gematik-Signaturprüfschlüssel für den ZETA Guard in die VAU-Image-Build-Pipeline einbringen und
3. Abwehrmaßnahmen gegen Manipulationen der VAU-Image-Build-Pipeline durch einen Innentäter umsetzen, was auch das Verhindern des unberechtigten Einbringens von Signatur-Prüfschlüsseln umfasst.

[<=]

##### 5.1.3.8 Konsistenz des Systemzustands, Logging und Monitoring

A_27423 - Digitale Patientenrechnung Fachdienst - Konsistenter Systemzustand des Verarbeitungskontextes der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS sicherstellen, dass ein konsistenter Zustand des Verarbeitungskontextes auch bei Bedienfehlern oder technischen Problemen immer erhalten bleibt bzw. wiederhergestellt werden kann. [<=]

A_27424 - Digitale Patientenrechnung Fachdienst - Datenschutzkonformes Logging und Monitoring des Verarbeitungskontextes der VAU

Die VAU des Digitale Patientenrechnung Fachdienstes MUSS die für den Betrieb eines Fachdienstes erforderlichen Logging- und Monitoring-Informationen in solcher Art und Weise erheben und verarbeiten, dass mit technischen Mitteln ausgeschlossen ist, dass dem Anbieter des Digitale Patientenrechnung Fachdienstes oder Dritten vertrauliche oder zur Profilbildung geeignete Daten zur Kenntnis gelangen. [<=]

A_25815-01 - Digitale Patientenrechnung Fachdienst - Funktionsmerkmale - Duplikatserkennung

Der Digitale Patientenrechnung Fachdienst MUSS im MVP eine übermittelte Rechnung ablehnen, falls die Identität der Rechnung mit einer schon übermittelten Rechnung übereinstimmt. Das Identifizierende Merkmal einer Rechnung ist folgender Hash-Wert:

1. Der FD decodiert das Base-64-codierte Original-Rechnungs-PDF und bildet den SHA-256-Hashwert über das decodierte PDF: Hash A
2. Der FD decodiert die Base-64-codierten strukturierten Rechnungsdaten und bildet den SHA-256-Hashwert über das decodierte FHIR-JSON-Dokument: Hash B
3. Der FD bildet den SHA-256-Hashwert über die Konkatenation aus Hash A und Hash B: identifizierender Hash-Wert.

Bei der Ablehnung MUSS der FD dem übermittelnden System mitteilen, zu welchem Zeitpunkt diejenige Rechnung im FD gespeichert wurde, zu der die abgelehnte Rechnung ein Duplikat darstellt. [<=]

Hinweis: Für Anhangsdokumente gibt es im MVP keine Duplikatserkennung

A_27458 - Digitale Patientenrechnung Fachdienst - Funktionsmerkmale - Vermeidung von Duplikaten aufgrund technischer Fehler

Falls der Rechnungsersteller ein Dokument an den Digitale Patientenrechnung Fachdienst übersendet und der Fachdienst die erfolgreiche Übermittlung aus technischen Gründen nicht bestätigen kann, dann MUSS der Fachdienst verhindern, dass durch das erneute Übertragen von Dokumenten Duplikate entstehen. [<=]

#### 5.1.4 Dateigrößen

Beim Austausch und Speicherung von Dokumenten müssen Dateigrößenbeschränkungen eingehalten werden. Diese gelten sowohl für einzelne Dokumente als auch die Kombination von Rechnungen und ihren ergänzenden Dokumenten.

A_25975 - Digitale Patientenrechnung Fachdienst - Dateigrößen - Maximale Größe einzelnes Dokument

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass einzelne Rechnungsdokumente und sonstige Dokumente nur bis zu einer maximalen Dateigröße von 10 MB in Übertragungen akzeptiert und gespeichert werden. [<=]

A_25976 - Digitale Patientenrechnung Fachdienst - Dateigrößen - Maximale Größe zusammengehörige Dokumente

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Kombinationen aus Rechnungsdokument und dessen ergänzenden Dokumente nur bis zu einer maximalen Dateigröße von 50 MB in Übertragungen akzeptiert und gespeichert werden. [<=]

#### 5.1.5 Dokumentenformate

A_25731-01 - Digitale Patientenrechnung Fachdienst - Dokumentenformate - Dokumente

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass ausschließlich die folgenden PDF/A-Formate nach [ISO 19005] akzeptiert werden:

- PDF/A-1a
- PDF/A-1b
- PDF/A-2a
- PDF/A-2u
- PDF/A-2b

Der Digitale Patientenrechnung Fachdienst MUSS das Dokumentenformat validieren und bei Validierungsfehlern ablehnen. [<=]

A_25736-01 - Digitale Patientenrechnung Fachdienst - Dokumentenformate - Angereichertes PDF

Der Digitale Patientenrechnung Fachdienst MUSS das angereicherte PDF im PDF/A-3 Format nach [ISO 19005] Abschnitt ISO 19005-3 erstellen. Die jeweilige Konformitätsstufe des PDF/A-3 entspricht dabei der Konformitätsstufe des Original-Dokuments, auf dem das angereicherte PDF basiert. [<=]

Das Format PDF/A-3 wird für die Einreichung beim Kostenträger per Frontend (z.B. "Teilen"-Funktion) benötigt, da dieses die Einbettung der strukturierten Rechnungsdaten ermöglicht.

#### 5.1.6 Nutzerprotokoll

Der Digitale Patientenrechnung Fachdienst muss verschiedene Arten von Zugriffen protokollieren, so dass diese zu einem späteren Zeitpunkt von betroffenen Versicherten abgefragt werden können. Allgemein gefasst sind die Art des Zugriffs, der Zeitpunkt, der zugreifende Akteur, das Ergebnis des Zugriffs, welche Ressourcen betroffen sind und der Protokolleintragsersteller zu protokollieren.

A_25980 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Zugriffszeit

Der Digitale Patientenrechnung Fachdienst MUSS bei jedem Zugriff den Zeitpunkt festhalten, zu dem dieser erfolgte. [<=]

A_29995 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Löschen von Protokolleinträgen

Der Digitale Patientenrechnung Fachdienst MUSS einen gespeicherten Nutzerprotokoll-Eintrag nach 3 Jahren ab dem Zugriffszeitpunkt innerhalb von einem Monat löschen, damit veraltete Einträge nach Ende der regulären Aufbewahrungsfrist entfernt werden. [<=]

##### 5.1.6.1 Rechnungen

Für verschiedene Zugriffsarten müssen verschiedene Informationen protokolliert werden. Nachfolgend sind die zu protokollierenden Informationen beschrieben.

A_25981 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Rechnungen - Übermittlung

Der Digitale Patientenrechnung Fachdienst MUSS beim Übermitteln einer Rechnung das Erstellen, den Rechnungsersteller und die übermittelte Rechnung und, sofern vorhanden, die ergänzenden Dokumente protokollieren. [<=]

Hinweis: Im MVP des Fachdienstes erfolgt die Einreichung von Rechnungen nicht über den Fachdienst selbst, sondern über alternative Wege, z.B. die "Teilen-Funktion" des FdV. Dass eine Rechnung eingereicht wurde, kann das FdV durch Setzen der entsprechenden Markierung anzeigen. Markierungen sind daher im MVP der einzige Weg, die Einreichung im Nutzerprotokoll zu erfassen, sofern das FdV die Markierung setzt.

Automatische Aktionen des Digitale Patientenrechnung Fachdienstes müssen ebenfalls protokolliert werden. Diese Aktionen sind beispielsweise das automatische Verschieben von Rechnungen in den Papierkorb oder das automatische Löschen.

A_25983 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Rechnungen - Automatische Aktionen

Der Digitale Patientenrechnung Fachdienst MUSS bei automatischen Aktionen durch den Fachdienst selbst

- die Aktion (das Aktualisieren bzw. Löschen),
- sich selbst als Akteur und
- die betroffenen Dokumente

protokollieren. [<=]

##### 5.1.6.2 Berechtigungen

Die Erstellung und Veränderung von Berechtigungen muss ebenfalls durch den Fachdienst protokolliert werden.

A_25984 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Berechtigungen - Erstellen

Der Digitale Patientenrechnung Fachdienst MUSS bei Erstellung von Berechtigungen die Erstellung, den entsprechenden Initiator und die erstellten Berechtigungen protokollieren. [<=]

A_25985 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Berechtigungen - Bestätigung/Widerruf

Der Digitale Patientenrechnung Fachdienst MUSS bei Bestätigung oder Widerruf von Berechtigungen die Aktualisierung dieser, den entsprechenden Bestätiger und die aktualisierten Berechtigungen protokollieren. [<=]

A_25986-01 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Berechtigungen - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS bei der Abfrage von Berechtigungen das Lesen, die Abfragenden und die abgefragten Berechtigungen protokollieren.
Ausnahmen:

- Bei automatisierten Berechtigungsprüfungen, die vom Fachdienst beim Rechnungsversand durchgeführt werden, SOLL keine Protokollierung erfolgen.
- Bei Berechtigungsprüfungen die mit dem Konto der versicherten Person auf ihren eigen Daten durchgeführt werden, SOLL keine Protokollierung erfolgen

Hinweis: Durch diese Ausnahmen haben Versicherte, die ihr Nutzerprotokoll einsehen, pro Rechnungsversand immer genau einen Eintrag für die Berechtigungsprüfung im Protokoll und nicht mehrere identische. [<=]

##### 5.1.6.3 Markierungen

A_25987 - Digitale Patientenrechnung Fachdienst - Nutzerprotokoll - Markierungen - Hinzufügen/Verändern

Der Digitale Patientenrechnung Fachdienst MUSS beim Hinzufügen oder Verändern von Markierungen das Aktualisieren, die betroffenen Dokumente und die Entitäten, die für die Veränderung verantwortlich sind, protokollieren. [<=]

##### 5.1.6.4 Nutzerkonten

A_25988 - Digitale Patientenrechnung Fachdienst -Nutzerprotokoll - Nutzerkonten - Erstellen

Der Digitale Patientenrechnung Fachdienst MUSS beim Erstellen von Nutzerkonten die Erstellung, den betreffenden Nutzer und das betreffende Nutzerkonto protokollieren. [<=]

### 5.2 RESTful API

A_25847 - Digitale Patientenrechnung Fachdienst - RESTful API - Schnittstelle

Der Digitale Patientenrechnung Fachdienst MUSS seine Schnittstellen für alle Zugriffe auf alle Datenobjekte und alle Ressourcen in einer RESTful API gemäß der FHIR-Spezifikation in https://hl7.org/fhir/r4/http.html der Version v4.0.1 umsetzen. [<=]

A_25896 - Digitale Patientenrechnung Fachdienst - RESTful API - FHIR Search

Der Digitale Patientenrechnung Fachdienst MUSS in seinen Schnittstellen Suchanfragen mittels FHIR-Search gemäß der FHIR-Spezifikation in https://www.hl7.org/fhir/r4/search.html der Version v4.0.1 in dem für die Anwendungsfälle (siehe [gemF_DiPag]) benötigten Umfang umsetzen. [<=]

A_25906 - Digitale Patientenrechnung Fachdienst - RESTful API - FHIR Operations

Der Digitale Patientenrechnung Fachdienst MUSS in seinen Schnittstellen FHIR-Operations gemäß der FHIR-Spezifikation in https://hl7.org/fhir/r4/operations.html der Version v4.0.1 in dem für die Anwendungsfälle (siehe [gemF_DiPag]) benötigten Umfang umsetzen. [<=]

A_25845 - Digitale Patientenrechnung Fachdienst - RESTful API - Konsumierende Formate

Der Digitale Patientenrechnung Fachdienst MUSS in seinen Schnittstellen für Zugriffe die MimeTypes application/fhir+json und application/fhir+xml akzeptieren und verarbeiten. [<=]

A_25846 - Digitale Patientenrechnung Fachdienst - RESTful API - Produzierende Formate

Der Digitale Patientenrechnung Fachdienst MUSS in seinen Schnittstellen für Zugriffe entsprechend des HTTP-Request-Headers Accept entweder den Mime-Type application/fhir+json oder application/fhir+xml in Responsen verwenden. [<=]

A_25848 - Digitale Patientenrechnung Fachdienst - RESTful API - CapabilityStatement

Der Digitale Patientenrechnung Fachdienst MUSS eine HTTP-Route namens /metadata anbieten, bei der auf einem GET-Aufruf ein CapabilityStatement gemäß https://www.hl7.org/fhir/capabilitystatement.html zurückgeliefert werden muss, welches die vom Digitale Patientenrechnung Fachdienst beschriebenen Ressourcen und Operations auflistet. [<=]

### 5.3 FHIR-Ressourcen

A_26053-01 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Dokument-Objekt

Der Digitale Patientenrechnung Fachdienst MUSS für das Entgegennehmen von Dokument-Objekten, bestehend aus Visualisierungen und strukturierten Daten, den FHIR-Ressource-Typ DocumentReference mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-dokumentenmetadaten-eingang verwenden und für das Ausliefern von Dokument-Objekten in Such-Operationen den FHIR-Ressource-Typ DocumentReference mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-dokumentenmetadaten-intern verwenden.
[<=]

A_26054 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Rechnungsdaten

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von strukturierten Rechnungsdaten den FHIR-Ressource-Typ Invoice mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-rechnung verwenden. [<=]

A_26062 - Digitale Patientenrechnung Fachdienst - FHIR-Ressouren - Rechnungsdokument

Der Digitale Patientenrechnung-Fachienst MUSS für den Austausch des Base64-kodierten Rechnungsdokuments den FHIR-Ressource-Typ Binary mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-rechnungsdokument verwenden. [<=]

A_26055 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Rechnungsposition

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Rechnungspositionen den FHIR-Ressource-Typ ChargeItem mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-rechnungsposition verwenden. [<=]

A_26063 - Digitale Patientenrechnung Fachdienst - FHIR-Ressource - Rechnungsdiagnose

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Diagnosen in Rechnungen den FHIR-Ressource-Typ Condition mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-rechnungsdiagnose verwenden. [<=]

A_26056-01 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Versicherte

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Informationen über Versicherten den FHIR-Ressource-Typ Patient mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-patient verwenden. [<=]

A_26057-01 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Leistungserbringer

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Informationen über Leistungserbringer den FHIR-Ressource-Typ Practitioner mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-person verwenden. [<=]

A_26058-01 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Leistungserbringer-Institution

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Informationen über Leistungserbringer-Institutionen den FHIR-Ressource-Typ Organization mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-institution verwenden. [<=]

A_26059 - Digitale Patientenrechnung Fachdienst - FHIR-Ressourcen - Nutzerprotokolleintrag

Der Digitale Patientenrechnung Fachdienst MUSS für den Austausch von Einträgen des Nutzerprotokolls den FHIR-Ressource-Typ AuditEvent mit dem Profil https://gematik.de/fhir/dipag/StructureDefinition/dipag-nutzungsprotokoll verwenden. [<=]

### 5.4 FHIR-Endpunkte und -Operations

Der Digitale Patientenrechnung Fachdienst muss für verschiedene Aktionen FHIR-Endpunkte und FHIR-Operations anbieten. Diese sind nachfolgend beschrieben.

#### 5.4.1 RE-PS als Akteur

Nachfolgend beschrieben sind Anforderungen für Anwendungsfälle, in denen die Rechnungsersteller-Primärsysteme (RE-PS) die Akteure sind.

##### 5.4.1.1 Abfrage Rechnungsempfänger und dessen Einwilligung zum Rechnungsversand

A_25852 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage Rechnungsempfänger und dessen Einwilligung zum Rechnungsversand - Aufruf

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage eines Rechnungsempfängers mittels der HTTP-GET-Methode auf dem Endpunkt /Patient unterstützen, wie unter [IG DiPag RE-PS#R0] beschrieben. [<=]

A_25879 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage Rechnungsempfänger und dessen Einwilligung zum Rechnungsversand - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-GET-Anfragen auf dem Endpunkt /Patient mit Status-Codes antworten, wie unter [IG DiPag RE-PS#R0] beschrieben. [<=]

A_26028 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage Rechnungsempfänger und dessen Einwilligung zum Rechnungsversand - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage eines Rechnungsempfängers einen Claim mit der Telematik-ID des Nutzers und den Scope insurantAccount.rs enthalten und andernfalls diese abweisen. [<=]

##### 5.4.1.2 Rechnung validieren und einreichen

A_25849-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren und einreichen - Aufruf

Der Digitale Patientenrechnung Fachdienst MUSS das Einreichen und Validieren von Rechnungen mittels HTTP-POST-Methode als FHIR-Operation $invoice-submit mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/Submit auf dem Endpunkt /Patient/<id>/ unterstützen, wie unter [IG DiPag RE-PS#R1] beschrieben. [<=]

Der FD muss die syntaktischen und semantischen Prüfungen der strukturierten Rechnung durchführen, welche in AF_10136 -01 unter 'Ablauf' beschrieben sind. Andernfalls ist der Request mit 400 - Bad Request abzulehnen.

A_25880 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren und einreichen - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /Patient/<id>/ mit der Operation $dipag-submit mit Status-Codes antworten, wie unter [IG DiPag RE-PS#R1] beschrieben. [<=]

A_26029 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren und einreichen - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Einreichen und Validieren von Rechnungen einen Claim mit der Telematik-ID des Nutzers und den Scope invoiceDoc.c enthalten und andernfalls diese abweisen. [<=]

##### 5.4.1.3 Rechnung validieren/einreichen (Bulk)

A_25853 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren/einreichen (Bulk) - Aufruf

Der Digitale Patientenrechnung Fachdienst MUSS die Validierung und Einreichen von Rechnungen als Bulk-Operation mittels HTTP-POST-Methode auf dem Endpunkt / unterstützen, wie unter [IG DiPag RE-PS#R2] beschrieben. [<=]

A_25881 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren/einreichen (Bulk) - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt / zum Einreichen und Validieren von Rechnungen als Bulk-Operation mit Status-Codes antworten, wie unter [IG DiPag RE-PS#R2] beschrieben. [<=]

A_26030 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Rechnung validieren/einreichen (Bulk) - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Einreichen und Validieren von Rechnungen als Bulk-Operation einen Claim mit der Telematik-ID des Nutzers und den Scope invoiceDoc.c enthalten und andernfalls diese abweisen. [<=]

##### 5.4.1.4 Abfrage von Daten zu Rechnungen und Dokumenten per Token

A_25854-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage von angereicherten PDFs per Token mittels HTTP-POST-Methode als FHIR-Operation $retrieve mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/Retrieve auf dem Endpunkt /DocumentReference/ unterstützen, wie unter [IG DiPag RE-PS#R3]beschrieben. [<=]

A_25882-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/ mit der Operation $retrieve mit Status-Codes antworten, wie unter [IG DiPag RE-PS#R3] beschrieben. [<=]

A_26031 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage von angereicherten PDFs per Token einen Claim mit der Telematik-ID des Nutzers und den Scope invoiceDoc.r enthalten und andernfalls diese abweisen. [<=]

A_29954 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Datenschutz

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass die an RE-PS ausgelieferten Rechnungs-Metadaten weder Rückschlüsse auf die vom Versicherten verwalteten Markierungen noch auf den vom Versicherten verwalteten Rechnungsstatus zulassen. [<=]

##### 5.4.1.5 Abfrage von angereicherten PDFs per Token (Bulk)

A_25855 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von angereicherten PDFs per Token (Bulk) - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage von angereicherten PDFs per Token als Bulk-Operation mittels HTTP-POST-Methode auf dem Endpunkt / unterstützen, wie unter [IG DiPag RE-PS#R4] beschrieben. [<=]

A_25883 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von angereicherten PDFs per Token (Bulk) - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt / zum Abfrage von angereicherten PDFs als Bulk-Operation mit Status-Codes antworten, wie unter [IG DiPag RE-PS#R4] beschrieben. [<=]

A_26032 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - RE-PS als Akteur - Abfrage von angereicherten PDFs per Token (Bulk) - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage von angereicherten PDFs per Token als Bulk-Operation einen Claim mit der Telematik-ID des Nutzers und den Scope invoiceDoc.r enthalten und andernfalls diese abweisen. [<=]

#### 5.4.2 FdV als Akteur

Nachfolgend beschrieben sind Anforderungen für Anwendungsfälle, in denen das Frontend des Versicherten (FdV) der Akteur ist.

##### 5.4.2.1 Abrufen/Suchen von Rechnungen

A_25857 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abrufen/Suchen von Rechnungen - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS den Abruf und die Suche von Rechnungen mittels HTTP-GET-Methode auf dem Endpunkt /DocumentReference mit den Suchparametern unterstützen, wie unter [IG DiPag FdV#R5] beschrieben. [<=]

A_25884 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abrufen/Suchen von Rechnungen - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-GET-Anfragen auf dem Endpunkt /DocumentReference mit den Suchparametern mit Status-Codes antworten, wie unter [IG DiPag FdV#R5] beschrieben. [<=]

A_26033 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abrufen/Suchen von Rechnungen - Claims und Scopes (Abfrage)

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Abruf von Rechnungen einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.r enthalten und andernfalls diese abweisen. [<=]

A_26034 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abrufen/Suchen von Rechnungen - Claims und Scopes (Suche)

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Suche von Rechnungen einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.s enthalten und andernfalls diese abweisen. [<=]

##### 5.4.2.2 Abfrage von Daten zu Rechnungen und Dokumenten per Token

A_25885-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage von angereicherten PDFs per Token mittels HTTP-POST-Methode als FHIR-Operation $retrieve mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/Retrieve auf dem Endpunkt /DocumentReference/ unterstützen, wie unter [IG DiPag FdV#R6] beschrieben. [<=]

A_25886-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/ mit der Operation $retrieve mit Status-Codes antworten, wie unter [IG DiPag FdV#R6] beschrieben. [<=]

A_26035 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage von angereicherten PDFs per Token einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.r enthalten und andernfalls diese abweisen. [<=]

##### 5.4.2.3 Statuswechsel

A_25858 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Statuswechsel - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Änderung des Status mittels HTTP-POST-Methode als FHIR-Operation $change-status mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/ChangeStatus mit dem Parameter tag und den Werten erledigt, offen und papierkorb auf dem Endpunkt /DocumentReference/<id>/ unterstützen, wie unter [IG DiPag FdV#R7] beschrieben. [<=]

A_25887 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Statuswechsel - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/<id>/ mit der FHIR-Operation $change-status und mit dem Parameter tag mit Status-Codes antworten, wie unter [IG DiPag FdV#R7] beschrieben. [<=]

A_26036 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Statuswechsel - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Änderung des Status einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.u enthalten und andernfalls diese abweisen. [<=]

##### 5.4.2.4 Markieren von Rechnungen und Dokumenten

A_25888 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Markieren von Rechnungen und Dokumenten - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS das Markieren von Rechnungen und Dokumenten mittels HTTP-POST-Methode als FHIR-Operation $process-flag mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/ProcessFlag auf dem Endpunkt /DocumentReference/<id>/ unterstützen, wie unter [IG DiPag FdV#R8] beschrieben. [<=]

A_25889 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Markieren von Rechnungen und Dokumenten - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/<id>/ mit der FHIR-Operation $process-flag mit Status-Codes antworten, wie unter [IG DiPag FdV#R8] beschrieben. [<=]

A_26039 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Markieren von Rechnungen und Dokumenten - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Markieren von Rechnungen und Dokumenten einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.u enthalten und andernfalls diese abweisen. [<=]

##### 5.4.2.5 Löschen eines Rechnungsvorgangs

A_25859 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Löschen eines Rechnungsvorgangs - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS das Löschen eines Rechnungsvorgangs mittels HTTP-POST-Methode als FHIR-Operation $erase mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/Erase auf dem Endpunkt /DocumentReference/<id>/ unterstützen, wie unter [IG DiPag FdV#R9] beschrieben. [<=]

A_25890 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Löschen eines Rechnungsvorgangs - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/<id>/ mit der FHIR-Operation $erase mit Status-Codes antworten, wie unter [IG DiPag FdV#R9] beschrieben. [<=]

A_26040 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Löschen eines Rechnungsvorgangs - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Löschen eines Rechnungsvorgangs einen Claim mit der KVNR des Nutzers und den Scope invoiceDoc.d enthalten und andernfalls diese abweisen. [<=]

##### 5.4.2.6 Nutzerprotokoll einsehen

A_25891 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Nutzerprotokoll einsehen - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage des Nutzerprotokolls mittels HTTP-GET-Methode auf dem Endpunkt /AuditEvent unterstützen, wie unter [IG DiPag FdV#R10] beschrieben. [<=]

A_25892 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Nutzerprotokoll einsehen - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-GET-Anfragen auf dem Endpunkt /AuditEvent antworten, wie unter [IG DiPag FdV#R10] beschrieben. [<=]

A_26041 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - FdV als Akteur - Nutzerprotokoll einsehen - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage des Nutzerprotokolls einen Claim mit der KVNR des Nutzers und den Scope auditEvent.rs enthalten und andernfalls diese abweisen. [<=]

#### 5.4.3 KTR als Akteur

Nachfolgend beschrieben sind Anforderungen für Anwendungsfälle, in denen Kostenträger (KTR) Akteure sind.

##### 5.4.3.1 Abfrage von Daten zu Rechnungen und Dokumenten per Token

A_25893-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - KTR als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Abfrage

Der Digitale Patientenrechnung Fachdienst MUSS die Abfrage von angereicherten PDFs per Token mittels HTTP-POST-Methode als FHIR-Operation $retrieve mit der Definition https://gematik.de/fhir/dipag/OperationDefinition/Retrieve auf dem Endpunkt /DocumentReference/ unterstützen, wie unter [IG DiPag PSK#R11] beschrieben. [<=]

A_25894-01 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - KTR als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Status-Codes

Der Digitale Patientenrechnung Fachdienst MUSS auf HTTP-POST-Anfragen auf dem Endpunkt /DocumentReference/ mit der Operation $retrieve mit Status-Codes antworten, wie unter [IG DiPag PSK#R11] beschrieben. [<=]

A_26042 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - KTR als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Abfrage von angereicherten PDFs per Token einen Claim mit der Telematik-ID des Nutzers und den Scope invoiceDoc.r enthalten und andernfalls diese abweisen. [<=]

A_29955 - Digitale Patientenrechnung Fachdienst - FHIR-Endpunkte und -Operations - KTR als Akteur - Abfrage von Daten zu Rechnungen und Dokumenten per Token - Datenschutz

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass die an KTR-PS ausgelieferten Rechnungs-Metadaten weder Rückschlüsse auf die vom Versicherten verwalteten Markierungen noch auf den vom Versicherten verwalteten Rechnungsstatus zulassen. [<=]

### 5.5 Weitere REST-Endpunkte

Der Digitale Patientenrechnung Fachdienst muss neben den FHIR-Endpunkten und -Operationen weitere REST-Endpunkte anbieten. Diese betreffen Anfragen, die nicht durch FHIR abbildbar sind, wie beispielsweise das Berechtigungsmanagement.

A_25967-01 - Digitale Patientenrechnung Fachdienst - Weitere REST-Endpunkte - Berechtigungen

Der Digitale Patientenrechnung Fachdienst MUSS eine Schnittstelle für das Abfragen und Bearbeiten von Berechtigungen als HTTP-REST-Anfragen unterstützen. Im MVP sind umzusetzen:

1. Eine Abfrage, mit der Versicherte alle Berechtigungen ermitteln können, die sie im FD erteilt haben.
2. Eine Funktion für die Versicherten, die es erlaubt, einzelne unter 1. abgefragte Berechtigungen zu entziehen oder neu zu erteilen

[<=]

A_26043-01 - Digitale Patientenrechnung Fachdienst - Weitere REST-Endpunkte - Berechtigungen Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zum Abfragen und Bearbeiten von Berechtigungen einen Claim mit der KVNR des Nutzers und zum Abfragen und Bearbeiten respektive den entsprechenden Scope permission.r oder permission.u enthalten und andernfalls diese abweisen. [<=]

Hinweis: Im MVP werden ausschließlich Rechnungsversandberechtigungen durch den FD verarbeitet. Rechnungsversandberechtigungen werden automatisiert beim Anlegen der ersten Rechnung durch den RE erstellt. Versicherte können einzelne Rechnungsversandberechtigungen entziehen und wieder erteilen. Entzug und Wiedererteilung der Berechtigung gelten als "Bearbeitung" einer existierenden Rechnungsversandberechtigung. Siehe [gemF_DiPag]

### 5.6 Nutzerregistrierung

#### 5.6.1 Institutionen

Institutionen wie Rechnungsersteller und Kostenträger (KTR) sollen sich am Digitale Patientenrechnung Fachdienst registrieren können. Diese Registrierung ermöglicht Institutionen den Zugriff auf eben diesen. Die Registrierung von KTR erlaubt außerdem Versicherten, bei Markierungen auf KTR zu verweisen. Sind KTR nicht am Fachdienst registriert, so kann bei einer Markierung der Verweis nur über einen Freitext erfolgen.

A_27554 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Institutionen - REST-Endpunkt

Der Digitale Patientenrechnung Fachdienst MUSS die Registrierung von Institutionen mittels eines REST-Endpunkts unterstützen. [<=]

A_27555 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Institutionen - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Registrierung von Institutionen Claims mit dem Anzeigenamen der Institution, die Telematik-ID des Nutzers und den Scope practitionerAccount.c (bei Rechnungserstellern) bzw. insuranceAccount.c (bei Kostenträgern) enthalten und andernfalls diese abweisen. Die übermittelten Informationen müssen gespeichert werden. [<=]

A_27556 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Institutionen - Registrierungsdaten

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass die bei der Registrierung von Institutionen übermittelten Claims des Anzeigenamens und der Telematik-ID im erstellten Nutzeraccount gespeichert werden. [<=]

A_28472-01 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Institutionen - Konto löschen

Der Digitale Patientenrechnung Fachdienst MUSS das aktive Löschen eines Institutionskontos unterstützen. Nachdem das Institutskonto gelöscht wurde, kann das betroffene Institut nicht mehr am Fachdienst teilnehmen. Das Löschen einer Institution MUSS einen eventuell erteilten Entzug der Rechnungsversandberechtigung durch den Versicherten für diese Institution bewahren: Wird ein Institutskonto nach dem Löschen neu angelegt, MUSS die Entscheidung des Versicherten bzgl. Erteilung/Widerruf der Rechnungsversandberechtigung nach wie vor durchgesetzt werden. [<=]

#### 5.6.2 Versicherte

A_27557 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - REST-Endpunkt

Der Digitale Patientenrechnung Fachdienst MUSS die Registrierung von Versicherten mittels eines REST-Endpunkts unterstützen. [<=]

A_27558 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Claims und Scopes

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass Anfragen zur Versichertenregistrierung Claims mit dem Anzeigenamen des Versicherten, die KVNR und das Geburtsdatum des Nutzers und den Scope insurantAccount.c enthalten und andernfalls diese abweisen. Die übermittelten Informationen müssen gespeichert werden. [<=]

A_27559 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Registrierungsdaten

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass die bei der Versichertenregistrierung übermittelten Claims mit dem Anzeigenamen des Versicherten, die KVNR und das Geburtsdatum im erstellten Nutzeraccount gespeichert werden. [<=]

A_28469 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Bearbeitung von Einstellungen des Nutzerkontos - REST-Endpunkt

Der Digitale Patientenrechnung Fachdienst MUSS das Ändern von Einstellungen des Nutzerkontos unterstützen. Es MÜSSEN insbesondere Benachrichtigungseinstellungen unterstützt werden. Für jeden Benachrichtigungstyp muss erfasst werden können, ob eine Push-Benachrichtigung oder eine E-Mail Benachrichtigung gewünscht wird. (Vgl [gemF_DiPag#4.5.3] ). [<=]

A_28485 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Benachrichtigungstype NEUE_RG

Der Digitale Patientenrechnung Fachdienst MUSS sicherstellen, dass bei der Bearbeitung von Benachrichtigungseinstellungen für das Ereignis NEUE_RG (Vgl [gemF_DiPag#4.5.3] ) mindestens ein Benachrichtigungstyp angegeben wird und andernfalls den Request mit einer Fehlermeldung abweisen. [<=]

A_28470-01 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Aktualisieren des Anzeigenamens

Der Digitale Patientenrechnung Fachdienst MUSS unterstützen, dass der Anzeigename des Nutzers aus dem Identitätsattribut der Gesundheits-ID aktualisieren wird.
[<=]

A_28471-01 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Konto löschen

Der Digitale Patientenrechnung Fachdienst MUSS das aktive Löschen eines Nutzerkontos unterstützen. Nach dem Löschen des Nutzerkontos sind alle mit dem Konto verknüpften Daten unmittelbar physisch gelöscht. Referenzen auf dem Konto zugeordnete Rechnungen werden ungültig. Systeme die Rechnungen abrufen, die zu einem gelöschten Account gehören, erhalten eine Fehlermeldung. [<=]

### 5.7 Benachrichtigungen

A_26102 - Digitale Patientenrechnung Fachdienst - Benachrichtigungen

Der Digitale Patientenrechnung Fachdienst MUSS aktive Benachrichtigungen gemäß [gemF_DiPag#4.5.3] an die Versicherten senden. Abhängig von den Einstellungen im Versichertenkonto (A_28469 - Digitale Patientenrechnung Fachdienst - Nutzerregistrierung - Versicherte - Bearbeitung von Einstellungen des Nutzerkontos - REST-Endpunkt ) sind folgende Nachrichtenkanäle vorgesehen:
Email
Falls Nachrichten als E-Mail versendet werden, MUSS die E-Mail-Adresse verwendet werden, die bei der Registrierung von Endgeräten der Versicherten (siehe Client-Registrierung in [gemSpec_ZETA]) validiert wurde und dem Versicherten zugeordnet ist. Die ZETA Komponenten stellen einen Endpunkt zum Abrufen der E-Mail-Adresse bereit. Die dort abgefragte Adresse ist immer für das Versenden von E-Mail-Benachrichtigungen zu verwenden.
Push-Benachrichtigung
Nachrichten MÜSSEN über den Notification-Service der ZETA Komponenten versendet werden.
Benachrichtigungen DÜRFEN KEINE personenbezogenen Daten enthalten.
[<=]

### 5.8 Interne Fehlercodes

A_27547-01 - Digitale Patientenrechnung Fachdienst - Telemetriedaten-Fehlercodes

Der Digitale Patientenrechnung Fachdienst MUSS bei der Telemetriedatenlieferung folgende interne Fehlercodes verwenden:

Tabelle 2 : Tab_DiPag_interne_Fehlercodes

BDE-Code | Errorcode Referenz | Beschreibung
--- | --- | ---
79030 | MISSING_OR_INVALID_HEADER | The required header <header> is missing or invalid.
79031 | UNSUPPORTED_MEDIATYPE | The clientsystem asked for an unsupported media type <media type>.
79032 | UNSUPPORTED_ENCODING | The clientsystem asked for an unsupported encoding scheme <encoding scheme>.
79040 | INVALID_HTTP_OPERATION | ERROR
79041 | INVALID_ENDPOINT | ERROR
79100 | SERVICE_INTERNAL_SERVER_ERROR | Unexpected internal server error.
79112 | OCSP_NOTREACHABLE | Certificate validation services can not be reached
79113 | OCSP_TIMEOUT | Certificate validation services timed out
79205 | MISSING_HEADER_CLIENTDATA | Header ZTA-Client-Data fehlt.
79206 | MISSING_HEADER_USERINFO | Header ZTA-User-Info fehlt.
79400 | ERROR_HEADER_CLIENTDATA | Client-Data Daten können nicht verarbeitet werden.
79401 | ERROR_HEADER_USERINFO | User-Info Daten können nicht verarbeitet werden.
79403 | ZETA_DPOP_VALIDATION_ERROR | Signature verification of the DPoP-JWT failed
79404 | ZETA_INVALID_ACCESSTOKEN | Signature verification of the presented access token failed
79405 | ZETA_EXPIRED_ACCESSTOKEN | Access token has expired

[<=]

## 6 Informationsmodell

### 6.1 FHIR-Ressourcen

Der Digitale Patientenrechnung Fachdienst muss FHIR-Ressourcen akzeptieren, verarbeiten und produzieren können, die dem Anwendungsfall entsprechen. Diese sind im vorhergehenden Kapitel beschrieben und deren Spezifikation befindet sich unter [Simplifier DiPag].

### 6.2 Nutzerprotokoll

A_29889 - Digitale Patientenrechnung Fachdienst - Zugriffsprotokoll - Protokollinformationen

Der Digitale Patientenrechnung Fachdienst MUSS bei jedem Zugriff, der Informationen liest, erstellt, verändert oder löscht als Protokolleintrag eine AuditEvent FHIR-Instanz erstellen. Dabei gelten folgende übergreifende Vorgaben für das Mapping von Zugriffen auf AuditEvent-Elemente:

FHIR-Audit-Event-Element | Inhalt
--- | ---
recorded | Zeitpunkt des Zugriffs, der Übermittlung, der Löschung usw.
source.observer | OID des Fachdienstes
source.display | "Fachdienst Digitale Patientenrechnung"
entity.Versicherter.what.reference | "Patient/{id des Versicherten dem der Protokolleintrag zugeordnet ist}"
entity.Versicherter.what.type | "Patient"
type | rest bei Nutzerinteraktionen und "Application Activity" bei automatischen Aktionen des Fachdienstes
subtype / action | Bei FHIR-Operationen: Name der Fhir-Operation ("invoice-submit", "change-status", "process-flag") und Action "E" Bei anderen Zugriffen: Wert aus dem FHIR Code System für RESTful Interactions ("create", "read", "update", "delete") mit den entspechenden Actions ("C","R","U","D")
agent.type | dataprocessor bei automatischen Zugriffen des Fachdienstes humanprocessor bei Nutzerinteraktionen
agent.who | Bei automatischen Aktionen des Fachdienstes Identifier: OID des Fachdienstes Display: "Fachdienst Digitale Patientenrechnung" Bei Aktionen der Institutionen Identifier: Telematik-ID der Institution Display: Display-Name der Institution Bei Aktionen der versicherten Person Identifier: KVNR Display: Display-Name der versicherten Person.

Für Zugriffsarten, die sich auf Rechnungen beziehen, gelten folgende allgemeine Vorgaben den AuditEvent-Mappings:

FHIR-Audit-Event-Element | Inhat
--- | ---
entity.DocumentReference.what.reference | "DocumentReference/{rechnungstoken}"
entity.DocumentReference.what.type | "DocumentReference"
what.reference.identifier | Rechnungsnummer
entity.DocumentReference.name | [description der Rechnung]

Der Entity-Detail-Typ und der FdV-freundliche Text MÜSSEN zum jeweiligen Zugriffstyp passen. Hier gelten folgende Vorgaben:

Typ des Zugriffs | Mapping auf FHIR Audit-Event
--- | ---
Digitale Patientenrechnung von Rechnungsersteller übermittelt | entity:DocumentReference.detail.type = Allgemein entity:DocumentReference.detail.valueString = "Die Rechnung wurde übermittelt."
Automatisches Verschieben einer Digitale Patientenrechnung mit zugehörigen Dokumenten in den Papierkorb aufgrund Löschfrist | entitiy:DocumentReference.detail.type = DocumentReference.meta.tag:dipag-rechnungsstatus entitiy:DocumentReference.detail.valueString = "Die Rechnung wurde in den Papierkorb verschoben."
Automatisches Löschen einer Digitale Patientenrechnung mit zugehörigen Dokumenten aus dem Papierkorb aufgrund Löschfrist | entity:Rechnung.detail.type = Allgemein entity:Rechnung.detail.valueString = "Die Rechnung wurde gelöscht."
Automatisches Setzen einer Markierung bei einer Rechnung/einem Dokument | entity:Rechnung.detail.type = DocumentReference.meta.extension:markierung entity:Rechnung.detail.valueString = "Die Rechnung wurde mit xy und z markiert." (Frontend-freundlicher Text) Eventuelle Zusatzinformationen MÜSSEN in den frontend-freundlichen Text integriert werden und werden im MVP nicht in strukturierter Form unterstützt. Beispiel: Beim Setzen der Markierung "Abgerufen durch Kostenträger" MUSS die der Anzeigenahme des Kostenträgers, der abgerufen hat, in den fontend-freundlichen Text integriert werden.
Setzen einer Liste von Markierungen bei einer Rechnung/einem Dokument durch einen Versicherten | entity:Rechnung.detail.type = DocumentReference.meta.extension:markierung entity:Rechnung.detail.valueString = "Die Rechnung wurde mit xy und z markiert." (Frontend-freundlicher Text) Bei Änderungen der Markierungsliste MÜSSEN im Text des AuditEvents alle in einem Schritt gespeicherten Markierungen aufgenommen werden. Wenn alle Markierungen gelöscht werden (Leere Liste bei der $process-flag-Operation) MUSS der Text lauten "Alle Markierungen wurden gelöscht"
Neue individuelle Berechtigung zum Rechnungsversand eines Rechnungsersteller angelegt | entity:Versicherter.detail.type = Rechnungsversand-Berechtigung entity:Versicherter.detail.valueString = "Die Rechnungsversand-Berechtigung für xy wurde angelegt." (Frontend-freundlicher Text)
Bestätigung/Widerruf einer Berechtigungsregel zum Rechnungsversand durch den Rechnungsempfänger | entity:Versicherter.detail.type = Rechnungsversand Berechtigung entity:Versicherter.detail.valueString = "Die Berechtigungsregel zum Rechnungsversand wurde durch den Rechnungsempfänger bestätigt/widerrufen" (Frontend-freundlicher Text)
Abfrage Berechtigung zum Rechnungsversand durch den Rechnungsersteller | entity:Versicherter.detail.type = Allgemein entity:Versicherter.detail.valueString = "Die Berechtigung zum Rechnungsversand wurde abgefragt."
Einrichtung Nutzerkonto und Einwilligung | entity:Versicherter.detail.type = Allgemein entity:Versicherter.detail.valueString = "Ein Nutzerkonto wurde eingerichtet"

[<=]

### 6.3 Rechnungs- oder Dokumenten-Token

#### 6.3.1 Zufallswert

A_26050 - Digitale Patientenrechnung Fachdienst - Rechnung/Dokument-Token - Zufallswert

Der Digitale Patientenrechnung Fachdienst MUSS als Rechnungs- oder Dokument-Token einen Zufallswert generieren, der hexadezimal codiert genau 64 Zeichen lang ist, wobei die Vorgaben zu Zufallszahlen gemäß [gemSpec_Krypt] zu beachten sind. [<=]

Dieses soll die Erratbarkeit gen Null senken. Ein Beispiel für einen Token wäre 777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea.

#### 6.3.2 Darstellung als Barcode

A_25724 - Digitale Patientenrechnung Fachdienst - Rechnung/Dokument-Token - Barcode-Format

Der Digitale Patientenrechnung Fachdienst MUSS den Barcode für das Rechnungs- oder Dokumenten-Token als einen möglichst kompakten DataMatrix-Code gemäß [DataMatrix] in einem Format generieren, welches:

- den eigentlichen Token und
- einen eindeutigen Typ-Identifikator enthält, der der Anwendung Digitale Patientenrechnung zuzuordnen ist.

[<=]

Hinweis: Die genaue Ausgestaltung des Formats obliegt dem Hersteller des Fachdienstes.

A_25725 - Digitale Patientenrechnung Fachdienst - Rechnung/Dokument-Token - Barcode-Inhalt

Der Digitale Patientenrechnung Fachdienst MUSS den Barcode aus dem zum Dokument gehörigen Digitale Patientenrechnung- oder Dokumenten-Token generieren und darf keine anderen Informationen enthalten. [<=]

### 6.4 Angereichertes PDF

A_25740-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Strukturierte Daten

Der Digitale Patientenrechnung Fachdienst MUSS bei der Anreicherung von Rechnungsdokumenten die strukturierten Daten im FHIR-JSON-Format als Attachment in das angereicherte PDF integrieren. Der FD DARF keine FHIR-XML-Formate für Rechnungsinhalte annehmen. Der FD MUSS die validierten vom RE gesendeten strukturierten Daten unverändert in das PDF integrieren. [<=]

Hinweis: während die FHIR-Schnittstellen des FD sowohl das FHIR-XML als auch das FHIR-JSON-Format unterstützen, erfolgt im MVP bezügliche des eigentlichen Rechnungsinhaltsformats eine Festlegung auf FHIR-JSON.

A_25726-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Größe Barcode

Der Digitale Patientenrechnung Fachdienst MUSS bei der Anreicherung von Rechnungsdokumenten und Anhangsdokumenten den Barcode in einer Größe und mit einem äußeren Abstand in das Dokument integrieren, so dass sich dieser vom ausgedruckten Dokument mit gängigen Methoden und gängiger Hardware einlesen lässt. [<=]

A_25727-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Positionierung Barcode Default

Der Digitale Patientenrechnung Fachdienst MUSS bei der Anreicherung von Rechnungsdokumenten und Anhangsdokumenten den Barcode so platzieren, dass bei gängigen Layouts des PDF und ohne explizite Vorgabe (Default) der Position keine Elemente des Dokuments (Original-PDF) durch diesen verdeckt werden. Dokumente mit gängigem Layout sind solche, die [DIN 5008] Form A oder Form B entsprechen. [<=]

A_27461-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Positionierung Barcode für Kuvertierung

Der Digitale Patientenrechnung Fachdienst MUSS bei der Anreicherung von Rechnungsdokumenten und Anhangsdokumenten den Barcode so platzieren, dass er bei gängigen Verfahren der Kuvertierung für den Postversand im Format DIN A4 nicht von Knickfalten betroffen wäre. [<=]

A_27462-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Positionierung Barcode nach Vorgabe

Der Digitale Patientenrechnung Fachdienst MUSS es bei der Anreicherung von Rechnungsdokumenten und Anhangsdokumenten ermöglichen, die Platzierung des Barcodes durch Angabe einer Position und Orientierung zu variieren, um ggf. Probleme mit:

- Knickfalten,
- verdeckten Inhalten oder
- Sichtbarkeit in einem Sichtfenster (DIN A4 Umschlag)

beheben zu können.
[<=]

A_25728-01 - Digitale Patientenrechnung Fachdienst - Angereichertes PDF - Positionierung Barcode Wiederholbarkeit

Der Digitale Patientenrechnung Fachdienst MUSS bei der Anreicherung von Rechnungsdokumenten und Anhangsdokumenten sicherstellen, dass die Positionierung des Barcodes sowohl bei dem optionalen, initialen Bereitstellen als auch bei späteren, wiederholten Abrufen identisch ist. [<=]

Hinweis: Die konkrete Ausgestaltung des Positionierungsverfahrens obliegt dem Hersteller des Fachdienstes.

### 6.5 Signatur

A_26052-01 - Digitale Patientenrechnung Fachdienst -Signatur - Erstellung

Der Digitale Patientenrechnung Fachdienst MUSS kryptographische Signaturen für die folgenden vom Fachdienst abrufbaren Datenobjekte erzeugen:

- Original-Rechnungs-PDF
- Angereicherte Rechnung
- Strukturierte Daten
- gemeinsame Repräsentation aus Original-Rechnungs-PDF und Strukturierten Daten
- jedes Anhangsdokument

Die Signaturen MÜSSEN so erzeugt werden, dass Integrität und Authentizität der signierten Inhalte von nachgelagerten Systemen unabhängig vom Zugriff auf den Fachdienst mit allgemein verfügbarer Signaturprüfsoftware überprüft werden können.
Hinweis: Nachgelagerte Systeme sind in diesem Zusammenhang Systeme, die keinen direkten Zugang über ZETA und SMC-B zum Digitale Patientenrechnung Fachdienst haben.
[<=]

## 7 Verteilungssicht

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

## 8 Anhang A – Verzeichnisse

### 8.1 Abkürzungen

Tabelle 3: Im Dokument verwendete Abkürzungen

Kürzel | Erläuterung
--- | ---
ADL | Abrechnungsdienstleister
CA | Certification Authority
CC | Common Criteria
FdV | Frontend des Versicherten
FIPS | Federal Information Processing Standard
HSM | Hardware Security Module
ITSEC | Information Technology Security Evaluation Criteria
KTR | Kostenträger
KVNR | Krankenversichertennummer
LEI | Leistungserbringerinstitution
PoPP | Proof of Patient Presence
RE | Rechnungsersteller
RE-PS | Rechnungsersteller Primärsystem
VAU | Vertrauenswürdigen Ausführungsumgebung

### 8.2 Glossar

Tabelle 4: Glossar der explizit im Dokument verwendeten Begriffe

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.

### 8.3 Abbildungsverzeichnis

- Abbildung 1: Funktionaler Aufbau der Anwendung Digitale Patientenrechnung

### 8.4 Tabellenverzeichnis

- Tabelle 1: Erlaubte Nutzergruppen und Rollen
- Tabelle 2 : Tab_DiPag_interne_Fehlercodes
- Tabelle 3: Im Dokument verwendete Abkürzungen
- Tabelle 4: Glossar der explizit im Dokument verwendeten Begriffe
- Tabelle 5: Referenzierte Dokumente der gematik
- Tabelle 6: Weitere Referenzen

### 8.5 Referenzierte Dokumente

#### 8.5.1 Dokumente der gematik

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

Tabelle 5: Referenzierte Dokumente der gematik

[Quelle] | Herausgeber: Titel
--- | ---
[gemSpec_DS_Hersteller] | gematik: Spezifikation Datenschutz- und Sicherheitsanforderungen der TI an Hersteller
[gemF_DiPag] | gematik: Feature Spezifikation/Konzept der Anwendung Digitale Patientenrechnung
[gemGlossar] | gematik: Einführung der Gesundheitskarte - Glossar
[gemSpec_Krypt] | gematik: Übergreifende Spezifikation: Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur
[gemSpec_OID] | gematik: Übergreifende Spezifikation: Festlegung von OIDs
[gemSpec_ZETA] | gematik: Spezifikation Zero Trust Access (ZETA)

#### 8.5.2 Weitere Referenzen

Tabelle 6: Weitere Referenzen

[Quelle] | Herausgeber (Erscheinungsdatum): Titel
--- | ---
[DataMatrix] | ISO/IEC 16022:2024: Information technology - Automatic identification and data capture techniques - Data Matrix bar code symbology specification
[IG DiPag FdV] | Implementierungsleitfaden Digitale Patientenrechnung - Szenarien - FdV als Akteur https://simplifier.net/guide/digitalepatientenrechnung-implementierungsleitfaden/Startseite/Szenarien/DiPag-FdV-als-Akteur?version=1.0.8 (Abruf 07/26)
[IG DiPag RE-PS] | Implementierungsleitfaden Digitale Patientenrechnung - Szenarien - RE-PS als Akteur https://simplifier.net/guide/digitalepatientenrechnung-implementierungsleitfaden/Startseite/Szenarien/RE-PS-als-Akteur?version=1.0.8 (Abruf 07/26)
[IG DiPag PSK] | Implementierungsleitfaden Digitale Patientenrechnung - Szenarien - PSK als Akteur https://simplifier.net/guide/digitalepatientenrechnung-implementierungsleitfaden/Startseite/Szenarien/ITSys-KTR-als-Akteur?version=1.0.8 (Abruf 07/26)
[ISO 19005] | ISO 19005 - PDF Association (Abschnitt "PDF/A = ISO 19005") https://pdfa.org/pdf-standards/ (Abruf 02/25)
[Simplifier DiPag] | Simplifier Projekt Digitale Patientenrechnung https://simplifier.net/DigitalePatientenrechnung/~introduction (Abruf 07/26)
[SMART on FHIR] | SMART on FHIR - Scopes https://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context.html (Abruf 07/25)
[DIN 5008] | DIN 5008 Berichtigung 1:2020-07: Schreib- und Gestaltungsregeln für die Text- und Informationsverarbeitung