If a reminder is set to occur on an event - usually a timer, if it is the simple kind of reminder (i.e. nothing happened for some period P, annoy the worker), will occur. Even if it is your example, it will normally occur. So to prevent a reminder from occurring we need to use a 'cancel' relation, as YAWL does (YAWL 'cancellation regions'). To do this properly, we need a connection between the REMINDER and the events waited on by the TASK_WAIT. But the general case is that we can create a 'reminder' with any event, e.g. your example of a TASK_TRANSITION. We need this also to be cancelled by the arrival of any other events it is designed to be a reminder for.

I'm pretty sure the point of reminder is that is might never happen, or it is even preferred not to. So preferably the task would be completed before any of its reminders fires and then we stop waiting for reminder events, no matter what kind they are. And it should be allowed to have all kinds of events for reminders.

For example (and I'm making this up), we might have two active tasks in parallel for different performers and it is expected that one of them (let's say some minor administrative work by the administrative worker) would be completed far sooner than the other one (let's say some complex examination by the doctor). We might set up a reminder on the first one when the second one completes (via a TASK_TRANSITION event) just to nudge the administrative worker to hurry up with that one.

So as far as reminders go, they need not be fired by "deterministic" events and they do not need a timeout mechanism; they will fire if the event occurs, but we actually hope it will not occur in time (i.e. before task completion).

And then I believe it again makes no sense to distinguish those two groups of events.

If you remember, you asked for REMINDER.event to be changed to PLAN_EVENT to allow for any kind of event to be a reminder trigger. Prior to that, it was just a TIMER_EVENT. I think I'm ok with that change, but it now means that a REMINDER could indeed not fire, because its event never arrives (e.g. something like patient BP dropping below some value). See attachment for how the model looks right now.

The way to fix this properly is to distinguish between deterministic and non-deterministic events in the model, by adding a bit of inheritance. Timer_event, Calendar_event and Timeline_moment are all deterministic, the rest are not. Then we could point REMINDER.event to DETERMINISTIC_EVENT, and then we don't need the timeout on it.

But then Reminder should also have an invariant about not having a timeout. At least I think that makes no conceptual sense.

Oh yes, sorry, forgot that. Will do.