hi Koray
Unknown Indeterminate. (though they overlap)
Generally, this is not really an endoscopy requirement. I've seen it come up
in all sorts of contexts. (for instance, the Australias structured pathology
reports). Even in the case of a list of medications: you can assert
that the patient *isn't* taking any medication. Also, you can assert that you're
not sure of the entire list, but you know that the patient is *not* taking a
medication
But it doesn't apply generally - it's a pattern that varies across particular
issues. Frustratingly, there's no consistency in the way people think, as
far as I can tell, and the various coding systems are even more inconsistent
than people's thinking (mainly due to variations in total capture of woolly
thinking across issues)
With regard to the proposal to have nullFlavor on cluster, HL7 pretty much
does this in v3 - all associations have a nullFlavor. But it's a
difficult concept -
when you say the association is not a proper value - which parts of it? It's
like negation - what parts of observed as improper, and what parts properly
define the improperness? (LIke negation - what's the scope of the negation?).
I don't see why the same concern wouldn't apply to a cluster.
It seems to me that this was meant to be solved by having optional clusters
with mandatory items. Because of the variations in the pattern, you sometimes
write additional constraints - like, for instance, you can't observe
any features
of a carcinoma if the carcinoma is not present. But usually we don't bother
encoding these very obvious things in the models
I do think that you have GUI hinting requirements for the template
language here.
These are the kind of things our kind-of-like-archetype-system focuses on:
GUI hints in the templating language
Grahame
On Wed, Dec 15, 2010 at 1:01 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 14/12/2010 10:44, Koray Atalag wrote:
Hi Tom, here is our response:
We have so far came across two issues which we believe should be handled at
the clinical modelling levels (i.e. RM, archetypes and templates). These
have to do with the structure and semantics of the clinical information and
underpinned by domain knowledge.
1) During our implementation one change request mandated that we should be
able to depict certain data items (endoscopic findings) as
present|unknown|absent as well as null if nothing has been specified about
it. In the work for Nehta on anatomical pathology models Ian followed a
similar approach where some findings were expressed as present, absent or
indeterminate as far as I remember and this was definitely a repeating
pattern.
This caused us to look more carefully into the whole thing and we came to a
conclusion that not all data items need/can be represented like that. For
example it doesn?t really make sense to indicate absence of a drug in
patient?s medication list or a medical procedure performed; they are either
present and further qualified (i.e. Aspirin 300mg tid or biopsy performed)
or not mentioned at all.
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?
Our workaround in current implementation is that we have inserted to each
and every clinical finding CLUSTER a special ELEMENT data item called
?Present?? of DV_CODED_TEXT which have the following? values: 0Null,
1Present, 2Unknown, 3Absent. We don?t further specify the reasons of
Unknown but using flavours of null would be logical.
Even more interesting when nothing is entered on GUI for a clinical finding
or when entered but later on it is ?cleared? instead of putting value 0 for
null we can actually ?prune? that particular CLUSTER (and all downstream
items); i.e. remove altogether from the value instance.
Our solution to this issue was to come up with a GUI Directive called
?isCoreConcept?.? This instructs our GUI generator to render that item with
3- state checkbox and also hide all its children until a value has been
selected. This directive also imposes an implicit precondition that the
affected CLUSTER define the special child ELEMENT that denotes Present? -
otherwise the GUI generator will render the model invalid. Actually when we
rethink about this we found out that this particular directive actually is
overloaded and has elements of both
