pass_through attribute in ADL 1.5
David, Pass_through has no relevance to this emphasis concept in any way. It has been a means to collapse container attributes such as items when the hierarchical structure inherited from the RM or Archetype is no longer desired or relevant in a template perhaps because sibling items in a cluster or multiplicity has been constrained. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner Sent: Thursday, 26 January 2012 9:16 AM To: For openEHR technical discussions Subject: Re: pass_through attribute in ADL 1.5 2012/1/25 Thomas Beale thomas.beale at 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? -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/93ab2c2a/attachment.html
pass_through attribute in ADL 1.5
Hi Pablo, 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. No, that is not what I are saying. I are saying it can be used for more than display purposes such as data views, 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 . Ocean doesn't bind to XML schema either, I used this as an example of why you may want to ensure your presentation view is consistent with a data view derived from the same template artefact. The use of the annotation-like structure for view directives allows us to separate these kind of directives from true annotations and the data definition itself whilst providing flexibility for specifying a set of directives that we know of now but may improve on later such as pass_through, add to in the future, and also use in local environments. We need to remember that templates where intended for local use cases but are now also becoming important at jurisdictional levels for shared use. I don't believe that pass_through should be hard coded into the AOM. It should be in a more generic framework such as that I proposed in my previous email. Heath -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/55d5f522/attachment.html
pass_through attribute in ADL 1.5
In fact, the emphasis attribute of 13606 is a CV. 2012/1/26 Diego Bosc? yampeku at gmail.com but they won't show everything on a 'full' GUI either. Maybe what is needed is not only a boolean but a way to tell exactly the criteria with different values of a controlled vocabulary, such as 'mandatory', 'recommended', 'passable'/'skippable'... 2012/1/26 David Moner damoca at gmail.com: Following this new sense for it, I think that the implications for a GUI or visual representation would depend on a decision of the implementers. If the screen space is reduced, they could opt for just showing the clinically relevant data and leave the rest for a second screen, a pop-up or something like that. 2012/1/25 Diego Bosc? yampeku at gmail.com 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 2012/1/25 David Moner damoca at gmail.com: 2012/1/25 Thomas Beale thomas.beale at 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? -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/b6c254ed/attachment.html
pass_through attribute in ADL 1.5
On 25/01/2012 22:45, David Moner wrote: 2012/1/25 Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at 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 remember many arguments about that one in CEN meetings. It was intended originally to be used on text items. 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. well I am always suspicious of subjective markers like 'important' and so on. At least 'pass-through' is a mechanistic kind of concept. I agree that it has not been analysed properly though, and I think that can only be done in the clinical realm. At the moment, I think we need to support it because it is already in use in the .oet templates. The question is whether it turns out to have some proper semantic basis or is indeed 'just presentation'. We should ask why it is there at all: the reason is that it deals with information nodes that are not needed cognitively (i.e. for human understanding) but are an unavoidable artefact of information trees - but only sometimes... as far as I know there is no reliable algorithm for removing these nodes from presentation. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/d7a2d003/attachment.html
pass_through attribute in ADL 1.5
On 25/01/2012 23:03, David Moner wrote: Following this new sense for it, I think that the implications for a GUI or visual representation would depend on a decision of the implementers. If the screen space is reduced, they could opt for just showing the clinically relevant data and leave the rest for a second screen, a pop-up or something like that. I know that sounds logical but that is not the way clinical people use this attribute. They look at certain archetypes and simply decide to add it, with out regard for which particular device it is displayed on. For them it is not optional to remove it or keep it - in a given archetype. In other archetypes it is not used at all. I will try to obtain some examples... - thomas
pass_through attribute in ADL 1.5
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:sequencexs:element name=constraints minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:element name=items maxOccurs=unbounded xs:complexType xs:sequence xs:element name=value type=xs:anySimpleType/ /xs:sequence xs:attribute name=id type=xs:string use=required//xs:complexType /xs:element /xs:sequencexs:attribute name=path type=xs:string use=required/ /xs:complexType/xs:element /xs:sequence/xs:complexType An example use of this is as follows: template xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns=http://schemas.openehr.org/v1; ? viewconstraints path=/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046] items id=pass_throughvaluetrue/value /items /constraints /view/template Heath Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cb0b6b65/attachment.html
pass_through attribute in ADL 1.5
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 On 25/01/2012 18:05, pablo pazos wrote: 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:complexTypename=T_VIEW xs:sequence xs:elementname=constraintsminOccurs=0maxOccurs=unbounded xs:complexType xs:sequence xs:elementname=itemsmaxOccurs=unbounded xs:complexType xs:sequence xs:elementname=valuetype=xs:anySimpleType/ /xs:sequence xs:attributename=idtype=xs:stringuse=required/ /xs:complexType /xs:element /xs:sequence xs:attributename=pathtype=xs:stringuse=required/ /xs:complexType /xs:element /xs:sequence /xs:complexType An example use of this is as follows: template xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns=http://schemas.openehr.org/v1; ... view constraints path=/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046] items id=pass_through valuetrue/value /items /constraints /view /template Heath Kind regards, Pablo. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cbcca1a9/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cbcca1a9/attachment.jpg
pass_through attribute in ADL 1.5
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. Date: Wed, 25 Jan 2012 20:09:51 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/1ac951cd/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/1ac951cd/attachment.jpg
pass_through attribute in ADL 1.5
2012/1/25 Thomas Beale thomas.beale at 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? -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/6c0f2e0b/attachment.html
pass_through attribute in ADL 1.5
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 2012/1/25 David Moner damoca at gmail.com: 2012/1/25 Thomas Beale thomas.beale at 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? -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
pass_through attribute in ADL 1.5
Hi Pablo, The Ocean Template Desiner is now freely available from https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+R eleases. 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:sequence xs:element name=constraints minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:element name=items maxOccurs=unbounded xs:complexType xs:sequence 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: template xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns=http://schemas.openehr.org/v1; . view constraints path=/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at00 02]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046] items id=pass_through valuetrue/value /items /constraints /view /template Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Thursday, 12 January 2012 9:24 AM To: openehr technical Subject: RE: pass_through attribute in ADL 1.5 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120113/487e0f28/attachment.html
pass_through attribute in ADL 1.5
Hi Diego On 11/01/2012 03:12, Diego Bosc? wrote: 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
pass_through attribute in ADL 1.5
On 13/01/2012 08:46, Diego Bosc? wrote: 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
pass_through attribute in ADL 1.5
No, but they can be used for different things, from creating specific editors, to mindmaps or sample GUI generation 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com: On 13/01/2012 08:46, Diego Bosc? wrote: 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
pass_through attribute in ADL 1.5
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. 2012/1/10 pablo pazos pazospablo at hotmail.com: 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. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 9 Jan 2012 19:03:32 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: 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. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
pass_through attribute in ADL 1.5
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 On 10/01/2012 11:47 AM, pablo pazos pazospablo at hotmail.com wrote: 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. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- Date: Mon, 9 Jan 2012 19:03:32 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: 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. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/164f0a7f/attachment.html
pass_through attribute in ADL 1.5
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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/e7b661d9/attachment.html
pass_through attribute in ADL 1.5
Hi! From: yampeku at gmail.com Date: Wed, 11 Jan 2012 10:12:39 +0100 Subject: Re: pass_through attribute in ADL 1.5 To: openehr-technical at openehr.org 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 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/480d646c/attachment.html
pass_through attribute in ADL 1.5
On 05/01/2012 08:54, Diego Bosc? wrote: 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/b95561fd/attachment.html -- next part -- A non-text attachment was scrubbed... Name: fdcdijfa.png Type: image/png Size: 8902 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/b95561fd/attachment.png
pass_through attribute in ADL 1.5
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': 1) Pure GUI related (such as passthrough or depicting a particular GUI widget, style etc.) 2) Assumed (e.g. to render a textbox for DV_TEXT or draw a frame/indend children nodes under CLUSTER) 3) 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 Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale Sent: Tuesday, 10 January 2012 8:04 a.m. To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: 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
pass_through attribute in ADL 1.5
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. On Mon, Jan 9, 2012 at 7:03 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 05/01/2012 08:54, Diego Bosc? wrote: 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/7e3bd9d7/attachment.html -- next part -- A non-text attachment was scrubbed... Name: fdcdijfa.png Type: image/png Size: 8902 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120109/7e3bd9d7/attachment.png
pass_through attribute in ADL 1.5
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.
