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

Technical (archive)
21

Hi All, late to respond but here are a few thoughts:

  • While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function.

  • I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘change’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view :wink:

  • I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations.

  • I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with.

My 4 cents…Cheers,

-koray

P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community…he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions…

22

Dear Tim,

Thank you for your response

Could you please provide me with more detail about this?
Would it need manual adjustment of any css/style file or would it be totally dynamic? Is it based on the templates, archetypes, or both?

I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation.

Best Regards
Pariya

MSc; PhD Candidate
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/

23

Dear Tim,

Thank you for your response
Could you please provide me with more detail about this?
Would it need manual adjustment of any css/style file or would it be
totally dynamic?

Well, you can generate dynamic UIs; but I really doubt that they are
useful in any real world situation. :slight_smile:

Is it based on the templates, archetypes, or both?

Archetype based; with a layer of templating for local constraints.

I am trying to summarize the answers from different contributors, so
that we can have a better image of the situation when it comes to GUI
generation.

Have you considered that it would be a good idea to conform to MSCUI?

--Tim

24

Hi,
From your response, my understanding is that one can generate such a GUI in OSHIP, but is also needs manual adjustments to reach the ideal GUI design.

I’m not sure if I understand your last phrase.
Do you mean considering design guidelines while generating GUIs?

Best Regards
Pariya

MSc; PhD Candidate
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/

25

I'm not sure if I understand your last phrase.
Do you mean considering design guidelines while generating GUI

Yes.

-Tim

26

Hi Tim,

I do tend to agree with you that GUI generation can be useful as a
startpoint, but that most real-world applications will demand much a
richer GUI that will need subsequent, manual intervention.

There are 2 other areas where auto-GUI generation can be useful. One
is in the area of user-defined forms, a common feature in many
applications. The other is in the area of requirements gathering and
prototyping, either for EHR aplication development or wider standards
development work.
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

27

Hi Ian,

I think there is a way to customize the GUI without (direct) manual manipulation.
If an application can generate expressive HTML, you can do all the customization with CSS (a good web designer can make this work for us).
For “expressive HTML” I mean, HTML code with tags, ids and classes that let you customize every aspect of the way each template/archetype node is displayed: position, size, labels, etc.

This is the only way to do GUI customization for projects that generate the GUI on the fly and that are web-based. (like the Open EHR-Gen).

Example:

This is an inexpressive HTML:

a label:

This is an expressive HTML:

a label:

Other idea is to use some CMS-like functions, like dragging and dropping generated components on different zone of a web page layout. So, each user can have its own customized GUI.
We can create a couple of these layouts, based on some GUI patterns and good practices, and adjust our GUI generators to use one layout or the other to see if the page generated is usable or not.
Our Open EHR-Gen Framework has some of this ideas already developed (each node in our GUI-templates have a “pageZone” attribute that indicates in wich zone of the web layout, this node has to be displayed). See: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates

28

#1. You do not revise data in a health record. You version it with
additional information.

You are right, I was not precise enough.

#2. Any well designed archetype / template combination is going to use
the same 'data structure'. Irregardless of the available options.

Of course, both revisions of data are valid and correct regarding the
archetypes, I did not say the contrary.

#3. The templates you use should only restrict data entry. It should
not filter existing data of the same structure. If it does; there goes
interoperability. Along with the entire premise for the use of and
purpose of archetypes.

Interesting... If templates are only used for data entry and not for
data reading and revision that should be stated clearly for all
developers, since I think it is not said anywhere at the
specifications, the web or the wiki. Every developer should know that
(coming back to the topic of this thread) if they hand-code a
visualization template all that work is only useful for the data
generated at their own system and not for the data from an external
one, even if it is using the same archetypes.

29

