Stream: workflow
Topic: Tasks in Messages
Richard Kavanagh (Oct 03 2017 at 21:08):
We are proposing to use Tasks in a Messaging solution to provide some very simple workflow mechanisms. Has anyone tackled tasks in messaging anywhere? Are there any known changes in this are for R4?
Lloyd McKenzie (Oct 03 2017 at 21:11):
I'm involved in a Canadian project that's using Tasks in messaging extensively around e-prescribing and "secure email". Project has been underway for about 1.5 years and has been in production for over 6 months.
Lloyd McKenzie (Oct 03 2017 at 21:12):
Only changes I'm aware of are some small changes to align with updates to the workflow request and event patterns. We agreed on a couple more changes to those on Monday and I hope to have them completed for final review for our Wed. workflow call.
Richard Kavanagh (Oct 03 2017 at 21:13):
OK thanks - where is the workflow / event material documented?
Lloyd McKenzie (Oct 03 2017 at 21:24):
build.fhir.org/event.html and build.fhir.org/request.html. (Task implements both patterns.)
Richard Kavanagh (Oct 03 2017 at 22:24):
So... If there was a message there would be a BUNDLE with a MESSAGEHEADER pointing to a TASK resource.
Richard Kavanagh (Oct 03 2017 at 22:26):
When the task has been "done" then should the response be in the Task.Output or MessageHeader.Response
Lloyd McKenzie (Oct 03 2017 at 23:12):
We always chose to respond to tasks with updated versions of the tasks. Essentially conveying the information the same way as if we'd just updated the Task with REST, but using messaging as the delivery mechanism.
René Spronk (Oct 19 2018 at 15:29):
I'm preparing some educational materials for a DevDays tutorial on OrderComms/result reporting. REST is a repository kind of model, hence the need for workflow applications and the Task resource.
It would seem that in FHIR Messaging there's no need to use Task, given the business/workflow-expectations associated with a trigger event: once the Request of a order placer has arrived at a order filler, the order filler creates its own (filler-) Request and manages the status thereof, and messages that (filler-)request back to the placer. As such the placer can monitor the status of the execution of its request. Using parent/child relationships on Request one can deal with what would be sub-tasks in the RESTful Task resource.
Lloyd McKenzie (Oct 19 2018 at 15:42):
At one point, I'd proposed possibly yanking event and one or two things out of MessageHeader and having it point to Task instead to have consistency across the messaging and Rest paradigms, but there wasn't much interest at the time. (There wasn't much interest in messaging generally.)
René Spronk (Oct 20 2018 at 09:47):
Looking at the characteristics of the various paradigms, REST doesn't seem to be the best option for Workflow or ordercoms, so I expect there to be lots of operations. "Find all tasks which could be fulfilled by me" is an operation, there's lots of business rules behind that. "Cancel my filler-part of a task" is probably an operation for it might impact a lot of resources that I (as a Filler) already created.
I'm aware this is early days when it comes to Workflow management in FHIR, for me this topic in FHIR is new (I haven't really looked at it in earnest before), but even with knowledge of v2/v3/IHE XDW the documentation (or better yet: the guidance related to real world scenarios) seems minimalistic at this point in time.
In general, Task in a message sounds superfluous, unless we start introducing workflow-definitions in messaging. Up to now such workflow agreements are out of bounds and require prior agreement between communicating parties, i.e. no need to explicitly reference the agreed upon workflow definition.
Lloyd McKenzie (Oct 20 2018 at 12:37):
There's never a reason to have to do messaging for workflow. Task.code is just as capable as MessageHeader.event. The reason for consistency is to avoid paradigm- specific variation when we're saying "please do".
René Spronk (Oct 20 2018 at 14:11):
I never intended to say that one would need messaging to do workflow - the paradigms nicely sit next to each other and can be used where appropriate. What I'm saying is that REST/CRUD (without operations) doesn't seem to be a terribly good paradigm for workflow support (ok, documents would be lots worse). But I guess workflow will always be messy, regardless of the paradigm.
Having 'centralized' workflow management (which is not always the case, I'm aware of that) doesn't fit very well with the client-orchestration nature of REST. Even in IHE XDW (which is client driven) one can't really get around the use of centralized workflow managers for complex workflows.
Question: have any operations been considered/proposed for Task ?
Lloyd McKenzie (Oct 21 2018 at 03:25):
We had operations but yanked them because we weren't sure why anyone would use them
Lloyd McKenzie (Oct 21 2018 at 03:51):
Don't understand why centralized workflow wouldn't fit well with REST. Task fits with a variety of architectures as documented in the workflow section of the spec.
René Spronk (Oct 21 2018 at 07:41):
Anyways, I now see this is the equivalent of the v3 ControlAct. Not a very well understood part of v3, so we'll have to make sure that somehow people understand the FHIR Task, which fulfills this role (and more). Task is very meta/abstract/flexible, which makes it hard to understand.
In my presentation I'll definitely be mentioning operations, I can't see how one could use Task without them (bar trivial workflows).
Lloyd McKenzie (Oct 21 2018 at 22:40):
Why would you need an operation? You post a Task indicating what needs to be done. The performer updates the Task once they've agreed to take it on and again once they have the results. Operations are only needed if systems don't expect to have a participant without a Task endpoint.
René Spronk (Oct 22 2018 at 06:14):
For example: As a filler, to find out what tasks should/could be executed by me is not that trivial an exercise, especially if one has a centralized Task queue. If we have a centralized load balancing system then certainly an operation would be called for; the filler doesn't get to decide what tasks they take on, that would be determined by the load balancer.
But even if we don't have a load balancing system, simply querying for tasks with certain characteristics is quite tricky. GET /Task?status=requested&intent=order,original-order&focus:ServiceRequest.category=laboratory (or perhaps focus.code in a value set) would also return any Requests which have been rejected (by this same filler) in the past. It could also include any 'dangling' resources which aren't properly managed anymore by any particular system or which got suck in the workflow somehow.
Example #2: suppose as a filler I've embarked on the creation of filler-orders, Observations, DiagnosyicReport and supporting resources for a particular task, and then (whilst still working on the task) the filler discovers the Task is cancelled by the placer. A Task/$cancel-output operation would allow for the cancellation of all output resources without having to navigate the various output resources one by one.
Lloyd McKenzie (Oct 22 2018 at 15:38):
If you have load balancing, then the load balancer will look at the tasks, look at what's asked for and update the Task to be "assigned" to a particular performer - who can then reject or accept. On rejectioon, the load balancer can create a new Task for a different performer. "Could be executed by me" would be a filter on the performer type and/or chained filter criteria on the task focus. Operation isn't going to make that any simpler
Lloyd McKenzie (Oct 22 2018 at 15:41):
It's not obvious that cancelling the Task would result in cancelling the outputs. If you do need to cancel them, you're going to have to iterate over all of them to cancel anyhow - though you can do that easily with a Batch. You certainly could create a custom operation for that purpose, but it's not clear why a custom operation would be better than a batch - and it's certainly much less likely to get implemented.
René Spronk (Oct 24 2018 at 08:55):
It's more of a gut feeling that there will be more server side logic to this than meets the eye. It's like scheduling: everything could be done by the clients, and yet the Argonaut implementation guide for scheduling mainly relies on a couple of server side operations, to $find, $hold and $book appointments. OrderComms is not that different from Scheduling, other than that it introduces more complexity and flexibility on how to do things. Sure, we can wait for the first implementation guides to appear and then we'll know whether they chose to use operations, but I'll bet they do. Maybe it's because I don't trust clients to do the right thing; client-side orchestration and this kind of complexity are IMHO not a good match. Time will tell.
Grahame Grieve (Oct 24 2018 at 09:01):
I agree that there'll be strong reliance on operations for actions that affect mutliple resources. Task itself won't be the focus on those operations, which is why most of them were removed; just update the resource.
René Spronk (Oct 24 2018 at 13:56):
As a filler, one would probably have to define operations on Task, given that depending on the requested service all sorts of Resource types could have been created already as outputs of the Task. The only real alternative is to use the filler-order as the focus of the operation, but when I look at the FHIR spec this doesn't always have to exist. $cancel on serviceRequest makes sense, but if there's no filler-order a $cancel on Task will be necessary.
Question: is a filler-order an output of a Task ? Or would task.output just be the DiagnosticReport/Observations (the result of the filler order)?
Using may lab example: The status of a filler-order depends on the status of a Task, which in turn depends on the status of a Filler-order, which in turn depends on the status of a DiagnosticReport which may depend on the status of the underlying Observations. No wonder people find this to be a complex topic.
Lloyd McKenzie (Oct 25 2018 at 03:41):
A filler order could be added to a Task as an output, but it's not a given. The status of the filler order does not depend on the status of the Task. If a request for fulfillment is revoked, the filler might choose to complete anyhow because they've passed the point of no return and intend to bill for it regardless. The same is true for cancellation of an order when there's a Task in progress.
René Spronk (Oct 26 2018 at 11:00):
Sure - the status of a placer order depends on the status of the task. From your answer I see that apparently the filler-order isn't normally regarded to be an output of a Task. The filler-order relationship with the placer-order is 'direct' and not via Task.
Lloyd McKenzie (Oct 26 2018 at 14:46):
"depends on" is a little strong. "is influenced by" is a bit more accurate. If a fulfillment Task is complete, that's a cue to the placer system to evaluate whether it wants to mark the Request as complete. But there are lots of reasons why it wouldn't. And even if the Task never gets marked as completed, the placer might mark the order as completed anyhow.
Lloyd McKenzie (Oct 26 2018 at 14:47):
There are business decisions that determine what the relationship is between placer and filler orders. Task is a communication vehicle. But there's never a guarantee that everything will be in sync.
Lloyd McKenzie (Oct 26 2018 at 14:48):
And operations don't make any of that nuance go away...
Last updated: Apr 12 2022 at 19:14 UTC
