Ein durchgängiger Ablauf für Systeme von Kostenträgern. Versicherte reichen Rechnungen bei ihrem Kostenträger ein; im aktuellen Stand geschieht das außerhalb des Fachdienstes, per Post mit DataMatrix-Code oder digital über die App der Versicherten. Der Fachdienst dient dem Kostenträger dazu, zu einem Token die Rechnungsdaten abzurufen

Informationen für Kostenträger, die Rechnungsobjekte per Token aus dem Fachdienst beziehen wollen

Schritt 1 – Voraussetzungen

• SMC-B (Org) mit Telematik-ID und der Rolle "Betriebsstätte Kostenträger" muss 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:

• Für eine Reihe von Plattformen ist ein SDK verfügbar, welches den Zugriff auf den ZETA-geschützten Fachdienst ermöglicht: https://github.com/gematik/zeta-sdk
• Sofern das SDK nicht eingesetzt werden kann, hilft folgender ZETA-Primärsystem Implementierungsleitfaden weiter: https://gemspec.gematik.de/docs/gemILF/gemILF_ZETA_API/

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

Schritt 3 – Konto anlegen

Für den Abruf per Token benötigt der Kostenträger ein Konto im Fachdienst. Durch das Anlegen stimmt die Kostenträger-Institution der Verwendung von Telematik-ID und Name des Kostenträgers durch den Fachdienst zu. (Dadurch können versicherte Personen sehen, welche Kostenträger-Institution Rechnungsdaten vom Fachdienst abgerufen hat). Telematik-ID und Anzeigename entnimmt der Fachdienst dem Zertifikat/Token, es wird nicht im HTTP Body übergeben.

Antwort bei Erfolg: HTTP-Status 201 Created.

Existiert das Konto schon: HTTP-Status 409.

Ohne Konto ist kein Abruf von Rechnungsdaten möglich.

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

Schritt 4 – Token beschaffen

Ein Token identifiziert genau ein Dokument (Rechnung oder Anhang). Das Token ist ein zufälliger, 64-stelliger Hex-Wert ohne personenbezogene Daten. Kostenträger erhalten es auf einem von 2 Wegen:

• Post: Jede Seite eines ausgedruckten Rechnungsdokuments trägt einen DataMatrix-Code. Er enthält nur das Token (plus eine Typkennung). Kostenträger können den Code automatisiert über Scanner auslesen.
  
  Beispiel-Datamatrix-Code der Digitalen Patientenrechnung:
  
  
  
  Inhalt des Codes:
  

  urn:dipag:rechnung:v1:988b8d318ba20bfa7da4a19a91a184e7b32fcb73f0c052478e6797b84ed8ab01

  
  
  
• Digital (sofern implementiert): Kostenträger, die Ihren Versicherten über eine App eine Funktion zum Abrufen und Einreichen von Rechnungen bereitstellen, können ein durch eine versicherte Person in der App abgerufenes Token direkt an das Kostenträger-Backend weitergeben.

Schritt 5 – Rechnung per Token abrufen

Das Kostenträger-System ruft mit dem Token die Operation $retrieve auf. Im Body des POST - Request kann über drei Flags das gewünschte Format gewählt werden, was direkt zurückgegeben werden soll:

Bei Erfolg: Antwort HTTP-Status 200 OK. In der Antwort sind neben dem angeforderten Format auch einige strukturierte Daten aus der Rechnung enthalten:

• Rechnungsdatum
• Rechnungsnummer
• Gesamtbetrag
• Fachrichtung
• behandelte Person
• Behandler

Dazu sind unabhängig vom gesetzten Parameter die FHIR-Binary-URLs enthalten, unter denen jedes Rechnungsformat einzeln abgerufen werden kann.

Beispiel-Antwort (gekürzt), wenn nur das angereicherte PDF angefordert wird. Die URLs zu allen drei Rechnungsformaten sind in der Antwort enthalten, aber das angereicherte PDF ist zusätzlich direkt eingebettet.

Nach erfolgreichem Aufruf der $retrieve-Operation wird die Rechnung im Fachdienst markiert. Die versicherte Person kann dann, je nach Ausgestaltung ihrer App, einen Hinweis auf der Rechnung sehen:  "abgerufen durch <Kostenträger>".

Schritt 6 – Strukturierte Daten auswerten

