Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VISIT_DETAIL/VISIT_OCCURRENCE admission column name is inconsistent #153

Closed
alistairewj opened this issue Jan 23, 2018 · 20 comments

Comments

@alistairewj
Copy link

commented Jan 23, 2018

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

This comment has been minimized.

Copy link

commented Jan 25, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2018

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

This comment has been minimized.

Copy link

commented Jan 25, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2018

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

This comment has been minimized.

Copy link

commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 31, 2018

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

This comment has been minimized.

Copy link

commented Jan 31, 2018

@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

This comment has been minimized.

Copy link

commented Feb 1, 2018

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 clairblacketer self-assigned this Aug 7, 2018
@clairblacketer clairblacketer added this to To do in CDM v6.0 via automation Aug 7, 2018
@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 2, 2018

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

@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

Why not just say visit_from_* visit_to_*?

Or place_from_*? Etc.

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

@cgreich

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 4, 2018

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 clairblacketer moved this from To do to Done in CDM v6.0 Sep 25, 2018
This was referenced Oct 11, 2018
@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

added in v6.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
CDM v6.0
  
Done
7 participants
You can’t perform that action at this time.