GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
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 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. > > > If you aren't careful you could end up with something HL7v3. > > > 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 > >
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
On Fri, 27 Jun 2008 13:46:27 -0300 Tim Cook 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. > > > If you aren't careful you could end up with something HL7v3. > > > 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
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
J.P. Freriks wrote: > > Or, another tool could be designed for GUI design. The clinicians will > work with this tool, after which Template designers distil the semantics > for the templates. > > *I think it will be one tool that writes two artefacts, one of which is GUI 'hints'. However, there are more semantic indicators being built into the template designer, some based on the NHS CUI project, that will provide good hints on GUI generation, including some temporal workflow aspects. - thomas beale *
