Thanks Ivar, that makes it a lot clearer to me. 😊


From: openEHR-clinical <> On Behalf 
Of Ivar Yrke
Sent: Monday, August 06, 2018 11:36 AM
To: For openEHR clinical discussions <>
Subject: SV: How to define transitions in the ISM

I’ll try again. To see my problem, imagine that you have an instance of a state 
machine that is currently in SUSPENDED. Now tell a nurse what options he has. 
You can do that based on the RM and the actual ACTION archetype, provided you 
can relate the archetype constrains to the RM.

The possible transitions are pre-constrained by the RM, as you say, and there 
is no need from our side to change that. The problem we face is that the 
ISM_TRANSITIONS as they are generated by current tools, do not carry enough 
information to identify their place in the RM. Which arrow do they represent? 
The only thing we get to know is their “end point” (current_state), but we 
cannot distinguish e.g. “resume” from “active_step”. Having the transition 
property populated would solve this for us. Without this information what our 
applications see is basically a mutilated state chart diagram, like this:

We can see that there are incoming and outgoing arrows, but we have no 
information about which end belongs to which. From the RM we know that there 
can be an arrow going from SUSPENDED to ACTIVE, but which one is it? I know, 
again from RM, that its transition is “resume”, but without this information I 
just see like in the diagram. Even though my archetype has two ISM_TRANSITIONS 
with current_state ACTIVE, there is no way to figure out which of them are 
relevant from the SUSPENDED state. We simply need more information in the 
archetype to be able to refer it to the RM.

So what is the big deal, can’t I just pick one? Well, in a just recording 
scenario I could. But I want to present the options to the nurse as guidance 
and there is a rather big difference in presenting the option “Resume suspended 
drug” from “Deliver drug” (these texts are the workflow_steps). To do that 
correctly I need to know which arrow goes out of SUSPENDED and the transition 
(together with RM) will tell me that.

Vennlig hilsen
Ivar Yrke
Senior systemutvikler
Telefon +47 75 59 24 06
Mobil +47 90 78 89 33

Fra: openEHR-clinical [] 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.


From: openEHR-clinical [] 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 action.

With regards,
Ivar Yrke
Senior systemutvikler
Telephone +47 75 59 24 06
Mobile +47 90 78 89 33

Fra: openEHR-clinical [] 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.


On Sun, Jul 1, 2018 at 4:21 AM, 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 



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.


On Wed, Jun 27, 2018 at 4:35 AM, 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 
( 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.


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.

(maps to ISM ACTIVE) and FINISHED (maps to ISM COMPLETED).

What the AE is not allowing is to specify the ISM_TRANSITION.transition : 

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 

How do clinical modelers solve those problems?

Will test LinkEHR to see how they define the ISM and the valid transitions.


Ing. Pablo Pazos Gutiérrez<>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<>


openEHR-clinical mailing list<>

Ing. Pablo Pazos Gutiérrez<>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<>


openEHR-clinical mailing list<>

Ing. Pablo Pazos Gutiérrez<>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<>


openEHR-clinical mailing list

Reply via email to