This was an strategy we used in our implementation and it worked very well: associate GUI-hints to archetypes and allow for someone to override the hints on specific templates, if needed.
We decided to do that because, after observing the hints that field specialists associated to the same archetype in different templates, we realized that most of the time the hints were the same and could be reused. So, I agree with your position. Fabiane Thilo Schuler wrote: > The advantage of deriving generic user interfaces only from data > instances and the underlying archetypes (without knowing the template) > is the possibility to edit unknown openEHR data, although the GUI > would be simple. Thus, I agree with Chunlan on the position of a > generic GUIs on Erik's spectrum. > > -Thilo > > On Tue, Jul 1, 2008 at 2:14 AM, Chunlan Ma > <chunlan.ma at oceaninformatics.com> wrote: > >> The Generic User Interfaces, i.e. the GUI_hints that are a bit more towards >> the "left" side of the spectrum described by Eric Sundvall, would be >> archetype specific rather than template specific. I personally think these >> generic GUI-hints should be processed by a generic form engine that >> understands archetypes only. For example, if tobacco use status value is >> "Never used", which is local coded text in the substance_use archetype, the >> "Method" cluster can be hidden from the form. This generic GUI_hint can be >> applied to all templates or user interfaces. A more specific form engine is >> required for context specific user interfaces. >> >> >> >> Cheers, >> >> Chunlan >> >> >>
