GUI-directives/hints again (Was: Developing usable GUIs)

[Koray_Atalag]

Hi Ian, others

We've had a bit of discussion on this at Medinfo and that you pointed to separation of pure GUI stuff from others where there is an inherent relationship with the semantics and structure of information - fully agree.
The question is how to do that and when; i.e. the process. I think the time is just about right as implementations start and progress rapidly. As to how I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us.

As Ian pointed out we have some 10 directives, which turned out to be all generic (i.e. not specific to our endoscopy application) which is great. The isCoreConcept directive really is a special one which deeply involves semantics and structure of the clinical information being modelled. Rest of the directives are not so much like this but there is an obvious need to separate. The mantra of openEHR modelling says that anything that has to do with structure and semantics goes into clinical models. Then which models? I think we must first make clear what we are talking about: out of models or within models and then Archetypes or Templates.

For us this was a no brainer because I think ALL pure GUI stuff should go to Templates. I have explained my reasoning in a previous message but shortly archetypes and templates are all about information capture and validation (i.e. which data items, their organisation, and basic constraints for validation). Real world semantics are delegated to terminology (i.e. heart murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I think we need to keep archetypes fairly pure and generic with large scale interoperability in mind. However templates provide all the convenience needed otherwise.

I strongly believe we do_not_need another layer of modelling for GUI because referring back to my definition of clinical models, these are to do with information capture and validation...And that's what GUI is tightly coupled with this. Our models are designed for change; indeed this is the very reason we split into multi-levels. So maintaining two different models serving similar purposes is not good modelling design I think. At least that wouldn't work for us with >3000 lines of ADL plus 9 language translations x 10 archetypes and many others...The mode of change has to be together; that is when I am making a change to an archetype or template I must immediately take care of its GUI behaviour.

That said, returning back to Ian's suggestion, other directives should probably be incorporated into templates and really hard ones into archetypes. For example we need some means to depict whether a clinical finding (aka core concept) is present or not I had to introduce an extra ELEMENT to each and every node of my MST archetypes. The flavours of null on ELEMENT is not sufficient for that and after all it has to be depicted at CLUSTER level. CoreConcept is also another one, perhaps need an abstract ITEM over CLUSTER and ELEMENT just to provide that semantics. We have studied this core concept stuff in detail and I also have substantial amount of practical experience on this. I must say that we drew the line by referring to Astrid van Ginneken's work - openSDE (from Erasmus Univ). There are REALLY good GUI related stuff there which openEHR can benefit - I have been saying this for long! The key phrase is whether you can talk about absence of something or not - if you can then it is a core concept which needs special attention in modelling.

http://opensde.sourceforge.net/

Here is the link to our original paper on the GUI Directives and how we implemented:
http://openehr.org/wiki/download/attachments/18513934/Atalag_HINZ2010-Paper.pdf?version=1&modificationDate=1291667587000

This is also another recent paper came out of the same study which mentions about implementation strategy including GUI stuff:
http://openehr.org/wiki/download/attachments/18513934/Atalag_1_5.pdf?version=1&modificationDate=1291667587000

Hope stimulates more discussions...

Greetings from Auckland

-koray

Skype: atalagk

[thomas.beale]

Only one problem with this reasoning: templates are often used for things other than the GUI, e.g. messages. In the future, they will end up being used for reports as well. In general, I believe the openEHR template will be an artefact defining a specific data set (including optionality where needed), and auxiliary artefacts will always be needed to connect that definition to its target technology: a specific kind of GUI form, message infrastructure or relational mapping or querying environment

• thomas

[ian.mcnicoll]

Hi Koray,

I agree with Thomas here, Koray, but I take your point about the
separation into a further layer represents added potential development
complexity. I think we should expect tools to handle this in the same
way that a complex development environment like Visual Studio handles
various layers of application 'code' and resources within a seamless
environment. You should not have to think about these separate layers
during development.

Your comments about 'isCoreConcept' are very interesting because I
think you have touched upon an issue in semantics that we are coming
across, particularly when modelling detailed clinical findings. I had
been thinking about the same issue from a different angle, essentially
how to cleanly model findings where the requirement might expand
gradually from a Y/N response to a full blown complex structure, in
different clinical contexts and over time as more detailed
requirements emerge. It touches upon the crucial areas of integration
with SNOMED post-coordinations and the handling of Questionnaire type
structures but I think we should continue this discussion is a
separate clinical thread because it is definitely not just an issue of
GUI.

Ian

Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org

[thomas.beale]

Hi Koray,

I agree with Thomas here, Koray, but I take your point about the
separation into a further layer represents added potential development
complexity.

well… software engineering history would say otherwise. Where a concept is needed you have two choices:

• A) mix it in with the languages & architectural layers you already have
• B) create a dedicated layer or component type, and possibly dedicated formalism if needed
  A) represents the history of large scale systems built in the 60s, 70s and 80s - unmaintainable spaghetti. B), if done right is always better.

 I think we should expect tools to handle this in the same
