Regards
Jag
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.
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
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
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
Agreed,that is exactly how I understood it. So strictly speaking the instruction is an action preceding another action!!
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
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
Dear Jagannathan,
I see the big confusion developing.
There is HL7 thinking and 13606 thinking. (and openEHR 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 openEHR.
In openEHR 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 openEHR 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 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
|
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
Gerard Freriks
EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
M: +31 620347088
E: gerard.freriks@EN13606.org
W: http:www.en13606.org
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
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
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
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
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
spot on 
- thomas
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
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
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.
- thomas
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.
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
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
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