Questions about the relationship between Instruction, workflow and Action

2012-08-09 Thread Sistine Barretto-Daniels
Hi Pablo,

 

Comments inline...

 

From: pablo pazos [mailto:pazospa...@hotmail.com] 
Sent: Saturday, 4 August 2012 6:15 AM
To: openeh technical
Cc: sistine.barretto-daniels at oceaninformatics.com
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

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).

 

The ?current_state? is the state of the INSTRUCTION ACTIVITY as a *result*
of performing an ACTION.  So, it *is* the current state of the ACTIVITY.
?The ACTION.transition? attribute tells you what state transition was fired
in order to reach that current_state.

 

E.g.:

* If previous ACTION state was = ?planned?, and the next ACTION state
recorded was ?active?, then the ACTION.transition would = ?start? (openEHR
code 540). (Refer to page 62 of EHR_IM spec for state machine model +
openEHR terminology spec to see the term and code values).

* If previous ACTION state was = ?active? and the next ACTION state was
?completed?, then the ACTION.transition = ?finish? (code = 548).

 

The state machine model defines the allowable transitions that can occur
between states, so you must ensure that the current_state is reachable based
on the state machine model otherwise it is invalid.

 

The ACTIVITY defines what should be done and when, but the ACTION describes
what was actually done and when it was actually done.  So, if the GP for
instance wants to know the current state of his prescription (described in
an INSTRUCTION.ACTIVITY), then we can query the latest corresponding ACTION
(and it might say it?s been dispensed (=active) or whatever).

 

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 (?))

 

From an openEHR repository point of view, it should check that the data is
valid against the archetype  RM, and this includes whether or not the
current_state of an ACTION recorded has a valid transition value based on
the openEHR ISM model.  At the moment, this has been partially implemented
in our Instruction Index.  In particular, we keep a tab of when an Activity
has reached a terminal state and when and does not allow further ACTIONs
with terminal states to be committed.  In future, this will need to
implement the entire openEHR ISM model validation checking.

 

However, it is the responsibility of the application to ensure that only the
valid *next* careflow_steps are made available to be performed.  This is
more from the perspective of the business/clinical process.  This *may* be
assisted via a workflow engine that maintains a ?worklist? that tells the
users for instance, what work (/?to do?) items are allowed to be done next,
etc, and/or invokes other appropriate applications or services that are
allowed to be used at that point in time.  As the workflow progresses, its
internal state based on the openEHR ISM can be persisted in the EHR. 

 

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?

 

It?s ?desirable? I guess with the view of encouraging archetype reuse where
it is possible, but not compulsory, so I don?t see why you couldn?t have a
different different structures between the activity and the action.  Sam may
want to add his thoughts on this in terms of examples in clinical practice
and comment on your specific domain requirements (e.g. exercise).

 

Hope this helps,

Sistine

 

Thanks a lot!

Pablo.

 

  _  

From: sistine.barre...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: RE: Questions about the relationship between Instruction, workflow
and Action
Date: Thu, 2 Aug 2012 17:56:20 +0930
CC: Sistine.Barretto-Daniels at oceaninformatics.com

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

Questions about the relationship between Instruction, workflow and Action

2012-08-03 Thread pablo pazos

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.
From: sistine.barre...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: RE: Questions about the relationship between Instruction,  
workflow and Action
Date: Thu, 2 Aug 2012 17:56:20 +0930
CC: Sistine.Barretto-Daniels at oceaninformatics.com

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 From: 
openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Sam Heard
Sent: Thursday, 2 August 2012 2:02 AM
To: For openEHR technical discussions
Cc: Sistine Barretto-Daniels
Subject: Re: Questions about the relationship between Instruction, workflow and 
Action Hi Pablo, Comments in line

Sent from my phone
On 01/08/2012, at 15:39, pablo pazos pazospablo at hotmail.com wrote:Hi Sam, 
I'm reviving this thread :D 

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

FW: Questions about the relationship between Instruction, workflow and Action

