Within the NHS in the UK we are experiencing a similar need. We wish to be able to define the "visual" presentation of a given template so that it can be ( in our case ) rendered in a format that is sensible for end-user review. The current experiences we have when clinicians review the HTML rendered templates are not productive. There is too much discussion on the aesthetics of the "form" rather than the actual content.
We are currently considering using a process of applying a "style" to a template. This would allow the visual aspects of each data point to be controlled ( i.e. screen position, control type i.e. checkbox, combo box etc ). It would be great to see what requirements others in the community might need for such a "tool". We are likely to commission the creation of a tool in the near future. regards Richard Kavanagh Interoperability Development Manager NHS Connecting for Health Richard.Kavanagh at nhs.net www.connectingforhealth.nhs.uk NHS Connecting for Health supports the NHS in providing better, safer care by delivering computer systems and services which improve the way patient information is stored and accessed. -----Original Message----- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde Sent: 27 June 2008 10:31 To: openehr-technical at openehr.org Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to formdemo (of sorts)) Hi all, in my opinion it is i) important to have some form of "GUI layout descriptions" that really enable smart GUI generation in the long run. If not, the whole automatic process stops just before the GUI, which is not really the best we can do in the long run I think. ii) However, it is important to keep this separate from templates. For example, to be able to display what is in a template on different devices ranging from normal to computers via PDAs to potentially your mobile phone, different GUI principles may apply. So essentially to me this sound like it is 1 template to n "GUI layout descriptions". Regards Sebastian J.P. Freriks wrote: > Hi all, > > I think that Eric has a point. I had the same experience when > designing a template. I had thoughts about functions in the GUI that I > couldn't save together with the template. > IMveryHO, the suggestions about how clinicians want the actual GUI to > look and work when they are designing their templates should be > accommodated for. > > Just some thoughts: > > It is not easy to distinguish between just semantics (the template) > and the GUI, which is after all all clinicians have to work with in > clinical practice. > Perhaps clinicians will only want to speak about what informations > needs to be presented how, where and when? Perhaps they don't care > about the difference between semantics and workflow, GUI, etc.? > Anyway, it is intuitive to discuss this in one and the same session. > > The suggestions for workflow or the GUI could be in the form of hints > for auto-generation of the GUI, or just text comments for the human > GUI designer. > Maybe the template designer can have a layer for non-semantic > information linked to points in the template intended for GUI > designers, that will not end up in the actual template definitions? > > Or, another tool could be designed for GUI design. The clinicians will > work with this tool, after which Template designers distil the > semantics for the templates. > > As I said, just some ideas. > > Josina Freriks > > > Tim Cook schreef: >> These are certainly implementation specific issues and IMHO should >> (must) be left there. >> >> >> --Tim >> >> >> >> >> On Fri, 2008-06-27 at 09:05 +0100, Ian McNicoll wrote: >> >>> Hi Eric, >>> >>> Good points. >>> >>> As you know, the NHS use of openEHR to date has been to specify >>> clinical content for the iSoft Lorenzo product, particularly for a >>> number of user-specified forms. One of the areas of difficulty has >>> been the tension between keeping the Template as a description of >>> use-case data content and the requirement to match the UI of the >>> end-user form, both for cross-checking by the users and for the >>> application designers. We found that there is a limit to the extent >>> that this can be done without compromising the quality of the >>> template and underlying archetypes. >>> >>> There is a clear need for some UI rendering suggestions/rules but >>> current thinking is that is best left to another layer of >>> documentation, rather than including it within the Template spec. We >>> did experiment with some 'dummy' UI instruction archetypes but this >>> remains somewhat clumsy. >>> >>> There are a couple of exceptions which through current Ocean use are >>> within the Template Spec >>> >>> 1. 'Hide from UI' is used, very specifically to hide intermediate >>> branch nodes from HTML and Ocean forms representations of the >>> Template. >>> >>> e.g >>> >>> Patient Details >>> Name >>> Structured Name >>> Surname >>> >>> >>> is flattened to >>> >>> Patient Details >>> Surname >>> >>> in the HTML and Ocean forms output. >>> >>> >>> 2. Conditional visiblilty. As you suggest, this can become highly >>> complex but there are some simple, universal conditionals which >>> should be true for all instances e.g Only display if the patient is >>> female, or over a certain age. The latest version of the Ocean >>> Template Editor supports this feature but it is not designed to deal >>> with complex interaction between data and UI, which starts to >>> encroach on decision/ workflow support, or with other 'static' >>> UIrendering advice,like "only display if button x is pressed" - this >>> is probably best left to a higher layer. >>> >>> A further discussion of the possible requirements for supra-Template >>> UI rendering would be very helpful. >>> >>> Ian >>> >>> >>> Dr Ian McNicoll >>> office / fax +44(0)141 560 4657 >>> mobile +44 (0)775 209 7859 >>> skype ianmcnicoll >>> >>> Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com >>> Consultant - IRIS GP Accounts >>> >>> Member of BCS Primary Health Care Specialist Group - www.phcsg.org >>> >>> >>> 2008/6/27 Erik Sundvall <erisu at imt.liu.se>: >>> >>>> Hi! >>>> >>>> On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote: >>>> >>>>> Thanks to the java reference implementation I have a demo of >>>>> importing archetypes to auto generate forms which have the >>>>> references to the archetype. >>>>> >>>> Nice. Keep up the good work. >>>> >>>> On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote: >>>> >>>>> One thing I noticed in the conversion that I don't have any way of >>>>> distinguishing between a line of text and multiline text in the >>>>> archetype (I would generate an appropriate pane in the latter case). >>>>> Perhaps not a big deal. >>>>> >>>> This might be a useful requirement for the current template >>>> specification currently being worked on, or possibly a new kind of >>>> related specification. >>>> >>>> I first thought that templates so far had been considered as purely >>>> specifying semantics and that they were not supposed to give hints >>>> regarding GUI rendering. But now I see a parameter "hide_in_ui" in >>>> the class T_COMPLEX_OBJECT found in the draft template >>>> specification. (A similar function is present in the Template >>>> Designer tool from Ocean Informatics there is an option to "hide" >>>> elements instead of constraining them to zero occurrence, in the >>>> output file this is persisted as hide_on_form="true".) Could >>>> anybody detail it's intended use a bit more? >>>> >>>> I think GUI rendering hints can be appropriate to specify at the >>>> same point in time as template design is taking place. If the hints >>>> are to be persisted in the template file or in a separate file I >>>> guess could be discussed, keeping it in the file could have >>>> maintenance advantages, but probably has some disadvantages too. >>>> Thoughts? (And no, GUI hints are not appropriate in Archetypes >>>> since they are meant to have a wider reuse and the use cases are >>>> not known in the same detail as for templates.) >>>> >>>> In some of our implementation experiments and in discussions with >>>> clinicians a possible need for specifying detail levels in >>>> templates have surfaced. Some elements from archetypes are easy to >>>> completely dismiss or include for the specific use case in mind >>>> when designing a template clinicians will say things like "this will always be needed" >>>> or "this will never be needed". Other things could be conditional >>>> and trickier "you can't have all these details om the form - users >>>> would go crazy - let them show up if i click a plus-button or if i >>>> tick value x was true". >>>> >>>> The requirement to use GUI screen area optimally is even more >>>> pressing when using small input devices such as PDAs. >>>> >>>> If there was some way of specifying detail level in the template >>>> perhaps using a simple integer (0=default, 1..n=deeper detail with >>>> increasing number) then the same template could better support >>>> automated or semi-automated design of entry forms different screen >>>> sizes etc. One naive/simple but useful way of using the integer >>>> could be to add a "plus-button" for things with detail level 1 and >>>> within that subform have further plus buttons for level 2 and so on. >>>> >>>> The "conditional" requirements are trickier and probably needs >>>> more experimentation and evaluation than can be allowed if a first >>>> template specification should be completed and released within >>>> reasonable time (we all want that). The conditions might also in >>>> some cases better be specified in decision support or workflow >>>> than in templates. Also a look at the previous work with gradually >>>> expanding forms in Clinergy/Pen&Pad should be considered, I believe >>>> they were partly auto generated from ontologies. >>>> >>>> Thoughts? >>>> >>>> Best regards, >>>> Erik Sundvall >>>> erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 __________ >>> 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 _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ********************************************************************** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail **********************************************************************
