# Revision of Instructions - clinical implications **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2011-12-10 15:44 UTC **Views:** 5 **Replies:** 56 **URL:** https://discourse.openehr.org/t/revision-of-instructions-clinical-implications/15116 --- ## Post #1 by @ian.mcnicoll There is a discussion on the technical lists about handling INSTRUCTIONS and subsequent ACTIONS in openEHR\. Heather Leslie has provided an excellent explanation of the process but there is one comment that I feel merits some further clinical discussion\. "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\." I have a current use case for modelling Medication orders, and the situation where the original order is altered slightly e\.g a minor change of dosage or timing, where the clinicians have expressed a requirement to have this 'seen' as a modification of the original order, rather than a completely new order\. This would seem to accord exactly with Heather's suggestion above i\.e\. simply modify the original order in the original committed composition, updating the version\. I am not totally comfortable with this approach, since it feels to me as if we are asserting that the original order was incorrect\. This would obviously be ok if we were indeed correcting an order which had never been actioned but for a valid, actioned order, this does not feel correct, since it essentially hides the original order, albeit that the original instruction is still available for medico\-legal purposes via the original committed version\. I think would prefer to create a new order but link it to the original to ensure that the clinical requirement to maintain a chain of events is ensured" Any thoughts? Ian Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www\.phcsg\.org --- ## Post #2 by @Dr.S.Jagannathan > Isn't 'Instruction' itself an action?

Jag

Dr. S Jagannathan
198 St Johns Road
Edinburgh
EH12 8SQ

--- On __Sat, 10/12/11, Ian McNicoll **__ wrote:

> From: Ian McNicoll
> Subject: Revision of Instructions - clinical implications
> To: "openEHR clinical discussions"
> Date: Saturday, 10 December, 2011, 15:44
>
> There is a discussion on the technical lists about handling
> INSTRUCTIONS and subsequent ACTIONS in openEHR. Heather Leslie has
> provided an excellent explanation of the process but there is one
> comment that I feel merits some further clinical discussion.
>
> "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."
>
> I have a current use case for modelling Medication orders, and the
> situation where the original order is altered slightly e.g a minor
> change of dosage or timing, where the clinicians have expressed a
> requirement to have this 'seen' as a modification of the original
> order, rather than a completely new order.
>
> This would seem to accord exactly with Heather's suggestion above i.e.
> simply modify the original order in the original committed
> composition, updating the version.
>
> I am not totally comfortable with this approach, since it feels to me
> as if we are asserting that the original order was incorrect. This
> would obviously be ok if we were indeed correcting an order which had
> never been actioned but for a valid, actioned order, this does not
> feel correct, since it essentially hides the original order, albeit
> that the original instruction is still available for medico-legal
> purposes via the original committed version.
>
> I think would prefer to create a new order but link it to the
> original to ensure that the clinical requirement to maintain a chain
> of events is ensured"
>
> Any thoughts?
>
> Ian
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll@oceaninformatics.com
>
> Clinical Modelling Consultant, Ocean Informatics, UK
> Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care www.phcsg.org
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@openehr.org
> [http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical)

| --- ## Post #3 by @Eunice_Ab Hello I think I have asked this question before. I always wondered why 'instructions' were separated from 'actions' as I thought an 'instruction' was an 'action' too. I really look forward to the answer to the question. Many thanks. Eunice Eunice Bamgboye --- ## Post #4 by @thomas.beale well version updates to persistent Compositions like medications list are not regarded as 'corrections', just updates to bring it up to date\. 'Correction' is just one possible reason for a new version of something\. \- thomas --- ## Post #5 by @thomas.beale Instruction defines what Activities should be performed\. Actions record the execution of those activities, which might not be exactly the same as what was ordained\. So Instruction = intended; Action = actual\. \- thomas --- ## Post #6 by @Seref would it be wrong to say instruction = request; action = response ? --- ## Post #7 by @thomas.beale Further: an Instruction might not get performed at all\. But you want a record of it anyway\. \- thomas --- ## Post #8 by @Dr.S.Jagannathan > When you instruct someone do to something then it is an action.

Jag

