OHDSI Home | Forums | Wiki | Github

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

CDM Builders
#1

Hi all,

During our last THEMIS Group 2 meeting, we discussed the problem of how to fulfill the visit end date field in visit_occurrence if no tangible date is available from the source data. We would like to hear from the community of CDM Builders about how you currently deal with this issue.

From the Janssen side, we would make it a 1 day visit, but that does not necessarily make clinical or practical sense. This approach makes it incumbent on the researcher to decide how to infer the “true” visit duration. Does anyone use some kind of inference technique to assign the visit end date in these cases?

Thanks,
Ajit

Still Active Visit at time of Data Cut
Utilizing the CDM for Clinical Applications with Second-Level Response Times
#2

@Ajit_Londhe:

Depends on the kind of visit you have in mind:

  • Outpatient: end_date=start_date
  • ER: end_date=start_date, maybe +1
  • Inpatient: 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.
  • Long term care: That’s tough. Similar to the usual Observation Period problem.
#3

For long term care events I looked at Truven where the place of service is (Skilled Nursing Facility (31), Nursing Facility (32), Hospice (34) or Assisted Living Facility (35) ). Most records are in the Outpatient services table.

I would create a Long term care visit where the start and end dates are the service date from the claim. That is the visit will be for one day. There may be multiple long term care visits for the person. I would not try to create a single Long term care visit for the person.

For Inpatient services deemed to be LTC I would create a Visit Occurrence record using the Admission and discharge dates. Again this may result in multiple long term care visits for the person.

#4

Friends:

Moving a debate from the Github THEMIS issues here, @aostropolets is scolding me there.

Let’s think use cases. What do we want to capture with a visit? A certain type of engagement with the healthcare system. Healthcare has to happen, either diagnosis, monitoring or treatment. So, it looks to me like we are talking three categories, which will also define our end_date strategy:

  • A home for the elderly without healthcare, which is none of our business here. We should not have that in the data.
  • A place for a frail old person with some care, usually by a nurse, with little perspective of recovering. The end_date can be probably be set at the latest reasonable choice (e.g. death date).
  • A place for a person requiring long term care, like a rehab, but with the perspective of eventually returning home or to an institution that is outside the healthcare system. The end date should be set less aggressively, but later than you would usually expect from an inpatient visit.

I am not familiar how the claims systems above mentioned by @DTorok relate to these categories. @jenniferduryea, @Gowtham_Rao? But doing one-day visits in a long-term care facility makes little sense to me.

#5

Without getting bogged down in the LTC debate, I have an issue with @DTorok’s suggestion of making LTC visits one day long when the visit_end_date is not specified.

From the claims perspective, there are two types of claims submitted while a patient is in long-term care - one from the doctor and one from the facility (where the patient actually resides). Doctors not contracted with the facility submit bills on their behalf. Those services last one day (i.e. evaluation/management visits that check on the general status/well being of the patient). And I am ok with setting those visit_end_dates = visit_start_dates since the length of time for that service is always within a day.

However, you should not make visit_end_dates = visit_start_dates for facility claims. Some facility claims are billed on a monthly basis (SNF reference here and (section 40) Medicare SNF Billing Manual; Hospice billing reference - section 90 (Medicare Hospice Facility Billing)) when a patient is in a skilled nursing facility (i.e. rehab after an acute inpatient setting) or hospice. Sometimes these patients can be in the SNF/hospice for months at a time. These facilities bill for the patient services by month and do not put in a discharge date because the patient is still in the SNF/hospice. However, the facility will bill using the start and end of the month to indicate the invoice date for the services charged. For these claims, I suggest using the claim’s billing start and end date as the visit start/end dates. This is because:

  1. Line items services (i.e. services attached to revenue codes) will have dates throughout the month. These services should be within the visit occurrence record’s start/end dates. If we were to set the visit_start_date = visit_end_date, you are going to get revenue codes/services (i.e. procedure_occurrence records) from the facility claim that are outside of that imputed one day visit. And that doesn’t make sense to anyone.
  2. This monthly visit record is more in line with what actually happened. The patient was in the facility for that month. So the facility is billing services (i.e. room and board services, nursing services, etc.) for that month.

I know there are other ideas of handling LTC visits, but imputing one-day events for LTC facility claims is problematic. And I suggest using the claim invoice dates (aka claim billing dates, claim dates - as named in other data sources) for visit_end_dates because that is the best information available to the user.

#6

What about the following . . . .

RECOMMENDATION
`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.`

ACTION
Add this as a convention under VISIT_OCCURRENCE

#7

@ericaVoss,

I like your suggestion and this will work for most of our data. However, our EHR data contain current inpatient visits. The person is still in the hospital, so there isn’t a visit_end_date. Null is against conventions, using the date of the data pull is inaccurate for length of stay calculations, and using a future date will also lead to inaccurate LOS. Suggestions?

#8

@MPhilofsky - so these are visits that cross the end of the time in the DB? Would you just end them when the DB ends?

#9

@ericaVoss,

Our database doesn’t end. We do daily incremental loads of current (well, almost current) data.

#10

@MPhilofsky - If you are doing incremental loads how do you handle a situation where a visit is still ongoing? Do you update existing VISIT_OCCURRENCE records as the end date extends until it is locked?

#11

@MPhilofsky could it make sense to update the VISIT_END_DATE each day the person is in the hospital and use the discharge status to denote they are still an active patient? Then when they are actually discharged, the discharge status can be updated to reflect that they left.

#12

How about adding

  1. For inpatient visits ongoing at the date of ETL, put today’s date as mandatory visit_end_date

(or ETL date)

OR
allow null

OR
don’t put the unfinished inpatient stays into the dataset at all and document them in metadata table how much data you “redacted” )

EDIT:
…hmmm https://blogs.iq.harvard.edu/how_many_data_a (is data countable or not?)

1 Like
#13

We can’t make it null as we are obliged to fill it. So far we indeed suggest using start date for most of the cases. On the other hand, it hardly reflects the realities of long term care visits.
“don’t put the unfinished inpatient stays into the dataset at all and
document them in metadata table how much data you “redacted” )” - then we might lose too many patients (especially keeping in mind that end date may be lost after a patient was discharged).

#14

Friends:

I’m with @aostropolets. It’s a small number of visits, and unless we want to anchor something to the discharge it won’t matter. So, 5) it is. :slight_smile:

#15

can you do visit_end_date = date of most recent data/etl, but mark discharge_to_concept_id as 'receiving care actively"

#16

I like @Gowtham_Rao add above but is there a concept for this. There is a discharge code of 30-still patient but that doesn’t seem to have a good standardize CONCEPT_ID. Do we need to create one or was there one you were thinking of?

If I’m processing all this properly . . .

ACTION
`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 today’s date as mandatory visit_end_date and set the DISCHARGE_TO_CONCEPT_ID as TBD CONCEPT_ID`

ACTION
Add this as a convention under VISIT_OCCURRENCE

@MPhilofsky - what do you think?

1 Like
#17

http://athena.ohdsi.org/search-terms/terms/32220

2 Likes
#18

@ericaVoss & @Gowtham_Rao,

#5, Ongoing inpatient visits, with the concept_id Gowtham suggested will work for our purposes.

Thanks!

2 Likes
#19

Good add @Gowtham_Rao and @MPhilofsky.

RECOMMENDATION
`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.`

ACTION
Add this as a convention under VISIT_OCCURRENCE

Making sense of date offsets in generated SQL
#20

Great!

1 Like
t