Perhaps I responded to the wrong thread, I will repost what I said in response to "Revision of Instructions - clinical implications".
When you order a lab test you actually need an Instruction to define the lab test, and an action to put It into the ordered state. The request time of the lab test order is the time in the action with the ordered state. An instruction without an action is not yet executing within a workflow. BTW, the workflow definition attribute is not intended to carry archetyped data. It is intended to specify the definition of a workflow executing within a workflow engine or similar. The workflow ID references the instance of the workflow executing for this instruction. We also use this for real world non-computerised workflows, such as a lab order number to allow us to keep track all the entries that relate to the same lab request including observations and evaluation. Heath From: Heather Leslie [mailto:heather.les...@oceaninformatics.com] Sent: Monday, 12 December 2011 1:30 PM To: 'For openEHR technical discussions' Cc: heath.frankel at oceaninformatics.com Subject: RE: Questions about the relationship between Instruction, workflow and Action From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Sunday, 11 December 2011 8:39 AM To: openehr technical Subject: RE: Questions about the relationship between Instruction, workflow and Action Hi Heather, I asked Heather on that issue ( <http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-ar chetype/> http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-arc hetype/) 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. I understood that part and agree 100%: We have the record of the original Instruction untouched, or if it need a change from a clinical point of view, this will be a new version/revision of the previous Instruction. 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. That's the problematic point I see on the use of an ACTION to record something that is merely administrative and may have no clinical relevancy. [HL>] From my point of view, it may be an administrative detail, but just the fact that something has been scheduled (without necessarily details of the time/date/location) is a valuable part of a clinical record. It does have clinical relevance as it records what has been done in the steps required to carry out at order/INSTRUCTION. While a non-clinical person may have technically carried out the ACTION, it is still critical info in the clinical record, still a 'clinical action' IMO. An ACTION should be ... "Used to record a clinical action that has been performed, which may have been ad hoc, or due to the execution of an Activity in an Instruction workflow. Every Action corresponds to a careflow step of some kind or another." (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73). I think we could analize this topic through an implementation (I think that's what you and Sam have mentioned) with the solution of having messages triggering ACTION creation or recording data on existing ACTIONs. [HL>] It is not at all simple to envisage how the flow of INSTRUCTION and various resulting ACTIONS play out, and I can't pretend to have it all 100% clear, but with implementations (and Heath Frankel certainly has plenty of recent experience) it is proving to work in practice. But I think we need to revise the openEHR specs, to see if this topic is clear enough, because I don't see a clear solution in the standard itself (maybe others could have better luck than mine). Or maybe this is one of those things that are not defined by the standard, like EHR security or RM persistence, and each implementation could create it's own solution. If that's the case, I think "Instruction management" is an important issue on EHR development and it should be considered on the specs. And my small contribution on this is that maybe ADMIN ENTRIES could also trigger/record Instruction state changes (without changing the instruction itself). 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? Thanks a lot! regards, Pablo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111212/b05f7077/attachment.html>