way that a complex development environment like Visual Studio handles
various layers of application 'code' and resources within a seamless
environment. You should not have to think about these separate layers
during development.

exactly

• thomas

[pablo (Pablo Pazos)]

May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems.

I think the only thing in common of those two type of template is that they reference a set of archetypes to do something.

[thomas.beale]

I would suggest that the GUI templates just reference paths found in the openEHR template.

• thomas

[pablo (Pablo Pazos)]

I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths.

[ian.mcnicoll]

Hi Pablo,

In both ADL1.4 and 1.5 every path is still an archetype-based path.
The proposed schema for an operational template is very similar to the
XML schema of an individual archetype but obviously includes multiple
aggregated archetypes and omits any nodes which are constrained out.

Templates are technically identical to specialised archetypes. The
difference is that specialised archetypes support templating features
such as constraining out unwanted elements and aggregating archetypes.

The only difference between an archetype and a template is that new
content i.e. new nodes or terms cannot be added to a template.

Ian

Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org

[pablo (Pablo Pazos)]

Hi Ian,

If I understand what Thomas said “I would suggest that the GUI templates just reference paths found in the openEHR template”, the paths in a GUI Template will come “only” from openEHR templates (the structural ones), not from archetypes (this is apart from that they are technically the same thing).

I think in ADL 1.4 the template specification is not complete, I would say that in 1.4 Templates are not so clear Archetype specializations.
In ADL 1.5 is more clear the relationship of Templates and Archetypes.

What I meant in the previous mail was: for us who have developed applications over ADL 1.4, our GUI Templates will use paths “directly” from Archetypes, instead of paths from openEHR structural Templates.

[Koray_Atalag]

Hi All,

I’ve read similar work before starting with our design and found Thilo’s prior work very relevant and well researched. This MIEUR 2006 paper describes a new layer of GUI model using Mozilla XUL – an XML based open web layout standard. AT the time of writing templates were not out there yet and from his discussion I reckon much of the GUI definition could be handled by templates. I now agree that pure GUI stuff must be represented elsewhere – but at the moment we find template annotations quite useful and sufficient. Be aware that our app is a Winforms one – not Web based. So the kind of GUI rules might differ from others which are almost all Web based.

And one note to Thomas: we actually use templates for defining a minimum data set (yes not a maximal) for the purpose of reporting…So w have both data entry/validation and reporting layout issues. Not messaging though but we are planning to transform the openEHR instance of endoscopy report into CDA and exchange with HL7 V2.x in near future.

Cheers,

-koray

[Koray_Atalag]

Sorry forgot Thilo’s paper info:

	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.

Cheers,

-koray

[thomas.beale]

Hi All,

I’ve read similar work before starting with our design and found Thilo’s prior work very relevant and well researched. This MIEUR 2006 paper describes a new layer of GUI model using Mozilla XUL – an XML based open web layout standard. AT the time of writing templates were not out there yet and from his discussion I reckon much of the GUI definition could be handled by templates. I now agree that pure GUI stuff must be represented elsewhere – but at the moment we find template annotations quite useful and sufficient. Be aware that our app is a Winforms one – not Web based. So the kind of GUI rules might differ from others which are almost all Web based.