--- On __Sat, 10/12/11, Thomas Beale **__ wrote:

> From: Thomas Beale
> Subject: Re: Revision of Instructions - clinical implications
> To: openehr-clinical@openehr.org
> Date: Saturday, 10 December, 2011, 16:49
>
> Instruction defines what Activities should be performed. Actions record
> the execution of those activities, which might not be exactly the same
> as what was ordained. So Instruction = intended; Action = actual.
>
> - thomas
>
> On 10/12/2011 16:00, S JAGANNATHAN wrote:
> > Isn't 'Instruction' itself an action?
> >
> > Jag
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@openehr.org
> [http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical)

| --- ## Post #9 by @Eunice_Ab Hi Thomas and Seref Many thanks for your response ... this was what I thought too .... but then does that not mean that all that is needed to be able to capture both under actions is an attribute of 'type' for 'intended' and 'actual' OR 'request' and 'response' rather than separating them to remove the confusion of thinking both are not actions. Thanks. Eunice Eunice Bamgboye --- ## Post #10 by @thomas.beale no, because the information structure of an Instruction is in future time, so specifying it requires structures / data items that correspond to that. The model we use in openEHR is by no means the best, but it illustrates: in future time you specify what might possibly happen, including with conditional branches, as workflow engines do. Actions are in past time, and are therefore simpler to represent. On the other hand, Actions being performed usually represent transitions in a state machine. See the openEHR models of these two Entry types [here](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html). - thomas --- ## Post #11 by @thomas.beale In a trivial sense that is of course true. But the interesting part of an Instruction is *what* is being instructed, which is where the potential complexity lies. - thomas --- ## Post #12 by @Dr.S.Jagannathan > Following a clinical examination/consultation a clinician may instruct, advise, prescribe, recommend etc. These are all actions which may be taken by the clinician.
Intended, proposed, actual, done, not done, are all attributes of an action.

Jag

--- On __Sat, 10/12/11, Eunice Ab **__ wrote:

> From: Eunice Ab
> Subject: Re: Revision of Instructions - clinical implications
> To: "For openEHR clinical discussions"
> Date: Saturday, 10 December, 2011, 17:04
>
> Hi Thomas and Seref
>
> Many thanks for your response ... this was what I thought too .... but then does that not mean that all that is needed to be able to capture both under actions is an attribute of 'type' for 'intended' and 'actual' OR 'request' and 'response' rather than separating them to remove the confusion of thinking both are not actions.
>
> Thanks.
>
> Eunice
>
> Eunice Bamgboye
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@openehr.org
> [http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical)

| --- ## Post #13 by @thomas.beale Well in an HL7 modelling view of the world this would be true\. But ontologically it is not, if 'action' means something that was done, which is what it means in openEHR\. All Actions in openEHR are 'actual'\. An Action may be used to record some clinical thing being 'not done' as well, since that is also an Action \(essentially a decision by the clinician\)\. But Actions in openEHR can't have the classifiers 'intended', 'proposed' or similar things\. This is what Instruction is for\. The data structures to represent future events and past events are different\. Simply using a classifier on a generic 'Act' model doesn't work\. \- thomas > Following a clinical examination/consultation a clinician may instruct, advise, prescribe, recommend etc\. These are all actions which may be taken by the clinician\. > Intended, proposed, actual, done, not done, are all attributes of an action\. --- ## Post #14 by @Dr.S.Jagannathan > If that is the case. then there really is no need for Instruction separately as such.
The 'what' can be specified and the context may be obtained by applying attributes such as for a procedure- proposed, done, not done, postponed, recommended, instructed(as well!) etc. and for drugs-prescribed, taken, dispensed etc.

Jag

--- On __Sat, 10/12/11, Thomas Beale **__ wrote:

> From: Thomas Beale
> Subject: Re: Revision of Instructions - clinical implications
> To: openehr-clinical@openehr.org
> Date: Saturday, 10 December, 2011, 17:15
>
> In a trivial sense that is of course true. But the interesting part of an Instruction is *what* is being instructed, which is where the potential complexity lies.
>
> - thomas
>
> On 10/12/2011 17:02, S JAGANNATHAN wrote:
> > When you instruct someone do to something then it is an action.
> >
> >
> > Jag
> >
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@openehr.org
> [http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical)

