Questions about the relationship between Instruction, workflow and Action

Clinical (archive)
1

Hi everyone!

I’m trying to understand how to execute a state machine of a fully structured INSTRUCTION, and I have some questions and thoughts to share with you…

The first issue is about archetyping an ACTION that execute and ACTIVITY of an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are specializations of PATHABLE, so those shouldn’t be archetypable (see http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).
Is this a bug in the AE or is an issue in the specs?

If the “ACTION.instruction_details” attribute can’t be archetyped in the AE, how could I know what specific structure the “ACTION.instruction_details.wf_details” attribute will have?

Is the “ACTION.instruction_details.wf_details” attribute related somehow with the “ACTIVITY.description” attribute?

The description of the “ACTION.instruction_details.wf_details” attribute says: condition that fired to cause this Action to be done (with actual variables substituted),
What is the meaning of “with actual variables substituted”? This makes me think having an ACTIVITY in memory, creating an instance of an ACTION to record the execution of that ACTIVITY, copying the ACTIVITY.description structure into the ACTION.instruction_details.wf_details, and the update the correspondent fields into the wf_details with actual execution data.

Does this make any sense? or I’m just to twisted :smiley:

The last one!
Now only ACTIONs can change a state on the ISM, but I think an ADMIN_ESTRY could change the state also, e.g. to move a “planned procedure” to the “scheduled” state, there is an administrative step of coordinating date & time, not a clinical action. Again, does this make any sense?!

Thanks a lot!

2

Nobody? :cry:

Maybe is better just one question at a time, sorry for that.

3

Hi Pablo,

The design principles are that the Instruction should remain unaltered by people basing actions on this instructions – as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc.

So the state of the instruction is carried in the record of the action (if appropriate). We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on.

In our openEHR repository we maintain an instruction index – that is a pointer to all instructions and all actions that relate to that instruction – and the current state of the instruction.

You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state.

Hope this helps.

Cheers, Sam

4

Hi Sam, thanks for the answer… I’m having several hours of bad sleeping, trying to understand this :smiley:

Hi Pablo,

The design principles are that the Instruction should remain unaltered by people basing actions on this instructions – as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc.

Sounds very reasonable. But I think that sometimes administrative entries could also change the state of an Instruction, like when scheduling a procedure.

I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, …) and them a message is sent to the EHR to tell the Instruction had been scheduled.

But: how is that change of the Instruction state recorded on the EHR?

Receiving a message from an external system could trigger the creation of an ACTION?

Is that the way you have implemented that?

So the state of the instruction is carried in the record of the action (if appropriate).

Is that recorded on ACTION.instruction_details.wf_details?

We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on.

You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state.

I think I saw that on the ehr_im.pdf as an example for “UK GP medicaton order workflow”.

As I understand it, this can be done by constraining the “ACTION.ism_transition” attribute, with the Archetype Editor, for all the ACTIONS that will be used to execute ACTIVITIES of the medication order INSTRUCTION.

If that’s right (?), maybe there’s a bug on the specs, because ISM_TRANSITION inherits from PATHABLE, and to be archetyped I think it should inherit from LOCATABLE (see ehr_im.pdf page 53).

For the workflow definition, do you use the INSTRUCTION.wf_definition? I can’t find an example on how to express a workflow there (maybe something like this could help http://doc.openerp.com/v6.0/developer/3_9_Workflow_Business_Process/index.html).

In our openEHR repository we maintain an instruction index – that is a pointer to all instructions and all actions that relate to that instruction – and the current state of the instruction.

Ok, so at an instance level, we should have all INSTRUCTION instances, the current state of each instruction, and all the ACTIONs executed for each INSTRUCTION/ACTIVITY.

That is a great implementation consideration, I’ll add that on the openEHR spanish course docs. :smiley:

Thanks a lot!

Cheers,

Pablo.

5

Hi Pablo,

Few clarifications inline.

6

Hi Heather,

I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, …) and them a message is sent to the EHR to tell the Instruction had been scheduled.