the general idea has always been that data can always be interpreted by a receiver using just the archetypes declared in the data. I believe this will continue to be a reliable assumption into the future. However, with the new style templates, which are essentially just archetypes, it may be that templates will be shared quite often as well, since the computing machinery that can deal with archetypes will be able to deal with ADL 1.5 templates as well (with only very minor upgrades from today, since we are talking about operational templates, which are essentially big archetypes). This is not going to add much information, since the information structures themselves (i.e. the compositional hierarchy of Composition, Sections, Entries etc) will reflect the structure of the template that was used. But if the receiver wants to validate the received data against the template, which is likely to include a) numerous removed optional items and b) further constrained coded text fields, then it will need the template. Note that the data as received must be definition already be valid with respect to the implicated archetypes, and if the receiver is interested in what the template says, then it means they probably have some agreement with the sender institution about using their templates. This will almost certainly happen with nationally standardised templates for referrals, discharge summaries and so on.

In summary: displaying and using the data with just the archetypes used to build it will be fine, since the data will reflect accurately the removed optional items, reduced terminology choices etc. Any site wanting to do processing against the template will undoubtedly be in some kind of communication with the publisher of the template.

  • thomas
30

Thanks Thomas. I will resume the reasoning that brought us here:
"in some cases" templates will also be shared together with
archetypes, then, in my opinion, they should not incorporate GUI
related stuff and be only about data constraints.

David

31

Hi Tom,

the general idea has always been that data can always be interpreted
by a receiver using just the archetypes declared in the data. I
believe this will continue to be a reliable assumption into the
future.

So this begs the question. Do you think that there is a possibility
that it will NOT continue to be a reliable assumption?

However, with the new style templates, which are essentially just
archetypes, it may be that templates will be shared quite often as
well, since the computing machinery that can deal with archetypes will
be able to deal with ADL 1.5 templates as well (with only very minor
upgrades from today, since we are talking about operational templates,
which are essentially big archetypes).

So in a paragraph or less can you explain the difference between
templates and simply constructing archetypes that use slots for
extendability?

This is not going to add much information, since the information
structures themselves (i.e. the compositional hierarchy of
Composition, Sections, Entries etc) will reflect the structure of the
template that was used. But if the receiver wants to validate the
received data against the template,

But if the data validates against the archetype(s) (and therefore the
reference model) there is no need to validate against templates.

and if the receiver is interested in what the template says, then it
means they probably have some agreement with the sender institution
about using their templates.

Correct. So this is not a technical issue at all. It is a
socio-political issue.

This will almost certainly happen with nationally standardised
templates for referrals, discharge summaries and so on.

Makes sense.

In summary: displaying and using the data with just the archetypes
used to build it will be fine, since the data will reflect accurately
the removed optional items, reduced terminology choices etc.

Actually the data will reflect the 'chosen' option(s). It is a
historical artifact.

Any site wanting to do processing against the template will
undoubtedly be in some kind of communication with the publisher of the
template.

Right; and otherwise the data is still valid against the archetype and
should be valid in any conforming application.

Since my original question was asking for a use case where templates
were required to fully interpret the data. Based on this assertion:

This specific use further constrains archetypes and these kind of
structural templates should be also shared as the archetypes
themselves since they will be needed to fully interpret the data.

David and I agree that GUI directives have no place in structural
definitions. Therefore, templates should not filter out existing (valid)
data. At least I think that is what he is saying.

But the point I am making is that templates do not have to be shared in
order to interpret the data. Again, the only information a template can
add is what particular subsets were available at the time a specific
entry was chosen. I simply do not see a purpose for this 'requirement'.
The data has been entered. It is now part of a historical record.
Since the archetype describes the data model of the concept as a set of
constraints against the reference model. That is all the validation
required.

Again, if I am missing something I am very interested in what it is.

Thanks,
Tim

32 
Hi Tom,



the general idea has always been that data can always be interpreted
by a receiver using just the archetypes declared in the data. I
believe this will continue to be a reliable assumption into the
future.


So this begs the question.  Do you think that there is a possibility
that it will NOT continue to be a reliable assumption?

The current design of ADL 1.5 is that template ids will be declared in the data (since they are just like archetype ids) - see http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf

