this is indeed a limitation, more or less the ‘last’ semantic limitation that I know of in the archetype formalism. It requires an addition to ADL2/AOM2, that I have partially worked out (it is technically related to tuples), but I don’t think it is going to work in ADL 1.4. It will be another reason to move to ADL2/AOM2… - thomas
Thomas, when I said “mapped to ASSIGNED” was an error, it is “mapped to PLANNED”, the flow that I explained is correct, not the last comment. My domain “NEW” and “ASSIGNED” are mapped to ISM “PLANED”. THe core issue is the need to define the transition between domain ASSIGNED to domain STARTED, and do not allow domain NEW to have a transition to STARTED, were in ISM PLANNED can flow to ACTIVE.
The new Marand ADL-designer tool that replaces both AE and TD is in late beta test, and should fix most things being talked about here, but won’t fix the splitting of transitions and separate data structures, because that’s an ADL-theoretic issue. But ADL-designer is AOM2 inside, so it should be able to fix the problem; there may be a way to fake the result back into ADL1.4, but I don’t know about this yet.
This is the tool pathway that will solve this problem for most people, I believe. LinkEHR might be able to do it as well, depending on what its current internal model is. It will also need the same modification to AOM we need to add to solve this particular problem.
I won’t jump the gun on publishing the new tool link - it’s better if they do that, but if there are people interested in beta-testing, it might not hurt to register your interest here.
- thomas
In my imagination it works in a similar way to the named or cloned events in the TD. At least I hope that it could be that simple.
Maybe I’m dreamin’?
Cheers
Heather
Also a bit of a late reply, dure to the holidays…
First about Ivar’s reply to my earlier comment:
I’m not sure I understand the technical implications of this issue (though I’m very interested to learn), so I’ll have to accept at face value that this is something that’s needed. 
The way I understand this, the possible transitions are pre-constrained by the RM state machine, right? So the issue is that you sometimes need to constrain this further for specific careflow_step? I understand that this can sometimes be needed in a specific use case, but I still believe it will be hard or impossible to predict for very generic archetypes like the ACTIONs we’ve currently published. Could this be specified at template level instead, or in addition to at the archetype level (where feasible)?
As Thomas commented further up in the thread, we’re in the process of slowly moving to the ADL Designer tools by Marand, which are in beta testing atm. Could we get someone from Marand to comment on this issue? (Fabio, I’m looking at you )
Finally, I agree with Heather that the way the template modelling tools (both Template Designer and ADL Designer) are handling OBSERVATION events, would be a very pedagogical way to handle ACTION steps and transitions as well, if possible. For new modellers, seeing an OBSERVATION archetype in the template modelling tool is often what makes understanding events click. Having a similar way of visualising careflow_steps and transitions would be extremely useful, as this is a complex area a lot of modellers (myself included) struggle to wrap their brains around.
I’ll try again. To see my problem, imagine that you have an instance of a state machine that is currently in SUSPENDED. Now tell a nurse what options he has. You can do that based on the RM and the actual ACTION archetype, provided you can relate the archetype constrains to the RM.
The possible transitions are pre-constrained by the RM, as you say, and there is no need from our side to change that. The problem we face is that the ISM_TRANSITIONS as they are generated by current tools, do not carry enough information to identify their place in the RM. Which arrow do they represent? The only thing we get to know is their “end point” (current_state), but we cannot distinguish e.g. “resume” from “active_step”. Having the transition property populated would solve this for us. Without this information what our applications see is basically a mutilated state chart diagram, like this:
We can see that there are incoming and outgoing arrows, but we have no information about which end belongs to which. From the RM we know that there can be an arrow going from SUSPENDED to ACTIVE, but which one is it? I know, again from RM, that its transition is “resume”, but without this information I just see like in the diagram. Even though my archetype has two ISM_TRANSITIONS with current_state ACTIVE, there is no way to figure out which of them are relevant from the SUSPENDED state. We simply need more information in the archetype to be able to refer it to the RM.
So what is the big deal, can’t I just pick one? Well, in a just recording scenario I could. But I want to present the options to the nurse as guidance and there is a rather big difference in presenting the option “Resume suspended drug” from “Deliver drug” (these texts are the workflow_steps). To do that correctly I need to know which arrow goes out of SUSPENDED and the transition (together with RM) will tell me that.
Thanks Ivar, that makes it a lot clearer to me.
(attachments)
Dear all,
We have just released a new version of LinkEHR which includes a revamped pathway editor. This editor includes a graph preview of the defined pathway (mimicking the one in the specifications) to ease the visualization of the defined pathway.
Special thanks to Ivar for providing us with feedback on how to create a useful pathway editor.
Regards