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. 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. 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). 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..." 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. Hope this helps to elaborate things... Cheers, -koray & hong yul From: openehr-technical-bounces at openehr.org [mailto:[email protected]] On Behalf Of Thomas Beale Sent: Friday, 10 December 2010 1:15 p.m. To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 09/12/2010 21:37, Koray Atalag wrote: Hi All, I've read similar work before starting with our design and found Thilo's prior work very relevant and well researched. This MIEUR 2006 paper describes a new layer of GUI model using Mozilla XUL - an XML based open web layout standard. AT the time of writing templates were not out there yet and from his discussion I reckon much of the GUI definition could be handled by templates. I now agree that pure GUI stuff must be represented elsewhere - but at the moment we find template annotations quite useful and sufficient. Be aware that our app is a Winforms one - not Web based. So the kind of GUI rules might differ from others which are almost all Web based. And one note to Thomas: we actually use templates for defining a minimum data set (yes not a maximal) for the purpose of reporting... that is more or less the intention of templates. Archetypes define 'maximal' sets of data points; templates define what you actually want to use in some circumstance. So w have both data entry/validation and reporting layout issues. Not messaging though but we are planning to transform the openEHR instance of endoscopy report into CDA and exchange with HL7 V2.x in near future. It would be interesting to see if you have some 'semantic' rules you think are needed in templates, as opposed to layout rules - can you summarise? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/25ab11ee/attachment.html>
