Stream: implementers
Topic: Action List
Dave Barnet (Apr 07 2021 at 08:48):
I have a use case whereby a client is dealing with an "action", in this case a Referral, and at a point in the referral process may ask the server for a list of "currently available actions" that may be carried out (given a state model that is maintained for referrals). The action list is literally a coded list of available actions.
I think we are are looking at an Operation to POST the idenifier of the Referral to an Endpoint, which would return the list of currently available actions, given the server's understanding of the state (status) of the referral.
I'm struggling to match the "currently available action list" to an appropriate resource? Task looks like a candidate, but that's more about a request to do something (this is merely a list of actions you could perform, not actions you are requested to perform. There are a couple of definitional resources (ActivityDefinition & PLan Definition) that sort of fit - but not quite. Any thoughts on how to return a "currently available action list"? (by the way, its a STU3 implementation).
Lloyd McKenzie (Apr 08 2021 at 02:24):
Task can have an intent of 'proposal' if you don't want to specifically say "this is definitely something that should be done".
Kevin Mayfield (Apr 08 2021 at 07:41):
Would it be a problem to do this as R4? I'm thinking perceived difficulties are not as high as actual difficulties (and actual problems will be more on STU3).
Kevin Mayfield (Apr 08 2021 at 07:49):
Think Task with intent of proposal works. Sounds like an operation where given a ServiceRequest what are the the next Tasks that can be (/need to be done).
Or GET /Task?group-identifier.identifier={referral identifier}&intent=proposal
As the ServiceRequest changes status the Task proposal resources would change.
Lloyd McKenzie (Apr 08 2021 at 15:38):
Whether GET will work will depend on whether the Tasks are pre-existing. With an operation, the Tasks could be 'generated' based on current state and protocol.
Dave Barnet (Apr 13 2021 at 14:34):
@Lloyd McKenzie - Just another clarification on this query. As stated previously, we are just returning an Action List to the client. There are no stored Tasks on the server, we create them when the client requests a list currently available actions. Should we be using Task.requester (The creator of the task), or Task.owner (Individual organization or Device currently responsible for task execution) to hold the details of who made the call to get the currently available actions? - I'm leaning towards Task.owner, as that's the person responsible for the Task execution.
Lloyd McKenzie (Apr 14 2021 at 04:07):
Right. The invoker of the operation is saying "what should I do" and the 'owner" is the doer. The system that's saying "you should do this" would probably be the software that's executing the decision support to come up with the task list - though it might also populate Task.instantiates to refer to the protocol(s) it used in making that determination
Last updated: Apr 12 2022 at 19:14 UTC
