Translation approaches

Clinical (archive)
1

I recently posted the question below to the CKM General Discussion
list. Replies there please, if possible.

Hi all,

It is great to see increasing numbers of translations being offered
for archetypes but I have a question for those of us working in
languages which have national/cultural variants e.g English, UK
English, US English or Spanish , Argentinian Spanish.

Creating and maintaining translations will be quite onerous. At the
moment, each translation of every sub-language is separately
maintained within ADL, although it is actually quite easy to hack the
ADL to copy/paste from a different language variant i.e to create
en-us from en-gb.

Although implementations may vary, I suspet most would work similar to
the Ocean tools and will look for and make use of a parent or neutral
language if possible e.g. if the tools native operating system culture
is 'en-gb' it will look for 'en-gb' translation and if not found look
for the parent 'en', finally defaulting to the primary archetype
language if necessary.

This 'default to parent' mechanism means that we could potentially
simplify translation by using the parent/neutral culture if at all
possible e.g translate to en rather than en-gb or es rather than
es-ar.

This would work pretty well in English where there few examples of
clinically important spelling differences which might cause confusion
between language variants. I am happy to tolerate a few American 'z'
spellings instead of 's', if it reduces the translation burden. If
people feel strongly they can always create the sub-language variant.

My question to an international audience is whether this would be
equally acceptable for other languages and cultures, appreciating that
this can be a touchy subject!!

One thing that might also help is to allow the sub-language variant to
be expressed a a differential on the parent language within ADL i.e.
rather than the es-ar variant being a complete list of translated
terms, just carry those that differ from the parent language terms.

So my suggestion is that when translating we use the parent language,
rather than a local variant unless there are compelling reasons, and
even then it may make sense to create the parent AND the variant,
where the parent does not already exist.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org

2

Hi Ian,

2012/1/13 Ian McNicoll <Ian.McNicoll@oceaninformatics.com>

One thing that might also help is to allow the sub-language variant to
be expressed a a differential on the parent language within ADL i.e.
rather than the es-ar variant being a complete list of translated
terms, just carry those that differ from the parent language terms.

That’s exactly my thinking. To work as much as possible with the root or parent language and just include at localised languages the possible changes or varying items. This differential approach seems quite useful to me.

David

3

Wait, because I answered too fast :slight_smile:

Imagine that the original language is English. Then a complete translation is made to “es-es”. And finally, a translation is made to “es-ar”. Can this last translation be just a differential form from “es-es”? The general rule is that any translation is made based on the original language. Thus, the system has no explicit way of knowing that “es-ar” items must be completed with those at “es-es”.

Moreover, can we allow using a “root” language as a primary language? I don’t think so, since anyone who does it will use implicitly his own variant. If an Argentinian creates an archetype, he will use the es-ar variant implicitly, since the pure “es” does not exist and he won’t even be aware that some words are local ones.

Seems that the problem is more tricky than we thought.

David

2012/1/13 David Moner <damoca@gmail.com>

4

Hi David,

Your concern is the root of my question.

I am confident that, at least for English, the variations in clinical
language are small enough that there would be no safety issue if an
American authored an 'en' translation using some en-us phrases that I
wanted to use in the UK. There might certainly be some aesthetic
annoyances e.g 'z' instead of 's' but it is difficult to imagine any
reallly significant problems or safety issues in use. As in
everything, 'let the buyer beware' - exactly the same caution must
apply to any translation since the translator may not fully understand
the underlying concepts - that is why we have added translation review
functionality to CKM so that broader input can be sought.

I think adopting a generic 'en' approach is safe and acceptable, not
sure about other languages.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org

5

yes, that's the way it should be. I will ensure this is made explicit in
ADL 1.5.

- thomas

6

Hi

In this thread it seems relevant to review the approaches which have been used in the development of SNOMED CT, not because they are the only or best approaches, but they illustrate some salient points to consider such as;

- Commitment not only to development but of maintenance
- The necessary extent of translation (can a partial set ever be adequate?)
- The need to percolate through any changes to all translations e.g. from a refined ontological definition
- There are definite authorities for IHTSDO who own various Editions of the SNOMED CT, they have to find the funds to perform and maintain translations, contrast this to volunteer effort alone.

There is a body of expertise in IHTSDO which may be a key resource to help you scope the approach in more detail.

It is interesting to note that the UK Terminology Centre take the US edition and make substantial augmentations and other adjustments for it to be used, the Austrians likewise have their own adjustments including their own medicines terminology (AMT) and New Zealand has a different approach to both these, Canada have Canadian French as well as US English in their release of SNOMED CT.

I hope this pointer to similar practise is helpful, regards

Tom Seabury
Implementation Consultant
Data Standards and Products, Technology Office
Department of Health Informatics Directorate
tom.seabury@nhs.net

7

