Hi Thomas,
Date: Mon, 26 Mar 2012 20:47:05 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: 13606 revisited - list proposal
On 26/03/2012 19:49, pablo pazos wrote:
Hi Thomas,
A while ago, we gave this issue a big thought when
designing the EHRGen framework.
Periodic event records are needed when recording certain
studies and when monitoring a patient, but this can be
recorded as single point events, and using a query to get
all the points in a series.
it can but that's very inefficient, and doesn't correctly represent
what is happening, when you are talking about multiple samples in a
series, e.g. coming from vital signs monitors, orthostatic BP,
apgar, and many others.
What I've said was incorrect, I mentioned "periodic events" and I should have
said "an Observation with many events", that was your question about, sorry for
that.
Here is the corrected answer: if you want to record a series of eventual events
you can do it with only one Observation with many EVENT, or many Observarions
with a single EVENT and an query to get the whole series, e.g. do create a
graph. E.g. for vital signs when a patient is under observation at an ER.
From the GUI perspective is very difficult to record
periodic events, because you have to login, select a
patient, select a record, select the section of that record
that contains the periodic data, enter a new item to the
time series.
and presumably enter another, and another. That doesn't sound like a
problem - it's how normal GUI for Apgar and multi-sample manual BP
collection work. Don't forget, we are talking about time series in
the seconds to minutes domain here. Although Glucose tolerance test
data would make more sense to be entered as one time series, after
the fact.
Consider this my comment with the "right answer".
>From the GUI perspective is very difficult to record MANY EVENTS IN THE SAME
>OBSERVATION, because you have to login, select a patient, select a record,
>select the section of that record that contains the OBSERVATION, enter a new
>EVENT FOR THAT OBSERVATION.
The other option is to have the patient's record always
open, and that is not possible in all scenarios (for
technical or security reasons).
well ifyou are talking about long period of time, like repeated
nursing observations, you should be committing those 1 sample at a
time.
Consider this ER scenario: a BP value could be recorded each 30" or so, and the
system could be used 1. for many patients, 2. by many users, 3. on the same
machine.
The problem is when an item is commited, it should be as a part of a
COMPOSITION (?), so if a nurse want to record a second take of a BP she is
monitoring, and of course she wants to see the current recorded values for that
series, another COMPOSITION should be created only for that value (or not?).
Sorry again for the confusion.
Kind regards,Pablo.
Of course, the system could have something in the middle storing all the values
without commiting them
In the other hand, in the majority of cases of clinical
record through a GUI, the data is recorded as a single point
event, e.g. at a patient visit. So we design the EHRGen just
to use point events, and if you want to record a series of
events, a service should be provided to get the data from
other systems (e.g. a LAB system), but not from the GUI.
that and vital signs monitors are certainly a common source of
time-based data. But whether the source of the data is the GUI or
somewhere else doesn't change the semantics of the model, or the
need for it. Like I said elsewhere, I have no problem with adding a
single-event Observation as well. But having only that will
completely cripple many hospital apps and efficient data
representation and querying related to this data.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/50b7decc/attachment.html>
