Ein durchgängiger Ablauf für rechnungserstellende Systeme wie die von Praxen oder Abrechnungsdienstleistern:
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.
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 { |
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" |
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
{ |
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" |
Das rechnungserstellende System benötigt
PDF und Bundle werden Base64-kodiert in eine DocumentReference (den "Umschlag") gelegt. Ein Beispiel findet sich in: Das Rechnungsformat - MVP
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 { |
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" |
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": { |
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"):
{ |
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" |
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
Details dazu stehen in der Parameter-Liste: https://simplifier.net/guide/digitalepatientenrechnung-implementierungsleitfaden/startseite/szenarien/re-ps-als-akteur#AF_10136
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.
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 { |
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" |
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 { HTTP/1.1 202 Accepted |
Das Polling geht dann durch ein
GET <absolute-url-zum-polling> HTTP/1.1
Mögliche Statuswerte im Ergebnis dieses GET-Requests:
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" |
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" |
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" |