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

For CDM v6 consolidate visit occurrence and visit detail into a single table #208

Closed
don-torok opened this issue Aug 8, 2018 · 9 comments

Comments

@don-torok
Copy link

Add a new column, parent_visit_occurrence_id, to visit occurrence and eliminate the visit detail table.

@gowthamrao
Copy link
Member

gowthamrao commented Aug 8, 2018

I am in support of this idea (infact this was the original proposal) I like less tables. But it may become a major change.

The reason we split it this way, was because the CDM work group did not want to mess up a core CDM table.

  1. Performance, @chrisknoll said (I think) that recursive reference to self i.e. parent_visit_occurrence_id is a performance problem.
  2. We have visit_detail_id in the clinical event tables that need to be deleted. E.g. condition_occurrence

We may also want to add a concept_id field that what level of the ancestor is the current record - something similar to concept_ancestor. Or, we need to create a visit_ancestor table that is similar to concept_ancestors design

@gowthamrao
Copy link
Member

I also think the proposed TREATMENT table by the oncology workgroup maybe then absorbed into this visit_occurrence table, because

treatment is a span of time that a person gets care, represented by multiple events
Visit is a span of time that a person gets care, represented by multiple events

@clairblacketer
Copy link
Contributor

I would prefer to leave VISIT_DETAIL as-is for now. In the initial proposal @cgreich laid out many good reasons why we need the two tables. Additionally, some organizations just converted to CDM v5.3, which is where the VISIT_DETAIL table was first added, and I don't think it would be smart to remove it in v6.0 undoing the work that has already been done.

@clairblacketer
Copy link
Contributor

Closing this but @dtorok feel free to reopen if you would like this to become a full proposal

@cgreich
Copy link
Contributor

cgreich commented Jan 6, 2021

Actually: Is anybody using VISIT_DETAIL?

@clairblacketer
Copy link
Contributor

clairblacketer commented Jan 6, 2021

Yes! I populate and use VISIT_DETAIL regularly. I even have standard logic that builds VISIT_OCCURRENCE records from VISIT_DETAIL

@gklebanov
Copy link

Yes, we populated in all of our ETLs too. But I think Christian's question is not whether we populate it, but if it is being used in studies?

@cgreich
Copy link
Contributor

cgreich commented Jan 7, 2021

Right. How do we populate, and does that feed a use case. Should we review?

@cukarthik
Copy link
Contributor

We populate it. We don't use it in OHDSI studies, but are starting to use it internally for other analysis on the inpatient side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants