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
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/d2008904/attachment.html>
