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: [email protected] [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: [email protected] 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>