| --- ## Post #15 by @Seref [http://en.wikipedia.org/wiki/God_object](http://en.wikipedia.org/wiki/God_object) --- ## Post #16 by @Eunice_Ab Hi I thought the data structures were to support the clinicians workflow view. I just wondered why you mentioned the 'Act' model would not work. As Jag explained all the things he listed including instructions are all actions ..... and why do we have to restrict the definition of 'an action' to what is done rather what it is actually... Even the models in SNOMED CT supports these as all being its term for actions .... 'procedures'. I totally agree with Jag's suggestions for having attributes to mark these as not done, done etc. Thanks. Eunice Eunice Bamgboye --- ## Post #17 by @thomas.beale Marking Actions as something 'done', 'not done', etc is normal of course\. In openEHR, such actions can be matched up with states in the abstract state machine, so that you can query afterward on what is active, suspended, completed etc\. But things like 'intended' are not meaningful possibilities for acts already performed\. You may not like the name 'Instruction' in openEHR \(we had to pick something\), but it distinguishes between what has not yet been done and what has already been done \- i\.e\. between future time and past time\. That's a key distinction\. Most workflow engines work this way, because the structure of something in the future can contain possible paths, whereas what was already done doesn't, it is just a series of events that actually occurred \- there is no branching or conditionality\. \- thomas --- ## Post #18 by @pablo Those are not the semantics used in openEHR: [http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf) In the openEHR RM the ACTION is the record of something done: a procedure, a study, etc. An INSTRUCTION is the record of the order of that procedure or study. --- ## Post #19 by @Dr.S.Jagannathan Not an expert on' openEHR semantics' But in simple terms it is still a matter of something + an attribute( in this case the tense) ie Procedure+ordered/instructed + done, + not done + proposed + postponed + suggested etc I wasn't trying to change any open ehr rules, but was just looking at it from a straightforward, logical and simplistic view to try and avoid ambiguity, confusion and duplication. Cheers Jag Dr. S Jagannathan --- ## Post #20 by @pablo But we are talking about the openEHR model, so we should consider the semantics of the terms we use based on those semantics instead of redefine them on every discussion. That's what a standard is for: defining a common language so we have no misunderstandings for differences on interpretation (= avoid ambigüity). The states you mention are modeled by the openEHR model already. There are 3 different concepts: the initial instruction, the actions made for that instruction, and the current execution state for that instruction, determined by the actions taken. The record of those 3 different elements should be done separately, because you want to have the execution history of the instruction, not only the current state. The execution history is recorded in the actions taken. This is needed for audit trail, for medico-legal reasons, and to detect problems on the care process. I think storing all the information in one class doesn't solve the problem and leaves out the historical information. --- ## Post #21 by @Dr.S.Jagannathan

