I have explored and think that it is a great idea to use the UK CUI. However, it is tied to a Microsoft EULA that renders it useless.

"PERSONAL AND NON-COMMERCIAL USE LIMITATION.

Unless otherwise specified, the Services are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell any information, software, products or services obtained from the Services. "

This is only a SMALL part of the EULA.

The YUI is at least BSD licensed. I wonder why there are the language differences noted here? The UI should be (in fact must be) totally language independent.

I haven't evaluated the YUI at all and I expect to ask experts in the field to weigh in on this. It is at least a starting point that can be readily shared. Maybe the CfH project should reconsider their choice of "standards"?

Some account needs to be made for the different between the capture/input approach and the data viewing/display approach. Sometimes it is not sensible or desirable to use the same screens - data display can be a lot more compact and efficient than data capture.

I think , unfortunately, UI depends on language and culture. We are often troubled in translating English to Japanese. Font glyph and syntax changes UI significantly. Although both "Ninja attacked Samurai" and "忍者が侍を攻撃した" have almostly same meanings, each sentense has different impact. Date time view is quite different in its culture. These are same date "Nov/27, 2007", "20071127", "2007年11月27日", and "平成19年11月27日"

We sometimes adjust not only UI widgets but also controlers which control the UI.

Great the UIs as the only visible and therefore very important part of an EHR are brought up here! 

I like the distinction between data display and data entry and regard them as different views on the same data. I also like the described layered approach for widgets: low-level openEHR data type and RM class organisational widgets that can be (usually automatically) assembled according to any openEHR data; versus higher-level (archetype or even template level) complex widgets that are more or less specialized and used for certain purposes. For some archetypes there will probably exist a number of complex widgets and the GUI designer or the user (even at runtime!) chooses the most appropriate one. This is one important mechanism to achieve customisation and adaptation to the local/personal workflow.

In our almost two years old paper (Schuler T, Garde S, Heard S, Beale T. Towards automatically generating graphical user interfaces from openEHR archetypes. Stud Health Technol Inform. 2006;124:221-6.) we wrote down similar thoughts. I am glad that openEHR has come to a stage where GUIs are an issue for real implementations. 

However, regarding the above wiki page I think we should clearly distinguish between general openEHR UI design/architectural recommendations (normally fairly technology independant!) and implementations of them. The reference to XSLT in the "Display of data" section and web forms (can mean many things from simple HTML forms +/- Ajax to Xforms or other declarative UI languages) & PHP (a server-side technology to - besides others - produce and process web forms) mentioned in the section "Other approaches", should be described as implementations of general openEHR UI principles. Building on past experience (see paper mentioned above), several conversations at Medinfo 2007 and a read up on XForms I envision an XForms based GUI using openEHR archetypes.

