-
Notifications
You must be signed in to change notification settings - Fork 450
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
Comments
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. |
Agree about
Other alternative name maybe
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+? |
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 IMO, we keep the naming conventions that were established to be consistent with the naming conventions of the Visit Occurrence table. |
Like this? Place_from_source_value Place_to_source_value |
More something like that: admitting_concept_id discharge_to_concept_id Then adding 2 fields is consistent as @MelaniePhilofsky proposed |
Agreed, though I would further argue for prefixes |
I would prefer we do not include the admitting_source_value 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. |
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. |
@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. |
So, we are changing "source" to what? "Visit"? |
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. |
Why not just say visit_from_* visit_to_*? Or place_from_*? Etc. Not all visits are admissions. And admissions generally mean inpatient visits |
@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. |
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. |
Please correct me if I am wrong. The two fields in question are to represent
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 |
@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. |
@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:
|
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 Thank you for the clarification. |
I would repeat the point made by @MelaniePhilofsky - which I didn't notice at first either. Since there is a Renaming the admitting column still seems relevant for VISIT_OCCURRENCE though: https:/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE |
added in v6.0 |
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 haveadmitting_concept_id
for the standardized data, notadmitting_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
anddischarged_to
admission_
anddischarge_
from_
andto_
Happy to separate the latter part out to a separate issue if it's desired.
The text was updated successfully, but these errors were encountered: