Support the FHIR PATCH interaction (FHIRPath Patch)

[schwzr]

Motivation

The DSF FHIR server currently supports create, read, vread, update, delete, search and history, but not the FHIR PATCH interaction. Clients that only want to modify part of a resource have to read the full resource, change it locally and send a complete update. This is unnecessarily verbose, is prone to lost-update problems in concurrent scenarios, and prevents callers (e.g. BPE
process plugins) from expressing a targeted change such as "set this Task's status" without transferring the whole resource.

PATCH is part of the FHIR RESTful API (https://www.hl7.org/fhir/http.html#patch) and is currently reported as not supported in the server's CapabilityStatement.

Proposed solution

Add support for the FHIR PATCH interaction using the FHIRPath Patch format (a Parameters resource, https://www.hl7.org/fhir/R4/fhirpatch.html):

• Direct REST:
  • PATCH [type]/[id]
  • conditional PATCH [type]?[search criteria]
• Inside transaction and batch bundles (Bundle.entry.request.method = PATCH)

A patch is applied to a copy of the current resource and then written through the existing update code path, so authorization, validation, optimistic locking (If-Match), versioning and the Prefer header behave exactly as for an update. PATCH maps to the existing UPDATE role — no new permission is required.

Advertise patch as a supported interaction in the CapabilityStatement.

Scope

In scope

• FHIRPath Patch format (Parameters with operation parameters: add / insert / delete / replace / move)
• REST (standard + conditional) and bundle (transaction + batch)
• FhirWebserviceClient support: patch(...) / patchConditionaly(...)
• Unit tests for the patch engine, integration tests for the interaction

Out of scope (for now)

• JSON Patch (application/json-patch+json) and XML Patch (application/xml-patch+xml) — intentionally omitted to avoid pulling in hapi-fhir-storage (JPA/Hibernate/Quartz) and keep the dependency footprint minimal. FHIRPath Patch is also the FHIR-recommended format for FHIR resources. Can be added later if a concrete need arises.
• Resolving temporary (urn:uuid:) references contained inside patch values when processed within a bundle.

Acceptance criteria

• PATCH [type]/[id] with a FHIRPath Parameters body updates the addressed resource and returns the result according to the Prefer header; a new version is created.
• Conditional PATCH [type]?[criteria] patches the single match, returns 404 on no match and 412 on multiple matches.
• PATCH entries work inside transaction and batch bundles.
• Authorization is enforced via the existing update rule (reasonUpdateAllowed(old, patched)); If-Match is honored.
• An invalid or inapplicable patch returns 400 with an OperationOutcome; a patch to a non-existing resource returns 404.
• The CapabilityStatement lists the patch interaction for the supported resource types.
• No new runtime dependency is added.
• Unit and integration tests cover the above.