- 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@crs4.it>
Subject: Re: Issues around UI technologies and bindings to back end
To: For openEHR technical discussions <openehr-technical@openehr.org>
Message-ID: <4A6F1642.40606@crs4.it>
Content-Type: text/plain; charset=windows-1252; format=flowedThomas 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 ThomasMay 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@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technicalEnd 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.