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 -- 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/7dd7fcde/attachment.asc>
