Hello everybody,
Regarding the TP specification, if you need to model two parallel tasks, one is a daily medication and the other some lab tests, and you want to interrupt the medication when the lab tests are ready, would a repeatable task be the right way to represent the medication with a terminate-condition (either a system or manual notification from the lab)? is there any other (better) way to represent that? I have seen that task-waits delay the start of the task, but in this case a task in branch B must interrupts a task in branch A in a parallel group.
As an extension to this question, is there a way other than task-waits (or period in repeatable tasks), of maintaining tasks in sync, with time spacers before, or after the task? For example, a task that starts with a given delay only when other task is initiated. I have seen that the event_relation task attribute allows specifying whether the task should start before, with or after the triggering event, and this could be enough for that, especially if extensions are added to these operators (before, with or after any event or absolute/relative times).
Another example would be when a group of tasks needs to meet the same (end) deadline. In this last case would the and-all paths decision branch be the right representation for this?
Finally, where can I find more information about the possibility of associating rules to a task or task group? The specification mentions that if a task Group needs more complex execution logic, this can be achieved by adding a rule to the task group using the TASK_GROUP.execution_rules attribute.
Hi Natalia,
if I have understood the problem correctly, a solution is here. It might need some adjustment, depending on what is supposed to happen after the medication path gets interrupted by the lab tests arriving, but clinically, I assume the idea would be to review medication and then restart, possibly with changed prescription (this latter part I did not show).
Events with delays are shown on the last row of this TP-VML figure. You have to make one of these events the trigger for a Task wait state (the red ball in front of a Task) to get the effect you want.
Well here it depends on what you mean by ārulesā - if you mean some rules to do with parallel synchronisation, e.g. āat least N paths of M must completeā, yes that would go there.
If you mean clinical logic rules, then you will refer to variables in Decision Logic Modules. We are working on this right now, but this example shows the idea - you can see āDSMā (should read āDLMā) following by a variable or rule name - those are the references to rules in the DLM futher down.
Hi,
Thank you so much for the answers. The question about rules was about introducing business logic for more sophisticated temporal constraints. I have read what has been done so far in the DLM spec, but in this case I am only thinking of having more complex time constraints between tasks.
Thanks again!!
Hello again,
Here is another situation that arises in clinical scenarios. A repeatable task (for example a lab test) which is repeated until certain results are obtained (letās say negative results). In that moment, a daily treatment that was executed in parallel, needs to be interrupted and the treatment duration must be reset to 7 days. Then the treatment is continued during these 7 additional days.
In my mind this would be a parallel execution group with two branches:
Branch A: blood culture task group is repeated daily with terminate condition= negative blood culture.
Branch B: treatment task group is repeated at least 2 days(as lab results come no earlier than 48 hrs), upper limit none, period=daily and with an event wait on the blood culture task group to complete.
Both branches end then, and a subsequent new sequential repeatable treatment task group is started with period daily and lower and upper limit = 7d.
I have three questions in this model:
should I always code an upper limit for the BC repeatable task? we do not know how many times it must be repeated, we must repeat it until it is negativeā¦
where can I read more about the type of terminate-conditions that can be coded?
how can I represent a treatment duration override in the model?
I enclose a sample representation as I understand it
Hi Natalia,
another good use case! I think your model is very close to right. One thing to note, we donāt have anything in the model that corresponds to that ādurationā on the BC group. Maybe we should: it could be a runtime attribute ādurationā on PLAN_ITEM which then could be constrained in the archetype to a range of possible durations. At the moment, it would have to be added .g. via PLAN_ITEM.other_details.
If I am not mistaken, the terminate_condition on the BC group should read ānegativeā?
On the 3 questions:
often you donāt need an upper range on a repetition, since the clinicians will stop when it makes sense, which can always be done with a ācancel not neededā lifecycle state change to the group.
the terminate condition can be any Event, so any kind of event that you can use on a Task Wait (the red ball in front of a Task).
see the above comment - but it depends on what you mean by ādurationā - maybe you can say more on this.
Iāve added visual elements to d TP-VML for Task Repeat - see here. Iāve also added these icons to the TP-VML library - if you do a pull on the Git repo or a download of the directory, youāll get the change.
Another possibility for the design is to make the medication path wait for a āstate eventā directly indicating the there is a negative result for the particular blood culture, rather than waiting on the BC pathway. This might be safer in some circumstances, just in case (for whatever reason) this BC pathway is slow, or even not being done, but the bloodwork is being done in reality, just somewhere else, and there are still results appearing correctly in the EHR.
Yes, it should be negative, not positiveā¦sorry for the mistake.
The terminate condition can be any event, could it also be the value of a task item or ehr data variable?
Regarding duration, it would naturally be a property of a treatment, that is, a EHR data variable. As TP claims to allow overrides of task info, I found this to be useful though. If you want TP to be used standalone independently from openehr I would add it, and in case of integration with openehr allow for task mapping between tp tasks items and ehr objects so that some task parameters can be written back to the ehr and viceversa.
Maybe it is worth thinking about this, as treatment durations, doses, medicationsā¦change all the time depending on patient evolution. Treatment and diagnostics are subject to changes in the course of a treatment.
A final question, regarding tp execution. How is the tp-vml translated into executable code? Any documentation about this?
Quick answer for now - TP-VML is just a visualistion of archetypes of the TP model. When you hit āsaveā, it creates archetypes (try it in the Archetype Designer). You need to stick the archetypes together into templates, in the usual way. Those templates can be executed by a TP engine. Better has one under development, with some plans already running. However, there is no freely available implementation of a TP engine yetā¦ but itās certainly coming. If you were trying to build something right now, you might try to build a āquick and dirtyā engine that could consume at least the basic elements of the template, ie. Task Groups, Tasks and Decision nodes.
Note that TP 2.0 will change things quite a lot such that the decision logic will go in Decision Logic Modules, and Task Plans will just refer to variables and rules in those modules.
Thanks for the quick answer. But even not having the TP engine, are there examples of the resulting ācodeā into which TP-VML is converted for execution? That would be enough for me now
Thanks a lot
