I would agree - this is clinically the safest and correct action. Ian
Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland On 4 March 2010 13:15, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 04/03/2010 12:57, Peter Gummer wrote: > > Thomas Beale wrote: > > > > Are end users really supposed to see the DV_TEXT.value > of those? I guess aplication logic and GUIs are better off trying to > use the embedded CODE_PHRASE than relying on the possibly language > dependent DV_TEXT.value for those fields/methods. > > > a base assumption in openEHR historically is that the data might > arrive in some application space that doesn't have access to the > terminology. This can easily happen for many reasons. We don't want > the application to be useless (i.e. can't put stuff on the screen) > just because it can't see the terminology. Now, in these structural > attributes, you could expect that the openEHR terminology would be > available somewhere in the application space. However, for both > these situations, we historically decided that it was always better > to have the original text of any coded element, in the original > language. > > > When you say "in the original language", do you mean the original > language of the archetype, or do you mean the original language that > the user saw on the screen when the data was committed? > > > it is the latter - the archetype's original language is irrelevant - we are > only interested in the locale language of the committing user, which could > easily be different. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
