Ok,
Do we also need to "grade" the degree of execution for "orders"?
If I want the patient to take a short course of antibiotics:
I could: a. write a manual prescription
b. make a note in EHR to that effect
OR
use my computer system to: print the prescription
record details
As a general practitioner, my remit is normally served by the further actions
of:
signing the prescription
giving it to the patient.
We could also consider recording, somewhere along the line:
when was the prescription given to the pharmacist
when it was dispensed, ready for collection
who the dispensed product was given to (patient or "agent")
and
when the patient started treatment
when they stopped, (resumed, started again...)
(why they stopped, resumed...)
how many tablets were left after the patient stopped taking the
tablets
and maybe even
disposal of those tablets.
I guess most of those are implemented in relation to narcotics, in most
countries.
I would humbly submit that Completion of the order is not a simple Boolean. For
each of the above, a truly detailed record would retain: date, time, identity
of the agent completing that step, identity of the agent recording the step,
and possibly a text field to record any further ambiguity not originally
compassed in the definition, such as the patient vomiting at some undefined
interval after oral administration.
Jan Ravet
Augusta
West Australia
----- Original Message -----
From: Gerard Freriks
To: Williamtfgoossen at cs.com
Cc: openehr-clinical at openehr.org ; d.kalra at chime.ucl.ac.uk ;
thomas.beale at oceaninformatics.biz
Sent: Wednesday, September 07, 2005 6:12 AM
Subject: Re: Antw: Re: 'Actionability' of orders
Hi,
In my parlance:
Messages are to update databases and are facts. eg lab results
Documents are to update humans with professional opinions that are signed.
The EHR and its extract are documents.
Depending on the type of archetype that what is recorded is:
-anamnesis (history)
-observation
- plan
- order
Each of these four types form a family of archetypes and indicate context.
Medication information inside an anamnesis archetype means that this is
reported by the patient or others (eg the pharmacist when he sends a copy)
Medication information inside an observation archetype means that this is
observed by the healthcare provider
Medication information inside a plan archetype means that this is an
intention by the healthcare provider
Medication information inside an order archetype means that this is a
prescription on behalf of the patient for others (pharmacist) to
dispense/provide
What we miss in this list is the context where the extract reports that
something has been executed.
This means that we have to provide for an archetype type that indicates that
a plan is executed, or an order is executed.
We have to add the execution type of archetype.
If this is the case we need attributes that allow us to indicate a
cancellation, of anamnesis, an observation, a plan, an order and execution.
This makes the complete list:
-anamnesis (history)
-observation
- plan
- order
- execution of a procedure.
And next we need the machinery to indicate the cancellation of these.
I'm just providing some thoughts.
In the AKF project we need to address all this.
Part 1,2,3,4,5 of EN13606 are not affected.
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 654 792800
On 6-sep-2005, at 23:04, Williamtfgoossen at cs.com wrote:
Hi All,
Interesting concepts discussed here: An EHR for a clinician deals with two
major classes of information:
1. Classes that describe the situation of the patient (different levels
of detail, changes over time, enourmous sets sometimes)
2. Classes that describe the behaviour of care professionals ( a single
medication description, giving information, asking consent, performing a
procedure,a gain many).
Often # 2 are triggered by #1.
And #1 and # 2 can have different time formats (past, present, future).
However, a proper EHR should allow to include 'future' things that could or
should happen. E.g. in care planning it is important to have a start value of
the situation of the patient, compare this with historic description of this
situation when available, state a goal of what to expect in an overseable time,
and then check for the actual outcome e.g. after care has been carried out.
If an EHR can only store what has already happened, so the past, it becomes
useless for supporting clinical practice.
It is interesting that the concepts of trigger is fundamental to HL7
dynamics, and the 'mood' of the action / obs (so #1 and # 2) are already
available in the RIM classes: INT, RQO, GOL, EVN are very powerful to support
the dynamics of monitoring and workflow. Key components of EHR.
See also the ISO TS on the EHR in which both data / structures and dynamics
are the first 2 chapters.
Sams distinction between action required versus for your information only
is interesting and probably would need further development on message and on
EHR level.
And again: from the perspective of clinical documentation and care planning
the disctinction between message and EHR is arbitrary: we have systems that are
integrated or that are coupled, that have similar functionalities. Key is that
we analyse #1 and # 2 appropriately, model it for ICT and only then develop the
tech stuff in which it works.
My 3 Euro cents,
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050907/2275c4e8/attachment.html>
