OHDSI Home | Forums | Wiki | Github

Source concept_id for gender, race and ethnicity


(Akshay Kumar) #1

Hello Everyone,

I am trying to map my patient details to OMOP CDM form. Though I already referred the related post , I have a quick question here.

I understand it may not be an important piece of information to store.

However, may I check what can be the source_concept_id values for Gender, Race and Ethnicity?

For ex: When I am dealing with ICD10 codes, I can for ex type M5:10X etc in OHDSI Athena and get the corresponding concept id which might be non-standard. So, this non-standard concept_id will go to source_concept_id and the corresponding standard concept_id will go concept_id filed. This is something I am aware

But what would happen for terms like Gender, Race, Ethnicity. If it’s always going to be zero why do we need those columns?

Can help me understand what will be the source_concept_id values for Gender, Race, Ethnicity?

(Roger Carlson) #2

As I understand it, the general reason for all of the “source_concept_id” fields is for additional information, particularly for data validation. If your source system happens to store a concept with a “standard” vocabulary value, it becomes useful to compare that to the mapped concept_id.

In most cases, Gender, Race, Ethnicity will always be zero. So why have them? Well, if some standards agency came up with a comprehensive standard for, say, race, AND source vendors (like Epic or Cerner) decide to start storing values with those codes, then the fields would already be in the OMOP standard ready for use.

(Don Torok) #3

There may not be a good use case for saving the Gender, Race and Ethnicity source concept id’s. But the CDM designers are trying to maintain a consistency for fields. You have _source_value, _concept_id and now _source_concept_id. Trust me if they were not included, others would be asking why the CDM sometimes wants the _source_concept_id and other times it doesn’t. Put in the zero’s and live with some of the small quirks of the CDM.