Post-coordinated SNOMED CT concept expression?

Vocabulary Users
1

Hello all,
I’m wondering how can I express SNOMED CT concept with post-coordination into OMOP CDM v5.
Is there any solution for describing detailed attributes using CDM?
For example, two clinical concepts such as “fracture of femur” and “fracture” have different meaning.
Please give some advice.

Thank you.

Borim

2

@Borim_Ryu:

This is a wonderful question. Right now, we only allow fully pre-coordinated Concepts that exist in SNOMED. The list is in the vocabulary CONCEPT table. If you want to combine Concepts, you have to put several records into the CONDITION table at the same day.

However, SNOMED is build in a multi-dimensional bases, and all pre-coordinated Concepts have a link to their components. So, “Fracture of femur” is linked to “Fracture” and to “Femur”. But not all combinations exist. So, we could do a couple of things:

  • We create all combinations people need and SNOMED doesn’t have.
  • We put three new fields into CONDITION_OCCURENCE: anatomical_site, pathology, cause
  • We somehow allow different concepts to be combined. Theoretically we have the FACT_RELATIONSHIP table for that, but nobody uses it

Thoughts?

3

I like #2, but one benefit of #1 is that by creating single concepts, you can put the hierarchy in the concept_ancestor tables (such that a fracture of femur is below fracture of lower limb which is below fracture).

4

Any more recent thoughts on this? :slight_smile:

5

Well, what is your use case. Right now, we have Fracture of femur, which has a relationship “Has associated morphology (SNOMED)” to Fracture (Domain Observation) and “Has finding site (SNOMED)” to Bone structure of femur (Domain Spec Anatomic Site). What’s missing?

6

If I can add my two cents and my use case, I think this example about Fracture of femur is a bit misleading.
The fact that Athena and the OMOP vocabularies now contain the SNOMED CT description logic is truly great, but does not solve this question about post-coordination in OMOP CDM.

In my institution we encode all our structured data into SNOMED CT and a significant proportion of our variables (roughly 10 to 20%) cannot be represented by a single SNOMED CT concept. Therefore we rely on post-coordination, following the SNOMED CT Compositional Grammar and the SNOMED CT Machine Readable Concept Model

Concepts such as upper lobe atelectasis are represented in SNOMED CT by

46621007 |Atelectasis (disorder)|:
363698007 |Finding site (attribute)| = 45653009 |Structure of upper lobe of lung (body structure)|

Because there is no such precoordinated concept in SNOMED CT.

The question of how to enter such composed concept into OMOP CDM is not solved for us. There is probably a way of using the FACT_RELATIONSHIP table to do so, but if someone already found a workaround for this I would be very interested.

Sorry if the English is not perfect, not my native language.

1 Like
7

@chrisgaubla:

Correct, we don’t do post-coordination, except in Measurement (“bacterial culture” - “negative”), observations and surveys. Instead, facts are declared through concepts, which are pre-coordinated.

There are a number of reasons for that:

  • The OMOP CDM actually didn’t invent that. Claims data are generally based on coding systems, which are pre-coordinated concepts.
  • The OMOP CDM is a relational database, in which relations are defined in the model, not through data. The reason is that the performance goes down drastically if the database engine has to read the content and figure out the relationships of records, rather than having that declared a-priori.
  • Well, the latter is only partially true. There are so-called EAV schemata, also known as question-answer or variable-value models. They are not quite the performance fiasco, but they have the problem that it is not clear what is the variable and what is the value (“iliac lymph node?” - “affected” vs “affected lymph node?” - “iliac”).
  • There are folks who are proposing graph structures for these data and store them in triple stores. These can be quite performant, but of course none of the current technology stack can use them. We are still waiting for a successful implementation - for a use case!

So, if you need a pre-coordinated concept “Atelectasis of the upper lobe of lung” - let us know and we put it in, including the relationship to the existing disorder and finding site.

8

Hello everyone. We are currently mapping wound data to omop. There we found the challenge that a patient might have several wounds of the same origin but at different body positions and lateralities, e.g., leg ulcers on the left and on the right side. Currently we are tackling this by inserting a new column - which is feasible - with a longer description of the wound, like “(wound: leg ulcer, position: lower leg, right, distal, central)” in order to distinguish between two different wounds. The different localisational and lateral information we put in single observations and add fact_relationships. It works so far, but it took me some time to come up with this solution.
Just my two pence to contribute to the discussion.

9

Hi Chris,
I am currently working on NPH funded project that uses OMOP database for their local code mapping. We need to create some pre-coordinated descriptions for the data we receive as there are no existing pre-coordinated SNOEMD codes for mapping. I need guidance on how to submit these pre-coordinated codes to OMOP. Kindly advice.
Thank you,
Himali

10

There is actually a tool, called Jackalope, specifically for this purpose.

It is currently rather in a state of a framework, not an independent application, but is the ideal match for this use-case.

Links:

https://www.ohdsi.org/2022showcase-41/

11

Thank you both for your respose.
Regards,
Himali

12

I hadn’t responded yet, but you already thanked me. Makes we feel guilty, and actually respond. :slight_smile:

Apart from @Eduard_Korchmar’s solution, the proper way to get changes to the vocabulary is throug hthe community contribution channel, and in your case probably the non-drug route.