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
More expressivity needed
> but don't forget, archetypes are essentially models of information > use, not descriptions of the real world; the latter is the job of > terminology. Archetypes are a frame-logic artefact, even for the > representation, things are different - terminologies are a description > logic artefact. Practically speaking, this means that archetypes are > more heavily oriented to machine notions of the is-a and particularly > compositional part-of relationships, while terminologies are oriented > to is-a (classification) and a rich set of other relationships that > occur in the real world, like part-of, uses, caused-by, has-site, > symptom-of and so on. > >> >> And here is a worse version of the use-case: _a given set of >> modifiers_ apply to certain - _not all sites_ for a given organ. For >> example the modifiers "anterior wall", "posterior wall" applies to >> fundus and body sites (of stomach) >> >> Finally here is the nightmare version: _a different set of modifiers_ >> apply to _different _and _not all sites_ for a given organ. For >> example the modifiers "Lower third", "Middle third" applies to "Main >> duct" site of pancreas and the modifiers "Left intrahepatic >> branches", "Right intrahepatic branches" apply to "Liver ducts" of >> pancreas. > > this is classic terminology / ontology stuff - we are talking here > about an ontological description of the various organs, gut etc. > >> >> Of course a (non-elegant) modelling strategy would be to make each >> site as an ELEMENT and then the set of modifiers for each and every >> one of them as values. Then this might be problematic during GUI >> design and also during querying. >> >> Here is what I suggest: add a feature in which some "attributes" can >> be specified for values of leaf nodes, like XML. I know this would >> result in dramatic changes in RM and tools (and existing >> implementations) but the sooner the better if you think this is useful. > > for other reasons, this has been suggested before, and I suspect it > would not be that hard to do, but so far there is not strong enough > evidence of the need. I think the above problem is best solved in the > terminology/ontology world! > > - thomas beale > > > > __ Information from ESET NOD32 Antivirus, version of virus > signature database 4283 (20090727) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 4283 (20090727) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz __ Information from ESET NOD32 Antivirus, version of virus signature database 4283 (20090727) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090728/74b138b3/attachment.html>
More expressivity needed
An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090728/520f9045/attachment.html>