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