Instruction & action archetypes?

Clinical (archive)
1

Hi!

Some (possibly stupid) questions:

- Are there any examples of instruction archetypes with more than one
activity anywhere?
- If different activities (of the same instruction) point to different
action archetypes how should then the resulting usage of the ISM be
interpreted? Can they be considered part of the same process with some
states in each action archetype?

A swift reply to one or more of the questions would be very welcome.

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/

2

Hello Erik,

I will provide you a quick answer, but I’ll reply to the list so other may comment as well.

Instructions and Actions are both entry subtypes but the difference is that Instructions tell what the planned activities were and Actions tell which actual actions were taken. They are meant to be recorded separately and since the instruction state machine (ISM) used in openEHR is coded by the support terminology the available states are static and every recorded action will cause a care flow step to be taken (which has an optional description) that defines a transition state in the ISM.

Also note that if the action was caused by an instruction the action will hold instruction details that reference the instruction and activity that was planned for the action.

Best wishes,

Mattias

2007/5/25, Erik Sundvall <erisu@imt.liu.se>:

3

Erik

We have just moved to multi-activity instructions in the archetype editor - examples that led to this (but are not on the web yet) are consent as part of a procedure instruction, and medication review as part of the medication instruction (it was formerly just a careflow step in the medication action itself but needs quite different data).

The state in the action does apply to an activity (mandatory) - as in fact only the activities have states (the instruction can have multiple states based on the sum of the states for all activities). Completing the instruction will mean placing all activities in a terminal state.

Remember, many actions will be entered without an instruction - so no activity id is required.

I hope this helps.

Cheers, Sam

Erik Sundvall wrote:

4

We have just moved to multi-activity instructions in the archetype editor -
examples that led to this (but are not on the web yet)

Would it be possible to get hold of those examples in a message to
this list, or in a private mail or by publication on the web or in
SVN? (If possible preferably before Wednesday morning European
time...)

In the openEHR "EHR Information Model" specification there is a nice
chapter with Instance structures that really help when explaining the
model. Would it be possible to add some examples for "Action" there
too? (Does anybody here on the list have instance examples of Action
structures available in any readable form?)

are consent as part
of a procedure instruction, and medication review as part of the medication
instruction (it was formerly just a careflow step in the medication action
itself but needs quite different data).

Thanks! Nice examples. I was actually trying to figure out where to
put consent in a process modeling situation.

The state in the action does apply to an activity (mandatory) - as in fact
only the activities have states

Do you mean _implicitly_ apply to an activity (since there are no
state-related fields in the class named ACTIVITY except a pattern
pointing out allowed action archetypes)? Maybe I am misunderstanding
something here.

Remember, many actions will be entered without an instruction - so no
activity id is required

Since the allowed states are archetyped in the ISM_TRANSITION of an
ACTION archetype where there are no mandatory references to ACTIVITY
instances or archetypes I wonder how the statement "state in the
action does apply to an activity (mandatory)" fits in.
If an ACTION is recorded ad hoc without an associated
INSTRUCTION+ACTIVITY-structure, then what is the state applying to? Is
there some implicit ACTIVITY? How is that then determined? If several
related actions (for the same implicit process) are recorded, can they
be connected somehow? Is it the "workflow_id" attribute of ENTRY that
connects them? Something else?

A related question: Why can an ENTRY only be associated with one
[0..1] workflow_id? Is it not possible that an ENTRY can be part of
several workflows defined in some external workflow engine(s)? (By the
way, wise choice not to commit to or include a specific workflow
engine in the openEHR spec. E Brownes thesis
http://www.openehr.org/publications/workflow/t_browne_thesis_abstract.htm
referenced in the spec is very enlightning on the current state of
affairs...)

(the instruction can have multiple states
based on the sum of the states for all activities). Completing the
instruction will mean placing all activities in a terminal state.

Thanks for the clarification there too.

I hope this helps.
Cheers, Sam

It sure did. Sorry if I am a bit dense not understanding everything
and for pestering you and the list with even more questions...

Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/