Hi,
I am doing some experiments on a XML serializer for the Java archetype editor. I wonder if there are any example XML archetypes that I can look at to verify that I follow the XML-schema documentation correctly?
Regards,
Mattias
Hi all,
I am involved in an internship project with the OpenMRS (www.openmrs.org) that involves the integration of this open source web application medical record system with OpenEHR archetypes. My work is to provide only a proof of concept for the OpenEHR modelling approach by allowing implementers use OpenMRS to consume archetypes as they build forms.
My observation is that it is much easier to work with the xml archetypes (generated in the editors) than the ADL.
My question: is there any xml schema definition for these archetypes? and the templates? And please kindly where can I find them?
Will there be a specification for xml?
Thanks a lot.
Cheers,
Ime
Skype: asangansiime
http://www.wiki.ehealthpedia.org/User:Asangansi
There is nothing to fear but fear itself. - Franklin D. Roosevelt
Hi Ime
http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html
For the AM, two schemas are provided:
Ime Asangansi wrote:
(attachments)
Sam,
Thanks a lot.
I’ll be back with questions…
Ime
Hi everybody,
I am working on a project that might involve generating xforms from archetypes. While there are many possibilities in doing this (including an internal form schema designer within the OpenMRS that is infopath-based), before making design decisions, I would really like to learn from people who are using archetypes to drive Xforms generation for their app.
And how is the seemingly complex archetype ‘definition’ part handled?
Also I would really like to know how the interface in the Ocean/LiU editors are generated?
XSLT or …?
Thirdly, has or is any one working on translating openehr archetype based messages to HL7 v2? I might need to translate (or transform) Xml data to HL7.
Thanks, in anticipation.
rgds,
Ime
Hi Ime and others
XForms is an intriguing technology and IMHO (and others' !) it seems
very suited to generate forms from templates and their underlying
archetypes .
I will first point you to two recent sources where XForms where
mentioned within the openEHR community:
1. Wiki (look in the comments area):
http://www.openehr.org/wiki/display/dev/User+Interface+and+openEHR+data
2. Mailing list thread:
http://www.openehr.org/mailarchives/openehr-technical/msg03208.html
So there are several people that have thought about or have actually
implemented code regarding XForms & openEHR archetypes. I will try to
list the relevant people that I know of:
1. Carl Alfon from Linköping University (Sweden) currently writes a
thesis on "Archetype based EHR GUI". In his practical work he
generates XForms using the openEHR ADL parser plus custom code.
2. Adam Flinton from the NHS has an "complete Xml forms engine" which
can be used with (besides others) XForms ("Chiba to render into
Ajax-ified html"). He also offered that this could be open-sourced.
3. Lisa Thurston from Ocean Informatics wrote a set of
customizable/extendable XSLT scripts that creates a generic read-only
view of openEHR instance data.
4. Heath Frankel (programming lead at Ocean Informatics) and I have
thought about using the Template Data Schemas (TDS) that can be
generated from templates (using the template designer) as the basis
for the XForms model. Tests are needed whether the currenty availble
XForms engine implementations support such complex nested schemas...
5. Myself, I have the humble goal (because I have so little time) of
writing a XForms GUI for a small template with only a couple of
archetypes that connects directly to an IBM DB2 server via web
services. Will start with a static one but finally generating it would
be awesome... A first test with a trivial 4 field form was successful
in retrieving and uploading data from the DB2 server.
6. There are a couple of more ppl generally interested in openEHR
GUIs: Helma van der Linden (University of Maastricht), Erik Sundval
(University of Linköping) and Sam Heard & Hugh Leslie from Ocean
Informatics.
I think we should join forces and create a sub-project to share ideas
and maybe code for an "openEHR XForms Toolkit". I have proposed this
in December already but have been slack & busy.
What is everybody's opinion (especially the people listed) on such a project?
Regarding GUI generation in general Hugh has argued that it won't
necessarily will be the most usable forms. I think that this is true
(and for complex data entry in complicated clinical workflows it will
propably never change) and in that case the generated GUI would be a
good start to for further hand-coded customization ("scaffolding GUI
code"). However one day we might be surprised by the power of XForms
especially once the engines have become even better and special
openEHR widget extensions are available (see again
http://lib.tkk.fi/Diss/2007/isbn9789512285662/isbn9789512285662.pdf).
Will be on a long anticipated and much needed skiing holiday for the
next 7 days, so won' t be able to reply until I return.
Cheers, Thilo
PS: See one more remark inline.
Hi everybody,
I am working on a project that might involve generating xforms from
archetypes. While there are many possibilities in doing this (including an
internal form schema designer within the OpenMRS that is infopath-based),
before making design decisions, I would really like to learn from people who
are using archetypes to drive Xforms generation for their app.
And how is the seemingly complex archetype 'definition' part handled?Also I would really like to know how the interface in the Ocean/LiU editors
are generated?
XSLT or ...?
No XSLT but going recursively through the object model in the kernel
component to create a certain widget for every datatype at the leaf
nodes. But others know better.
Thilo and others,
Thanks for this remarkable and engaging read!
This will come in helpful in the project…
BTW: This is a really supportive community
But it will be nice to hear from the guys who did the things you outlined…
It will be nice to have such a project… it will also be a step towards a pure full blown open-source openehr implementation
rgds,
Ime
Ime Asangansi wrote:
Thilo and others,
Thanks for this remarkable and engaging read!
This will come in helpful in the project...BTW: This is a really supportive community
But it will be nice to hear from the guys who did the things you
outlined...
It will be nice to have such a project... it will also be a step
towards a pure full blown open-source openehr implementationrgds,
Ime
Hi Ime, Thilo and all
We investigated using XForms for automatically-generated data entry GUIs
last year. There are some features of XForms which made it seem
particularly well suited to the task: a lot of built-in entry data
validation, ability to validate data against a schema embedded in the
XForms definition, ability to decouple the connection between an input
widget and the target item in the schema by using an XForms binding
item... not to mention being a completely open, platform-independent and
XML-based standard (even if there's very limited browser support thus
far), etc. It was a while ago, so I have probably forgotten some other pros.
But gradually it came to feel like we were trying to force XForms to do
something it is too generic/low-level to be suited to. The main
challenges were:
1. The existing XForms implementations were generally immature/flaky or
not in line with the latest XForms specification.
2. The openEHR DATA_VALUE types are of a larger grain than most of the
XForms widgets, so more than one XForm widget, more than one databinding
and more than one binding constraint had to be defined per openEHR
ELEMENT. That made the XForms definition very verbose and complicated to
read as code.
3. The set of XForms widgets available seemed very limiting when it came
to creating graphic entry controls for certain data values or with
complex value constraints. For example, we never successfully created a
mechanism to populate an externally coded term (would have had to query
a terminology web service) using XForms widgets and events. It may be
possible, but not at all trivial.
4. It was a particularly challenging task to model the AOM constraints
(for each ELEMENT) as XForms binding constraints and so we experimented
with adding the value constraints directly as from the AOM schema using
the XForms extension module (but this required an XForms engine that
could understand the AOM extensions to really test it and no such engine
exists.... *yet*)
NB: For #4 it doesn't necessarily matter if you don't want to
apply/validate the AOM constraints on the client side, but I think it is
important in most cases to have these constraints contained and applied
in the XForms definition to make it *usable*.
What has your experience been Thilo, Ime? What are your thoughts? I am
very interested in any work going on in this area!
Lisa
Hey Lisa, ime et al
back from skiing - had 6 sunny days and time.
Thanks for the valuable replies.
Comments inline...
Hi Ime, Thilo and all
We investigated using XForms for automatically-generated data entry GUIs
last year. There are some features of XForms which made it seem
particularly well suited to the task: a lot of built-in entry data
validation, ability to validate data against a schema embedded in the
XForms definition, ability to decouple the connection between an input
widget and the target item in the schema by using an XForms binding
item... not to mention being a completely open, platform-independent and
XML-based standard (even if there's very limited browser support thus
far), etc. It was a while ago, so I have probably forgotten some other pros.
IBM enlists these reasons for XFrorms:
# XForms is a W3C XML Standard;
# XForms is XML and submits XML;
# XForms uses W3C XML Schema for validation and data integrity;
# XForms uses W3C XPath for data references;
# XForms is a Model-View-Control (MVC) architecture;
# XForms uses W3C XML Events for loose coupling;
# XForms can be embedded in other host languages;
# XForms rendering is decided "on the glass" (write once, render anywhere);
# XForms reduces/eliminates need for scripting;
# XForms decreases client/server traffic; and
# XForms encodes dependencies in data and validates that data is
declaratively and relatively easily.
Their XForms <-> DB2 Demos
(http://services.alphaworks.ibm.com/DB2pureXMLDemo/) are fascinating
but also seem very 'hacky'. Look for example at the HL7 CDA one at
http://services.alphaworks.ibm.com/DB2pureXMLDemo/hl7CDAXForms/XFormsDemo.xhtml
But gradually it came to feel like we were trying to force XForms to do
something it is too generic/low-level to be suited to. The main
challenges were:
1. The existing XForms implementations were generally immature/flaky or
not in line with the latest XForms specification.
Have gotten better but still don't support the whole XForms 1.1 specs.
Especially if you try non trivial stuff the chances for bug increase
rapidly
2. The openEHR DATA_VALUE types are of a larger grain than most of the
XForms widgets, so more than one XForm widget, more than one databinding
and more than one binding constraint had to be defined per openEHR
ELEMENT. That made the XForms definition very verbose and complicated to
read as code.
Here encapsulting the code as a custom XBL widget could help -> hides
complexity. This would also allow to do hidden (from the XForms markup
point of view), well-tested scripting where XForms capabilities are
not enough.
Here is an example of a simple XBL widget:
http://www.ibm.com/developerworks/library/x-xformsrte/
Currently only the Firefox XForms extension and partly the Formsplayer
IE-plugin support XBL. And since it hasn't been used much also a good
chance of flakyness...
Here are two links describing using XBL in the above mentioned XForms
engines: http://developer.mozilla.org/en/docs/XForms:Custom_Controls
and http://www.formsplayer.com/node/378
3. The set of XForms widgets available seemed very limiting when it came
to creating graphic entry controls for certain data values or with
complex value constraints. For example, we never successfully created a
mechanism to populate an externally coded term (would have had to query
a terminology web service) using XForms widgets and events. It may be
possible, but not at all trivial.
Again a well written and tested XBL custom widget could do the job
4. It was a particularly challenging task to model the AOM constraints
(for each ELEMENT) as XForms binding constraints and so we experimented
with adding the value constraints directly as from the AOM schema using
the XForms extension module (but this required an XForms engine that
could understand the AOM extensions to really test it and no such engine
exists.... *yet*)
What do you mean by XForms extension module?
Do you want to add own elements or attributes (in a separate
namespace)? IMO, in such a case you would need to create your own
XForms engine (or build on an existing one) that understands these
add-ons. This is an example:
http://www.fh-oow.de/institute/iapg/personen/brinkhoff/paper/W2GIS2007.pdf
NB: For #4 it doesn't necessarily matter if you don't want to
apply/validate the AOM constraints on the client side, but I think it is
important in most cases to have these constraints contained and applied
in the XForms definition to make it *usable*.What has your experience been Thilo, Ime? What are your thoughts? I am
very interested in any work going on in this area!
I can totally understand your concerns. In this work
http://www.ncbi.nlm.nih.gov/pubmed/17108529, I fiddled with too
immature XUL and XBL.
So with XForms and DB2 I plan to start very modestly (more on a fun
basis besides boring exam studying) and see were I am going...
Generally I still think a declerative approach is the best option for
form generation. Here are two more links regarding XForms forms
generation (obviously not as complicated as openEHR forms would be):
- http://www.ibm.com/developerworks/library/x-xformsniem/
- http://www.alphaworks.ibm.com/tech/xfg
From a business perspective (ie Ocean) either a stable, reliable
technology is needed to get good results in the mid-term or possibly
considerable investment in improving the XForms engines needs to be
made.
What are your plans at Ocean regarding GUIs?
Cheers, Thilo
Hi Lisa, Thilo et al,
Really appreciate your comments… I have the impression that much still has to be done about Xforms…
OpenMRS is based on infopath for now, so I am now looking at archetypes as form templates (.xtp files). These are relatively reusable form parts and are analogous to form parts. Beginning to put my thoughts on a blog at asangansi.blogspot.com.
Will have to map the datatypes to control types…
etc
Ime
Ime Asangansi wrote:
Hi Lisa, Thilo et al,
Really appreciate your comments... I have the impression that much
still has to be done about Xforms...
OpenMRS is based on infopath for now, so I am now looking at
archetypes as form templates (.xtp files). These are relatively
reusable form parts and are analogous to form parts. Beginning to put
my thoughts on a blog at asangansi.blogspot.com.
Will have to map the datatypes to control types...
etc
We have built a generic XForms engines which uses Chiba to render the
XForm into XHTML + Ajax etc.
Adam
Hi Adams et al,
Nice to hear that.
But I think the tough issue is converting the archetypes xml to xforms.
Please how do you do that?
especially converting the definition section…
Just to add this: we are shifting from Infopath… It has never been a nice thing to be locked into that.
Thats why, Adam, it would be interesting to see you guys put this OSS too. You said (some time ago) that you were waiting for the OHT. Please how is that going now?
Thanks
Cheers,
Ime
Ime Asangansi wrote:
Hi Adams et al,
Nice to hear that.
But I think the tough issue is converting the archetypes xml to xforms.
Please how do you do that?
especially converting the definition section...
there are already answers to this, but you don't want to convert
archetypes to Xforms, you want to convert openEHR Templates. The new
specifications for templates are underway and drafts will be available
in the next few weeks.
- thomas beale
Hmm... yes, thanks for that correction
looking forward to that...
Ime
Ime Asangansi wrote:
Hi Adams et al,
Nice to hear that.
But I think the tough issue is converting the archetypes xml to xforms.
Please how do you do that?
especially converting the definition section...Just to add this: we are shifting from Infopath... It has never been a
nice thing to be locked into that.Thats why, Adam, it would be interesting to see you guys put this OSS
too. You said (some time ago) that you were waiting for the OHT.
Please how is that going now?
I have the XForms Engine up on the OHT site but they're waiting to "go
public" (I have no real idea what the delay is but....)...hopefully
anonymous access is an "any day now" event.
https://xmlprocess.projects.openhealthtools.org/
You'll need a login
General Site:
http://www.openhealthtools.org/index.htm
If you want a login mail Peter Tanner : peter@openhealthtools.org
I have been devoting some time to OpenEHR etc recently
A) Our Publishing mechanism is basically done & now includes subversion
functionality including committing to a branch vs committing to the
trunk etc (e.g. if you want to create a given release).
It is Apache Ant + XSLT with a couple of mini ant tasks in java (one to
CDATA a String & the other to split a string). Again I hope to get this
up to the OHT site at some point (again ASAP as IMHO many eyes shallow
bugs etc).
B) WRT the subject & (A).....one of the fun things the publishing
mechanism does is to create reports in XML form for a repository
including a "validfiles.xml" which list all errors & which artefacts
link to which (e.g. template<>template via GUID, template<>archetype via
name/compound name & archetype<> archetype via regex/compound name +
regex etc).
This drill down is what is a bit of a pain at the moment were one to
wish to open a template & then see a generated XForm GUI...but using the
validfiles.xml it's pretty simple.
C) Wrt moving existing forms etc into Archetypes/templates etc what I've
been playing with is OpenOffice as it's forms designer is XForms based &
allows one to create a model/instance based form in a WYSIWYG way with
all the niceties XForms offers wrt data analysis/mapping e.g. types
from both std XSD & your own schemas/simple types (e.g. restricting a
length or applying a pattern). You can then map that model to the
relevant templates/archetypes while allowing the users to be sure that
you've captured all the fields that their current form captures. In a
very neat move you can even exports that form as an Adobe pdf form.
D) What has raised itself as I've been playing with concepts to do with
this is that you should be able to create a form at the lowest possible
level & then accrete them into a whole i.e. a template/archetype should
have it's own xform which is locatable e.g. archFileName_xform.xhtml
which then includes...etc. i.e. if I open a template xform & the xform
contains other templates/archetypes etc it would be nice to simply load
them via linking (e.g. xlink or similar) rather than some sort of
involved drill down & render approach.
i.e. for a given archetype/template, the XForm is just for that
archetype/tamplate & then includes the relevant form for the relevant
child archetype/template etc.
an example is that you might have an "A&E admissions form" with a
select1 tick box & a set of choices e.g. "has: head wound chest wound
leg wound" & if you click head wound you would want to see the head
wound form.
e.g.
http://internet-apps.blogspot.com/2006/08/using-subforms-in-xforms.html
It is possible that the operational template as per:
"- the XML templates should probably become .xts (ts = template
specification), because there will also be an operational template file,
which is a template with all substitutions done, with an extension like
.xot (ot = operational template) or .xtom (tom = template object model).
The current 'templates' are template 'specifications', i.e. a set of
differences with respect to archetypes. The 'operational' form is what
can be used to create message definitions from, and can be used at runtime."
might cover this off but it the drill down part is interesting.
Adam