2012-08-01 Thread pablo pazos

Hi Sam,
I'm reviving this thread :D 

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?
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

From: sam.he...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: RE: Questions about the relationship between Instruction,  
workflowand Action
Date: Wed, 7 Dec 2011 13:09:31 +0930

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
From: pazospa...@hotmail.com
To: openehr-clinical at openehr.org; openehr-technical at openehr.org
Subject: Questions about the relationship between Instruction, workflow and 
Action
Date: Sun, 4 Dec 2011 15:36:36 -0300Hi 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 :D  The last one!Now only ACTIONs can change a state on the 
ISM, but I think

Questions about the relationship between Instruction, workflow and Action

2012-08-01 Thread Sam Heard
Hi Pablo,

Comments in line

Sent from my phone

On 01/08/2012, at 15:39, pablo pazos pazospablo at hotmail.com wrote:

 Hi Sam,
 
 I'm reviving this thread :D 
 
 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 correctlinking 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

 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos
 
 From: sam.heard at oceaninformatics.com
 To: openehr-technical at openehr.org
 Subject: RE: Questions about the relationship between Instruction,
 workflowand Action
 Date: Wed, 7 Dec 2011 13:09:31 +0930
 
 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
 
 
 
 From: pazospablo at hotmail.com
 To: openehr-clinical at openehr.org; openehr-technical at openehr.org
 Subject: Questions about the relationship between Instruction, workflow and 
 Action
 Date: Sun, 4 Dec 2011 15:36:36 -0300
 
 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

Questions about the relationship between Instruction, workflow and Action

2011-12-15 Thread pablo pazos

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!

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

From: heather.les...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: RE: Questions about the relationship between Instruction,  
workflowand Action
Date: Mon, 12 Dec 2011 15:00:13 +1100

 From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Sunday, 11 December 2011 8:39 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow and 
Action 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

Questions about the relationship between Instruction, workflow and Action

2011-12-12 Thread Heath Frankel
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

 

From: Heather Leslie [mailto:heather.les...@oceaninformatics.com] 
Sent: Monday, 12 December 2011 1:30 PM
To: 'For openEHR technical discussions'
Cc: heath.frankel at oceaninformatics.com
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Sunday, 11 December 2011 8:39 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

Hi Heather,

I asked Heather on that issue (
http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-ar
chetype/
http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-arc
hetype/) 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

Questions about the relationship between Instruction, workflow and Action

2011-12-09 Thread Heather Leslie
Hi Pablo,

Few clarifications inline.

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Friday, 9 December 2011 7:16 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

Hi Sam, thanks for the answer... I'm having several hours of bad sleeping,
trying to understand this :D

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-ar
chetype/) 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.

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.

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.h
tml
http://doc.openerp.com/v6.0/developer/3_9_Workflow_Business_Process/index.ht
ml).

 

 

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. :D

 

 

 

Thanks a lot!

 

Cheers,

Pablo.

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111209/fd0a6475/attachment.html


Questions about the relationship between Instruction, workflow and Action

2011-12-08 Thread pablo pazos

Hi Sam, thanks for the answer... I'm having several hours of bad sleeping, 
trying to understand this :D



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. :D


Thanks a lot!
Cheers,Pablo. 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/d5cbedfd/attachment.html


Questions about the relationship between Instruction, workflow and Action

2011-12-07 Thread Sam Heard
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

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 7 December 2011 9:19 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

Nobody? :'(

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

  _  

From: pazospa...@hotmail.com
To: openehr-clinical at openehr.org; openehr-technical at openehr.org
Subject: Questions about the relationship between Instruction, workflow and
Action
Date: Sun, 4 Dec 2011 15:36:36 -0300

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 :D

 

 

 

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!


-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos


___ openEHR-technical mailing
list openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111207/48c14f98/attachment.html


Questions about the relationship between Instruction, workflow and Action

2011-12-04 Thread pablo pazos

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 :D


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!
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111204/c51453b5/attachment.html