OHDSI Home | Forums | Wiki | Github

<entity>_SOURCE_CONCEPT_ID with home-grown source data codes

CDM Builders
#1

Hello,

I am mapping home-grown provider specially codes to standard concept_id’s in the provider table, but I am having trouble deciding what to put (if anything ) in specialty_source_concept_id

I understand that the XXX_SOURCE_CONCEPT_ID is a “Foreign key into the Standardized Vocabularies representing the concept and terminology used in the source data”.

In the case of the ‘Drug’ domain the source data might contain nationally accepted / standardized NDC codes. In this case:

-The drug_source_value would be an NDC code.

-The drug_source_concept_id would be the corresponding concept_id from the concept table where vocabulary_id=NDC….

-The drug_concept_id would be the corresponding RxNorm concept_id mapped from the concept relationship table.

However, it seems unnecessary for anything to go into drug_source_concept_id if the source date contained home-grown coding (not NDC) that is not a listed OMOP vocabulary?

I am mapping a home-grown provider specialty codes to standard OMOP concept ID’s. I can easily map my values to the “Specialty” or “NUCC” vocabularies for specialty_concept_id, but do I need to put anything in specialty_source_concept_id? If so, what goes into specialty_source_concept_id given that the source coding system is not a listed vocabulary?

Thanks,
Jeff

#2

Obviously you cannot put in a specialty_source_concept_id if there is no
corresponding concept. My only point would be do distinguish between not
putting anything, i.e. set the value to NULL vs setting the concept_id to
zero, ‘No matching concept’. We have always tried to follow the rule that
concept_id fields and NOT NULL and if you don’t have anything good to say
set it to zero.

#3

Thank you very much. This is very helpful.

When the source data coding system’s vocabulary is home-grown and therefore not listed vocabulary table, I will set concept_id to zero.

-Jeff

#4

@jmcphee:

@DTorok is right.

If you have something homegronw you should use the SOURCE_TO_CONCEPT table. The drug_source_concept_id would be set to 0 in that case.

Same thing.

#5

Thank you.

-Jeff

#6

Hi Christian,

I have a follow-up question:

Say you have a home-grown provider specialty coding system, but some (but not most) code values on the source data match verbatim with an OMOP vocabulary (e.g. source value is “Anesthesiology” with is also a value in OMOP’s ‘Specialty’ vocabulary). Would you populate the Source_Concept_ID with 38004450 (Anesthesiology) on this observation, or would you set Source_Concept_ID=0 because this was just a coincidental match and the source data did not actually use an OMOP-specified vocabulary for all values?

If verbatim matches do in fact require populating the Source_Concept_ID with matched concept id, how about near-verbatim matches (e.g. if the source code had been ‘Anesthesiologist’ rather than ‘Anesthesiology’)? Populate with valid code or set to zero?

Thank you,
Jeff

#7

If your source is not one of the vocabularies in the vocabulary table, then
I would not populate the source_concept_id field. This is an optional
field, and is only applicable for analytic use cases where to not want to
run shared network studies using a common standard vocabulary, but instead
require to run the analysis on your local source codes. The motivating
example that gave rise to these fields were community members who wanted to
run icd9-based analyses rather than following the standard convention for
conditions using snomed. It is not required to do this, and generally
discouraged, so I wouldn’t force data into these fields unless you have a
known compelling reason (in which case, it’d be great for you to share that
analytic use case so we can learn from your experience and perspective).

#8

Thank you Patrick. This is very helpful.

#9

In a follow-up to Jeff’s question. If we can map our homegrown concept to a standard, would we populate the Standard_Concept_ID field with 38004450 or set it to 0?

t