# FDZ

FDZ

# Einleitung

Das FDZ tritt in zwei Rollen auf -- einmal als Server und einmal als ePA-Client.

Wichtigste Anwendungsfälle sind:

- Annahme von Übersetzungstabelle PüP-AN (Submission mit Submission-ID) von der VST  
    (FDZ ist Server)
- Abholen von pseudonymisierten Daten inkl. AN (Submission mit Submission-ID) vom ePA-Aktensystem   
    (FDZ ist "normaler" ePA-Client)

<div drawio-diagram="9"><img src="https://tipkg.de/uploads/images/drawio/2025-04/drawing-1-1744320090.png" alt=""/></div>

Ein AS erzeugt zufällig eine Submission-ID und stellt eine Submission. Dabei werden vom AS Auftragsnummer (AN), Lieferpseudonyme (LP) und pseudoynmisierte Daten erzeugt.

Die Submission-ID (256-Bit-Wert) ist ein wichtiger Zuordnungsschlüsselwert (im Datenbanksinne / Zuordnungsschlüssel).

Das AS sendet eine Abbildungstabelle LP-AN inkl. Submission-ID an die VST. ([Link](https://tipkg.de/books/fdz/page/lieferung-lpansubmission-id-durch-die-beiden-as-an-die-vst))

Die VST sendet eine Abbildungstabelle PüP-AN inkl. Submission-ID an das FDZ. ([Link)](https://tipkg.de/books/fdz/page/lieferung-von-pupansubmission-id-vom-vst-an-das-fdz)

Das FDZ bezieht als "normaler" ePA-Client vom AS die pseudonymisierten Daten (URL kommt dafür aus dem Submission-Daten, siehe weiter unten `call_back_url`). ([Link](https://tipkg.de/books/fdz/page/abholung-von-submissions-durch-das-fdz-von-den-as))

<table border="1" id="bkmrk-fachdienst%2Fin-rolle-" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col></colgroup><tbody><tr><td>*Fachdienst/in Rolle*</td><td>*Client*</td><td>*Server*</td></tr><tr><td>AS</td><td>Lieferung LP+AN-Submission-ID Daten an die VST</td><td>Hält pseudoynmisierte Daten inkl. AN + Submission-ID vor für das FDZ</td></tr><tr><td>VST</td><td>Liefert PüP+AN-Submission-ID ans FDZ</td><td>Empfänge PüP+AN-Submission-ID  
</td></tr><tr><td>FDZ</td><td>Bezieht pseudonmyisierte Daten inkl. AN + Submission-ID vom AS</td><td>Empfäng PüP+AN-Submission-ID</td></tr></tbody></table>

#### Übersetzungstabelle LP-AN+Submission-ID

Das AS sendet an die VST nach beidseitiger Authentisierung eine Übersetzungstabelle LP-AN+Submission-ID.

#### Übersetzungstabelle PüP-AN+Submission-ID

Das VST sendet an das FDZ eine Übersetzungstabelle PüP-AN+Submission-ID.

Das ist eine mit der Nomenklatur `Datenausleitung-VST-FDZ-<Submission-ID-Hex>.cbor`

Darin befindet sich folgende Datenstruktur.

```json
Submission = [
    {"type": "vst->fdz",
     "created_at": Unix-Zeit,
     "submission_id": Submission-ID,
     "call_back_url": url_aktensystem},
     [PüP1, AN1], [PüP2, AN2] …
]
```

Die Datenstruktur wird über [CBOR](https://datatracker.ietf.org/doc/html/rfc8949) binär kodiert.

Das FDZ erhält also bspw. `Datenausleitung-VST-FDZ-81b1b83e2736d45db16674e527890b8adc69ff7275acf11925faf44ae57f7e2f.cbor`

In der Datenstruktur selbst (CBOR-kodiert) sind die Submission-ID, PüP und AN binär kodiert (also jeweils 32 Byte Binärdaten).

#### Submission vom AS

Aus der `call_back_url` weiß das FDZ, welches AS es mit welcher URL kontaktieren muss. Das FDZ bezieht nach beidseitiger Authentisierung (siehe spätere Abschnitte) die Daten.

Die Daten sind "New-Line-Delimited-JSON (NDJSON)"-Dateien (mit bspw. folgenden Namen: `Datenausleitung-AS-FDZ-<Submission-ID-Hex>.ndjson`).

Vergleiche auch [I\_Data\_Submission\_Service](https://github.com/gematik/ePA-Basic/blob/ePA-3.1.2/src/openapi/I_Data_Submission_Service.yaml).

#### Datensicherung

Wie in [TLS+VAU-Protokoll](https://tipkg.de/books/fdz/page/tlsvau-protokoll) beschrieben werden die Datentransporte jeweils über zwei übereinander liegende Sicherungsschichten (TLS+VAU-Protokoll) Vertraulichkeits- und Authentitätsgeschützt. Auf TLS-Ebene (HTTPS-Schnittstelle) gibt es nur eine Server-seitige Authentisierung. Auf der darüberliegen VAU-Protokoll-Ebene gibt es eine beidseitige Authentisierung (also sowohl VAU-Protokoll-Server-Authentisierung als auch VAU-Protokoll-Client-Authentisierung) -- Standardvorgehen bei ePA weil meistens ePA-Clients keine X.509-Zertifikate über die "direkte" Authentisierung bei TLS einsetzen können. Die nur Server-seitige TLS-Authentisierung bei der VST erleichtert die Umsetzung (spezielle Einsatzumgebung dort / Perimeter TLS-Gateway).

# Lieferung LP+AN+Submission-ID durch die beiden AS an die VST

Wie in I\_VST definiert hat die VST innerhalb der TI eine HTTPS-Schnittstelle und damit auch ein TLS-Serverzertifikat aus der TI-PKI (Komponenten-PKI der TI). Im TLS-Serverzertifikat gibt es eine OID oid\_epa\_vst als Profession-OID.

Auf Anwendungsebene erfolgt dann ein [VAU-Protokoll-Verbindungsaufbau](https://tipkg.de/books/fdz/page/tlsvau-protokoll) bei dem die VST ein <span data-prototype="Document" id="bkmrk-"></span>C.FD.AUT-Zertifikat (TI-PKI) besitzt mit professionOID gleich oid\_epa\_vst.

Das AS als VAU-Protokoll-Client authentisiert sind wie üblich über [PKI-basierte VAU-Protokoll-Client-Authentisierung](https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#A_24658-01) beim VAU-Protokoll Verbindungsbaufbau. Zitat aus I\_VST:

> "Erst nachdem sich das ePA-AS authentisiert hat und die VST die Authentifizierung erfolgreich durchführen konnte, darf das VST fachliche Zugriffe erlauben (Submission entgegennehmen)."

Ein AS stellt eine Submission her -- erzeugt dabei zufällig eine Submission-ID (256-Bit-Wert).

Innerhalb des VAU-Protokoll schickt das AS (= hier Client) in einem [inneren Request](https://tipkg.de/books/fdz/page/tlsvau-protokoll) per POST an `<span style="color: rgb(0, 0, 0);">/epa/submission/api/v1/submissions/<Submission-ID-Hex></span>` die Übersetzungstabelle mit folgender Struktur (CBOR-kodiert):

```json
Submission = [
    {"type": "as->vst",
     "created_at": Unix-Zeit,
     "submission_id": Submission-ID,
     "call_back_url": url_aktensystem},
     [LP1, AN1],
     [LP2, AN2], …
]
```

Submission-ID ist ein 32 Byte Binärwert. Die Auftragsnummern (ANy) sind jeweils 32 Byte Binärwerte. Die Lieferpseudonyme (LPx) (Erzeugungsvorschrift wird ist in I\_VST definiert) sind jeweils 103 Byte lange Binärwerte.

Die `call_back_url` verwendet das FDZ dann folgend um die pseduoynmisierten Daten vom Aktensystem per GET (TLS+VAU-Protokoll+Client-Authentisierung-FDZ) zu beziehen.

Die `call_back_url` muss mit `https://epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de` beginnen. ePA-Anbieter-Zahl kann aktuell genau nur 1 oder 2 sein. Die "Umgebung" hat in der PU den Wert "prod".

In der `call_back_url` ist die Submission-ID schon vorhanden.

# Lieferung von PüP+AN+Submission-ID vom VST an das FDZ

Für den Datentransfer der Übersetzungstabellen PüP+AN+Submission-ID vom VST an das FDZ hat die gematik keine Regelungshoheit. Die gematik schlägt vor die Schnittstelle genau so wie bei der VST (I\_VST) und beim ePA-AS zu gestalten. Dann wäre die Schnittstellen alle beteiligten Kommunikationspartner gleich.

Dies wird im folgenden beschrieben.

Das FDZ besitzt eine HTTPS-Schnittstelle (TLS-Server-Zertifikat aus der TI-PKI, im Zertifikat oid\_epa\_fdz). Auf Anwendungsebene besitzt das FDZ ein C.FD.AUT-Zertifikat (TI-PKI) mit der OID oid\_epa\_fdz.

<table border="1" id="bkmrk-kommunikationspartne" style="border-collapse: collapse; height: 258.3px; width: 79.1667%;"><colgroup><col style="width: 35.3748%;"></col><col style="width: 64.6101%;"></col></colgroup><tbody><tr style="height: 29.7px;"><td style="height: 29.7px;">*Kommunikationspartner*</td><td style="height: 29.7px;">*Zertifikate*</td></tr><tr style="height: 46.5px;"><td style="height: 46.5px;">ePA-AS</td><td style="height: 46.5px;">TLS-Server-Zertifikat mit oid\_epa\_dvw

C.FD.AUT-Zertifikat mit oid\_epa\_vau

</td></tr><tr style="height: 46.5px;"><td style="height: 46.5px;">VST</td><td style="height: 46.5px;">TLS-Server-Zertifikat mit oid\_epa\_vst

C.FD.AUT-Zertifikat mit oid\_epa\_vst

</td></tr><tr style="height: 46.5px;"><td style="height: 46.5px;">FDZ</td><td style="height: 46.5px;">TLS-Server-Zertifikat mit oid\_epa\_fdz

C.FD.AUT-Zertifikat mit oid\_epa\_fdz

</td></tr></tbody></table>

Die VST baut auf Anwendungsebene eine [VAU-Protokoll-Verbindung](https://tipkg.de/books/fdz/page/tlsvau-protokoll) auf. Darin authentisiert sich die VST über [PKI-basierte VAU-Protokoll-Client-Authentisierung](https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#A_24658-01), genau wie zuvor das AS gebenüber der VST und später das FDZ gegenüber dem AS.

Anschließend sendet dei VST über einen innere HTTP-Request per POST an `/epa/submission/api/v1/submissions/<Submission-ID-Hex>` eine Abbildungstabelle PüP+AN+Submission-ID wie in I\_VST definiert.

```json
Submission = [
    {"type": "vst->fdz",
     "created_at": Unix-Zeit,
     "submission_id": Submission-ID,
     "call_back_url": url_aktensystem},
     [PüP1, AN1],
     [PüP2, AN2], …
]
```

Submission-ID ist ein 32 Byte Binärwert. Die Auftragsnummern (ANx) sind ebenfalls 32 Byte Binärwerte. Die PüP sind Binärwerte.

Die `call_back_url` muss mit `https://epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de` beginnen. ePA-Anbieter-Zahl kann aktuell genau nur 1 oder 2 sein. Die "Umgebung" hat in der PU den Wert "prod".

In der `call_back_url` ist die Submission-ID schon vorhanden.

# Abholung von Submissions durch das FDZ von den AS

Das FDZ tritt hier als "normaler" ePA-Client auf. Es verbindet sich per TLS an den in der `call_back_url` angegeben Host (FQDN in der URL).

Die `call_back_url` muss mit `https://epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de` beginnen. ePA-Anbieter-Zahl kann aktuell genau nur 1 oder 2 sein. Die "Umgebung" hat in der PU den Wert "prod".

Anschließend baut es über das VAU-Protokoll (zu verwendenen Pfade dort definiert) eine VAU-Protokoll-Verbindung auf. Anschließend authentisiert sich das FDZ über die [PKI-basierte VAU-Protokoll-Client-Authentisierung](https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#A_24658-01).

Nun kann es per GET im inneren Request per GET die im `call_back_url` aufgeführte Submission abholen.

Beispiel für `call_back_url`:

> [https://epa-as-1.prod.epa4all.de/epa/submission/api/v1/submissions/6f3e4ad45a4c1c363f3e9b797ecca58c4f72998f83defe0b3fe867a988c9b362](https://epa-as-1.prod.epa4all.de/epa/submission/api/v1/submissions/6f3e4ad45a4c1c363f3e9b797ecca58c4f72998f83defe0b3fe867a988c9b362)

Vergleiche auch [I\_Data\_Submission\_Service](https://github.com/gematik/ePA-Basic/blob/ePA-3.1.2/src/openapi/I_Data_Submission_Service.yaml).

# TLS+VAU-Protokoll

Bei ePA wird bei den Kommunikationen zwei Sicherungsschichten (TLS+VAU-Protokoll) parallel verwendet.

[![grafik.png](https://tipkg.de/uploads/images/gallery/2025-04/scaled-1680-/6ocgrafik.png)](https://tipkg.de/uploads/images/gallery/2025-04/6ocgrafik.png)

Zunächst gibt es eine TLS-Schicht, die die Grundlage einer HTTPS-Schnittstelle ist. Auf der TLS-Ebene gibt es ein TLS-Server-Zertifikat aus der TI-PKI.

Über diese HTTPS-Schnittstelle werden "äußere HTTP-Request" vom Client an den Server (VST, FDZ, ePA-AS) gesendet.

In diesen äußeren Requests sind VAU-Protokoll-Nachrichten verpackt. Eine zentrale Grundlage des VAU-Protokolls stellt das VAU-Protokoll-Server-Zertifikat -- wieder aus der Komponenten-PKI der TI.

VAU-Protokoll:

<table border="1" id="bkmrk-spezifikation%3A%C2%A0-http" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>Spezifikation:

</td><td>[https://gemspec.gematik.de/docs/gemSpec/gemSpec\_Krypt/latest/#7](https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#7)   
</td></tr><tr><td>Beispiel-Code für Aushandlung der symmetrischen VAU-Kanal-Schlüssel:</td><td>[https://bitbucket.org/andreas\_hallof/vau-protokoll/src/master/minimal/](https://bitbucket.org/andreas_hallof/vau-protokoll/src/master/minimal/)   
</td></tr><tr><td>Beispiel-Code in python</td><td>[https://bitbucket.org/andreas\_hallof/vau-protokoll/src/master/](https://bitbucket.org/andreas_hallof/vau-protokoll/src/master/)   
</td></tr><tr><td>Beispiel-Code für Java:</td><td>[https://github.com/gematik/lib-vau](https://github.com/gematik/lib-vau)   
</td></tr><tr><td>Beispiel-Code in C#:</td><td>[https://github.com/gematik/lib-vau-csharp](https://github.com/gematik/lib-vau-csharp)   
</td></tr><tr><td>Beispiel-Code in Go:</td><td>[https://github.com/gematik/zero-lab/tree/vau/pkg/libvau](https://github.com/gematik/zero-lab/tree/vau/pkg/libvau)   
</td></tr></tbody></table>