I am with you on that layers are important and keep the approach more simple in the long time. As Heather pointed out, we have to be very careful not to distract the clinicians with GUI fluff from clean modelling. But for review and testing there is no doubt, that a real GUI is of value. At the moment the Ocean Template Desinger does both using the "one tool, two artefacts" approach, and as Thomas wrote it will become better based on the NHS CUI project. The "one tool, two artefacts" approach is good as it lets clinicians build and adapt runnable GUIs from their authored templates, but also shows that there can be many possible GUIs created from one template.
Having a set of core template tags and several extensions (for GUI/message/... hints) is more a technical design choice for better manageability and doesn't interfere with the layers (separation is done via namespaces). Templates are mostly local artefacts and GUIs even more so. So, as Rong said, theses markup-extensions will only be there to ease local implementation. E.g. Ocean could have used such an extension to create the previously mentioned Hide_in_GUI-Hint in a clean way separated from the core template model. Regarding Greg's comment on problems with the visibility of a certain field: IMHO openEHR should not try to standardise GUIs (meaning sharing GUI hints or presentation artefacts). This is a huge task and we have enough problems solving what we are working on right now. But I can picture a system that scaffolds a basic editable GUI based on unknown openEHR data (provided it has access to the underlying archetypes). This scaffolded view could then be adapted by the local user, and the next time this user tries to access similar openEHR data (meaning same archetypes in the same structure/order) the local system remembers it and the customised view is used to display and edit the data. Customisation could even go as far as choosing certain GUI components (per archetype or per aggregated archetypes) from a (shared!) library... But this is still all implementation specific and not part of the openEHR specs. Cheers, Thilo On Fri, Jun 27, 2008 at 6:46 PM, Tim Cook <timothywayne.cook at gmail.com> wrote: > > On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: >> Very interesting - maybe we could have seperate namespaces for the >> core tags and extensions. Could be a good compromise! While I see the >> advantages of keeping GUI stuff out of the template, I also see that >> this more and more complicated as we add additional abstraction >> layers. > > Ahhh, true. It is complicated. It is the reason why health informatics > is where it is today. The beauty of the openEHR specs is that each > portion does one thing well and yet all the parts fit together. > > If we get carried away and start mixing the layers then the specs get > more complex, the tools more difficult to use, applications less likely > to inter-operate and there won't be very many implementations. > > <sarcasm> > If you aren't careful you could end up with something HL7v3. > </sarcasm> > > As "my buddy" Albert E. said; Make everything as simple as possible but > no simpler. ;-) > > > --Tim > > > > > > -- > 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* > ************************************************************** > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
