Page tree

Are any other members using the 372148003|Ethnic group (ethnic group)| AND 415229000|Racial group (racial group)| hierarchies?

We've had some users request a a revision of this content, as there's a few issues. For example, some of the "groupers" are country specific.
The user is wanting to use this content with risk calculators and genomic use cases.

I recall a discussion a few years back, and I think the EU countries didn't?

(AFAIK this isn't on any foreseeable SI work plan)


  • No labels

20 Comments

  1. Hi we were just wondering if there have been any further discussions on this issue?

  2. Robyn Richards At this point in time it's still an open topic with no further work since Matt's post. From an international perspective we aren't adding new content but are aware the current content needs review with potential inactivation. The plans for that will be discussed internally and I'll come back to you shortly on that. Cathy

  3. As there is no internationally accepted classification for race and ethnicity and each country has their own classification, which can vary widely among countries, it would be prudent to recommend inactivation of the current race and ethnicity concepts from the international release and allow for each country to represent their own classes. One of the underlying problems is that the groupings, as Matt suggested are highly variable from country to country so any taxonomy that we created in the international release would NOT be internationally applicable.  One suggestion would be to add this content to the community content area where countries could pick and choose (i.e. refsets) those races and ethnicities valid in their jurisdictions.

    Most countries publish their own race and ethnicity lists, so SNOMED would be justified in allowing those jurisdictions to manage the content in this area.

    https://nces.ed.gov/ipeds/report-your-data/race-ethnicity-definitions

    https://www.ethnicity-facts-figures.service.gov.uk/style-guide/ethnic-groups

    The European Union does not have a universal categorization of race and ethnicity and each member state has their own.

  4. HI Cathy Richardson and Jim Case ,

    What will happen if multiple managed services countries request to have the same concept activated in their respective extensions? This question was posed by Piper Allyn Ranallo .


    For example, if multiple countries would like to keep 413773004 |Caucasian (racial group)| active in their extension will they have to create a new concept in their extension or will the original international concept be kept active in the international edition?

  5. Reactivating a concept retains the original conceptID.  

    1. Agreed, it does retain the original conceptID. That being said, I don't think the same conceptID is allowed to exist in multiple different moduleIDs. We would not want to have the same active conceptid associated with the US, Estonia, and Canadian extension moduleIDs, or am I misunderstanding?

      1. I'm wondering the same!

  6. Checking with our technical team, reactivation of a concept will retain the same conceptID; however, this is only recommended for the international release (i.e. reactivating an international concept in the international namespace).  The recommendation for national extensions is to recreate the concept in your extension.  SNOMED managed service currently does not support reactivation of international concepts so any proposed reactivation would have to be directly in RF2, but again, it is discouraged.  The challenge with race/ethnicity concepts is that the underlying definition for who fits into a particular category varies by jurisdiction, so one class (e.g. Caucasian) may not include the same "types" of individuals from one country to the next.  

  7. I agree 100% about the underlying problem. But I think the concepts are mostly the same across jurisdictions, but the organisation of is what differs. Perhaps in international release, rather than retiring concepts, the hierarchy was flattened (the IS A retired)?

    That would give all members to access to the "labels", and they can aggregate however they want.
    (Though I'm not sure if the managed service currently allows extensions to state relationships to core concepts)

    Also, given 372148003|Ethnic group (ethnic group)| AND 415229000|Racial group (racial group)|  are disjoint groups is still messy. Maybe merge?

    Maybe it is easier to just retire it all in core, and leave the countries to do whatever they need. Even if that means duplicating content.

  8. The concepts of the subtypes of 372148003 | Ethnic group (ethnic group) | and 415229000 |Racial group (racial group)| are widely used by different users in Canada.

    In order to minimize the duplication of future work in the different extensions, we would like to propose that certain categories be kept in the international edition. We agree that subsequently the content of these categories could vary from one extension to another depending on the definition that will be applied to them, but at the very least, a common base will exist to insert the content. Also, a definition of the concepts 372148003 | Ethnic group (ethnic group) | and 415229000 |Racial group (racial group)| should be added to avoid ambiguity.

  9. I agree with the suggestion of Julie Boutin if I look at the Belgian use cases using this content.

  10. I just noticed this change has gone through (in the June 2024 release).
    SNOMED CT - Ethnic group (ethnic group) (snomedtools.org)


    It's not mentioned in the release notes but I discovered it happened through the impact report (we had one concept in the subhierarchy "Fijian Indian")
    What others are doing now?

    Are we going to be able to reactivate these in our local editions? Or will we all have to recreate them?
    (I found it in the visibility report, though marked as July) 

  11. Hi Matt Cordell ,

    The information on the inactivation of this content was included in the July 2024 International Release notes, see 2.7.1: July 2024 SNOMED CT International Edition The monthly inactivation reports are provided to the CMAG in advance of the release. The topic was discussed by the Member Forum and the comments on action if concepts were required at a national level were "Member countries may recreate or reactivate these concepts in their respective extensions if necessary, with a preference for recreation over reactivation to avoid potential discrepancies in meaning across different regions". 

    Kind regards,

    Cathy 

    1. Hi Cathy Richardson and Matt Cordell 

      I could be incorrect, but I believe the only option is for each extension to recreate the content in their extension. If more than one country were to "reactivate" the international concepts in their extension, then the same concept SCTID would exist as active in multiple modules, which I didn't think was allowed? 

      1. Yeah, having it the same concept(id) in different modules isn't ideal. But I'm not sure it violates the RF2 specification.
        Recreating the same content in multiple editions isn't ideal either..
        I'm not sure there was really ever much variation between countries for most of these. The difference was probably mostly about which concept were relevant in different jurisdictions.

        These issues were all raised during the consultation period.. but anyway, it's done now..

  12. John Snyder - Reactivation of an international concept in an extension is not encouraged and can not be done using the managed service authoring platform.

    Cheers,

    Cathy

    Matt Cordell 

  13. Hi Matt Cordell & Cathy Richardson 

    Can the inactivated race & Ethnicity content be reactivated in a community content space? (Community content initiative will ‘“democratize” the development of SNOMED CT | SNOMED International) A representative from each NRC could be added as an author to the space so that new content could be added. Each country could use that community content as either a dependency or extract it and place it in an intensional or extensional value set for distribution.

    DICOM has recently approached Suzy Roy and myself to communicate their disappointment in the inactivation of this content, so it seems that now that people are actually having to deal with the inactivations, we are seeing some real-world issues bubbling to the surface and being passionately communicated.

    I agree that placing these concepts in a community content area does not address or resolve the underlying problem of each concept having an ambiguous or country specific meaning, which was the basis for the inactivation. I am just suggesting it as a "hack" to prevent each country from having to recreate the content in their own extension.

    Thoughts?

    1. John Snyder 

      Moving the content to the Community content area does nothing to resolve the issue that resulted in the inactivation in the first place, i.e. the variable meaning of the terms amongst jurisdictions.  When looking at the issue prior to discussion at the Member Forum, it was found that there is no international consensus on inclusion within a particular race or ethnicity.  Additionally, each country has their own curated list of race and ethnicity along with (some) guidance on how it is to be applied.  By relegating this back to the members, (consensus by the MF) the meaning for each category can be made specific for their needs.  Even if each country has the same term for a particular race or ethnicity, by having unique identifiers, those who might want to aggregate data can select which set of identifiers they would like to combine, based on the definition provided by each country.  It was interesting to hear from some members that they were actually not allowed to collect ethnicity data.  

  14. Hi John Snyder , I've noted your comments and will raise them internally. Cathy