Maybe I sent it to the wrong place originally.
Any ideas?
thank you
good question!!!
(though, seems an implementer-question to me)
I hope you get a good answer, interesting for me, also
regards
Bert
Rodrigo Filgueira schreef:
Bert Verhees wrote:
good question!!!
(though, seems an implementer-question to me)I hope you get a good answer, interesting for me, also
some answers inline below..
I'm trying to see how medication administration control or reporting should be modeled based on the OEHR RM and Archetypes.
Let's take an example of say a intravenous medication to be administered for 8 hours. I have an GUI where nurses register the following information:
- amount of medication administered since the last control.
These are Actions (see EHR IM - http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/ehr_im.pdf, ACTION type).
- problems which lead to cancellation of the medication plus the amount of medication administered so far.
this is most likely an ACTION for suspending or aborting the medication, with accompanying reason (e.g. low white cell count). These kinds of actions (abort, cancel, suspend, resume) are all archetypable in such a way that clinical pathway actions can be mapped
The archetypes for this kind of thing are built around INSTRUCTION, ACTIVITY (part of instruction), and ACTION. See e.g. the archetype for medication order at http://oceaninformatics.biz/archetypes/openEHR-EHR-INSTRUCTION.medication.v1.html; there is a link to the Action archetype. Currently this link seems to be broken, so the correct link is http://oceaninformatics.biz/archetypes/openEHR-EHR-ACTION.medication.v1.html . It takes a bit of time to understand how this modelling works, and you need to read the Instruction section in the EHR IM to see the design approach.
- thomas
Dear All
I will take this slowly. The implementation and modelling processes are different.
Modelling:First, each action is a recording which leaves some ‘instruction’ (which may or may not be recorded) in some state (active, completed, cancelled etc). An Instruction is a recording that calls for some action to take place, and may or may not lead to a recording of this action in the EHR. It can be set to time_out. Otherwise the current state is set by the action record that is generated when someone does what is instructed. As the machine states in which the ‘action leaves the instruction’ are recorded as part of the action, the archetype of the care pathway steps are in the action archetype. This was not immediately obvious to me - but as soon as you consider that an action can be recorded without an instruction, it is clear that this is where it must be. Also, the instruction is not altered as the actions are being carried out - a distinct advantage which will become clear with more implementation experience.
Summary: Actions are things done to patients in response to instructions - in health care these are requests or orders by a provider (generally). Instructions beget actions, and are left in a known state after these actions.
Implementation:It seems possible to predetermine all aspects of an action record in the instruction record that generates the action. For example we could say, “Give the baby her MMR vaccination” or we could say “Give the baby her MMR vaccination using a 25G needle in the right thigh laterally at 08:00 on 21/6/06 using batch no: AE43445”. It is unlikely but possible.
What becomes clear from this is the specification for what could be recorded is pretty much in line with the specification for what could be instructed - the categorical difference is that an instruction will have timing ( times a day after meals), whereas an action will have a time (08:00 on 26/6/06).
This is the reason that the archetypes for instructions and actions are sharing a data structure - it is an embedded archetype and the first time we have used this, although the openEHR model has been geared for this from very early days.
Thomas Beale wrote:
My answer would be the following.
I write it down to make clear I understood the reaction by Sam.
-1- An EHR is there to document what has happened
-2- An EHR doesn’t contain workflow states. That is handled outside the EHR. It is in the EHR-system
-3- There will be archetypes that help document a Plan, an Instruction, an Observation.
E.g. to Plan for treatment, resulting in an Instruction to give medicines via injection , and the Observation that at the medication/injection has been administered at a specific point in time by a specific healthcare provider.
-4- Each archetype mentioned is almost the same has almost the same structure and will share common internal archetypes. There will be small subtle differences between these archetypes. Plans and Instruction can (but must not be always) less specific than the Observation when something has happened. The Observation is about a specific place, using specific methods, by specific person, at a specific time, etc.
The Plan and Instruction can be more vague about the: where, when, what, with what, how, by whom, etc.
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Gerard
Comments in line…
-1- An EHR is there to document what has happened
And a system to make this documentation work for the patient, providers and others…
-2- An EHR doesn’t contain workflow states. That is handled outside the EHR. It is in the EHR-system
An EHR does record the workflow states if required…see below
-3- There will be archetypes that help document a Plan, an Instruction, an Observation.
The Action class is specifically to record something that is done (by or to the patient) - this is not an observation in openEHR, rather it is a record of what was done. An order (instruction) to monitor the LFTs of a patient, may lead to an action recording the sample was taken (leaving the instruction in an active state), the action that the result was received and filed (leaving the instruction in a completed state). The observation of the actual level of the LFT enzymes is a separate recording.
E.g. to Plan for treatment, resulting in an Instruction to give medicines via injection , and the Observation that at the medication/injection has been administered at a specific point in time by a specific healthcare provider.
No, the Action record that the medication was administered
-4- Each archetype mentioned is almost the same has almost the same structure and will share common internal archetypes.
I think this is true for many instruction/action pairs.
There will be small subtle differences between these archetypes. Plans and Instruction can (but must not be always) less specific than the Observation
ACTION
when something has happened. The Observation
ACTION
is about a specific place, using specific methods, by specific person, at a specific time, etc.
The Plan and Instruction can be more vague about the: where, when, what, with what, how, by whom, etc.
A plan is a larger concept than an instruction - it is, we think, a set of instructions - some in the initial, some in planned state.
Hope this helps - Sam
Hi Sam,
The EHR-system cannot function without State models.
There will be archetypes that contain state models.
Because they are expressions of business rules and other domain knowledge.
Therefor the Archetype Ontology will have at least one State Model.
The EHR will contain a (implicit?) State Model!
(This is to the contrary of what I have written in a recent e-mail)
This State Model, that is part of the EHR (and should be of EN13606 part 1) deals with topics like the states data, information and knowledge can have in the process of recording:
- raw data received - rejected - …
- raw data admitted/committed to the EHR - rejected - …
- information (processed data + professional opinion) - …
- report (selected information by a professional) - …
- report sent
E.g.:
a series of lab results is sent to the healthcare providers,
when accepted it is formal a part of the EHR to be committed,
after the committal we know that the responsible professional fully accepts this data to the EHR.
When this data is selected in a healthcare process and contributes to diagnosis and treatment I call it information. It has been processed by the healthcare provider. He added his professional knowledge to the data and what is recorded is Information.
When data and information are selected in a healthcare process/context by the healthcare provider it will end up in a report (internal report)
Finally this report can be sent to the outside world.
Note that when received by others this report will enter that EHR as data.
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
In een bericht met de datum 12-5-2006 13:42:29 West-Europa (zomertijd), schrijft gfrer@luna.nl:
Hi Sam,
The EHR-system cannot function without State models.
There will be archetypes that contain state models.
Because they are expressions of business rules and other domain knowledge.
Therefor the Archetype Ontology will have at least one State Model.The EHR will contain a (implicit?) State Model!
(This is to the contrary of what I have written in a recent e-mail)
As sais before, the HL7 state machine is based on years of experience, and if we talk about harmonizing, these are exactly the items that would apply in CEN 13606.
Then the lacking items in OpenEHR can be enhanced too. This state machine operates on Act, which can be any clinical EHR entry, and you could limit the Act attributes if you want (except the status code of course, because that is what you need).
William
Dear William,
There are State Machines and “state machines”.
They serve a business purpose.
So before we know what we are talking about we must know the context.
I was talking about the state one’s and zero’s in strings go through going from data, to information expressing a professional opinion.
data in → information and knowledge out.
Of course there are state machines for:
messages,
clinical workflow
office workflow,
etc, etc
Can you provide us the context of the State Machines HL7v3 provides at this moment?
Gerard
In the proposed part 3 of EN13606 there is the following text about possible states an Entry in EN13606-1 EHRcom can have.
ENTRY.act_status
ACT01
|
Foreseen
|
- | - |
ACT02
|
Requested
|
ACT03
|
Accepted
|
ACT04
|
Booked
|
ACT05
|
Planned
|
ACT06
|
Ready
|
ACT07
|
In progress
|
ACT08
|
Completed
|
ACT09
|
Reported
|
ACT10
|
Terminated
|
ACT11
|
Forwarded
|
ACT12
|
Suspended
|
ACT13
|
Annulled-Cancelled
|
ACT14
|
Annulled-Rejected
|
ACT15
|
Substituted
|
NOTES: These terms are identical to those in HISA, as previously discussed and agreed, except that codes have been added. HISA will relate these as appropriate to HL7 Mood Codes. The original ENV13606 Domain Termlists for life-cycle and process status have been removed in favour of this more rigourous and harmonised list.
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Gerard Freriks wrote:
Hi Sam,
The EHR-system cannot function without State models.
There will be archetypes that contain state models.
Because they are expressions of business rules and other domain knowledge.
Therefor the Archetype Ontology will have at least one State Model.The EHR will contain a (implicit?) State Model!
(This is to the contrary of what I have written in a recent e-mail)
To keep things clear, I suggest we use the terminology "lifecycle state", i.e. of the documentation in the EHR; otherwise we tend to use "state" and "state machine" to refer to the state of an Instruction as it is executed in the real world (e.g. started, cancelled, postponed, active, suspended, aborted, completed etc).
This State Model, that is part of the EHR (and should be of EN13606 part 1) deals with topics like the states data, information and knowledge can have in the process of recording:
- raw data received - rejected - ...
- raw data admitted/committed to the EHR - rejected - ...
- information (processed data + professional opinion) - ...
- report (selected information by a professional) - ...
- report sent
openEHR doesn't model all of these, but some are modelled in VERSION.lifecycle_state; others are lower-level concepts in the communications framework..
- thomas beale