Stream: workflow
Topic: Tasks and other requests
Josh Mandel (Jun 24 2021 at 22:29):
Since we've identified many places where a Task might be the only resource tracking a request, is there a reason not to allow Observation.basedOn to reference a task?
Josh Mandel (Jun 24 2021 at 22:29):
(And presumably this question applies to many other references to request-y type stuff.)
Lloyd McKenzie (Jun 24 2021 at 23:36):
basedOn is about the flow of 'authorization'. In general Tasks drive workflow, but not authorization. If an Event is linked with a Task, it's typically done via Task.output. Do you have a use-case where there would be an Observation with no corresponding ServiceRequest or other driving Request instance where the authorization would flow only from a Task?
Josh Mandel (Jun 24 2021 at 23:43):
I have use cases where things like observations and questionnaire responses might be associated with a task. Earlier you were saying how for things like communication request you would just skip the request resource and use a task to model the workflow, so I'm trying to figure out where the boundaries are.
Josh Mandel (Jun 24 2021 at 23:45):
In practice I could create all kinds of pseudo request resources artificially -- tasks, service requests, etc. It's frustrating to have to pick the "right" kind of request bucket in circumstances where all you really are going to know is a code. Some codes might have to do with nutrition, others might have to do with procedures, others might have to do with at home exercises or meds...
Josh Mandel (Jun 24 2021 at 23:45):
I was thinking that task was the way to get around this pain.
Lloyd McKenzie (Jun 25 2021 at 00:09):
Ok. The question then is whether there's a reason for the Event to point to the Task when the typical behavior is for the Task to point to the Event (and we prefer not to have bi-directional references).
Josh Mandel (Jun 25 2021 at 00:15):
The use case here has to do with demonstrating (at the time of creating the event) that it is being created because of an existing task/request/whatever
Lloyd McKenzie (Jun 25 2021 at 02:33):
And is linking it from the Task not sufficient?
Josh Mandel (Jun 25 2021 at 02:38):
There will be an ongoing stream of data arriving. Can't easily link to all of it from the task.
Josh Mandel (Jun 25 2021 at 02:39):
I guess I just don't understand why we wouldn't allow pointing to a task as the basis for an Observation
Lloyd McKenzie (Jun 25 2021 at 13:17):
You absolutely can. It just creates a challenge of Task pointing to the Observation as output and Observation pointing to the Task as basedOn - which is something we generally prefer not to do.
Josh Mandel (Jun 25 2021 at 19:24):
You absolutely can
How? There's no option for Reference(Task).
Vassil Peytchev (Jun 25 2021 at 19:38):
I think Lloyd means that you can keep adding links to Observation to Task.output
Lloyd McKenzie (Jun 25 2021 at 23:30):
Right now you'd have to do it with an extension. I'm saying that if we decide it's necessary, it can be done and if we decide the need is common enough, it can be added to core. I just think it creates challenges with bi-directional references and will also create confusion in cases where there's both a Request and a Task.
Eric Haas (Jun 28 2021 at 02:35):
Right now if you want to represent a task to for patient to create observation X without extensions you would need:
Eric Haas (Jun 28 2021 at 15:57):
Looking at this decision tree It does not cover pushing data where the push may be rejected or accepted or may need human review and may be async. This tree would lead me to propose an operation, but I think Task could do the same thing. The use case is "solicited or unsolicited" Patient Write/ "unsolicited" Provider - Provider write (CDEX and Argo). A basic FHIR RESTful CREATE is looking less feasible unless it is really an operation in disguise ( which I am fine with as long as we are all aware what it is)
Vassil Peytchev (Jun 28 2021 at 17:07):
I think the decision tree has some changes to it. I was trying to reconcile it with decisions related to workflow management, but ran out of time, and didn't want to hold up the IG just for it. I think once you add workflow considerations to it, it may become a matrix, and not a tree.
Lloyd McKenzie (Jun 28 2021 at 17:19):
If the Task is saying "please fulfill this request", the link from Task would be 'focus', not 'basedOn'.
Eric Haas (Jun 29 2021 at 17:57):
Lloyd McKenzie said:
If the Task is saying "please fulfill this request", the link from Task would be 'focus', not 'basedOn'.
always a source of confusion for me since it is anti-pattern to all other event resources.
see FHIR-29636
Eric Haas (Jun 29 2021 at 18:03):
Vassil Peytchev (Jun 29 2021 at 18:13):
Also, the Observation is the output of the Task, isn't it?
Eric Haas (Jun 29 2021 at 19:27):
yes this only show the"pre-completed" state.
Lloyd McKenzie (Jun 29 2021 at 20:41):
Task.basedOn is "where does the authorization for this flow from". Task.focus is "what am I supposed to perform the Task.code action on". When you're seeking fulfillment, the thing to fulfill is definitely the latter.
Kevin Mayfield (Sep 19 2021 at 09:12):
I've got a slight mapping issue. What I want to represent is a prescription order fulfilment which can have several medicationrequests.
At present I've put the medication requests in input and used a snomed procedure code to represent the Task type. I don't have a focus.
My use of type in task.input.type doesn't feel right, it feels like it's a task type.
Kevin Mayfield (Sep 19 2021 at 09:27):
Focus I'm using to link to groupIdentifier
Parnesh Raniga (Sep 19 2021 at 09:30):
Kevin Mayfield said:
I've got a slight mapping issue. What I want to represent is a prescription order fulfilment which can have several medicationrequests.
At present I've put the medication requests in input and used a snomed procedure code to represent the Task type. I don't have a focus.
My use of type in task.input.type doesn't feel right, it feels like it's a task type.
Wouldn't the requests go into basedOn?
Lloyd McKenzie (Sep 19 2021 at 15:59):
The requests definitely don't go into 'basedOn'. That would be "what authorizes you to ask for fulfillment". It would never be "what you're asking to be fulfilled". What you want to be fulfilled is always Task.focus.
If you want to ask for 3 distinct orders to be fulfilled, you'll need 3 distinct Tasks, as a different decision could be made about each of them. If you want to treat the fulfillments as part of an overall request, you could certainly make them sub-tasks.
Parnesh Raniga (Sep 20 2021 at 00:07):
Thanks @Lloyd McKenzie . I got my wires crossed between "what authorizes you to ask for fullfillment" and "what you're asking to be fulfilled".
Kevin Mayfield (Sep 23 2021 at 07:14):
Do we ever need medication requests to be fulfilled as a single entity? It all or nothing.
I’m after discounting that as a use case.
Lloyd McKenzie (Sep 23 2021 at 23:40):
@Kevin Mayfield, I'm not quite following your question
Kevin Mayfield (Sep 24 2021 at 06:39):
I need an example. I was thinking drug A and B need to be fulfilled together.
Lloyd McKenzie (Sep 24 2021 at 16:15):
So you're asking if there's a business requirement for that sort of behavior? Might be better asking that on #Medication
Kevin Mayfield (Sep 28 2021 at 08:13):
thanks. I'll check internally - gut feeling is it may happen but not often.
Last updated: Apr 12 2022 at 19:14 UTC