I have to humbly disagree that there will be any loss of historical information. As I said before I have no intention of trying to change anything about open ehr and would personally wish to discontinue my part in this discussion. Regards Jag Dr. S Jagannathan --- ## Post #22 by @Dr_Carola_Hullin_Luc An instruction is the conceptual documentation of the inference. The aciton is the physical delivery of the instruction. I am really surprise of the confusion, I tend to believe that non clinician get truly confuse about this. When you create, design and develop health program, it is very clear instructions as conceptual notes and then actions as the person who deliver that instruction as described. Cheers Carol __**Dra. Hullin Lucay Cossio**__ __**(RN,BN,Hons,PhD,Post Doc)**__ __**IMIA LAC President**__ __**www.imia-lac.net**__ [](http://www.infolac2011.org/) --- ## Post #23 by @Colin_Sutton An instruction is an imperative e\.g\. "Take two tablets daily", the action is "Took the tablets" or "Forgot the tablets" or "Ignored the instruction"\. The instruction stays the same, or is superseded \(figuratively 'replaced'\) by another instruction\. Colin --- ## Post #24 by @Heath_Frankel3 Actually Jag, is not far from the truth. 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 --- ## Post #25 by @Dr.S.Jagannathan Agreed,that is exactly how I understood it\. So strictly speaking the instruction is an action preceding another action\!\! --- ## Post #26 by @Colin_Sutton Look at the tense of the verb: active is not the same as imperative\. Giving an instruction \(instructing\) would be an action in everyday parlance but the instruction is not an action\. The instruction has a workflow: the steps in the workflow are ACTIONs in the OpenEHR terminology\. Colin --- ## Post #27 by @rjsearle Sounds like: action = instruct result = new instruction (eg take your tablets) subsequently: action = follow instruction (take tablets) result = tablets taken So if I understand this correctly, the instruction is NOT the act of instructing, rather the product of the act. Regards Russell --- ## Post #28 by @system Dear Jagannathan, I see the big confusion developing. There is HL7 thinking and 13606 thinking. (and *open*EHR thinking) In HL7 'the act' of documentation is modeled as an Act with a specific mood code. In 13606 'the act' of documentation is about either an Observation archetype, an Evaluation archetype, an Instruction archetype , an Action archetypeor any other constructs we might need (e.g. Administrative, etc). In HL7 there were (are?) too loose definition so one time (2006) the question: Is a Patient Record an Entity or an Act? created a huge debate and confusion. In 13606-circles these specialised Entry-Classes are defined in an other way than in *open*EHR. In *open*EHR their Reference Mode constrains 'hardcoded' the specialised classes; Observation, Evaluation, Instruction and Action. In 13606-circles we feel that our Reference Model should stay as generic as possible. The Entry Class is sufficient. We deal with these specialisations of the Entry Class using semantic patterns that constrain the Entry Class and depending classes via archetyping to reflect the specialisation In order to understand the picture it is essential to observe that when we document we can perceive states, using our senses or machines, phenomena at points in time. Phenomena that are the result of ongoing processes inside the patient system, documented using the **Observation archetype**. All the observed phenomena (observed states) give rise to inferences about the process and that are documented using the **Evaluation archetype**. We can not observe processes inside the patient system. The inferences together with the existing knowledge and experience gives rise to instructions/orders to do something to influence the processes inside the patient system or collect more Observations on states. These are documented using the **Instruction archetype.** As acts of God or as the result of Instructions deeds are done that either influence the observable states or influence the processes in the patient system, using the **Action archetype**. In between instructions and actions there can be protocols or clinical pathways or workflow machines, or case management tools. Each of the four defined archetypes (for the Observation, Evaluation, Instruction or Action) carry their own state model. Some are more complex than others. (e.g. the state model or the Observation can be simple. That of the Action is more complex. These state models can influence each other sometimes. E.g. when all instructions have been performed by means of the execution of actions (and updating the state model of the actions) the state model of the corresponding instruction needs to be updated to reflect this.) A strict adherence to these definitions leads to the consequence that what is modeled in *open*EHR as one Observation, in EN13606-circles will be modeled as an Action archetype (documenting the execution of an observation/measurement such as Blood Pressure Measurement) and a 'coupled' Observation archetype where the result of the measurement is documented. The Action archetype will document the method/protocol, etc. used in that Action archetype to measure something. Each Entry Class archetype defines one Clinical Statement/Detailed Clinical Model (DCM)/ Clinical Information Model (CIM), using constraints. Each Entry archetype defines only one topic, one measurement, one diagnosis, and all its semantic context as one semantic atomic construct. This means that something like the Blood Pressure measurement actually is a Panel, an ad-hoc assembly of two or more semantic atomic clinical statements (archetypes Entry Class). This means that in EN13606 thinking the Blood Pressure Measurement is defined by constraining the Section Class to 'hold' at least two Entry classes. One for the systolic and one for the Diastolic Action/Observation. In this way all Panels will be modeled as sections in EN13606. Each update in any state model, each update of data or information documented, and as specified using an archetype, will have to result in a new version and properly documented to make the complete audit trail possible. The thinking as developed in EN13606-circles will be provided to CEN/ISO (and CIMI) as input for standardisation. For more info have a look at [http://www.En13606.org](http://www.En13606.org) and at the EN13606 WIKI at that site. For the figure about the Patient system and the Entry classes see:[http://en13606.webs.upv.es/wiki/index.php?title=File:GF_Archetype_and_Patient_System.png](http://en13606.webs.upv.es/wiki/index.php?title=File:GF_Archetype_and_Patient_System.png) >

