More expressivity needed
Hi All, I have a use case which I am having quite hard time to model. The thing is in fact very simple to express with a tabular list, spreadsheet or XML - which we do not fancy much because ADL is claimed to have much more expressive power (well in general yes)! Here is the use-case: A CLUSTER archetype for depicting the anatomical sites of a finding for a given organ. The clinical domain is digestive endoscopy but this applies to others I think. So we have an _organ, then list of sites and a list of modifiers_ which further specify a particular site. The simple modelling strategy to model each organ with an ELEMENT and then putting sites as values might work given that these modifiers can be expressed in the archetype separately and tell the application to combine these during runtime. Another option is of course using terminology service to get the proper semantics (i.e. post-coordination and subsets) - but this is not an option in my case and I must stick with local codes. I talking about 5-10 sites per organ so it does not make sense to use terminology service. Also you can say that this can further be specified by templates - true but why not putting such simple constraints at the archetype level - if we say that archetypes represent discrete clinical concepts for reuse then we should do it at archetype level. And here is a worse version of the use-case: _a given set of modifiers_ apply to certain - _not all sites_ for a given organ. For example the modifiers anterior wall, posterior wall applies to fundus and body sites (of stomach) Finally here is the nightmare version: _a different set of modifiers_ apply to _different _and _not all sites_ for a given organ. For example the modifiers Lower third, Middle third applies to Main duct site of pancreas and the modifiers Left intrahepatic branches, Right intrahepatic branches apply to Liver ducts of pancreas. Of course a (non-elegant) modelling strategy would be to make each site as an ELEMENT and then the set of modifiers for each and every one of them as values. Then this might be problematic during GUI design and also during querying. Here is what I suggest: add a feature in which some attributes can be specified for values of leaf nodes, like XML. I know this would result in dramatic changes in RM and tools (and existing implementations) but the sooner the better if you think this is useful. Cheers, -koray -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz __ Information from ESET NOD32 Antivirus, version of virus signature database 4265 (20090721) __ 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/20090722/63a8da04/attachment.html
Issues around UI technologies and bindings to back end
Hi Gavin, Thanks for the input, Now, to see a little bit more, please visit http://www.mscui.net/PatientJourneyDemonstrator/ Omer Hotomaroglu notified me of this some time ago, and I guess everyting here is not in CUI specs yet, but this is a much better demonstration of how GUI specialization can end up. Of course I'm not a clinician, but assuming MS has someone telling them that clinicians would be happy with this, I'm focusing on the functionality. As you've said it is about interactions between UI controls, and if you check this page you'll see that layout related capabilities are also important, I'll write about the in the wiki in detail, but the link above shows that making use of every UI capability is useful, actually, I've written about this in my blog some time ago : http://www.serefarikan.com/?p=42 The problem, especialy with these specific controls is, what will we do when a widget binds to multiple models? or there is an overlap between two models, which are used by two widgets on the same UI? I have reason to believe that our binding approaches are a little bit naive at this point, and I'd be satisfied when I can bind GUIs like in the Patient Journey Demonstrator to openEHR back end. Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply leave certain things out of the specifications. Templates may have some space in them where you can act naughty? Like the Z segment of HL7 V2, a redlight district where everyone visits every once in a while, but does not mention so much.. I've never heard about Orbeon, and I'll be taking a good look at it, if it looks handy, I can simply add a link to it from Opereffa, to see how things will shape up. Thanks again for the input, and the useful discussion. Kind regards Seref On Tue, Jul 21, 2009 at 6:05 PM, gjb gjb at crs4.it wrote: Hi Seref, Seref Arikan wrote: I've written an initial set of things here : http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation . based on Opereffa, but I'd really like to hear how others are tackling UI layer. I'm a little bit worried since I can see MS CUI ... I had a look at these Silverlight controls - such as http://www.mscui.net/Components/SingleConceptMatching.aspx etc - perhaps I missed something, but I can't see anything greatly different from what a Luddite like me might achieve with XHTML-like select, check-boxes etc. Complexity grows, in any case, when one considers screens where one data-value (e.g. drop-down list) should vary in accordance with another control's value (e.g. another list's item). I am not even sure how openEHR archetypes fully allow such co-occurrence constraints to be defined - I guess I'd try using invariant rules. This isn't just a case of panels/containers being present/visible or not - as archetype-slot toggling ought to be able to handle. If we assume that detailed co-occurrence variations can be declared as ASL invariant rules then - IMHO - it makes sense to take that declarative approach down to the GUI level and interpret such rules at data entry. This is what xForms was supposed to be designed to do (using it's bind declarations) - but the majority opinion of openEHR developer is that xForms are dead in the water - and we should instead instantiate object-oriented widgets to implement our GUIs. I am not so convinced - I've played with the Orbeon xForms server http://www.orbeon.com/ which embeds the eXist xml-db an I am quite impressed just how far you can get in modern browsers without writing javascript or requiring plugins. XML in XML out. It's nice to be web-based/RESTful since it gives you so much for free. It would be nice to implement a demo that compiles-down ADL to a form Orbeon can serve - but, as I noted earlier, this is not a main-line idea here: for one thing it mostly throws out the O from the AOM. Good work with Opereffa Gavin Brelstaff CRS4 Sardinia Italy. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090722/f11abdbc/attachment.html
Issues around UI technologies and bindings to back end
Seref Arikan said the following on 22/7/09 11:39: Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply Hi, I must confess I've only half followed this discussion due to time constraints, but this remark comes very close to my findings in a paper I've written on this topic, which is now available as epub: Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye. van der Linden H, Austin T, Talmon J. Comput Methods Programs Biomed. 2009 Sep;95(3):213-26. Epub 2009 Apr 15. http://www.ncbi.nlm.nih.gov/pubmed/19368989 Re Orbeon: I think that's a nice start. Should dive into it more in the near future. With regards, Helma van der Linden
Issues around UI technologies and bindings to back end
Thanks Helma, Very interesting feedback. Considering one of the authors, Tony Austin, is in the next room, and here I am hearing about this work from you :) Kind regards Seref On Wed, Jul 22, 2009 at 2:16 PM, hepabolu hepabolu at gmail.com wrote: Seref Arikan said the following on 22/7/09 11:39: Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply Hi, I must confess I've only half followed this discussion due to time constraints, but this remark comes very close to my findings in a paper I've written on this topic, which is now available as epub: Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye. van der Linden H, Austin T, Talmon J. Comput Methods Programs Biomed. 2009 Sep;95(3):213-26. Epub 2009 Apr 15. http://www.ncbi.nlm.nih.gov/pubmed/19368989 Re Orbeon: I think that's a nice start. Should dive into it more in the near future. With regards, Helma van der Linden ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090722/116aeeb6/attachment.html
