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.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 +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://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120801/9a1b5ae5/attachment-0001.html>
