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....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 -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazosFrom: sam.heard at oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Questions about the relationship between Instruction, workflow and Action Date: Wed, 7 Dec 2011 13:09:31 +0930Hi 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 -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 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_______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120803/7833cdc9/attachment-0001.html>
