OHDSI Home | Forums | Wiki | Github

Mapping - Visit Occurrence Table

Hello Everyone,

Can you please help me with the mapping for Visit_Occurence Table? The below are the list of columns that I have from raw data file and they have to be converted to OMOP CDM format for visit_occurence table. Though I was able to find some relevant matches, I am stuck with rest of the columns. Please help

Can you please confirm as to whether I have correctly mapped and how can I map the ‘remaining source columns’ shown in screenshot above to OMOP CDM format?

Please note that Athena returns 0 results under ‘place of service’ class for values like ‘Discharged against advice’. Transferred to Nursing’ etc. However, I am able to find some matches in ‘Pt dis status’, should I follow that? But the CDM convention is to follow the ‘Place of service’ class for the field discussed above


The definitions for these fields are confusing. Here’s my take:

  • Visit_concept_id is the concept_id that corresponds to your Enc_Type. For instance, Outpatient = 9202 and Inpatient = 9201, etc.

  • Visit_Source_Value is where you put the actual text of your Enc_Type (ie “Outpatient”, etc).

  • Visit_type_concept_id is a concept_id which reflects “the type of source data”, not the actual “visit type”. So an example would be: 44818518 = Visit derived from EHR record. If all of this data is from an EHR, you could just hard-code this value.

Now when you see fields that end in “source_value”, it’s asking for the value from the source of the preceding term. Like the above Visit_Source_Value, it’s asking for the Value of Visit that is in your Source. Always keep the term “source_value” together. Like Visit:Source_Value rather than Visit_Source: Value. See the difference?

  • Admitting_source_value is asking for the Admitting code or description that is stored in your source system.

  • Discharge_to_source_value is asking for the Discharge Disposition in your source system.

Likewise when you see a field that ends in “source_concept_id” always keep those terms together. It is asking for the concept_id IF AND ONLY IF it is stored in your source. So:

  • Visit_source_concept_id should only be filled in if you have the actual concept_id for Visit stored in you source system.

  • Admitting_source_concept_id should only be filled in if you have the concept_id for Admitting stored in your source system.

It doesn’t look as if you have any concept_ids stored in your system, so all of those should have a 0 (zero).

The documentation at https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE should help you. The visit_type_concept_id should be a concept where the vocabulary_id = ‘Visit Type’, see what best represents your source data. It does not look like your source data has admitting information, so set the admitting_source_concept_id to zero and leave the admitting source value as NULL. Your source has discharge disposition. The discharge_to_concept_id should be a concept where the vocabulary_id = ‘Place of service’ and the discharge to source value should get the discharge disposition from your source data.

1 Like

Hello @DTorok

Thanks for the response. However for the discharge disposition, I don’t find relevant matches in ‘Place of Service’ vocabulary. However I am able to find closer matches in ‘UB04_pt_dis_status’. Is it okay to use that as long as it’s a standard term?

No you should not use ‘UB04 Pt dis status’ concept because the documentation says the concept should be in the Place of Service vocabulary. You should request that the Themis group look into allowing ‘UB04 Pt dis status’ concepts in discharge_to_concept_id. In the meantime you could add a couple of rows to your Visit Occurrence table to hold the discharge disposition and discharge disposition concept.

@DTorok - I saw that you have raised the above pointer as an issue with Themis. Thank you Don Torok. I have subscribed to the thread in github.

Can you also please help me with the below post?