Two weeks ago we discussed the idea of flagging 'grouper concepts', such as groups of anatomical locations that are not actual locations themselves, in SNOMED, as that information would be useful for translators. Monica has asked us for examples; let's collect a few here in this discussion.
For instance: 10293006 |Structure of iliac artery (body structure)|. This concept proved very confusing to our medical reviewers, who insisted there was no such structure; though they did recognise the common, the external and the internal iliac artery.
As chair of the translation group, can I ask that you query the group concerning the terms "requires", "requirement for" versus "dependence", "dependence on"? We're considering what is the meaning of these terms. Are there any non-English connotations to consider? If SNOMED CT were to treat these as synonyms, would that cause a problem for any country? If not, what contexts would be appropriate for each?
These are often in the finding hierarchy and describe devices, substances, an
klilly Please note that you have to look for other word forms also: require, requires, requirement, needs, need of, need for, dependency and perhaps more that we have not found yet.
How do you translate body parts ending with 'proper'? For example, how do you make the distinction in the translation of 818999009 | Structure of blood vessel of abdomen (body structure) | and 787123006 | Structure of blood vessel of abdomen proper (body structure) |
Ouch, I never saw this discussion before and it was created in 2020... I know we really struggled with this as well and failed to find a single solution. Some we translated to a Latin term which includes the word 'propria'; in some cases we were able to distinguish between the 'proper' structure and its broader parent with different Dutch terms (e.g. eyeball vs eye).
Abdomen cavity proper we translated to 'cavitas abdominalis', and abdominopelvic cavity to 'abdominopelviene holte'. I don't think there is a 'abdomen cavity' in SNOMED - that helps.
The translation of 'injury of ...' concepts is proving pretty traumatic for us ;-) If we solely look at the term, the best translation is 'letsel'. However, nearly all 'injury' concepts are defined as traumatic, but 'letsel' is frequently not traumatic. It may be caused by tumors, operations, poison - any number of things.
We could translate all these concepts as 'traumatisch letsel' and keep the meaning intact. Concepts for damage could then be translated as 'letsel'. But the healthcar
We basically made the same choice as you, translating them to 'letsel'. But now the proposal in that QI page is to define all injury concepts with 'due to traumatic event'. Which means the relations clearly start to express the traumatic part.
As you say, we are supposed to treat the FSN as the source of truth - here is an example where that doesn't seem to have worked out for us (as in, the Netherlands).
mlambot In this case, you should not report them individually, but respond to that QI page, because the discussion on how to model injuries is taking place there. My colleague edegroot may also raise this issue in the content committee, if some other NRC's agree that the current proposal would cause translation problems.
Rory has created a Jira-project where we can log concepts we deem impossible to translate. How should we configure the project? How generic or specific should the issues be, which fields do we need? The project can be explored at /projects/SCTF/summary https://jira.ihtsdotools.org/projects/SCTF/summary.
Definitely we need to be able to mark in the Jira when the problem has been passed to a CRG for investigation/solution, to which speciality group, when and have the permissions on our page set so that the people from the CRG we passed the problem to can write their answer/follow up on our pages so we know what happens to our questions without ending up sitting in all possible CRGs (even if that would not be a bad thing, it's a too time consuming one).
On searchability, it would be uselful to be able to add "tags" to each issue we describe, like the hastags or hidden keywords on internet pages, especially when registering a problem touching many concepts and of which we give only an example. Better even would be if we could add all the SCTID of the concepts concerned by the described issue as hidden tag. If you don't somehow list somewhere all the concepts you register as having a problem, how will people find out that a problem has been reported upon one specific concept? And we need to be able to know how vast a problem is to correctly figure where it should be adressed and what ressources this would cost so making a true list of how many concepts are involved is important. Finding all the concepts sharing similar features can most often be found using an expression in the browser or performing word seach/NLP techniques on a DB containing the core. We should be able to upload expressions or extensional refsets thus in the SCTID field and perform searches on this field.
Fields should include who reports it, but also who claims the task when there are investigations to be made on it. Dates, to be able to see since how long an issue is lying "dead". I would advocate for a built in way to contact the person who declared the issue because it's very frustrating when you stumble on a nice group page and you can't write on it because you have no permission and have no clue who to ask about it. There are also going to be issues someone has created and no-one understands. Better to be able to ask directly you queston to the "owner" of the issue.
Yet we have to think carefully about not recreating here a parallel CRS... or maybe this is exactly what one needs to create, a kind of "open" multi-actors translation-related CRS that prepares, evaluates and sorts out issues that need to be pushed (or not) to the real SNOMED international CRS? This relates actually to the topic of moving toward worldwide co-authoring of SNOMED CT content.
The Translation Management Guidelines has a section on workflow, but the workflow it suggests may not be practical for each NRCs. We should expand it to discuss alternative workflows with their pros and cons.
NRC-NL-Translation workflow.png
This portrays the Dutch workflow. The translation agency has their own 3-stage workflow. The NRC adds for each concept two reviews: semantic (is the meaning correct?) and clinical (is the translation recognisable for healthcare professionals?). Conflicts between FSN and definition, and duplicate concepts, are reported to Snomed Int.; highly specialised concepts are sent to an expert pool filled with healthcare specialists from different specialisations. The disadvantage is that it is, obviously, rather more complicated and more time-consuming as each concept is seen by at least three people (translator, semantic reviewer, clinical reviewer). The advantage is that it is much easier to find clinical validators and terminologists, than to find reviewers who are both healthcare professionals and terminologist. As Snomed contains upwards of 300,000 concepts, it is unrealistic to expect Snomed enthusiasts to review the entire thing, however motivated they are. When you start hiring reviewers, you had better make your requirements realistic.
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?
Dear ovage, In the Netherlands we are compiling a partial patient-friendly translation, as a separate language reference set, using the 'Thesaurus zorg & welzijn'. This thesaurus was developed as a dictionary to translate between the professional and the ordinary citizen. The health-care related terms are where possible reviewed and approved by patient associations: associations which focus on a particular disease, are founded by chronic sufferers of that disease or relatives, whose aim is to provide knowledge and support to other patients with the same disease.
SNOMED is not yet used by Dutch GP's in the Netherlands; they have had their own separate ICPC-based table for decades and are not ready to switch. We see the same disagreement as to preferred term as you do though. I think we might need a separate language reference set for GP's if we want them to use SNOMED.
When you translate, how do you choose the preferred term? Which English descriptions do you translate: FSN, preferred term, synonyms?
We will use this discussion to write new guidelines for this dilemma.
As for which English descriptions we use as source: we have found many cases where English synonyms do not mean quite the same as the FSN, preferred term and definition. In quite a few of these cases, Snomed contained another concept that they should have been synonym of. So I would not advise someone to translate every synonym. Besides, not every English term has its equivalent in Dutch, and those languages are closely related: you couldn't do it if you wanted to.
On the other hand, sometimes synonyms help us to interpret the concept. E.g. in the case of eponyms, which can be obscure or on the other hand much more well-known than the descriptive FSN. So I wouldn't ignore them either.
Finally, sometimes a single word in English has two or three synonymous ways to express it in Dutch. So what we do is: we use all descriptions and the concept's definition to determine the meaning. Then we create the FSN based on our translation guidelines, add all descriptions which are commonly used in Dutch healthcare to denote the concept, and make the most usual term preferred. That means sometimes we have 0 synonyms where the core has 6, and sometimes we have 6 synonyms where th core has 0. We use all English descriptions, but only to interpret the concept.
We have agreed during the first meeting to hold monthly recurring meetings from now on. We suggest Tuesday 14.00 UTC as a regular time, starting on July 10th. Are there any members in this group for whom that time is (too) inconvenient?
Dear all,
Update: the frequency has been changed to a bimonthly meeting, Tuesdays 13 UTC, starting January 14th. Please send me (hielkema@nictiz.nl) your email address so I can invite you through Outlook.
The Member Translation Matrix is provided to record details of the translation activities of SNOMED Internationsl members.
Please can members complete the attached template, and post the completed template this discussion forum, to provide visibility to all members.
The responses will be combined into a central matrix to provide an overview of all translation activities currently underway.
(And a big thank-you to all those Members attending the session in London, and a specific thank-yo
Feikje Hielkema-Raadsveld