|

**Definition**

| > - | - | >
**Patient System**
|
The ensemble of the constituting processes and parts of the body, the body as a whole and its social and other environment of a person that is the recipient of healthcare delivery.
| >
**Entry Class**
|
A Class in the EN13606 EHR-com model that can be constrained to generate clinical relevant statements about an entity for documentation.
| >
**Observation**
|
An Entry Class archetype that defines by constraining the Entry Class of EN13606-1
what can be documented about a specific observed state of a process in the Patient System at a point in time using the faculties of seeing, hearing, tasting, touching, smelling, or directly via a medical device or service.
| >
**Evaluation**
|
An Entry Class archetype that defines by constraining the Entry Class of EN13606-1
what can be documented about an inferred process in the patient system using observations, expertise and knowledge,
or about plans with,
or risk assessments about, the Patient system.
| >
**Instruction**
|
An Entry Class archetype that defines by constraining the Entry Class of EN13606-1
what can be documented about the intended actions with the aim to change the state or process in the Patient System.
| >
**Action**
|
An Entry Class archetype that defines by constraining the Entry Class of EN13606-1
what can be documented about events that changed (or could change) states or processes in the Patient System.
| Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Gerard Freriks **EN13606 Association** p/a Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands M: +31 620347088 E: [g](mailto:gfrer@luna.nl)[erard.freriks@EN13606.org](mailto:erard.freriks@EN13606.org) **W: http:www.en13606.org** --- ## Post #29 by @system Hi, Think it's easy to distinguish one from another if you think on a paper record. Instructions and actions are separated there. Instructions are the orders ( instructions) recorded when finishing patient 's evaluation and actions are recorded when they were either performed, or suspended, or postponed, or even not done. I.e actions follow instructions in the workflow. Jussara --- ## Post #30 by @ian.mcnicoll Interesting discussion but so far no-one has addressed my original question, other than Thomas, and I do not think we can assume that a Medication list is necessarily modelled as a persistent composition. Even then I suspect the same issue still arises. We do not want to hide the previous valid Instruction from normal querying/visibility, just assert that the revised order is regarded as part of a single clinical continuum So I will ask again... If I revise a medication order in a fairly minimal way e.g. Dosage change from 200mg daily to 250mg daily, should it be acceptable to revise the original Instruction, or should we create a new Instruction? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll [ian.mcnicoll@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) --- ## Post #31 by @heather.leslie In your specific scenario I agree that it's a new order - stop the original order and commence a new one with the appropriate dosage or frequency. Heather --- ## Post #32 by @system Ian, Medication list in my book is a kind of Folder or Section that assembles data and information already stored in the Patient Record. The data is stored in (formally committed to) the database. Any change after the data is committed needs to be recorded fully in the audit trail. Time, committer, etc needs to be recorded. Only in this way the record is a faithful record. As much s possible we need to create and maintain the train of events. Minimally because the data of the commit is secured. Maximally because via versioning and/or semantic links cause effect relations are recorded. Werner Ceusters calls this 'Referent Tracking'. > Each update in any state model, each update of data or information documented, and as specified using an archetype, will have to result in a new version and properly documented to make the complete audit trail possible. My position is and was clear. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #33 by @thomas.beale spot on ;\-\) \- thomas --- ## Post #34 by @thomas.beale I hate to say it, but this is the kind of mess we get into with HL7 mood code thinking\. Yes, it's true, everything is an act, in a trivial sense\. But that idea doesn't help define EHR information structures, and tends to confuse things because everyone keeps thinking they have to make everything into an Act of some kind when building models of content\. But we can do things much more simply\. If an Instruction \(entry\) is committed to the EHR by a clinician, obviously an 'act of instructing' \(usually an order of some kind\) has occurred \- by definition, that is what the Instruction entry is there to document\. So we don't need to get tied in knots about whether we have specifically recorded the 'act of instructing' separately from what the instruction says; the recorded Instruction entry automatically indicates the former, and specifically documents the latter, which is what clinicians need to work with\. I know people in HL7 will disagree, but this is the route we have taken in openEHR, and it works nicely\. \- thomas --- ## Post #35 by @thomas.beale I think we can produce the correct answer when you (clinical professionals ;-) decide whether you mean: - the medication order (prescription) was formally revoked and replaced by a new one, OR - the medication order remained, but at some point before or at administration the clinician (or some other person) changed the actual dosage so you need to decide whether 'revise' is some kind of formal act or replacing an existing prescription, or some kind of informal act that often occurs in real life, or something else. - thomas --- ## Post #36 by @thomas.beale IN that case, what you would have chronologically in openEHR is: - INSTRUCTION (#1234): paracetomol 200mg 1td po (etc) - ACTION: 3 July 2011 15:04 - **cancel** Instruction #1234 - INSTRUCTION (#5678): paracetomol **300mg** 1td po (etc) - ACTION: 4 July 2011 09:10 - dispense - ACTION: 4 July 2011 10:30 - administer - ACTION: 5 July 2011 10:30 - administer - etc As Heather and others doing Action archetypes do, the exact set of possible actions an be named any way needed, and each action type can be associated with abstract states in the [standard state machine](http://www.openehr.org/325-OE/version/default/part/ImageData/data/openehr_state_machine.png). - thomas --- ## Post #37 by @system RA medication revision shall be a new entry always, even if it´s only to change the dosage...because you have to enter a new information at a different point of time. We have to differentiate acts from actions, although for both of them there´s a doing in the sense of the word, therefore they are used often interchangeably, but actually don´t represent the same concept. Actions involve physical changes and are used in activity phrases, while act generally means something that was already accomplished. So we can´t compare act in the RIM with action in OpenEHR, they´re semantically different. --- ## Post #38 by @rjsearle Hi Thomas, As I was typing my previous email, I wished I 'said out-loud' what was going through my mind, that it was going down the HL7 fork in the road.. I offered it to clarify prior conversations that seemed to be becoming circular, rather than propose a HL7 model. I understand that if there is an instruction on the EHR, it was clearly created. Therefore the action that created the instruction is implied by its very existence. I'm not an openEHR practitioner, but I expect there is sufficient context data recorded with the instruction to answer the who/where/why kind of questions. Although I am a little curious why the action of cancelling an instruction is explicitly modelled when replacing the instruction. On one hand an action on the instruction is implicit and on another the action is explicit. My first thought was to expect a second instruction that referred to the cancelled instruction, thereby cancelling it. ie the first instruction would refer to its cancelling instruction. Perhaps I'm being a little too 'relational' here and breaking a 'thou shalt not modify' rule. Is this situation based on a state model design pattern whereby the creation action is implicit by existence but all subsequent changes of state are explicit? Thanks Russell --- ## Post #39 by @thomas.beale no, I think you are being entirely reasonable\. If the Instruction were not just cancelled, but let's say adjusted, then we could expect INSTRUCTION \#1 ACTION \#1 ==> INSTRUCTION \#1 state = cancelled INSTRUCTION \#2 // like \#1 with different dose Alternaitvely, if there were actually an error in INSTRUCTION \#1, then we should see INSTRUCTION \#1 \(ver 1\) INSTRUCTION \#1 \(ver 2\) \-\-> correct dose i\.e\. 2 versions\. \(DON't forget in openEHR, everything is versioned all the time, so in the first list above, each of those things is really 'ver 1' of something\)\. So there is certainly an element of 'what is the openEHR interpretation' of a given set of object structures, or to look at it in reverse, for any given real world situation, what is the correct pattern of object structures\. Some of these situations could arguably be represented in more than one way, so we need \(as a community\) to establish the right way\. \- thomas --- ## Post #40 by @system Hi Ian I have not read all the replies but there is an essential distinction in openEHR that covers this important point \- the difference between EVENT and PERSISTENT compositions\. The later is provided for information that will be repeatedly updated and not invalidated by a new version \(ie the previous version provided a complete and correct set of information and the new version is an alteration that is also complete and correct\.\) So, if a medication list \(as a persistent composition\) is updated then there is no doubt about the link \- assuming that there is a link between the two medications \(a workflow ID \- or just that it is the same drug\)\. If I prescribe something as a one off \- I might correct it in the same event, but if I update the dose in a new event, then this would not be a correction \- the previous instruction would have to be ceased and the new one started in the new event \- with a link as you have said\. I will make a new post on these compositions types\. Cheers, Sam --- ## Post #41 by @system We have to be careful to develop the nomenclature that meets our needs. An instruction can lead to actions and other things. So an instruction to do a Diabetic review may lead to a number of observations and even evaluations – but it will be the Action saying that this thing (the diabetic review) has been done that will relate to the instruction directly (workflow may link the other observations as well). Referral is a good example of a work flow that does not really relate to the ‘actions’ one might expect. So a lab order will stay active while the sample is taken, analysed, reported, communicated, reviewed and actioned. The ‘action’ in the usual sense is the laboratory report which is a separate document. It will take some time before these workflows are commonly dealt with as a transparent process. Cheers, Sam --- ## Post #42 by @system Hi Jag Again, the nomenclature is important – as is the separation to some extent of clinical and technical. The information construct that arose from clinical requirements is that we need a way to say that something has to be done. This should have, in the future, a machine readable statement as to when. From this point of view, anything that is to be carried out in the future is an instruction. This could be to advise, prescribe, recommend etc. Prescibe is an excellent word to consider – is this the ‘order in the medication list’ or is it the actual order that is communicated to the pharmacy. In openEHR archetypes at the moment it is the later. It is a copy of the standing order (INSTRUCTION) that is transmitted to the pharmacy and an ACTION of prescribe is recorded in the record. This is not a trivial distinction. Hope that helps, Sam --- ## Post #43 by @system Jag, This assumes that the information about the thing that is proposed is the same as the thing that is done. That was our starting point and we did reuse structures in models for a time. Then we started to see that there are quite a few differences. What would you call a standing order for a PAP test every two years when the woman has already had two? What is the re-issuing of a prescription? Also, do you have write access to the information that you are acting on? I think you will see that your proposal falls on difficulties quite quickly in a distributed eHealth environment. Cheers, Sam --- ## Post #44 by @system Ian, This is indeed a very interesting question. I am inclined to think revision based approach seems to be more intuitive here if the update is not due to an obvious dosing error. Cheers, Rong --- ## Post #45 by @yampeku If revision means changing and losing the original data \(the 200 value is lost forever\) then I think we shouldn't do that\. As a bad prescribed medication can harm the patient I think we need always to be able to track the source of the problem\. If revision is supposed to store original and revised one then no problem with that --- ## Post #46 by @thomas.beale well that happens anyway, all openEHR data are versioned, there are no overwrites, ever\.\.\. \- thomas --- ## Post #47 by @yampeku then if this already happens, I don't understand Ian's question --- ## Post #48 by @system As Thomas said, the versioning of Instructions happens anyways, on the technical implementation level\. So I guess what Ian is after is more on the clinical level \- which way is more intuitive to the clinicians\. I know cases where the dose changes are anticipated, e\.g\. based on lab tests, temperature etc depending on how the patient responses to the treatment\. In these cases, it seems natural to keep the original workflow and just update the medication dose\. Cheers, Rong --- ## Post #49 by @system Hi Ian There is no logical difference no matter what the change. What you want to do is link an update with the previous instruction. I would suggest that this will be done by workflow or by links. Cheers, Sam --- ## Post #50 by @ian.mcnicoll Hi Diego, The issue is that that the 'current version' of the EHR should reflect what is currently believed to be true and 'safe' about the patient's record without having to trawl through previous versions\. So If I query for all medication orders, I should get back the original order, as well as the revised order, since both were accurate and 'true'\. If the revised order is recorded by amending the original order entry, rather than by creating a new 'linked' order, a query will only get back the revision, unless I specifically request older versions to be included\. If I do the latter, I will also retrieve incorrect or erroneous orders which have been correctly amended or deleted\. Ian Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www\.phcsg\.org --- ## Post #51 by @system Hi Ian Well, the workflow link may do this but the link from an action to an instruction is actually to the version \(EHR\_URI\) \- as this is the sensible option\. Cheers, Sam --- ## Post #52 by @system The precise 'choreography' of these things like versions, updates, error corrections, etc. can not be solved in a standard. The standard must be so flexible that it can document whatever choices are made by the implementation. Then it is a deployment issue for implementers to solve. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #53 by @ian.mcnicoll Hi Sam, This is really a link between INSTRUCTIONS, asserting some sort of clinical continuity, almost at a visual level i\.e show me these orders as a single entity, rather than as 2 separate lines\. I am not sure it is usefully computable beyond that\. Was 'Superceded' ever considered as one of the Action states, though I am not sure this would be the right way to go\. I have also had an interesting conversation off\-list about the situation where a pharmacist corrects or amends the original order, in a hospital setting i\.e\. the order itself, not the dispense or administration\. Ian Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www\.phcsg\.org --- ## Post #54 by @ian.mcnicoll Hi Gerard, I agree, but openEHR is not just about standards, it is about implementation and we need to be able to think through the implications of particular approaches, where different options are available\. The issues being discussed are directly related to the openEHR specifications and not particular to the Ocean engine\. For those of us who are implementers it helps to establish some ground\-rules/ shared experience about how to achieve this in practice\. In a sense, we are also possibly slowly developing some standard 'norms' and good practice of clinical system behaviour, so that cross\-system querying becomes a reality\. It also opens up a wider discussion about a tricky clinical informatics issue, which is common to all applications, dealing with medications orders\. One of the attractions of openEHR is that it perhaps lets us establish some best practice in this area, independent of any specific applicaiton\. Ian Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www\.phcsg\.org --- ## Post #55 by @Dr.S.Jagannathan

