Version 1.4.0

Diese Version enthält nicht rückwärtskompatible Änderungen am Profil DiPagPatient (Name verpflichtend) sowie an der API (Entfernung des Bulk-Abrufs per Token), daher der Sprung auf 1.4.0.

Profile und Extensions

• DiPagPatient: Das Element name ist nun verpflichtend (Kardinalität 0..* → 1..*) (Breaking Change). Der Name der behandelten Person ist im fachlichen Modell ein Pflichtfeld; bisher war er im Profil lediglich als SOLL-Angabe empfohlen. Patient-Instanzen ohne Namen werden ab dieser Version bei der Validierung abgelehnt, Rechnungen ohne Namen der behandelten Person werden somit vom Fachdienst zurückgewiesen.
• DiPagRechnung: Der Kommentar zu subject (behandelte Person) wurde entsprechend angepasst: Der Name der behandelten Person MUSS angegeben werden (bisher SOLL).
• DiPagDokumentenmetadatenIntern: Der Kommentar zu subject stellt klar, dass der Fachdienst bei Anhängen die behandelte Person analog zu den Rechnungen in subject abbilden MUSS. subject wird dabei von der Rechnung übernommen, mit der der Anhang im selben Submit übermittelt wurde.

CapabilityStatement

• Neue systemweite Interaktion batch (Expectation SHALL). Die zugehörige documentation beschreibt, welche Interaktionen und Operationen innerhalb eines batch-Bundles zulässig sind: die Suche nach Rechnungsempfängern (search-type auf Patient), $invoice-submit an Patient und an Organization (jeweils asynchron) sowie $change-status. Alle übrigen Interaktionen und Operationen, insbesondere $retrieve, $process-flag und $erase, werden innerhalb eines batch-Bundles nicht unterstützt und müssen einzeln aufgerufen werden. Eine maschinenlesbare Kennzeichnung pro Operation sieht die FHIR-Kernspezifikation (R4 bis R6) nicht vor.

Szenarien und API-Änderungen

• Bulk-Abruf per Token (AF_10271-Bulk): Der Anwendungsfall wurde vorerst aus dem Implementierungsleitfaden entfernt (Breaking Change). Entfernt wurden die Szenarioseite "R4: Abfrage von angereicherten PDF/A per Token (Rechnungsersteller) (Bulk)", der zugehörige Abschnitt auf der Seite "Akteure und Interaktionen" sowie die Beispiele BulkRetrieveExampleInput, BulkRetrieveExampleOutput, BeispielParameterRetrieveInput2 und BeispielDocumentReferenceRechnungRetrieve2. Die Operation $retrieve ist nur noch als Einzelabruf ({{pagelink:AF_10271}}) spezifiziert. Die Nummerierung der übrigen Szenarien bleibt unverändert.
• Rechnung mit Dokumenten validieren und versenden ({{pagelink:AF_10136}}): Die Verarbeitungsschritte im FD stellen klar, dass DocumentReference.subject für Anhänge analog zu den Rechnungen zu setzen ist.

Redaktionelle Änderungen

• In den Release Notes früherer Versionen wurden die Verweise auf die entfernte Szenarioseite AF_10271-Bulk durch Klartext ersetzt.