And one note to Thomas: we actually use templates for defining a minimum data set (yes not a maximal) for the purpose of reporting…

[system]

Hi!

A very interesting discussion, thanks to everybody here! Great with all references too!

Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems.

Or perhaps “GUI focused templates” and “Structurally focused templates” (since both will be openEHR based).

Correct me if I’m wrong:
If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different.

So an example inheritance/specialisation hierarchy in a running system could be:

A bunch of clinical archetypes (mostly international, and some regional ones)
…are used as building blocks in…

a “structural” template (maybe national/regional) often creating a composite SECTION or COMPOSITION

[add more structural layers if useful]

…that is then annotated with GUI-hints by…
a set of “GUI templates” with each template fitting a different recurring use case

…for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools

you have two choices:

• A) mix it in with the languages & architectural layers you already have
• B) create a dedicated layer or component type, and possibly dedicated formalism if needed

I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be.

If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You’d still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use.

[Thilo_Schuler1 (Thilo Schuler)]

Hi Koray, Erik, Pablo, Pariya and other GUI interested

These are very exciting times for me. I have been interested in openEHR GUIs and GUI generation since the first experiments that the co-authors and I did prior to publishing the MIE 2006 paper that Koray mentioned. For those still interested I uploaded a very late draft [;)] of this old paper to the wiki.

After that Helma, her supervisor, Rong and I published a very future-oriented paper about sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)published it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway… Hello Helma?).
This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion.
An extended version of Lisa’s EhrView mechanism with a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information.

It is great to see/hear that GUI generation is working in two proper end-to-end applications now:

• Next week I will continue my exploration of Open Ehr-Gen
• As soon as GastrOS is open-sourced I will give it a spin as well

Due to lack of time, money, programming skill, openEHR maturity,… I haven’t been involved in this topic anymore lately. This discussion and the before mentioned applications are motivation for me to start again providing my small share to drive this topic further. I think this could be very important for openEHR overall as e.g. web-based Open EHR-Gen will make it easy to demonstrate openEHR to a wider audience.

Erik makes a very good point about “ownership” of this issue. We who are interested and especially those with practical experience should drive this topic.
Here from memory a group that has been or is involved with openEHR GUI generation (please add those who I forgot)

• Koray & Hong Yul
• Pablo & Leandro
• Seref & Tony
• Helma
• Lisa
• Rong
• Thilo

Let’s take the max leverage for openEHR out of this discussion!

Cheers,
Thilo

[pablo (Pablo Pazos)]

Hi Thilo,

Is great to see such enthusiasm on the subject of GUI definition & generation (subject I love).

I see we have many people interested in the subject too.

I think your work in exploring tools like ours, is of great importance, because without these explorations and trials we could not improve our tools (owned by the community).

I really think that your work exploring the tools is as important as our work making them. Without people like you, our work is senseless.

I hope to see more advance in your the exploration of the EHR-Gen next week. All your comments and thoughts will be considered to improve the tool. And anyone who want to participate in the improvement, is welcome. Of course, any questions or comments are welcome.

[Thilo_Schuler1 (Thilo Schuler)]

Hi everybody,

I got permission to publish the MedInfo paper and its successor mentioned below.

You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007±+Brisbane+Australia

Cheers,
Thilo

[Koray_Atalag]

Thanks Thile, didn’t have this paper before – will read now with much pleasure J

Hong Yul and I had a long discussion yesterday and will prepare a joint response today or tomorrow (well NZ time of course!). Especially Tom has asked whether we have any issues which might need to go into Templates or Archetypes that has to do with the semantics and structure rather than GUI only. We think that we do but need first to define and be able to articulate in plain words.

Cheers,

-koray

[Koray_Atalag]

Hi Tom, here is our response:

We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge.

1. During our implementation one change request mandated that we should be able to depict certain data items (endoscopic findings) as present|unknown|absent as well as null if nothing has been specified about it. In the work for Nehta on anatomical pathology models Ian followed a similar approach where some findings were expressed as present, absent or indeterminate as far as I remember and this was definitely a repeating pattern.

