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.
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.
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.
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@oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group – www.phcsg.org
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)
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.
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".
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@oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group – www.phcsg.org
Within the NHS in the UK we are experiencing a similar need.
We wish to be able to define the "visual" presentation of a given template
so that it can be ( in our case ) rendered in a format that is sensible for
end-user review. The current experiences we have when clinicians review the
HTML rendered templates are not productive. There is too much discussion on
the aesthetics of the "form" rather than the actual content.
We are currently considering using a process of applying a "style" to a
template. This would allow the visual aspects of each data point to be
controlled ( i.e. screen position, control type i.e. checkbox, combo box etc
).
It would be great to see what requirements others in the community might
need for such a "tool". We are likely to commission the creation of a tool
in the near future.
regards
Richard Kavanagh
Interoperability Development Manager
NHS Connecting for Health
Richard.Kavanagh@nhs.net
www.connectingforhealth.nhs.uk
NHS Connecting for Health supports the NHS in providing better, safer care
by delivering computer systems and services which improve the way patient
information is stored and accessed.
[mailto:openehr-technical-bounces@openehr.org] On Behalf Of Sebastian Garde
Are you talking about a tool that can read one or more templates and
then aide in development of a GUI that will meet the Common User
Interface specification?
That, I think, is a worthwhile approach. While it is another layer. It
does help keep the templates simple and purposeful on a semantic level.
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.
Not withstanding your 'where appropriate' caveat. The clinicians
creating templates (as with archetypes) need to have training and a
special understanding of what is at stake.
If the clinicians designing archetypes/templates do not care about the
difference between semantics and GUI stuff then they are they wrong
clinicians to be designing archetypes and templates.
<sarcasm>
They should probably be designing another "By Physicians for Physicians
EMR". Do we really need another one of those? We also do not need
another EHR built by clueless IT people.
</sarcasm>
That's not meant to disparage the clinicians on the various openEHR
mailing lists. This is a multidisciplinary issue and it takes all of us
to do this the right way. Again, the 'right' people must be the ones
designing the knowledge modules.
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).
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
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.
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
[mailto:openehr-technical-bounces@openehr.org] On Behalf Of Tim Cook
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.
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
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.
<sarcasm>
If you aren't careful you could end up with something HL7v3.
</sarcasm>
As "my buddy" Albert E. said; Make everything as simple as possible but
no simpler.
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.
