On 21/06/2012 19:07, Gerard Freriks wrote:
>>
>> So to summarise, it came down to finding categories on which /health
>> information data structures /- i.e. information models - could be
>> based that would work reliably for most if not all of medicine. Now,
>> having used these categories for some years, it turns out that they
>> are remarkably stable. I know that the grey-zone debate on
>> Observation/Evaluation will continue for ever, but if one steps back
>> for a second, what you see is that for /most types of clinical /data,
>> it is obvious which category to use. Most of the archetypes for these
>> types are not really in question. Further, noone has identified (to
>> my knowledge) a strong contender for any new kind of category
>> (excepting for sub-categories of AdminEntry, which will probably
>> appear one day).
>>
>
> On the contrary, in spite of your claimed years of experience, I have
> my claim to experience both in the openEHR world and that of the
> EN13606 association and this experience shows that they way users use
> the definitions in openEHR give rise to problems for the users. I
> agree that nobody will annotate a Blood Sugar Measurement result as an
> Evaluation or Instruction or Action.
> In literature I have seen many wrong annotations because of
> problematic and unclear definitions in the real of openEHR.
> Why are we having this discussion if there were no problems what so ever?
*
* Not my personal experience, I mean the experience of deployed openEHR
systems around the world. In a sense there is no difference between
openEHR and 13606 - the same problem has to be solved: what data
structures are used to represent various clinical information? It's just
that 13606, being designed solely for haphazard and unknowable (in
advance) legacy data doesn't provide any specific Entry data structures.
OpenEHR provides the GenericEntry for that case, but also specific types
of Entry for data (legacy or newly created) whose structure is known.
There are various advantages of these data structures:
* a) you can actually build software that can process the data
properly. When everything is a tree, you have to write your own
private model for that - everyone re-invents a basic wheel, and
those software components are not generally re-usable with different
data.
* b) You can reliably query, because you know where things are. When
you aggregate huge amounts of clinical data from numerous sources
into patient-centric health records, being able to find Event origin
times, Action descriptions, protocol data and so on is worth a lot.
* c) you have a standard representation for some key patterns, which
means archetypes based on those patterns will be the same in those
key features, which provides a level of built-in standardisation for
archetypes, for those features.
It is not that there are no problems; the problems are to do with, in
some cases, knowing what Entry type to use (since you appear to agree
with the use of the specialised Entry types, this problem is the same in
13606). The answer has been confused somewhat by us being too purist and
trying to completely equate the data structures with the intended
ontological categories - as Ian McNicoll has said many times. I have
always said, what's the problem? But as soon as a clinical modeller
comes up with an example like some kind of summary, there is a long
debate. That's all that is happening here.
There is nothing basically wrong with the existing Entry types, or at
least no evidence of it that I have seen (and a lot of evidence to the
contrary). What is potentially not quite right is our understanding of
how to use them in all cases. We need to develop better descriptions of
which types to use for the more recently apprehended examples like
'clinical summary' and various types of lab result which have
'interpretations' included.
Interestingly, in the openEHR system implementation environments I know
of, these debates are short and sweet. The choice is made, the
archetypes, template and software are built and deployed.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120622/408ecb3e/attachment.html>
