VISIT_DETAIL/VISIT_OCCURRENCE admission column name is inconsistent

[alistairewj]

The VISIT_DETAIL and table has four columns representing admission source and discharge disposition:

• admitting_source_concept_id
• admitting_source_value
• discharge_to_concept_id
• discharge_to_source_value

The description of admitting_source_concept_id is: "A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit."

I think the word "source" here is inconsistent with the use of the word source in other columns: admitting_source_value is the original data, and next to it we should have admitting_concept_id for the standardized data, not admitting_source_concept_id.

While on this topic, perhaps the column names could be changed to enhance consistency and clarity in the data. Some potential prefix alternatives:

• admitted_from and discharged_to
• admission_ and discharge_
• from_ and to_

Happy to separate the latter part out to a separate issue if it's desired.

[survitup]

In addition to that inconsistency, the convention section the documentation makes reference to a non-existent column (discharge_disposition_concept_id) which I assume is meant to be there or instead discharge_to_concept_id.

[gowthamrao]

Agree about

inconsistent with the use of the word source in other columns: admitting_source_value is the original data, and next to it we should have admitting_concept_id for the standardized data, not admitting_source_concept_id.

Other alternative name maybe

• visit_place_from. visit_place_from_concept_id (27 characters - Oracle will be fine)
• visit_place_to visit_place_to_concept_id

This generalizes it further, and but referencing only admission and discharge, which are usually used for inpatient visits. Since we are using place of service Concept id for these fields, the name place makes sense.

@cgreich I like this. These are lesser used fields in the table. I don't think ohdsi standard tools are using them . Proposal from v6+?

[MelaniePhilofsky]

For every *_concept_id in the CDM there should be a *_source_value to represent the data as it appears in the source system and a *_source_concept_id to represent "A foreign key to a Concept that refers to the code used in the source". This table (and the Visit Occurrence table) are missing the following fields:

admitting_concept_id
discharge_to_source_concept_id

IMO, we keep the naming conventions that were established to be consistent with the naming conventions of the Visit Occurrence table.

[gowthamrao]

Like this?

Place_from_source_value
Place_from_value
Place_from_source_concept_id
Place_from_concept_id

Place_to_source_value
Place_to_value
Place_to_source_concept_id
Place_to_concept_id

[parisni]

More something like that:

admitting_concept_id
admitting_source_concept_id
admitting_source_value

discharge_to_concept_id
discharge_to_source_concept_id
discharge_to_source_value

Then adding 2 fields is consistent as @MelaniePhilofsky proposed

[alistairewj]

Agreed, though I would further argue for prefixes from_ and to_ because there are quite a few instances of using this table to track transfers and not admissions.

[MelaniePhilofsky]

@alistairewj ,

I would prefer we do not include the

admitting_source_value
admitting_source_concept_id
admitting_concept_id
discharge_to_source_value
discharge_to_source_concept_id
discharge_to_concept_id

fields in the Visit Detail table because these are repetitive fields from the parent Visit_Occurrence table. We only need admission & discharge once at the Visit level. Let's just get rid of them, unless @gowthamrao has a use case?

Every row in the visit_detail table has the care_site_id field and preceding_visit_detail_id field. We are able to string together the visit_detail_id and the care_site_ids to track transfers within the Visit. The conventions for the admitting_______ fields and the discharge_to________ fields state that Place of Service codes are to be used. The Place of Service code set does not offer the granularity required to track inpatient transfers. Please see this example I posted to the forum http://forums.ohdsi.org/t/visit-occurrence-and-details-discharge-to/3916/2?u on how to use the table to track transfers.

[parisni]

The Place of Service code set does not offer the granularity required to track inpatient transfers.

I assume this is mainly because visit_detail does not yet have any dedicated vocabulary. That would make sense to add track of transfers into Place of Service for visit_detail and not reuse those created for visit_occurrence. ("ward transfer", "bed transfer", "service transfer" and so on) to be able to finely describe what "details" appens, and not general information already stated in visit_occurrence.

In the meantime, in your example, duplicating information from visit_occurrence into visit_detail (eg: inpatient visit). Again, dedicated new vocabulary for visit_detail would be a great opportunity to fit better EHR data.

[clairblacketer]

@cgreich I think the renaming of the admitting_source_* columns in visit_occurrence and visit_detail should be renamed in v6.0 to admitted_from_* as described above. The use of the word 'source' is confusing here and admitting_source_concept_id is actually meant to house a standard concept for the place where the patient was admitted from.

[cgreich]

So, we are changing "source" to what? "Visit"?

[clairblacketer]

So we are changing admitting_source_* to admitted_from_*. This seemed like the least offensive option since it retains some of the initial naming convention.