Hi!

Yesterday I asked if anybody had any motivated objections to using the
openEHR template formalism as a layer to catch some GUI-hints/rules. I bring
it up again to get some response :-)

The point to have separate concerns in separate artifacts is often good.
Regarding GUI-hints it seems reasonable to not have them at the clinical
archetype level, and in some cases not at a first clinically focused
template level either. But, as we have discussed earlier, through
specialisation and/or inclusion it's possible to have several layers of
openEHR templates.

This means that ADL or some other serialisation format of the archetype
object model (that now will include templates) can be used for GUI-related
annotations and GUI-related logic in some form. Does anybody have concerns
or worries regarding this?

You could still have separate artifacts by splitting reusable clinical
modeling and use case specific GUI modeling in separate layers of
templates.

A nice thing with reusing the template formalism for catching GUI stuff is
that shared tools and understanding is already in place as opposed to
inventing some new purely GUI-related formalism. Also in some cases it's
likely that the same groups that are designing archetypes and clinically
focused templates will have knowledge of some use cases in which they know
what they'd want to happen on the GUI side. Then it would be nice to be able
to reuse people, tools, template governance repositories etc.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

P.s. (off topic)
I'm not sure it's always optimal to split everything into separate
artifacts, especially when it comes boundary problems like terminology
bindings. You could argue that the binding should be done in a separate
artifact that is neither part of archetypes nor part of terminologies, but
I'm not sure that would always make things better. Having the bindings in
the archetype forces the archetype authors to revise the bindings at the
same time as they revise an archetype and that might be good.

On the other hand you could argue that a SNOMED CT refset might be exactly
such a third artifact that can be used for managing bindings. But if you
would have three different groups maintaining archetypes, refsets and
terminology systems then you'd better keep them very well aware of each
other's actions...

On Wed, Mar 23, 2011 at 21:09, pablo pazos <pazospablo at hotmail.com> wrote:

>  I agree with Thomas, in order to have a clean design we need to separate
> the concerns of our artifacts. If we have a solid base to our complete
> clinical data structures like Archetypes, we can define other "upper layer"
> artifacts to model rules, conditions, gui directives, etc.
>
> I like this approach because we can solve one problem at a time, instead of
> having a messy one-fits-all solution.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110324/63e8fc42/attachment.html>

Reply via email to