GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thilo Schuler]

Hi all,

As some of you know I am interested in XForms and would love to be
part of this community effort if and when it starts.

Currently I am co-supervising two thesis students working on a project
the uses XForms, Grails, and IBM DB2  similar to this
http://www.ibm.com/developerworks/xml/library/x-xformsruby1/index.html
(but Grails instead of Rails). The goal of the project is to have a
generic form-based documentation framework for medical data. Obviously
in the longterm I have openEHR data in mind. I don't think we will get
as far as auto-generating XForms GUIs for openEHR data, but I hope we
can hand-code a XForms GUI for the chronic wound use case I have been
building several archetypes and one template for.

To speed up the XForms hand-coding I plan to use the IBM XForms
Generator (http://www.alphaworks.ibm.com/tech/xfg) to scaffold an
initial form, which obviously needs to be customised a lot to
respresent as many of the archetype and template constraints as
possible. After submission of the instance it will be additionally
checked against the whole template data schema (TDS) on the
server-side.

I did a first test of this generator. For more details look on the
wiki: http://www.openehr.org/wiki/display/dev/IBM+XForms+Generator+Test

Cheers, Thilo


On Mon, Jun 30, 2008 at 5:42 AM, Heath Frankel
 wrote:
> Hi Thilo,
> It is interesting you have talked about the idea of scaffolding a GUI.  This
> is exactly the work Ocean is doing at present.  We have redeveloped our Web
> Forms engine to work based on this principle.  From a template developed
> using the Ocean template Designer, we now generate a Form Definition file
> based on that template using a basic (and modifiable) presentation
> transformation.  This assumes nothing about layout and only specifies the
> existence of controls within groups and incorporate the AOM constraints for
> the corresponding data bound object from the reference model.  This gives
> forms engine all the information it needs to generate a basic form at
> runtime straight from a template.  The advantage of having this form
> definition over simply creating a form straight from the template/archetype
> as demonstrated by Greg is that we can use the same artefact to customise
> the layout of the form using an editor.  The forms engine can then process
> both designed (after initial scaffolding) and auto-generated forms as
> required.  The Forms Definition format we are currently using is
> proprietary, but I would be interested give some time and reason to see how
> we can import/export into a standard format such as XForms.  However, I am
> sceptical about the use of XForms unless we utilise extensions significantly
> otherwise we lose way too much information available in the AOM constraints.
>
>
> Heath
>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thomas Beale]

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

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thilo Schuler]

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))

[Thilo Schuler]

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

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Fabiane Bizinella Nardon]

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
>>
>>
>> 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Hugh Leslie]

An HTML attachment was scrubbed...
URL: 

Template 'governance' (was RE: GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Heather Leslie]

Hi Josina,

My comments about 'pure' and 'pragmatic' modelling were regarding archetypes
rather than templates.

It is the archetypes that need governance to support interoperability, and
in general for this we need a 'purer' approach.  But there are times when an
archetype can be built for a specific local purpose for which there is no
need to share, or something practical and purpose-driven like the (now
famous) example of the Barthel index - utilizing a more pragmatic approach.

Templates don't need governance in quite the same way.  It is true that
anyone can build any template for any purpose, and as long as they use
widely accepted/agreed archetypes then the template can achieve its purpose.
Hence governance for archetypes is the key.

But in a practical sense, a discharge summary and a prescription and an
antenatal consultation all have very similar component archetypes wherever
they might be used.  It would make sense that we don't have every ward in
every hospital in every country create a discharge summary template from
scratch.  That would be duplicating work in a hugely inefficient way.  So
from my point of view it should be our goal to facilitate the sharing
templates - so that a hospital might take an existing discharge summary
template and then each ward or consultant can use this as the basis for
their own preferred way of representing patient discharge data.  

I definitely don't think we will get agreement on 'THE discharge summary
template' - and we will not be seeking to do so.  However I will be seeking
to collect examples of 'good' templates in use from diverse use-cases,
domains and geographical locations so that these can potentially be shared
and adapted for local use.  This is proposed as (not too far in the) future
functionality for the openEHR knowledge repository.

