GUI-directives/hints again (Was: Developing usable GUIs)
Thanks Thile, didn't have this paper before - will read now with much pleasure :) Hong Yul and I had a long discussion yesterday and will prepare a joint response today or tomorrow (well NZ time of course!). Especially Tom has asked whether we have any issues which might need to go into Templates or Archetypes that has to do with the semantics and structure rather than GUI only. We think that we do but need first to define and be able to articulate in plain words. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thilo Schuler Sent: Monday, 13 December 2010 7:20 p.m. To: For openEHR technical discussions Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia Cheers, Thilo After that Helma, her supervisor, Rong and I published a very future-oriented paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum about sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989 it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML with a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/ac01db6d/attachment.html
CUI discussions and CURIO project
* * Over the past year, UCL CHIME has been running a small joint project with the NHS Data Standards and Products Group in the UK, to deliver open source implementations of some key components of the NHS Common User Interface (CUI) specifications. Named CURIO, this very practically focused project has allowed us to gain insight into generic and cutting edge UI requirements for delivery of capable clinical information systems. The outputs from the CURIO project will be made publicly available, and we believe that having open source UI layer implementations will help implementers explore the challenges of UI functionality in clinical information systems. The NHS has arranged a small closed workshop on January 12th where the work will be demonstrated and discussed. After this, we expect to be given clearance to publish links to both the technology assessment document (about 100 pages) and the proof of concept open source widgets which have been written, demonstrating the NHS Drugs and Medicines list CUI controls, linked with a NHS DM+D database, and the single term SNOMED searching tool CUI control, which will be demonstrated alongside the Opereffa implementation of the LexEVS terminology server. Other current projects at CHIME, such as the open source clinical application development framework, Opereffa, will incorporate both the technology and feedback from the CURIO project, with the goal of improving a growing set of *open*EHR-based clinical systems implementations. We hope that the outputs from the CURIO project will make a useful contribution to the *open*EHR community, by demonstrating the kinds of functionality that the NHS CUI analysis has identified. We believe that the challenges identified in supporting a UI centric approach to applications development, alongside an EHR centric approach, may stimulate some interesting and fruitful discussions. We will post a separate technical note about the progress and future of Opereffa since it was released a year ago and introduce a new and related project known as Project Bosphorus. Opereffa has had some 750+ downloads in 79 countries, notably from the USA. We received useful feedback from software vendors, researchers and clinicians, which led to significantly changed design, and we are hoping to release new versions incorporating these changes in the first half of 2011. We are hoping that the upcoming releases will allow more parties to explore and use openEHR. Seref Arikan and David Ingram -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/bee6a533/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 10/12/2010 08:49, Erik Sundvall wrote: Hi! A very interesting discussion, thanks to everybody here! Great with all references too! On Wed, Dec 8, 2010 at 16:26, pablo pazos pazospablo at hotmail.com mailto:pazospablo at hotmail.com wrote: Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. Or perhaps GUI focused templates and Structurally focused templates (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] all correct up to here ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools On Wed, Dec 8, 2010 at 15:55, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: you have two choices: * A) mix it in with the languages architectural layers you already have * B) create a dedicated layer or component type, and possibly dedicated formalism if needed I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. I agree - we don't yet have a clear list of the GUi semantics that would need to be in a UI template... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz mailto:k.atalag at auckland.ac.nz wrote: 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. Koray, what makes you exclude yourself from the core group? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official core that is busy prioritizing other important explorations. Whatever that core is I believe it will be actively involved in, and appreciate, the discussions. Erik, is right. There is no special 'core group' like in the old days - these days, it is whoever is here. In terms of ADL/AOM 1.5 specs, I will simply take into account any requirements that are clearly enough documented for me to understand... - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/60c3b1b6/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] all correct up to here ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)Level 2: structural templates (for localized use of archetypes, general and specialized templates)Level 3: define the use of the structural templatesGUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. Cheers, -Pablo. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/13dec05e/attachment.html
