Generated Narrative: OperationDefinition batch-emp-entries-op Profile: OperationDefinition Profil für TI FHIR Data Service URL: [base]/$$batch-emp Parameters Use Name Scope Cardinality Type Binding Documentation IN resource 1..1 Bundle FHIR-Bundle vom Typ transaction gemäß des Profils gemäß EPABatchEmpRequestBundle. Die Ausführungssemantik ist serverseitig festgelegt. Verboten: direkte POST/PUT/DELETE auf Ressourcen außerhalb von Operationen. OUT return 1..1 Bundle Antwort ist ein Bundle vom Typ transaction-response (bei atomarer Server-Policy. Für jeden Request-Entry enthält die Antwort einen korrespondierenden Entry mit: response.status (HTTP-Status), resource = Parameters (Ergebnisse von $add-emp-entry / $update-emp-entry), beim letzten Eintrag ($emp-commit): eine Provenance-Instanz (neue eMP-Plan-Version).
Mit der Batch Operation $batch-emp können Primärsysteme mehrere fachliche Änderungen am eMP in einem Aufruf an den Medication Service übergeben. Innerhalb des Request-Bundles werden ausschließlich FHIR-Operationen ausgeführt (keine direkten Resource-CRUDs). Am Ende wird ein emp-commit ausgeführt, der eine neue Plan-Version (Provenance) erzeugt. Die Operation antwortet mit einem Bundle vom Typ transaction-response.
Stapelverarbeitung von eMP-Änderungen mit konsistenter, atomarer Ausführung und anschließender Versionierung des eMP. Reduziert Roundtrips, vermeidet Zwischenzustände und stellt eine neue Plan-Version bereit.
FHIR-Bundle vom Typ transaction gemäß des Profils gemäß EPABatchEmpRequestBundle. Die Ausführungssemantik ist serverseitig festgelegt. Verboten: direkte POST/PUT/DELETE auf Ressourcen außerhalb von Operationen.
Antwort ist ein Bundle vom Typ transaction-response (bei atomarer Server-Policy. Für jeden Request-Entry enthält die Antwort einen korrespondierenden Entry mit: - response.status (HTTP-Status), - resource = Parameters (Ergebnisse von $add-emp-entry / $update-emp-entry), - beim letzten Eintrag ($emp-commit): eine Provenance-Instanz (neue eMP-Plan-Version).