Repository navigation
Managing resource contention when suggesting/accepting updates #452
Description
Activity
Note that this is referring to scenarios where the suggested update is to a persisted resource, not a scratch pad or otherwise in-memory resource that is not yet persisted.
Hey @dennispatterson ,
I think that the optimal case is that it's not possible for
another workflow [to] make an update before the [CDS Hook's card's] action is accepted
But, perhaps that's a short-sighted perspective.
Did you have in mind specific "Semantics/documentation" that would handle this scenario?
Why not simply declare it as out of scope?
Isaac
- added a commit that references this issue
on Jul 28, 2025
FHIR manages resource contention by the inclusion of an If-Match request header on a PUT to indicate that an update should only be applied if the current version of the resource matches what that caller received when it was read. Otherwise, two "simultaneous" updates could trample one another.
When a CDS service returns a card with a suggested update to a FHIR resource, there is no concept of supplying something like an If-Match. However, if another workflow makes an update before the action is accepted, loss of data could result. Semantics/documentation need to be added for handling this scenario.