How to define transitions in the ISM

Pablo Pazos pablo.pazos at cabolabs.com
Mon Jul 2 16:44:40 EDT 2018


Hi Heather, thanks for the insight.

It seems this is a well known issue for clinical modelers.

I certainly agree with the criteria of the maximal dataset, IMO what makes
a maximal dataset depends on the modelers interpretation of each specific
use case. Of course less constraints allow a greater set of use cases to be
considered, but also increases the work that needs to be done to fill the
blanks between a generic archetype and a specific State Machine to be
implemented. That negotiation that you mention is what I described as
"extra metadata needs to be given for implementation".

In terms of the gap in modeling tools, I agree, technically archetype
editors and template designers (Ocean and others) should be able to
constraint the valid or invalid transitions. Then if modelers use or not
those constraints, should depend on their criteria, not on limitations of
modeling tools. On the other hand, *this issue of modeling tools not
supporting these constraints might be because in the RM, ISM_TRANSITION is
not LOCATABLE (all classes that can be archetyped), but inherits from
PATHABLE (RM 1.0.2 & 1.0.3)*. Considering this, it is a little inconsistent
that the AE allows to create constraints for ACTION.ism_transition, but
only for the ISM_TRANSITION.current_state and ISM_TRANSITION.careflow_step.
but not ISM_TRANSITION.transition.

Maybe a solution form the RM is to make ISM_TRANSITION inherit from
LOCATABLE, then update modeling tools to support it.

I will mention this to the SEC.


Best,
Pablo.


On Sun, Jul 1, 2018 at 4:21 AM, Heather Leslie <
heather.leslie at atomicainformatics.com> wrote:

> Hi Pablo,
>
>
>
> Every archetype ideally needs to be designed for the maximal dataset and
> universal use case. The ACTION archetypes are no different.
>
>
>
> But you have picked up on a major gap in our tooling at present – the
> modellers need the ability to be able to constrain the ACTION archetypes in
> templates for each use case:
>
>    - to show what data points are relevant for each pathway step, and
>    - which steps are relevant to our use case.
>
>
>
> It is also not currently possible for modellers to record the proposed
> workflow or transitions in any template at present. This is another major
> gap and, in practice, is usually managed on a project by project basis a
> negotiated by the parties involved – verbally, word docs etc.
>
>
>
> This is a relatively unexplored area where we need more tooling and/or
> standardised processes to communicate the requirements of the clinicians
> and intent of the modellers to the software engineers implementing systems.
>
>
>
> No silver bullet here, yet. But open to collaborate with anyone who has
> suggestions…
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> *From:* openEHR-clinical <openehr-clinical-bounces at lists.openehr.org> *On
> Behalf Of *Pablo Pazos
> *Sent:* Sunday, 1 July 2018 4:12 AM
> *To:* For openEHR clinical discussions <openehr-clinical at lists.openehr.org
> >
> *Subject:* Re: How to define transitions in the ISM
>
>
>
> Hi Silje,
>
>
>
> I got the issue with complex workflows.
>
>
>
> With the current solution you'll need to provide more metadata to the
> developers so they can implement the correct workflows, like possible or
> impossible transitions from one state to another, because constraints are
> not in the archetype.
>
>
>
> On the other hand, simple workflows can be completely specified in the
> archetype without providing extra medadata separately from the archetype,
> since both states and possible transitions can be specified there, like the
> little toy state machine on my previous message. The issue is the AE
> doesn't allow to express constraints for the ISM_TRANSITION.transition
> (DV_CODED_TEXT) attribute (a constraint that can explicitly state a list of
> valid transitions to reach that state, I think "transition" is about
> inbound transitions not outbound, but that is a separate issue). I'll test
> if this can be done using LinkEHR.
>
>
>
> Also for complex flows, it would be good to provide the possible
> transitions, even if the list of possibilities is big, this is just to make
> the archetype contain all the metadata needed for implementation, without
> the need of providing that externally to the archetype. I know this
> requires more work in the archetype, but it might be less work in total,
> since the problem will need to be solved as you said, in the business
> logic. IMO this approach does not add more constraints to the archetype,
> just more information, and made the implicit freedom of transitions
> explicit.
>
>
>
> Maybe this should be considered case by case, and modeling tools should
> allow to constraint the transition, but leave that to the modeler. I think
> a good approach is to constraint what can be constrained, for instance on
> the medication archetype there are a lot of transitions between active
> states, but maybe there are less transitions between other states, and
> those can be in the archetype. This would remove a little friction at
> development time.
>
>
>
> It would be nice to know how other modelers do this and how other
> implementers deal with non defined transitions in ACTION archetypes.
>
>
>
> Best,
>
> Pablo.
>
>
>
> On Wed, Jun 27, 2018 at 4:35 AM, Bakke, Silje Ljosland <
> silje.ljosland.bakke at nasjonalikt.no> wrote:
>
> Hi Pablo!
>
>
>
> I’ll try to answer your question about how clinical modellers solve this
> problem. Have a look at the ACTION.medication archetype (
> http://openehr.org/ckm/#showArchetype_1013.1.123). This archetype has 11
> separate steps for the ACTIVE state. In each medication management context,
> one or more of these will be relevant, and often in a way or order that’s
> not possible to predict. We therefore “solve” the problem by leaving it to
> the business logic of the application. This may be frustrating for the
> implementers (I don’t know, is it?), but it makes our work manageable.
> Designing ACTION archetypes is complex in the first place, and I’m not sure
> we’d get any published if we needed to map out all possible combinations
> and orders of pathway steps too.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-clinical <openehr-clinical-bounces at lists.openehr.org> *On
> Behalf Of *Pablo Pazos
> *Sent:* Wednesday, June 27, 2018 3:45 AM
> *To:* For openEHR clinical discussions <openehr-clinical at lists.openehr.org
> >
> *Subject:* How to define transitions in the ISM
>
>
>
> Hi all,
>
>
>
> I'm testing the AE for a new workshop, and designed a simple state machine
> for and order so my students can use it as basic for more complex state
> machines.
>
>
>
> I have: NEW (maps to ISM PLANNED), ASSIGNED (maps to ISM PLANNED), STARTED
> (maps to ISM ACTIVE) and FINISHED (maps to ISM COMPLETED).
>
>
>
> What the AE is not allowing is to specify the ISM_TRANSITION.transition :
> DV_CODED_TEXT.
>
>
>
> The problem is if I have two states mapped to ASSIGNED, how a software
> knows which one is the state to activate if the transition "initiate" is
> not define. Also I want to specify that from new should happen a
> "plan_step" transition to change the state to ASSIGNED. Seems we are
> missing important metadata in the archetype.
>
>
>
> How do clinical modelers solve those problems?
>
>
>
> Will test LinkEHR to see how they define the ISM and the valid transitions.
>
>
>
> Thanks,
>
> Pablo.
>
>
> --
>
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pazos at cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
>
>
>
> --
>
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pazos at cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pazos at cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180702/b62be193/attachment-0001.html>


More information about the openEHR-clinical mailing list