Hi Tom and Diego,
Short response is yes this is a better way of hardwiring a pure presentation related attribute into Archetypes which are supposed to deal with meta-data, structure and semantics of information only. The ideal solution would be to have an accompanying (but separate) layer of model responsible for GUI stuff. Our experience is that there are three types of such 'things': 1) Pure GUI related (such as passthrough or depicting a particular GUI widget, style etc.) 2) Assumed (e.g. to render a textbox for DV_TEXT or draw a frame/indend children nodes under CLUSTER) 3) Mixed - where it is not easy to separate presentation from semantics. Regarding (3), for example we have a GUI Directive called isCoreConcept (which we were inspired by the openSDE project by Astrid van Ginneken) which when modelling clinical findings and causes GUI generator to put a four state checkbox (null, present, absent, unknown). This actually applies to any 'thing' which we can also talk about its absence. This semantics implies to show or hide all of its children based on its presence (or absence). I think we can use one Archetype attribute (to depict the semantics that this is a clinical finding or perhaps a new class of its own (e.g. DV_CLINICAL_FINDING) and perhaps separate GUI directives (or make it an assumed behaviour when that semantic attribute is set) create this appearance and behaviour. Not so sure if I can show you other clear examples (other than core concept) at this stage but I suspect there are others. Oh and we have also identified a whole new territory which we call 'information axes' and 'semantic equivalence' ;) This also has to do with both semantics and presentation I believe. Think about capturing (and modelling archetypes) a clinical statement as: "Polyps were present in sigmoid colon and rectum and ulceration was seen in rectum." "In rectum polyps and ulceration were seen and ulceration was present in sigmoid colon" These are equivalent but how to model the archetypes; e.g. finding or site oriented will depend on modelling best practices and use cases. Rule of thumb is to design archetypes as close to screen representation as possible (hence the clinicians thinking). We must be able to depict in archetypes and/or presentation model that alternative representations exist and how to construct these. SNOMED CTs normal/canonical forms is pretty related with this but then the semantics is hardcoded into the SCT axes. My 2 cents Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale Sent: Tuesday, 10 January 2012 8:04 a.m. To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: Put a couple of comments on the wiki, but I think it is a thing that should be discussed on the list. In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows nodes required for structuring data but otherwise redundant for screen display and reporting to be detected by rendering software'. So now we have a GUI directive on the ADL. Shouldn't this be a part of the reference model information (if it is never supposed to be displayed) or part of a 'visualization template' (another different level). I would say that more information about visualization will be needed, and having visualization information separated between two different places feels like a bad design move. In general I am inclined to agree, and I have to say I have been in two minds about having this attribute in there. I am convinced by clinical modellers who say that something is needed to control interior tree nodes not appearing on the GUI (indeed, it is visual pollution). And - even if the template were being used to build a message definition (generated XSD or similar), and the data were processed into some report or other output, this attribute would be respected (technically, this is still 'user interface'). I know the passthrough attribute is used often from the current .oet template usage, so we need a way of dealing with the requirement. If we take it out, and say it is a GUI directive, the problem is we currently have no formal framework for that yet. Maybe the lesser of two evils is to do what Koray (I think?) said, and make it a special kind of annotation. I have implemented annotations in ADL/AOM 1.5, and they work nicely. We need to agree on some kind of standard representation, e.g. I originally didn't like this approach (I still don't really) but we have to be realistic and it's not the end of the world to bootstrap like this. As you can see it is 'soft programming', so error-prone, but it can obviously be made to work, and isn't hard to implement. However, now rendering software has to know to look for "ui" annotations and do sensible things with them. thoughts? - thomas __________ Information from ESET NOD32 Antivirus, version of virus signature database 6780 (20120109) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/9876515b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8902 bytes Desc: image001.png URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/9876515b/attachment.png>
