All useful questions and answers! Please feel free to update this issue: https://openehr.atlassian.net/browse/SPECPR-205
Also I like the idea of the ACTIVITY SM! +1 for me -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com Subject: Re: SV: initial states for instructions / when do we need actions? To: [email protected] From: [email protected] Date: Tue, 26 Jul 2016 11:09:56 +0100 On 26/07/2016 07:58, Ivar Yrke wrote: 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). this is the correct interpretation of the state machine. 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? 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. · 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. 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. · 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. good point - that would be an easy addition to make. - thomas _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