Die strukturierten Daten sind ein FHIR-Bundle (collection) mit einer Rechnung (Invoice), den Positionen (ChargeItem), Patient, behandelnder Person und Rechnungsersteller. 

Details zum Rechnungsformat: Das Rechnungsformat - MVP.

Schritt 8 – Konto löschen

Eine Institution kann ihr Konto löschen. Der Aufruf braucht die eigene Telematik-ID im Pfad, sie muss zu der im Token übereinstimmen.

Antwort bei Erfolg: 204: No Content; 

Antwort 404, wenn es kein Konto gibt.

Das Löschen des Institutskontos führt nicht zum Löschen der Markierungen (siehe Schritt 5)

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

Informationen für Kostenträger, die das angereicherte Rechnungs-PDF auf anderem Weg erhalten

Kostenträger müssen im MVP der Digitalen Patientenrechnung nicht zwingend am Fachdienst "angeschlossen" sein, um strukturierte und validierte Rechnungsdaten verarbeiten zu können.  Rechnungen, die Versicherte über ihre Apps aus dem Fachdienst herunterladen, können auch auf anderen Wegen zum Kostenträger gelangen. ("Teilen"-Funktion in einer App, Upload in einem existierenden Webportal beim Kostenträger, ....)

Der Fachdienst Digitale Patientenrechnung bettet daher die vom Rechnungsersteller übermittelten strukturierten Daten in das angereicherte PDF ein. Dadurch können Kostenträger-Systeme, die nur das angereicherte PDF erhalten, dennoch automatisiert auf die vom Fachdienst validierten Rechnungsdaten zugreifen.

Die Rechnungsinhalte im PDF sind in "Das Rechnungsformat - MVP" beschrieben. Der Mime-Type der Strukturierten Daten wird an dieser Stelle immer `application/fhir+json` sein.

Der Anhang im PDF heißt "strukturierterRechnungsinhalt.json".

Am Beispiel der Java-Libraries "gson" und "pdfbox" könnte das Auslesen der Strukturierten Rechnungsdaten (hier: Rechnungsdatum und Betrag) so implementiert werden (kompletter Source Code unter Entwicklungs-Tools):

    static final String ANHANG = "strukturierterRechnungsinhalt.json";

    String json = leseAnhang(new File("angereicherteRechnung.pdf));
    JsonObject invoice = findeInvoice(JsonParser.parseString(json).getAsJsonObject());

    LocalDate datum = LocalDate.parse(invoice.get("date").getAsString());

    // Gesamtbetrag: Invoice.totalGross
    JsonObject total = invoice.getAsJsonObject("totalGross");
    BigDecimal betrag = total.get("value").getAsBigDecimal();

    System.out.println("Rechnungsdatum: " + datum.format(DateTimeFormatter.ofPattern("dd.MM.yyyy")));
    System.out.println("Gesamtbetrag:   " + betrag.setScale(2) + " " + total.get("currency").getAsString());

    static String leseAnhang(File pdf) throws Exception {
        try (PDDocument doc = PDDocument.load(pdf)) {
            PDEmbeddedFilesNameTreeNode anhaenge = doc.getDocumentCatalog().getNames().getEmbeddedFiles();
            PDComplexFileSpecification datei = (PDComplexFileSpecification) anhaenge.getValue(ANHANG);
            return new String(datei.getEmbeddedFile().getByteArray(), StandardCharsets.UTF_8);
        }
    }

    static JsonObject findeInvoice(JsonObject bundle) {
        for (JsonElement entry : bundle.getAsJsonArray("entry")) {
            JsonObject res = entry.getAsJsonObject().getAsJsonObject("resource");
            if ("Invoice".equals(res.get("resourceType").getAsString())) {
                return res;
            }
        }
        throw new IllegalArgumentException("Keine Invoice-Ressource im Bundle gefunden");
    }
}

Signatur

Rechnungen, die nicht direkt vom Fachdienst bezogen werden, könnten auf dem Weg zum Kostenträger manipuliert werden. Aus diesem Grund sind alle Rechnungen, die aus dem Fachdienst Digitale Patientenrechnung stammen, mit einer Signatur versehen. Kostenträger können somit die Integrität und Authentizität der erhaltenen Rechnungsobjekte selbst verifizieren.