Clarify evaluate order and semantics of REPEAT_SPEC.
Description
Activity
Matija Polajnar May 5, 2020 at 10:57 AM
Yes, this now matches our understanding and implementation of those attributes!
Thomas Beale May 5, 2020 at 9:42 AM
I’ve made final adjustments to reflect this. See https://specifications.openehr.org/releases/PROC/latest/task_planning.html#_repetition and the class text https://specifications.openehr.org/releases/PROC/latest/task_planning.html#_task_repeat_class
Matija Polajnar May 5, 2020 at 7:15 AM
I don’t think we have a common understanding here.
What we have implemented is that the terminate condition does occur before each iteration, but only if the lower bound for repeats has already been reached. So the number of repeats (not counting the initial run) always respects the interval in the repeats attribute (well, unless someone abandons the entire plan or whatever), but after the lower bound has been reached, each new iteration (until the upper bound is reached) is preceded by a terminate condition predicate.
Thomas Beale April 28, 2020 at 12:17 PM
Now ready for review (again). https://specifications.openehr.org/releases/PROC/latest/task_planning.html#_repetition
Thomas Beale April 28, 2020 at 12:07 PM
So I think I will fix this one by documenting the terminate_condition here as acting as a post-test in the sense you have implemented it. This probably won’t be the final answer on this, but it should at least be coherent for now. We can treat exceptions as more like ‘clinical interrupts’ as I was describing above.
Currently the spec does not say whether the terminate_condition should be evaluated before or after the execution of the PLAN_ITEM. Adding a Boolean would enable the two standard flavours of loop to be supported i.e. while/do and repeat/until.