How to define transitions in the ISM
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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical