OHDSI Home | Forums | Wiki | Github

Double domains

CDM Builders
#1

Hi @Christian, @Dymshyts,
there are concepts in ‘Read’ vocabulary under double source domains (please see them in attachments). These codes do not have target concept_id in concept_relationship.

For example, if a concept is under domain ‘Condition/Obs’, it should be populated in both condition_occurrence and observation? And the same should be applied for other domains from the list below?

double_domains.xlsx (12.2 KB)

Thank you,
Irina

Question : Double Domains
#2

If you have these double domains, you choose the one table:
here is how you choose:
Condition > Procedure > Measurement > Observation > Device > Drug
(i.e. Condition/Proc domain goes to Condition, Procedure/Observation domains goes to Procedure)

#3

Hi, @Dymshyts: I was under the impression that standard concepts would only ever have one domain. Has this changed?

#4

Those are non-standard.
so they populate the table (let’s say condition) this way:
condition_concept_id = 0
source_concept_id = {this_non_standard_concept}.

#5

I understand now, thank you. I missed the part where these source concepts did not have a target concept ID (and therefore don’t have a standard concept mapping).I hadn’t thought to use the source concept’s domain to populate the appropriate CDM table when a concept doesn’t have standard concept mapping. That makes sense.

#6

@Dymshyts @Christian_Reich The old ETL documentation seemed to suggest that condition/procedure target domain_id meant that the fact went in both tables… could you confirm that it really means to go into one table with the prioritization… is that still true?

Why would they list the target domain as condition/procedure if they already have a deterministic way to resolve to one domain… i.e., why wouldn’t they just remove that hybrid domain_id?

#7

Well, actually
select * from concept where lower (domain_id) like ‘%/%’ and invalid_reason is null
;
Here we have only OXMIS vocabulary and we haven’t have any use cases using of it for a long time, so we haven’t updated it.
So for now for active concepts you’ll have only one domain available.
And for now it’s pretty straightforward - you use one domain.

But on the other hand you may meet outdated concepts in the source data, like this one:
id = 45481470 name = Flashbacks. And we didn’t update the domain definition for them also as they are outdated.
@Christian_Reich, should we update domain definition for those Depracated concepts?
again it seems to be the same problem derived from the ambiguity of deprecation:
deprecation as out mistake - we don’t do anything with the concept then
deprecation as outdated by the source - we treat this concept normally as it may be present in a patient data.
what do you think?

#8

That may make sense.

t