Ein durchgängiger Ablauf für rechnungserstellende Systeme wie die von Praxen oder Abrechnungsdienstleistern:

Schritt 1 – Voraussetzungen schaffen

  • SMC-B (Org) mit Telematik-ID und einer der Rollen "Betriebsstätte Abrechnungsdienstleister", "Betriebsstätte Arzt" oder "Zahnarztpraxis" müssen vorliegen.
  • Für die Testumgebungen können Testzertifikate von der Gematik bezogen werden

Schritt 2 – Zugriff herstellen

Alle folgenden Aufrufe auf die einzelnen APIs benötigen von den ZETA-Komponenten des Fachdienstes ausgestellte Access Tokens. Damit diese ausgestellt, werden muss sich das rechnungserstellende System beim Fachdienst registrieren:

Unter ZETA-Client ist am Beispiel der Java-Plattform ein vollständiger Zugriff auf den Fachdienst über ZETA gezeigt.

Schritt 3 – Konto anlegen

Bevor Rechnungen gesendet werden können, muss die sendende Institution ein Konto im Fachdienst anlegen. Dabei stimmt das Institut der Verwendung von Telematik-ID und Name (der Praxis oder des Abrechnungsdienstleisters) zu. Telematik-ID und Anzeigename entnimmt der Fachdienst dem Zertifikat/Token, es wird nicht im HTTP Body übergeben:

POST https://dev.digitale-patientenrechnung.de/api/PractitionerAccount HTTP/1.1
Content-Type: application/json

{
  "zustimmungVerwendungTelematikID": true,
  "zustimmungVerwendungAnzeigename": true
}

Antwort: 201 Created .Existiert das Konto schon: HTTP-Status 409. Ohne Konto ist kein Versand möglich.
Weitere Details zu diesem Aufruf finden sich in OpenAPI-Beschreibung unter Entwicklungs-Tools

Benötigte Scopes zum Anlegen des Kontos: "dipag practitionerAccount.crud"

Schritt 4 – Rechnungsempfänger prüfen

Bevor eine Rechnung versendet wird, muss die Zieladresse der Rechnung mit KVNR und Geburtsdatum abgefragt werden (im Beispiel V202606242 und 1.1.1970). So kann festgestellt werden ob die versicherte Person ein Konto hat und dem Versand nicht widersprochen hat. Das Resultat des Aufrufs ist eine technische ID des Empfängers (Patient.id), die für den Versand benötigt wird. 

GET https://dev.digitale-patientenrechnung.de/fhir/Patient?identifier=V202606242&birthdate=1970-01-01 HTTP/1.1
Accept: application/fhir+json


Antwort 200 OK, ein searchset-Bundle mit genau einem Patient (gekürzt):

 {
  "resourceType": "Bundle", "type": "searchset", "total": 1,
  "entry": [ { "resource": {
    "resourceType": "Patient", "id": "4711",
    "identifier": [ { "system": "http://fhir.de/sid/gkv/kvid-10", "value": "V202606242" } ],
    "name": [ { "given": ["Manfred"], "family": "Mustermann" } ],
    "birthDate": "1970-01-01"
  } } ]
}

Bei 404 als Antwort ist ein Versand nicht möglich. Das heißt, die versicherte Person hat entweder kein Konto oder dem Rechnungsversand widersprochen (der Fachdienst unterscheidet das nach außen nicht). In diesem Fall muss die Rechnung der versicherten Person auf herkömmliche Weise zugestellt werden

Details: FHIR IG Use Case R0

Benötigte Scopes zum Prüfen des Rechnungsempfängers: "dipag insurantAccount.rs"

Schritt 5 – Rechnung erstellen

Das rechnungserstellende System benötigt

  • (a) das Original-PDF im Format PDF/A-1 oder PDF/A-2 und
  • (b) die strukturierten Daten als FHIR-Bundle (JSON) und
  • optional (c) Anhänge als PDF/A-1 oder A2.

PDF und Bundle werden Base64-kodiert in eine DocumentReference (den "Umschlag") gelegt. Ein Beispiel findet sich in: Das Rechnungsformat - MVP

Schritt 6 – Rechnung im Testmodus validieren

Mit modus=test prüft der Fachdienst die Rechnung, speichert aber nichts und stellt nichts zu. So können insbesondere während der Entwicklung vor dem eigentlichen Versand Fehler behoben werden. Der Aufruf ist eine FHIR-Operation $invoice-submit auf der ID des Empfängers.

