batch-emp-entries-op
type: OperationDefinition
node role: treeRoot
id:
  v: batch-emp-entries-op
meta:
  profile:
    v: https://gematik.de/fhir/ti/StructureDefinition/ti-operationdefinition
    l: ti-operationdefinition
text:
  status:
    v: generated
  div:
    v: 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).
extension:
  url:
    v: https://gematik.de/fhir/ti/StructureDefinition/extension-http-method
    l: extension-http-method
  value: Code
    v: POST
url:
  v: https://gematik.de/fhir/epa-medication/OperationDefinition/batch-emp-entries-op
  l: batch-emp-entries-op
version:
  v: 1.3.2
name:
  v: batchEMPEntries_MedicationSvc
title:
  v: Batch eMP Einträge
status:
  v: active
kind:
  v: operation
date:
  v: 2026-03-20
publisher:
  v: gematik GmbH
contact:
  name:
    v: gematik GmbH
  telecom:
    system:
      v: url
    value:
      v: https://www.gematik.de
  telecom:
    system:
      v: email
    value:
      v: patientteam [ at ] gematik.de
description:
  v: 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). Als letzte Operation ein $emp-commit ausgeführt, der eine neue Plan-Version (Provenance) erzeugt. Die Operation antwortet mit einem Bundle vom Typ transaction-response.
jurisdiction:
  coding:
    system:
      v: urn:iso:std:iso:3166
      l: 3166
    code:
      v: DE
purpose:
  v: 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.
affects state:
  v: true
code:
  v: batch-emp
system:
  v: true
type:
  v: false
instance:
  v: false
parameter:
  name:
    v: resource
  use:
    v: in
  min:
    v: 1
  max:
    v: 1
  documentation:
    v: 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.
  type:
    v: Bundle
parameter:
  name:
    v: return
  use:
    v: out
  min:
    v: 1
  max:
    v: 1
  documentation:
    v: 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).
  type:
    v: Bundle