I hope the Java Project (including me!) manages to set up a prototype sometime in 2008 (probably using www.orbeon.com). Similar to the recently mentioned TDS (see http://www.openehr.org/mailarchives/openehr-technical/msg03116.html), which Ocean generates from templates, the XForms model (XForms implements the MVC design pattern) should be able to be generated as well. As many constraints as possible should be expressed with native XForms methods. For the remaining ones an XForms openEHR extension in a separate namespace could be created. For this model several MVC views can be (semi-)automatically generated or manually created by a GUI designer. Since XForms is a W3C standard such a system can be build on several existing XForms engines: server-based (like www.orbeon.com) or client-based (like www.formsplayer.com or Mozilla XForms). Customisation could be achieved through CSS (mostly visual) and XBL (also functional e.g. to create archetype level widgets). Obviously to validate against as many constraints as possible on the client-side, the existing XForms engines need to be able to process the above mentioned openEHR-specific XForms extensions. But even if the engine hasn't been extended it can still use the unextended part of the XForms model. If the produced data instance is invalid this will be picked up at the final (usually kernel based) check before committal. 

Puhhh, this was a lot of information and probably slightly incomprehensible. I will try to amend the above wiki page (separate general openEHR UI recommendations and implementations of them) and add a link to a child page about the XForms ideas in the next time.

Cheers, Thilo

Here at Linköping University (Sweden) we have a master thesis project (by Carl Alfon) running regarding input GUI for openEHR. xForms are currently generated from ADL via the openEHR java ADL parser supplemented by custom code (with knowledge about RM). We'll post more information about this project later.

Regarding GUIs for viewing openEHR-based data some of you might also be aware of our prototyping environment using/abusing Google Earth for overviews and navigation (seehttp://www.openehr.org/publications/health_ict/MedInfo2007-graphicalEHR-Sundvall.pdf). Hope to write more regarding that later on this wikipage.

// Erik

I am particularly interested in the development of UIs from openEHR and I implemented the approach that we (in Ocean) use for producing GUIs from openEHR templates.

I reckon that using Templates for the generation of the GUI is going to be more useful than generating from archetypes.  The reason being that its unlikely that all of an archetype is going to be used for any given use case.  A good example of this is a blood pressure, where if you generated a gui from the pure adl, then you would have something amazingly unwieldy.

 The other issue for me is that generating forms is all very well, but will never replace the need for someone who understands workflow for a clinical application to design a good user interface.  Gadgets and widgets can help but won't be able to replace this.

@Erik&Carl, Adam, Hugh

It seems that we have all chosen (at least partly) XForms as the technology for openEHR GUIs. Due to this common choice an OSS effort - as Adam suggested on the list - would make a lot of sense to share ideas and code. As XForms is a standard we don't necessarily have to use the same implementation (or XForms engine).

Regarding Hugh's comment: Yes totally agree! Good GUI design is crucial for efficient workflows and happy doctors. That's why the idea of customisation is so important. A fully generically generated GUI would be the starting point for it. In most cases the end users (health workers) won't do that by themselves.
I always had templates in mind to generate forms as one archetype usually doesn't cover a whole form and contains many unused parts if applied in a certain context (maximum datasets!). Templates can be seen as further constrained archetype aggregations and therefore follow the same rules and general structure as archetypes. Technically (regardin GUI generation) there is not much difference.

I think that XForms is good technology for implementing openEHR  GUI. Now, Nerosoft company prepared XForms solution as XForms Composite Aplication Patform (XCAF)"  for implementation GUI based on taxonomy ( for example: XBRL, ADL). In his solution there is Visual Editor for constructin tamplets based on defined components. When we generated XFORM from taxonomy(archetype) we should have change presentation layer.  We can generate logical layer but only default presentation layer. Presentation layer should be coreccted by Visual Editor. In this solution will be integrated BPM engine to implement "work flow"  in apllication.  XForms server will cooperate with BPM engine, BPM engine will runing proceses and  XForms server will runing "intelligent documents". XForms server will implement openEHR Repository via universal conector based on XDAD specyfication ( XML Data Access Definition).

Described abowe architecture was veryfied in the banking solution where XForms was generated from XBRL taxonomy and "work flow" was deploed in BPM engine (Fujitsu). In that case we use to visual editors  one (BPM) for "work flow" desining and enather (XFORMS) for forms desining.

Wladyslaw Weglarz (Nerosoft)
I think that XForms is good technology for implementing openEHR  GUI. Now, Nerosoft company prepared XForms solution as XForms Composite Aplication Patform (XCAF)"  for implementation GUI based on taxonomy ( for example: XBRL, ADL). In his solution there is Visual Editor for constructin tamplets based on defined components. When we generated XFORM from taxonomy(archetype) we should have change presentation layer.  We can generate logical layer but only default presentation layer. Presentation layer should be coreccted by Visual Editor. In this solution will be integrated BPM engine to implement "work flow"  in apllication.  XForms server will cooperate with BPM engine, BPM engine will runing proceses and  XForms server will runing "intelligent documents". XForms server will implement openEHR Repository via universal conector based on XDAD specyfication ( XML Data Access Definition).

Described abowe architecture was veryfied in the banking solution where XForms was generated from XBRL taxonomy and "work flow" was deploed in BPM engine (Fujitsu). In that case we use to visual editors  one (BPM) for "work flow" desining and enather (XFORMS) for forms desining.

wladyslaw.weglarz@nerosoft.pl