PatientOS archetype to form demo (of sorts)
Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Here is the video example of doing blood pressure: http://www.patientos.org/software/video_files/openehr/patientos_openehr.htm If you are curious as to how the other forms came out you can view the demo (one at a time) here: http://www.patientos.org/demo.htm username/password demo/demo - double click a patient, forms tab and press new form. It is running via a java applet which has a number of warnings to start. You do need privs on your machine - no sure what the min version of java is. One can build new forms using selected controls from the existing forms. Later I will make the archetype based forms templates, not actual forms you can select. One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. All work in progress of course!. Greg
PatientOS archetype to form demo (of sorts)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/369dde18/attachment.html
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.) Could anybody detail it's intended use a bit more? I think GUI rendering hints can be appropriate to specify at the same point in time as template design is taking place. If the hints are to be persisted in the template file or in a separate file I guess could be discussed, keeping it in the file could have maintenance advantages, but probably has some disadvantages too. Thoughts? (And no, GUI hints are not appropriate in Archetypes since they are meant to have a wider reuse and the use cases are not known in the same detail as for templates.) In some of our implementation experiments and in discussions with clinicians a possible need for specifying detail levels in templates have surfaced. Some elements from archetypes are easy to completely dismiss or include for the specific use case in mind when designing a template clinicians will say things like this will always be needed or this will never be needed. Other things could be conditional and trickier you can't have all these details om the form - users would go crazy - let them show up if i click a plus-button or if i tick value x was true. The requirement to use GUI screen area optimally is even more pressing when using small input devices such as PDAs. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One naive/simple but useful way of using the integer could be to add a plus-button for things with detail level 1 and within that subform have further plus buttons for level 2 and so on. The conditional requirements are trickier and probably needs more experimentation and evaluation than can be allowed if a first template specification should be completed and released within reasonable time (we all want that). The conditions might also in some cases better be specified in decision support or workflow than in templates. Also a look at the previous work with gradually expanding forms in Clinergy/PenPad should be considered, I believe they were partly auto generated from ontologies. Thoughts? Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
PatientOS archetype to form demo (of sorts)
Hi Greg! The demo looks great, keep the good work =) /Rong On Fri, Jun 27, 2008 at 7:08 AM, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Here is the video example of doing blood pressure: http://www.patientos.org/software/video_files/openehr/patientos_openehr.htm If you are curious as to how the other forms came out you can view the demo (one at a time) here: http://www.patientos.org/demo.htm username/password demo/demo - double click a patient, forms tab and press new form. It is running via a java applet which has a number of warnings to start. You do need privs on your machine - no sure what the min version of java is. One can build new forms using selected controls from the existing forms. Later I will make the archetype based forms templates, not actual forms you can select. One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. All work in progress of course!. Greg ___ 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/20080627/a734b061/attachment.html
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/0f069d83/attachment.html
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi Eric, Good points. As you know, the NHS use of openEHR to date has been to specify clinical content for the iSoft Lorenzo product, particularly for a number of user-specified forms. One of the areas of difficulty has been the tension between keeping the Template as a description of use-case data content and the requirement to match the UI of the end-user form, both for cross-checking by the users and for the application designers. We found that there is a limit to the extent that this can be done without compromising the quality of the template and underlying archetypes. There is a clear need for some UI rendering suggestions/rules but current thinking is that is best left to another layer of documentation, rather than including it within the Template spec. We did experiment with some 'dummy' UI instruction archetypes but this remains somewhat clumsy. There are a couple of exceptions which through current Ocean use are within the Template Spec 1. 'Hide from UI' is used, very specifically to hide intermediate branch nodes from HTML and Ocean forms representations of the Template. e.g Patient Details Name Structured Name Surname is flattened to Patient Details Surname in the HTML and Ocean forms output. 2. Conditional visiblilty. As you suggest, this can become highly complex but there are some simple, universal conditionals which should be true for all instances e.g Only display if the patient is female, or over a certain age. The latest version of the Ocean Template Editor supports this feature but it is not designed to deal with complex interaction between data and UI, which starts to encroach on decision/ workflow support, or with other 'static' UIrendering advice,like only display if button x is pressed - this is probably best left to a higher layer. A further discussion of the possible requirements for supra-Template UI rendering would be very helpful. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? www.phcsg.org 2008/6/27 Erik Sundvall erisu at imt.liu.se: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.) Could anybody detail it's intended use a bit more? I think GUI rendering hints can be appropriate to specify at the same point in time as template design is taking place. If the hints are to be persisted in the template file or in a separate file I guess could be discussed, keeping it in the file could have maintenance advantages, but probably has some disadvantages too. Thoughts? (And no, GUI hints are not appropriate in Archetypes since they are meant to have a wider reuse and the use cases are not known in the same detail as for templates.) In some of our implementation experiments and in discussions with clinicians a possible need for specifying detail levels in templates have surfaced. Some elements from archetypes are easy to completely dismiss or include for the specific use case in mind when designing a template clinicians will say things like this will always be needed or this will never be needed. Other things could be conditional and trickier you can't have all these details om the form - users would go crazy - let them show up if i click a plus-button or if i tick value x was true. The requirement to use GUI screen area optimally is even more pressing when using small input devices such as PDAs. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One naive/simple but useful way of using the integer could be to add a plus-button for things with detail level 1 and within that subform have further plus buttons for level 2 and so on. The conditional requirements are trickier and probably needs more experimentation and evaluation than can be allowed if a first template specification should be completed and released within reasonable time (we all want that). The conditions might also in some cases better be specified in decision support or workflow than in templates. Also a look at the previous work with gradually expanding forms in Clinergy/PenPad should be considered, I believe they were partly auto generated from ontologies. Thoughts? Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 ___ 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 -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/7dd7fcde/attachment.asc
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. I agree with Hugh - I would push back very strongly on the concept of UI hints in the template definitions. I'd make the point that everyone always thinks that given enough hints computers will be able to intelligently lay out interface components (not just in openehr world - I have seen this in many UI projects). Invariably, the autogenerated interfaces are the exception rather than the rule - by that, I mean that the autogenerated interfaces can be made useful but most real users end up preferring an interface layout designed explicitly by a human being. The classic case in point for this is indeed the blood pressure archetype - where any real user interface would present the data [systolic] / [diastolic] and yet there is no real reason why this is the case (that could be deduced by a computer) Andrew
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi all, I think that Eric has a point. I had the same experience when designing a template. I had thoughts about functions in the GUI that I couldn't save together with the template. IMveryHO, the suggestions about how clinicians want the actual GUI to look and work when they are designing their templates should be accommodated for. Just some thoughts: It is not easy to distinguish between just semantics (the template) and the GUI, which is after all all clinicians have to work with in clinical practice. Perhaps clinicians will only want to speak about what informations needs to be presented how, where and when? Perhaps they don't care about the difference between semantics and workflow, GUI, etc.? Anyway, it is intuitive to discuss this in one and the same session. The suggestions for workflow or the GUI could be in the form of hints for auto-generation of the GUI, or just text comments for the human GUI designer. Maybe the template designer can have a layer for non-semantic information linked to points in the template intended for GUI designers, that will not end up in the actual template definitions? Or, another tool could be designed for GUI design. The clinicians will work with this tool, after which Template designers distil the semantics for the templates. As I said, just some ideas. Josina Freriks Tim Cook schreef: These are certainly implementation specific issues and IMHO should (must) be left there. --Tim On Fri, 2008-06-27 at 09:05 +0100, Ian McNicoll wrote: Hi Eric, Good points. As you know, the NHS use of openEHR to date has been to specify clinical content for the iSoft Lorenzo product, particularly for a number of user-specified forms. One of the areas of difficulty has been the tension between keeping the Template as a description of use-case data content and the requirement to match the UI of the end-user form, both for cross-checking by the users and for the application designers. We found that there is a limit to the extent that this can be done without compromising the quality of the template and underlying archetypes. There is a clear need for some UI rendering suggestions/rules but current thinking is that is best left to another layer of documentation, rather than including it within the Template spec. We did experiment with some 'dummy' UI instruction archetypes but this remains somewhat clumsy. There are a couple of exceptions which through current Ocean use are within the Template Spec 1. 'Hide from UI' is used, very specifically to hide intermediate branch nodes from HTML and Ocean forms representations of the Template. e.g Patient Details Name Structured Name Surname is flattened to Patient Details Surname in the HTML and Ocean forms output. 2. Conditional visiblilty. As you suggest, this can become highly complex but there are some simple, universal conditionals which should be true for all instances e.g Only display if the patient is female, or over a certain age. The latest version of the Ocean Template Editor supports this feature but it is not designed to deal with complex interaction between data and UI, which starts to encroach on decision/ workflow support, or with other 'static' UIrendering advice,like only display if button x is pressed - this is probably best left to a higher layer. A further discussion of the possible requirements for supra-Template UI rendering would be very helpful. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? www.phcsg.org 2008/6/27 Erik Sundvall erisu at imt.liu.se: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi all, in my opinion it is i) important to have some form of GUI layout descriptions that really enable smart GUI generation in the long run. If not, the whole automatic process stops just before the GUI, which is not really the best we can do in the long run I think. ii) However, it is important to keep this separate from templates. For example, to be able to display what is in a template on different devices ranging from normal to computers via PDAs to potentially your mobile phone, different GUI principles may apply. So essentially to me this sound like it is 1 template to n GUI layout descriptions. Regards Sebastian J.P. Freriks wrote: Hi all, I think that Eric has a point. I had the same experience when designing a template. I had thoughts about functions in the GUI that I couldn't save together with the template. IMveryHO, the suggestions about how clinicians want the actual GUI to look and work when they are designing their templates should be accommodated for. Just some thoughts: It is not easy to distinguish between just semantics (the template) and the GUI, which is after all all clinicians have to work with in clinical practice. Perhaps clinicians will only want to speak about what informations needs to be presented how, where and when? Perhaps they don't care about the difference between semantics and workflow, GUI, etc.? Anyway, it is intuitive to discuss this in one and the same session. The suggestions for workflow or the GUI could be in the form of hints for auto-generation of the GUI, or just text comments for the human GUI designer. Maybe the template designer can have a layer for non-semantic information linked to points in the template intended for GUI designers, that will not end up in the actual template definitions? Or, another tool could be designed for GUI design. The clinicians will work with this tool, after which Template designers distil the semantics for the templates. As I said, just some ideas. Josina Freriks Tim Cook schreef: These are certainly implementation specific issues and IMHO should (must) be left there. --Tim On Fri, 2008-06-27 at 09:05 +0100, Ian McNicoll wrote: Hi Eric, Good points. As you know, the NHS use of openEHR to date has been to specify clinical content for the iSoft Lorenzo product, particularly for a number of user-specified forms. One of the areas of difficulty has been the tension between keeping the Template as a description of use-case data content and the requirement to match the UI of the end-user form, both for cross-checking by the users and for the application designers. We found that there is a limit to the extent that this can be done without compromising the quality of the template and underlying archetypes. There is a clear need for some UI rendering suggestions/rules but current thinking is that is best left to another layer of documentation, rather than including it within the Template spec. We did experiment with some 'dummy' UI instruction archetypes but this remains somewhat clumsy. There are a couple of exceptions which through current Ocean use are within the Template Spec 1. 'Hide from UI' is used, very specifically to hide intermediate branch nodes from HTML and Ocean forms representations of the Template. e.g Patient Details Name Structured Name Surname is flattened to Patient Details Surname in the HTML and Ocean forms output. 2. Conditional visiblilty. As you suggest, this can become highly complex but there are some simple, universal conditionals which should be true for all instances e.g Only display if the patient is female, or over a certain age. The latest version of the Ocean Template Editor supports this feature but it is not designed to deal with complex interaction between data and UI, which starts to encroach on decision/ workflow support, or with other 'static' UIrendering advice,like only display if button x is pressed - this is probably best left to a higher layer. A further discussion of the possible requirements for supra-Template UI rendering would be very helpful. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? www.phcsg.org 2008/6/27 Erik Sundvall erisu at imt.liu.se: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
I think it is possible to make use of the auto-generation capacity afforded by templates to create a draft form, which at least removes some of the grunt work in creating components and binding them tothe the underlying data cnstructs. This can then be manually adjusted and amened to best suit the device used, usability issues and aesthetics. It should be possible to design environments where this can be acheived without breaking the correlation to the underlying template by using some sort of node data-binding link. The Ocean from designer, though not a thing of aesthetic beauty, does allow form components to be resized and moved. Josina - I think it would be a mistake to try to cram in the separate UI requirements to the template designer,. I think there is a place for a specific UI demo tool that lets users and developers investigate appropriate UI options. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? www.phcsg.org 2008/6/27 Sebastian Garde sebastian.garde at oceaninformatics.com: Hi all, in my opinion it is i) important to have some form of GUI layout descriptions that really enable smart GUI generation in the long run. If not, the whole automatic process stops just before the GUI, which is not really the best we can do in the long run I think. ii) However, it is important to keep this separate from templates. For example, to be able to display what is in a template on different devices ranging from normal to computers via PDAs to potentially your mobile phone, different GUI principles may apply. So essentially to me this sound like it is 1 template to n GUI layout descriptions. Regards Sebastian J.P. Freriks wrote: Hi all, I think that Eric has a point. I had the same experience when designing a template. I had thoughts about functions in the GUI that I couldn't save together with the template. IMveryHO, the suggestions about how clinicians want the actual GUI to look and work when they are designing their templates should be accommodated for. Just some thoughts: It is not easy to distinguish between just semantics (the template) and the GUI, which is after all all clinicians have to work with in clinical practice. Perhaps clinicians will only want to speak about what informations needs to be presented how, where and when? Perhaps they don't care about the difference between semantics and workflow, GUI, etc.? Anyway, it is intuitive to discuss this in one and the same session. The suggestions for workflow or the GUI could be in the form of hints for auto-generation of the GUI, or just text comments for the human GUI designer. Maybe the template designer can have a layer for non-semantic information linked to points in the template intended for GUI designers, that will not end up in the actual template definitions? Or, another tool could be designed for GUI design. The clinicians will work with this tool, after which Template designers distil the semantics for the templates. As I said, just some ideas. Josina Freriks Tim Cook schreef: These are certainly implementation specific issues and IMHO should (must) be left there. --Tim On Fri, 2008-06-27 at 09:05 +0100, Ian McNicoll wrote: Hi Eric, Good points. As you know, the NHS use of openEHR to date has been to specify clinical content for the iSoft Lorenzo product, particularly for a number of user-specified forms. One of the areas of difficulty has been the tension between keeping the Template as a description of use-case data content and the requirement to match the UI of the end-user form, both for cross-checking by the users and for the application designers. We found that there is a limit to the extent that this can be done without compromising the quality of the template and underlying archetypes. There is a clear need for some UI rendering suggestions/rules but current thinking is that is best left to another layer of documentation, rather than including it within the Template spec. We did experiment with some 'dummy' UI instruction archetypes but this remains somewhat clumsy. There are a couple of exceptions which through current Ocean use are within the Template Spec 1. 'Hide from UI' is used, very specifically to hide intermediate branch nodes from HTML and Ocean forms representations of the Template. e.g Patient Details Name Structured Name Surname is flattened to Patient Details Surname in the HTML and Ocean forms output. 2. Conditional visiblilty. As you suggest, this can become highly complex but there are some simple, universal conditionals which should be true for all instances e.g Only display if the patient is female, or over a certain age. The latest version of the Ocean Template Editor supports this
GUI-hints in openEHR templates? (Was: PatientOS archetype to formdemo (of sorts))
Within the NHS in the UK we are experiencing a similar need. We wish to be able to define the visual presentation of a given template so that it can be ( in our case ) rendered in a format that is sensible for end-user review. The current experiences we have when clinicians review the HTML rendered templates are not productive. There is too much discussion on the aesthetics of the form rather than the actual content. We are currently considering using a process of applying a style to a template. This would allow the visual aspects of each data point to be controlled ( i.e. screen position, control type i.e. checkbox, combo box etc ). It would be great to see what requirements others in the community might need for such a tool. We are likely to commission the creation of a tool in the near future. regards Richard Kavanagh Interoperability Development Manager NHS Connecting for Health Richard.Kavanagh at nhs.net www.connectingforhealth.nhs.uk NHS Connecting for Health supports the NHS in providing better, safer care by delivering computer systems and services which improve the way patient information is stored and accessed. -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde Sent: 27 June 2008 10:31 To: openehr-technical at openehr.org Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to formdemo (of sorts)) Hi all, in my opinion it is i) important to have some form of GUI layout descriptions that really enable smart GUI generation in the long run. If not, the whole automatic process stops just before the GUI, which is not really the best we can do in the long run I think. ii) However, it is important to keep this separate from templates. For example, to be able to display what is in a template on different devices ranging from normal to computers via PDAs to potentially your mobile phone, different GUI principles may apply. So essentially to me this sound like it is 1 template to n GUI layout descriptions. Regards Sebastian J.P. Freriks wrote: Hi all, I think that Eric has a point. I had the same experience when designing a template. I had thoughts about functions in the GUI that I couldn't save together with the template. IMveryHO, the suggestions about how clinicians want the actual GUI to look and work when they are designing their templates should be accommodated for. Just some thoughts: It is not easy to distinguish between just semantics (the template) and the GUI, which is after all all clinicians have to work with in clinical practice. Perhaps clinicians will only want to speak about what informations needs to be presented how, where and when? Perhaps they don't care about the difference between semantics and workflow, GUI, etc.? Anyway, it is intuitive to discuss this in one and the same session. The suggestions for workflow or the GUI could be in the form of hints for auto-generation of the GUI, or just text comments for the human GUI designer. Maybe the template designer can have a layer for non-semantic information linked to points in the template intended for GUI designers, that will not end up in the actual template definitions? Or, another tool could be designed for GUI design. The clinicians will work with this tool, after which Template designers distil the semantics for the templates. As I said, just some ideas. Josina Freriks Tim Cook schreef: These are certainly implementation specific issues and IMHO should (must) be left there. --Tim On Fri, 2008-06-27 at 09:05 +0100, Ian McNicoll wrote: Hi Eric, Good points. As you know, the NHS use of openEHR to date has been to specify clinical content for the iSoft Lorenzo product, particularly for a number of user-specified forms. One of the areas of difficulty has been the tension between keeping the Template as a description of use-case data content and the requirement to match the UI of the end-user form, both for cross-checking by the users and for the application designers. We found that there is a limit to the extent that this can be done without compromising the quality of the template and underlying archetypes. There is a clear need for some UI rendering suggestions/rules but current thinking is that is best left to another layer of documentation, rather than including it within the Template spec. We did experiment with some 'dummy' UI instruction archetypes but this remains somewhat clumsy. There are a couple of exceptions which through current Ocean use are within the Template Spec 1. 'Hide from UI' is used, very specifically to hide intermediate branch nodes from HTML and Ocean forms representations of the Template. e.g Patient Details Name Structured Name Surname is flattened to Patient Details Surname in the HTML and Ocean forms output. 2. Conditional visiblilty. As
GUI-hints in openEHR templates? (Was: PatientOS archetype to formdemo (of sorts))
than in templates. Also a look at the previous work with gradually expanding forms in Clinergy/PenPad should be considered, I believe they were partly auto generated from ontologies. Thoughts? Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 __ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/b5b706d2/attachment.asc
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need to add specific things for these other uses and it might get very messy. regards Hugh Erik Sundvall wrote: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.) Could anybody detail it's intended use a bit more? I think GUI rendering hints can be appropriate to specify at the same point in time as template design is taking place. If the hints are to be persisted in the template file or in a separate file I guess could be discussed, keeping it in the file could have maintenance advantages, but probably has some disadvantages too. Thoughts? (And no, GUI hints are not appropriate in Archetypes since they are meant to have a wider reuse and the use cases are not known in the same detail as for templates.) In some of our implementation experiments and in discussions with clinicians a possible need for specifying detail levels in templates have surfaced. Some elements from archetypes are easy to completely dismiss or include for the specific use case in mind when designing a template clinicians will say things like this will always be needed or this will never be needed. Other things could be conditional and trickier you can't have all these details om the form - users would go crazy - let them show up if i click a plus-button or if i tick value x was true. The requirement to use GUI screen area optimally is even more pressing when using small input devices such as PDAs. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One naive/simple but useful way of using the integer could be to add a plus-button for things with detail level 1 and within that subform have further plus buttons for level 2 and so on. The conditional requirements are trickier and probably needs more experimentation and evaluation than can be allowed if a first template specification should be completed and released within reasonable time (we all want that). The conditions might also in some cases
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
On Fri, 2008-06-27 at 12:30 +0200, Thilo Schuler wrote: I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Not withstanding your 'where appropriate' caveat. The clinicians creating templates (as with archetypes) need to have training and a special understanding of what is at stake. If the clinicians designing archetypes/templates do not care about the difference between semantics and GUI stuff then they are they wrong clinicians to be designing archetypes and templates. sarcasm They should probably be designing another By Physicians for Physicians EMR. Do we really need another one of those? We also do not need another EHR built by clueless IT people. /sarcasm That's not meant to disparage the clinicians on the various openEHR mailing lists. This is a multidisciplinary issue and it takes all of us to do this the right way. Again, the 'right' people must be the ones designing the knowledge modules. My 2 pence. --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/976968f8/attachment.asc
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
On Fri, Jun 27, 2008 at 07:54:36AM -0300, Tim Cook wrote: They should probably be designing another By Physicians for Physicians EMR. Do we really need another one of those? No we don't and some of them are only still existing until sufficiently advanced OpenEHR based implementations exist (and, no, PatientOS doesn't count towards that because its focus quite apparently is inpatient care). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
GUI-hints in openEHR templates?
Similar to others we customize the GUI in the form builder tool where complex logic (hiding controls, looking up values, validation, business logic etc) can be added. It would be a large (but noble) effort to implement that in templates or even separate presentation templates (my preference) for automation. However my question is if we want true interoperability are we expecting a completed form created in PatientOS to be edited in an external openEHR system? If we are, I can see issues if I determined a field to be a large multiline text field (e.g. comments on this vitals form: http://www.patientos.org/forum_temp/vitals_form.png)) but the external system created a short single text box. The net effect would be visually truncated data - unless it is unreasonable to expect we can swap and edit documents. Perhaps that is just an implementation detail to be hacked out. Greg http://www.patientos.org
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
? (And no, GUI hints are not appropriate in Archetypes since they are meant to have a wider reuse and the use cases are not known in the same detail as for templates.) In some of our implementation experiments and in discussions with clinicians a possible need for specifying detail levels in templates have surfaced. Some elements from archetypes are easy to completely dismiss or include for the specific use case in mind when designing a template clinicians will say things like this will always be needed or this will never be needed. Other things could be conditional and trickier you can't have all these details om the form - users would go crazy - let them show up if i click a plus-button or if i tick value x was true. The requirement to use GUI screen area optimally is even more pressing when using small input devices such as PDAs. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One naive/simple but useful way of using the integer could be to add a plus-button for things with detail level 1 and within that subform have further plus buttons for level 2 and so on. The conditional requirements are trickier and probably needs more experimentation and evaluation than can be allowed if a first template specification should be completed and released within reasonable time (we all want that). The conditions might also in some cases better be specified in decision support or workflow than in templates. Also a look at the previous work with gradually expanding forms in Clinergy/PenPad should be considered, I believe they were partly auto generated from ontologies. Thoughts? Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/http://www.imt.liu.se/%7Eerisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Clinical Director Ocean Informatics Pty Ltd M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: www.oceaninformatics.com ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/dc348a5c/attachment.html
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Very interesting - maybe we could have seperate namespaces for the core tags and extensions. Could be a good compromise! While I see the advantages of keeping GUI stuff out of the template, I also see that this more and more complicated as we add additional abstraction layers. On Fri, Jun 27, 2008 at 2:26 PM, Rong Chen rong.acode at gmail.com wrote: Hi all, My thoughts on this is so far our experience with templates are mostly related to screen forms and GUI widgets. It's probably easiest to relate to screens when engage clinicians for templates reviewing, hence the need for visual presentation of templates from the NHS work. We also want to reuse the semantics in templates to generate messages, reports etc. The question is how much 'generic' semantics can be reused from the templates built for specific purpose - screen templates, message templates and report templates. Surely the content for all types of templates will be quite different and we probably would like to have special syntax to support GUI hints, but do we need special syntax to support other uses? How about indicators for decision support, clinical research data and information lifecycle management? I am thinking about an extendable markup language that can be plugged into the core template language as a way to add extensions to templates if there is any application specific meta-data required. I am also in favour of the idea to store these extra meta-data inside the templates to ease the maintenance. When passing these templates around, the template engines can ignore the extended markup and only process the standard part if they don't recognize the extended syntax. Something like gui_markup_plugin hide_in_GUI path=.../ hide_in_GUI path=.../ /gui_markup_plugin Cheers, Rong On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler thilo.schuler at gmail.com wrote: Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need to add specific things for these other uses and it might get very messy. regards Hugh Erik Sundvall wrote: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.)
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Heather, You are correct. Do not mix things. Tools become to complex. And healthcare providers loose focus. When designing archetypes we see the archetype screen. When designing and discussing templates we see the template screen. But when discussing data entry and data presentation screens we see them. For each its own tooling and ways to present. Thinking about the presentation aspect: - There are several levels: - parts of the data/information that display urgent matters that have to be signaled and that this fact needs to be documented. - local arrangements that deal with conditional context dependent presentation, the functionality of a electronic form - local arrangements that deal with local preferences on location on the screen, presentation forms, fonts, colors, etc. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On Jun 27, 2008, at 2:40 PM, Heather Leslie wrote: Hi all, From where I sit the issue being discussed here is an old one essentially about human nature - we all respond most easily to that which we know and understand. In designing a website we know that if you want input about navigation, then don't have any meaningful content or GUI hints available or almost certainly all the feedback will be about the size or color of the button and the font and position of the heading. Similarly my concern in designing templates and getting the content reviewed appropriately is that as soon as you add interface/GUI features to make it more 'intuitive' to the clinicians their focus goes immediately to that which is more familiar. That is, the feedback tends to be related to their user interface experience (naturally gained from their day-to-day use of their current clinical system) rather than actually critiquing which archetypes have been used, which data fields are presented, and all their associated attributes, cardinality, constraints and related metadata etc etc. So my preferred response (and from positive experience) is to spend a relatively small amount of time to educate the clinicians on how to feedback appropriately and meaningfully on the pure archetypes and templates - we have done this successfully, but I suggest it is probably optimal if a clinician involved in the design (perhaps a health informatician with a leg in 'both camps') to walk them thru the models and to make it a sensible conversation. It is my opinion that the GUI design and review should be completely separate to the content design and review - mixing the two gets very confusing. Regards Heather -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/02f94708/attachment.html
