VisitDetail
type: StructureDefinition
node role: treeRoot
id:
  v: VisitDetail
language:
  v: en
text:
  status:
    v: extensions
  div:
    v: Generated Narrative: StructureDefinition VisitDetail Language: en Name Flags Card. Type Description & Constraints<img src="[binary]" alt="doco" style="background-color: inherit"/> <a href="StructureDefinition-VisitDetail-definitions.html#VisitDetail" title="The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.">VisitDetail 0..* Base Visit Detail OMOP Table Instances of this logical model can be the target of a Reference #xD; visit_detail_id 1..1 integer Visit Detail Identifier #xD; person_id 1..1 integer Person #xD; visit_detail_concept_id 1..1 code Visit Detail #xD; visit_detail_start_date 1..1 date Visit Detail Start Date #xD; visit_detail_start_datetime 0..1 dateTime Visit Detail Start Datetime #xD; visit_detail_end_date 1..1 date Visit Detail End Date #xD; visit_detail_end_datetime 0..1 dateTime Visit Detail End Datetime #xD; visit_detail_type_concept_id 1..1 code Visit Detail Type #xD; <a href="StructureDefinition-VisitDetail-definitions.html#VisitDetail.provider-id" title="There will only be one provider per **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.">provider_id 0..1 integer Provider #xD; care_site_id 0..1 integer Care Site #xD; visit_detail_source_value 0..1 string Visit Detail Source Va…
extension:
  url:
    v: http://hl7.org/fhir/StructureDefinition/structuredefinition-type-characteristics
    l: structuredefinition-type-characteristics
  value: Code
    v: can-be-target
extension:
  url:
    v: http://hl7.org/fhir/StructureDefinition/structuredefinition-wg
    l: structuredefinition-wg
  value: Code
    v: brr
extension:
  url:
    v: http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm
    l: structuredefinition-fmm
  value: Integer
    v: 1
    extension:
      url:
        v: http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom
        l: structuredefinition-conformance-derivedFrom
      value: Canonical
        v: http://hl7.org/fhir/uv/omop/ImplementationGuide/hl7.fhir.uv.omop
        l: hl7.fhir.uv.omop
extension:
  url:
    v: http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status
    l: structuredefinition-standards-status
  value: Code
    v: informative
    extension:
      url:
        v: http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom
        l: structuredefinition-conformance-derivedFrom
      value: Canonical
        v: http://hl7.org/fhir/uv/omop/ImplementationGuide/hl7.fhir.uv.omop
        l: hl7.fhir.uv.omop
url:
  v: http://hl7.org/fhir/uv/omop/StructureDefinition/VisitDetail
  l: VisitDetail
version:
  v: 1.0.0
name:
  v: VisitDetail
title:
  v: Visit Detail OMOP Table
status:
  v: active
date:
  v: 2026-04-02T22:51:15+00:00
publisher:
  v: HL7 International / Biomedical Research and Regulation
contact:
  name:
    v: HL7 International / Biomedical Research and Regulation
  telecom:
    system:
      v: url
    value:
      v: http://www.hl7.org/Special/committees/rcrim
description:
  v: The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.
jurisdiction:
  coding:
    system:
      v: http://unstats.un.org/unsd/methods/m49/m49.htm
      l: m49.htm
    code:
      v: 001
    display:
      v: World
fhir version:
  v: 5.0.0
mapping:
  identity:
    v: rim
  uri:
    v: http://hl7.org/v3
    l: v3
  name:
    v: RIM Mapping
kind:
  v: logical
abstract:
  v: false
type:
  v: http://hl7.org/fhir/uv/omop/StructureDefinition/VisitDetail
  l: VisitDetail
base definition:
  v: http://hl7.org/fhir/StructureDefinition/Base
  l: Base
derivation:
  v: specialization
snapshot:
  extension:
    url:
      v: http://hl7.org/fhir/tools/StructureDefinition/snapshot-base-version
      l: snapshot-base-version
    value: String
      v: 5.0.0
  element:
    id:
      v: VisitDetail
    path:
      v: VisitDetail
    short:
      v: Visit Detail OMOP Table
    definition:
      v: The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.
    min:
      v: 0
    max:
      v: *
    base:
      path:
        v: Base
      min:
        v: 0
      max:
        v: *
    is modifier:
      v: false
    mapping:
      identity:
        v: rim
      map:
        v: n/a
  element:
    id:
      v: VisitDetail.visit-detail-id
    path:
      v: VisitDetail.visit_detail_id
    short:
      v: Visit Detail Identifier
    definition:
      v: 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 detail.
    min:
      v: 1
    max:
      v: 1
    base:
      path:
        v: VisitDetail.visit_detail_id
      min:
        v: 1
      max:
        v: 1
    type:
      code:
        v: integer
        l: integer
  element:
    id:
      v: VisitDetail.person-id
    path:
      v: VisitDetail.person_id
    short:
      v: Person
    definition:
      v: Person
    min:
      v: 1
    max:
      v: 1
    base:
      path:
        v: VisitDetail.person_id
      min:
        v: 1
      max:
        v: 1
    type:
      code:
        v: integer
        l: integer
  element:
    id:
      v: VisitDetail.visit-detail-concept-id
    path:
      v: VisitDetail.visit_detail_concept_id
    short:
      v: Visit Detail
    definition:
      v: This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
    min:
      v: 1
    max:
      v: 1
    base:
      path:
        v: VisitDetail.visit_detail_concept_id