So it is really about the mechanisms for sharing archetypes and templates. If specific templates are made available for sharing, then they will be used, just like archetypes. If locally produced specialised archetypes are made available for sharing, the same for them; otherwise the receiver system has to revert back to whatever archetypes and templates it can access. Now, assuming a standardised kind of published service (of which CKM can be considered an initial example) is used, then it just depends on producers ‘publishing’ archetypes and templates. So far in the national programmes we have seen the intention is to create most templates nationally and share them at that level.

The key point to remember is that no matter what reduced set of archetypes or templates are available, the data received are always correct according to the local artefacts in use at the sender side (barring software or other system errors of course). So the potential limitations at the receiver are to do with:

  • not having the archetype information for added data points, due to not having specialised archetypes produced locally at the origin.

  • this is correct: if the definition of those added items were of interest outside the producer site, it would have published the relevant archetypes somewhere

  • regardless, the data structures are always openEHR standard structures, and the receiver can always process them in a generic way.- not having the templates: the only limitation here is not knowing what restrictions (removed data points, more constrained term sets) were specified in the template above those of the underlying archetypes.

  • this is also correct: this would only matter if the receiver wanted to allow users to modify the data according to the same templates as at the senders location; if this is true, it means that the receiver wants to share the templates, and they will have arranged to do this.



However, with the new style templates, which are essentially just
archetypes, it may be that templates will be shared quite often as
well, since the computing machinery that can deal with archetypes will
be able to deal with ADL 1.5 templates as well (with only very minor
upgrades from today, since we are talking about operational templates,
which are essentially big archetypes).


So in a paragraph or less can you explain the difference between
templates and simply constructing archetypes that use slots for
extendability?

Archetypes contain slots; templates fill them and remove unwanted archetype data points (generally most of them in any given template). It is a matter for discussion whether templates should ever be allowed to add new data points the way an archetype can.

This is not going to add much information, since the information
structures themselves (i.e. the compositional hierarchy of
Composition, Sections, Entries etc) will reflect the structure of the
template that was used. But if the receiver wants to validate the
received data against the template,


But if the data validates against the archetype(s) (and therefore the
reference model) there is no need to validate against templates.

at the receiver side, correct. Unless the receiver wants to do that for some reason, e.g. to enable users to further modify the data according to the same rules as at the sender, in which case sharing is required.

But the point I am making is that templates do not have to be shared in
order to interpret the data.  Again, the only information a template can
add is what particular subsets were available at the time a specific
entry was chosen.  I simply do not see a purpose for this 'requirement'.
The data has been entered.  It  is now part of a historical record.
Since the archetype describes the data model of the concept as a set of
constraints  against the reference model. That is all the validation
required.

Again, if I am missing something I am very interested in what it is.

Thanks,
Tim

for interpreting data, I would agree. For doing other things, possibly not.

  • thomas
33

I would regard this as a base assumption, and a clear separation of concerns.

  • thomas
34

Hi Tom,

The current design of ADL 1.5 is that template ids will be declared in
the data (since they are just like archetype ids) - see
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf

So it is really about the mechanisms for sharing archetypes and
templates. If specific templates are made available for sharing, then
they will be used, just like archetypes. If locally produced
specialised archetypes are made available for sharing, the same for
them; otherwise the receiver system has to revert back to whatever
archetypes and templates it can access.

...

Archetypes contain slots; templates fill them and remove unwanted
archetype data points (generally most of them in any given template).
It is a matter for discussion whether templates should ever be allowed
to add new data points the way an archetype can.

Thanks for these clarifications. They are *very* important points to
consider.

IMHO, if templates are permitted to add to the constraints published by
an archetype then it changes the basic design paradigm.

Something to consider very seriously.

Regards,
Tim

35

I mostly agree: it just makes it clearer if templates are not adding any more data points. The formalism will in fact allow this, so it will be up to tools to prevent it. That is not hard to do. On the other hand, one could make the same argument about added data items in templates as for purely locally used archetypes: they are of local interest only (e.g. some kind of hospital specific business process study), and have really no meaning whatever outside.

