Managing resource contention when suggesting/accepting updates

[dennispatterson]

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.

[dennispatterson]

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.

[isaacvetter]

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