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

mvanzandt · September 25, 2019, 7:13am

All - The concept ID 32220 - Still Patient is not standard. Should we really be using this?

Christian_Reich · September 25, 2019, 7:23am

What for?

MPhilofsky · September 25, 2019, 8:24pm

Should we bring this to Themis or petition the vocabulary team to make this a standard concept id?

Dymshyts · September 26, 2019, 8:58am

github.com/OHDSI/Themis

Missing Visit End Dates

opened 03:11PM - 28 Apr 18 UTC

aostropolets

Incorporated! Ratified! WG#2

TYPE | NOTES -- | -- ITEM | How to handle missing visit end dates? Can we leav…e it blank? FORUM POST | http://forums.ohdsi.org/t/themis-2-how-do-you-handle-missing-visit-end-dates/4308 SOLUTION |Visit_end_date is mandatory. Use the best information to infer a visit end date. If end dates are not provided, possible ways to derive them include: 1) Outpatient Visit: end_date=start_date 2) Emergency Room Visit: end_date=start_date 3) Inpatient Visit: usually there is information about discharge. If not you should be able to derive from the sudden decline of activity, or from the absence of inpatient procedures/drugs. But the latter would be not obvious. 4) Long Term Care Visits: particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. 5) For inpatient visits ongoing at the date of ETL, put date of processing the data as mandatory visit_end_date and VISIT_TYPE_CONCEPT_ID with 32220-"Still patient" to identify the visit as incomplete. NEXT STEPS | Add this as a convention under VISIT_OCCURRENCE Add the following note to 6.5: "Visit_end_date is mandatory. If there is no definite information, the following heuristic can be used: equate end date to start date, use discharge date or another way to pick the best option"

it’s already there.

@Christian_Reich I don’t see any reasons why this concept can’t be standard.

Alexandra_Orlova · September 26, 2019, 11:15pm

Probably we should populate with that concept discharge_to_concept_id field since 32220-“Still patient” concept is from domain “Visit” and vocabulary “UB04 Pt dis status” and has nothing to do with the provenance of source data?

Christian_Reich · September 27, 2019, 6:43am

Yeah, this is a little odd. I don’t think a Type Concept is the right way. It would be something “From UB04 claim form” if we need that level of detail. What we really need is a convention for a future unknown date and put that into VISIT_END_DATE. How about 31-Dec-2099 like in the vocabularies? However, this would screw up Visit duration calculations. To be honest with you an empty VISIT_END_DATE makes the most sense here. Should we revoke the THEMIS rule?

Dymshyts · September 27, 2019, 10:16am

I like that

Christian_Reich · October 7, 2019, 10:43am

Want to put an issue in, @Dymshyts?

Dymshyts · October 7, 2019, 1:36pm

VISIT_OCCURRENCE.visit_end_date is nullable.
So there’s no CommonDataModel issue.

MPhilofsky · October 8, 2019, 9:02pm

Is nullable in v6, but the VISIT_OCCURRENCE.visit_end_datetime is required in v6. And in v5.3 the visit_end_date is required, but visit_end_datetime is not required.

Having a nullable visit_end_date/time may not be the best idea because many sources don’t have end_date for Outpatient Visits. So, there will be millions/billions of visits with no end_dates if the field isn’t required. And then folks running a study will have all these visits that start and never end. Let’s keep visit_end_date/time as a required field UNLESS discharge_to_concept_id = 32220, “Still patient”. If the Person is not currently a patient, their Visit has ended and an end_date should be populated.

Alexdavv · October 1, 2020, 3:37pm

It sounds like we need to relive Still patient Visit concept.

But I wouldn’t use it in visit_type_concept_id field.
As for me, discharge_to_concept_id field suggested by @Gowtham_Rao fits better.
It’s currently the case for the patient’s death, absence without leave, and self-discharge against medical advice.

@ericaVoss Why had you switched to type_concept_id on some point?

Discharge_to looks better, agree?

@Christian_Reich @DTorok @ericaVoss @MPhilofsky @Vojtech_Huser

MPhilofsky · October 1, 2020, 4:47pm

Agreed.

Christian_Reich · October 5, 2020, 5:54pm

With? The still patient?

MPhilofsky · October 5, 2020, 9:08pm

@Christian_Reich,

And I suggest we change “should” to “needs”

Chris_Knoll · October 5, 2020, 11:53pm

I’d like to suggest we don’t use null end dates: we won’t be able to determine what the total visit time is, and I don’t think using getDate() is the right answer:

