Hi Tom, I'll try to make a few things clear. I'll chop off parts of my original
message for better readability.
.....
However clinical findings, as in our case, essentially require to be depicted
as unknown or absent explicitly. We have initially thought we could solve the
issue by using flavours of null which is defined by openEHR RM for each ELEMENT
data item (caution here it is only for ELEMENT) but the problem is that these
findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes.
This is because we use ELEMENTs under each CLUSTER to depict properties or
attributes of those findings such as size, number extent etc. And we cannot
represent Absent with flavours of null either.
Koray, I don't get this bit: you are saying you want the effect of flavours of
null for whole sub-trees of information?
Yes I suggest that we have some means to indicate the presence state of a whole
sub-tree with further qualifiers as to why information was not available. I am
talking about present (well this is straightforward), absent (there has been an
effort to find a certain lesion but it was not there) and unknown/indeterminate
(which I think flavours of null can be used to further qualify). I think the
absent option can simply be handled by negation of present (as Graeme
mentions); but not sure how to do that in openEHR.
.....
We think this might best be denoted in the RM; either at CLUSTER or ITEM
classes. Something like null flavours but not quite the same. Or perhaps a
dedicated new class?? That's up to the discussions.
well moving null flavours to ITEM (meaning CLUSTER and ELEMENT both get it)
would not be that hard to do - it has no negative impact on anything. But we
have not done any general semantic analysis on this idea...
Happy to provide you with more information and help with that if
necessary.
.....
To depict standalone findings during archetype design setting the cardinality
of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality
to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1
it's possible to have CLUSTER's with 0 ITEM's as long as it isn't validated by
the RmValidator, this isn't considered a desirable usage).
but you can't record any data in a CLUSTER with no children. If the CLUSTER is
named (i.e. has at-code) for 'haemorrhoids' the implication is that something
is going to be said about this. The function of this name/code here is as a
name, not as a value. Some ways of doing this would be:
ELEMENT [haemorrhoids]; value = present
This won't work for us because almost all findings are qualified by attributes
and associated by anatomical sites. So it has to be under a cluster as a
sub-tree
or
CLUSTER [haemorrhoids];
CLUSTER -- more complex description of haemorrhoids
ELEMENT
ELEMENT
etc
Well close but not exactly. Our modelling approach is:
CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat
as a whole for defining same finding with a different set of qualifiers)
ELEMENT {0..1} [Type] --- values
ELEMENT {0..1} [Stage] --- values
ELEMENT {0..1} [Extent] --- values
ELEMENT {0..*} [Sites] --- values (note that this can be multiple with
occurrences set to 0..*)
So when we create the 'value' instance which is a shadow of the opt we have
all parts of the model in place - i.e. all ELEMENTS have null values and
obviously CLUSTERS holding them are all instantiated. When use enters data from
GUI the widgets are bound to the parts of the instance and values are updated.
If a multiple entry has been made then new instances of some subtrees are added
to the 'value' instance. However when persisting this 'value' instance we prune
all null sub-trees and then serialise and save.
So the point is we never have empty CLUSTERS which we want to store data; but
what happens is initially lots of CLUSTERS holding sub-trees are instantiated
with all its ELEMENTs with null/default/assumed values. As I explained in order
to represent the presence of this sub-tree we insert a special ELEMENT which
depicts this presence information to each and every sub-tree. And we then have
to hardcode this in our application which makes me uncomfortable. I think it is
not good modelling practice to do this manually. Perhaps best way would be not
to touch the current data structures but introduce a custom syntax in ADL which
will make things easier and more consistent among different implementations.
or
CLUSTER [features present];
ELEMENT [observed feature]; value = haemorrhoids
ELEMENT [observed feature]; value = something else
etc
Same as first one - won't work
The real issue is a bit more tricky and has to do with core semantics: it
doesn't make sense to depict a finding as absent or unknown when qualified by
certain attributes.
....
ok, so absence / negation is a common requirement in endoscopy...
That is the current requirement for us but I think this applies
equally to many other domains in clinical medicine.
So it looks like some qualifiers may change the existence of core concepts - so
perhaps we need some means to tag them during modelling. It looks like these
are 'physical' properties and not 'man-made' concepts.
I think you mean that the possibility of reporting absence (when it can make
sense) depends on the morphological feature?
Good point - have to dig further into the morphological
features and check to see if there are any exceptions though.
-koray
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101216/7ff0f7fc/attachment.html>