Sam Perhaps this explanation is too simplistic and naive! The 'thing' remains the same ie PAP smear, there is no assumption about the 'thing'. Only the qualification of it is whether the 'thing' was done or whether it is proposed to be done. Other qualifications can be applied to the same 'thing' such as not done, postponed, cancelled etc. The thing is a PAP smear: Thing: PAP smear Attribute: Done: Time related Info, Time point Date and time: 1 Date and time 2 Thing: PAP smear. Attribute: Scheduled Time related info: frequency Two yearly 0r Time related info: Date and time A reissue of a prescription (thing) is still a prescription with a different date ie date of issue or a future date. Reissue and repeat prescriptions are just descriptions of a prescription. Regards Jag Dr. S Jagannathan --- ## Post #56 by @ian.mcnicoll Hi Jag, It is a little simplistic, since it is quite common for the recording requirements of the activity to differ significantly from that of the original order. e.g. The performer may need to record variance from the original order (drug given at a different dose/time), complications, related findings, device/materials used (which may not be specified in the original instruction). In the example of medication there are a whole host of other things that need to be recorded around meds administration (batch number, expiry date, site) that are not specified in the original order, and similarly for dispensing. Of course, there is considerable overlap (which we capture by using shareable cluster archetypes) but ultimately the recording requirements of an instruction may differ markedly from that of an Action. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll [ian.mcnicoll@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) --- ## Post #57 by @Dr.S.Jagannathan

Thanks for the reply Ian. I based the explanation on the sample that Sam posed. It is still possible to record all the other information that you have mentioned in a similar manner. The contents (things) in your original order do not change, Only additional information on the contents and perhaps some additional contents may be required. I don't want to divert your attention from the hard work being done by you all. May be we'll call an end to this discussion as this can go on till the cows come home. Regards Jag Dr. S Jagannathan 198 St Johns Road Edinburgh EH12 8SQ --- **Canonical:** https://discourse.openehr.org/t/revision-of-instructions-clinical-implications/15116 **Original content:** https://discourse.openehr.org/t/revision-of-instructions-clinical-implications/15116