But: how is that change of the Instruction state recorded on the EHR?

[HL>] The INSTRUCTION for a procedure remains unchanged, unless the clinician changes the nature of the original order and this is carried out with a revision of the committed INSTRUCTION.

The ACTION is recording the progress of activity in carrying out the INSTRUCTION – ie the procedure is planned, scheduled, performed, completed and at each of these pathway steps the appropriate data is captured eg what procedure is scheduled and the scheduled time; and what/ when was actually finally performed etc. What was actually done/performed/administered may be different to what was originally ordered due to clinical circumstances etc – the ACTION allows this evolution to be captured. Yet through all this the original instruction/order persists as is.

I understood that part and agree 100%: We have the record of the original Instruction untouched, or if it need a change from a clinical point of view, this will be a new version/revision of the previous Instruction.

Receiving a message from an external system could trigger the creation of an ACTION?

[HL>] It could trigger the creation of an ACTION if received from a scheduling system and there had been no ACTION created previously. That same newly created ACTION could then be used to record the data against subsequent pathway steps.

OR the message could be used to trigger an entry using the existing ACTION containing the Scheduled data against the Scheduled pathway.

That’s the problematic point I see on the use of an ACTION to record something that is merely administrative and may have no clinical relevancy.

An ACTION should be … “Used to record a clinical action that has been performed, which may have been ad hoc, or due to the execution of an Activity in an Instruction workflow. Every Action corresponds to a careflow step of some kind or another.” (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73).

I think we could analize this topic through an implementation (I think that’s what you and Sam have mentioned) with the solution of having messages triggering ACTION creation or recording data on existing ACTIONs.

But I think we need to revise the openEHR specs, to see if this topic is clear enough, because I don’t see a clear solution in the standard itself (maybe others could have better luck than mine).

Or maybe this is one of those things that are not defined by the standard, like EHR security or RM persistence, and each implementation could create it’s own solution. If that’s the case, I think “Instruction management” is an important issue on EHR development and it should be considered on the specs. And my small contribution on this is that maybe ADMIN ENTRIES could also trigger/record Instruction state changes (without changing the instruction itself).

Is that the way you have implemented that?

So the state of the instruction is carried in the record of the action (if appropriate).

Is that recorded on ACTION.instruction_details.wf_details?

Thanks a lot!

regards,

Pablo.

7

Hi Heather,

I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, …) and them a message is sent to the EHR to tell the Instruction had been scheduled.

But: how is that change of the Instruction state recorded on the EHR?

[HL>] The INSTRUCTION for a procedure remains unchanged, unless the clinician changes the nature of the original order and this is carried out with a revision of the committed INSTRUCTION.

The ACTION is recording the progress of activity in carrying out the INSTRUCTION – ie the procedure is planned, scheduled, performed, completed and at each of these pathway steps the appropriate data is captured eg what procedure is scheduled and the scheduled time; and what/ when was actually finally performed etc. What was actually done/performed/administered may be different to what was originally ordered due to clinical circumstances etc – the ACTION allows this evolution to be captured. Yet through all this the original instruction/order persists as is.

I understood that part and agree 100%: We have the record of the original Instruction untouched, or if it need a change from a clinical point of view, this will be a new version/revision of the previous Instruction.

Receiving a message from an external system could trigger the creation of an ACTION?

[HL>] It could trigger the creation of an ACTION if received from a scheduling system and there had been no ACTION created previously. That same newly created ACTION could then be used to record the data against subsequent pathway steps.

OR the message could be used to trigger an entry using the existing ACTION containing the Scheduled data against the Scheduled pathway.

That’s the problematic point I see on the use of an ACTION to record something that is merely administrative and may have no clinical relevancy.

[HL>] >From my point of view, it may be an administrative detail, but just the fact that something has been scheduled (without necessarily details of the time/date/location) is a valuable part of a clinical record. It does have clinical relevance as it records what has been done in the steps required to carry out at order/INSTRUCTION. While a non-clinical person may have technically carried out the ACTION, it is still critical info in the clinical record, still a ‘clinical action’ IMO.

