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
