GUI means implementation. Software is written for different OS, programming languages, etc. Do you expect the specification to go as far as those implementation issues?
Ogi Pishev ----- Original Message ----- From: <[email protected]> To: <openehr-technical at openehr.org> Sent: Sunday, June 29, 2008 9:00 PM Subject: openEHR-technical Digest, Vol 23, Issue 52 > Send openEHR-technical mailing list submissions to > openehr-technical at openehr.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > or, via email, send a message with subject or body 'help' to > openehr-technical-request at openehr.org > > You can reach the person managing the list at > openehr-technical-owner at openehr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openEHR-technical digest..." > > > Today's Topics: > > 1. Re: GUI-hints in openEHR templates? (Was: PatientOS archetype > to form demo (of sorts)) (Thilo Schuler) > 2. Re: GUI-hints in openEHR templates? (Was: PatientOS archetype > to form demo (of sorts)) (Greg Harris) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 28 Jun 2008 13:38:27 +0200 > From: "Thilo Schuler" <thilo.schuler at gmail.com> > Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype > to form demo (of sorts)) > To: timothywayne.cook at gmail.com, "For openEHR technical discussions" > <openehr-technical at openehr.org> > Message-ID: > <898a84d70806280438s42194336mbaec25697646e5db at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I am with you on that layers are important and keep the approach more > simple in the long time. As Heather pointed out, we have to be very > careful not to distract the clinicians with GUI fluff from clean > modelling. But for review and testing there is no doubt, that a real > GUI is of value. At the moment the Ocean Template Desinger does both > using the "one tool, two artefacts" approach, and as Thomas wrote it > will become better based on the NHS CUI project. The "one tool, two > artefacts" approach is good as it lets clinicians build and adapt > runnable GUIs from their authored templates, but also shows that there > can be many possible GUIs created from one template. > > Having a set of core template tags and several extensions (for > GUI/message/... hints) is more a technical design choice for better > manageability and doesn't interfere with the layers (separation is > done via namespaces). Templates are mostly local artefacts and GUIs > even more so. So, as Rong said, theses markup-extensions will only be > there to ease local implementation. E.g. Ocean could have used such an > extension to create the previously mentioned Hide_in_GUI-Hint in a > clean way separated from the core template model. > > Regarding Greg's comment on problems with the visibility of a certain > field: IMHO openEHR should not try to standardise GUIs (meaning > sharing GUI hints or presentation artefacts). This is a huge task and > we have enough problems solving what we are working on right now. But > I can picture a system that scaffolds a basic editable GUI based on > unknown openEHR data (provided it has access to the underlying > archetypes). This scaffolded view could then be adapted by the local > user, and the next time this user tries to access similar openEHR data > (meaning same archetypes in the same structure/order) the local system > remembers it and the customised view is used to display and edit the > data. Customisation could even go as far as choosing certain GUI > components (per archetype or per aggregated archetypes) from a > (shared!) library... But this is still all implementation specific and > not part of the openEHR specs. > > Cheers, Thilo > > On Fri, Jun 27, 2008 at 6:46 PM, Tim Cook <timothywayne.cook at gmail.com> > wrote: >> >> On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: >>> Very interesting - maybe we could have seperate namespaces for the >>> core tags and extensions. Could be a good compromise! While I see the >>> advantages of keeping GUI stuff out of the template, I also see that >>> this more and more complicated as we add additional abstraction >>> layers. >> >> Ahhh, true. It is complicated. It is the reason why health informatics >> is where it is today. The beauty of the openEHR specs is that each >> portion does one thing well and yet all the parts fit together. >> >> If we get carried away and start mixing the layers then the specs get >> more complex, the tools more difficult to use, applications less likely >> to inter-operate and there won't be very many implementations. >> >> <sarcasm> >> If you aren't careful you could end up with something HL7v3. >> </sarcasm> >> >> As "my buddy" Albert E. said; Make everything as simple as possible but >> no simpler. ;-) >> >> >> --Tim >> >> >> >> >> >> -- >> Timothy Cook, MSc >> Health Informatics Research & Development Services >> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook >> Skype ID == timothy.cook >> ************************************************************** >> *You may get my Public GPG key from popular keyservers or * >> *from this link http://timothywayne.cook.googlepages.com/home* >> ************************************************************** >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > > > ------------------------------ > > Message: 2 > Date: Sat, 28 Jun 2008 11:56:12 -0400 > From: Greg Harris <glharris at panix.com> > Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype > to form demo (of sorts)) > To: openehr-technical at openehr.org > Message-ID: <20080628115612.21330b7b at glh-a.harris-law.org> > Content-Type: text/plain; charset=US-ASCII > > On Fri, 27 Jun 2008 13:46:27 -0300 > Tim Cook <timothywayne.cook at gmail.com> wrote: > >> >> On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: >> > Very interesting - maybe we could have seperate namespaces for the >> > core tags and extensions. Could be a good compromise! While I see >> > the advantages of keeping GUI stuff out of the template, I also see >> > that this more and more complicated as we add additional abstraction >> > layers. >> >> Ahhh, true. It is complicated. It is the reason why health >> informatics is where it is today. The beauty of the openEHR specs is >> that each portion does one thing well and yet all the parts fit >> together. >> >> If we get carried away and start mixing the layers then the specs get >> more complex, the tools more difficult to use, applications less >> likely to inter-operate and there won't be very many implementations. >> >> <sarcasm> >> If you aren't careful you could end up with something HL7v3. >> </sarcasm> >> >> As "my buddy" Albert E. said; Make everything as simple as possible >> but no simpler. ;-) >> >> >> --Tim >> > As counsel for a trade group many years ago, I watched a committee work > long, earnestly, and hard to develop a proposal for a standardized set > of paper forms for claim notices. When that committee subsequently was > asked to review the adequacy of a set of draft EDIFACT messages to > communicate the same information content, they had a very difficult > time separating the information from its presentation. > > They were neither stupid nor uncommitted to the effort; their input > was both indispensable to success and immediately useful for the > developers. But for them, IT was something of a single cloud. It took a > while for them to distinguish between the separate problems of (a) > signing off on inter-company data sufficiency and (b) implementing and > presenting that data on their respective internal systems. And while > these people were volunteers in a sense, getting this done was part of > their jobs and had the full backing of their employers. But if their > input governed the back-end design and development, there would have > been no progress. It was successful (or not) project management to get > their involvement in the right amounts at the right times. > > Without any qualifications whatsoever to offer a judgment on this, I > see a development interplay among three groups: the clinicians, the > developers of the underlying structure, and the designers of > implementing systems. (My guess is that's an obvious and seriously > non-profound observation.) Aside from a long anecdote, it strikes me > that UI decisions should be kept as separate as possible from any of > the underlying structure; that presumption could be rebutted where an > identified UI need can't otherwise be satisfied. Of course, at some > level that's a nullity because the UI needs really define the structure > design. > > As simple as possible can be quite complex. It's amazing what's been > accomplished. > > Greg Harris > > > ------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > End of openEHR-technical Digest, Vol 23, Issue 52 > ************************************************* >
