subject:"How to define transitions in the ISM"

Re: How to define transitions in the ISM

2018-08-27 Thread Diego Boscá

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

El sáb., 28 jul. 2018 a las 0:01, Heather Leslie (<
heather.les...@atomicainformatics.com>) escribió:

> 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
>
>
>
> *From:* openEHR-clinical  *On
> Behalf Of *Thomas Beale
> *Sent:* Saturday, 28 July 2018 6:12 AM
> *To:* openehr-clinical@lists.openehr.org
> *Subject:* Re: How to define transitions in the ISM
>
>
>
>
>
>
>
> On 01/07/2018 08:21, Heather Leslie 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.
>
>
> 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
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>

-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

SV: How to define transitions in the ISM

2018-08-06 Thread Ivar Yrke

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:

[cid:image001.jpg@01D42D79.AC1161A0]
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.

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 Bakke, Silje Ljosland
Sendt: 6. august 2018 10:42
Til: For openEHR clinical discussions 
Emne: RE: How to define transitions in the ISM

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.

Regards,
Silje

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Ivar Yrke
Sent: Monday, July 23, 2018 1:59 PM
To: For openEHR clinical discussions 
mailto:openehr-clinical@lists.openehr.org>>
Subject: SV: How to define transitions in the ISM

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 maint

RE: How to define transitions in the ISM

2018-08-06 Thread Bakke, Silje Ljosland

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.

Regards,
Silje

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Ivar Yrke
Sent: Monday, July 23, 2018 1:59 PM
To: For openEHR clinical discussions 
Subject: SV: How to define transitions in the ISM

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

Re: How to define transitions in the ISM

2018-07-27 Thread Thomas Beale

sible 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] *På vegne av* 
Pablo Pazos

*Sendt:* 2. juli 2018 22:45
*Til:* For openEHR clinical discussions 
<mailto: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 
<mailto:heather.les...@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
mailto:openehr-clinical-boun...@list

Re: How to define transitions in the ISM

2018-07-27 Thread Pablo Pazos

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.

On Fri, Jul 27, 2018 at 5:08 PM, Thomas Beale 
wrote:

>
>
> On 27/06/2018 08:35, Bakke, Silje Ljosland 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.
>
>
>
>
>
> 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,
>
>
> this is not a legal thing to do! If Assigned is a 'careflow step', its
> execution in the real world has to result in the ISM state machine being
> advanced to one defined state.
>
> So there is a problem from the outset with this discussion...
>
> - thomas
>
>
> ___
> 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://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

Re: How to define transitions in the ISM

2018-07-27 Thread Thomas Beale




On 01/07/2018 08:21, Heather Leslie 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.



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

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: How to define transitions in the ISM

2018-07-27 Thread Thomas Beale




On 27/06/2018 08:35, Bakke, Silje Ljosland 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.


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,



this is not a legal thing to do! If Assigned is a 'careflow step', its 
execution in the real world has to result in the ISM state machine being 
advanced to one defined state.


So there is a problem from the outset with this discussion...

- thomas

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: How to define transitions in the ISM

2018-07-27 Thread Diego Boscá

Well, LinkEHR has been around for a while now :)
We have implemented an "export to archetype editor" functionality that
limits the ADL syntax to what Archetype Editor & Template designer can
understand, so I'm pretty sure you won't have problems in that area.
In regards of OPT, exported OPTs are indistinguishable from the ones
created with TD. For example, if you import a template into LinkEHR and
export it right away OPT is exactly the same.

Regards

2018-07-27 11:59 GMT+02:00 Ivar Yrke :

> 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.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  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.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  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.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
>

SV: How to define transitions in the ISM

2018-07-27 Thread Ivar Yrke

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
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 mailto: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<mailto:openehr-clinical-boun...@lists.openehr.org>]
På vegne av Pablo Pazos
Sendt: 27. juli 2018 10:32
Til: For openEHR clinical discussions
mailto: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 mailto: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<mailto:openehr-clinical-boun...@lists.openehr.org>]
På vegne av Peter Gummer
Sendt: 26. juli 2018 15:18

Til: For openEHR clinical discussions
mailto: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 lim

Re: How to define transitions in the ISM

2018-07-27 Thread Pablo Pazos

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  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  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
>

Re: How to define transitions in the ISM

2018-07-27 Thread Diego Boscá

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  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-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  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:
>
>
>
> h

SV: How to define transitions in the ISM

2018-07-27 Thread Ivar Yrke

Pablo, it would be great to hear how to get on with LinkEHR.

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
Emne: Re: How to define transitions in the ISM

@Peter thanks for the feedback!

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 mailto:i...@dips.no>>
wrote:
Hi Peter, thanks for your reply. It adds several relevant facts and background
to the problem description.

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<mailto:openehr-clinical-boun...@lists.openehr.org>]
På vegne av Peter Gummer
Sendt: 26. juli 2018 15:18

Til: For openEHR clinical discussions
mailto:openehr-clinical@lists.openehr.org>>
Emne: Re: How to define transitions in the ISM

Hi Ivar and Pablo,

https://github.com/openEHR/arch_ed-dotnet/commit/7cd2968557074daec0e4ca97b6518483f516ba01

And here’s the comment that I wrote explaining the change:

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

Re: How to define transitions in the ISM

2018-07-27 Thread Diego Boscá

Yeah, in LinkEHR you are able to constraint any part of the RM, and since
the export OPT feature doesn't really remove any constraint probably it
should work for you.
In fact, I'm currently working on giving support to the creation of
ISM_TRANSITIONS in LinkEHR openEHR specific editor to ease the creation of
these constraints, I'll have news about it very soon.

