Achtung! Da der Fachdienst Digitale Patientenrechnung sich noch Entwicklung befindet, sind noch nicht alle Tools auf dem ab November 2026 verfügbaren Stand. Kleinere Änderungen sind also noch möglich. 

Folgende Tools/Umgebungen können bei Bedarf zur schnellen lokalen Entwicklung genutzt werden.

Umgebungen


Die Gematik stellt die Entwicklungsversion des DiPag Fachdienstes unter https://dev.digitale-patientenrechnung.de zur Verfügung. Um diesen Dienst nutzen zu können, benötigen Sie digitale Testidentitäten (SMC-B oder Gesundheits-ID), die Gematik auf Anfrage zur Verfügung stellt.

Die weiteren im Aufbau befindlichen Umgebungen sind:

ZETA Guard / ZETA Client


Der Zugriff auf den Fachdienst der Entwicklungs- Produktions- und Testumgebung wird vom so genannten "ZETA Guard" kontrolliert.

Die Gematik veröffentlicht einen Leitfaden für Implementierungsschritte, die notwendig sind, damit ein Client vom "ZETA Guard" für den Fachdienst berechtigt wird: https://gemspec.gematik.de/docs/gemILF/gemILF_ZETA_API/latest/

Darüber hinaus wird ein ZETA Client SDK veröffentlicht, welches für viele gängige Plattformen verfügbar ist. Das SDK vereinfacht die Anbindung an den Fachdienst indem darin die notwendigen Implementierungsschritte schon umgesetzt sind: https://github.com/gematik/zeta-sdk

OpenAPI - Accountverwaltung

Die Fachdienst-APIs für das Verwalten von Accounts und das Zugriffsrechtemanagement sind als OpenAPI-Dokumentation verfügbar:

⬇️ DOWNLOAD ⬇️ DiPag-OpenAPI_v0.3.1-0.json

Test-Collection


Eine Test Collection für den End-to-End-Test des DiPag Fachdienstes (Digitale Patientenrechnung) der gematik. Die Collection bildet einen Rechnungsworkflow zwischen Arztpraxis, Versicherter Person, Kostenträger und Abrechnungsdienstleister (ADL) ab.

⬇️ DOWNLOAD ⬇️ DiPag-Fachdienst-Test-Collection-v1.0-ru-dev-0.3.1.zip

Die Test-Collection funktioniert nur mit einer Fachdienst-Umgebung, die nicht von ZETA geschützt ist, beispielsweise funktioniert sie mit dem lokal laufenden Fachdienst-Container, s.u.
Sie kann daher als Demonstration der fachlichen Use Cases genutzt werden. Mit dieser Test-Collection haben alle Beteiligten die Möglichkeit, ganzen Ende-zu-Ende-Prozess der digitalen Patientenrechnung durchzuführen.

Der Fachdienst-Container, gegen den diese Test-Collection ausführbar ist wird im November 2026 zur Verfügung stehen.

Verfügbare Versionen

Die Collection ist in zwei verschiedenen Formaten verfügbar:

