Hi Ian, others We've had a bit of discussion on this at Medinfo and that you pointed to separation of pure GUI stuff from others where there is an inherent relationship with the semantics and structure of information - fully agree. The question is how to do that and when; i.e. the process. I think the time is just about right as implementations start and progress rapidly. As to how I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us.
As Ian pointed out we have some 10 directives, which turned out to be all generic (i.e. not specific to our endoscopy application) which is great. The isCoreConcept directive really is a special one which deeply involves semantics and structure of the clinical information being modelled. Rest of the directives are not so much like this but there is an obvious need to separate. The mantra of openEHR modelling says that anything that has to do with structure and semantics goes into clinical models. Then which models? I think we must first make clear what we are talking about: out of models or within models and then Archetypes or Templates. For us this was a no brainer because I think ALL pure GUI stuff should go to Templates. I have explained my reasoning in a previous message but shortly archetypes and templates are all about information capture and validation (i.e. which data items, their organisation, and basic constraints for validation). Real world semantics are delegated to terminology (i.e. heart murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I think we need to keep archetypes fairly pure and generic with large scale interoperability in mind. However templates provide all the convenience needed otherwise. I strongly believe we do_not_need another layer of modelling for GUI because referring back to my definition of clinical models, these are to do with information capture and validation...And that's what GUI is tightly coupled with this. Our models are designed for change; indeed this is the very reason we split into multi-levels. So maintaining two different models serving similar purposes is not good modelling design I think. At least that wouldn't work for us with >3000 lines of ADL plus 9 language translations x 10 archetypes and many others...The mode of change has to be together; that is when I am making a change to an archetype or template I must immediately take care of its GUI behaviour. That said, returning back to Ian's suggestion, other directives should probably be incorporated into templates and really hard ones into archetypes. For example we need some means to depict whether a clinical finding (aka core concept) is present or not I had to introduce an extra ELEMENT to each and every node of my MST archetypes. The flavours of null on ELEMENT is not sufficient for that and after all it has to be depicted at CLUSTER level. CoreConcept is also another one, perhaps need an abstract ITEM over CLUSTER and ELEMENT just to provide that semantics. We have studied this core concept stuff in detail and I also have substantial amount of practical experience on this. I must say that we drew the line by referring to Astrid van Ginneken's work - openSDE (from Erasmus Univ). There are REALLY good GUI related stuff there which openEHR can benefit - I have been saying this for long! The key phrase is whether you can talk about absence of something or not - if you can then it is a core concept which needs special attention in modelling. http://opensde.sourceforge.net/ Here is the link to our original paper on the GUI Directives and how we implemented: http://openehr.org/wiki/download/attachments/18513934/Atalag_HINZ2010-Paper.pdf?version=1&modificationDate=1291667587000 This is also another recent paper came out of the same study which mentions about implementation strategy including GUI stuff: http://openehr.org/wiki/download/attachments/18513934/Atalag_1_5.pdf?version=1&modificationDate=1291667587000 Hope stimulates more discussions... Greetings from Auckland :) -koray Skype: atalagk -----Original Message----- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Ian McNicoll Sent: Tuesday, 7 December 2010 1:14 a.m. To: For openEHR technical discussions Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) Hi Olof, I agree but I think there are some directives that are actually not purely GUI directives but which say something meaningful about the underlying information. For instance Koray's directive isCoreConcept (g): "This is an abstract concept; but we can say that Core Concepts are real-world entities which we can talk about their abscence (i.e. a clinical finding, a disease but not tumour grade or physical examination). The directive depicts whether a node with all its children (if any) shall be handled and repeated as a whole in an archetype (i.e. makes sense together such as a clinical finding with other attributes defining its nature). When the node and/or its children are selected, its presence information is stored in the corresponding ELEMENT node which records this (i.e. in MST Findings archetypes [Present?] node)." This seems to me to represent some sort of association between a parent concept and potential children which is independent of any GUI representation. These, I believe, should be considered for inclusion within archetypes/templates. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 6 December 2010 10:36, Olof Torgersson <olof.torgersson at chalmers.se> wrote: > 5 dec 2010 kl. 18.04 skrev Thomas Beale: > > On 05/12/2010 16:49, Tim Cook wrote: > > I personally think it makes it simpler for everyone to think of templates as > only being used for 1. slot-filling 2. removal of unneeded optional data > points and 3. tightening of some leaf value constraints, nearly always coded > terms. If it turns out that data node additions make sense, we will deal > with it when a true need is clear. > > > Returning to the original topic of what should go into a template, I would > say that this statement supports that template should not > contain GUI-directives, but that such information should go into a special > visualization layer? > regards > Olof > > > - thomas > > > <ATT00001..txt> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
