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
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
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
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
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080701/22630a39/attachment.html
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
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
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
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
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
28 matches
Mail list logo
