Issues around UI technologies and bindings to back end (gjb)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090729/c5b5b224/attachment.html
Issues around UI technologies and bindings to back end (gjb)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090729/eef11df0/attachment.html
Issues around UI technologies and bindings to back end (gjb)
Hi Tim, Two questions regarding your comments: I want to speak on (what **I** think) is this underlying REAL problem. I could not understand what the real problem you describe is. Could you please define it once more? But the reality is that we have been battling this for more than 45 years while the rest of the world has moved on... (see the video on Youtube about IBM at Johns Hopkins in 1963) Would you mind explaining to where the world has moved on? I'd like to think that I have a decent view of the major work around the issues we have been discussing. So if someone has made significant progress about the things we've been discussing I'd really like to know. Best Regards Seref ps: sending this again due to a dns problem On Wed, Jul 29, 2009 at 8:48 PM, Tim Cook timothywayne.cook at gmail.comwrote: On Wed, 2009-07-29 at 17:28 +0100, Thomas Beale wrote: But one could build a UI that is not so mundane. We have many more properties in the model behind our forms than is currently included in the templates to achieve that and soon we will have a web client to complement our fat client using the same underlying data model I want to speak on (what **I** think) is this underlying REAL problem. This is NOT a DATA MODEL issue. (damn I wish educators would quit teaching this). It is NOT a Java problem it is not a SQL problem.it is an INFORMATION problem. YOUR (or my) data model don't mean crap. It's about representing the information in a semantically meaningful way. .. Yep...this was an abrasive, affrontive attack on the status que... most especially in academia and monpolistic business. Since I am an independent consultant/researcher I guess I have the liberty to say so. We can delve into technical issues if you wish and I'll be happy to debate them with you. But the reality is that we have been battling this for more than 45 years while the rest of the world has moved on... (see the video on Youtube about IBM at Johns Hopkins in 1963) Think about it. ?We can't solve problems by using the same kind of thinking we used when we created them.? --Albert Einstein Insanity: doing the same thing over and over again and expecting different results. --Albert Einstein Yeah; I like to quote him. He was a man of great intellect and foresight. You *MUST* think beyond today or you are just padding your pocket instead of caring about the tomorrow. --Tim Cook (2009) -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook *** *You may get my Public GPG key from popular keyservers or* *from this link http://timothywayne.cook.googlepages.com/home * *** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://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/20090729/9eb5ffd6/attachment.html
Issues around UI technologies and bindings to back end
Thomas Beale wrote: 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 Hi Thomas May be I can frame the question in a different way: Is what we have now (including imminent Template Spec) an advantageous starting point for building EHR data entry / GUI interfaces or is it perhaps an impediment: requiring a compliance which might pragmatically only be obtained by retro-fitting software to the published archetypes/templates ? My doubts arise from the fact that in traditional Object-Oriented Design (OOD) the overall architecture is informed _simultaneously_ by two independent formative factors: structure and behaviour. The structural factor appear to be dominant in the formation of openEHR archetypes - even in the CKM - with any behaviour / methods / operation being left as technical afterthoughts. This might not matter if programming a GUI interface can simply be made a question of implementing any required behaviours in the objects of the classes derived (via templates and slots etc) from the openEHR archetypes. But if the nature of these behaviours do not conform to the containment model specified by the openEHR archetype hierarchy then the implementer is right to ask the question: should I refactor the archetypes (as normal OOD requires) or should I accepted reduced behaviours to avoid their impacting those archetypes? Personally I like the ADL specification - it is human-readable in a way that neither XML nor any programming language like Java, or even Python, is. But the very fact that it omits behaviour implies that is declarative and is actually Declaring Documents and not Modelling Information per se. I would have thought the openEHR would have become more document-centric than it is now. I know there are archetypes for document Sections - but that marginalises the fact a document-based interface is what most non-techie humans are capable of comprehending and not to follow this venerable tradition leads to information disorientation. So why facilitate the freedom to diverge from it? An analogous approach to openEHR would be simply to specify constraints on the legal content of particular Health Record documents. Commonalities between the document sections might be marked up - in the same spirit of inheriting reuse as is adopted for discovering archetypes in openEHR . Of course today's web-fed technologies attempt to do all this in ugly unreadable XML which gets transformed into humanised GUI pages/screens. As I commented else where recent advance in server and browser implementations mean that xForms armed with well designed schema specifications might be up for this job. Yet I am still not sure what to make of MS-CUI - its demos seem particularly disorientating and techie-targeted. My problem here is that any data-entry objects get instantiated when they arrive in browser's document object model and (to me at least) it seems that they may be completely different objects to those archetyped at the highest level of the design and so - even with an excellent template specification - it may be unprofitable to think about adding methods to classes based on archetypes as OOD is usually progressed. I am interested in ways of reconciling openEHR archetype/templates with browser mediated documents ? based on open-standards. I'd be pleased if anyone else might care to comment on this could be achieved. Gavin Brelstaff CRS4 Sardinia Pula (CA) Italy
Issues around UI technologies and bindings to back end
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. 2009/7/25 Thomas Beale thomas.beale at oceaninformatics.com: 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) 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) 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Diego Bosc? Tom?s diebosto at fis.upv.es yampeku at gmail.com Grupo IBIME Instituto ITACA - Universidad Polit?cnica de Valencia Acceso B Edificio 8G Camino Vera s/n 46022 VALENCIA (Spain) tel: +34 963 875 277 http://ibime.upv.es
Issues around UI technologies and bindings to back end
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
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090726/a7e5ac29/attachment.html
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090726/fc6b2289/attachment.html
Issues around UI technologies and bindings to back end
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 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 Heath Frankel Product Development Manager Ocean Informatics heath.frankel at oceaninformatics.com +61 (0) 8 7127 5574 Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Thursday, 23 July 2009 8:45 PM To: openehr-technical at openehr.org Subject: Re: Issues around UI technologies and bindings to back end Date: Wed, 22 Jul 2009 15:16:20 +0200 From: hepabolu hepab...@gmail.com Subject: Re: Issues around UI technologies and bindings to back end To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 4A671124.7020002 at 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? -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3ad435d6/attachment.html
Issues around UI technologies and bindings to back end
Message: 1 Date: Sat, 25 Jul 2009 01:59:36 +0930 From: Heath Frankel heath.frankel at oceaninformatics.com Subject: RE: Issues around UI technologies and bindings to back end To: 'For openEHR technical discussions' openehr-technical at openehr.org Message-ID: 00db01ca0c7b$f05e67f0$d11b37d0$@frankel at 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 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. -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3ef081b8/attachment.html
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/3575dcad/attachment.html
Issues around UI technologies and bindings to back end
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
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090725/5d242ea7/attachment.html
Issues around UI technologies and bindings to back end
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
Issues around UI technologies and bindings to back end
Date: Wed, 22 Jul 2009 15:16:20 +0200 From: hepabolu hepabolu at gmail.com Subject: Re: Issues around UI technologies and bindings to back end To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 4A671124.7020002 at 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-Controllerhttp://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controllerapproach. 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? -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090723/06735c3c/attachment.html
Issues around UI technologies and bindings to back end
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 On Thu, Jul 23, 2009 at 12:15 PM, Greg Caulton caultonpos at gmail.com wrote: Date: Wed, 22 Jul 2009 15:16:20 +0200 From: hepabolu hepabolu at gmail.com Subject: Re: Issues around UI technologies and bindings to back end To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 4A671124.7020002 at 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-Controllerhttp://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controllerapproach. 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? -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://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/20090723/5ef57d4d/attachment.html
Issues around UI technologies and bindings to back end
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 2009/7/23 Greg Caulton caultonpos at gmail.com: Date: Wed, 22 Jul 2009 15:16:20 +0200 From: hepabolu hepabolu at gmail.com Subject: Re: Issues around UI technologies and bindings to back end To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 4A671124.7020002 at 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 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? -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax ?857.241.3022 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Diego Bosc? Tom?s diebosto at fis.upv.es yampeku at gmail.com Grupo IBIME Instituto ITACA - Universidad Polit?cnica de Valencia Acceso B Edificio 8G Camino Vera s/n 46022 VALENCIA (Spain) tel: +34 963 875 277 http://ibime.upv.es http://www.linkehr.com
Issues around UI technologies and bindings to back end
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090723/ea56d6d5/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090723/ea56d6d5/attachment.png
Issues around UI technologies and bindings to back end
Hi Gavin, Thanks for the input, Now, to see a little bit more, please visit 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 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 On Tue, Jul 21, 2009 at 6:05 PM, gjb gjb at crs4.it wrote: 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. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://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/20090722/f11abdbc/attachment.html
Issues around UI technologies and bindings to back end
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
Issues around UI technologies and bindings to back end
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 On Wed, Jul 22, 2009 at 2:16 PM, hepabolu hepabolu at gmail.com wrote: 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://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/20090722/116aeeb6/attachment.html
Issues around UI technologies and bindings to back end
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. 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090721/991f0863/attachment.html
Issues around UI technologies and bindings to back end
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.
