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: 0>Null, > 1>Present, 2>Unknown, 3>Absent. 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 semantic and presentation information. > So we propose to delegate the semantics part to modelling side and use > another GUI directive called ?hideChildren? (which actually we have also > defined before but not used. This directive can then be used for core and > non-core concepts. > > > > 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... > > > > 2) We also saw that some clinical findings can exist alone; i.e. without > further qualification or depicting anatomical sites. Example is haemorrhoids > where anatomical site is implied and it can just be reported as > ?haemorrhoids were observed? (can be qualified as internal external or even > a grade but the point is it can exist on its own). But when you talk about a > tumour you need further description? i.e. site, type, grade etc. It is not a > valid clinical expression to say ?tumour was present? in an endoscopy report > (yes context is important, in some other contexts this expression may well > be valid). This indeed was also denoted in openSDE with a GUI directive > called ?selection requires further description?. > > > > 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 > > or > > CLUSTER [haemorrhoids]; > ??? CLUSTER -- more complex description of haemorrhoids > ??? ??? ELEMENT > ??? ELEMENT > ??? etc > > or > > CLUSTER [features present]; > ??? ELEMENT [observed feature]; value = haemorrhoids > ??? ELEMENT [observed feature]; value = something else > ??? etc > > > > 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. > > > > One example is: ?Three polyps were observed at ascending colon? there is no > point in saying ?Three polyps were absent at ...? > > > > But this is a perfectly valid (and quite frequently used) expression in > endoscopy reporting: ?Villous polyps were absent at ascending colon? (here > villous is an attribute for type of polyp). > > > > Another invalid expression: ?3 cm long stenosis was been absent...? > > ok, so absence / negation is a common requirement in endoscopy... > > > > 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? > > - thomas > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Grahame Grieve, CTO A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083 P: + 61 3 9450 2230 M: + 61 411 867 065 F: + 61 3 92450 2299 E: grahame at kestral.com.au W: http://www.kestral.com.au
