OHDSI Home | Forums | Wiki | Github

Proposed changes in SNOMED domains

This post follows on the recent discussion on SNOMED overhaul taking place in the Vocabulary WG last Tuesday, slides, recording and meeting notes available in Teams.

Given multiple debates over Condition vs Observation vs Measurement in the community, the Vocabulary Team has proposed to use SNOMED tags to assign domains in these gray areas.

Here’s a snapshot of the presentation.
For example, both Hemoglobin low and Anemia were Conditions. In proposal, we use tags to assign them different concept_class_id, which leads to Anemia staying in Condition domain and Hemoglobin low moving to Measurement domain (and being post-coordinated).

Attached snomed_domain_delta.xlsx (1.2 MB)
is the table with full delta (old domains and new proposed domains). Please check it out and comment here/come to the Vocab WG next Tuesday for further discussion.

Tagging some of the folks participating in the conversation on the last call:
@MPhilofsky, @Andy_Kanter, @DaveraG, @hspence. Please share with others! :slight_smile:


@aostropolets Great work!

I came across a topical discovery. A lot of Observations from the ‘Clinical history/examination observable’ SNOMED branch hold the potential to be classified as Measurements. Prior to this, I was particularly focused on the child concept ‘Near visual acuity’ for mapping purposes. Would it be possible for you to check if your automated approach can also effectively cover this hierarchical branch?

1 Like

Thanks so much!! We will check it out :slight_smile:

So to be clear, the concern that I had was that by differentiating between findings and diseases that we don’t break subsumption queries… if clinical staff or prior ETL assume things to be synonyms then they would expect the subsumption queries to return both. This might be a bad example but if we have a finding “positive gonorrhea test” and from a phenotype perspective this might mean the patient has gonorrhea. The current parents of this concept are positive test with no relationship to gonorrhea. If this change doesn’t change existing hierarchies, then perhaps there is no problem. But if previously low hemoglobin would have been captured when people were looking for anemia, then by formally separating the hierarchies could cause problems. @aostropolets you implied that subsumption won’t change.

Right. This change will not affect the SNOMED’s hierarchy, but you’d need to query more clinical event tables in some cases

This is a good question, actually. On one hand, changing the SNOMED hierarchy would be suicidal. On the other hand, if hierarchies cross domain boundaries than they violate the idea of a hierarchy, in which descendants inherit all the properties of the parent. The problem we are causing is that our domain is an attribute SNOMED is oblivious of. Now what?

Exactly here. I don’t know what @Andy_Kanter has in mind, but let’s say gonorrhea is the parent of the positive test. Then a query of gonorrhea and all its children will correctly bring back the test. However, it is in a different domain, and then the cohort will not miraculously contain both Condition and Measurement records. In other words, preserving the hierarchy even if it goes cross domain boundaries doesn’t help us in practice.

I don’t have a good idea. An idea that doesn’t sound so good would be to break the hierarchy at the domain, and stitch the individual pieces together. Urgh.

@Polina_Talapova, hello!

Thank you for your comment.
Indeed, Observable Entity concept class is a sophisticated mixture of measurements and observations. We have covered the mentioned branch with hierarchical peaks and assigned Measurement domain where needed. Specifically, Visual acuity and its descendants will be moved to the Measurement domain.

1 Like

Greetings! Appreciate your excellent work. I’ve reviewed the list of concepts with updated domains and would like to share our findings.
As a new user on this platform, I’m unable to upload files. Could you guide me to a location where I can upload the table with results?

Many thanks for looking it! :slight_smile: file restrictions are annoying - could you try sending it in a message? Or, alternatively, to my email, which is ostropolets@ohdsi.org.