Stream: implementers
Topic: Task dependencies
Orlando Osorio (Jul 21 2020 at 21:20):
We use tasks to model most of our non-trivial workflows, and some of those tasks are automated.
We need to model dependencies between some tasks, e.g.:
Task #1: pay for Invoice/5
Task #2: send a fax to the pharmacy
Task/2 is automated, but we need to block it by Task/1, so that when someone balances Invoice/5, only then the fax is sent.
We looked at putting Task/2 with status on-hold and add Task/1 as an input to Task/2 with a label of blockedBy or dependsOn. While that works for the moment, we were thinking maybe it made sense to have something more "first-class", so the queries are more explicit, the intent is more apparent and the implementation easier.
We can, of course, add an extension, but wanted to know if this is something that made sense to have in FHIR.
Lloyd McKenzie (Jul 22 2020 at 05:04):
It probably doesn't make sense to have as part of core, but it's potentially reasonable to have this included as a standard extension. You could submit a change request. You might also look at RequestGroup, which allows strict dependency of a bunch of Request resources (of which Task is one). However, it doesn't allow for independent state transitions of the governed requests - the state is maintained at the RequestGroup level.
Orlando Osorio (Jul 22 2020 at 14:58):
We use RequestGroups when we want to orchestrate more complex operations.
We looked at them for this scenario but we feel that using them would change the root resource of some operations. Most of the time we don't have dependencies and backend services just look for active tasks to perform (by code and owner). It also adds a new "thing" to create for seemingly simple user actions.
Our goal is to build upon the Task abstraction to provide an easy to use, easy to understand, data-oriented interface for the end-user and we think most of it is achievable using Task as a building block. The only piece we've found missing is the ability to link Tasks with a label (blocked-by, depends-on, related, superseded, etc)
Would you consider instead of adding a dependsOn property to core having something more generic and extensible like MedicationKnowledge.relatedMedicationKnowledge?
Vassil Peytchev (Jul 22 2020 at 15:22):
Isn't a depends-on relationship expressible with PlanDefinition? It seemed to me that was what we have been discussion in the FHIR workflow calls...
Orlando Osorio (Jul 22 2020 at 15:29):
While it is expressible we would have to name it, create a new "thing", coordinate state changes, move the responsibility up the graph, and introduce PlanDefinition (and CarePlans?) to our model.
In our case, the dependency is managed at the task level, practitioners and office staff understand those dependencies at that level, A is blocked by B, C is related to D, etc.
We already use PlanDefinition and CarePlans in other contexts, we have protocols that fit perfectly in the PlanDefinition resource. But we think the needs here are a bit lighter.
As an example of the type of interface we are building for Task management, please check https://clickup.com/features/dependencies
Lloyd McKenzie (Jul 22 2020 at 16:36):
PlanDefinition would define the rule, but it's reasonable/appropriate for the actual Task/Request to explicitly declare the pre-condition constraint.
Orlando Osorio (Jul 23 2020 at 14:30):
Hi, @Lloyd McKenzie, just in case this question got missed:
Would you consider instead of adding a dependsOn property to core having something more generic and extensible like MedicationKnowledge.relatedMedicationKnowledge?
Lloyd McKenzie (Jul 23 2020 at 14:42):
We try hard to avoid 'typed' references because they're harder to constrain and declare conformance to - you get forced into slicing. Best practice is to enumerate the specific types of relationships as distinct properties - each potentially constrained to different allowed target resources.
Lloyd McKenzie (Jul 23 2020 at 14:43):
@Jean Duteau @Melva Peters side question - why is MedicationKnowledge taking this approach. And in particular, why isn't the 'type' element constrained to a specific value set?
Melva Peters (Jul 23 2020 at 14:45):
There will be value sets added, we haven't finished that work yet. Is it an issue if they are exemplar value sets?
Lloyd McKenzie (Jul 23 2020 at 15:02):
For something like this, it really ought to be required or extensible. Otherwise you would have zero interoperability. "This med relates to this other med 'somehow' doesn't tell you much..."
Orlando Osorio (Jul 23 2020 at 15:03):
We currently use MedicationKnowledge.related to model medications that have minor variations between them but are different products in our catalog, e.g.: different flavors, different packaging (syringe vs topi-click), etc. And we link them with shortcuts in the UI when ordering.
The value set we use is our own, so 'example' or 'preferred' would be ideal for us.
Lloyd McKenzie (Jul 23 2020 at 15:31):
Example/preferred is always easier because no mapping is required, but the result is that while it's easy to comply, it's next to impossible to interoperate across organizations.
Jean Duteau (Jul 23 2020 at 16:30):
the "relatedMedicationKnowledge" element is intended to allow for hierarchies of products to be expressed. We've had use cases for simply parent-child relationships, but also related, same class, equivalence, etc. Thus we added a type code to allow different knowledgebase vendors to express their assorted hierarchies. Like Melva said, we are currently working on providing example bindings to value sets.
Lloyd McKenzie (Jul 23 2020 at 16:50):
Why wouldn't you provide required or extensible bindings? Why the need to support variation by implementation?
Jean Duteau (Jul 23 2020 at 16:57):
because we have no idea what the complete set of relationships would be. and different implementations will have different relationships.
Lloyd McKenzie (Jul 23 2020 at 16:58):
That doesn't mean you can't identify the 4-5 most common ones and mandate codes for those with an extensible binding
Jean Duteau (Jul 23 2020 at 16:59):
that's an interesting idea. when we get this more complete and have a connectathon about it, we'll ask the implementers what they think
Lloyd McKenzie (Jul 23 2020 at 17:54):
A wide open typed relationship is a FHIR anti-pattern
Jean Duteau (Jul 23 2020 at 18:03):
really? hmm. (looks at ServiceRequest.performerType, Claim.related.relationship, EpisodeOfCare.diagnosis.role). As Melva and I said above, we are still working on all of our value sets and their bindings and we'll take your advice into account when we work with our implementers.
Vassil Peytchev (Jul 23 2020 at 19:08):
A side observation: ServiceRequest, Claim, EpisodeOfCare are all FMM level 2. Is removing the anti-pattern something to be considered when resources move to a higher level?
Lloyd McKenzie (Jul 23 2020 at 19:08):
performerType isn't tied to a relationship. Claim.related.relationship is definitely antipattern. EpisodeOfCare.diagnosis.role is a qualifier and is optional. It's not necessary to understand the instance.
Lloyd McKenzie (Jul 23 2020 at 19:09):
Removing anti-patterns can (and should) be done as early as they're detected prior to getting locked into normative.
Last updated: Apr 12 2022 at 19:14 UTC