BrunoBruno Desktop Appbruno/*.bru + environments/
PostmanPostmanpostman/*.json

Beide Versionen enthalten denselben Test-Workflow und dieselben Requests.

Voraussetzungen

Schnellstart

Mit Bruno

  1. Bruno öffnen → Open Collection → den Ordner bruno/ auswählen.
  2. Oben rechts die Umgebung auswählen.
  3. Nur bei Bedarf: Identifier anpassen, siehe unten (Testdaten anpassen)
  4. Requests der Reihe nach ausführen.

Hinweis: In Bruno den Entwicklungsmodus (Developer Mode) aktivieren. Im Standardmodus (Safe Mode) begrenzt Bruno die Größe von Requests/Scripts; der Batch-Aufruf in Gruppe 7 (10 Rechnungen inkl. PDF-Anhang je Eintrag) kann dadurch scheitern.

Mit Postman

  1. Postman öffnen → Import → DiPag-Fachdienst-Test-Collection-v1.0-ru-dev-0.3.1.json auswählen (aus postman/ Ordner).
  2. Environment importieren (aus postman/ Ordner).
  3. Die Umgebung oben rechts auswählen.
  4. Nur bei Bedarf: Identifier anpassen, siehe unten (Testdaten anpassen)
  5. Requests der Reihe nach ausführen.

Hinweis: In Postman werden die einzelnen Requests in der Sidebar manchmal nicht in der korrekten Reihenfolge angezeigt. Das ist nur ein Anzeigeproblem, die Ausführungsreigenfolge entspricht der Nummerierung. Bei Bedarf kann man in der Sidebar die Sortier-Reihenfolge auf "alphabetisch" umstellen.

Workflow-Übersicht

Die Requests sind in Gruppen organisiert und müssen in dieser Reihenfolge ausgeführt werden, da spätere Schritte Variablen verwenden, die von früheren Schritten gesetzt werden.

Gruppe 1 – Accounts anlegen

1.1ArztpraxisPraxis-Account anlegen (POST /PractitionerAccount)
1.2Versicherung (Kostenträger)Kostenträger-Account anlegen (POST /InsuranceAccount)
1.3Versicherte PersonPatienten-Account anlegen (POST /InsurantAccount)
1.4Abrechnungsdienstleister (ADL)ADL-Account anlegen (POST /PractitionerAccount)

Gruppe 2 – Arztpraxis versendet Rechnung

2.1ArztpraxisVersicherte Person per FHIR suchen (GET /fhir/Patient) → speichert fhir-patient-id
2.2ArztpraxisRechnung im Testmodus validieren (POST /fhir/Patient/{id}/$invoice-submit, modus: test) → erwartet HTTP 400 mit Fehlerliste
2.3ArztpraxisRechnung mit Anhang senden (POST /fhir/Patient/{id}/$invoice-submit) → speichert rechnungs-token
2.4ArztpraxisAngereichertes PDF per Token abrufen (POST /fhir/DocumentReference/$retrieve)

Gruppe 3 – Versicherte Person ruft ab und entzieht Berechtigung

3.1Versicherte PersonRechnungsliste abrufen (GET /fhir/DocumentReference) → speichert angereichertes_pdf_url
3.2Versicherte PersonAngereichertes PDF herunterladen (direkt)
3.3Versicherte PersonAngereichertes PDF als FHIR Binary abrufen
3.4Versicherte PersonMarkierungen setzen – Bezahlt/Gelesen (POST /fhir/DocumentReference/{id}/$process-flag)
3.5Versicherte PersonZustimmungen abrufen (GET /permission)
3.6Versicherte PersonZustimmung für Hausarzt entziehen (POST /permission/{id}/status)

Gruppe 4 – Arztpraxis sendet Rechnung nach Entzug

4.1ArztpraxisVersicherte Person nach Entzug suchen (GET /fhir/Patient) → prüft, ob Patient noch auffindbar
4.2ArztpraxisRechnung nach Entzug senden (POST /fhir/Patient/{id}/$invoice-submit) → erwartet Fehler wegen Entzug

Gruppe 5 – Kostenträger ruft Rechnung ab

5.1KostenträgerAngereichertes PDF per Token abrufen (POST /fhir/DocumentReference/$retrieve)
5.2KostenträgerNur Binary-Links abrufen (POST /fhir/DocumentReference/$retrieve)
5.3KostenträgerStrukturierte Daten per Token abrufen (POST /fhir/DocumentReference/$retrieve) → speichert rechnungsinhalt-binary-url
5.4KostenträgerStrukturierte Daten direkt abrufen (GET auf rechnungsinhalt-binary-url)

Gruppe 6 – Versicherte Person löscht Rechnung

6.1Versicherte PersonDirektes Löschen der Rechnung (POST /fhir/DocumentReference/{id}/$erase) → erwartet HTTP 412, da Rechnung nicht im Papierkorb
6.2Versicherte PersonRechnung in den Papierkorb verschieben (POST /fhir/DocumentReference/{id}/$change-status)
6.3Versicherte PersonRechnung aus dem Papierkorb löschen (POST /fhir/DocumentReference/{id}/$erase)
6.4Versicherte PersonRechnungsliste erneut abrufen (GET /fhir/DocumentReference) → erwartet keine Treffer mehr

Gruppe 7 – Abrechnungsdienstleister sendet Massendaten

Der Abrechnungsdienstleister (ADL) reicht mehrere Rechnungen gebündelt in einem FHIR-Batch asynchron ein und fragt das Ergebnis per Polling ab.

7.1ADLVersicherte Person per FHIR suchen (GET /fhir/Patient) → speichert fhir-patient-id
7.2ADLBatch-Bundle mit 10 Rechnungen inkl. Anhang asynchron senden (POST /fhir, Header Prefer: respond-async) → erwartet HTTP 202 mit content-location-Header
7.3ADLPolling 1 – einmalig abfragen, ob das Ergebnis fertig ist (GET {content-location}) → erwartet HTTP 202 (noch in Verarbeitung) oder 200 (fertig)
7.4ADLPolling 2 – ungeduldiges, zu häufiges Nachfragen (GET {content-location}) → erwartet HTTP 429 (Too Many Requests) oder 200 (fertig)
7.5ADLPolling 3 – geduldiges, automatisiertes Warten unter Beachtung des Retry-After-Headers, bis das Ergebnis vorliegt → erwartet HTTP 200 mit FHIR-Bundle (10 Einträge)


Hinweis: Die Requests 7.3–7.5 demonstrieren unterschiedliches Polling-Verhalten auf denselben Batch-Job und können unabhängig voneinander ausgeführt werden.

Gruppe 99 – Accounts löschen

99.1ArztpraxisPraxis-Account löschen (DELETE /PractitionerAccount/{id})
99.2KostenträgerKostenträger-Account löschen (DELETE /InsuranceAccount/{id})
99.3Versicherte PersonPatienten-Account löschen (DELETE /InsurantAccount/{id})
99.4Abrechnungsdienstleister (ADL)ADL-Account löschen (DELETE /PractitionerAccount/{id})

Testdaten anpassen

Alle Testparameter befinden sich in der Environment-Datei:

DiPag_RU-DEV_environment.bru (für Bruno)
DiPag_RU-DEV_environment.json (für Postman)

Für jeden neuen Testdurchlauf müssen diese Werte eindeutig sein:

ktr-telematikID
Telematik-ID des Kostenträgers
K202605261
praxis-telematikID
Telematik-ID der Praxis
P202605261
adl-telematikID
Telematik-ID des ADL
A20270910
patient-kvnr
Krankenversicherungsnummer
V202605261
rechnungsnummer
Eindeutige Rechnungsnummer
RE-202605261
befundid
ID des mitgesendeten Anhangs
B202606034

Weitere konfigurierbare Felder sind Patientendaten (Name, Geburtsdatum, Adresse), Arztdaten, Rechnungspositionen und die PDF-Anlagen (als Base64 in den Umgebungsvariablen KI-Reiseimpfung-Gelbfieber-b64 und KI-untersuchung-b64).

Für die 10 Rechnungen des Massendaten-Batches (Gruppe 7) werden Rechnungsnummern und Anhang-IDs automatisch im Pre-Request-Script generiert (RE-2026001–RE-2026010 bzw. B2026001–B2026010) und müssen nicht manuell gepflegt werden.

Hinweis: Wird die Suite vollständig in einem Durchlauf ausgeführt, müssen die Identifier nicht vor jedem Testlauf neu gesetzt werden. Gruppe 99 löscht am Ende automatisch alle angelegten Accounts (Praxis, Kostenträger, Versicherte Person, Abrechnungsdienstleister), sodass dieselben Identifier im nächsten Durchlauf erneut verwendet werden können.

Fachdienst-Container

Um schnell gegen die fachlichen Schnittstellen des DiPag Fachdienstes (ohne ZETA) entwickeln zu können veröffentlicht die Gematik das jeweils aktuelle Release des DiPag Fachdienst auch als OCI Container:

⬇️ DOWNLOAD ⬇️ dipag-anwendungsdienst:0.2.0.0.tar.gz (Fachdienst-Docker-Image)

Die Veröffentlichung des Images mit dem vollständigen Fachdienst, der den aktuellen Stand der RU-DEV - Umgebung widerspiegelt ist derzeit in Arbeit und für November 2026 geplant.

Der DiPag-Fachdienst-Container benötigt als externe Abhängigkeiten

Die Integration mit diesen Abhängigkeiten ist beispielhaft in folgender docker-compose-Konfiguration gezeigt.

name: dipag

services:

  DiPag-MariaDB:
    image: mariadb:latest
    container_name: mariadb
    command: --port=3306
    ports:
      - "3306:3306"
    environment:
      MARIADB_ROOT_PASSWORD: root
      MARIADB_DATABASE: dipag
    volumes:
      - dipag-mariadb-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 15s
      interval: 10s
      timeout: 5s
      retries: 5

  DiPag-S3:
    image: minio/minio:latest
    container_name: s3-minio
    command: server /data --console-address ":9101"
    ports:
      - "9100:9000"
      - "9101:9101"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    volumes:
      -  dipag-s3-data:/data
    healthcheck:
      test: ["CMD", "mc", "ready", "local"]
      start_period: 10s
      interval: 10s
      timeout: 5s
      retries: 5

  DiPag-Fachdienst:
    image: dipag-anwendungsdienst:0.2.0.0
    container_name: DiPag-Fachdienst
    ports:
      - "8080:8080"
      - "8081:8081"
    environment:
      SPRING_DATASOURCE_URL: jdbc:mariadb://mariadb:3306/dipag
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: root
      DIPAG_BLOB_URL: http://s3-minio:9000
      DIPAG_BLOB_ACCESS_KEY: minioadmin
      DIPAG_BLOB_SECRET_KEY: minioadmin
      DIPAG_BLOB_REGION: us-east-1
      DIPAG_BLOB_BUCKET: dipag
      DIPAG_BLOB_TEMP_DIR: /tmp/dipag
    depends_on:
      DiPag-MariaDB:
        condition: service_healthy
      DiPag-S3:
        condition: service_healthy

# named volumes
volumes:
  dipag-mariadb-data: 
  dipag-s3-data:

Auslesen von strukturierten Rechnungsdaten

Minimal-Beispiel eines Java-Programms zum Auslesen von strukturierten Rechnungsdaten aus einem angereicherten PDF der Digitalen Patientenrechnung.

⬇️ DOWNLOAD ⬇️ rechnunglesen.zip

Start mit dem Tool "maven":

$ mvn -q -Dexec.args="response.pdf"


Verfügbarkeit der Entwicklungs-Tools



v0.2.0 (05/2026)v0.3.1 (07/2026)

v0.4.0 (11/2026)

v1.0.0 (1.12.2026)

Source Code des Fachdienstes verfügbar

geplantgeplant
Docker-Image verfügbar für lokale Tests✅
geplantgeplant
Entwicklungsumgebung verfügbar (ru-dev)
✅geplantgeplant
Referenzumgebung verfügbar (ru)


geplant
Produktionsumgebung verfügbar (pu)


geplant
Postman/Bruno Testsuite
✅geplantgeplant
Account API (OpenAPI)
✅geplantgeplant
FHIR-IG-Version
1.0.71.4.x geplant
ZETA-Guard-Version
1.3.3