This caused us to look more carefully into the whole thing and we came to a conclusion that not all data items need/can be represented like that. For example it doesn’t really make sense to indicate absence of a drug in patient’s medication list or a medical procedure performed; they are either present and further qualified (i.e. Aspirin 300mg tid or biopsy performed) or not mentioned at all.

However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either.

Our workaround in current implementation is that we have inserted to each and every clinical finding CLUSTER a special ELEMENT data item called “Present?” of DV_CODED_TEXT which have the following values: 0>Null, 1>Present, 2>Unknown, 3>Absent. We don’t further specify the reasons of Unknown but using flavours of null would be logical.

Even more interesting when nothing is entered on GUI for a clinical finding or when entered but later on it is ‘cleared’ instead of putting value 0 for null we can actually ‘prune’ that particular CLUSTER (and all downstream items); i.e. remove altogether from the value instance.

Our solution to this issue was to come up with a GUI Directive called “isCoreConcept”. This instructs our GUI generator to render that item with 3- state checkbox and also hide all its children until a value has been selected. This directive also imposes an implicit precondition that the affected CLUSTER define the special child ELEMENT that denotes “Present?” - otherwise the GUI generator will render the model invalid. Actually when we rethink about this we found out that this particular directive actually is overloaded and has elements of both semantic and presentation information. So we propose to delegate the semantics part to modelling side and use another GUI directive called “hideChildren” (which actually we have also defined before but not used. This directive can then be used for core and non-core concepts.

We think this might best be denoted in the RM; either at CLUSTER or ITEM classes. Something like null flavours but not quite the same. Or perhaps a dedicated new class?? That’s up to the discussions.

2. We also saw that some clinical findings can exist alone; i.e. without further qualification or depicting anatomical sites. Example is haemorrhoids where anatomical site is implied and it can just be reported as “haemorrhoids were observed” (can be qualified as internal external or even a grade but the point is it can exist on its own). But when you talk about a tumour you need further description” i.e. site, type, grade etc. It is not a valid clinical expression to say “tumour was present” in an endoscopy report (yes context is important, in some other contexts this expression may well be valid). This indeed was also denoted in openSDE with a GUI directive called “selection requires further description”.

To depict standalone findings during archetype design setting the cardinality of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1 it’s possible to have CLUSTER’s with 0 ITEM’s as long as it isn’t validated by the RmValidator, this isn’t considered a desirable usage).

The real issue is a bit more tricky and has to do with core semantics: it doesn’t make sense to depict a finding as absent or unknown when qualified by certain attributes.

One example is: “Three polyps were observed at ascending colon” there is no point in saying “Three polyps were absent at …”

But this is a perfectly valid (and quite frequently used) expression in endoscopy reporting: “Villous polyps were absent at ascending colon” (here villous is an attribute for type of polyp).

Another invalid expression: “3 cm long stenosis was been absent…”

So it looks like some qualifiers may change the existence of core concepts – so perhaps we need some means to tag them during modelling. It looks like these are ‘physical’ properties and not ‘man-made’ concepts.

Hope this helps to elaborate things…

Cheers,

-koray & hong yul

[thomas.beale]

Hi Tom, here is our response:

We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge.

1. During our implementation one change request mandated that we should be able to depict certain data items (endoscopic findings) as present|unknown|absent as well as null if nothing has been specified about it. In the work for Nehta on anatomical pathology models Ian followed a similar approach where some findings were expressed as present, absent or indeterminate as far as I remember and this was definitely a repeating pattern.

This caused us to look more carefully into the whole thing and we came to a conclusion that not all data items need/can be represented like that. For example it doesn’t really make sense to indicate absence of a drug in patient’s medication list or a medical procedure performed; they are either present and further qualified (i.e. Aspirin 300mg tid or biopsy performed) or not mentioned at all.

However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either.

[Helma]

Hi everyone,

for those interested, my full thesis is available here:
http://www.sourcefusion.nl/thesis/Dissertation-HvdL.pdf

A link on the openEHR website to this PDF is appreciated.

Sorry for not participating in the discussion, but my current job has me
swamped with work and deadlines.

With regards,

Helma van der Linden

Thilo Schuler said the following on 13/12/2010 07:20: