> > > 1. Re: Issues around UI technologies and bindings to back end (gjb) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jul 2009 17:16:18 +0200 > From: gjb <gjb at crs4.it> > Subject: Re: Issues around UI technologies and bindings to back end > To: For openEHR technical discussions <openehr-technical at openehr.org> > Message-ID: <4A6F1642.40606 at crs4.it> > Content-Type: text/plain; charset=windows-1252; format=flowed > > 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 > > > ------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > End of openEHR-technical Digest, Vol 36, Issue 22 > ************************************************* >
Excellent insight Gavin. You speak to the difference between Cerner and Microsoft. Microsoft is a dump of healthcare related controls whereas Cerner provides software that is suited to clinicians workflow (to some degree). Loosely speaking (though we do not use them) I see the OpenEHR templates are what you described - a form. I agree that the auto generated web forms are usability challenged. 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 and services. It will be interesting to see if we can break through the web issues with todays AJAX technologies. -- Gregory Caulton Principal at PatientOS Inc. personal email: caultonpos at gmail.com http://www.patientos.com corporate: (888)-NBR-1EMR || fax 857.241.3022 (Side rant - I wish the Ocean team would not include the ocean (Image) in their emails as it messes up the digest version of the mailing list as nearly being unreadable and certainly a lot more work to have to go and login to see their replies) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090729/851afbc8/attachment.html>
