@Peter thanks for the feedback! As Diego mentioned, I think currently the only tool that support full specification of constraints for the ISM is LinkEHR, I need to test it! And since they added OPT support, transitions might get exported as well.
I also have the VB code, but I'm a little allergic to VB :) Best, Pablo. On Fri, Jul 27, 2018 at 5:02 AM, Ivar Yrke <[email protected]> wrote: > Hi Peter, thanks for your reply. It adds several relevant facts and > background to the problem description. > > > > We did in fact have a copy of the AE with transistions, but we could not > figure out how to use it. We do not need to go beyond the RM, we only need > to fully specify according to RM. If memory serves me right I think that > implementation did not help us with that. In fact, I think the whole > implementation/visualization if pathway in AE is part of the > problem/limitation. It kind of contains a left-to-right idea, which isn’t > really reflection the dynamics of the ISM. > > > > I actually did look into the code. After some struggling into the VB code > (which isn’t my strong side) I eventually found that the problem also went > into the underlying java-classes (which is not my strong side either). I > concluded this was not an easy fix, which I had hoped, and basically gave > up. > > > > But you are absolutely right, the rest of the tool stack is just as > important. This problem really needs support from the community and is > desperately needed for serious use of the ISM. > > > > Vennlig hilsen > > *Ivar Yrke* > > Senior systemutvikler > > DIPS AS > Telefon +47 75 59 24 06 > > Mobil +47 90 78 89 33 > > > > > *Fra:* openEHR-clinical [mailto:[email protected]] > *På vegne av* Peter Gummer > *Sendt:* 26. juli 2018 15:18 > > *Til:* For openEHR clinical discussions <openehr-clinical@lists. > openehr.org> > *Emne:* Re: How to define transitions in the ISM > > > > Hi Ivar and Pablo, > > > > Reading this, I had the vague recollection that old versions of Archetype > Editor used to have a stab at supporting the transition, but that I had > removed it because it didn’t actually work. A quick search of github … and > here’s the relevant commit, more than five years ago: > > > > https://github.com/openEHR/arch_ed-dotnet/commit/ > 7cd2968557074daec0e4ca97b6518483f516ba01 > > > > And here’s the comment that I wrote explaining the change: > > > > *In ACTION archetypes, remove the Transitions option from the **Pathway > Specification. It has never worked and no one has ever found that the > transition constraints should be limited more than the standard openEHR > state diagram. The partial implementation that was in place also seemed > back-to-front with respect to the reference model: the RM specifies the > transition that which occurred to arrive in the current state, whereas the > user interface was constraining which states could be reached from the > current state. For simplicity and to avoid confusion, it's best to remove > the existing non-functional implementation.* > > > > So … “no one has ever found that the transition constraints should be > limited more than the standard openEHR state diagram." Based on what you’ve > written below, Ivar, it sounds like you now have a convincing case for > implementing it! > > > > Sadly, it would seem that nobody has been supporting the Archetype Editor > github repository since my final commit almost three years ago: > > > > https://github.com/openEHR/arch_ed-dotnet/commits/master > > > > Nonetheless, anyone can clone the repository and implement the transition > in Archetype Editor, if they have the time, skill and will to do so. But > unfortunately I don’t think this will solve your problem. Whenever we used > to implement a new feature in Archetype Editor, we had to take into > consideration its impact on the downstream tools. You’ve mentioned that > Template Designer ignores the transition; so even if you did get the > transition into your archetype, wouldn’t it be lost in your templates? > Beyond the template and the OPT, further downstream support would be > needed. Has support for the transition been implemented in CKM and whatever > runtime openEHR libraries your software is built upon? > > > > I don’t see an easy solution for you, because your whole stack would need > to support it. Hand-coding the ADL, OPT, etc. is an ugly solution, but it’s > a solution that won't work at all unless your downstream tools and software > can accept the transition. > > > > Regards, > > Peter > > > > > > On 23 Jul 2018, at 21:58, Ivar Yrke <[email protected]> wrote: > > > > Hi all > > Somewhat late reply due to vacation… > > > > We have come across that same problem and for us it actually was a show > stopper for which we had to invent a work around. > > > > *First a remark about the tools:* > > We saw that ArchetypeEditor did not add the transition. So we tried to add > I manually to the adl-file. We found however that AE ignores it and after > saving again from AE it is gone. Further we tried to use the modified adl > in a template using Template Designer, but it was ignored and no trace of > it in the resulting opt. > > > > These are very serious limitations in the tools and forces a work around > that we should very much like to abandon (see below). It raises the > question how the community should go forward to make sure there are > appropriate tools. Who owns the tools? Who pays for their maintenance? > > > > The ISM is potentially a very powerful asset of openEHR. Missing the > transition property mutilates it to very limited value. > > > > *Then a remark to Silje’s reply:* > > “Solving” the problem in the business logic is only possible when recoding > after the fact. Given that the current state is so and so and the new state > is so and so we can deduce (in most cases) the transition. > > > > *Our problem:* > > Our problem is the opposite of solving after the fact. We want to present > to the user only the transitions valid at any moment in time. Given the ISM > and completely defined ISM_TRANSITIONs this would be possible and easy. But > not so without the transition! Without that information it is not possible > to distinguish the transitions having the same current state. > > > > To see the problem, assume a simple state machine with one of each of > these transitions: active_step, suspend and resume. Let the current state > be SUSPENDED (last recorded action was suspend). In this state we only want > to give the user the option to resume. However, without the transition > property in the ISM_TRANSITION we cannot distinguish resume from > active_step. Both have ACTIVE as their current step and careflow_step is > only descriptive and not usable. The only option is to give the user all > choices and assume he does the right thing. Not a good option. After all, > resuming a suspended drug and administering the drug are quite different > things and we do not want an erroneous administering to take place as > result of our system suggesting it! > > > > *Our work around:* > > Fortunately each ISM_TRANSITION has a unique id. Based on this id we add > the missing transition, from our own local configuration, to the archetypes > we use after having loaded them. This information is transient and only > lives in our memory instances of the archetype. But at least we have it > available so that we can make a full state machine evaluation and find only > the relevant transitions to present to the user. > > > > *Some questions:* > > What if the user inadvertently administers a drug that has been suspended? > In that case he surely needs to have this transition anyway, doesn’t he? > Well, yes, but not as a suggestion from our system! This situation must be > handled separately from guiding the user through the states. In fact, it > could be argued that this be recorded as an ad hoc action. > > > > With regards, > *Ivar Yrke* > > Senior systemutvikler > > DIPS AS > Telephone +47 75 59 24 06 > > Mobile +47 90 78 89 33 > > > > > *Fra:* openEHR-clinical [mailto:[email protected] > <[email protected]>] *På vegne av* Pablo Pazos > *Sendt:* 2. juli 2018 22:45 > *Til:* For openEHR clinical discussions <openehr-clinical@lists. > openehr.org> > *Emne:* Re: How to define transitions in the ISM > > > > Hi Heather, thanks for the insight. > > > > It seems this is a well known issue for clinical modelers. > > > > I certainly agree with the criteria of the maximal dataset, IMO what makes > a maximal dataset depends on the modelers interpretation of each specific > use case. Of course less constraints allow a greater set of use cases to be > considered, but also increases the work that needs to be done to fill the > blanks between a generic archetype and a specific State Machine to be > implemented. That negotiation that you mention is what I described as > "extra metadata needs to be given for implementation". > > > > In terms of the gap in modeling tools, I agree, technically archetype > editors and template designers (Ocean and others) should be able to > constraint the valid or invalid transitions. Then if modelers use or not > those constraints, should depend on their criteria, not on limitations of > modeling tools. On the other hand, *this issue of modeling tools not > supporting these constraints might be because in the RM, ISM_TRANSITION is > not LOCATABLE (all classes that can be archetyped), but inherits from > PATHABLE (RM 1.0.2 & 1.0.3)*. Considering this, it is a little > inconsistent that the AE allows to create constraints for > ACTION.ism_transition, but only for the ISM_TRANSITION.current_state and > ISM_TRANSITION.careflow_step. but not ISM_TRANSITION.transition. > > > > Maybe a solution form the RM is to make ISM_TRANSITION inherit from > LOCATABLE, then update modeling tools to support it. > > > > I will mention this to the SEC. > > > > > > Best, > > Pablo. > > > > > > On Sun, Jul 1, 2018 at 4:21 AM, Heather Leslie <heather.leslie@ > atomicainformatics.com> wrote: > > Hi Pablo, > > > > Every archetype ideally needs to be designed for the maximal dataset and > universal use case. The ACTION archetypes are no different. > > > > But you have picked up on a major gap in our tooling at present – the > modellers need the ability to be able to constrain the ACTION archetypes in > templates for each use case: > > · to show what data points are relevant for each pathway step, > and > > · which steps are relevant to our use case. > > > > It is also not currently possible for modellers to record the proposed > workflow or transitions in any template at present. This is another major > gap and, in practice, is usually managed on a project by project basis a > negotiated by the parties involved – verbally, word docs etc. > > > > This is a relatively unexplored area where we need more tooling and/or > standardised processes to communicate the requirements of the clinicians > and intent of the modellers to the software engineers implementing systems. > > > > No silver bullet here, yet. But open to collaborate with anyone who has > suggestions… > > > > Regards > > > > Heather > > > > *From:* openEHR-clinical <[email protected]> *On > Behalf Of *Pablo Pazos > *Sent:* Sunday, 1 July 2018 4:12 AM > *To:* For openEHR clinical discussions <[email protected] > > > *Subject:* Re: How to define transitions in the ISM > > > > Hi Silje, > > > > I got the issue with complex workflows. > > > > With the current solution you'll need to provide more metadata to the > developers so they can implement the correct workflows, like possible or > impossible transitions from one state to another, because constraints are > not in the archetype. > > > > On the other hand, simple workflows can be completely specified in the > archetype without providing extra medadata separately from the archetype, > since both states and possible transitions can be specified there, like the > little toy state machine on my previous message. The issue is the AE > doesn't allow to express constraints for the ISM_TRANSITION.transition > (DV_CODED_TEXT) attribute (a constraint that can explicitly state a list of > valid transitions to reach that state, I think "transition" is about > inbound transitions not outbound, but that is a separate issue). I'll test > if this can be done using LinkEHR. > > > > Also for complex flows, it would be good to provide the possible > transitions, even if the list of possibilities is big, this is just to make > the archetype contain all the metadata needed for implementation, without > the need of providing that externally to the archetype. I know this > requires more work in the archetype, but it might be less work in total, > since the problem will need to be solved as you said, in the business > logic. IMO this approach does not add more constraints to the archetype, > just more information, and made the implicit freedom of transitions > explicit. > > > > Maybe this should be considered case by case, and modeling tools should > allow to constraint the transition, but leave that to the modeler. I think > a good approach is to constraint what can be constrained, for instance on > the medication archetype there are a lot of transitions between active > states, but maybe there are less transitions between other states, and > those can be in the archetype. This would remove a little friction at > development time. > > > > It would be nice to know how other modelers do this and how other > implementers deal with non defined transitions in ACTION archetypes. > > > > Best, > > Pablo. > > > > On Wed, Jun 27, 2018 at 4:35 AM, Bakke, Silje Ljosland < > [email protected]> wrote: > > Hi Pablo! > > > > I’ll try to answer your question about how clinical modellers solve this > problem. Have a look at the ACTION.medication archetype ( > http://openehr.org/ckm/#showArchetype_1013.1.123). This archetype has 11 > separate steps for the ACTIVE state. In each medication management context, > one or more of these will be relevant, and often in a way or order that’s > not possible to predict. We therefore “solve” the problem by leaving it to > the business logic of the application. This may be frustrating for the > implementers (I don’t know, is it?), but it makes our work manageable. > Designing ACTION archetypes is complex in the first place, and I’m not sure > we’d get any published if we needed to map out all possible combinations > and orders of pathway steps too. > > > > Regards, > > *Silje* > > > > *From:* openEHR-clinical <[email protected]> *On > Behalf Of *Pablo Pazos > *Sent:* Wednesday, June 27, 2018 3:45 AM > *To:* For openEHR clinical discussions <[email protected] > > > *Subject:* How to define transitions in the ISM > > > > Hi all, > > > > I'm testing the AE for a new workshop, and designed a simple state machine > for and order so my students can use it as basic for more complex state > machines. > > > > I have: NEW (maps to ISM PLANNED), ASSIGNED (maps to ISM PLANNED), STARTED > (maps to ISM ACTIVE) and FINISHED (maps to ISM COMPLETED). > > > > What the AE is not allowing is to specify the ISM_TRANSITION.transition : > DV_CODED_TEXT. > > > > The problem is if I have two states mapped to ASSIGNED, how a software > knows which one is the state to activate if the transition "initiate" is > not define. Also I want to specify that from new should happen a > "plan_step" transition to change the state to ASSIGNED. Seems we are > missing important metadata in the archetype. > > > > How do clinical modelers solve those problems? > > > > Will test LinkEHR to see how they define the ISM and the valid transitions. > > > > Thanks, > > Pablo. > > > -- > > > > _______________________________________________ > openEHR-clinical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > -- *Ing. Pablo Pazos Gutiérrez* [email protected] +598 99 043 145 skype: cabolabs Subscribe to our newsletter <http://eepurl.com/b_w_tj> <https://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com
_______________________________________________ openEHR-clinical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
