I’m trying to better understand the relationship between the mandatory RM attribute ACTION.time and workflow/state modelling in openEHR. In the CKM, for the Procedure archetype, the RM attribute “Date and time Action step performed” (ACTION.time) is mandatory (Occurrences: 1..1). From a semantic perspective, this timestamp appears to be more closely related to the workflow transition represented by ism_transition than to current_state.
My question is:
If a model/template chooses to include current_state but does not include ism_transition, how should ACTION.time be interpreted? Does the mandatory RM attribute effectively become associated with the recorded current_state, or is it still intended to represent the time at which the action itself was performed, independent of any state modelling?
More generally, what is the recommended interpretation of ACTION.time when only current_state is used and ism_transition is absent?
In general I would advise storing current_state without the associated careflow_step (ISM_TRANSITION). current_state is just a low-level generic flavour of the state of the Action. careflow_step is added specifically by each archetype and generally applies much more specific ‘clinical’ ideas of the state of the action, so that there are often multiple careflow_steps per current_state, gnerally more specific and contextual.
Each careflow_step is bound to a specific current_state (think of it a sub-classing) so the ‘meaning’ of ACTION.time is best represented by the careflow_step, but if not available, current_state should be ‘correct’ if less specific/contextual
Very occasionally, creflow_step might be associated with more than 1 current_state - see ‘Prescription (refill) authorization awaited’ below. The very first time a prescrpition is awaiting authorization it will be a planned state but refill authorizations will have an active state.
With the current model ACTION.time is the moment when the action was actually performed or recorded. The ACTION leads to the current_state. But the actual change in the state will happen when the COMPOSITION that contains the ACTION is committed to the EHR, which can be after the ACTION.time. Semantically you can consider in the context of the ACTION, the actual change of state was at ACTION.time, it was just recorded later (commit time).