POST https://dev.digitale-patientenrechnung.de/fhir/Patient/4711/$invoice-submit HTTP/1.1
Content-Type: application/fhir+json
Accept: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "rechnung", "part": [ { "name": "dokument", "resource": {
        "resourceType": "DocumentReference",
        "meta": { "profile": [ "https://gematik.de/fhir/dipag/StructureDefinition/dipag-dokumentenmetadaten-eingang-patient" ] },
        "status": "current",
        "type": { "coding": [ { "system": "http://dvmd.de/fhir/CodeSystem/kdl", "code": "AM010106", "display": "Rechnung ambulante/stationäre Behandlung" } ] },
        "description": "Rechnung Reiseimpfung vom 10.01.2024",
        "subject": { "display": "Max Mustermann" },
        "content": [
          { "format": { "system": "https://gematik.de/fhir/dipag/CodeSystem/dipag-attachment-format-cs", "code": "originaleRechnung" },
            "attachment": { "contentType": "application/pdf", "data": "<base64 des PDF/A der Original-Rechnung>" } },
          { "format": { "system": "https://gematik.de/fhir/dipag/CodeSystem/dipag-attachment-format-cs", "code": "rechnungsinhalt" },
            "attachment": { "contentType": "application/fhir+json", "data": "<base64 des Rechnungsbundles>" } }
        ]
    } } ] },
    { "name": "modus", "valueCode": "test" }
  ]
}

Antwort: 200 OK mit FHIR-Parameters-Objekt (möglicherweise mit Warnungen als OperationOutcome mit Schweregrad "warning").

Bei schweren Fehlern: 400 mit OperationOutcome.

Details: FHIR IG Use Case R1

Benötigte Scopes zum Senden einer Rechnung (Testmodus): "dipag invoiceDoc.cr"

Schritt 7 – Rechnung senden

Derselbe Aufruf wie im vorigen Schritt mit modus=normal (oder ohne modus, Standard ist "normal"). Der Fachdienst prüft auf Duplikate, validiert, speichert, erzeugt das angereicherte PDF (also das um DataMatrix-Code und strukturierte Daten angereicherte Dokument) und benachrichtigt die versicherte Person über den Erhalt einer neuen Rechnung.

Mit angereichertesPDF=true bekommt man das angereicherte PDF (inkl. DataMatrix-Code und eingebetteter strukturierter Daten) gleich in der Antwort.

Anhänge kommen als weiterer Parameter "anhang" dazu (gleicher Aufbau, Format rechnungsanhang):

 { "name": "anhang", "part": [ { "name": "dokument", "resource": {
    "resourceType": "DocumentReference",
    "meta": { "profile": [ "https://gematik.de/fhir/dipag/StructureDefinition/dipag-dokumentenmetadaten-eingang-patient" ] },
    "status": "current",
    "identifier": [ { "type": { "coding": [ { "system": "https://gematik.de/fhir/dipag/CodeSystem/dipag-rechnung-identifier-type-cs", "code": "anhang" } ] },
                      "system": "https://example.org/fhir/sid/anhangids", "value": "987-654-321" } ],
    "type": { "coding": [ { "system": "http://dvmd.de/fhir/CodeSystem/kdl", "code": "PT130102", "display": "Molekularpathologiebefund" } ] },
    "description": "Molekularpathologiebefund vom 31.12.21",
    "content": [ { "format": { "system": "https://gematik.de/fhir/dipag/CodeSystem/dipag-attachment-format-cs", "code": "rechnungsanhang" },
                   "attachment": { "contentType": "application/pdf", "data": "<base64 des Anhangs im PDF/A Format>" } } ]
} } ] },
{ "name": "angereichertesPDF", "valueBoolean": true }

Der Fachdienst kann Dokumentreferenzen der rechnungserstellenden Systeme speichern, also Rechnungsnummern, Dokument-Kennungen von Befunden usw. Bei den Rechnungen selbst wird die Rechnungsnummer als Teil der strukturierten Daten übermittelt. Da derzeit für Anhänge keine strukturierten Daten unterstützt werden, kann die Dokumentenkennung als Identifier hier separat übermittelt werden (im Beispiel "987-654-321"). 

