Localising translation guidelines
We also need guidelines on how to create local guidelines for your translation project. What do you need to consider, what decisions do you need to make?
Comments
Guidelines for patient-friendly terms
In Norway a (partial) translation of SNOMED has recently commenced by adding both preferred term and other synonyms to each concept. The scope does not include a translation of FSN, at least for the moment.
According to the Norwegian translation guidelines, the preferred term should be the candidate which prevails in professional clinical usage. This is a pretty vague statement. As far as I can see in the translations made so far, this criterion has rendered preferred terms which are being objected by some general practitioners as being unfamiliar.
A new refset designed for the general practitioners is now being planned. In tandem with this work we are discussing the possibilities to add a "tail" to the Norwegian translation guidelines. These additional guidelines should provide help to select patient-friendly terms for such refsets. The term "patient-friendly" is slightly misguiding, as other stakeholders such as police, social security and other municipal services are relevant.
Do any of you have any experiences or viewpoints on this topic?
Should there be a (new?) data category in the descriptions for synonyms that are patient-friendly? Or should the preferred term be patient-friendly in specific refsets (such as refsets for GPs), in contrast with our national extension?
What is a patient-friendly term and how to select one? Should we involve the user group as a part of the process? Or should we use predefined publications as references, such as medical encyclopedias and guides for family/home use? Are there other possibilities?
Viewpoints from all of you would be highly appreciated
Dear Ole,
We have come across your questions too at the CSCT a few months ago so I can give you the fruits of this reflexion. Currently Belgium does not translate FSNs in the sense that we do not make a translation which has the semantic tag at the end of the term and that no-one will ever use as interface term because of it. BUT in the recent pneumology concepts translation we have done for the NRC, we have done what we call "pseudo-FSNs" which are terms that extensively describe the concept, as an FSN should now according to the SNOMED international editorial guidelines, but we make it without semantic tag. We have done this especially for the body structures where clinicians will often want adjectival short forms(ex: apicobasal bronchus of superior left lobe) and SNOMED international asks in the guidelines for extensive noun forms (apicobasal bronchus of upper lobe of left lung).
Before you ask, we have done these pseudoFSNs conforming to the current SNOMED international guidelines even if the current FSN doesn't conform yet. To save is the trouble of going back there twice. Our NRC has agreed this approach is useful to disambiguate the meaning of some concepts by providing a clean, extensive, "long form term" and useful to standardize translation. Especially in anatomical concepts and all concepts naming anatomical parts in their FSN.
Now we had a discussion also about "interface terms". There are several categories of them. One is bad medical language and abbreviations SNOMED international would not allow as synonyms. Those we have decided not to allow either no matter the field local pressure as accreditation Canada most of our hospitals have done refuses the use of abbreviations and slang in EHRs for safety reasons. So there we have arguments to refuse the pressure of the field for "bad words" currently in use. They have to change and it's not SNOMED asking but accreditation and that's it.
Another category is patient-friendly terms and "baby talk" for explaining to kids. Another is all the terms that don't perfectly fit the SNOMED international rules but are nevertheless unambiguous to the users. Another are the plural forms one needs at the bedside while SNOMED always asks for singular forms in descriptions. The original NRC point of view was that the BE extension was to hold only the "pure" forms and all the rest was "interface terms" and the problem of EHR vendors and interface terminology vendors. Our position was that it is much better to create those synonyms, especially the plural forms and less scientific but still correct forms when the terms are translated and have them created by the same team using strict authoring rules then let public safety rely on vendors which might or might not have done a strict job. It's also a pure question of wasted time. Translating a concept correctly requires you spend time understanding it so making that onerous job twice, once for high class medical vocabulary and a second time for common language is a waste of resources.
On the technical side, initially like you did, we thought to create a new kind of description for that, named "interface term" or "common term". But we put some more thoughts about it with our NRC and actually we concluded it is best that this is done in the language refset as an additional acceptability. You would have preferred, acceptable syn (the classical syn full SNOMED compliant) and interface synonym (or whatever name you choose for the not-perfect but still usable terms, we have not decided yet how best to call this new acceptability). This is much better then creating a new description type because if your authoring rules evolve and finally you deem an "interface term" good enough to become an acceptable synonym, all you need to change is that language refset tag. You need not touch at the description file itself. Much easier that way, much less maintenance.
Regarding the PT, we put, as a rule for the BE extension as PT the term "which is most commonly used by clinicians". And sometime that just doesn't work because the most commonly used by surgeons isn't the most commonly used by radiologist and yet another is preferred by GP. If that happens we pick the one we feel would most appear in EHRs in general, the term that can be understood by the general practitioner who'll read the hospital reports and actually we do not worry overmuch about the choice of the PT because we all plan to use as you said specific language refsets for GP, specialists and patients. So what matters actually is to create in your national extension all the synonyms you would need for every user and what they find preferred or acceptable, they will configure through language preference refsets and they can even change that at hospital level with their vendor or at unit level, who cares. What is important is that your NRC will have endorsed that all those synonyms are safe to represent this concept.
As to the involvment of patient user groups into the translation process, yes if you have them I would definitely involve them. We don't have much of that here but as a rule, one should always try to involve people who will use the translations into the translation process.
Hope it helps. Feel free to write me if you want to work on templates. I happen to have friends in Norway and to have done some external patient record review for them a few years ago so I have some knowledge and a personal curiosity toward what is done there in healthcare.
Within the work with National Medication List in Sweden they plan to have seperate language refsets including "common language"/patient-friendly terms that have been added as acceptable synonyms for each concept. So they have not chosen a general system, such as requesting a new attribute from SNOMED International:
Recommended (professional) term
Acceptable synonym
Common language/patient-friendly terms (our terminologists prefer "common language" i.e. allmänspråklig in Swedish and maybe Norwegian)
So either Norway could do as we do, local smaller selection of common language terms, or we raise the issue jointly to SI about introducing a new type of term. "Public term" or what it can now be called in "Internationalian".
Do you aim for at least one correct translation per concept, or do you want to maximise findability by adding many synonyms?
If there are multiple allowable ways to spell words, specify which style to follow (in Dutch e.g Eppstein-anomalie vs. eppsteinanomalie).
Decide which specialism's jargon should determine the preferred term - if you leave it up to individuals from different backgrounds, you will generate much inconsistency.
Specify syntax patterns to follow. Do you use verbs (has a fever) or avoid them (fever, feverish)? What grammatical construction do you prefer, what word order?
Do you use acronyms, eponyms, abbreviations?
Where do you use Arabian numerals and where Latin?
Keep a list (translation memory?) of words and phrases where you have decided how to translate them: this will improve consistency.
For each subhierarchy that you translate, identify stock phrases (starting with the semantic tag) and decide how to translate those in FSN, PT and synonyms. E.g. in body structures 'Structure of (femur/upper limb/...)', in morphologic abnormalities ' - no ICD-O-subtype'.
Decide when to ignore inconsistencies between English FSN's (if the meaning is the same, why translate differently?), and when to follow them (if there actually is a subtle clinical distinction). Ensure there are mechanisms to detect and discuss such inconsistencies.
Configure specific guidelines into your translation tooling if at all possible: it makes it much easier for translators to remember to apply them.
Keep updating your guidelines and don't be afraid to change an existing guideline - provided you have some way to refactor approved translations. Snomed is large and complicated and it is impossible to get everything right all the time.