2018-07-27 10:31 GMT+02:00 Pablo Pazos :

> @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  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-bounc
>> e...@lists.openehr.org] *På vegne av* Peter Gummer
>> *Sendt:* 26. juli 2018 15:18
>>
>> *Til:* For openEHR clinical discussions > r.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/7cd29685570
>> 74daec0e4ca97b6518483f516ba01
>>
>>
>>
>> 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
>> cons

Re: How to define transitions in the ISM

2018-07-27 Thread Pablo Pazos

@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  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.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  wrote:
>
>
>
> Hi all
>
> Somewhat la

Re: How to define transitions in the ISM

2018-07-27 Thread Peter Gummer

Hi Ivar,

On 27 Jul 2018, at 18:02, Ivar Yrke  wrote:
> 
> 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.

Just a minor point: the underlying classes are written in Eiffel, not Java. The 
Eiffel archetype parser underlying AE was forked from Thomas’s version 1.4 
parser in 2007, at the time when he started work on specialisations and other 
2.0 improvements. Yes indeed, fixes and enhancements to AE sometimes required 
changing the forked Eiffel code. The intention was that AE would eventually 
switch to the latest 2.0 parser code, with the option of backward compatibility 
with ADL 1.4, but we never got around to doing it. The Eiffel source code is 
here, by the way:

https://github.com/openEHR/adl-tools/tree/Aug2007ForkForAdlParserUsedByAE

I don’t recall digging deeply enough into how AE handled transitions to 
discover whether the underlying Eiffel parser had a problem with them.

Regards,
Peter___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

SV: How to define transitions in the ISM

2018-07-27 Thread Ivar Yrke

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 
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 mailto: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 po

Re: How to define transitions in the ISM

2018-07-26 Thread Peter Gummer

ood 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] På 
> vegne av Pablo Pazos
> Sendt: 2. juli 2018 22:45
> Til: For openEHR clinical discussions 
> 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 
>  <mailto:heather.les...@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  <mailto:openehr-clinical-boun...@lists.openehr.org>> On Behalf Of Pablo Pazos
> Sent: Sunday, 1 July 2018 4:12 AM
> To: For openEHR clinical discussions  <mailto: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 me

Re: How to define transitions in the ISM

2018-07-23 Thread Pablo Pazos

Thanks Ivar, that was a great explanation (much better than mine) and
describes the same issues I'm having with the legacy modeling tools, and
how that affects development.

I'm also looking into what Diego suggest, migrating the legacy modeling
tools to LinkEHR.


On Mon, Jul 23, 2018 at 12:03 PM, Diego Boscá  wrote:

> Hello,
>
> In principle, it is possible to edit the transition part of Action
> archetypes in LinkEHR by using the Archetype Tree view.
>
>
>
>
> Nothing fancy but should do the trick (at least it should be better than
> editing them by hand :)
>
> If there is interest we could improve the openEHR specific editor to
> support the definition of all ISM_TRANSITIONS constraints in a single dialog
>
> Regards
>
>
>
>
> 2018-07-23 13:58 GMT+02:00 Ivar Yrke :
>
>> 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-clinica

Re: How to define transitions in the ISM

2018-07-23 Thread Diego Boscá

Hello,

In principle, it is possible to edit the transition part of Action
archetypes in LinkEHR by using the Archetype Tree view.




Nothing fancy but should do the trick (at least it should be better than
editing them by hand :)

If there is interest we could improve the openEHR specific editor to
support the definition of all ISM_TRANSITIONS constraints in a single dialog

Regards




2018-07-23 13:58 GMT+02:00 Ivar Yrke :

> 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]
> *På vegne av* Pablo Pazos
> *Sendt:* 2. juli 2018 22:45
> *Til:* For openEHR clinical discussions  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 y

Re: How to define transitions in the ISM

2018-07-02 Thread Pablo Pazos

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.les...@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  *On
> Behalf Of *Pablo Pazos
> *Sent:* Sunday, 1 July 2018 4:12 AM
> *To:* For openEHR clinical discussions  >
> *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 constra

RE: How to define transitions in the ISM

2018-07-01 Thread Heather Leslie

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  On Behalf 
Of Pablo Pazos
Sent: Sunday, 1 July 2018 4:12 AM
To: For openEHR clinical discussions 
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 
mailto: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 
mailto:openehr-clinical-boun...@lists.openehr.org>>
 On Behalf Of Pablo Pazos
Sent: Wednesday, June 27, 2018 3:45 AM
To: For openEHR clinical discussions 
mailto: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

Re: How to define transitions in the ISM

2018-06-30 Thread Pablo Pazos

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  *On
> Behalf Of *Pablo Pazos
> *Sent:* Wednesday, June 27, 2018 3:45 AM
> *To:* For openEHR clinical discussions  >
> *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.
>
>
> --
>
> *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
>
>

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabo

RE: How to define transitions in the ISM

2018-06-27 Thread Bakke, Silje Ljosland

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  On Behalf 
Of Pablo Pazos
Sent: Wednesday, June 27, 2018 3:45 AM
To: For openEHR clinical discussions 
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.

--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

[https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]<https://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

How to define transitions in the ISM

2018-06-26 Thread Pablo Pazos

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.

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

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

Re: How to define transitions in the ISM

SV: How to define transitions in the ISM

RE: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

SV: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

SV: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

SV: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

Re: How to define transitions in the ISM

RE: How to define transitions in the ISM

Re: How to define transitions in the ISM

RE: How to define transitions in the ISM

How to define transitions in the ISM

24 matches

Site Navigation

Mail list logo

Footer information