I don’t think this will fly. The names for some oeprations are different, e.g. appendectomy, appendicectomy, also professions - anaesthetist / anesthesiologist (wikipedia). I doubt if all the ‘serious’ instititutions in either country will put up with changes like this.

  • thomas
8

Sure , that's fine but I am not suggesting that local variants are
never required. If someone demands or requires a local spelling or
term, so be it, they can go and create the translation.

Also, many of these stylistic issues will actually (as in your
examples) likely to be in an external terminology, or in node
descriptions / metadata rather in the internal terms themselves.

The issue is whether there are any real safety concerns, rather than
just cultural preferences. Not a problem in English as far as I can
tell.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org

9

I think we have to assume that managing a group of translations like es,
es-es, es-cl, and so on, will always require a bit of juggling each time
a new one is added. What is in the 'es' one is goinng to be somewhat
arbitrary. Consider for instance that a Spanish doctor gets there first
with what she thinks is a normative 'es' translation; but then imagine 5
South American countries want to use the archetype and they all have the
same variation, i.e. in fact if we consider the number of users, it
should be the South American translation should become the 'es'
translation and the Spanish one should become 'es-es' (just the
differences). If this is not done, it means there have to be 5 es-cl,
es-ar, etc additions, which is obviously somewhat annoying since it
could have been avoided (AFAIK there is no way to make a es-?? where ??
= some region, like South America).

So it seems to me that the only thing that we can mandate is that the
final result of 'compressing' es-es + es, es-cl + es, es-ar + es etc, is
in fact correct for each language.

WHen any new translation is added, it could mean that all the
translations for that language group are changed in some way, so as to
get the most optimal outcome, but I don't see how we could mandate this.

- thomas

10

Hi,

The examples given by Thomas are on the level of classifications and terminologies and not the generic names in artifacts, I think.

Gerard Freriks
+31 620347088
gfrer@luna.nl

11

Exactly, that is what I mean when I said that a pure “es” does not exist, and probably the same applies to any other language with localisations.

An example of different local interpretation I can recall now in Spanish is the word “constipado”. In Argentina it means the same as in English, “constipation”. But in Spain it means “to have a cold”.

As Ian and Gerard have said, probably this is solved by using terminologies, but it is an indication that local language codes are needed.

2012/1/13 Thomas Beale <thomas.beale@oceaninformatics.com>

12

Brilliant example!!

That could indeed lead to some unfortunate decision support being enacted.

I think it is pretty clear that for eference terminologies, even in
English, there is really no option but to create a localised
translation because of the variation you have described. I just
wonder, however, whether it really applies in archetypes where the
context is much more constrained.

It might be interesting for you or other native Spanish speakers to
have a look at the recent es-ar translations uploaded to CKM and see
how many 'incorrect' es-es you can find.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org

13

Ian,

What is needed are local tesauri in the local dialect referring to a Reference Terminology plus additional concepts when the Reference Terminology (and UK-English) do not know these concepts.

Names for nodes in artefacts can be given an UK-English name and code from a Reference Terminology. In the Template people can add their own local dialects.

Gerard Freriks
+31 620347088
gfrer@luna.nl

14

Since I’m not a clinician maybe I could miss many details, but in any case there should not be many differences and not of importance. In a quick view I only found “provisorio” at the “test status” of openEHR-EHR-OBSERVATION.lab_test-blood_gases.v1. In Spain “provisional” would be used instead. But this is similar to the British/American English differences, a change not of real importance.

2012/1/13 Ian McNicoll <Ian.McNicoll@oceaninformatics.com>

15

they would be if they were single terms and available in e.g. Snomed,
but where they occur in larger phrases defined in archetype term
definitions, I don't see any alternative to using the archetype
mechanism to solve it. In most cases, there will be no available
translation in any external terminology (SNomed has only a few languages
done), not to mention the many cases where there is no term at all in
any language in SCT or elsewhere.

- thomas

16

well again, I know these differences seem small to us technical people,
but there are all kinds of objections that could be raised by
clinicians, organisations that cannot tolerate different terms from what
their software currently uses, etc.... I think we should be careful
making assumptions about what is acceptable on a clinician user interface.

- thomas

17

Templates will provide local dialects.
Archetype nodes are defined in a preferred English-UK language.

Gerard Freriks
+31 620347088
gfrer@luna.nl

18

Local to organisations probably yes (I really don’t know how languages are managed at template level, but seem reasonable that there you can add local terms, right?). But you cannot expect that archetypes will be always defined by British clinicians

2012/1/14 Gerard Freriks <gfrer@luna.nl>

19

Wen there are no codes from a Reference Terminology we need to specify an other Golden Standard and that is UK-English, monitored by a committee that is the owner of the list of preferred terms/

Gerard Freriks
+31 620347088
gfrer@luna.nl

20

Ok, but as Thomas said we are talking about the archetype node descriptions, not about coded terms or values of clinical data.

2012/1/14 Gerard Freriks <gfrer@luna.nl>