Confirm the server supports FHIRPath Patch by checking the CapabilityStatement for application/fhir+json patch support and any server-specific documentation
Construct the patch as a Parameters resource with parameter elements: each has a name of operation and a part array containing name/value pairs for type (insert, delete, replace, add, move), path (FHIRPath expression), and value (the new value resource element)
Send PATCH [base]/[ResourceType]/[id] with Content-Type: application/fhir+json and If-Match: W/"[versionId]" for optimistic locking; the body is the Parameters resource
The server evaluates each FHIRPath expression against the resource and applies the mutation; on success it returns 200 with the updated resource or 204
Validate FHIRPath expressions against the resource structure before sending; use a FHIRPath library (e.g., fhirpath.js) to test expressions locally
Handle 400 if the FHIRPath expression fails to resolve or the operation is not supported; examine the OperationOutcome for diagnostic details
Known gotchas
FHIRPath Patch and JSON Patch use different Content-Type values (application/fhir+json vs application/json-patch+json); mixing them up causes the server to reject or misparse the patch
FHIRPath expressions in patches must resolve to exactly the target node; expressions that match multiple nodes or no nodes will cause errors on strict servers
The Parameters resource structure for FHIRPath Patch is FHIR-version-specific; verify the correct part name conventions against the FHIR spec version the server implements
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp