Put a couple of comments on the wiki, but I think it is a thing that
should be discussed on the list.
In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows
nodes required for structuring data but otherwise redundant for screen
display and reporting to be detected by rendering software'. So now we
have a GUI directive on the ADL. Shouldn't this be a part of the
reference model information (if it is never supposed to be displayed)
or part of a 'visualization template' (another different level).
I would say that more information about visualization will be needed,
and having visualization information separated between two different
places feels like a bad design move.
In general I am inclined to agree, and I have to say I have been in two minds about having this attribute in there. I am convinced by clinical modellers who say that something is needed to control interior tree nodes not appearing on the GUI (indeed, it is visual pollution). And - even if the template were being used to build a message definition (generated XSD or similar), and the data were processed into some report or other output, this attribute would be respected (technically, this is still ‘user interface’).
I know the passthrough attribute is used often from the current .oet template usage, so we need a way of dealing with the requirement. If we take it out, and say it is a GUI directive, the problem is we currently have no formal framework for that yet. Maybe the lesser of two evils is to do what Koray (I think?) said, and make it a special kind of annotation. I have implemented annotations in ADL/AOM 1.5, and they work nicely. We need to agree on some kind of standard representation, e.g.
I originally didn’t like this approach (I still don’t really) but we have to be realistic and it’s not the end of the world to bootstrap like this. As you can see it is ‘soft programming’, so error-prone, but it can obviously be made to work, and isn’t hard to implement. However, now rendering software has to know to look for “ui” annotations and do sensible things with them.
thoughts?
- thomas
Hi Tom and Diego,
Short response is yes this is a better way of hardwiring a pure presentation related attribute into Archetypes which are supposed to deal with meta-data, structure and semantics of information only. The ideal solution would be to have an accompanying (but separate) layer of model responsible for GUI stuff.
Our experience is that there are three types of such ‘things’:
-
Pure GUI related (such as passthrough or depicting a particular GUI widget, style etc.)
-
Assumed (e.g. to render a textbox for DV_TEXT or draw a frame/indend children nodes under CLUSTER)
-
Mixed – where it is not easy to separate presentation from semantics.
Regarding (3), for example we have a GUI Directive called isCoreConcept (which we were inspired by the openSDE project by Astrid van Ginneken) which when modelling clinical findings and causes GUI generator to put a four state checkbox (null, present, absent, unknown). This actually applies to any ‘thing’ which we can also talk about its absence. This semantics implies to show or hide all of its children based on its presence (or absence).
I think we can use one Archetype attribute (to depict the semantics that this is a clinical finding or perhaps a new class of its own (e.g. DV_CLINICAL_FINDING) and perhaps separate GUI directives (or make it an assumed behaviour when that semantic attribute is set) create this appearance and behaviour.
Not so sure if I can show you other clear examples (other than core concept) at this stage but I suspect there are others.
Oh and we have also identified a whole new territory which we call ‘information axes’ and ‘semantic equivalence’ 
This also has to do with both semantics and presentation I believe. Think about capturing (and modelling archetypes) a clinical statement as:
“Polyps were present in sigmoid colon and rectum and ulceration was seen in rectum.”
“In rectum polyps and ulceration were seen and ulceration was present in sigmoid colon”
These are equivalent but how to model the archetypes; e.g. finding or site oriented will depend on modelling best practices and use cases. Rule of thumb is to design archetypes as close to screen representation as possible (hence the clinicians thinking). We must be able to depict in archetypes and/or presentation model that alternative representations exist and how to construct these. SNOMED CTs normal/canonical forms is pretty related with this but then the semantics is hardcoded into the SCT axes.
My 2 cents
(attachments)
Why don’t we use the new annotations feature to handle these type of concerns? You can put pretty much anything you want into annotations section for a node. The whole section is optional, so one can simply ignore that section, and no concerns are mixed…
In fact, given the external ref mechanism, one can even create “annotation archetypes” simply consisting of nodes to annotate in another archetype, and the annotation section.
(attachments)
Hi Diego & Thomas,
I think this should be out of the scope of the new semantic/structural archetypes & templates specs, and should be included in a new specification of GUI Templates.
I been working on this subject for a while and want to formalize a XML format to have GUI directives / GUI definition (input controls, position, visibility, order, …) and binding with structural archetypes and templates (in a system this bindings should be to OPTs).
http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates
On february/march 2012 I’ll be working on this to improve the flexibility of our current templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce
If anyone want to work on this, would be a pleasure to colaborate.
FYI: We have developed a prototype editor for those GUI templates: http://code.google.com/p/template-editor-open-ehr-gen/
It is web based, and can access archetypes repositories via HTTP to pull archetypes to be included in a GUI template.
(attachments)
If it is really needed for the moment for representing templates then
it's OK with me (as long as we agree that this is a temporal thing),
but I still feel that having two separated places to rule UI
generation is a bad idea.
I think that annotations could work for you (even creating a new
specific ADL section would).
We currently have all the GUI directives for representation in a
documentation file for each reference model (as you can see in this
screen capture http://i.imgur.com/tQxRt.png). This could be extended
to general templates in similar way to the one that Pablo has posted.
on the other hand, EHRFlex uses a complete MVC architecture, in which
the intermediate model (which also depends of your RM) is the one
responsible to transform archetypes/templates into classes that the
'view' part can then paint.
Hi Diego,
'pass-through' is required to construct clear clinical views of
template models in some circumstances. I think the suggestion to use
the annotations feature makes sense.
A common example might be where a complex Discharge summary
requirement asks for a Diagnosis field. This would be modelled as
something like
EVALUATION. diagnosis.v1
items
Diagnosis name
From a clinical review perspective the EVALUATION root node and items
node are redundant, and it is confusing to have them appear in the
tooling views
It would be great if we could make some progress on a GUI templating
formailsm putting together the work done in EHRFlex, Koray's GastrOS
directives and, of course, Pablo's work, bearing in mind that at least
some of the directives and transformations have utility in other
outputs e.g Documentation and not just in GUI production.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
Hi Paplo,
Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer.
If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class.
The term view was adopted because it is used in both GUI and data oriented contexts.
I can provide the XML schema for this AOM extension used by the template designer if people are interested.
Heath
Hi Heath,
Hi Paplo,
Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer.
In that case, I think we should separate the uses of the directive. IMO is a little anoying to use the same directive to do semantic processing of the structure and to do GUI generation/customization.
If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class.
I’m afraid I could not see what you mention, I don’t have a licence for the TD.
The term view was adopted because it is used in both GUI and data oriented contexts.
I can provide the XML schema for this AOM extension used by the template designer if people are interested.
It would be nice to see the schema and some documentation about the structure and rationale behind it if you have some (just to understand the XML structure).
Cheers,
Pablo.
Hi!
From: yampeku@gmail.com
Date: Wed, 11 Jan 2012 10:12:39 +0100
Subject: Re: pass_through attribute in ADL 1.5
To: openehr-technical@openehr.orgIf it is really needed for the moment for representing templates then
it’s OK with me (as long as we agree that this is a temporal thing),
but I still feel that having two separated places to rule UI
generation is a bad idea.
I totally agree with Diego.
I think that annotations could work for you (even creating a new
specific ADL section would).
We currently have all the GUI directives for representation in a
documentation file for each reference model (as you can see in this
screen capture http://i.imgur.com/tQxRt.png). This could be extended
to general templates in similar way to the one that Pablo has posted.
on the other hand, EHRFlex uses a complete MVC architecture, in which
the intermediate model (which also depends of your RM) is the one
responsible to transform archetypes/templates into classes that the
‘view’ part can then paint.
EHRGen also is MVC but we generate HTML forms for creating & editing clinical records, and a other HTMLs for showing individual records (documents/compositions).
Maybe we could share our current GUI directive formalisms to think about a new/common formal way to express all the things we need to generate GUI. I also want to work on generation of reports with aggregated data, trying to reuse what we could for the GUI generation for clinical recording & viewing.
Cheers,
Pablo.
Hi Pablo,
The Ocean Template Desiner is now freely available from https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases.
The pass_through view constraint is not a GUI directive, it is a data view directive which is consistent with archetypes/templates being definitions of data structures. Just as form generators may use this data definition to lay out a form and bind to a data instance, it may use this pass_through view constraint to collapse a redundant grouping on a screen. Similarly an XML schema or class generator may use this same constraint to collapse a redundant element grouping. This ensures that screen layout and binding are consistent with the XML schema or class it will bind to.
I historically was of the opinion that GUI only directives such as control type or position should be provided separately as these a really implementation specific and have minimal use in shared artefacts such as archetypes and templates. Having said that the view constraint could easily be used for this purpose if desired.
The XSD for the view constraint is as follows:
<xs:complexType name=“T_VIEW”>
<xs:element name=“constraints” minOccurs=“0” maxOccurs=“unbounded”>
<xs:element name=“items” maxOccurs=“unbounded” >
<xs:element name=“value” type=“xs:anySimpleType”/>
</xs:sequence>
<xs:attribute name=“id” type=“xs:string” use=“required”/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name=“path” type=“xs:string” use=“required”/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
An example use of this is as follows:
…
true
Heath
Hi Diego
If it is really needed for the moment for representing templates then
it's OK with me (as long as we agree that this is a temporal thing),
but I still feel that having two separated places to rule UI
generation is a bad idea.
I think that annotations could work for you (even creating a new
specific ADL section would).
technically, the annotations might work - it depends on how much needs
to be said, because the annotations are not very powerful in terms of
structure or semantic expressions - they are after all designed to be
'notes' of some kind. But the real problem is likely to be that for a
given archetype (most likely national or local ones) or template (e.g. a
national one for discharge summary), there are more than one UI template
'overlay' - e.g. let's say you have a Spanish template & some e-health
groups in Andalusia & Galicia regions want different UIs. That means
multiple UI-templates.
We currently have all the GUI directives for representation in a
documentation file for each reference model (as you can see in this
screen capture http://i.imgur.com/tQxRt.png).
I don't understand which of these settings inn the right hand group is
too do with UI rendering of the data...?
- thomas
visible, allowed types, icon...
ok - I understood those were settings relating to the display of that
kind of node within the modelling tool, not of the data in a deployed
system.... so its about data? What does icon mean then?
- thomas
No, but they can be used for different things, from creating specific
editors, to mindmaps or sample GUI generation
Hi Heath!
Just for the record, I think as Diego: I don’t have a problem to have the pass_through attr on templates right now, but we have to comment possible issues with this and other attributes to improve templates in the future.
The pass_through view constraint is not a GUI directive, it is a data view directive which is consistent with archetypes/templates being definitions of data structures. Just as form generators may use this data definition to lay out a form and bind to a data instance, it may use this pass_through view constraint to collapse a redundant grouping on a screen. Similarly an XML schema or class generator may use this same constraint to collapse a redundant element grouping. This ensures that screen layout and binding are consistent with the XML schema or class it will bind to.
If I understand correctly, the pass_through attribute is only for data displaying on a screen (as you mention the use for data grouping or collapsing). If that’s right, I don’t think that should be part of the generic template structure, because templates are meant to represent other elements than data views/GUI, like messages, reports, etc.
As you mention " screen layout and binding are consistent with the XML schema or class it will bind to" I feel maybe this is a little attached to Oceans implementation, e.g. in our implementaition we don’t have binding with XML Schemas .
I historically was of the opinion that GUI only directives such as control type or position should be provided separately as these a really implementation specific and have minimal use in shared artefacts such as archetypes and templates. Having said that the view constraint could easily be used for this purpose if desired.
I totally agree with you. Having an operative template with all the data structure in it, the last step should be define the GUI Template with controls, position, style, etc., and that should be the artefact consumed by EHR software for clinical data recording and displaying.
The XSD for the view constraint is as follows:
<xs:complexType name=“T_VIEW”>
<xs:element name=“constraints” minOccurs=“0” maxOccurs=“unbounded”>
<xs:element name=“items” maxOccurs=“unbounded” >
<xs:element name=“value” type=“xs:anySimpleType”/>
</xs:sequence>
<xs:attribute name=“id” type=“xs:string” use=“required”/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name=“path” type=“xs:string” use=“required”/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
An example use of this is as follows:
…
true
Heath
Kind regards,
Pablo.
If we had a ‘GUI template’ facility in openEHR, I am not 100% sure that this pass-through setting would go into it. It’s not GUI-specific, but I think it probably is ‘presentation-specific’, i.e. GUI, reports, any rendering of data onto a display device. Not all display devices are active GUIs: a tablet showing a PDF isn’t.
Maybe another way of understanding this flag is as ‘this node can be skipped without loss of meaning’. I would be very interested to know if we should make AQL queries sensitive to this flag. Has anyone thought about that?
- thomas
(attachments)
Hi Thomas,
Maybe we should talk about Presentation templates instead of GUI templates, but I definetly we should separate attributes for data related logic and presentation/GUI logic.
Regards,
Pablo.
(attachments)
2012/1/25 Thomas Beale <thomas.beale@oceaninformatics.com>
Maybe another way of understanding this flag is as ‘this node can be skipped without loss of meaning’. I would be very interested to know if we should make AQL queries sensitive to this flag. Has anyone thought about that?
In this sense I can see the reason for this attribute, since it can be understood as part of the documentation of the clinical model. But definitely it is not clearly described at the specs since there it seems to be linked to the presentation template only.
I fact, there is a similar attribute in EN13606 ITEM class, but used in an opposite sense. The attribute is “emphasis” and it is described as “A way of denoting that the composer wished to mark this ITEM as being of particular note (an unusual measurement value, an unexpected outcome, anything that might be considered necessary to highlight to a future reader).”
I have never thought about this. I don’t know if this kind of annotations (“this item is important or clinically relevant or not”) better fits as part of the RM or part of the AOM. In other words, if this marker is related to a specific data instance or to a data item definition in an archetype.
Thoughts on this?
Would this attribute value change depending on where is the archetype
used? i.e. if we use it on a GUI of a smartphone rather than a
standalone or web application