Hi!
I just want to get some more global response to a little discussion
some of us had here at LiU. So here comes some provocations... ![]()
In contact with clinicians we have discovered that the naming of the
openEHR reference model classes OBSERVATION and EVALUATION (and of
course the corresponding archetype families) is confusing partly
because of the class names themselves. The distinction in practical
clinical documentation cases is often far from obvious when just
looking at the names, ontology or the "investigator-patient-cycle"
(see e.g. http://www.openehr.org/wiki/display/ontol/Ontologies+Home )
.
When one starts telling clinicians _not_ to focus on the names and
explains the _technical_ difference of available attributes and
mechanisms of the respective classes, then the confusion often gets
reduced.
What OBSERVATION does provide is extensive support for structured
reporting of timed events. EVALUATION on the other hand is the most
generic concrete form of CARE_ENTRY.
The problem is that the words "observation" and "evaluation" already
are so loaded with meaning. Maybe some renaming (at least during
pedagogical presentations) would help understanding. Mentally rename:
CARE_ENTRY to ABSTRACT_CARE_ENTRY (usually never seen by clinicians)
EVALUATION to CARE_ENTRY
OBSERVATION to CARE_ENTRY_SUPPORTING_STRUCTURED_TIMING
(I'm not insisting on actual technical changes to class names, but
rather in mental presentation approach. I think the openEHR RM-design
is great, it's the presentation and naming I'm concerned about)
This way of thinking may make it easier to select class according to
documentation (and reuse) needs rather than trying to fit it into some
more or less useful ontological thinking.
If you want to create EHR systems with advanced graphical user
interfaces or decision support using timepoints in the data, then the
task is a lot easier if there is a uniform way of reporting time (as
in the OBSERVATION class) than if people squeeze in timepoints in
arbitrary places of EVALUATION, so there is a technical need for both
classes. The selection of class during archetype design could however
rather be based on the possibility/applicability of timing-structure
rather than ontological hair-splitting (Don't get me wrong, I do
appreciate ontologies in a general sense...).
INSTRUCTION and ACTION usually lead to less confusion, and are
probably less harmful names.
The focus on the investigator-patient cycle and the "beauty" of an
"ontological" approach is probably attractive at first, but if it
leads to problems during presentation and modelling, then their role
should be played down.
Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
P.s. Compare to the deceptive "beauty" and simplicity of the handful
of HL7 v3 RIM core classes and then consider if the
openEHR-cycle-and-ontology-presentation-focus is a similar mental trap
that seems nice at first, but really does not make modelling and reuse
simpler. (...or was that too provocative...)