v: 1

v: 1

code:
  v: code
  l: code

id:
  v: VisitDetail.visit-detail-start-date
path:
  v: VisitDetail.visit_detail_start_date
short:
  v: Visit Detail Start Date
definition:
  v: This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.
min:
  v: 1
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_start_date
  min:
    v: 1
  max:
    v: 1
type:
  code:
    v: date
    l: date

id:
  v: VisitDetail.visit-detail-start-datetime
path:
  v: VisitDetail.visit_detail_start_datetime
short:
  v: Visit Detail Start Datetime
definition:
  v: Visit Detail Start Datetime
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_start_datetime
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: dateTime
    l: dateTime

id:
  v: VisitDetail.visit-detail-end-date
path:
  v: VisitDetail.visit_detail_end_date
short:
  v: Visit Detail End Date
definition:
  v: This the end date of the patient-provider interaction. If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.
min:
  v: 1
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_end_date
  min:
    v: 1
  max:
    v: 1
type:
  code:
    v: date
    l: date

id:
  v: VisitDetail.visit-detail-end-datetime
path:
  v: VisitDetail.visit_detail_end_datetime
short:
  v: Visit Detail End Datetime
definition:
  v: If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_end_datetime
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: dateTime
    l: dateTime

id:
  v: VisitDetail.visit-detail-type-concept-id
path:
  v: VisitDetail.visit_detail_type_concept_id
short:
  v: Visit Detail Type
definition:
  v: Use this field to understand the provenance of the visit detail record, or where the record comes from.
min:
  v: 1
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_type_concept_id
  min:
    v: 1
  max:
    v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.provider-id
path:
  v: VisitDetail.provider_id
short:
  v: Provider
definition:
  v: There will only be one provider per **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.provider_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.care-site-id
path:
  v: VisitDetail.care_site_id
short:
  v: Care Site
definition:
  v: This field provides information about the Care Site where the Visit Detail took place.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.care_site_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.visit-detail-source-value
path:
  v: VisitDetail.visit_detail_source_value
short:
  v: Visit Detail Source Value
definition:
  v: This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_source_value
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: string
    l: string

id:
  v: VisitDetail.visit-detail-source-concept-id
path:
  v: VisitDetail.visit_detail_source_concept_id
short:
  v: Visit Detail Source Concept
definition:
  v: Visit Detail Source Concept
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_detail_source_concept_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.admitted-from-concept-id
path:
  v: VisitDetail.admitted_from_concept_id
short:
  v: Admitted From
definition:
  v: 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.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.admitted_from_concept_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.admitted-from-source-value
path:
  v: VisitDetail.admitted_from_source_value
short:
  v: Admitted From Source Value
definition:
  v: Admitted From Source Value
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.admitted_from_source_value
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: string
    l: string

id:
  v: VisitDetail.discharged-to-source-value
path:
  v: VisitDetail.discharged_to_source_value
short:
  v: Discharged To Source Value
definition:
  v: Discharged To Source Value
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.discharged_to_source_value
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: string
    l: string

id:
  v: VisitDetail.discharged-to-concept-id
path:
  v: VisitDetail.discharged_to_concept_id
short:
  v: Discharged To
definition:
  v: 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 transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for "home". Use concept id = 0 when a person is discharged to home.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.discharged_to_concept_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.preceding-visit-detail-id
path:
  v: VisitDetail.preceding_visit_detail_id
short:
  v: Preceding Visit
definition:
  v: Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.preceding_visit_detail_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.parent-visit-detail-id
path:
  v: VisitDetail.parent_visit_detail_id
short:
  v: Parent Visit
definition:
  v: Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
min:
  v: 0
max:
  v: 1
base:
  path:
    v: VisitDetail.parent_visit_detail_id
  min:
    v: 0
  max:
    v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.visit-occurrence-id
path:
  v: VisitDetail.visit_occurrence_id
short:
  v: Visit Occurrence
definition:
  v: Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.
min:
  v: 1
max:
  v: 1
base:
  path:
    v: VisitDetail.visit_occurrence_id
  min:
    v: 1
  max:
    v: 1
type:
  code:
    v: integer
    l: integer

element:
  id:
    v: VisitDetail
  path:
    v: VisitDetail
  short:
    v: Visit Detail OMOP Table
  definition:
    v: The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.
element:
  id:
    v: VisitDetail.visit-detail-id
  path:
    v: VisitDetail.visit_detail_id
  short:
    v: Visit Detail Identifier
  definition:
    v: 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 detail.
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: integer
      l: integer