Hope this helps

Heather


-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of J.P. Freriks
Sent: Tuesday, 1 July 2008 12:24 AM
To: For openEHR technical discussions
Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to
form demo (of sorts))

Is it true that there are two types of templates: generic ones like 'lab 
request' (which contains a combination of several archetypes), and a 
further constrained version for local usage?
If so, this might mean that clinicians that are trained in openEHR could 
design the first kind of templates (like Heather Leslie proposed); while 
'local' clinicians will decide in (I believe, but correct me if I'm 
wrong: preferably) one and the same session about the local template and 
UI features.
Or, are templates generally speaking too specific to local practice (so 
that each template has to be designed locally) to make the above 
distinction?

Josina


Gerard Freriks schreef:
> 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 <mailto: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.
>
>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Chunlan Ma]

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-boun...@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.

 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080701/1e27b335/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[J.P. Freriks]

Is it true that there are two types of templates: generic ones like 'lab 
request' (which contains a combination of several archetypes), and a 
further constrained version for local usage?
If so, this might mean that clinicians that are trained in openEHR could 
design the first kind of templates (like Heather Leslie proposed); while 
'local' clinicians will decide in (I believe, but correct me if I'm 
wrong: preferably) one and the same session about the local template and 
UI features.
Or, are templates generally speaking too specific to local practice (so 
that each template has to be designed locally) to make the above 
distinction?

Josina


Gerard Freriks schreef:
> 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))

[Gerard Freriks]

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.

-- next part --
An HTML attachment was scrubbed...
URL: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Erik Sundvall]

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 iterations of discussion and redesign. If we
could capture at least some the common clinical GUI-related
requirements in a machine readable form at an early stage we could
achieve some benefits:
1. You could get a better "scaffolding" as a start in d

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Heath Frankel]

Hi Thilo,
It is interesting you have talked about the idea of scaffolding a GUI.  This
is exactly the work Ocean is doing at present.  We have redeveloped our Web
Forms engine to work based on this principle.  From a template developed
using the Ocean template Designer, we now generate a Form Definition file
based on that template using a basic (and modifiable) presentation
transformation.  This assumes nothing about layout and only specifies the
existence of controls within groups and incorporate the AOM constraints for
the corresponding data bound object from the reference model.  This gives
forms engine all the information it needs to generate a basic form at
runtime straight from a template.  The advantage of having this form
definition over simply creating a form straight from the template/archetype
as demonstrated by Greg is that we can use the same artefact to customise
the layout of the form using an editor.  The forms engine can then process
both designed (after initial scaffolding) and auto-generated forms as
required.  The Forms Definition format we are currently using is
proprietary, but I would be interested give some time and reason to see how
we can import/export into a standard format such as XForms.  However, I am
sceptical about the use of XForms unless we utilise extensions significantly
otherwise we lose way too much information available in the AOM constraints.


Heath

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Thilo Schuler
> Sent: Friday, 27 June 2008 8:00 PM
> To: For openEHR technical discussions
> Subject: Re: 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
>  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 
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 
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
> 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Heath Frankel]

Hi All,
This extension idea is used in XForms in a similar manner.  In fact this
extension mechanism is actually something that I played with 18 months ago
to represent AOM constraints of data associated with each form control
expressed in XForms.  I shelved this approach due to the complexity of
implement this approach.  I would be interested in revisiting this again
with the aid of the community.

However, Rong is proposing the opposite, having form extensions within the
template.  This could be viable.

The other consideration I had when I objected internally to the Hide-on-form
attribute provided by the Ocean Template Designer, was to have a separate
section within the template for form definition details.  This again is
borrowed from XForms where it has the multiple sections including the Model
(similar to template definition but in an instance form, although you can
also reference an XML schema in XForms I believe), and View (form
definition).  

Heath

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Thilo Schuler
> Sent: Friday, 27 June 2008 10:12 PM
> To: For openEHR technical discussions
> Subject: Re: 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  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
> >
> > 
> > 
> > 
> > 
> >
> >
> > Cheers,
> > Rong
> >
> >
> > On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler

> > 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
> >>  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
> >&

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thilo Schuler]

I am with you on that layers are important and keep the approach more
simple in the long time. As Heather pointed out, we have to be very
careful not to distract the clinicians with GUI fluff from clean
modelling. But for review and testing there is no doubt, that a real
GUI is of value. At the moment the Ocean Template Desinger does both
using the "one tool, two artefacts" approach, and as Thomas wrote it
will become better based on the NHS CUI project. The "one tool, two
artefacts" approach is good as it lets clinicians build and adapt
runnable GUIs from their authored templates, but also shows that there
can be many possible GUIs created from one template.

Having a set of core template tags and several extensions (for
GUI/message/... hints) is more a technical design choice for better
manageability and doesn't interfere with the layers (separation is
done via namespaces). Templates are mostly local artefacts and GUIs
even more so. So, as Rong said, theses markup-extensions will only be
there to ease local implementation. E.g. Ocean could have used such an
extension to create the previously mentioned Hide_in_GUI-Hint in a
clean way separated from the core template model.

Regarding Greg's comment on problems with the visibility of a certain
field: IMHO openEHR should not try to standardise GUIs (meaning
sharing GUI hints or presentation artefacts). This is a huge task and
we have enough problems solving what we are working on right now. But
I can picture a system that scaffolds a basic editable GUI based on
unknown openEHR data (provided it has access to the underlying
archetypes). This scaffolded view could then be adapted by the local
user, and the next time this user tries to access similar openEHR data
(meaning same archetypes in the same structure/order) the local system
remembers it and the customised view is used to display and edit the
data. Customisation could even go as far as choosing certain GUI
components (per archetype or per aggregated archetypes) from a
(shared!) library... But this is still all implementation specific and
not part of the openEHR specs.

Cheers, Thilo

On Fri, Jun 27, 2008 at 6:46 PM, Tim Cook  
wrote:
>
> On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote:
>> 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.
>
> Ahhh, true. It is complicated.  It is the reason why health informatics
> is where it is today.  The beauty of the openEHR specs is that each
> portion does one thing well and yet all the parts fit together.
>
> If we get carried away and start mixing the layers then the specs get
> more complex, the tools more difficult to use, applications less likely
> to inter-operate and there won't be very many implementations.
>
> 
> If you aren't careful you could end up with something HL7v3.
> 
>
> As "my buddy" Albert E. said; Make everything as simple as possible but
> no simpler.  ;-)
>
>
> --Tim
>
>
>
>
>
> --
> 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*
> **
>
> ___
> 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))

[Greg Harris]

On Fri, 27 Jun 2008 13:46:27 -0300
Tim Cook  wrote:

> 
> On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote:
> > 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.
> 
> Ahhh, true. It is complicated.  It is the reason why health
> informatics is where it is today.  The beauty of the openEHR specs is
> that each portion does one thing well and yet all the parts fit
> together.  
> 
> If we get carried away and start mixing the layers then the specs get
> more complex, the tools more difficult to use, applications less
> likely to inter-operate and there won't be very many implementations. 
> 
> 
> If you aren't careful you could end up with something HL7v3. 
> 
> 
> As "my buddy" Albert E. said; Make everything as simple as possible
> but no simpler.  ;-)
> 
> 
> --Tim
>  
As counsel for a trade group many years ago, I watched a committee work
long, earnestly, and hard to develop a proposal for a standardized set
of paper forms for claim notices. When that committee subsequently was
asked to review the adequacy of a set of draft EDIFACT messages to
communicate the same information content, they had a very difficult
time separating the information from its presentation. 

They were neither stupid nor uncommitted to the effort; their input
was both indispensable to success and immediately useful for the
developers. But for them, IT was something of a single cloud. It took a
while for them to distinguish between the separate problems of (a)
signing off on inter-company data sufficiency and (b) implementing and
presenting that data on their respective internal systems. And while
these people were volunteers in a sense, getting this done was part of
their jobs and had the full backing of their employers. But if their
input governed the back-end design and development, there would have
been no progress. It was successful (or not) project management to get
their involvement in the right amounts at the right times.

