GUI-directives/hints again (Was: Developing usable GUIs)
Hi Pablo, In both ADL1.4 and 1.5 every path is still an archetype-based path. The proposed schema for an operational template is very similar to the XML schema of an individual archetype but obviously includes multiple aggregated archetypes and omits any nodes which are constrained out. Templates are technically identical to specialised archetypes. The difference is that specialised archetypes support templating features such as constraining out unwanted elements and aggregating archetypes. The only difference between an archetype and a template is that new content i.e. new nodes or terms cannot be added to a template. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at 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 On 8 December 2010 16:55, pablo pazos wrote: > I agree with your comment, but only for v1.5 templates and archetypes. For > v1.4 I think that GUI Templates must reference archetypes ids and paths. > > -- > Kind regards, > A/C Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos > > > > > Date: Wed, 8 Dec 2010 15:41:11 + > From: thomas.beale at oceaninformatics.com > To: openehr-technical at openehr.org > Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) > > On 08/12/2010 15:26, pablo pazos wrote: > > May be if we change the terminology to GUI Templates and openEHR Templates, > we will not have these problems. > > I think the only thing in common of those two type of template is that they > reference a set of archetypes to do something. > > > I would suggest that the GUI templates just reference paths found in the > openEHR template. > > - thomas > > > ___ 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 > >
GUI-directives/hints again (Was: Developing usable GUIs)
On 08/12/2010 15:26, pablo pazos wrote: > May be if we change the terminology to GUI Templates and openEHR > Templates, we will not have these problems. > > I think the only thing in common of those two type of template is that > they reference a set of archetypes to do something. > * > * I would suggest that the GUI templates just reference paths found in the openEHR template. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/57ab6747/attachment.html>
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Ian, If I understand what Thomas said "I would suggest that the GUI templates just reference paths found in the openEHR template", the paths in a GUI Template will come "only" from openEHR templates (the structural ones), not from archetypes (this is apart from that they are technically the same thing). I think in ADL 1.4 the template specification is not complete, I would say that in 1.4 Templates are not so clear Archetype specializations. In ADL 1.5 is more clear the relationship of Templates and Archetypes. What I meant in the previous mail was: for us who have developed applications over ADL 1.4, our GUI Templates will use paths "directly" from Archetypes, instead of paths from openEHR structural Templates. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > From: Ian.McNicoll at oceaninformatics.com > Date: Wed, 8 Dec 2010 17:30:38 + > Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) > To: openehr-technical at openehr.org > > Hi Pablo, > > In both ADL1.4 and 1.5 every path is still an archetype-based path. > The proposed schema for an operational template is very similar to the > XML schema of an individual archetype but obviously includes multiple > aggregated archetypes and omits any nodes which are constrained out. > > Templates are technically identical to specialised archetypes. The > difference is that specialised archetypes support templating features > such as constraining out unwanted elements and aggregating archetypes. > > The only difference between an archetype and a template is that new > content i.e. new nodes or terms cannot be added to a template. > > Ian > > Dr Ian McNicoll > office / fax +44(0)1536 414994 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/42cd0939/attachment.html>
GUI-directives/hints again (Was: Developing usable GUIs)
On 08/12/2010 14:32, Ian McNicoll wrote: > Hi Koray, > > I agree with Thomas here, Koray, but I take your point about the > separation into a further layer represents added potential development > complexity. well... software engineering history would say otherwise. Where a concept is needed you have two choices: * A) mix it in with the languages & architectural layers you already have * B) create a dedicated layer or component type, and possibly dedicated formalism if needed A) represents the history of large scale systems built in the 60s, 70s and 80s - unmaintainable spaghetti. B), if done right is always better. > I think we should expect tools to handle this in the same > way that a complex development environment like Visual Studio handles > various layers of application 'code' and resources within a seamless > environment. You should not have to think about these separate layers > during development. exactly - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/71781480/attachment.html>
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Koray, I agree with Thomas here, Koray, but I take your point about the separation into a further layer represents added potential development complexity. I think we should expect tools to handle this in the same way that a complex development environment like Visual Studio handles various layers of application 'code' and resources within a seamless environment. You should not have to think about these separate layers during development. Your comments about 'isCoreConcept' are very interesting because I think you have touched upon an issue in semantics that we are coming across, particularly when modelling detailed clinical findings. I had been thinking about the same issue from a different angle, essentially how to cleanly model findings where the requirement might expand gradually from a Y/N response to a full blown complex structure, in different clinical contexts and over time as more detailed requirements emerge. It touches upon the crucial areas of integration with SNOMED post-coordinations and the handling of Questionnaire type structures but I think we should continue this discussion is a separate clinical thread because it is definitely not just an issue of GUI. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at 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 On 8 December 2010 14:14, Thomas Beale wrote: > On 06/12/2010 21:06, Koray Atalag wrote: > > For us this was a no brainer because I think ALL pure GUI stuff should go to > Templates. I have explained my reasoning in a previous message but shortly > archetypes and templates are all about information capture and validation > (i.e. which data items, their organisation, and basic constraints for > validation). Real world semantics are delegated to terminology (i.e. heart > murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I > think we need to keep archetypes fairly pure and generic with large scale > interoperability in mind. However templates provide all the convenience > needed otherwise. > > I strongly believe we do_not_need another layer of modelling for GUI because > referring back to my definition of clinical models, these are to do with > information capture and validation... > > Only one problem with this reasoning: templates are often used for things > other than the GUI, e.g. messages. In the future, they will end up being > used for reports as well. In general, I believe the openEHR template will be > an artefact defining a specific data set (including optionality where > needed), and auxiliary artefacts will always be needed to connect that > definition to its target technology: a specific kind of GUI form, message > infrastructure or relational mapping or querying environment > > - thomas > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
GUI-directives/hints again (Was: Developing usable GUIs)
On 06/12/2010 21:06, Koray Atalag wrote: > > For us this was a no brainer because I think ALL pure GUI stuff should go to > Templates. I have explained my reasoning in a previous message but shortly > archetypes and templates are all about information capture and validation > (i.e. which data items, their organisation, and basic constraints for > validation). Real world semantics are delegated to terminology (i.e. heart > murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I > think we need to keep archetypes fairly pure and generic with large scale > interoperability in mind. However templates provide all the convenience > needed otherwise. > > I strongly believe we do_not_need another layer of modelling for GUI because > referring back to my definition of clinical models, these are to do with > information capture and validation... Only one problem with this reasoning: templates are often used for things other than the GUI, e.g. messages. In the future, they will end up being used for reports as well. In general, I believe the openEHR template will be an artefact defining a specific data set (including optionality where needed), and auxiliary artefacts will always be needed to connect that definition to its target technology: a specific kind of GUI form, message infrastructure or relational mapping or querying environment - thomas * * -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/10e1b4ce/attachment.html>
GUI-directives/hints again (Was: Developing usable GUIs)
I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 8 Dec 2010 15:41:11 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 08/12/2010 15:26, pablo pazos wrote: May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. I would suggest that the GUI templates just reference paths found in the openEHR template. - 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/20101208/679651d3/attachment.html>
GUI-directives/hints again (Was: Developing usable GUIs)
May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 8 Dec 2010 14:14:04 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 06/12/2010 21:06, Koray Atalag wrote: For us this was a no brainer because I think ALL pure GUI stuff should go to Templates. I have explained my reasoning in a previous message but shortly archetypes and templates are all about information capture and validation (i.e. which data items, their organisation, and basic constraints for validation). Real world semantics are delegated to terminology (i.e. heart murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I think we need to keep archetypes fairly pure and generic with large scale interoperability in mind. However templates provide all the convenience needed otherwise. I strongly believe we do_not_need another layer of modelling for GUI because referring back to my definition of clinical models, these are to do with information capture and validation... Only one problem with this reasoning: templates are often used for things other than the GUI, e.g. messages. In the future, they will end up being used for reports as well. In general, I believe the openEHR template will be an artefact defining a specific data set (including optionality where needed), and auxiliary artefacts will always be needed to connect that definition to its target technology: a specific kind of GUI form, message infrastructure or relational mapping or querying environment - thomas ___ 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/20101208/81e70a7e/attachment.html>
