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.

[gowthamrao]

Why not just say visit_from_* visit_to_*?

Or place_from_*? Etc.

Not all visits are admissions. And admissions generally mean inpatient visits

[cgreich]

@gowthamrao: Remember, we are not linking actual Visits. We are linking Visit Concept IDs. We may or may not have that visit in our books.

So: Admission_from_visit_concept_id? One character too long for the old Oracle restriction.

[clairblacketer]

I did admitted_from_concept_id and admitted_from_source_value as the intent is that it will house a concept in the place of service vocabulary. These should meet the Oracle requirement. To @gowthamrao 's point, yes the word admit typically evokes inpatient visits, but I am not sure of an outpatient instance where you would need or even have the information of where they were previously.

[gowthamrao]

Please correct me if I am wrong. The two fields in question are to represent

• where was the patient before start of the visit
• where will the patient go at the end of the visit

E.g. if a patient came FROM (source) home for an emergency room visit and LEFT TO (disposition) home after that visit.

Or, a patient came FROM physician office (source) for an inpatient hospital visit, and then got discharged TO rehabilitation unit

@cgreich agree, we are not linking across visits. We are only characterizing a single visit. Where did the patient come FROM for the visit and where is the patient going TO after the visit.

So, the two key words are FROM & TO

[gowthamrao]

@clairblacketer to address your question about the need for information about where the patient came from in outpatient settings.

In US health care, there are financial differentials based on site of care. So, transitions between site of care are important use cases for health economic analysis. This information is used for pricing and managing resource allocation.

E.g. if a patient presented to an outpatient diagnostic/imaging facility from an ambulatory surgical center, this is an important piece of information.

Lot of use cases around how outpatient infusion centers for drugs get referrals - did the patient come from home, from nursing home, from skilled nursing facility, etc.

[clairblacketer]

@gowthamrao that's fair, though it's not a typical piece of information we regularly see on outpatient claims nor has there been an analytic use case as of yet. I would prefer to keep the columns as admitted_from_* and discharged_to_* for 2 reasons:

1. It reduces thrash in the tables. My aim is to keep the tables as stable as possible and I don't want to change column names unless it is absolutely necessary. In this case, admission_source_concept_id was actually meant to house a standard concept and went against the agreed upon naming convention for capturing source and standard information, thereby requiring a change.
2. The names from_* and to_* do not clearly elucidate their meaning. As much as we can in the CDM we try to keep the names as descriptive as possible so upon first glance you have an idea of what type of data a column contains. While the term "admission" may not technically apply to every situation, most people knows that it means "the process or fact of entering or being allowed to enter a place, organization, or institution". Yes, it more precisely describes an inpatient encounter but I see from_* and to_* potentially causing more confusion as the names alone are ambiguous.

[gowthamrao]

Thank you Clair. I think, we all seem to agree with the meaning/intent behind the fields in question. This is most important. I think we should document the meaning in the CDM field description wiki page.

I agree with you that making major name changes are difficult. We should avoid it.

I think I see the concern of using just
from_* and to_* , as being potentially ambiguous.

Thank you for the clarification.

[alistairewj]

I would repeat the point made by @MelaniePhilofsky - which I didn't notice at first either. Since there is a care_site_id field and a preceding_visit_detail_id field, you can quite easily derive the admitting/discharge locations within a visit occurrence - making the additional columns redundant for tracking locations. For the first visit detail in this table with no preceding row, you can cross-reference with visit_occurrence (with a similar argument for the last visit). There may be an argument for dropping the columns entirely from this table to ensure consistency in the use of the CDM.

Renaming the admitting column still seems relevant for VISIT_OCCURRENCE though: https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE

[clairblacketer]

added in v6.0