On 28/08/2013 10:07, David Moner wrote:
>
>
>
> No, currently all atNNNN codes are also found at the ontology in
> LinkEHR, even if they are empty, to be compatible with the VATDF2
> check, although we would like to avoid it :-)
>
> In my opinion we talk of two different levels of meaning. One is the
> explicit meaning, where the definition of the node is defined through
> a natural text or a terminology binding and that is, of course, the
> needed for a complete semantic interoperability. The other is the
> implicit meaning, when you create e.g. an OBSERVATION with occurrences
> {1..1} you are creating "An OBSERVATION that only happens once". That
> means something (otherwise you wouldn't have defined that constraint),
> even if you cannot give it a natural name or a terminology code. And
> if it means something, it shall have an identifier.
David, I am not totally clear on what you mean. OBSERVATION is a class
that always has an at-code on it anyway, because it is a high-level
class and needs its clinical meaning defined anyway. If you impose
{1..1} on it, you will do that via a SECTION or COMPOSITION slot.
>
>
> If we go the other way, then we are saying: at-codes are 100%
> mandatory everywhere, but definitions for them are optional. Then
> we need some rules on when it is optional and when mandatory. What
> rules would you propose for that? Remembering that a clinical
> modeller absolutely relies on those rules for understanding the
> archetype?
>
>
>
> I don't think a clinical modeller would have to mind about these
> aspects. He/she creates an archetype node (internally, a unique atNNNN
> code is created). He/she optionally gives it a name or defines a
> terminology binding (internally the ontology structures are created).
> When the archetype is used or processed, the systems will only use the
> information they have available.
Ok, but if tools have no rules, then we can end up with an archetype
like this:
OBSERVATION matches {
data matches {
HISTORY matches {
....
}
}
}
with no meaning on anything. What is to prevent that?
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/6610f406/attachment-0001.html>