An ACTION should be … “Used to record a clinical action that has been performed, which may have been ad hoc, or due to the execution of an Activity in an Instruction workflow. Every Action corresponds to a careflow step of some kind or another.” (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73).

I think we could analize this topic through an implementation (I think that’s what you and Sam have mentioned) with the solution of having messages triggering ACTION creation or recording data on existing ACTIONs.

[HL>] It is not at all simple to envisage how the flow of INSTRUCTION and various resulting ACTIONS play out, and I can’t pretend to have it all 100% clear, but with implementations (and Heath Frankel certainly has plenty of recent experience) it is proving to work in practice.

But I think we need to revise the openEHR specs, to see if this topic is clear enough, because I don’t see a clear solution in the standard itself (maybe others could have better luck than mine).

Or maybe this is one of those things that are not defined by the standard, like EHR security or RM persistence, and each implementation could create it’s own solution. If that’s the case, I think “Instruction management” is an important issue on EHR development and it should be considered on the specs. And my small contribution on this is that maybe ADMIN ENTRIES could also trigger/record Instruction state changes (without changing the instruction itself).

Is that the way you have implemented that?

So the state of the instruction is carried in the record of the action (if appropriate).

Is that recorded on ACTION.instruction_details.wf_details?

Thanks a lot!

regards,

Pablo.

8

Perhaps I responded to the wrong thread, I will repost what I said in response to “Revision of Instructions – clinical implications”.

When you order a lab test you actually need an Instruction to define the lab test, and an action to put It into the ordered state. The request time of the lab test order is the time in the action with the ordered state. An instruction without an action is not yet executing within a workflow.

BTW, the workflow definition attribute is not intended to carry archetyped data. It is intended to specify the definition of a workflow executing within a workflow engine or similar. The workflow ID references the instance of the workflow executing for this instruction. We also use this for real world non-computerised workflows, such as a lab order number to allow us to keep track all the entries that relate to the same lab request including observations and evaluation.

Heath

9

Hi Heather,

You give me a lot to thought about. In my mind I was reserving the creation of actions, observations, instructions and evaluations only for clinical staff, now I see that administrative clerks could also create (directly or indirectly) actions on the clinical record. That will suffice for explaining how to implement all the changes in an instruction’s state.

Thanks a lot for your patience!

10

Hi Sam,

I’m reviving this thread :smiley:

I’m working on a project and we need to define a simple state machine, this is the way I think it should be done and it would be very nice to have you comments about this:

The idea is to record physical activity recomended by a clinician.

There is one INSTRUCTION (the recommendation) with many ACTIVITIES (each one a recommended sport or activity).
We have 4 states: INITIAL, SCHEDULED, ACTIVE and COMPLETED.
And there are 2 ACTIONS, one to record the scheduling of the activity and other to record the initiation and end of the activity. (Let’s say these are SCHED_ACTION and INIT_END_ACTION).

When a recommendation is created (INSTRUCTION and ACITIVITIES), the current state is INITIAL (that should be saved on the repository that you mentioned in your email).

Now we need to model the state machine: INITIAL --(schedule)–> SCHEDULED --(start)–> ACTIVE --(finish)–> COMPLETED.

So, we create a ISM_TRANSITION on the SCHED_ACTION with current_state = INITIAL and careflow_step = schedule.
And in the INIT_END_ACTION we have 2 ISM_TRANSITIONs with curr_state = SHCEDULED and careflow_step = start, and the other, curr_state = ACTIVE and careflow_step = finish.

The third part should be to provide the entry point to execute that ISM, so we set the SCHED_ACTION.archetypeId to each ACTIVITY.action_archetype_id, so when the INSTRUCTION is on INITIAL, only a SCHED_ACTION could be executed.

And, on any ACTION execution, we update the repository with the action executed and the new state (and we keep all the actions and transitions taken so we can reproduce the process later).

What do you think? That’s the right way to do it?

11

