Visit Occurrence and Details Discharge To

[MPhilofsky (Melanie Philofsky)]

There are two separate, but similar conversations happening. One here and one on GitHub. I am cutting and pasting my GitHub postings to this thread.

@parisni

@MPhilofsky to me there is a problem with your implementation: visit_concept_id, visit_type_concept_id, admitting_from_concept_id, discharge_to_concept_id are from Visit vocabulary and then are duplicate information from visit_occurrence table. This is no relevant information since one can join the tables to get the same information.

Agreed! And that is why I posted this opinion to GitHub:

"I would prefer we do not include the

admitting_source_value
admitting_source_concept_id
admitting_concept_id
discharge_to_source_value
discharge_to_source_concept_id
discharge_to_concept_id

fields in the Visit Detail table because these are repetitive fields from the parent Visit_Occurrence table. We only need admission & discharge once at the Visit level. Let’s just get rid of them, unless @gowthamrao has a use case?"

@parisni

Finally, in the admitting_from_concept_id, and discharge_to_concept_id of the visit_detail table, we extended the dictionary in order to track bed transfers and ward transfers.

You don’t need to do the above (and it goes against the conventions) because the Visit Detail table allows for transfers. Per my GitHub postings linked above:

“Every row in the visit_detail table has the care_site_id field and preceding_visit_detail_id field. We are able to string together the visit_detail_id and the care_site_ids to track transfers within the Visit. The conventions for the admitting_______ fields and the discharge_to________ fields state that Place of Service codes are to be used. The Place of Service code set does not offer the granularity required to track inpatient transfers.”