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
>
