CARE_SITE_ID and VISIT_DETAIL_CONCEPT_ID

CDM Builders
1

Hi All,

Today during the CDM working group call we started discussing the VISIT_OCCURRENCE and VISIT_DETAIL tables. @DTorok questioned the necessity of the CARE_SITE_ID in the VISIT_DETAIL table since records in the VISIT_DETAIL table roll up to records in the VISIT_OCCURRENCE table and therefore should always be related to the CARE_SITE_ID in the parent Visit record. We dug a little deeper and read our new and improved documentation on the CARE_SITE table where we realized that Care Sites can be physical locations like hospitals but they can also be wards within the hospital like ICU or Med-Surg. Herein lies the core of our question:

Should movements between hospital wards be tracked using

  1. The CARE_SITE_ID in the VISIT_DETAIL table OR
  2. The VISIT_DETAIL_CONCEPT_ID in the VISIT_DETAIL table

@MPhilofsky have you all in the EHR group decided how to handle this issue?

2

The fact that some of the same concepts ( where domain_id = ‘Visit’ and vocabulary_id IN( ‘CMS Place of Service’, ‘NUCC’) can be used as both VISIT_CONCEPT_ID and PLACE_OF_SERVICE_CONDEPT_ID in CARE_SITE can be confusing. But, if we agree that the VISIT or VISIT_DETAIL concept_id only refers to a generic facility type, ‘Psychiatric Hospital’ and that only the CARE_SITE can refer to a specific ‘Psychiatric Hospital’ then the overlap of concepts can be explained.

A problem with our description of a Visit is a statement that the Visit and Visit Detail must all be the ‘same’ Care Site which means it will be an error if the Care Site Id in any of the Visit Detail records is different. I think the intent is that the Care Sites in the detail belong to the same establishment, (dare say Organization). It may be helpful to add a column to Care Site for ‘parent’ Care Site to more easily create and follow relationships between Care Sites.

1 Like
3

The visit_detail_concept_id is NOT granular enough to track movements between hospital wards. It doesn’t distinguish a surgical ICU from a med-surg ICU from the neonatal ICU from the pediatric ICU, etc.

The EHR WG has had informal discussions about the level of granularity for Visit Detail data. Most EHR data holders track via the department level care_site_id.

This is a problem for EHR data. A Visit is the time a Person enters a hospital/establishment/organization until they leave the hospital/establishment/organization. This “hospital/establishment/organization” is one care_site_id. The Visit Details are the departments/wards/units within the hospital/establishment/organization. And each departments/wards/units has a different care_site_id.

The Visit Detail table links to the parent Visit Occurrence record via the VISIT_DETAIL.visit_detail_parent_id. The parent record in Visit Occurrence table has a VISIT_OCCURRENCE.care_site_id.

4

Why only those vocabularies, @DTorok?

Needs to go away.

I agree, the Case Site in a Visit Detail should be the same or some kind of a descendant of that in a Visit Occurrence record. The question is whether or not we need to make that explicit, or if an implicit understanding suffices. After all, we realize that the exact identity of Care Sites is impossible to interpret outside the context of an institution, and all we really want is to be able to incorporate this information into co-variates or strata.

…, which, if necessary we can add to the Visit hierarchy. Of course only to determine a generic care setting, not as a way to identify a Care Site “specialty”. Not sure this is true, here.

I would agree with @MPhilofsky.

5

I do not see a consensus of opinion. @Christian_Reich seems to be advocating that the Care Site is just a geographic location with no intrinsic properties (as implied by the place of service code). This means that the specificity @MPhilofsky is looking for ( distinguish a surgical ICU from a med-surg ICU from the neonatal ICU from the pediatric ICU) needs to be incorporated into the visit and visit detail concept id.

6

Where is the contradiction?

7

It’s not necessary.

Colorado’s original use case for the Visit Detail table was for outcomes research for a Procedure happening at two different department care_sites within the same hospital. This can’t be done at the Visit level because the Visit record only records the care site at the hospital level. Therefore, we petitioned for the Visit Detail table to connect clinical events with the department level Care Site where the clinical event occurred. The Visit Detail table also allows us to track a Person’s journey through the hospital, especially important to see which clinical events lead to a higher level of care.

We don’t need more granular Visit concept_ids, the care_site_ids suffice for our use case. I do think defining concept_ids at the SICU, MICU, NICU and PICU would be quite difficult. At the larger, urban hospitals there may be multiple SICUs usually with a different clinical domain expertise. And the larger, urban hospital ICU is not comparable to the rural, critical access hospital.

And to join the metaphor party. We’re comparing gala apples to honey crisp apples, both are red apples, but not the same :slight_smile:

1 Like