Multiple Instances in TP

Specifications Task Planning/GDL
#1

In the OpenEHR TP specification, in section 6.2.2.2. Repetition, is stated:

The second attribute, repeat_spec of type TASK_REPEAT enables a Task or Group to be marked as repeating. This is not intended to replace the use of individual Task instances over time, such as repeated medication administrations, but rather to be used to indicate if larger sections (i.e. Task Groups) of planned Tasks are repeatable.

I’d like to ask the meaning of the phrase “This is not intended to replace the use of individual Task instances over time, such as repeated medication administrations, but rather to be used to indicate if larger sections (i.e. Task Groups) of planned Tasks are repeatable.”

As far as I know, Repeat is the only way to model multiple instances of a task or task group in TP, and they are thus executed sequentially. If not using a Repeat loop, what are the alternatives? For repeated medication I am using Repeat as I do not know any other way of expressing mulplicity of a Task or Task Group, neither sequential nor parallel.

Thanks!

#2

Sorry I missed this one earlier…

If you have a look at the second (main) plan for the chemotherapy example, you’ll see a section of 4 days of prednisolone - day2 … day 5. The text you mentioned refers to this kind of thing: it’s not really a repeating administration, but a fixed 4 day series of tasks. We didn’t use the repeat feature to do this because the design intent of the protocol is that you just give that drug in a certain dose on day2, day3, day4 and day5. I guess in theory it could be a repeat block, which is what we used to model the repetitions of the overall protocol for each of its cycles, which can be variable and varied depending on the patient reaction.

If you use a repeat block for the inner one I think it may make it harder for the engine to process it (i.e. to visualise for a user) and to show which tasks have been done and which not.

Our original thinking was that the repeat facility was for longer sections of tasks that are likely to be executed some period apart, i.e. in different shifts, possibly with different workers etc.

Like everything else in the model, I am sure we will adjust our ideas as we do more examples, so don’t take this feature as gospel the way it is currently stated!

#3

Ok, understood, I agree that in the chemotherapy example a repeat would not suffice. If I understand well, you can either explicitly represent each task in the model, as in the chemotherapy example, or use a repeat loop whenever adequate for the process scenario that you want to represent. As far as I have seen, TP does not know the concept of BPMN multi-instance activities, where an activity occurs for a collection of objects or items, is that correct?

I am focusing on infections, therefore the perspective is a bit different than the chemotherapy example. In infections, treatment duration is sacred but it often requires on-the-fly changes if patient does not respond well to treatment. So the sentence in your reply “which can be variable and varied depending on the patient reaction” is really important to me. For example: can I change the attributes of a repeat task on-the-fly in response to an event, keeping track at execution time of the number of already executed iterations? Does the terminate-condition of a repeat loop allow any type of event trigger, like a subject variable changing its value?

#4

At the moment TP Work Plans are undertaken for a ‘subject’, meaning a subject of care. In openEHR, and health informatics generally, this is usually understood as any possible subject of care in the real world of healthcare - usually a single patient (can be an animal, for veterinary healthcare), but could be a family or some other combination of individuals that is being attended to by clinicians.

However… a particular Task can of course focus on a ‘proximate object’ such as a blood sample, or some part of the patient etc. I proposed some time ago that we consider formalising this proximate object at a Task level, but was convinced out of it (probably correctly - you can’t formalise everything!)

With respect to what kind of Event can be used as a TASK_REPEAT.terminate_condition - it is any PLAN_EVENT. So this can be e.g. a patient micro result coming back negative (e.g. after some course of anti-biotics), or any other patient variable, as well as just elapsed time etc.

At the moment, we don’t have an obvious way of changing other attributes like period etc. I have been thinking of a general approach to how such values could be mutable while a Work Plan is ‘in flight’, and I think the best approach is not some complicated way of plan modification and re-versioning or whatever (for parts already executing), but rather an approach that allows the value of a currently fixed attribute (like TASK_REPEAT.period) to be a subject variable or rule result from an attached DLM. We have to do a bit more meta-model work to enable that.

If you are interested to provide an example of anything you are working on, we could add it to the ‘process examples’ document (attributed to you of course).

1 Like