Question about storing related codes of different domains

[mr.nim.li]

Hello everyone,

I am very new to the OHDSI community … I hope I have posted the question to the right place.

We have a source system that organizes pathology data in Question-Answer format. For example, the data can be like:

‘Q’ - Skin Invasion (with a CAPECC code)
‘A’ - Invasive carcinoma does not invade into the dermis or epidermis (with another CAPECC code)

In this example, I can find the mapping of the CAPECC code to the Standard code through the concept_relationship table. With the mapping, the Standard codes look like:

‘Q’ - Skin observable (concept id: 4265704, under domain: “Observation”)
‘A’ - Intact skin (concept id: 40481164, under domain “Condition”)

Since the ‘Q’ and ‘A’ are under 2 different domains, I expect they will end up being stored in 2 different tables - The ‘Q’ will go to the “Observation” table, and the ‘A’ will go to the “Condition_occurrence” table.

Following the documentation:

https://ohdsi.github.io/CommonDataModel/cdm54.html#OBSERVATION

I am thinking to use the “observation_event_id” and “obs_event_field_concept_id”, of the “Observation” table, to link the ‘Q’ and ‘A’ data together.

So in the “Observation” table, the “value_as_concept_id” field will become null (because the ‘A’ will be stored in the “Condition_occurrence” table). Instead, the “observation_event_id” field will store the ‘condition_occurrence_id’ value of ‘A’ (from the “Condition_occurrence” table), and the “obs_event_field_concept_id” will store the concept id 1147333 (to indicate it comes from the “condition_occurrence” table).

Is my understanding correct?

I am asking this because I initially thought that both the ‘Q’ and ‘A’ would always be stored in the same table, but this does not seem like the case here. Also, looking at another post:

https://forums.ohdsi.org/t/what-is-observation-event-id-and-obs-event-field-concept-id/7194

it seems these 2 fields - “observation_event_id” and “obs_event_field_concept_id” - might have been created for other purpose before. So I want to check with other people whether I am on the right track.

Any feedback is welcome. Thank you!!

[DTorok (Don Torok)]

More applicable forum discussion where the point is that the Observation value_as_concept_id can contain concepts that belong to domains other than Observation.

Put you question/answer pairs into the Observation table
Observation concept id = Skin observable (concept id: 4265704, under domain: “Observation”)
Observation value as concept id = Intact skin (concept id: 40481164, under domain “Condition”)

[Christian_Reich]

@mr.nim.li:

@DTorok is right, except it is only the short answer. The longer answer is this:

Question-answer data are possible, but not that useful. Because unless you are intimately familiar with what you are searching for you will not find it. For example, your skin invasion example could also be Q: Invasion of adjacent organs - A: Skin (or correctly None, since the skin is not invaded), and you would have to search both in the question and in the answer. The typical analyst wretch will give up at this point.

Instead, we have fully pre-coordinated concepts that say it all and can be searched. Your skin invasion is OMOP concept ID 36770094 Invasion into the Skin. Like all cancer attributes it is a Measurement. Since the skin is not invaded you have to negate it by putting 9190 Not detected into value_as_concept_id.

You seem to have CAPeCC data. If you want you can export them (no patient level data please) and we map them over. Most of them should have a hit.

[mr.nim.li]

Hello,

@Christian_Reich and @DTorok, thank you so much for both of your feedback!

@DTorok
…value_as_concept_id can contain concepts that belong to domains other than Observation…

I see. oo … I misundestood the concept then … … mm … Please let me clarify my understanding …

So in our case, when the pathology data comes in question(‘Q’)-and-answer(‘A’) format, I should aim to keep the pair of data together in the same table. Which table the pair can go to depends on the “domain” of the mapped-concept-id of ‘Q’.

Looking at the documentation, both of these tables - ‘Observation’ and ‘Measurement’ - contain the “value_as_concept_id” field. So in these 2 tables, when I store the mapped-concept-id of ‘A’, I can always store the value to the “value_as_concept_id” field regardless of what “domain” ‘A’ belongs to. I suppose this is also true when both ‘Q’ and ‘A’ belong to the same domain. For example, in another case, I have seen:

Q - Appearance of skeletal muscle (concept id: 4271648, under domain: “Observation”)
A - Unidentified (concept id: 4321411, under domain: “Observation”)

so for this case, in the same record of the Observation table, I would have 4271648 in the observation_concept_id and 4321411 in the value_as_concept_id.

In case if I misunderstood anything (again), please let me know.

@Christian_Reich
…Question-answer data are possible, but not that useful … we have fully pre-coordinated concepts that say it all and can be searched…

I see. Just to clarify my understanding - so, even if we manage to find a one-on-one mapping of the CAPECC code to the Standard code (through the downloaded vocabulary), in our situation we may consider to re-do some of the mapping (manually), in order to make the search more straight forward for our users later.

FYI, in our team, @Anisa is currently managing the manual mapping of the data. I will discuss this with her.

@Christian_Reich
…You seem to have CAPeCC data. If you want you can export them (no patient level data please) and we map them over. Most of them should have a hit…

Thank you so much!
We have another team member Gord (…not sure about his OHDSI user id…) who has downloaded the CAPECC vocabulary from Athena. With the downloaded vocabulary, I have written some SQL codes to find the mapping of our CAPECC codes to the OMOP Standard code through the concept_relationship table. For the CAPECC values that we cannot find any match, @Anisa is working on them with Usagi now. We are actively working on this. I will discuss your feedback with her.

Please let us know if you have any thoughts and comments. Many thanks!!

[Christian_Reich]

You may want to come to @agolozar’s oncology WG (golozar аt ohdsi.org). That’s where will find all your new friends.