Thomas Beale wrote:
> the current semantics are that the occurrences of the referenced node
> are what takes effect. However, I agree that a preferable approach would
> be if the occurrences could be overridden at the origin point of the
> use_node reference. This would not be incompatible with the current
> semantics, and would probably be a useful change. What do others think?
>
>
Hi again,
I am happy that the issue of overriding occurrences will not create to
much trouble. I really would like to see that in upcoming releases soon.
Here is an interesting practical situation I had come across recently
which I wanted to share with you.
The problem is: CLUSTER[at3100) may appear >0 but when it appears
Site(s) attribute represented bye use_node as the third item can not
exist by itself. It may only exist >1 times if either one or both
ELEMENTs are selected. If I can override the occurrences of use_node
(which is default {0..*}) at the referencing point and make as {1..*}
then the problem can be resolved. Note that is the number of items of
the CLUSTER were only two, then it would be possible to handle the issue
by Cardinality {2..*}.
Clinically speaking during endoscopic observation of stomach if
physician visualizes an Hyperemic Mucosa he may further describe its
extent and presence of bleeding (if any) by depicting site(s) it is
observed. It may well be the case that in one site he sees a lesion
without bleeding and in three other sites he sees lesions (With same
extent or none at all) with bleeding. So the CLUSTER instance will
repeat itself two times in runtime.
CLUSTER[at3100] occurrences matches {0..*} matches { -- Erythematous
(Hyperemic)
items cardinality matches {0..*; ordered} matches {
ELEMENT[at3110] occurrences matches {0..1}
matches { -- Extent
name matches {
CODED_TEXT matches {
code matches
{[ac3110]} -- Extent
}
}
value matches {
CODED_TEXT matches {
code matches {
[local::
at3111, -- Localised
at3112, -- Patchy
at3113, -- Striped
at3114] -- Diffuse
}
}
}
}
ELEMENT[at3120] occurrences matches {0..1}
matches { -- Bleeding
name matches {
CODED_TEXT matches {
code matches
{[ac3120]} -- Bleeding
}
}
value matches {
CODED_TEXT matches {
code matches {
[local::
at1121, -- Yes
at1122, -- No
at3123] -- Stigmata of bleeding
}
}
}
}
use_node ELEMENT
/data[at0001]/events[at0002]/data[at0003]/items[at0050]/items[at0100]/items[at0110]
-- Site(s)
}
}
In shorter words when two or more items exist (with {0..y} occurrences)
under a container structure together with one or more use_node
references (at the original location having occurrences {0..x},
currently there is no way (other that writing the references nodes
possible with same codes) to constrain conditional existence or number
of instances of these items.
Best regards,
Koray Atalag, M.D.
METU Informatics Institute
Ph.D. Candidate on Information Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070115/0ca8b54c/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
