Page tree

2539 View 9 Comment In discussion Comments enabled In the category: Undefined

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

Contributors (4)


  1. I think I can recall three types of translation problems I'd like to deposit in this project:

    1. Single concepts that are obsolete, or whose scope is limited to UK or USA. 
    2. Pairs or even trio's of duplicate concepts, where we cannot translate both and would prefer early feedback on which will be retained and which will be inactivated.
    3. Entire branches of concepts, or concepts that share a particular phrase, whose scope is limited. E.g. 'private referral to...' - not possible in the Netherlands. Or 'soft drugs'/'hard drug's' - multiple concepts that refer to a different list of drugs in each country. 

    For the first category an SCTID field would be very handy, but for the latter you could only put an example. And I wouldn't want to create separate issues for concepts with have basically the same issue.

    What kinds of issues do you envisage? Which fields could we add to improve searchability?

  2. I would like to add a fourth problem to Feikjes list: concepts with unclear meaning, usually concepts without any defining attributes. 

  3. I've also encountered the problem of concepts where the attributes don't match the FSN. Ex: allergic rhinitis due to tree pollen, which was modelled with a causative agent of tree and shrub pollen while the tree pollen concept exists as child of tree and shrub pollen. This concept was already reported by me to the allergy CRG along with a similar one with weed pollen/flower dan weed pollen causative agent and both will be corrected (modification of the causative agent attribute value).

    I've also encountred the reverse, FSN that is mode vague the the attribute while clearly the intended meaning of the concepts was indeed the narrower meaning of the attribute value. There is a whole bunch of disease of "tonsil" that are like that, that points actually to palatine tonsils, where the attribute is correctly to those specific tonsils but the FSN, by stating only "tonsil" is ambiguous because there are a few concepts that are general groupers for all tonsils tubal, pharyngeal and palatine and without looking at the definition, you never know from the FSN is it goes about the general meaning or the palatine ones.

  4. I've had a meeting with my colleagues in the Dutch NRC about how to use the Jira project. We have the following configuration suggestions:

    • Dropdown with different values (or create a separate field) in issue type, to wit: duplicate, obsolete, ambiguous, anglocultural, spelling error;
    • Add a field for SCTID. We're not sure whether the field should be mandatory; but what would be highly useful, is a mechanism that stops you creating a new issue about a concept that already has an issue that is still active.
    • When the issue type = duplicate, a second SCTID field?
    • A field for the NRC that raised the issue. 

    Configuration apart, it would be very useful to make agreements amongst different NRCs, including UK and USA, and Snomed International, which people we could tag in this project. E.g. if I think a concept is typically British and want to confirm that, I might as well approach the UK NRC directly instead of pestering Snomed International first. 

  5. I agree on all your points, Feikje.

    I also would like to add a translation problem to the list. To make allergens in the substance hierarchy unambiguous, the FSN should be composed based on a latin name (where possible) rather than a trivial name. In the substance hierarchy we discovered trivial names, such as 840362007 |Deer fly salivary protein (substance)|, 846617008 |Firebrush pollen (substance)| and 846615000 |Snakeweed pollen (substance)|. Extremely hard to translate! Since you can imagine that these concepts are representing allergens that are created to define anti-allergy products, it is quite crucial to get the translation correct. But with only trivial names, it is not easy to understand what species/genus they mean. "Deer fly" - a direct translation into Swedish would be possible ("hjortfluga"), but when you google a little further, combining "deer fly" (in English) and "allergy", it turns out that this probably is another genus than what is meant when you say "hjortfluga" (deer fly in Swedish).  And so on. 

    Should I report this as a Content Request Service issue, or is it more suitable in this new Jira project coming? 

    1. I recognise the problem! We encountered it translating plants and trees. I think with issues that involve so many concepts, your best hope is to go through SNOMED groups for relevant topics, such as in this case the allergy CRG that Marie-Alexandra recommends.

      With CRS, you quickly run into the 150 limit if you tackle stuff like this. The JIRA project might a suitable place to start such discussions, and other NRC's could help raise the issue in the relevant group, or decide to form a new group. Perhaps we need a field/way to mark that an issue involves many concepts, i.e. has far-reaching consequences.

      1. 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.

  6. Hi Emma,

    I've forwarded your remark to Bruce Goldberg, head the allergy CRG on which I sit so we can look into how to adress this in our to-do list. The CRG is definitely the right place to ask, especially since we are working on a new modelling for allergens which are identified proteins or parts derived from living organisms so that it would be possible to recognize that when one registers an allergy to "cat", "cat dander" or "cat salivary protein" it's the same allergy the clinician is talking about. We have concentrated on animal allergens at the moment as they are the most common but once the mechanisme is in place it could be applied to others. Currently there is more often then not no relationship between allergenic proteins or substances and the organism they come from and it's not ok since the first line is most likely to use trivial names of organisms for the allergies and want to keep doing that and the specialists will deem the trivial names bad language and want to use the obscure protein names that are of course more precise but nevertheless unknown for non specialists and more general health workers, childhood carers, kitchen workers or indeed patients who'd want to read this information for safety.

    I don't believe we have someone from Sweden sitting with us at the CRG Allergy but anyone who wants to join the work would be welcome. Countries who are actively working on allergy registration right now are more then welcome to give their insight. Send me an email if you want to discuss this further, the allergy CRG meets monthly and is very active.



    1. Super! Thank you very much. At the moment I don't have a Swedish candidate to the CRG Allergy, but I'll spread the word.