Hi Pablo,

Comments in line…

Hi Sam,

I’m reviving this thread :smiley:

I’m working on a project and we need to define a simple state machine, this is the way I think it should be done and it would be very nice to have you comments about this:

The idea is that the ‘computational’ state machine is defined in the RM - initial, active, etc. you are defining the clinically relevant steps, linked to this underlying state machine. These are archetyped.

The idea is to record physical activity recomended by a clinician.

There is one INSTRUCTION (the recommendation) with many ACTIVITIES (each one a recommended sport or activity).
We have 4 states: INITIAL, SCHEDULED, ACTIVE and COMPLETED.
And there are 2 ACTIONS, one to record the scheduling of the activity and other to record the initiation and end of the activity. (Let’s say these are SCHED_ACTION and INIT_END_ACTION).

When a recommendation is created (INSTRUCTION and ACITIVITIES), the current state is INITIAL (that should be saved on the repository that you mentioned in your email).

The action will be to ‘prescribe’ the exercise or plan it - something the clinician will understand. The state will be initial.

Now we need to model the state machine: INITIAL --(schedule)–> SCHEDULED --(start)–> ACTIVE --(finish)–> COMPLETED.

The ACTION to schedule will have the state Scheduled, to undertake the exercise with state Active and then an Action to record completing the exercise with state Completed.

So, we create a ISM_TRANSITION on the SCHED_ACTION with current_state = INITIAL and careflow_step = schedule.

State = Scheduled

And in the INIT_END_ACTION we have 2 ISM_TRANSITIONs with curr_state = SHCEDULED and careflow_step = start,

The state is Active , the crr_state is the state after the transition.

and the other, curr_state = ACTIVE and careflow_step = finish.

Completed

The third part should be to provide the entry point to execute that ISM, so we set the SCHED_ACTION.archetypeId to each ACTIVITY.action_archetype_id, so when the INSTRUCTION is on INITIAL, only a SCHED_ACTION could be executed.

And, on any ACTION execution, we update the repository with the action executed and the new state (and we keep all the actions and transitions taken so we can reproduce the process later).

This is correct…linking with EHR path or WorkflowID - which allows linking other ENTRYs as well.

What do you think? That’s the right way to do it?

Hope that helps - Sistine might give a little more guidance.

Cheers Sam

12

Hi Pablo,

The states that Sam has indicated are correct. The careflow_step is the bit that’s archetyped and these should be terms that clinicians use/understand to identify the steps in the clinical process ore ‘careflow’ (like “plan exercise program” → “start exercise” → “monitor weight loss” → “adjust exercise program”). Each of these steps in the careflow should result in a state transition in the system as they are performed and you define the mapping between the two in the archetype.

You may note that the ‘initial’ state does not appear in the Archetype Editor. It’s begins at the concrete openEHR state of “Planned”. This makes sense to me, from an archetyping / recording point of view where as soon as the clinician has described and recorded the Instruction of what to do, it’s essentially set to ‘planned’ in reality.

Hope that makes sense. /:-\

Cheers,

Sistine

13

Hi Sam / Sistine,

Thanks for the answers, both were very helpful.

I was checking the specs, just need to confirm a couple of points:

  1. The archetyped attribute ACTION.ism_transition.current_state is not the current state of the ACTIVITY, but is the next state (the state after the transition is executed).

  2. If an ACTION archetype define more than one ISM_TRANSITION, who is responsible to check what transitions could be executed from the current state of an ACTIVITY? (in your software maybe this is done querying the instruction index repository (?))

  3. From the specs (ehr_im p.65): “These descriptions [ACTIVITY.description & ACTION.description] are always of the same form for any given Instruction, and it is highly desirable to have the same archetype component for both”.
    As I understand it, this means that the description structure should be the same. But what happens when the ACTION should have data related only the the ACTION executed (e.g. perceived exertion is only part of the exercise results), is this also part of the ACTIVITY description archetype?

Thanks a lot!
Pablo.

14

Hi Pablo,

Comments inline…