Hi Erik, In the past months we have talked about the scope of each artifact. One thing that is clear is that we can have structural templates and GUI templates, that can be defined, shared and used separately, but GUI templates can rely on structural templates, as structural templates rely on archetypes.
Here is a reference to the discussion: http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/2011-January/005787.html -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 24 Mar 2011 09:05:49 +0100 Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) From: [email protected] To: openehr-technical at openehr.org 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. _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110324/e3937741/attachment.html>
