Visit Detail

The VISIT_DETAIL table is used to represent clinically meaningful movements of a patient within each record of the parent VISIT_OCCURRENCE table.

Each row of the VISIT_DETAIL table represents a transfer between Care Sites within the hospital. Within the scope of this project, Care Sites represent generic levels of care, rather than specific beds. This is because beds are both identifying to the local site, and cannot be understood without specific knowledge of the hospital.

A movement between geographically separate Care Sites should trigger a new row in the VISIT_DETAIL table. Bed movements within a ward, are not expressed as new rows. Examples of movements that each trigger a new Visit Detail record include:

• A&E Majors -> A&E Resus -> ICU
• Adult Inpatient Ward -> Adult Inpatient Ward (geographically new ward)

For every Visit Occurrence record there may be 0 or more Visit Detail records, with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE and belongs to the similar domain as the visit.

Field	Required	Type	FK Table	Description
visit_detail_id	Yes	bigint		A unique identifier for each Person’s visit or encounter at a healthcare provider.
person_id	Yes	bigint	PERSON	A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table.
visit_detail_concept_id	Yes	bigint	CONCEPT	A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies.
visit_detail_start_date	Yes	date		The UTC start date of the visit.
visit_detail_start_datetime	No	datetime		The date and time of the visit started.
visit_detail_end_date	No	date		The end date of the visit. If this is a one-day visit the end date should match the start date. NULL if the patient is still there.
visit_detail_end_datetime	No	datetime		The UTC date and time of the visit end. NULL if the patient is still there.
visit_detail_type_concept_id	No	bigint	CONCEPT	Not used.
provider_id	No	bigint	PROVIDER	Not used.
care_site_id	Yes	bigint	CARE_SITE	A foreign key to the care site in the care site table that was visited.
visit_detail_source_value	No	varchar(50)		The source code for the visit as it appears in the source data (e.g. a transfer identifier).
visit_detail_source_concept_id	No	bigint	CONCEPT	If the visit_detail_source_value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.
admitting_source_value	No	Varchar(50)		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.
admitting_source_concept_id	No	bigint	CONCEPT	If available, map the admitted_from_source_valu e to a standard concept in the visit domain.
discharge_to_source_value	No	varchar(50)		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.
discharge_to_concept_id	No	bigint	CONCEPT	If available, map the discharge_to_source_value to a Standard Concept in the Visit domain.
preceding_visit_detail_id	No	bigint	VISIT_DETAIL	A foreign key to the Visit Detail record of the visit immediately preceding this visit.
visit_detail_parent_id	No	bigint	VISIT_DETAIL	A foreign key to the Visit Detail record representing the immediate parent of this visit. A visit with a parent is a visit that does not free the parent bed - i.e. a visit to the OR, CT / X-RAY.
visit_occurrence_id	Yes	bigint	VISIT_OCCURRENCE	A foreign key that refers to the parent Visit Occurrence record. This is a required field, because every Visit Detail is child of a Visit Occurrence and cannot exist without a corresponding parent record in the VISIT_OCCURRENCE table.

Conventions

Most conventions used in Visit Occurrence apply to Visit Detail, with some notable exceptions:

• A Visit Detail is an optional detail record for each Visit Occurrence to a healthcare facility. For every record in VISIT_DETAIL there has to be a parent Visit Occurrence record.
• One record in VISIT_DETAIL can only have one Visit Occurrence parent.
• A single Visit Occurrence record may have many child Visit Detail records.

• Unlike Visit Occurrence, Visit Detail may have nested visits with hierarchical relationships to each other.

  Example: an entire inpatient stay may be expressed as one Visit Occurrence record. This may have any number of Visit Detail records such as A&E, ICU, Adult Inpatient, etc. Each of these Visit Details may have different start/end date-times and different concept ids. These would become separate Visit Detail records with a foreign key link to the Visit Occurrence.

  Each record within VISIT_DETAIL may be related to each other, sequentially: e.g., A&E leading to ICU leading to ward. Hierarchical parent-child visits are not expressed in HIC-CC (for example a visit for a CT scan while in ICU.)

Relationship to VISIT_OCCURRENCE