How to define transitions in the ISM

Diego Boscá yampeku at gmail.com
Fri Jul 27 05:24:01 EDT 2018


That's why specific rm editors are also provided with LinkEHR, to hide that
complexity. I'm adding support to these new classes to the openEHR editor
as we speak :)

El vie., 27 jul. 2018 11:14, Ivar Yrke <iyr at dips.no> escribió:

> 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-bounces at lists.openehr.org]
> *På vegne av* Pablo Pazos
> *Sendt:* 27. juli 2018 10:32
> *Til:* For openEHR clinical discussions <
> openehr-clinical at 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 <iyr at 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-bounces at lists.openehr.org]
> *På vegne av* Peter Gummer
> *Sendt:* 26. juli 2018 15:18
>
>
> *Til:* For openEHR clinical discussions <
> openehr-clinical at 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 <iyr at 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-bounces at lists.openehr.org
> <openehr-clinical-bounces at lists.openehr.org>] *På vegne av* Pablo Pazos
> *Sendt:* 2. juli 2018 22:45
> *Til:* For openEHR clinical discussions <
> openehr-clinical at 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 at 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-bounces at lists.openehr.org> *On
> Behalf Of *Pablo Pazos
> *Sent:* Sunday, 1 July 2018 4:12 AM
> *To:* For openEHR clinical discussions <openehr-clinical at 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.bakke at 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-bounces at lists.openehr.org> *On
> Behalf Of *Pablo Pazos
> *Sent:* Wednesday, June 27, 2018 3:45 AM
> *To:* For openEHR clinical discussions <openehr-clinical at 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 at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
>
>
> --
>
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pazos at 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 at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180727/95f1227f/attachment-0001.html>


More information about the openEHR-clinical mailing list