# Issues around UI technologies and bindings to back end **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2009-07-21 15:34 UTC **Views:** 5 **Replies:** 20 **URL:** https://discourse.openehr.org/t/issues-around-ui-technologies-and-bindings-to-back-end/14010 --- ## Post #1 by @Seref Hi, Even if it feels a little bit too implementation related I'd like to get your opinions about the various UI implementation ideas/practices you may have, especially about web based applications. I've written an initial set of things here : [http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation](http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation). based on Opereffa, but I'd really like to hear how others are tackling UI layer. I'm a little bit worried since I can see MS CUI being a little bit isolated from model driven approaches. If we are going to make use of this work (and I think we should), along with our own work, we'd better try to see how implementations of rich UI widgets can be put into use for clinicians. Your comments will be appreciated Kind regards Seref --- ## Post #2 by @Gavin_Brelstaff Hi Seref, Seref Arikan wrote: > I've written an initial set of things here : > http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation. > based on Opereffa, but I'd really like to hear how others are tackling UI > layer\. > I'm a little bit worried since I can see MS CUI \.\.\. I had a look at these Silverlight "controls" \- such as http://www.mscui.net/Components/SingleConceptMatching.aspx etc \- perhaps I missed something, but I can't see anything greatly different from what a Luddite like me might achieve with XHTML\-like select, check\-boxes etc\. Complexity grows, in any case, when one considers screens where one data\-value \(e\.g\. drop\-down list\) should vary in accordance with another control's value \(e\.g\. another list's item\)\. I am not even sure how openEHR archetypes fully allow such co\-occurrence constraints to be defined \- I guess I'd try using invariant rules\. This isn't just a case of panels/containers being present/visible or not \- as archetype\-slot toggling ought to be able to handle\. If we assume that detailed co\-occurrence variations can be declared as ASL invariant rules then \- IMHO \- it makes sense to take that declarative approach down to the GUI level and interpret such rules at data entry\. This is what xForms was supposed to be designed to do \(using it's bind declarations\) \- but the majority opinion of openEHR developer is that xForms are dead in the water \- and we should instead instantiate object\-oriented widgets to implement our GUIs\. I am not so convinced \- I've played with the Orbeon xForms server http://www.orbeon.com/ which embeds the eXist xml\-db an I am quite impressed just how far you can get in modern browsers without writing javascript or requiring plugins\. XML in XML out\. It's nice to be web\-based/RESTful since it gives you so much for free\. It would be nice to implement a demo that compiles\-down ADL to a form Orbeon can serve \- but, as I noted earlier, this is not a main\-line idea here: for one thing it mostly throws out the "O" from the "AOM"\. Good work with Opereffa Gavin Brelstaff CRS4 Sardinia Italy\. --- ## Post #3 by @Seref Hi Gavin, Thanks for the input, Now, to see a little bit more, please visit [http://www.mscui.net/PatientJourneyDemonstrator/](http://www.mscui.net/PatientJourneyDemonstrator/) Omer Hotomaroglu notified me of this some time ago, and I guess everyting here is not in CUI specs yet, but this is a much better demonstration of how GUI specialization can end up. Of course I'm not a clinician, but assuming MS has someone telling them that clinicians would be happy with this, I'm focusing on the functionality. As you've said it is about interactions between UI controls, and if you check this page you'll see that layout related capabilities are also important, I'll write about the in the wiki in detail, but the link above shows that making use of every UI capability is useful, actually, I've written about this in my blog some time ago : [http://www.serefarikan.com/?p=42](http://www.serefarikan.com/?p=42) The problem, especialy with these specific controls is, what will we do when a widget binds to multiple models? or there is an overlap between two models, which are used by two widgets on the same UI? I have reason to believe that our binding approaches are a little bit naive at this point, and I'd be satisfied when I can bind GUIs like in the Patient Journey Demonstrator to openEHR back end. Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply leave certain things out of the specifications. Templates may have some space in them where you can act naughty? Like the Z segment of HL7 V2, a redlight district where everyone visits every once in a while, but does not mention so much.. I've never heard about Orbeon, and I'll be taking a good look at it, if it looks handy, I can simply add a link to it from Opereffa, to see how things will shape up. Thanks again for the input, and the useful discussion. Kind regards Seref --- ## Post #4 by @Helma Seref Arikan said the following on 22/7/09 11:39: > Now about UI \- model relationship, my view is the GUI layer is way too > complex and diverse to include in openEHR specifications, even a subset > of the UI related stuff would be enough to introduce more problems than > it solves\. > IF there emerges a cross platform AND cross technology declerative > markup for GUI and GUI interactions and bindings, and this is a big if, > then it may be considered, otherwise, my personal opinion is to simply Hi, I must confess I've only half followed this discussion due to time constraints, but this remark comes very close to my findings in a paper I've written on this topic, which is now available as epub: Generic screen representations for future\-proof systems, is it possible? There is more to a GUI than meets the eye\. van der Linden H, Austin T, Talmon J\. Comput Methods Programs Biomed\. 2009 Sep;95\(3\):213\-26\. Epub 2009 Apr 15\. http://www.ncbi.nlm.nih.gov/pubmed/19368989 Re Orbeon: I think that's a nice start\. Should dive into it more in the near future\. With regards, Helma van der Linden --- ## Post #5 by @Seref Thanks Helma, Very interesting feedback. Considering one of the authors, Tony Austin, is in the next room, and here I am hearing about this work from you :) Kind regards Seref --- ## Post #6 by @Greg_Caulton > Date: Wed, 22 Jul 2009 15:16:20 +0200 > From: hepabolu <[hepabolu@gmail.com](mailto:hepabolu@gmail.com)> > Subject: Re: Issues around UI technologies and bindings to back end > To: For openEHR technical discussions <[openehr-technical@openehr.org](mailto:openehr-technical@openehr.org)> > Message-ID: <[4A671124.7020002@gmail.com](mailto:4A671124.7020002@gmail.com)> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Seref Arikan said the following on 22/7/09 11:39: > > Now about UI - model relationship, my view is the GUI layer is way too > > complex and diverse to include in openEHR specifications, even a subset > > of the UI related stuff would be enough to introduce more problems than > > it solves. > > IF there emerges a cross platform AND cross technology declerative > > markup for GUI and GUI interactions and bindings, and this is a big if, > > then it may be considered, otherwise, my personal opinion is to simply I agree, to start integrating UI related content into the archetypes is a very bad idea. Most modern UIs follow a [Model-View-Controller](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) approach. For PatientOS Archetypes provide the data elements. The relationships and constraints within the archetype data elements is implemented in our model. We have different views - fat client, web client which are implemented through controllers written in java or javascript. Atttempts to push everything into the archetype definition would create a complex beast which would defeat KISS principal. As a side note I also think the ADL files is hampering adoption - not for us as there is a Java parser. Since everything that is the ADL must be expressable in XML (otherwise interoperability of the definitions would be problematic) - why have both - XML is ubiquitous and I think the benefits of readibility of an ADL file is no longer needed since there are tools which replace it - how many people read an ADL file any more? --- ## Post #7 by @Seref Hi Greg, I for one read ADL. We have Java parser, and .NET people has a .NET parser. If there are others out there with technologies without a parser (Python? anyting else?) I'd like to hear it voiced as a request. Here is the reason I'd rather see ADL instead of XML: According to me, ADL is a machine processable representation for humans, and XML is a human processable representation for machines, and for some reason I find myself reading ADL from time to time. Kind regards Seref --- ## Post #8 by @yampeku More people than you think still read and write ADL by hand, as openEHR clinical model is not the only language you can build archetypes \(for instance, you can do archetypes of openEHR demographics, CEN EN13606 clinical model or demographics\)\. However, it's true that available tools support or plan to support different models, but the tools that support those models are still unknown to a lot of potential users --- ## Post #9 by @thomas.beale To clarify one thing: UI structures have to be based on templates, which are essentially specific 'data set' definitions, not archetypes, which standardise all content irrespective of any particular use. But I agree with the point that any such artefact cannot be assumed to be a direct basis for automated GUI building. I don't think it is impossible, merely difficult (which reminds me of the Galen motto: "making the impossible very difficult"). Re: ADL files; the reason ADL exists is because an ADL archetype is definitive - there is only one possible expression. With XML on the other hand, we have the current published schema; in the near future, I suspect it will be upgraded to be more efficient (seems everyone hates innefficient XML), and that could easily happen a few more times into the future. Practically speaking, you are right, most normal system / product developers/vendors don't need to care about the ADL if they don't like it, they can just use the XML, and everything will work fine. If ADL is 'hampering adoption' then we need to improve how we communicate the notion of archetypes, how to use them etc. Suggestions in this area are welcome. - thomas beale Greg Caulton wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #10 by @Heath_Frankel3 There is an open source ADL to XML conversion library for .NET written in c# located at [http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLParser](http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLParser). This is used by the Archetype Editor to generate a pure XML representation of the ADL file via the ADL_Parser so that it can create a canonical xml representation of the archetype model for hashing purposes. The XML displayed and files generated directly from the Archetype Editor uses a different (legacy) mechanism and is not as reliable as that produced by the conversion library, the result is slightly different XML output. We just have not had enough volunteer time to replace this legacy approach within the Archetype Editor. If anyone need assistance in using this conversion library I can provide an NUnit test library that shows how it can be used, or you can sift through the Archetype Editor code if you prefer VB. We actually have a publishing tool using this library that can run a batch process against an entire Archetype file repository that can be run within an auto-build process and committed back into svn. This is how the XML archetypes on openEHR used to get generated prior to CKM. I am not sure if CKM supports XML output of archetypes as yet but if it is felt that not having archetypes available in XML is holding back openEHR adoption then I am sure this can be put on the change request list for prioritisation. Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel@oceaninformatics.com +61 (0) 8 7127 5574 Regards Heath --- ## Post #11 by @system Heath Frankel wrote: > > I am not sure if CKM supports XML output of archetypes as yet but if > it is felt that not having archetypes available in XML is holding back > openEHR adoption then I am sure this can be put on the change request > list for prioritisation\. > No, it doesn't yet, but shouldn't be too hard\. There is a Java XML Generator as well, but not sure if it is consistent with the C\# conversion library yet\. Sebastian --- ## Post #12 by @Greg_Caulton > Message: 1 > Date: Sat, 25 Jul 2009 01:59:36 +0930 > From: "Heath Frankel" <[heath.frankel@oceaninformatics.com](mailto:heath.frankel@oceaninformatics.com)> > Subject: RE: Issues around UI technologies and bindings to back end > To: "'For openEHR technical discussions'" > <[openehr-technical@openehr.org](mailto:openehr-technical@openehr.org)> > Message-ID: > <00db01ca0c7b$f05e67f0$d11b37d0$@[frankel@oceaninformatics.com](mailto:frankel@oceaninformatics.com)> > Content-Type: text/plain; charset="us-ascii" > > There is an open source ADL to XML conversion library for .NET written in c# > located at > [http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLPars](http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLPars) > er. This is used by the Archetype Editor to generate a pure XML > representation of the ADL file via the ADL_Parser so that it can create a > canonical xml representation of the archetype model for hashing purposes. > The XML displayed and files generated directly from the Archetype Editor > uses a different (legacy) mechanism and is not as reliable as that produced > by the conversion library, the result is slightly different XML output. We > just have not had enough volunteer time to replace this legacy approach > within the Archetype Editor. > > If anyone need assistance in using this conversion library I can provide an > NUnit test library that shows how it can be used, or you can sift through > the Archetype Editor code if you prefer VB. > > We actually have a publishing tool using this library that can run a batch > process against an entire Archetype file repository that can be run within > an auto-build process and committed back into svn. This is how the XML > archetypes on openEHR used to get generated prior to CKM. > > I am not sure if CKM supports XML output of archetypes as yet but if it is > felt that not having archetypes available in XML is holding back openEHR > adoption then I am sure this can be put on the change request list for > prioritisation. > > Regards > > Heath Generating XML from ADL is one piece - but what is needed is the schema definition and not the generic one that fits all archetypes but rather one that is specific to the data elements and content of each archetype. The technical people working with Archetypes today are obviously content with working with an ADL file but IMHO the software developers of tomorrow need to spend about 1 hour evaluating archetypes, import the definitions and then demonstrate that this well thought out, well structured OpenEHR data is of more value that defining ones own data hierarchy using HL7, LOINC, SNOMED etc. XML, XSD has orders of more tooling support, ADL only has the few tools available that we know of and that affects productivity. If XML/XSD became the defacto standard I could take our administrative and billing data model and convert into 'archetypes' and quickly people could begin to review them. As the CKM clinical reviews take place and the quality and quantity of the clinical archetypes increases the content becomes more valuable. But without easy access to that content I believe it does hamper adoption. --- ## Post #13 by @thomas.beale Greg Caulton wrote: > > > > Generating XML from ADL is one piece - but what is needed is the schema definition and not the generic one that fits all archetypes but rather one that is specific to the data elements and content of each archetype. Hi Greg, both are needed. The generic openEHR XSD is used for software processing archetypes, including model authoring software and run-time software. A second kind of schema we call a 'Template Data Schema' is generated from an openEHR template, i.e. 1 template = 1 schema. This has not yet been openly specified due to lack of resources, but will as soon as it is possible. The reason why this kind of schema needs to be based on templates is because templates are the data-sets that correspond to any particular scenario of data capture or messaging. Archetypes as schemas in general don't make clinical sense (a few come close, like some of the lab ones, which causes for some people the illusion that it is a general phenomenon). > The technical people working with Archetypes today are obviously content with working with an ADL file but IMHO the software developers of tomorrow need to spend about 1 hour evaluating archetypes, import the definitions and then demonstrate that this well thought out, well structured OpenEHR data is of more value that defining ones own data hierarchy using HL7, LOINC, SNOMED etc. yes - but to do this, they need to be working with templates. Archetypes on their own don't make sense as direct data-capture models. > XML, XSD has orders of more tooling support, ADL only has the few tools available that we know of and that affects productivity. If XML/XSD became the defacto standard I could take our administrative and billing data model and convert into 'archetypes' and quickly people could begin to review them. what would be needed for that is to develop and publish more templates, along with their generate schemas, this would give the lever you are looking for. - thomas beale --- ## Post #14 by @system > yes \- but to do this, they need to be working with templates\. > Archetypes on their own don't make sense as direct data\-capture models\. Thomas, I wonder why this is, maybe you can explain this or point to an explanation\. Thanks Bert --- ## Post #15 by @thomas.beale Bert Verhees wrote: > > ``` > > yes - but to do this, they need to be working with templates. > > Archetypes on their own don't make sense as direct data-capture models. > > > > ``` > > ``` > Thomas, I wonder why this is, maybe you can explain this or point to an > explanation. > > ``` Archetypes act as a way to standardise the *possible* data points that could be captured about some topic, in any possible context (i.e. type of patient, type of clinic etc). So for example, the blood pressure archetype (see [http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.130](http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.130)) contains the following data points in the 'data' part: - systolic pressure (SP) - diastolic pressure (DP) - mean arterial pressure (MAP) - perfusion pressure used by anaesthetists - pulse pressure (PP) - difference between SP and DP - comment Now, in actual real contexts, the things that can be used in a meaningful way are one of the following: - SP, DP // the usual one - MAP - which is related by a formula to SP & DP (see [http://en.wikipedia.org/wiki/Mean_arterial_pressure](http://en.wikipedia.org/wiki/Mean_arterial_pressure)) - PP - either computed from SP - DP, or measured directly by some devices MAP will never be needed in a normal GP or nursing context, and PP won't usually be either, although I believe it is becoming moreso, because the PP history is recognised as an indicator of some problems. The point is, you will (probably) never create any data set (such as a form or a message) that corresponds to a particular clinical event (such as GP visit, etc) that contains all of these. Instead, you will make a template, that contains the SP and DP, possbly some other BP archetype items, and also a bunch of other items from other archetypes. This latter combination of items is what is being recorded in the specific situation. For another context, e.g. emergency department admission, a different combination of items will be recorded. Both could easily contain common elements from the archetypes they use; this is why archetypes exist - to standardise the semantic definitions of the information items; templates exist to put them together (sometimes with further constraints) for specific use cases. One reason that this is not always clear is that there are some archetypes that would normally be used in their entirety in the template, e.g. Apgar, Barthel, some lab results and so on (although even then, the protocol information may or may not be included). hope this clarifies - thomas beale --- ## Post #16 by @yampeku This reminds me a thing\. Would be useful to have at ADL level something like postconditions? \(In your example, something stating how to obtain or validate MBP from available values\)\. I think this falls into "knowledge" level\. --- ## Post #17 by @Olof_Torgersson1 Hi, I can see the difference between templates and archetypes and why the templates are needed for UI:s. The problem is the there is no complete template specification. Is there a time plan for when it will be finished? Regards Olof --- ## Post #18 by @system >> hope this clarifies Thanks, Thomas, it clarifies why archetypes do not suffice in application\-context for data entry/presentation\. For the moment, we can live without templates \(leave it to form\-developers to define where to use a specific archetype\-item\), or fabricate template\-definition for internal use\. In initial phase, it does not have to be very complicated\. > for UI:s\. The problem is the there is no complete template > specification\. I agree with Olof that there is a need for formal template\-specification\. I think that when there is, it will be possible to exchange templates, application forms, or even better, develop to exchangeable application\-functionality\. This would cause the openehr\-kernel to become a supporting module which presents forms and stores data\. But the real application will be defined in the templates\. Is this the road\-map we are looking at? Or are the goals different? My thoughts on a Sunday\-morning: Medical\-information\-application\-development will be a matter of writing templates and archetypes\. This can than be done by people specialized in writing/defining GUI's and specialized in medical applications\. I remember this to be one of the original goals of the openehr\-kernel\. The mix needed for software development, not only medical, is that an application\-developer needs to have technical knowledge, but also domain\-knowledge\. Very often this prevents developers to be as good skilled as would be possible if they could concentrate on either\. \(no flame bait intended, there are many positive exceptions\) Software\-developers than can concentrate on writing a good kernel, writing good tooling\. They can concentrate on the technical part of an application\. For example: It would even be possible to write a OpenEHR\-OS, highly optimized for this purpose\. This could, for example, be based on the Linux\-kernel which is available for this, because it is open source and therefore modifiable\. It also fits in the idea of having a separate OS\-instantiation for each separate service\-application possible running in virtual environments\. If for scalability\-purpose needed, it can also run on separate servers, clusters, or even distributed\. A matter of modularity\. regards, Bert --- ## Post #19 by @thomas.beale Diego Boscá wrote: > ``` > This reminds me a thing. Would be useful to have at ADL level > something like postconditions? (In your example, something stating how > to obtain or validate MBP from available values). I think this falls > into "knowledge" level. > > ``` we already have 'invariants', which in ADL 1.5 would be renamed to 'rules'. These are first-order predicate logic expressions that can reference anything in the definition. In ADL 1.5 I think they will be in a variant of Xpath syntax. This would enable the relationship between various data points to be asserted (e.g. with a formula). There is also the idea that derived data points should be able to be expressed as functions, which I think will also occur in the future - this is probably what you are thinking about. This would allow the computation of a data point to be defined. - thomas beale --- ## Post #20 by @thomas.beale Olof Torgersson wrote: --- ## Post #21 by @thomas.beale Bert Verhees wrote: > > > ``` > > > hope this clarifies > > > > > > ``` > > ``` > > Thanks, Thomas, it clarifies why archetypes do not suffice in > application-context for data entry/presentation. > For the moment, we can live without templates (leave it to form-developers > to define where to use a specific archetype-item), or fabricate > template-definition for internal use. In initial phase, it does not have > to be very complicated. > > > ``` yes, I should have said this: anyone can fabricate their own 'templates' for the moment. They won't be reusable outside the local environment, but for application building that won't matter. Only one thing matters - whatever your 'templates' look like, make sure they include the archetype paths / node ids (i.e. at-codes) for each data point. > ``` > > ``` > > > ``` > > for UI:s. The problem is the there is no complete template > > specification. > > > > ``` > > ``` > > I agree with Olof that there is a need for formal template-specification. > > I think that when there is, it will be possible to exchange templates, > application forms, or even better, develop to exchangeable > application-functionality. This would cause the openehr-kernel to become a > supporting module which presents forms and stores data. But the real > application will be defined in the templates. > > ``` getting close to that, yes > ``` > Is this the road-map we are looking at? Or are the goals different? > > My thoughts on a Sunday-morning: > Medical-information-application-development will be a matter of writing > templates and archetypes. This can than be done by people specialized in > writing/defining GUI's and specialized in medical applications. I remember > this to be one of the original goals of the openehr-kernel. > > ``` there will still be GUI-specific stuff to work out I think - we have to live with the fact that good GUI will always require some hand-building. > ``` > The mix needed for software development, not only medical, is that an > application-developer needs to have technical knowledge, but also > domain-knowledge. Very often this prevents developers to be as good > skilled as would be possible if they could concentrate on either. > (no flame bait intended, there are many positive exceptions) > > ``` if medical professionals have mainly been responsible for the archetypes, developers could have a fair go at templates. > ``` > Software-developers than can concentrate on writing a good kernel, writing > good tooling. They can concentrate on the technical part of an > application. For example: It would even be possible to write a OpenEHR-OS, > highly optimized for this purpose. This could, for example, be based on > the Linux-kernel which is available for this, because it is open source > and therefore modifiable. > > ``` well, that's a nice future to think about - it just relies on a nice API being developed, published and adopted. - thomas beale --- **Canonical:** https://discourse.openehr.org/t/issues-around-ui-technologies-and-bindings-to-back-end/14010 **Original content:** https://discourse.openehr.org/t/issues-around-ui-technologies-and-bindings-to-back-end/14010