Without any qualifications whatsoever to offer a judgment on this, I
see a development interplay among three groups: the clinicians, the
developers of the underlying structure, and the designers of
implementing systems. (My guess is that's an obvious and seriously
non-profound observation.) Aside from a long anecdote, it strikes me
that UI decisions should be kept as separate as possible from any of
the underlying structure; that presumption could be rebutted where an
identified UI need can't otherwise be satisfied. Of course, at some
level that's a nullity because the UI needs really define the structure
design.

As simple as possible can be quite complex. It's amazing what's been
accomplished.

Greg Harris

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thomas Beale]

J.P. Freriks wrote:
>
> 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.
>
>   
*I think it will be one tool that writes two artefacts, one of which is 
GUI 'hints'. However, 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.

- thomas beale

*

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Heather Leslie]

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
-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Tim Cook
Sent: Friday, 27 June 2008 8:55 PM
To: For openEHR technical discussions
Subject: Re: 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. 


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.


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

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Sebastian Garde]

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 :
>>> 
 Hi!

 On Fri, Jun 27, 2008 at 07:08, Greg Caulton  
 wrote:
   
> Thanks to the java reference implementation I have a demo of importing
> archetypes to auto generate forms which have the references 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Andrew Patterson]

> 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))

[Hugh Leslie]

An HTML attachment was scrubbed...
URL: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

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

--  --
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: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Thilo Schuler]

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  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
>
> 
> 
> 
> 
>
>
> Cheers,
> Rong
>
>
> On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler 
> 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
>>  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 
>> > 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 
>> > 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

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Rong Chen]

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







Cheers,
Rong


On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler 
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
>  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 
> 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 
> 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 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

Dear all,

Archetypes are Documentation Patterns for clinical and non-clinical  
topics.
Templates are Documentation Patters used in a specific context. They  
can be considered as agreements/contracts on what to show, store, and  
exchange.
How that content of a Template is represented on the screen is the  
topic of this discussion.

On one hand: Keeps things simple. And things are simple when we  
separate as much asp possible. We separated IT from data and  
Information and it  makes a lot of sense to separate presentation of  
that data and information as well.
On the other: Objects consist of three things: Information, Methods  
and Representation. And the information and representation parts carry  
semantics.
Information represented in black is not the the same as when  
represented on a screen in RED or in CAPITALS or flickering.

Thinking about it:
Data and Information- Arche-Types (and Templates)
Presentation: Presentation-Types
Methods: Method-Types

Each Type its own tool, Model and Language
Plus one tool that integrate all three aspects of the Object.

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 27, 2008, at 8:58 AM, Erik Sundvall 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.

-- next part --
An HTML attachment was scrubbed...
URL: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Tim Cook]

On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote:
> 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.

Ahhh, true. It is complicated.  It is the reason why health informatics
is where it is today.  The beauty of the openEHR specs is that each
portion does one thing well and yet all the parts fit together.  

If we get carried away and start mixing the layers then the specs get
more complex, the tools more difficult to use, applications less likely
to inter-operate and there won't be very many implementations. 


If you aren't careful you could end up with something HL7v3. 


As "my buddy" Albert E. said; Make everything as simple as possible but
no simpler.  ;-)


--Tim
 




-- 
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: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Karsten Hilbert]

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? (Was: PatientOS archetype to form demo (of sorts))

[Thilo Schuler]

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
 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  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  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 condition

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[J.P. Freriks]

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 :
>> 
>>> Hi!
>>>
>>> On Fri, Jun 27, 2008 at 07:08, Greg Caulton  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  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 i

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Ian McNicoll]

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 :
> 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 yo

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Ian McNicoll]

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 :
> Hi!
>
> On Fri, Jun 27, 2008 at 07:08, Greg Caulton  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  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
> siz

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Erik Sundvall]

Hi!

On Fri, Jun 27, 2008 at 07:08, Greg Caulton  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  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/Pen&Pad 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

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Tim Cook]

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. 


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.


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: 

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Tim Cook]

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 :
> > Hi!
> >
> > On Fri, Jun 27, 2008 at 07:08, Greg Caulton  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  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".
> >