# ISM: initial states for instructions / when do we need actions? **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2016-07-12 02:58 UTC **Views:** 1 **Replies:** 10 **URL:** https://discourse.openehr.org/t/ism-initial-states-for-instructions-when-do-we-need-actions/15446 --- ## Post #1 by @pablo Hi all, This message is related to my previous message "ACTIVITY.description vs ACTION.description archetypes‏" (didn't got any answers :( but this is focused on when we need actions to change a instruction state, and what's the initial state. Considering the specs: [http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_the_standard_instruction_state_machine_ism](http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_the_standard_instruction_state_machine_ism) I think when an instruction is firstly recorded, it should have a state. But I'm not 100% if that state should be INITIAL, or can also be PLANNED, SCHEDULED or ACTIVE, since at least for SCHEDULED and ACTIVE I think we need an ACTION to be recorded to trigger the transition, but it is not clear that we need that to trigger the transition "initiate (INITIAL -> PLANNED)". 1- Is INITIAL the state associated with an instruction when no action is recorded? 2- If what it's recorded is a medication prescription, I guess the initial state should be PLANNED, do we need to record an action alongside with the instruction to make the "initiate (INITIAL -> PLANNED)" transition? OR, we can just set the initial state to PLANNED, even though no actions are recorded for the instruction/activity? 3- On the case of recording a treatment that should be scheduled, do we also need an action to trigger the "schedule (INITIAL -> SCHEDULED)" transition? (I guess yes if the instruction is created at one time, and the schedule comes later). 3.1- If yes, what happens on the case the instruction includes scheduling? Should we include an action to trigger the transition or can we set the state to SCHEDULED directly? At least for me this is not 100% on the specs. If this happens to others, we might need to improve the specs and add more examples to make this topic clear for newcomers. Thanks! --- ## Post #2 by @Heath_Frankel3 Hi Pablo, Some comments below. Heath --- ## Post #3 by @pablo Hi Heath, thanks for taking the time to answer, this is really useful and I think your comments should be included in the specs as examples of how the instruction/action interaction and the effect of that interaction on the ISM should work. First it makes total sense for me to have INITIAL as the current state when no ACTION was recorded for the INSTRUCTION. And it also makes sense to include a "placeholder" ACTION (might not have much info but the next state) for INSTRUCTIONS that need to be on PLANNED when the INSTRUCTION is created (like the medication case). About 3.1 I was thinking of a case where the event of creating the INSTRUCTION also includes the coordination/scheduling of ACTIONs that will be performed. I think this is just another case of my previous paragraph: we need an ACTION to change the state to SCHEDULED. Thanks a lot! --- ## Post #4 by @system Hi Pablo can you raise a PR for this, with some summary of the changes you think are needed? thanks - thomas --- ## Post #5 by @pablo yes I will, BTW there is another conversation that is related to this and to improving the specs, the subject is: "ACTIVITY.description vs ACTION.description archetypes‏" if anyone can take a look at it, would be helpful. --- ## Post #6 by @Etienne_Saliez1 Thank you very much for the schema. However I believe that the handling of an Action should start earlier before the "INITIAL" state. - "SUGGESTED" Preliminary informal suggestion, according to some generic guidelines, regardless of the details of the current context of the patient - "POROPSED" It could be useful to record temporarily proposals by student, junior assistant or nurse, or simply when a staff member is considering some action while waiting on more information from the lab. Nothing yet done, but information could be useful to be recorded temporarily as an element of discussion. - "VALIDATED" The decision for he action is confirmed by an authorised member of the staff. Although not yet scheduled. The author of an order is also responsible to specify a time range, from "very urgent" to "to be done within on month". If the time would have been outdated the order should be reevaluated. - etc as on the schema ..... - "STARTED" For example a treatment for 10 days is actually started. Or a bacteriology test which necessitate at least 24 hours. "COMPLETED" Completely executed. In priciple a conclusion is expected. Etienne Saliez --- ## Post #7 by @pablo Hi Etienne, did you checked the ISM specs? I think the flow phases you mention are mappable to the current states of the ISM. Also consider this conversation is about INSTRUCTION handling, not ACTION handling, ACTIONs are used to modify the state of the INSTRUCTION/ACTIVITY. --- ## Post #8 by @Ivar_Yrke Hi Last thing first: We also have the need for «proposed». For that we use PLANNED. After all you can CANCEL from PLANNED, so it serves the purpose. I think the issue here is to not overinterpret the names in the state machine and to avoid making it overly complex. I agree with your initial concern that the use of INITIAL state is not very clear. In the diagram it is grayed out, indicating that there is something special about it. I have come to think that it is the initial pseudo state, the one that in UML is a black filled circle. As such this state can never exist, meaning that there always must be an ACTION attached giving it a real state (there is no other way to assign a state). With this background I therefore agree with the replies from Heath. If your PR will lead to clarifications in the description or even in the state machine, I would like the following to be considered along the way: · Clarify if INITIAL is a real or pseudo state. Should there always be an ACTION giving each ACTIVITY a real state? · The Instruction State Machine (ISM) is actually an Activity State Machine (ASM). This is very confusing when introducing to new persons and I wonder if it would be beneficial with a name change here. The instruction aggregated state is really the state of the instruction. · There seems to be a missing transition “do” that goes directly from INITIAL to COMPLETED. This is needed both for ad hoc ACTIONS as well as one time ACTIVITIES that have already been done by the time of doing the “paper work”. It seems overly formal to have to model this through two ACTIONS. --- ## Post #9 by @system the above 3 action types would normally be mapped to the 'PLANNED' state - that's the point of the standard state machine - to be reasonably simple, but to allow any action plan to be mapped to it. this would probably be mapped to the ACTIVE state. - thomas --- ## Post #10 by @system this is the correct interpretation of the state machine. yes it is a pseudo-state; please mention this in the PR if anyone things the documentation is not clear enough about it. Also, ACTIONs have to occur to move the state machine forward, otherwise it is nothing every started. that's an interesting point! We called it the Instruction State Machine because it's the state machine of the instruction - i.e. intervention, medication etc - in the real world, 'being done'. We can only know where the progress is up to by a series of ACTIONs representing actions that were done in the real world. So from that point of view, it seems reasonable to call it the Instruction State Machine, even though it is by means of ACTIONs being reported that we know what state it is currently in. I suspect we can at least clarify the documentation text on this, so please mention it in the PR as well. good point - that would be an easy addition to make. - thomas --- ## Post #11 by @pablo All useful questions and answers! Please feel free to update this issue: [https://openehr.atlassian.net/browse/SPECPR-205](https://openehr.atlassian.net/browse/SPECPR-205) Also I like the idea of the ACTIVITY SM! +1 for me --- **Canonical:** https://discourse.openehr.org/t/ism-initial-states-for-instructions-when-do-we-need-actions/15446 **Original content:** https://discourse.openehr.org/t/ism-initial-states-for-instructions-when-do-we-need-actions/15446