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

Location History Table #181

Closed
clairblacketer opened this issue May 10, 2018 · 11 comments

Comments

@clairblacketer
Copy link
Contributor

commented May 10, 2018

This is a link to the location history table proposal on the GIS githhub page. This proposal was accepted on 5/10/2018 and will be added to an upcoming version of the cdm.

@gowthamrao

This comment has been minimized.

Copy link
Contributor

commented May 10, 2018

Instead of entity_id can we call it entity_concept_id

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented May 10, 2018

@gowthamrao I don't know that entity_concept_id would fit, the idea is that the field would house something like a person_id or a care_site_id

@gowthamrao

This comment has been minimized.

Copy link
Contributor

commented May 11, 2018

Thank you for the clarification.

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2018

reopening this since it has not yet been added to the cdm

@clairblacketer clairblacketer added this to To do in CDM v6.0 Jul 16, 2018
@clairblacketer clairblacketer moved this from To do to In progress in CDM v6.0 Jul 16, 2018
@clairblacketer clairblacketer moved this from In progress to on Dev in CDM v6.0 Jul 25, 2018
@gowthamrao

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2018

Initially posted here 5d26033

@clairblacketer @cgreich @pbr6cornell

The location_history table is going to be an extremely large (EAV) like table. Currently we have two varchar(30) columns

  • relationship_type with values 'residence', 'work', 'school' etc
  • domain_id with values 'PERSON', 'PROVIDER', 'CARE_SITE' etc

Can we convert these to integers - using concept_id

i.e. instead of relationship_type, change to relationship_type_concept_id
domain_id to domain_concept_id or table_concept_id (to differentiate between tables belonging to same domain_id like visit_occurrence and visit_detail)

Integers would be expected to lead to better performance, I think. Plus, it would achieve the same end-goal that the CDM WG wants to represents in this table.

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2018

@gowthamrao we are going to discuss changing all domain_id references to table_concept_id at the September CDM meeting. I agree it would help cut down on confusion where two tables have the same domain.

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2018

@rtmill how do you feel about the relationship_type_concept_id field?

@cgreich

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2018

I agree with both.

@rtmill

This comment has been minimized.

Copy link

commented Aug 28, 2018

@clairblacketer @gowthamrao @cgreich That was the plan for relationship_type (create a small vocabulary) and I agree it also makes sense for domain_id. This seems similar to the way domains are represented in the FACT_RELATIONSHIP table?

then it would be:
relationship_type -> relationship_type_concept_id
domain_id -> domain_concept_id
?

The question I remember during the proposal was whether or not we should include relationship_type_source_value.

@clairblacketer clairblacketer self-assigned this Aug 29, 2018
@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2018

@rtmill from the proposal it looks like there will only be four options for relationship_type_concept_id ('residence', 'work site', 'school', NULL) so I don't see the need for a *source_value field. We can always add it later if the use case comes up.

In terms of domain_concept_id, we will most likely be moving to table_concept_id instead as there are multiple tables with the same domain (visit_occurrence, visit_detail) which makes it tricky for other tables that reference domain, like COST. For now we will keep it as domain_id until a decision is made on 9/4.

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

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
4 participants
You can’t perform that action at this time.