OHDSI Home | Forums | Wiki | Github

(THEMIS 2) How do you handle missing visit end dates?

themis

(Melanie Philofsky) #41

Yes, agreed. That is now the stated convention. The above quoted post is from last year before the convention was formalized


(Charles Bailey) #42

FWIW, option 1 seems to make the most sense to me. Right now, we have discharge_to_concept_id NULL until a patient is actually discharged to somewhere, so that might also be an easy way to identify ongoing visits without assigning a value to this field.


(Chris Knoll) #43

With all respect, I do not agree with this assertion: if I’m in the hospital for 7 days and I’m still in the hospital, my total hospital time is 7 days … and if I hand over my patient level data to someone for analysis as of that day, they should know that i was in the hospital for 7 days regardless if the analysis was performed a week later of a month later.

If we want to know that the patient is ‘still in hospital setting’, i’d recommend some sort of visit_status (like we have with condition-status) to indicate that. Or an observation if we feel that for the most part, visit_status will always be ‘discharged’.

I’m not clear on the use case where we need to know that the visit is completed and only completed visits are valid? A person who is in the hospital for 90 days doesn’t count for anything until they discharge?

yes, but ongoing as of when? See prior points: I run the query to get the total time person is in hospital, using get_date() on a null column to ‘fill it in’ gives me different duration based on the day I run the query…If I want to know how much time people are spending in the hospital, is your argument that people currently in the hospital don’t count?

Maybe the answer is to not populate the CDM with incomplete visits…(your Option 3). Not a fan of that choice tho, I don’t like ignoring data…

Why? I’m not trying to be obtuse, I am generally interested in knowing this reason because there’s some gap in my analytical thinking that this is an important point that I don’t understand.

Sorry, I looked up that ID, and it’s from the UB04 Pt dis status vocabularyID, I don’t see how that indicates ‘still patient’. I think that if we have a discharge_* column on the visit, any visit with a NULL discharge value could be interpreted as ‘not discharged’ but for ETL’ers who aren’t populating that column, everyone would appear ‘not discharged’ but I think this is where the value of NULL (or lack of a value) would make logical sense. (like @bailey described)


(Christian Reich) #44

I think this is the source of confusion, @Chris_Knoll. The reason is simple: The length of a visit is a typical use case for outcome of a disease (the longer, the more severe the condition, or the higher the healthcare utilization). While a patient is still in the hospital we don’t know how long that is going to be case, so having the NULL value kick out those cases is exactly what we need. So, the length is not from beginning to some arbitrary “now”, but from beginning to the actual discharge.

The discharge_to_concept_id is not meant to indicate whether or not a patient is discharged. That’s what the visit_end_date should do. The discharge* field indicates whether or not (NULL in this case) the patient maintains engagement with the healthcare system. If the patient goes home, or bolts against medical advice to go home, by definition there is no healthcare. Otherwise, if the patient goes to a rehab, or hospice, or some kind of home service the concept from the Visit domain will indicate so.


(Chris Knoll) #45

Still not clear why you require a discharge to know that a person has been in the hospital at least X days in order to certify a certain level of healthcare utilization. In the prior example, I was in the hospital for 7 days, at which point I developed a AE of a GI bleed, and we’re going to say ‘must have at least 3 days of healthcare utilization’. Wouldn’t I qualify? (rhetorical) I feel like looking for the end date in the future of some outcome leads to a certain type of bias…

Another way of saying: I don’t think the only use case of visits is ‘until they discharge’. You could start a study (and I have) looking for VTE/DVT events after completion of a surgery (TKA). If the context of this was prospective capture of the data, people go from ER to a hospital bed in the same week, which I want to study. But I can’t because they haven’t been discharged yet. I’m baffled, but I don’t want to beat a dead horse…if the model doesn’t support the use case, that’s fine, just need to be aware of it.


(Christian Reich) #46

@Chris_Knoll:

If the use case is about things happening during a Visit or after admission than it’s fully supported. You wouldn’t look for the end date. You’d take all the Procedures/Measurements/Conditions affiliated with the Visit. If the cross-link isn’t there, like in some data assets, you can still use the open-ended visit, because no end_date means the Visit was still going on at observation_period_end_date. Don’t see an issue.


(Melanie Philofsky) #47

‘Total visit time’ = Admission to discharge.

Your use case for an ongoing visit is valid and analysis can be completed on the unfinished Visit.

My use cases: length of stay, healthcare utilization, disease outcome, further utilization of healthcare services with a discharge to SNF or rehab, etc. Who leaves the hospital to go home and who goes to the morgue? These can’t be determined until the Visit ends.

concept_id = 32220 has concept_name = ‘Still patient’ with domain_id = ‘Visit’ and per conventions we are to use standard concepts with domain_id = ‘Visit’. Obviously, the ‘standard’ part is an issue since the concept is non-standard, but I’d like to fix this :slight_smile:

According to Christian, discharge to a non-healthcare institution will not be represented in this field because it is assumed the Person went home. Also, this is NOT a required field and not all collaborators have this data.

Option #2 should satisfy all use cases. It’s just against the rules right now. And I would like the rule to be changed to allow NULL Visit end_dates ONLY when a Visit is ongoing. If the Visit is not ongoing, then an end_date needs to be populated. Populating the date of ETL as the Visit end_date for an ongoing Visit is not necessary and will affect analysis


(Chris Knoll) #48

Whew :slight_smile: I’m glad that we’re on the same page that this is indeed a valid use case.

yes, of course, if your analysis depends on the visit ending, then of course the visit must end, but the primary point of this thread is leaving visit_end_date null, and for your study those records wouldn’t have an impact. I would prefer that you could use discharge status to determine…discharge status, and I appreciate the logical attraction to ‘visits that didn’t end don’t have an end date’, but I need some help resolving the following:

I’m calculating an incidence rate where I’m going to calculate the number of cases / total follow up time. We’re only going to use visits for total knee replacement, and we’re looking for an outcome of deep vein thrombosis.

In this data cut, I have people that are discharged and people who are ongoing recovery. For one person, they stayed in the hospital for 7 days without DVT issues, so they contribute 7 days of follow up. For another person, they developed DVT on day 4 of their visit, and left on day 8. This person contributes 4 days of follow up, and is a case.

But, I find a person who started their visit, and developed DVT on day 3…this person hasn’t been discharged, so I am able to find their follow up time (3 days) and put them into the denominator of my IR calculation. However, there is another person who started their visit, did not develop a DVT…and there is no visit end date. I don’t think I can just ignore the person, as to not include their follow up time will bias my IR calculation. But they are contributing time without a DVT…How many days should they contribute to my IR calculation?

Ok, so taking this direction, we would take the observation_period_end_date as the visit_end_date if visit_end_date is null. If we want to make this a rule, we should make sure that our tools apply this logic.


(Roger Carlson) #49

I’ve been following this issue, but have refrained from commenting so far because, as an ETL developer, I’m more interested in getting data in than getting data out. Our standard is not to put any hospital visit into OMOP until it is completed (discharged).

I have a background in Quality Improvement, and we did the same thing there. Our model was to use Statistical Process Control charts to track retrospective trends in data to avoid special cause variation. We required between 18-24 data points (usually monthly), so patients currently in the hospital were statistically insignificant.

It seems to me, research is much the same. It’s looking at data statistically; not so much individually. Christian has often said that OMOP is observational data for research, not to run your hospital or insurance company. Is it also fair to say it’s not for near-term clinical decision making?

Now, if you’re using an OMOP database as a reporting database, then you certainly have a use case for including patient who are not yet discharged. You can use it however you like, but I don’t think that should influence the standard.


t