element:
  id:
    v: VisitDetail.person-id
  path:
    v: VisitDetail.person_id
  short:
    v: Person
  definition:
    v: Person
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: integer
      l: integer
element:
  id:
    v: VisitDetail.visit-detail-concept-id
  path:
    v: VisitDetail.visit_detail_concept_id
  short:
    v: Visit Detail
  definition:
    v: This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: code
      l: code
element:
  id:
    v: VisitDetail.visit-detail-start-date
  path:
    v: VisitDetail.visit_detail_start_date
  short:
    v: Visit Detail Start Date
  definition:
    v: This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: date
      l: date
element:
  id:
    v: VisitDetail.visit-detail-start-datetime
  path:
    v: VisitDetail.visit_detail_start_datetime
  short:
    v: Visit Detail Start Datetime
  definition:
    v: Visit Detail Start Datetime
  min:
    v: 0
  max:
    v: 1
  type:
    code:
      v: dateTime
      l: dateTime
element:
  id:
    v: VisitDetail.visit-detail-end-date
  path:
    v: VisitDetail.visit_detail_end_date
  short:
    v: Visit Detail End Date
  definition:
    v: This the end date of the patient-provider interaction. If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: date
      l: date
element:
  id:
    v: VisitDetail.visit-detail-end-datetime
  path:
    v: VisitDetail.visit_detail_end_datetime
  short:
    v: Visit Detail End Datetime
  definition:
    v: If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.
  min:
    v: 0
  max:
    v: 1
  type:
    code:
      v: dateTime
      l: dateTime
element:
  id:
    v: VisitDetail.visit-detail-type-concept-id
  path:
    v: VisitDetail.visit_detail_type_concept_id
  short:
    v: Visit Detail Type
  definition:
    v: Use this field to understand the provenance of the visit detail record, or where the record comes from.
  min:
    v: 1
  max:
    v: 1
  type:
    code:
      v: code
      l: code
element:
  id:
    v: VisitDetail.provider-id
  path:
    v: VisitDetail.provider_id
  short:
    v: Provider
  definition:
    v: There will only be one provider per **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.
  min:
    v: 0
  max:
    v: 1
  type:
    code:
      v: integer
      l: integer
element:
  id:
    v: VisitDetail.care-site-id
  path:
    v: VisitDetail.care_site_id
  short:
    v: Care Site
  definition:
    v: This field provides information about the Care Site where the Visit Detail took place.
  min:
    v: 0
  max:
    v: 1
  type:
    code:
      v: integer
      l: integer
element:
  id:
    v: VisitDetail.visit-detail-source-value
  path:
    v: VisitDetail.visit_detail_source_value
  short:
    v: Visit Detail Source Value
  definition:
    v: This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)
  min:
    v: 0
  max:
    v: 1
  type:
    code:
      v: string
      l: string
element:
  id:
    v: VisitDetail.visit-detail-source-concept-id
  path:
    v: VisitDetail.visit_detail_source_concept_id

v: Visit Detail Source Concept

v: Visit Detail Source Concept

v: 0

v: 1

code:
  v: code
  l: code

id:
  v: VisitDetail.admitted-from-concept-id
path:
  v: VisitDetail.admitted_from_concept_id
short:
  v: Admitted From
definition:
  v: 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.
min:
  v: 0
max:
  v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.admitted-from-source-value
path:
  v: VisitDetail.admitted_from_source_value
short:
  v: Admitted From Source Value
definition:
  v: Admitted From Source Value
min:
  v: 0
max:
  v: 1
type:
  code:
    v: string
    l: string

id:
  v: VisitDetail.discharged-to-source-value
path:
  v: VisitDetail.discharged_to_source_value
short:
  v: Discharged To Source Value
definition:
  v: Discharged To Source Value
min:
  v: 0
max:
  v: 1
type:
  code:
    v: string
    l: string

id:
  v: VisitDetail.discharged-to-concept-id
path:
  v: VisitDetail.discharged_to_concept_id
short:
  v: Discharged To
definition:
  v: 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 transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for "home". Use concept id = 0 when a person is discharged to home.
min:
  v: 0
max:
  v: 1
type:
  code:
    v: code
    l: code

id:
  v: VisitDetail.preceding-visit-detail-id
path:
  v: VisitDetail.preceding_visit_detail_id
short:
  v: Preceding Visit
definition:
  v: Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
min:
  v: 0
max:
  v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.parent-visit-detail-id
path:
  v: VisitDetail.parent_visit_detail_id
short:
  v: Parent Visit
definition:
  v: Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.
min:
  v: 0
max:
  v: 1
type:
  code:
    v: integer
    l: integer

id:
  v: VisitDetail.visit-occurrence-id
path:
  v: VisitDetail.visit_occurrence_id
short:
  v: Visit Occurrence
definition:
  v: Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.
min:
  v: 1
max:
  v: 1
type:
  code:
    v: integer
    l: integer