Hi everyone,
Tomorrow we have a CDM workgroup meeting at 1pm eastern where we will be continuing our discussion of the VISIT_OCCURRENCE table. The Skype meeting link can be found on our homepage and the straw-man description of the VISIT_OCCURRENCE table is below. Please review and come ready to discuss.
Clair
Table Description
This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.
| CDM Field Name | User Guidance | ETL Conventions |
|---|---|---|
| visit_occurrence_id | Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit. | This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. |
| person_id | ||
| visit_concept_id | This field contains a concept id representing the kind of visit, like inpatient or outpatient. | Populate this field based on the kind of visit that took place for the person. For example this could be "Inpatient Visit", "Outpatient Visit", "Ambulatory Visit", etc. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. In US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. |
| visit_start_date | For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same. | When populating visit_start_date, you will first have to make decisions on how to define visits. In some cases visits in the source data can be strung together if there are one or fewer days between them. |
| visit_start_datetime | If no time is given for the start date of a visit, set it to midnight (00:00:0000). | |
| visit_end_date | For inpatient visits the end date is typically the discharge date. | Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: Outpatient Visit: visit_end_datetime = visit_start_datetime Emergency Room Visit: visit_end_datetime = visit_start_datetime Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. 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. All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date. |
| visit_end_datetime | If no time is given for the end date of a visit, set it to midnight (00:00:0000). | |
| visit_type_concept_id | Use this field to understand the provenance of the visit record, or where the record comes from. | Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. |
| provider_id | There will only be one provider per visit. If multiple providers are associated with a visit that information can be found in the VISIT_DETAIL table. | If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the visit_detail table. |
| care_site_id | This field provides information about the care site where the visit took place. | There should only be one care site associated with a visit. |
| visit_source_value | This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.) | If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created. |
| visit_source_concept_id | If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. | |
| admitting_source_concept_id | Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example. | If available, map the admitted_from_source_value to a standard concept in the visit domain. |
| admitting_source_value | This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits. | |
| discharge_to_concept_id | Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example. | If available, map the discharge_to_source_value to a standard concept in the visit domain. |
| discharge_to_source_value | This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more. | |
| preceding_visit_occurrence_id | Use this field to find the visit that occured for the person prior to the given visit. There could be a few days or a few years in between. | The preceding_visit_id can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a "following_visit_id". |
.