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 structureThe proposed
POINT_EVENT of the ACTION could record the information like the current
ACTION.time attributeThere 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>?
Thanks a lot for sharing,Kind regards,Pablo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120213/7247d0d2/attachment.html>
