Persistent vs transient PlanDefinition $apply
# support
v
There seems to be some abmiguity in R4 about whether PlanDefinition $apply should be a transient or persistent operation, which is later disambiguated in R5 and in the Clinical Practice Guidelines. In the latter 2 (and other related documentation), the spec is explicit that the $apply operation is transient - "Note that result of this operation is transient (i.e. none of the resources created by the operation are persisted in the server, they are all returned as entries in the result Bundle(s)). The result effectively represents a proposed set of activities, and it is up to the caller to determine whether and how those activities are actually carried out and/or persisted." Having the operation return the response, instead of persisting it, makes it possible for the caller to control idempotency/transaction-bundles/if-match optimistic locking, etc and inject user requested overrides where appropriate before persisting. Are there any plans to consider moving towards the transient implementation of $apply? And implementing $apply more fully in general?
r
Good question. Teams in general are developing custom operations to support this type of use case https://www.medplum.com/docs/bots/custom-fhir-operations
9 Views