Antwort 200 OK (gekürzt): je Dokument ein "token" mit der Token-ID (id), der Dokumentreferenz des rechnungserstellenden Systems und dem angereicherten PDF (sofern angefordert über "angereichertesPDF=true"):

 {
  "resourceType": "Parameters",
  "parameter": [
    { "name": "token", "part": [
      { "name": "id", "valueId": "<64-stelliges-Rechnungs-token>" },
      { "name": "angereichertesPDF", "resource": { "resourceType": "Binary", "contentType": "application/pdf", "data": "…" } }
    ] },
    { "name": "token", "part": [
      { "name": "id", "valueId": "<64-stelliges-Anhangs-token>" },
      { "name": "docRef", "valueIdentifier": { "system": "https://example.org/fhir/sid/anhangids", "value": "987-654-321" } }
    ] }
  ]
}


Die Tokens können vom rechnungserstellenden System gespeichert werden. Sie sind der Schlüssel, um das angereicherte PDF später abzurufen. Das kann z.B. dazu genutzt werden, der versicherten Person den angereicherten Ausdruck der angereicherten Rechnung auszuhändigen.

Ein erneutes Senden derselben strukturierten Rechnungsdaten und desselben Rechnungs-PDF führt zur Ablehung des PDF durch einen 409 Conflict Fehler. In der OperationOutcome steht dann der Eingangszeitstempel der der Rechnung mit der die gesendeten Daten in Konflikt stehen.

Details: FHIR IG Use Case R1. Dort finden sich auch die Details, wann eine Rechnung als Duplikat einer anderen Rechnung vom Fachdienst abgelehnt wird.

Benötigte Scopes zum Senden einer Rechnung (Normal-Moduls): "dipag invoiceDoc.cr"

Positionierung DataMatrix-Code in angereichertem PDF

Die Datamatrix-Codes werden immer unten links auf der Originalrechnung angereichert. Falls das originale Rechnungsdokument und die Anhänge die in ISO 5008 Form A und Form B angegebenen Ränder umsetzen, ist sichergestellt, dass der Datamatrix-Code keine Rechnungselemente überdeckt:



Sollte das Layout der Rechnung jedoch abweichen, kann das rechnungserstellende System beim Übermitteln für jedes einzelne Dokument eine alternative Position des Datamatrix-Codes festlegen. Die entsprechende FHIR-Operation ermöglicht dazu das Setzen von

  • rechnung.barcodePosition.x
  • rechnung.barcodePosition.y
  • anhang.barcodePosition.x
  • anhang.barcodePosition.y

Details dazu stehen in der Parameter-Liste: https://simplifier.net/guide/digitalepatientenrechnung-implementierungsleitfaden/startseite/szenarien/re-ps-als-akteur#AF_10136

Markieren von Rechnungsanhängen als "persönlich"

Rechnungserstellende Systeme können Rechnungsanhänge als "persönlich" markieren, um anzuzeigen, dass die so markierten Dokumente nicht für das Einreichen bei einem Kostenträger bestimmt sind (z.B. Begleitschreiben, Anschreiben, usw.). Diese Markierung wird dann in den Apps der versicherten Personen angezeigt. 

Um einen Anhang als "persönlich" zu markieren muss die Markierung in der DocumentReference gesetzt werden, die den "Umschlag" repräsentiert. Siehe Das Rechnungsformat - MVP.

Schritt 8 – Angereichertes PDF erneut abrufen

Wurde das PDF beim Senden nicht angefordert oder wird es später erneut benötigt, kann es per Token abgerufen werden. Über die Flags kann man auswählen, welche Datenobjekte zurückgegeben werden sollen:

POST https://dev.digitale-patientenrechnung.de/fhir/DocumentReference/$retrieve HTTP/1.1
Content-Type: application/fhir+json
Accept: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "token", "valueString": "<64-stelliges-token>" },
    { "name": "pdf", "valueBoolean": true },
    { "name": "strukturierterRechnungsinhalt", "valueBoolean": false },
    { "name": "originaleRechnung", "valueBoolean": false }
  ]
}
 

Die Antwort 200 OK liefert die DocumentReference (Parameter "dokument") und wenn beim Aufruf pdf=true gesetzt wurde, das PDF als Binary Ressource.
Über diese Funktion können nur vom jeweiligen rechnungserstellenden System selbst erstellte Rechnungen abgerufen werden; ein Abruf ändert den Status der Rechnung für die versicherte Person nicht. 
Versicherte Personen können die ihnen zugestellten Rechnungen im Fachdienst jederzeit löschen. Sollte die Rechnung inzwischen gelöscht worden sein, antwortet der Fachdienst mit einen HTTP 404-Fehler

Details: FHIR IG Use Case R3

Benötigte Scopes zum Abruf einer einzelnen Rechnung: "dipag invoiceDoc.cr"

Schritt 9 – Variante: viele Rechnungen auf einmal versenden (Batch)

Sollten größere Rechnungs-Mengen versendet werden müssen, können mehrere $invoice-submit-Aufrufe in einem FHIR-Batch-Bundle an den Fachdienst übermittelt werden. Der Fachdienst arbeitet hier asynchron. Nach Übermittlung erhält das rechnungserstellende System einen HTTP Status-Code 202 Accepted und im Header Content-Location die Adresse, für das kontinuierliche Abfragen ("Polling").

 POST https://dev.digitale-patientenrechnung.de/fhir/ HTTP/1.1
Content-Type: application/fhir+json
Prefer: respond-async

{
  "resourceType": "Bundle", "type": "batch",
  "entry": [
    { "request": { "method": "POST", "url": "Patient/4711/$invoice-submit" },
      "resource": { "resourceType": "Parameters", "parameter": [ "… wie in Schritt 7 …" ] } },
    { "request": { "method": "POST", "url": "Patient/0815>/$invoice-submit" },
      "resource": { "resourceType": "Parameters", "parameter": [ "…" ] } }
  ]
}

HTTP/1.1 202 Accepted
Content-Location: <absolute-url-zum-polling>

Das Polling geht dann durch ein 

GET <absolute-url-zum-polling> HTTP/1.1

Mögliche Statuswerte im Ergebnis dieses GET-Requests:

  • 202 Accepted: noch in Arbeit: Bitte warten später erneut nachfragen.
  • 429 Too Many Requests (mit Retry-After): zu häufig gefragt, bitte entsprechend warten. Im MVP wird als Retry-After-Header immer die Uhrzeit und nicht die Anzahl an Sekunden übertragen. Als Referenz-Server-Uhrzeit der Response kann der darin enthaltene "Date"- Header genutzt werden.
  • 200 OK: fertig. Der Body ist ein batch-response-Bundle mit einem Ergebnis je Rechnung.

Der Fachdienst begrenzt derzeit eine Batch-Übermittlung auf 100 Rechnungen oder 1 GB. Noch größere Datenmengen müssen vom rechnungserstellenden System in mehrere kleinere Batches unterteilt werden. Geht die Antwort verloren, kann das Bundle erneut gesendet werden: bereits verarbeitete Rechnungen werden wie in Schritt 7 behandelt und liefern die ursprüngliche Antwort. 

Details: FHIR-IG Use Case 2

Benötigte Scopes für den Batch-Versand mehrere Rechnungen: "dipag invoiceDoc.cr"

Schritt 10 – Korrektur statt Storno

Eine gesendete Rechnung lässt sich nicht zurückziehen oder stornieren; löschen kann sie nur die versicherte Person. Ein Fehler wird durch eine Korrekturrechnung behoben: Das rechnungserstellende System sendet eine neue Rechnung, deren strukturierte Daten auf Rechnungsnummer und Token der zu korrigierenden Rechnung verweisen.

Im Rechnungsbundle (Profil "dipag-rechnung") trägt man dafür zwei optionale Extensions ein: Korrekturrechnung (Referenz auf die ersetzte Rechnung) und Korrekturtoken (Identifier mit dem Token der ersetzten Rechnung). Die Rechnungsnummer der ersetzten Rechnung steht im Datenfeld "Info Korrekturrechnung". 

Details: FHIR Datenobjekt Rechnung sowie Das Rechnungsformat - MVP

Benötigte Scopes für die Korrektur einer Rechnung: "dipag invoiceDoc.cr"

Schritt 11 – Konto löschen

Eine Institution kann ihr Konto löschen. Der Aufruf benötigt die eigene Telematik-ID im Pfad, sie muss zu der Telematik-ID aus der verwendeten SMC-B-Org Identität passen.

DELETE https://dev.digitale-patientenrechnung.de/api/PractitionerAccount/> HTTP/1.1

Antwort bei Erfolg: 204 No Content

Antwort 404, wenn es kein Konto gibt.

Ein bereits ausgesprochener Widerspruch einer versicherten Person gegen Ihre Institution bleibt auch nach Löschen und Neuanlegen bestehen.

Das Löschen des Institutskontos führt nicht zum Löschen der durch dieses Institut erstellten Rechnungen.

Weitere Details zu diesem Aufruf finden sich in OpenAPI-Beschreibung unter Entwicklungs-Tools

Benötigte Scopes für das Account-Löschen: "dipag practitionerAccount.crud"


  • No labels

© gematik GmbH 2025