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.
@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?
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?
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.
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.
(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
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.
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?
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.
