Hi Richard, Are you talking about a tool that can read one or more templates and then aide in development of a GUI that will meet the Common User Interface specification?
That, I think, is a worthwhile approach. While it is another layer. It does help keep the templates simple and purposeful on a semantic level. --Tim On Fri, 2008-06-27 at 10:51 +0100, Richard Kavanagh (NHS Connecting for Health) wrote: > 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-bounces at 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 > ********************************************************************** > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/b5b706d2/attachment.asc>
