Thanks to the java reference implementation I have a demo of importing
archetypes to auto generate forms which have the references to the
archetype. Here is the video example of doing blood pressure:
http://www.patientos.org/software/video_files/openehr/patientos_openehr.htm
If you are
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/369dde18/attachment.html
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
...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/a734b061/attachment.html
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
*
**
-- 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:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/7dd7fcde
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
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
*
**
-- 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:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/b5b706d2
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
: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/976968f8/attachment.asc
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
://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/dc348a5c/attachment.html
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,
:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/02f94708/attachment.html
20 matches
Mail list logo
