OHDSI Home | Forums | Wiki | Github

Difference between person_id and person_source_value column in PERSON table of OMOP CDM


(Chetan) #1

What’s the difference between person_id and person_source_value columns in PERSON table? If MRN needs to be mapped, then to which of these two columns must be used?

(Eldar Allakhverdiiev) #2

@CSC source_value columns store how a certain entity is identified in the source data.
If, for example diagnosis is recorder as ICD code then condition_source_value should store this code, while condition_concept_id - concept_id of the ICD concept taken from vocabulary.

For person table column person_source_value should store how is person identified in your source data (social security number,alphanumeric encrypted code etc.) So, you’d put MRN into person_source_value

(Chetan) #3

Thanks Eldar.
Now it makes more sense. :+1:
So is Person_Id an auto-generated identifier for PERSON table?

(Evan Sholle) #4

If, for example diagnosis is recorder as ICD code then condition_source_value should store this code, while condition_concept_id - concept_id of the ICD concept taken from vocabulary.

Wait - I’m a little confused here. My understanding has always been that the ICD concept from the vocabulary is stored as the condition_source_concept_id, and that the condition_concept_id should be a Standard Concept (standard_concept = ‘S’) - using CONCEPT_RELATIONSHIP to derive this relationship. So in your example, let’s say the patient was diagnosed with 732.2. What you’d end up with in CONDITION_OCCURRENCE is a row with a condition_source_value of ‘732.2’, a condition_source_concept_id of ‘44826910’, and a condition_concept_id of ‘133848’, after mapping.

select c1.* from concept c
join CONCEPT_RELATIONSHIP cr on cr.concept_id_1 = c.concept_id
join concept c1 on c1.concept_id = cr.concept_id_2 and relationship_id = 'Maps to' and c1.standard_concept = 'S'
where c.concept_id = '44826910'

Have I been laboring under a misconception? @aostropolets, @Christian_Reich, thoughts?

(Shrikant Kunte) #5

Yes @CSC , Person_id is autogenerated identifier for PERSON table. You can get more information from https://github.com/OHDSI/CommonDataModel/wiki/PERSON

(Chetan) #6

Thanks Shrikant.
I had already been to CDM\PERSON. But I assumed that person_id could be MRN as well because MRN is also a unique identifier (in source table). Also, person_source_value has a ‘No’ under Required column, so if it is populated with MRN then there should be ‘Yes’ in Required column, because MRN would rarely be null/blank/unavailable for a patient.
Please correct me if I am wrong.

(Eldar Allakhverdiiev) #7

@esholle ,
Thank you for the example - I just saw, that made a mistake in the explanation.
You are right - I meant condition_source_concept_id, but not condition_concept_id

(Roger Carlson) #8

I personally would not use MRN as the person_id for the same reason I wouldn’t use Social Security Number. They can change. The actual value can change, the datatype and format can change. If it’s stored as a string (even if the string is all digits), it might not be able to convert to an integer. Best bet is to use a system generated number, whether it’s one created by your EHR or one generated in the OMOP ETL process.

(Anna Ostropolets) #9

@esholle yep, all correct.
@CSC Agree with Roger, I wouldn’t use MRN as person_id for the same reasons, although you can, of course.

(Chetan) #10

Thanks Roger. :+1:

(Chetan) #11

Thanks Anna :+1:

(Christian Reich) #12


For Conditions, and other medical domains like Drug, Procedure etc. data are stored in standardized coding systems. The OMOP CDM representation works the way @esholle describes it (code in source_value, concept for code in source_concept_id, mapped standard concept in concept_id).

For Person, there is no standard. You can put anything you want into person_id and person_source_value. You can use the EHR record number in either one, or create a new person_id from it, or hide the true ID from both fields. The OMOP CDM does not care, it will only use person_id to link data for the same patient from different tables. Your decision depends on your security requirements (hiding or using the record number) and if you want to be able to refer back to the original source. That’s outside the OMOP definition.