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 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-boun...@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/ppazos _____ From: sam.he...@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 +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 -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 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120809/8ba8f4e9/attachment-0001.html>
