Version 1.0.8

Profile und Extensions

• DiPagDokumentenmetadatenIntern: Das Dokumenttoken wird als eigener Identifier-Slice Token (System https://gematik.de/fhir/sid/dipag-token, Kardinalität 1..1) profiliert. Das Token ist damit nicht mehr mit der technischen DocumentReference.id identisch und MUSS so vergeben werden, dass es nicht aus der DocumentReference.id ableitbar ist.
• DiPagDocumentReferenceMarkierung: Die separate gelesen-Sub-Extension (boolean) samt zugehöriger Invariante wurde entfernt – der Gelesen-Status wird ausschließlich über den Markierungstyp abgebildet. Max-Length (1024) für die Markierungsdetails (details) und den Anzeigetext des kostentraeger ergänzt.
• DiPagDokumentenmetadatenEingang: Max-Length (1024) für Markierungsdetails und Coding-Anzeigetexte (type.coding.display) ergänzt.

CapabilityStatement und Search Parameter

• Bei DocumentReference die read-Interaktion und den Suchparameter _id entfernt: Es gibt keinen Use Case, in dem nach der technischen Ressourcen-id gesucht bzw. ein Dokument darüber gelesen werden muss. Der Abruf erfolgt ausschließlich über die $retrieve-Operation (per Token) bzw. die fachlichen Suchparameter.
• DiPagDokumentenmetadatenIntern: Slicing von context.related (patient, anhaenge) so umgestellt, dass es ohne Auflösung der Referenz funktioniert. Der Diskriminator nutzt nun Reference.type (Typ pattern auf Pfad type) statt $this.resolve(). Dadurch ist eine einzelne DocumentReference auch ohne Bundle-Kontext (z.B. als Ergebnis von $retrieve oder der Suche) validierbar. Hinweis: Der Fachdienst MUSS Reference.type (Patient bzw. DocumentReference) in context.related setzen.

OperationDefinitions

• DiPagOperationSubmit (invoice-submit): Klarstellung der Validierungssemantik – zusätzliche, nicht profilierte Extensions in den Eingangsressourcen (Parameter rechnung und anhang) werden nicht ignoriert, sondern abgelehnt (strikte Validierung).
• DiPagOperationProcessFlag (process-flag): Korrektur der mit 1.0.7 eingeführten Festlegungen. Kardinalität des Eingabeparameters markierung von 1..* auf 0..* geändert: Da $process-flag der einzige Endpunkt zur Pflege der Markierungen ist und nach dem Complete-Replacement-Prinzip arbeitet, war das vollständige Löschen aller Markierungen mit der bisherigen Mindestkardinalität nicht möglich. Ein leerer Markierungssatz entfernt nun alle änderbaren Markierungen; die nicht änderbaren Markierungen persönlich und abgerufen durch KTR bleiben ausgenommen. Beschreibung der Operation sowie Verarbeitungsschritte in {{pagelink:AF_10160}} entsprechend präzisiert (zuvor inkonsistente Hinzufügen-Semantik).

Szenarien und API-Änderungen

• Bulk-Einreichung ({{pagelink:AF_10136-Bulk}}): Korrektur der asynchronen Verarbeitung an die FHIR-Vorgaben zum asynchronen Request Pattern – die Annahme des batch-Bundles wird nun mit 202 - Accepted bestätigt und die Polling-URL über den Content-Location-Header (statt Location) mitgeteilt. Beispiele entsprechend angepasst (R2 zuvor fälschlich 200 - OK als Erfolgsfall).
• Bulk-Abruf per Token ({{pagelink:AF_10271-Bulk}}): Die Verarbeitung wurde von asynchron wieder auf synchron umgestellt – die Annahme erfolgt nicht mehr mit 202 - Accepted und Polling über eine Content-Location-URL, sondern der FD gibt das batch-response-Bundle direkt mit 200 - OK im Body zurück. Hintergrund: Der Fachdienst implementiert diese Schnittstelle aktuell ausschließlich synchron. Die gematik bittet die Clienthersteller um Feedback, ob eine synchrone oder eine asynchrone Ausgestaltung bevorzugt wird (siehe Hinweis auf der Szenario-Seite).

Sonstige Änderungen

• Umstellung auf artefakt-individuelle Versionierung: Die Version eines Conformance-Artefakts wird nur noch angehoben, wenn sich dessen Inhalt ändert, und kann daher unterhalb der Paketversion liegen. Details siehe "Hinweis zu Artefakt-Versionen".