Agree with Tim's comments - health information is not something we can be sloppy with. Also, Dipak's Norwegian example was exactly the kind of example I was thinking of - where thinking you know what language the words are in is probably dangerous.
As a practical solution which satisfies the need for non-ambiguity of language, but also doesn't cause too much data excess in EHRs in very mono-lingual contexts (e.g. most anglo countries, but also a surprising number of other countries, e.g. Brazil, Russia, France...) - is: ENTRY class has - a mandatory language attribute - a mandatory character encoding attribute (says which flavour of unicode). This forces the whole ENTRY to be encoded the same way no matter what, but also allows distinct ENTRYs to be encoded in e.g. UTF-8, UTF-16. DV_TEXT class has - an optional language attribute, which is understood to override the one from its enclosing ENTRY. further thoughts from the group? - thomas beale Tim Cook wrote: >Getting in late on comments but......... > >On Sat, 2004-03-06 at 14:57, Thomas Beale wrote: > > >>some higher level class - e.g. COMPOSITION, since almost all the time it >>is the same on DV_TEXT items in a given EHR. We don't think it should be >>that high, since language cannot be guaranteed the same throughout a >>COMPOSITION >> >> > >I wholly agree with your analysis. > >The key trigger phrase above is "almost all the time". Anytime there is >vagueness then a solution should be taken into account. This really is >the real reason for this specification and model anyway isn't it? To >get away from all those "it hardly ever happens", "we'll use the notes >field for that" or "five is enough addresses" ... instances in other >models. > >The scenarios given have been excellent and I especially appreciate >Dipak's comment; "But when records really are travelling (sic) across >the globe, and such translation software is mature, will we have >prevented a valuable aid to safe health care?" That kind of vision >shared by all those that have worked so hard for so long on this is what >makes it the prime solution that it is going to be. > >Sorry....broke into a little cheer leading there.....<g> > > >Ciao, >Tim > > > > > -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Hon. Research Fellow, University College London openEHR (http://www.openEHR.org) Archetypes (http://www.oceaninformatics.biz/adl.html) Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
