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>
