Stream: implementers
Topic: State transition operations
Lloyd McKenzie (Apr 12 2017 at 22:28):
When we initially created the Task resource, we defined a number of operations for things like suspending, resuming, stopping, cancelling and making other specific manipulations to the Task resource. We yanked them prior to publication on the grounds that these were all functions that could be performed using a simple RESTful "update" and we had no clear guidance as to when systems might want to use an operation-based rather than pure REST-based approach to making such changes.
In subsequent discussion, the primary advantage of an operation-based approach is that it provides a simpler way of tracking and enforcing more granular access control and audit than a basic REST update. As well, the operation approach provides for the possibility of cascading a status change through descendant tasks rather than just updating the primary task (though this would likely only be feasible if all descendant tasks were under the control of the same server that owned the root task.)
Before the FHIR workflow project takes any further action on developing/standardizing operations for Task or recommending the existence of operations for other resources, we wanted to see what requirements (if any) the implementation community has for operations supporting state changes on FHIR resources.
So: Do you want state-change operations? What are your use-cases for them?
If we don't get a response, we'll leave the state-change operation space alone until someone comes forward asking for them.
Grahame Grieve (Apr 15 2017 at 21:34):
the use case would appear to indicate that the server isn't in a position to do a diff analysis between current and posted....
Last updated: Apr 12 2022 at 19:14 UTC
