# XML archetypes **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-11-13 15:02 UTC **Views:** 2 **Replies:** 15 **URL:** https://discourse.openehr.org/t/xml-archetypes/14594 --- ## Post #1 by @Mattias_Forss1 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 --- ## Post #2 by @Ime_Asangansi 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 --- ## Post #3 by @system Hi Ime [http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html) For the AM, two schemas are provided: - [Archetype](http://www.openehr.org/releases/1.0.1/its/XML-schema/documentation/Archetype.xsd.html) - types from the Archetype Object Model (AOM) ([xsd](http://www.openehr.org/releases/1.0.1/its/XML-schema/Archetype.xsd) file) Ime Asangansi wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #4 by @Ime_Asangansi Sam, Thanks a lot. I'll be back with questions... Ime --- ## Post #5 by @Ime_Asangansi 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 --- ## Post #6 by @Thilo_Schuler1 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\. --- ## Post #7 by @Ime_Asangansi 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 --- ## Post #8 by @Lisa_Thurston1 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 implementation > > rgds, > 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 --- ## Post #9 by @Thilo_Schuler1 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 --- ## Post #10 by @Ime_Asangansi 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 --- ## Post #11 by @Adam_Flinton 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 --- ## Post #12 by @Ime_Asangansi 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 --- ## Post #13 by @thomas.beale 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 --- ## Post #14 by @Ime_Asangansi Hmm\.\.\. yes, thanks for that correction looking forward to that\.\.\. Ime --- ## Post #15 by @Adam_Flinton 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 --- ## Post #16 by @Ime_Asangansi --- **Canonical:** https://discourse.openehr.org/t/xml-archetypes/14594 **Original content:** https://discourse.openehr.org/t/xml-archetypes/14594