I personally think it makes it simpler for everyone to think of templates as only being used for 1. slot-filling 2. removal of unneeded optional data points and 3. tightening of some leaf value constraints, nearly always coded terms. If it turns out that data node additions make sense, we will deal with it when a true need is clear.

  • thomas
36

5 dec 2010 kl. 18.04 skrev Thomas Beale:

I personally think it makes it simpler for everyone to think of templates as only being used for 1. slot-filling 2. removal of unneeded optional data points and 3. tightening of some leaf value constraints, nearly always coded terms. If it turns out that data node additions make sense, we will deal with it when a true need is clear.

Returning to the original topic of what should go into a template, I would say that this statement supports that template should not
contain GUI-directives, but that such information should go into a special visualization layer?

regards

Olof

37

Hi All, late to respond but here are a few thoughts:

  • While having ‘another layer’ of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ‘universal’ and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function.

  • I strongly believe that the presentation information should not be separated from data-set definitions – templates. As archetypes and templates are designed to handle ‘change’ this means that the model will be on constant change so maintaining two models – kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view :wink:

  • I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain – we’ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications – which will boost consistency among different implementations.

  • I also think while thinking on these issues we should also have a look at other facades of GUI – such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with.

My 4 cents…Cheers,

-koray

P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community…he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself – don’t be shy! And people don’t hesitate to ask all your hard questions…

38

5 dec 2010 kl. 18.04 skrev Thomas Beale:

Returning to the original topic of what should go into a template, I would say that this statement supports that template should not
contain GUI-directives, but that such information should go into a special visualization layer?

Yes. Visualisation / GUI hints could be written on a per-form basis, probably 1:1 or maybe 1:N with respect to templates, and could use archetype paths, same as in AQL to reference things. E.g. it could have statements logically like:

id = <“some form id”>
templates = <“template 1”, “template 2”>
structure = <
[1] = (VBOX) <
[1] = (HBOX) <
location = <
x = <>
y = <>

controls = <
[1] = <text_and_coded_text_control(//[diagnosis_archetype_id]/path/to/diagnosis)>
[2] = etc

[2] = (HBOX) <
controls = <
[1] = <some_other_control(//****[some_other_archetype_id]/****some/other[at0003]/path[at0012])>

[3] = (VBOX) <
etc

etc

I just made this up in dADL, the real thing will be in some XML format, the point is to use archetype paths, and also potentially to have a way of mapping back from archetype/template paths to locations in the visual structure. In the above, the archetype path [diagnosis_archetype_id]/path/to/diagnosis is at /structure[1][1]/controls[1] in the specification structure, which is a text_and_coded_text_control. You might also map a complex custom built control that captures 4 or 5 commonly grouped data elements, to a non-terminal path within a template structure.

Please note: I am just thinking out aloud here, and a working ‘GUI hints’ language / file format will no doubt look completely different.

  • thomas
39

Exactly, we have some researchers here doing exactly that work. I am
certain that their results will be open sourced.

--Tim

40

Hi Olof,

I agree but I think there are some directives that are actually not
purely GUI directives but which say something meaningful about the
underlying information.

For instance Koray's directive

isCoreConcept (g): "This is an abstract concept; but we can say that
Core Concepts are real-world entities which we can talk about their
abscence (i.e. a clinical finding, a disease but not tumour grade or
physical examination). The directive depicts whether a node with all
its children (if any) shall be handled and repeated as a whole in an
archetype (i.e. makes sense together such as a clinical finding with
other attributes defining its nature). When the node and/or its
children are selected, its presence information is stored in the
corresponding ELEMENT node which records this (i.e. in MST Findings
archetypes [Present?] node)."

This seems to me to represent some sort of association between a
parent concept and potential children which is independent of any GUI
representation. These, I believe, should be considered for inclusion
within archetypes/templates.

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