In our internal data we have things like “abdominal pain, moderate”, “abdominal pain, tearing”, “abdominal pain, throbbing”, etc.
How do you recommend to convert it into OMOP CDM?
@Sergei and I are thinking to do in this way for “abdominal pain, throbbing”:
Add record into CONDITION_OCCURRENCE table with concept id 200219 (Abdominal pain)
Add record into OBSERVATION table with 4090435 (Type of abdominal pain) and value concept id 4106708 (Throbbing pain)
Is it correct to use value concept id from “condition” domain? Do you have any constraints for concepts for “value_as_concept_id” fields?
What you are trying to do is representing the semantic concept of a pre-coordinating concept for which you don’t have a Standard Concept to map to. So, you want to take both components and store them separately. The problem is that you are losing the connection that the pain was in the abdomen. You could use FACT_RELATIONSHIP in order to preserve the connection, but ATLAS or any other attempts to query for those patients are unlikely to follow your gymnastic exercise.
This is a problem that we want to solve with the idea of extension concepts. So, you could create your pre-coordinated concepts and have them placed into the hierarchy in the appropriate way (children of abdominal pain). We don’t have the infrastructure for that available today.
So, go ahead, but in reality you will get stuck with just abdominal pain.
Thanks for your response. Do you have any conventions about concepts for field “value_as_concept_id” in the Observation table? Should we put there only concepts from the domain “meas value”?
I am thinking along the same line with @alexander.
Since in oncology, we already use the Measurement table (modifier_of_event_id, modifier_of_field_concept_id, value_as_number, and value_as_concept_id columns) to add more attributes (stage, tumor size etc.) to the Condition, I wonder whether we want to do the same thing here to resolve this issue. All we need to do is to add “moderate”, “tearing” and “throbbing” etc as the standard concept_id for the value_as_concept_id field in the Measurement table.
@Christian_Reich is right. We need to solve terminology problems (if something doesn’t exist in OHDSI vocabulary) on the vocabulary level, but not the CDM level.
I don’t think it’s just a terminology issue.
How many types of abdominal pain do we expect to have to cover the needs of various datasets?
Currently, we have 46 and there is a dramatic lack
Query
SELECT c.*
FROM concept_ancestor ca
JOIN concept c ON descendant_concept_id = c.concept_id
WHERE ancestor_concept_id = 200219
AND c.concept_name ilike ‘%abdom%’ AND c.concept_name ilike ‘%pain%’
Is it even realistic to pre-coordinate everything using every possible characteristic of abdominal pain? Don’t forget we might have severity, localization (2x axes), cause, genesis, character, timing, radiation, associations, worsening/relieving factors, etc. We could simply multiply everything by everything, but what kind of terminology will we get then?
Wouldn’t this be more balanced if we say “no” proposing a mapping to the nearest SNOMED condition? I suppose it will work and already does for most of the studies. And if someone has so specific use cases, please go the oncology WG way. But let’s provide this way first extending this option to the whole CDM and thinking about the place of Observations as modifiers.
I’d generally agree that these cases should be handled through post-coordination or rolled up. In this specific case the subjective characteristic of pain doesn’t seem to be that important if it’s not accompanied by an objective diagnosis.
I also though that an example of table that can handle post-coordination was one the oncology tables, right @Dymshyts?
Totally understood. So, we are trying a pragmatic solution, and only add those combinations that exist in the wild. Usually, that’s a small (1-20%) subset of the total.
Not really. The ETLers are just looking for a solution. The modifications came to the ETL through source vocabulary modifiers, like HCPCS and CPT4 have. Not through use cases. Since we didn’t have a proper solution we just shoved these modifier_concept_id fields in there. We need to resolve these. They are stepchildren.
Don’t forget, that “handling” doesn’t just mean us making a decision, but all the tools and libraries have to follow suit.
Exactly. We need the use cases, in order to determine if something is “important” or can be ignored.
Friends: Let’s be good. Currently, we prefer pre-coordinated Concepts that are composed of attributes of different dimensions. We do not like pre-coordinated Concepts that are composed of attributes of the same dimension (so-called AND or OR Concepts). But we get them from the not-so-clean source vocabularies all the time, and have to deal with them. And then we have EAV in MEASUREMENT and OBSERVATION, which allow to post-coordinate TWO attributes. Not more. We use them:
When one of the attribute is a value-unit combination, which cannot be modeled through distinct concepts (Lab tests)
When the Cartesian product of attributes is too large or unknown/not established (cancer attributes)
That’s it. If you want to break out of this narrow corset you will need damn good use cases. Without that, don’t waste Forum space, please.
In oncology module we have modifiers added to MEASUREMENT, So we can connect, let’s say, cancer stage (in measurement) and Cancer diagnosis (in Condition).
But it’s not a pure post-coordination thing, anyway we connect two facts represented separately in a source.
