That's a good starting point. Here is our effort to make usable GUI templates: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates This is developed, documented and working ok.
-- 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 > From: yampeku at gmail.com > Date: Fri, 25 Mar 2011 14:32:41 +0900 > Subject: Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) > To: openehr-technical at openehr.org > > Maybe we could use as inspiration all the available XML to GUI efforts > that already exist. Mostly to avoid reinventing the wheel > > 2011/3/25 pablo pazos <pazospablo at hotmail.com>: > > Hi Koray, > > > > I think we are the core group, and if we can agree some basic notation of > > some basic GUI directives (there are some thoughts of mine on the wiki: > > http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) > > and can implement them in a consistent way (we all use heterogeneous > > technologies), we can lead the definition and improvement of this inside the > > standard. > > > > We have to options: 1. keep waiting for some "signal", 2. think outside the > > box and take the lead. > > > > Any one who want #2 and have time to work can drop me a line to coordinate > > the required work, share experiences and colaborate on this subject. > > > > -- > > 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 > > > > > > > > ________________________________ > > From: k.atalag at auckland.ac.nz > > To: openehr-technical at openehr.org > > Date: Fri, 25 Mar 2011 16:05:22 +1300 > > Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) > > > > 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:openehr-technical-bounces at openehr.org] 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 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 > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > _______________________________________________ > 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/20110325/1cf6765f/attachment.html>
