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.
>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. 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).
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.
I don't know if I'm clear here, but hope that helps.
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Date: Fri, 23 Mar 2012 14:25:34 +0000
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal
In the thread below, Pablo asked whether Action should have as its
data not just an ItemStructure but a History, like Observation. Does
anyone else have evidence supporting this need?
A related question is: is there a need for an Observation type that
only has one Event in it, i.e. one time-point? Obviously quite a few
observations in real life, including 'patient story' are of this
form. Our original motivation was to make all Observation data
structures the same, hence the current data structures. Introducing
more types makes code more complex and therefore error-prone, but
generally makes data simpler/smaller overall.
thoughts?
- thomas
On 13/02/2012 21:31, pablo pazos wrote:
Hi Thomas,
Sorry for the delay, I'm working on several projects right now
and have little time to follow discussion here.
I'm also thinking about the ENTRY model, to lift up
the data/description attributes from all entry
subclasses to the ENTRY, to have a
ENTRY.data:DATA_STRUCTURE attribute, so all subentries
could define the data as ITEM_STRUCTURE or as a HISTORY.
We did think about this a long time
ago, but it did not seem useful. But I assume you are
thinking of doing it because you want to make ENTRY a
concrete class which could have 'any' structure.
Nope, is because I see a common pattern on concreate ENTRY
subclases.
In theory doing this breaks a basic
modelling rule, which is that a superclass whose descendants
define the possible data space should not itself be
concrete.
I think this is not the case, having a ENTRY.data :
DATA_STRUCTURE is in fact a more specific ENTRY class, but is
still a generic one that could be specialized in many ways. In
my (maybe biased) experience, all subclasses from ENTRY would
make use of this attribute since a structure is needed to
record information.
The argument here I suppose is that
we want to build in a 13606-style 'uncommitted' kind of
ENTRY. In fact we already have this - it's currently called
GENERIC_ENTRY. This doesn't get used
at the moment (although it has been there for years), and if
we want to make it a subtype of ENTRY, that could be done.
The main thing to solve I guess is the conversion of any of
the specific openEHR kinds of ENTRY into a generic ENTRY
structure defined by 13606. This can actually be formally
specified by an algorithm. It doesn't require that the
parent abstract ENTRY become concrete either. I am unclear
if there are other reasons to make the ENTRY parent type
concrete, to mimic 13606 ENTRY, rather than simply move
GENERIC_ENTRY to be a subtype, which seems more obvious to
me.
Maybe to have the flexibility to define ACTIONS and
other entries to have a data attribute of class
ITEM_STRUCTURE or HISTORY to track time of events
instead of inventing DV_DATE/DV_DATETIME ELEMENTs on
ACTION/EVALUATION/INSTRUCTION archetypes is a good idea.
What do you think?
Well then I think we risk making the
model ambiguous, and different people will use such flexible
structures to do the same thing in different ways, which was
the thing we were originally trying to avoid.
I disagree here, the model semantics could be defined in
the specs. My argument is that we are giving a more flexible
IM is adding flexibility (not ambiguity) to archetypes, and
giving knowledge modelers more options. Then, when they create
a concrete archetype, there is no ambiguity because an
archetype models a concept in one way, and if abstract classes
are used in archetypes, the archetype needs specialization to
make is usable on a real environment (software can't
instantiate abstract classes, and could not make the decision
between using subclass A or subclass B).
The HISTORY class is very nicely
designed to represent complex time-series data that has the
same protocol and was captured in an uinterrupted series. It
does not try to model sequences of different types of data -
in that case, you just have multiple observations.
I totally agree.
It deal well with point values,
averaged interval values, max, min, sample compression and a
few other things. But it's no good with a succession of
different kinds of patient events. Any such timeline for
that kind of thing has to be constructed post-hoc, when the
actual events have already occurred.
That's the model semantics that should be defined on the
specs. Knowing that, not misuse should happen. In the other
hand, tools should not permit this to happen, and this could
be implemented as semantic validation of RM instances (BTW
this should be done with the current model also).
I can see a theoretical argument to
wanting HISTORY in ACTION, instead of just a single point
time, but in practice, noone has ever been able to come up
with an example where a series of ACTIONs needs to look like
a structured series, mainly because ACTIONs usually need to
get recorded when they are done.
IMO ACTION.time:DV_DATE_TIME could have the same semantics
as ACTION.data.events[0].time, if ACTION.data:HISTORY and
events[0]:POINT_EVENT.
The easier example is a repetitive INSTRUCTION like "give
5mg of XXX for 10h every 30m":
The ACTION would register the same information structure
The proposed POINT_EVENT of the ACTION could record the
information like the current ACTION.time attribute
There is a series of ACTIONS recorded for the same
INSTRUCTION (instead of creating one ACTION instance for
each XXX administration, one ACTION could handle all the
information, time series and data, for all the susbtance
administrations for the same INSTRUCTION/ACTIVITY).
For example, a regular IV drug
administration _could_ in theory be represented by an ACTION
with a HISTORY, each of whose events described the action
(say: admin Morphine 20 mg IV) but to achieve this you would
have to wait until all the administrations were done before
writing the data. So for some hours it would look like no
drugs were being administered, then a long series of them
would suddenly appear in the EHR stretching back... days?
I can't see the difference with the current ACTION model: the
ACTION could be created when the administration starts, and
the date/time of that event could be written in
INTERVAL_EVENT.time attribute, and when the administration
ends, the duration could be written in the
INTERVAL_EVENT.width.
Maybe I'm missing something here, but that's whay I
understand.
I am not saying ACTION is perfect -
there have been suggestions for example that an ACTION +
link + OBSERVATION structure should be available for when
the prescribed 'action' was in fact a new observation, such
as 'check patient reaction to drug'.
It would be nice to discuss this proposals with more
members of the community. I'm not saying we need to do the
changes, what I say is lets discuss if we can improve the
model in some way, analize the pros and cons, and write down a
decision. I mean: we need to try to not leave these kind of
discussions die on the maillist, this things are valuable
assets that could be explored/exploted in the future.
Another question of time comes up with
EVALUATION - e.g. the diagnosis archetype. This is full of
times, and tries to follow a disease course model. Currently
there is no RM class for this, but if a standardised
temporal disease model were agreed across medicine, I
suppose there is no reason why not. But it also is not a
simple HISTORY - it is more 'bumpy'... and I don't know if
there is any agreed standard model of this.
Maybe is something like a HISTORY<ENTRY> or a
HISTORY<COMPOSITION>?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/7d3d8590/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/7d3d8590/attachment-0001.jpg>
