Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don't remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it'd be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not.
Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:[email protected]] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) 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<mailto: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<mailto: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/20110325/c8089def/attachment.html>
