OHDSI Home | Forums | Wiki | Github

About fields added in cdm v5.1 visit_occurrence table

CDM Builders
#1

I reviewed the newly added field in CDM v5.1.

And I would like to ask if I understood the new field well.

I read the explanation on the OHDSI wiki and understood as follows.
Is my understanding correct?

In visit_occurrence table

  • Admitting_source field: Information about where the patient was served before visiting the hospital
  • Discharge_to_source field: Information about where the patient will be served after discharge from the hospital
  • Preceding_visit_occurrence_id field: Enter the previous visit_occurrence_id immediately if the patient has a visit history prior to the visit

In condition_occurrence table

  • Condition_status_source_value field: For example, if you were diagnosed at admission, enter ‘admission diagnosis’. And if you were diagnosed at discharge, enter the status when you entered “discharge diagnosis”

If the above is misinterpreted, please give me a detailed explanation.

Thank you.

#2

@Dahye_Shin:

I think you nailed it. If you think the documentation could be in need of some improvements, let us know.

#3

@Dahye_Shin

A slight clarification: admission source and discharge disposition may also be ‘Home’, so it’s not necessarily medical facility,

1 Like
#4

@Christian_Reich, could you clarify what does the word immediately in visit_occurrence.preceding_visit_occurrence_id description means? Should this field be populated for any previous visit or is there a rule according a date range between visits?

And could you explain the meaning of this new field, for which situation a linked history of visits might be useful?

#5

@NStarikova:

Good question. The meaning was indeed immediately (same day or day before), but now we have VISIT_DETAIL, so these Visits stacked up against each other should go to that one.

@rimma; @Gowtham_Rao: You are the main sponsors of this stuff. What do you think?

#6

Visit_detail is the child of the visit_occurrence. Sequential children maybe represented using preceding_vi*. There is no need to infer sequence during ETL if the source data did not have the sequence. Inferring sequence may be done thru temporal association at analytic time. If the source data has a sequence, then preceding_vis* maybe useful.

#7

@Gowtham_Rao:

I understand, but the question is about what “preceding” means. Is it “immediately preceding” or could there be a gap? For VISIT_DETAIL I think it should be immediate (same or previous day). For VISIT_OCCURRENCE only in rare coincidence, where one hospitalization is truly followed by another one the next day, but they are not considered the same thing.

#8

Good question. I don’t know @rimma ?

(don’t think i was part of the cdm discussions that lead to addition of this field)

However - I don’t think we should ‘infer’ this during ETL. If the source data says that two records are sequential (i.e. Source data says one record precedes the other), then we should use the field. So, the use of preceding_visit* should be to maintain provenance to the source data, not be an ohdsi convention

#9

@Gowtham_Rao:

But all that is part of the ETL. If you have, say, a claims database with claims from Blue Cross Blue Shield you will preserve it. If you have an EHR database you may have to interpret a hell of a lot to get it right.

#10

From https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE

admitting_source_concept_id: A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.
discharge_to_concept_id: A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.

For the above two fields in visit_occurrence and visit_detail, we are being asked to used the place-of-service vocabulary. Athena Place-of-service vocabulary belongs to the place-of-service domain, and class place-of-service.

My question is around OMOP CDM design principles – should the concept_id’s populating admitting_source_concept_id and discharge_to_concept_id have the domain’s ‘admitting source’ and ‘discharge to’? Or is it ok to use place-of-service domain to populate these fields?

#11

@Christian_Reich @Gowtham_Rao @Dahye_Shin,

Apologies for continuing on the old thread.

Can you please help me with the below post? Though I have mapped few fields, I am quite confused as to how can I map the remaining fields?

Thanks
Selva

#12

@SELVA_MUTHU_KUMARAN:

Sorry for the radio silence.

In general, you are on the right track:

  • For the visit_occurrence_id you can, but needn’t utilize the original Encounter_ID_masked
  • The visit_type_concept_id needs to get on of the Visit Type concepts:

select * from concept where vocabulary_id='Visit Type';

  • provider_id: You can leave that empty, unless there is something like a primary provider for the encounter
  • care_site_id: Same thing. This is supposed to contain the Care Site the Visit happened.
  • visit_source_concept_id: When you map a code from vocabularies “Medicare specialty”, “CMS Place of Service”, ‘NUCC’ or ‘ABMS’ and it is a non-standard concept mapped to a standard one, the non-standard one goes here. In your case, you seem to be operating off of short text strings. In that case, you may not fill this field at all.
  • admitting_source_concept_id and discharge_to_concept_id should contain the same Visit concepts you use in visit_concept_id. Except we need to work on birth and death, still.
  • Discharge_Disposition is the same thing as discharge_to_concept_id
  • Service is not used in OMOP: Visits don’t have specialty. Only providers do.
  • Location_masked: Looks like you want to put that into the CARE_SITE table, and then link the corresponding care_site_id to the equivalent field in the VISIT table.

Hope this helps.

#13

Thank you for the response @Christian_Reich

#14

@Christian_Reich
When it comes to birth, how to deal with admitted_from_concept_id? I haven’t found any concept fitting this situation.

#15

@qiongwang:

Yeah, we need “Admitted from the Heavens” or something. :slight_smile:

You don’t need an admitted_from for the child. The child is born. The fact is stored in PERSON.

#16

@Christian_Reich
admitted_from_concept_id is a required field, can we used Concept 32206 "New Born " ?

#17

@Christian_Reich,

Is this a mistake:

It’s required in v6 documentation, but should it be? This is a change from v5.3

#18

That’s wrong. We don’t always know where a patient is admitted from. Will have to fix in the CDM.

#19

It’s clear, thanks @Christian_Reich

t