I know that this is probably something very inappropriate but I happened
to need such a solution. An example:
CLUSTER [AAAA]
CLUSTER [BBBB] Some type of finding (a lesion: ulcers)
ELEMENT [CCCC] A Feature of the finding (i.e. bleeding)
v: some value
ELEMENT [DDDD] Another Feature of the finding (area)
v: some value
ELEMENT [DDDD] Another type of finding (a lesion: atrophy)
v: some value OR null_flavor
My problem is I want to be able to state whether CLUSTER[BBBB] is
observed (True) or not (False) when both features (ELEMENTs CCCC and
DDDD) are not present (NULL). I am perfectly able to state it when the
data structure is an ELEMENT.
Problem arises when none of the features (attributes) of CLUSTER [BBBB]
is observed and that two things can happen:
1) None of the features could really not be assessed, but there is
definitely an ulcer (presence=TRUE)
2) The lesion in CLUSTER [BBBB] is not visualized at all
(Presence=FALSE). But then we need to know why (classical flavors of null)?
Of course a straightforward solution is putting under each CLUSTER with
child nodes, a new ELEMENT describing its "presence" with Boolean type
and with null_flavor.
However if it will not break very badly current semantics and other
strategies, the advantages of such approach might be:
1) Reducing size, manageability and understandability of (big) archetypes
2) During querying of leaf-nodes in a huge repository, the search
algorithm can first check parent nodes' presence and then further go
down to leaf-nodes. If a whole branch is not valid/null from the top,
then there is no need to look for lower levels and the performance might
be enhanced.
I might be making a horrible proposal here technically or even there
exists another solution already, but this is what I need.
Thanks for your (always) kind answer...My comments & reply is below
Sam Heard wrote:
Hi Kory
You can have an empty cluster....if you want to say why it is empty
then use null flavor on one or more of the possible elements.
Yes this is exactly what can be done now...But when starting to think
(or even implement) archetypes not merely as abstract clinical concept
models but as objects or program data (as instances) then this may issue
become more obvious.
If these do not suffice as approaches I probably need the precise
example. It suggests that your model may not be optimal.
Cheers, Sam
Well you are definitely right (and polite) about my models...I also
suspect that they are might not only be optimal but I am trying. The
previous example was meant to be the precise example but I assume did
not make sense (even to me now!). Well instead of an example I will
shortly summarize the issue by example:
Consider instances of some archetype; let's say with 2,3 levels of
nested Clusters each having many elements in leaf nodes. The archetype
may describe a cardiovascular patient history and these particular
clusters happen to define Risk factors. So one path might be: > Risk
factors > Smoking > Cigarette > Quantity. And if a patient has no risk
factors, all the entries will be null in runtime instance and eventually
in the database.
Think about the simplicity of putting a flag or null_flavor at the top
node so that a query or a GUI generator will utilize for better
performance. Is there any other way than checking each path for element
value/null_flavor path? And think about this for millions of records.
What disturbs me most with as is approach is that the control is
transferred to implementors in deciding to either put an element under
each cluster or depict presence/null_flavor on clusters.
If I understand correctly, to put it in database terms: if the archetype element may be null, the record structure may not exist. That's not the same as the data in the record being null.
If fact, Koray, I think it's it's what you are asking for.
In your example, if null is allowed in the archetype, smoking could have a cigarette record with elements, or a cigarette record with no elements, or no cigarette record,
It would then be up to the implementor to decide whether to capture the type of smoking at all, or for example just smoking/nonsmoking/don't know.
Regards,
Colin