Hi Ivar, I believe that should be handled by an internal management process, defining who can update an archetype and which tool should be used for that.
Also my comment was considering the current situation where we are "in transition" from a tool set to another. As a parallel though, and trying to avoid what happened with the AE/TD, I think we need to find a sustainable model for modeling tools, so we are sure someone is maintaining them, and we can reach out to someone for bug reports and change requests. One way would be through donations, but that is too variable. Another way would be to buy support, or event getting some support from the Foundation, to be able to keep up to date modeling tools (this could be proposed from the Software Program). I like this idea because the Foundation can put a % of the memberships into the Software Program, to allow free access from the community to modeling tools and other tools that might be useful for implementation. These are just ideas to avoid future problems that we are having right now. On Fri, Jul 27, 2018 at 6:59 AM, Ivar Yrke <i...@dips.no> wrote: > Excellent if we can get there. My concern is that someone opens my > meticulously crafted (using LinkEHR) ACTION with transitions in AE, to fix > say a translation error, removing all transition info when they save. > Hopefully these new tools become good enough to be accepted by all users. > > > > Vennlig hilsen > > *Ivar Yrke* > > Senior systemutvikler > > DIPS AS > Telefon +47 75 59 24 06 > > Mobil +47 90 78 89 33 > > > > > *Fra:* openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] > *På vegne av* Pablo Pazos > *Sendt:* 27. juli 2018 11:45 > > *Til:* For openEHR clinical discussions <openehr-clinical@lists. > openehr.org> > *Emne:* Re: How to define transitions in the ISM > > > > The nice thing is artifacts are standard, so you can use AE, and when you > find a limitation, just load the ADL on LinkEHR to add the tiny bits, also > can export OPT from there. Until we have a perfect tool, we need to use > what is there (and free). Also use and feedback make tools to evolve, and > currently the more active dev effort is on LinkEHR. My idea is to > completely switch all ADL and template design to LinkEHR in the short term. > > > > On Fri, Jul 27, 2018, 06:14 Ivar Yrke <i...@dips.no> wrote: > > Pablo, it would be great to hear how to get on with LinkEHR. > > > > To me it seems very «technical», exposing all the nitty-gritty details and > requiring knowledge of such from the user. So I can’t see how we can force > everyone to use that tool rather than AE, resulting in loss of information. > So even though there might be a tool that works all the way through we > really have a tool issue. > > > > Vennlig hilsen > > *Ivar Yrke* > > Senior systemutvikler > > DIPS AS > Telefon +47 75 59 24 06 > > Mobil +47 90 78 89 33 > > > > > *Fra:* openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] > *På vegne av* Pablo Pazos > *Sendt:* 27. juli 2018 10:32 > *Til:* For openEHR clinical discussions <openehr-clinical@lists. > openehr.org> > *Emne:* Re: How to define transitions in the ISM > > > > @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 <i...@dips.no> 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:openehr-clinical-boun...@lists.openehr.org] > *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 <i...@dips.no> 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:openehr-clinical-boun...@lists.openehr.org > <openehr-clinical-boun...@lists.openehr.org>] *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 <openehr-clinical-boun...@lists.openehr.org> *On > Behalf Of *Pablo Pazos > *Sent:* Sunday, 1 July 2018 4:12 AM > *To:* For openEHR clinical discussions <openehr-clinical@lists.openehr.org > > > *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 < > silje.ljosland.ba...@nasjonalikt.no> 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 <openehr-clinical-boun...@lists.openehr.org> *On > Behalf Of *Pablo Pazos > *Sent:* Wednesday, June 27, 2018 3:45 AM > *To:* For openEHR clinical discussions <openehr-clinical@lists.openehr.org > > > *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 > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > > > > -- > > *Ing. Pablo Pazos Gutiérrez* > pablo.pa...@cabolabs.com > +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 > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > -- *Ing. Pablo Pazos Gutiérrez* pablo.pa...@cabolabs.com +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 openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
