Yes, agreed. That is now the stated convention. The above quoted post is from last year before the convention was formalized
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.
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)
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.
2 Likes
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.
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.
ā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 
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
Whew 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.
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.
Sorry to be re-opening this topic after more than 3 years but it seems (as far as I can google) that it is still unresolved. Concept 32220 is still not standard and NULLs are still not permitted according to the 5.4 documentation. I think the consensus is that for many use cases (albeit not all) is to allow ongoing visits.
There seem to be a variety of use cases for the data but we are looking for one rule for ETL so can I suggest option #6:
NULLs are allowed for visit_end_dates only for ongoing visits (similar to several previous suggestions but without making any other change to ETL)
This means that discharge_to_concept_id is not used to indicate the visit status so we donāt need to worry about 32220.
Because the researcher is the only one that knows their own use cases, it is their responsiblity to decide what to do with such visits. If they want to exclude them, then thatās easy to do. If they want to include count the LoS from admission date to the ETL date then they can coalesce with the ETL date from the METADATA table.
2 Likes
I would use the CDM_Source tableās source_release_date column since it is a required table that all implementations should include vs the MetaData table that may or may not be utilized by everyone.
Although I understand that the Discharge To Concept ID is not meant to hold a patientās actual status, it seems as if this column would more accurately describe the patientās status than the Visit Type Concept ID.
If we were to make the Discharge To Concept ID column required (0 if unknown) and then have a standard concept for āstill patientā it would enable us to write a data quality check that requires the Visit End Date to be populated unless itās an ongoing visit.
Good point. I donāt know how many collaborators use the Metadata table.
Correct, the visit_type_concept_id, and all type concept_ids, hold the provenance of the record. Where did the record originate? This field is not about the person or their status.
The CDM only requires fields necessary for analytics: start dates for all clinical events, length of exposure to a drug, person_id in all clinical event tables, length of stay, etc. Where a person goes after a visit isnāt necessary for the majority of use cases and many data sources donāt have this information. We could make āstill patientā a standard concept_id and allow the visit_end_date to be NULL. Or we could make āstill patientā a standard concept_id and still require the visit_end_date to be populated. Or we could come up with another solution. The one thing we as a community need to do is decide on a solution which satisfies the use cases, doesnāt break any OHDSI tools and doesnāt break any studies. Or if something must be broken, then we must give it very thoughtful consideration from a wide audience to ensure it is absolutely necessary.
@KSimon, Thank you for your input! This has been an ongoing issue for quite some time. Letās continue the discussion on this CDM GitHub issue.