If you ETL’d your data yesturday, then the visit length for today will result in visit of some date length, which will be different when you run the query tomorrow or the next week (because the ETL data is ‘frozen in time’ but our real-world clock keeps running, making the visits look longer just because we queried the data on a later day.

Instead, when you ETL, visits should end as of the ETL date, and attach soem status to the visit that they are still patient. In this way, The ETL is as of (for example) 9/1/2020…and someone who was admitted 8/15 has a visit duration of 15 days (as of the data)…but are also marked as ‘still patient’. No matter when you analyze the data, that person has had a (continuing) visit duration of 15 days. Next time you ETL on 9/7, the person now has 22 days of duration, and is still a patient…next time he really leaves on 9/10, and has 25 days of visit duration, and has now been discharged.

I don’t see how we can do the same thing if we leave the visit end dates null and use getDate(). That would only work if systems were ‘real time’ but I don’t think there’s any systems that operate like that (even if they were wouldn’t they be ‘snapshotted’ to do an analysis as of a certain date?)

-Chris

Christian_Reich · October 13, 2020, 9:27am

@Chris_Knoll, @MPhilofsky :

I think the problem is that people don’t care how long the patient was already in the hospital as of today/date of EHR etc. They want to exclude that patient from visit duration calculations altogether, because the patient hasn’t ended his/her visit.

How about we leave the end_date null, effectively achieving that exclusion. If you really want to know what’s happening you can always do coalesce(visti_end_date, observation_period_end_date).

Your “still patient” solution would achieve the same trick, except for the standard use case (give me the average duration for population XYZ) it always needs an extra join to the OBSERVATION table.

Thoughts?

Christian_Reich · October 13, 2020, 9:28am

Outpatient visits by definition end the same day. The visit_end_date should always be filled=visit_start_date.

bailey · October 13, 2020, 1:05pm

For yet another variation on the theme, we don’t require a visit_end_date for outpatient visits, based on visit_concept_id. But we do follow @Christian_Reich’s proposal for inpatient visits, where a null visit_emd_date indicates that the closing date isn’t known, typically because the visit is ongoing at the time of ETL. In that case, the end of the observation period is typically set by some other factors; a MRD administration, a lab test, a vital sign measurement, a procedure.

Chris_Knoll · October 13, 2020, 1:43pm

We don’t? You may not, but we have analysis where we are looking for outcomes during hospital stay. So the Time At Risk is defined as visit_start to visit_end, and if visit_end is null, then you’re saying that we just drop those people, but we want to follow people while they are in the hospital…so we really need an end date. And, per my agruments against this above: we don’t want the follow up time to change based on which day you ran the query against the data.

If people are updating their CDMs daily to mark people ‘still patient’ etc, why is it so hard to just sweep the people that are ‘still patient’ to update their visit_end_date as the current date? You have to do that with observation period end dates too, yes?

MPhilofsky · October 13, 2020, 2:21pm

We won’t be able to determine the total visit time until a visit officially ends, regardless if the visit_end_date is populated with the ETL date or NULL. My concern is if visit_end_date is populated, analysis will be done on what looks to be a completed visit even if it is ongoing. I imagine it being used to calculate average or mean length of stay when it shouldn’t be used for such a calculation. I doubt most people will look into the discharge_to_concept_id field for this information. By leaving the Visit end_date NULL researchers will know/be forced to know the Visit is still ongoing. The Observation Period.end_date and CDM_SOURCE.source_release_date will both be = to the ETL date. Actually, ongoing visits shouldn’t be used for a lot of analysis, but folks want to know what happened/is happening with emergent conditions. Covid is really thrusting the ongoing visits into the spotlight with the continuously evolving medical and diagnostic treatments. Another idea that has floated around is not including ongoing Visits in the Visit table. I think for most use cases this would not be a problem, but for Covid, it could make the inpatient hospitalization rate for Persons with a positive Covid test look really low for the most recent data when in actuality the Covid hospitalization rate is increasing. I’m not sure the best way to represent ongoing visits

Option 1: Leave Visit end_date as NULL if the Visit is ongoing AND have discharge_to_concept_id = 32220

Makes an ongoing Visit obvious.
Could this break OHDSI tools? Atlas? I know we would get error/warning/fail messages on our data quality applications

Option 2: Populate the Visit end-date with the ETL date if the Visit is ongoing AND have discharge_to_concept_id = 32220

Data may be used ‘as is’ without consideration a visit is ongoing because it isn’t obvious.

Option 3: Remove ongoing visits from the Visit table

Will falsely decrease the # of inpatient Visits for the time period closest to ETL date

Option 4: ?