Hi Hugh,
ok, you got me ;), I tried but I could not find a case were there would
have been a value in knowing that two standings are (more or less) the
same, I think because the word standing is so obviously *well-enough*
defined in everyday English, even for a Swede! But what about e.g. the
various laboratory battery archetypes? I would think that to know when
there is an overlap between batteries is a good thing. E.g.
P-ALAT;cat.c. would be in at least a couple of batteries.
Also, I do not see this as a problem of bad or good archetyping, but as
an archetyping reproducibility problem.
Hi Gerard,
the problem, as I see it, is that the vocabulary have semantic
structures attached whether it is represented or not and these semantics
may interact with the semantics of the archetype, hence the grey zone.
As it is hard to draw the line reproducibly and as the boundaries may
move as both archetypes and terminologies evolve, some overlap may be
another good thing.
As a conclusion I would like to agree with Hugh that terminology needs
information models and vice versa and that the focus now should be to
build consensus on the areas surrounding the grey zone.
/Daniel
On Wed, 2008-06-11 at 09:23 +1000, Hugh Leslie wrote:
Hi Daniel
I would be interested in a real world use case where you need to know
that standing has the same meaning in two different archetypes. If
archetypes are designed properly, then the semantics of the model are
self contained as a single concept. Specialisations of the model will
maintain the same meaning of the contained elements, and the semantics
of the contained elements relate to the whole concept. I would
contend, that in any examples where the same element needs to have the
same meaning across different archetypes, it is probably because the
design of the archetype is bad.
Coding everything to that level has great implications in terms of
cost - not only in terms of development, but also in terms of
maintenance. If there are compelling real world use cases for doing
this, lets do it, otherwise lets do what is pragmatic and gets the job
done as soon as possible.
regards Hugh
Daniel Karlsson wrote:
Hugh,
The argument comes when you say that every data point in an archetype
needs to be coded and here there are arguments both ways. I would say
that it is unnecessary to code every data point. There is little
benefit for instance in coding sitting, lying, standing, reclining n a
blood pressure archetype. The archetype contrains the value of
position to these four values. The values are in context and their
meaning is clear to anyone using this archetype. Translation is much
easier as the archetype gives an absolute context for the meaning of
the term. Coding these terms in SNOMED would be so that you can query
your health record for every standing item? Its pretty unlikely
that this would be a useful requirement. Coding everything s going to
be a very slow and enormously expensive process to get right. It
makes translation of archetypes much more difficult, especially for
those many countries that don't (yet) have a SNOMED translation.
Building archetypes is proving to be a very rapid and useful process.
I think that there can be more reasons for binding archetype nodes to
external terminologies apart from information re-use requirements in the
query for everything standing example, e.g. to be able to express that
standing in one archetype has the same meaning as standing in
another archetype.
Also, I didn't realise that I said that everything necessarily should be
coded. Referring to David Markwell's report, he states (more or less)
that things in the grey zone should be represented redundantly but he
also states that terminology binding requirements should be driven by
information re-use requirements. I agree with him on both points.
/Daniel
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI
Clinical Director
Ocean Informatics Pty Ltd
M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W:
www.oceaninformatics.com
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
