Implementation Guide
ePA Medication Service
Version 1.2.0-ballot.2 - draft

## OperationDefinition: Batch eMP Einträge

Official URL: https://gematik.de/fhir/epa-medication/OperationDefinition/batch-emp-entries-op | Version: 1.2.0-ballot.2
Draft as of 2025-09-02 | Computable Name: batchEMPEntries_MedicationSvc

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.

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).