GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Erik Sundvall wrote: > > I obviously did not explain clearly what I meant by GUI-hints. What I > was thinking of was a bit more towards the "left" side of the spectrum > trying to capture some some of the "semantics" of the > human-computer-interaction when entering the things described by > templates. I was not thinking of colors, fonts, detailed component > placement etc. Instead I'm thinking of things like: > - Greg's suggestion that one could specify whether a text node in a > template will likely be short (e.g. a name) or if it is more likely to > be a paragraph that would benefit from a multiline-type of text entry > widget. > - In a long template that also includes a section about "tobacco use" > you might want to specify that the detailed parts regarding amount of > consumption don't need to be shown if the person has been documented > with the status "Never used". (I.e. implemented using simple > conditional statements). > - In the a particular use case in mind you might want to assign the > the subtree "Consumption, Amount of substance" a higher priority in > GUIs than the "Previous attempts to quit smoking" subtree so that the > latter gets pushed to a normally hidden collapsed/hidden subform if > there is a lack of space. (I.e. using a detail level mechanism) > - Mechanisms like "hide_in_ui" to skip intermediate things that are > meaningful in information modelling but are distracting or unnecessary > in a GUI. > most of the above are part of the CUI design ideas in the NHS, and I agree, are more 'semantic'. I think of them as 'workflow' semantics, rather than data semantics. They are a logical concept that could be implemented in presentation in more than one way. The conditionality idea (Erik's 2nd point above) is included in the new template / specialised archetype specification. Some things like the priority have not yet been considered (even by the CUI group) but probably need to be. > As you can see these things have a bit of a semantic touch also, but > maybe a different kind of semantics than we usually refer to as > semantics in this community. > > When it comes to template design it would be interesting to know if > the clinicians always are comfortable only having the on/off (set zero > occurrence) of templates (or are there more restrictions available)? > Don't you get a lot of "it depends"-answers whether to include > something in a template or not? Do you believe that answers what to > "kill" from (for the use case) overly detailed archetypes templates > would be different if the clinicians are aware of the possibilities to > change priorities, set conditional statements etc? > hence the need to add conditionality to the template spec;-) > I don't suggest that these hints necessarily should be created > simultaneously with the template editing, but I guess that the very > same clinical experts that design the template would be also good > candidates to give some GUI-hints after the template creation. > Thoughts? > > When it comes to what I call GUI-hints above I believe it would be > useful to specify a model (like the with the AM) and one or many > serialization formats of it rather than going straight for a markup > language. some of these hints will be covered by the new specialised archetype / template model. but some are not yet. I wonder if we can construct a definitive list? > Artifacts built using that model could then be used for auto > generation of GUIs (whenever that is necessary) and as input to other > steps specifying things more to the "right" in the spectrum like > dealing with specific widgets, component positioning etc. for example > I think this is true as well... > > One last thing... > > On Sat, Jun 28, 2008 at 00:18, Thomas Beale > wrote: > >> ... there are more semantic indicators being built >> into the template designer, some based on the NHS CUI project, that will >> provide good hints on GUI generation, including some temporal workflow >> aspects. >> > > Are these things or the principles behind them something you can and > would like to like detail a bit more or share with the community when > time permits? > as far as I know the CUI group's work is not secret; we have been given a list of about 10 things they want to see in a GUI, but I have to admit I have not even checked to see if this is on the relevant website. We need to find that out and make it public if it is not. - thomas beale
* (en) problem of archetype editor
Seung Jong Yu wrote: > Actually it may not be proper for this mailing list but > http://dev.oceanehr.com/mantis/main_page.php is not work now. Hi SeungJong Yu, Maybe you are using an old version of the Ocean Archetype Editor, because we haven't used Mantis for about a year. The current version's Help | Report Issue menu links to https://projects.oceaninformatics.com/jira/secure/Dashboard.jspa . - Peter
* (en) problem of archetype editor
Hi all. Actually it may not be proper for this mailing list but http://dev.oceanehr.com/mantis/main_page.php is not work now. So I am posting this mailing list. Problem is After I "Add Language" in "Language" Menu (korean in my case) in Archetype Editor, all sentences in "test & description in term_definitions" and "keywords in Header" are expressed as "* any english (en)". For example, at *Apgar score(en) *Clinical score derived from assessment of breathing, colour, muscle tone, heart rate and reflex response usually taken at 1, 5 and 10 minutes after birth(en). I think it may prevent confusion of among Languages. But in most case, it bothers me because some terms are not needed to be translated. Some terms are only used for interna. For example ["at0001"] = < description = <"@ internal @"> text = <"structure"> > ["at0002"] = < description = <"@ internal @"> text = <"history"> And in my case I translate only "text" and don't translate "description". In this case I must remove all *(en) marks. Even more I have to remove *(en) in "keywords" because "keywords" are not affected by modifyng "term_definitions" So I propose that Language should be displayed anywhere in Menu and do not add *(en). Best Regards SeungJong Yu MD, MS seungjong.yu at gmail.com (for general use) ggojang at gmail.com (for mailing lists) Researcher Center for Interoperable EHR Annex Building, Seoul National university College of Medicine 199-1 Dongsoong-Dong, Jongno-Go, Seoul, 110-810, Tel: +82-2-741-1260 Fax: +82-2-741-1240 C.P: +82-17-752-5435 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080702/234f46a5/attachment.html>
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
The advantage of deriving generic user interfaces only from data instances and the underlying archetypes (without knowing the template) is the possibility to edit unknown openEHR data, although the GUI would be simple. Thus, I agree with Chunlan on the position of a generic GUIs on Erik's spectrum. -Thilo On Tue, Jul 1, 2008 at 2:14 AM, Chunlan Ma wrote: > The Generic User Interfaces, i.e. the GUI_hints that are a bit more towards > the "left" side of the spectrum described by Eric Sundvall, would be > archetype specific rather than template specific. I personally think these > generic GUI-hints should be processed by a generic form engine that > understands archetypes only. For example, if tobacco use status value is > "Never used", which is local coded text in the substance_use archetype, the > "Method" cluster can be hidden from the form. This generic GUI_hint can be > applied to all templates or user interfaces. A more specific form engine is > required for context specific user interfaces. > > > > Cheers, > > Chunlan > > > > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Gerard Freriks > Sent: Monday, June 30, 2008 11:32 PM > To: erisu at imt.liu.se; For openEHR technical discussions > Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to > form demo (of sorts)) > > > > My spectrum: > > > > - Archetypes (generic documentation patterns) > > - Templates (context dependent documentation patterns) > > - Generic User Interfaces (generic presentation patterns) > > - User Interface (context dependent presentation patterns) > > > > Gerard > > > > > > -- -- > > 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 30, 2008, at 3:19 PM, Erik Sundvall wrote: > > Hi! > > Thanks for a lot of interesting response regarding "GUI-hints" and other > things. > > Please excuse a little left-to-right analogy below: > There seems too be a scale or spectrum of detail level and use case > specificity going from... > Left: purely semantic (maximum data set) models = archetypes > ...via the nearby... > openEHR templates (still purely semantic if we skip the "hide_in_ui" > to keep the template artifacts) > ...further far away to... > Right: actual GUI in an implemented system with specific widgets positioning > etc > > Currently openEHR specifications describe artifacts at the "left" side > of the spectrum. This discussion has interestingly been broadened > further to the "right" than I was thinking of in my initial questions. > If we look at a tool like the Template Designer from Ocean Informatics > there is an immediate jump from templates (close to the left) to > detailed GUI layout (far right), that jump could be divided into more > steps (possibly with some steps persisted and reusable) as suggested > by some in this discussion. > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
See short note inline On Mon, Jun 30, 2008 at 3:19 PM, Erik Sundvall wrote: > Hi! > > Thanks for a lot of interesting response regarding "GUI-hints" and other > things. > > Please excuse a little left-to-right analogy below: > There seems too be a scale or spectrum of detail level and use case > specificity going from... > Left: purely semantic (maximum data set) models = archetypes > ...via the nearby... > openEHR templates (still purely semantic if we skip the "hide_in_ui" > to keep the template artifacts) > ...further far away to... > Right: actual GUI in an implemented system with specific widgets positioning > etc > > Currently openEHR specifications describe artifacts at the "left" side > of the spectrum. This discussion has interestingly been broadened > further to the "right" than I was thinking of in my initial questions. > If we look at a tool like the Template Designer from Ocean Informatics > there is an immediate jump from templates (close to the left) to > detailed GUI layout (far right), that jump could be divided into more > steps (possibly with some steps persisted and reusable) as suggested > by some in this discussion. > > On Fri, Jun 27, 2008 at 10:03, Hugh Leslie > wrote: >> I don't think that templates should contain GUI rendering hints >> as they should remain purely about the semantics. > ... >> 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. > > On Fri, Jun 27, 2008 at 10:57, Andrew Patterson > wrote: >> I agree with Hugh - I would push back very strongly on the concept of >> UI hints in the template definitions. > > On Sat, Jun 28, 2008 at 00:18, Thomas Beale > wrote: >> *I think it will be one tool that writes two artefacts, one of which is >> GUI 'hints'. > > These comments seem very reasonable, could we then conclude that the > "hide_in_ui" and similar GUI-hints should not be in the template spec > and that we instead can continue discussion regarding other artifacts > with GUI-related information that might be reusable between > implementations. > > On Fri, Jun 27, 2008 at 10:57, Andrew Patterson > wrote: >> 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. > > I agree (except to "everyone always"). In most cases explicitly > layouted interfaces will be preferred, due to aesthetics, optimal use > of screen real estate etc. That's why I wrote "automated or > _semi-automated_ design". > > Consider a use case where you at a national level want to standardize > parts of the information capture in for example yearly diabetes > check-up visits in primary care in order to do statistics, data mining > etc. Also consider that a couple of parts will be added or modified on > approximately a yearly basis to improve the follow up process and > incorporate new treatments etc. Add to this that you have five openEHR > compliant vendors with hundreds of separate system installations > across the nation. > > The openEHR approach with archetypes and templates facilitate the > semantic parts of the above scenario very well and the yearly updates > of archetypes and templates can be loaded into the (purely semantic > part) system more or less with the push of a button. But what happens > on the GUI side of things? Will that always have to wait for manual > layout before the new archetypes and templates can start to be used in > clinical practice? How fast will that happen? Some vendors and > customers will certainly have the resources to swiftly incorporate the > changes but many others will experience considerable delay and would > in the meantime have to resort to either keep using the old forms and > semantics (thus loosing ability to capture data using the new national > standars) or use general GUIs based on templates only (probably not so > nice and efficient - driving clinicians crazy). > > Maybe this was just a way of restating Sebastians comment... > On Fri, Jun 27, 2008 at 11:30, Sebastian Garde wrote: >> 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. > > When manually designing the GUIs, the designers (from every vendor) > need to capture the user requirements in discussions with users, this > is often done in several i
Creating Archetypes based on questionaire
An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080702/86e69ea1/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080702/86e69ea1/attachment.JPG>
Creating Archetypes based on questionaire
Hi there, In our project, clinicians-who work in the area of oral medicine- use an online form editor that help them create forms based on their experiences any time needed. It means that each clinician can create his/her own questionnaires. (experiences in this project showed that they are eager to have their own protocol including questionnaires and data they may access )there are some forms, or templates that are more general including questions like this one named GENERAL MEDICAL HISTORY Do you consider yourself healthy? Do you currently suffer from any disease or illness? Have you previously suffered from any disease or illness? Do you currently use any medication? Have you had treatment with Steroids during the last year? Do you have any skin problem? Also we have other kinds of forms like SALIVARY GLAND DISEASE What areas were examined? What is the color of the skin/mucosa covering the salivary gland? Are there any signs of muscositis? . (I shows that there are two kinds of questions, one may be asked patient, one is for clinician herself to show what to examine or... ) well, There are some unsolved problems in my mind regarding these questions and the possibility to create Archetypes or Templates for these questionnaires like the one above. 1- Is this an appropriate design way for Archetypes to create Archetypes based on questions or actions that one may ask or may do during visit or treatment? 2- Can I map these questionnaires to Archetypes or they are more like Templates? 3- I have this methodology in my mind when I try to map things to openEHR concepts - What are the specifications on the disease I want to present , symptoms, signs, related guidelines,...(general knowledge about disease) - Which questions may I ask when a patient visits me? general patient data, patient medical history,... - Is there any protocol for data gathering? - What kind of treatments I may suggest, or any more data do I need? any related laboratory tests ? Finally, is it a proper way to think of creating an Archetype for a specific disease?I know that I should first search for existing Archetypes and combine them to create Templates, but what if I cannot find any suitable Archetype for my case? I should mention that all these efforts is to create a CDSS for a specific disease, so I need to be more specific in knowledge or data gathering. Regards Paria PhD Student IDC | Interaction Design Collegium Department of Computing Science and Engineering Chalmers University of Technology Email: hajar.kashfi at chalmers.se Office:+46 (0)31 7725407 Mobile Phone: +46 (0)707222815 Postal adress: IT University of G?teborg 412 96 G?teborg, Sweden Visit: Room Simula B, House Svea, Campus Lindholmen -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080702/938cbe66/attachment.html>
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
This was an strategy we used in our implementation and it worked very well: associate GUI-hints to archetypes and allow for someone to override the hints on specific templates, if needed. We decided to do that because, after observing the hints that field specialists associated to the same archetype in different templates, we realized that most of the time the hints were the same and could be reused. So, I agree with your position. Fabiane Thilo Schuler wrote: > The advantage of deriving generic user interfaces only from data > instances and the underlying archetypes (without knowing the template) > is the possibility to edit unknown openEHR data, although the GUI > would be simple. Thus, I agree with Chunlan on the position of a > generic GUIs on Erik's spectrum. > > -Thilo > > On Tue, Jul 1, 2008 at 2:14 AM, Chunlan Ma > wrote: > >> The Generic User Interfaces, i.e. the GUI_hints that are a bit more towards >> the "left" side of the spectrum described by Eric Sundvall, would be >> archetype specific rather than template specific. I personally think these >> generic GUI-hints should be processed by a generic form engine that >> understands archetypes only. For example, if tobacco use status value is >> "Never used", which is local coded text in the substance_use archetype, the >> "Method" cluster can be hidden from the form. This generic GUI_hint can be >> applied to all templates or user interfaces. A more specific form engine is >> required for context specific user interfaces. >> >> >> >> Cheers, >> >> Chunlan >> >> >>
