How to define transitions in the ISM

Thomas Beale thomas.beale at openehr.org
Fri Jul 27 16:08:42 EDT 2018



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180727/9f93bdcc/attachment.html>


More information about the openEHR-clinical mailing list