On 15/12/2010 12:17, Koray Atalag wrote:
>
> Hi Tom, yes you nailed it...Actually this is exactly what we do at the
> moment but uncomfortable with this approach. I think it'd be great if
> the formalism handles this common pattern without such a workaround
> which is repeating all over.
>
> Cheers,
>
Ah - I see. Well to my mind, this is not a workaround - I think it
properly represents the data. You could maybe consider
CLUSTER occurrences {0..*} [Tumour]
*ELEMENT {1..1} [Presence] --- DV_ORDINAL : present, absent, ...
other values?*
CLUSTER {0..1} [details]
ELEMENT {0..1} [Type] --- values
ELEMENT {0..1} [Stage] --- value
ELEMENT {0..1} [Extent] --- values
ELEMENT {0..*} [Sites] --- values (note that this can be
multiple with occurrences set to 0..*)
The you can have path logic like:
if .../items[tumour]/items[presence]/value = present then
-- do stuff with .../items[tumour]/items[details]/items[type] and
siblings
end
which might seem more logical.
In any case, the presence node should be mandatory I think. This is also
not a case for null-flavours, since there is no inability to get the
data; the observations are being made perfectly normally, and some of
the observations are that X is not present. This should not be confused
with the inability to perform an observation, which is what
null-flavours are about.
- thomas
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101215/f5057a5c/attachment.html>
