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
See short note inline
On Mon, Jun 30, 2008 at 3:19 PM, Erik Sundvall erisu at imt.liu.se 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
: 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
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
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
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080701/22630a39/attachment.html
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
[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
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
My spectrum:
- Archetypes (generic documentation patterns)
- Templates (context dependent documentation patterns)
- Generic User Interfaces (generic presentation patterns)
- User Interface (context dependent presentation patterns)
Gerard
-- private --
Gerard Freriks, MD
Huigsloterdijk 378
2158
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
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
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
On Fri, 27 Jun 2008 13:46:27 -0300
Tim Cook timothywayne.cook at gmail.com 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
Hi!
On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote:
Thanks to the java reference implementation I have a demo of importing
archetypes to auto generate forms which have the references to the
archetype.
Nice. Keep up the good work.
On Fri, Jun 27, 2008 at 07:08, Greg
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/0f069d83/attachment.html
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
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
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
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
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
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
-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde
Sent: 27 June 2008 10:31
To: openehr-technical at openehr.org
Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to
formdemo (of sorts))
Hi all,
in my opinion it is
i) important
at openehr.org
Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to
formdemo (of sorts))
Hi all,
in my opinion it is
i) important to have some form of GUI layout descriptions that really
enable smart GUI generation in the long run. If not, the whole automatic
process
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
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
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
Similar to others we customize the GUI in the form builder tool where
complex logic (hiding controls, looking up values, validation,
business logic etc) can be added. It would be a large (but noble)
effort to implement that in templates or even separate presentation
templates (my preference) for
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
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,
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
31 matches
Mail list logo