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> 
> 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

Reply via email to