On 29/08/2013 08:30, David Moner wrote:
>
>
> 2013/8/28 Gerard Freriks <gfrer at luna.nl <mailto:gfrer at luna.nl>>
>
> David,
>
> Can I summarise it for my understanding as:
> - ATxxxx codes are pointers to an 'ontology'.
> - ATxxxx codes can be considered symbols that represent a
> particular concept
> - The 'ontology' provides a name that will be used to display the
> name of a node (concept) in an archetype.
>
>
> I will stop at this point because I think it is the kernel of the
> discussion. Which should be the idea?
> - The ontology "must" provide a name or meaning for each atNNNN node
> in an archetype? This is how thing are supposed to work in current
> specifications
> - The ontology "can" provide a name or meaning for each atNNNN node in
> an archetype? This is how we think it should be, the ontology provides
> a semantic description only when it is needed or it is possible.
My view (to date, which I am happy to revise if a better theory comes
into view) has been:
- the ontology section provides a name or meaning for any node whose
clinical/domain meaning is otherwise not understandable.
That is, it's not needed for:
* single valued-attributes, one alternative,
o e.g. ENTRY.protocol in most archetypes is just one constraint
tree, so it just means 'protocol' for whatever kind of Entry it
is, e.g. BP measurement
* arguably single-valued attributes with multiple alternatives of
different RM types
o e.g. ELEMENT[at011|cigarettes smoked|].value matches DV_COUNT or
DV_QUANTITY (grams).
The meanings of the above kinds of nodes are comprehensible.
Now, another requirement may be that a unique path can be stated for
every possible alternative in an archetype. This would force the second
case above to require codes anyway (which is the current rule).
My question is not which node codes don't need definitions, but which
nodes don't need codes? And secondarily, are there any nodes that need
codes that don't need meanings? I struggle to find any example of the
latter (but I haven't looked that hard).
>
> And what is providing a meaning or semantic description?
> - A terminology binding? Of course, we will rely on terminologies and
> ontologies for a complete semantic interoperability.
> - A natural language description? Well, here is where no automatic
> rules can exist to check if a description such as "Systolic blood
> pressure" or "This is a PQ type node" or "The sky is blue" or " " are
> correct or have a sense, only a human validation check can work here.
well the idea here has always been, and remains justified today:
* an archetype-local definition in words for the meaning of the node
is needed, because this says _exactly_ what the designers intended
* those meanings are given by domain experts, and (with some review,
QA process) will be as good as any linguistic definition in any
ontology or terminology (probably better, because they are specific
to the case at hand)
* if we are lucky enough to find some code that matches, or
approximately describes the same thing in an ontology and/or SNOMED
CT / LOINC etc, then we can add those bindings
If we were only allowed to define nodes for which matching codes can be
found in OBO, SNOMED or other supposedly reliable places, then we would
have no chance of building anything but the most meagre archetypes, and
no ability to build semantically enabled health information systems.
I don't know of any facts that would contradict this long-standing
position today...
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/0bf74e72/attachment.html>
