openEHR mailing lists - moving
Hi Tom, Yes, learning cost is very important. The reason why I am moving my Ruby works to GitHub is learning and maintenance cost. The most attractive point in Launchpad is translation related features, but I think it does not matter. Thank you for your reply. Regards, Shinji 2012/1/25 Thomas Beale thomas.beale at oceaninformatics.com: On 24/01/2012 02:53, Shinji KOBAYASHI wrote: Hi Tom, What about launchpad? (http://launchpad.net) I think launchpad has enough features as you mentioned. Cheers, Shinji It may well. I personally don't have experience of using more than a couple of the available technologies, so we need community members help to make such decisions. There is no strict necessity for all software projects to be in the same place, but if they are all in different places, it obviously makes supplying any common adminstrative and educational support more difficult. E.g. let's say for example we decided to stick with Atlassian for everything, then everyone could learn Jira via some webinars. If some or all projects are on Github, then people on those projects can help teach each other about using those environments. One thing I do know is that the work of learning how to use these kinds of environments should not be under-estimated. - 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
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
