On 23 Jul 2018, at 21:58, Ivar Yrke <[email protected]
<mailto:[email protected]>> wrote:
Hi all
Somewhat late reply due to vacation…
We have come across that same problem and for us it actually was a
show stopper for which we had to invent a work around.
*First a remark about the tools:*
We saw that ArchetypeEditor did not add the transition. So we tried
to add I manually to the adl-file. We found however that AE ignores
it and after saving again from AE it is gone. Further we tried to use
the modified adl in a template using Template Designer, but it was
ignored and no trace of it in the resulting opt.
These are very serious limitations in the tools and forces a work
around that we should very much like to abandon (see below). It
raises the question how the community should go forward to make sure
there are appropriate tools. Who owns the tools? Who pays for their
maintenance?
The ISM is potentially a very powerful asset of openEHR. Missing the
transition property mutilates it to very limited value.
*Then a remark to Silje’s reply:*
“Solving” the problem in the business logic is only possible when
recoding after the fact. Given that the current state is so and so
and the new state is so and so we can deduce (in most cases) the
transition.
*Our problem:*
Our problem is the opposite of solving after the fact. We want to
present to the user only the transitions valid at any moment in time.
Given the ISM and completely defined ISM_TRANSITIONs this would be
possible and easy. But not so without the transition! Without that
information it is not possible to distinguish the transitions having
the same current state.
To see the problem, assume a simple state machine with one of each of
these transitions: active_step, suspend and resume. Let the current
state be SUSPENDED (last recorded action was suspend). In this state
we only want to give the user the option to resume. However, without
the transition property in the ISM_TRANSITION we cannot distinguish
resume from active_step. Both have ACTIVE as their current step and
careflow_step is only descriptive and not usable. The only option is
to give the user all choices and assume he does the right thing. Not
a good option. After all, resuming a suspended drug and administering
the drug are quite different things and we do not want an erroneous
administering to take place as result of our system suggesting it!
*Our work around:*
Fortunately each ISM_TRANSITION has a unique id. Based on this id we
add the missing transition, from our own local configuration, to the
archetypes we use after having loaded them. This information is
transient and only lives in our memory instances of the archetype.
But at least we have it available so that we can make a full state
machine evaluation and find only the relevant transitions to present
to the user.
*Some questions:*
What if the user inadvertently administers a drug that has been
suspended? In that case he surely needs to have this transition
anyway, doesn’t he? Well, yes, but not as a suggestion from our
system! This situation must be handled separately from guiding the
user through the states. In fact, it could be argued that this be
recorded as an ad hoc action.
With regards,
*Ivar Yrke*
Senior systemutvikler
DIPS AS
Telephone +47 75 59 24 06
Mobile +47 90 78 89 33
*Fra:*openEHR-clinical
[mailto:[email protected]] *På vegne av*
Pablo Pazos
*Sendt:* 2. juli 2018 22:45
*Til:* For openEHR clinical discussions
<[email protected]
<mailto:[email protected]>>
*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
<[email protected]
<mailto:[email protected]>> wrote:
Hi Pablo,
Every archetype ideally needs to be designed for the maximal
dataset and universal use case. The ACTION archetypes are no
different.
But you have picked up on a major gap in our tooling at present –
the modellers need the ability to be able to constrain the ACTION
archetypes in templates for each use case:
·to show what data points are relevant for each pathway step, and
·which steps are relevant to our use case.
It is also not currently possible for modellers to record the
proposed workflow or transitions in any template at present. This
is another major gap and, in practice, is usually managed on a
project by project basis a negotiated by the parties involved –
verbally, word docs etc.
This is a relatively unexplored area where we need more tooling
and/or standardised processes to communicate the requirements of
the clinicians and intent of the modellers to the software
engineers implementing systems.
No silver bullet here, yet. But open to collaborate with anyone
who has suggestions…
Regards
Heather
*From:*openEHR-clinical
<[email protected]
<mailto:[email protected]>> *On Behalf
Of *Pablo Pazos
*Sent:* Sunday, 1 July 2018 4:12 AM
*To:* For openEHR clinical discussions
<[email protected]
<mailto:[email protected]>>
*Subject:* Re: How to define transitions in the ISM
Hi Silje,
I got the issue with complex workflows.
With the current solution you'll need to provide more metadata to
the developers so they can implement the correct workflows, like
possible or impossible transitions from one state to another,
because constraints are not in the archetype.
On the other hand, simple workflows can be completely specified
in the archetype without providing extra medadata separately from
the archetype, since both states and possible transitions can be
specified there, like the little toy state machine on my previous
message. The issue is the AE doesn't allow to express constraints
for the ISM_TRANSITION.transition (DV_CODED_TEXT) attribute (a
constraint that can explicitly state a list of valid transitions
to reach that state, I think "transition" is about inbound
transitions not outbound, but that is a separate issue). I'll
test if this can be done using LinkEHR.
Also for complex flows, it would be good to provide the possible
transitions, even if the list of possibilities is big, this is
just to make the archetype contain all the metadata needed for
implementation, without the need of providing that externally to
the archetype. I know this requires more work in the archetype,
but it might be less work in total, since the problem will need
to be solved as you said, in the business logic. IMO this
approach does not add more constraints to the archetype, just
more information, and made the implicit freedom of transitions
explicit.
Maybe this should be considered case by case, and modeling tools
should allow to constraint the transition, but leave that to the
modeler. I think a good approach is to constraint what can be
constrained, for instance on the medication archetype there are a
lot of transitions between active states, but maybe there are
less transitions between other states, and those can be in the
archetype. This would remove a little friction at development time.
It would be nice to know how other modelers do this and how other
implementers deal with non defined transitions in ACTION archetypes.
Best,
Pablo.
On Wed, Jun 27, 2018 at 4:35 AM, Bakke, Silje Ljosland
<[email protected]
<mailto:[email protected]>> wrote:
Hi Pablo!
I’ll try to answer your question about how clinical modellers
solve this problem. Have a look at the ACTION.medication
archetype (http://openehr.org/ckm/#showArchetype_1013.1.123).
This archetype has 11 separate steps for the ACTIVE state. In
each medication management context, one or more of these will
be relevant, and often in a way or order that’s not possible
to predict. We therefore “solve” the problem by leaving it to
the business logic of the application. This may be
frustrating for the implementers (I don’t know, is it?), but
it makes our work manageable. Designing ACTION archetypes is
complex in the first place, and I’m not sure we’d get any
published if we needed to map out all possible combinations
and orders of pathway steps too.
Regards,
*Silje*
*From:* openEHR-clinical
<[email protected]
<mailto:[email protected]>> *On
Behalf Of *Pablo Pazos
*Sent:* Wednesday, June 27, 2018 3:45 AM
*To:* For openEHR clinical discussions
<[email protected]
<mailto:[email protected]>>
*Subject:* How to define transitions in the ISM
Hi all,
I'm testing the AE for a new workshop, and designed a simple
state machine for and order so my students can use it as
basic for more complex state machines.
I have: NEW (maps to ISM PLANNED), ASSIGNED (maps to ISM
PLANNED), STARTED (maps to ISM ACTIVE) and FINISHED (maps to
ISM COMPLETED).
What the AE is not allowing is to specify the
ISM_TRANSITION.transition : DV_CODED_TEXT.
The problem is if I have two states mapped to ASSIGNED, how a
software knows which one is the state to activate if the
transition "initiate" is not define. Also I want to specify
that from new should happen a "plan_step" transition to
change the state to ASSIGNED. Seems we are missing important
metadata in the archetype.
How do clinical modelers solve those problems?
Will test LinkEHR to see how they define the ISM and the
valid transitions.
Thanks,
Pablo.
--
