OHDSI / Themis

Repository for OMOP CDM conventions as defined by THEMIS. These can be reference lists of concepts, pieces of standardized code for data generation or quality certification, and debates.
Apache License 2.0
27 stars 8 forks source link

Missing Visit End Dates #13

Open aostropolets opened 6 years ago

aostropolets commented 6 years ago
TYPE NOTES
ITEM How to handle missing visit end dates? Can we leave 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"
don-torok commented 6 years ago

I think the statement 'NEXT STEPS | no steps required' is premature. How to handle long term care visit requires some guidance.

cgreich commented 6 years ago

@don-torok: Do you think there can be? Sounds to me like an ETL problem we cannot solve centrally.

don-torok commented 6 years ago

Better to give some guidance. In last Themis meeting we agreed that it was not necessary nor desirable to attempt to create a single visit to account for all the long term care events. If the source provides a start and end date then that can be used, but if the source records the event similar to an outpatient event, except that the place of service indicates skilled nursing/hospice/nursing home, it is fine to treat it as a one day event that happens to take place in a long term care facility.

cgreich commented 6 years ago

Well, I wasn't there. But I probably would have pushed for a little more courage. Look: If you are in a nursing home you usually don't go back home. Your home is usually sold by your children, and the proceedes go into the nursing homes. Otherwise - why would we need this visit type at all?

don-torok commented 6 years ago

Good question, what is the use case for LTC? Also what is the definition, I used to think only nursing home or hospice, but others include skilled nursing which would include rehab time from which one would like to return.

aostropolets commented 6 years ago

Friends: I know there’s a forum post about that. Can we switch to it? GitHub is for issues we agreed on, not for discussions. The decision here is to leave visit_end_date mandatory, so no further steps are required. Don, we can help you with LTC on forum.

chandryou commented 5 years ago

Friends, recently one of Korean folks asked this here.

To our knowledge, it is recommended to use visit concept id of 32220 (Still patient) which is not the standard concept any more.

Do we have any standard convention for this currently?

(For visit_end_date, we know that it is recommended to store when these data are captured)

dimshitc commented 5 years ago

Was decided that VISIT_OCCURRENCE.visit_end_date = NULL for this case. see https://forums.ohdsi.org/t/themis-2-how-do-you-handle-missing-visit-end-dates/4308/26?u=dymshyts

MelaniePhilofsky commented 1 year ago

The CDM v5.4 conventions state "For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 “Still patient” to identify the visit as incomplete."

BUT concept_id = 32220 is non-standard. AND the guidance states to put it into the visit_type_concept_id field. *_type_concept_ids reserved for the provenance of a record, 32220 should not go in there. We need to fix this. Who wants to sponsor this topic? At the very least we need to update concept_id = 32220 to standard status since only standard concept_ids are allowed in the visit_type_concept_id field.

@cgreich @dimshitc @aostropolets @don-torok @dimshitc