Dear All, The proposal being discussed necessitates that THERE BE NO REQUIREMENT FOR a Composition (or maybe an Entry) to internally formally specify the language used for a textual expression, to differentiate it from the language applying to the Composition/Entry as a whole. This ought not to be determined by storage concerns, but on the basis of the requirement. If we cannot be confident that there is no need, we ought not to remove the present functionality which permits it.
When considering this issue the scenarios that come most to my mind are genuinely multi-lingual cultures or contexts. In some countries more than one language prevails, and health care professionals might be proficient in more than one of these. In such situations, the health care agent might have a principal language for record-keeping and an ability and a wish to capture some aspects of the consultation in a patient's own (different) language, such as a symptom description. The HCA might also wish to compose some patient instructions in the patient's own language knowing, perhaps, that the patient can go home and view this EHR on their own computer. Although London is not officially a multi-lingual city, I was working in east London with Bengali-speaking health workers to pilot such schemes (using multi-lingual paper based records) several years ago. Since we do permit pre-existing EHR information (e.g. an Entry) to be included as a referenced copy in a new Composition, there might also arise a situation when the information so included was recorded in another language. One question raised in discussions so far is if we need to formally specify the language, or if it is obvious and can be inferred. For words that have been absorbed from other languages (e.g. ,in English, laissez faire) this might be true, but there is a risk that the same word in two languages has different meanings. Torbjorn Nystadnes has told me of one European example: " Rolig " Norwegian = quiet (calm, peaceful) Swedish = funny in Norway: He died 'rolig' = he died peacefully in Sweden: you can imagine!! Whilst natural language translation facilities are still limited, you might feel it is OK to reply upon human "common sense" in such situations. But when records really are travelling across the globe, and such translation software is mature, will we have prevented a valuable aid to safe health care? A second concern that comes to mind, maybe erroneously, relates to applications and EHR systems that are used across national boundaries. For example, an English-language application being used in France. Consider perhaps that the form labels have been translated into French but not the underling code. Might some attribute values such as the Name be committed to the EHR in English (determined by the form field being used, and as encoded by the app developer, and not a Name value chosen by a French user) and the textual value of that box (written by the user in French). If the language attribute is removed from the DV_TEXT class can we still represent an Element whose Name (or some other attribute value) is in English but whose textual Data Value is in French? A third concern is interoperability. Since both CEN and HL7 presently carry language as part of textual data types, is it going to be unhelpful for us to do this differently? i.e will we ALWAYS be able to map safely between the proposed modification to openEHR and CEN/HL7? I am not great champion for gratuitously identical behaviour, but we do also need to help bring interoperable EHRs into existence despite all of the business drivers to the contrary! So, are we confident that we can remove this function from lower levels of the model? With best wishes, Dipak ________________________________________________________ Dr Dipak Kalra Senior Clinical Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Direct Line: +44-20-7288-3362 Fax: +44-20-7288-3322 Web site: http://www.chime.ucl.ac.uk - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
