Currently in the OMOP CDM v6.0 documentation, under Visit Occurrence table section (Page 35 in PDF file), it states as follows:
“discharge_to_concept_id Yes Integer A foreign key to the predefined concept in the Place of Service
Vocabulary reflecting the discharge disposition for a visit.”
I believe this is very confusing and has been raised as a Themis issue by @don-torok (https://github.com/OHDSI/Themis/issues/52). It should be changed to:
Source Concepts are mapped into vocabulary ‘UB04 Pt dis status’ and can then be mapped to standard vocabulary.
I suggest we change the documentation for Visit Occurrence discharge_to_concept_id to allow concepts from either vocabulary, ‘UB04 Pt dis status’ or ‘CMS Place of Service’.
The allowable values for Visit Detail discharge to concept id may have to be expanded even more if the OHDSI community decides that the discharge to concept id can be used to describe in hospital transfers such as ICU to general hospital bed.
All of these will be Visit concepts. We have mapped the UB04 uglinesses to them. Will have to fix the documentation.
Hi!
I have some concerns about discharge_to_concept_id and discharge_to_source_value fields:
we have UB04 Pt dis status codes in source data. According to the concept table, all these codes are non-standard, but target concept ids not always look proper.
For example, Discharged to home/self care (routine charge) and Discharged to Care of Family/Friend(s) are mapped to 581476 - Home Visit.
Part of the codes is not mapped.
For example, Still patient or Left against medical advice or discontinued care.
If a code is not mapped to a standard concept, we will loose all information about it unless add some prefics like ‘UB04 Pt dis status’:
discharge_to_concept_id = 0
discharge_to_source_value = ‘07’ or discharge_to_source_value = ‘UB04 Pt dis status: 07’
Hi! I have one more thing to add. ‘Still patient’ is currently non-standard and not re-mapped to any standard concept BUT it is presented as an example in Rule 11 for Visit_occurrence table.
You are right. This is wrong. There is no Visit. Being at home is not an encounter with healthcare. Thanks for the catch.
Well, that is the same Visit as before. Your ETL code has to just extend the existing visit.
This is exactly the same as you mentioned in your first paragraph: The patient went home = no more healthcare encounter = no Visit. The fact that the Visit ended against medical advice we don’t have a way to capture right now. I could think of some kind of stop_reason. Is there a use case for that?
I will say that as many times as I have to, which means, probably indefinitely: If we don’t have a use case we don’t mind losing information. Keeping information just because we have it is the “attic use case”.
Yep.
We are rewriting these descriptions. Sorry for making you wait.
I don’t have a use case. ‘UB04 Pt dis status’ vocab was standard some time ago and when this vocab became non-standard, we got the losing info issue. So I was just wondering whether or not it is possible to keep information that we didn’t lose before vocabulary update.
I will attach a sticker to my monitor 
Thank you for the answers!