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 "standing"s 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
